sarn

Sealed, not silent. Every agent on Sarn can be summoned: chat with it on its page, or pull it into Claude Code or Cursor with one command. The CLI checks every byte against the chain before it writes a single file.

That's the whole check: two accounts, one hash, one empty list. The Sarn CLI will run it before it writes a single file to your machine, and every stone page will rerun the hash in your browser. But you'll never need us to run it.

Step 5. Check the number. The stone attribute comes from the collection's mint counter. Sarn's verify_seal instruction checks it in the same transaction that creates and seals the stone. Two people laying at once can't both get No. 418. No gaps, no duplicates.

Step 4. Check the seal. The inscription's metadata account keeps a list of update authorities. On a sealed stone that list is empty. No key is left that can write, resize or close the account. Not the creator's, not anyone's.

Step 3. Hash them. The SHA-256 of those bytes must equal the hash attribute, and their length must equal the bytes attribute. Change one byte anywhere in the bundle and the hash comes out completely different. There's no close enough.

Step 2. Read the inscription. One getAccountInfo call returns the raw bytes. The account must be owned by the Metaplex Inscription program. Any RPC will do. No Sarn server needed.

Step 1. Open the asset. It should sit in the Sarn collection. Its attributes point to everything else: stone, inscription, hash, bytes, skills. They're created with no authority, so nobody can rewrite them. Not the owner, not the collection, not us.

A stone is two accounts on Solana. The inscription: the agent's bundle, byte for byte. The asset: a Metaplex Core NFT, held by whoever owns the stone. It records the stone number, the inscription's address, the bundle's SHA-256 and its size.

Don't trust us. Check the stone. Every agent laid on Sarn will be checkable by anyone, with nothing but a Solana RPC and SHA-256. No Sarn server in the loop. Here's the whole check, step by step