Read your receipt on Sui

What you will have at the end

The object id of the receipt Permafrost minted for something you stored, open in a Sui explorer, with its fields in front of you — read from the chain rather than from us.

You will also have a clear line between what that receipt asserts and what it does not, because the two are easy to blur and the difference is the whole argument for having it.

Prerequisites

• Something you stored, and its bytes — or its sha256. Store, read back, and know when it is certified is the short path to both.
• curl, and a Sui explorer in a browser. You do not need a wallet, an account, or a fullnode of your own.
• The instance up, for the lookup step only — see below.

1. Find the receipt id

The keyless verify route is how you get it. Ask it with the sha256 of the bytes you stored:

curl -sS 'https://testnet.permafrost.live/v1/api/verify?hash=<sha256>'

A provenance: true answer carries nft_id — the receipt object — and explorer_url, which is that id on a Sui explorer. That is the field you came for. Verify a file by hash, with no account covers the rest of the response and the cases where it answers false.

The tenant-scoped object-metadata reads are a different question and do not carry the receipt id:

curl -sS -H "Authorization: Bearer $PF_SK" \
  https://testnet.permafrost.live/v1/api/meta/objects

That lists your own rows, and each one answers with id, state, blob_id, walrus_epoch, synced_at, created_at, size_bytes and content_type — where an object stands, not what was minted for it. /v1/api/meta/objects/<id> answers the same eight fields for one row, 404 for a row that is not yours. Use verify for the receipt.

2. Open it

Paste nft_id into a Sui explorer, or follow explorer_url straight from the answer. The receipt is an ordinary Sui object; any explorer, any fullnode, any SDK that can read an object can read it.

3. Read what it holds

A receipt for a single stored object carries these fields:

Field	What it is
manifest_blob_id	the manifest this receipt points at, holding the file index
root_hash	the content fingerprint — what the receipt anchors
file_count	how many files the manifest indexes
total_bytes	their size
encrypted	whether the recorded bytes were encrypted
previous_id	the prior receipt this one descends from, when there is one
owner	the address holding this receipt object
created_at	the epoch it was minted in

Two of those repay a second look.

previous_id is the lineage. It links a receipt to the one before it, so a re-upload does not orphan its history — the chain is walkable from the current receipt backwards, on chain, by anybody.

owner is the address that holds the object, and on this instance that is ours, not yours. The mint for an ordinary upload is signed by the instance’s own key, so the receipt lands in the instance’s address rather than your tenant address. Do not read owner as “the party who stored this”. What ties the receipt to content is the fingerprint, which is the next section.

A receipt for a multipart object is a different shape — it records the parts count and the whole-file fingerprint, and it carries no lineage link. On-chain objects has both side by side.

What “resolves without us” means

The receipt is state on Sui. It is there whether or not this instance is running, whether or not you still have a credential, and whether or not you ever talk to us again. Reading it needs a Sui fullnode — not this host, not a key, not a support ticket. That is the property, and it is the reason the receipt exists separately from the storage.

What it asserts: this content, fingerprinted this way, was recorded at this epoch, under this lineage.

What it does not assert: that the bytes are still retrievable. Storage on Walrus is leased, and a receipt on Sui outliving a lease is exactly the case the separation is designed for. A storage receipt is not a provenance receipt is that argument in full, and Leases, renewal, and nothing expiring silently is what the instance does about the lease while it is running.

How you know it worked

The explorer resolves the id and shows you the fields above, with no credential anywhere in the request. Open the same id from a different machine, with nothing of ours configured on it: same object, same fields.

What to read next

• On-chain objects — every object type this instance mints, field by field.
• What survives Permafrost, and what does not — the receipt is the map; this is what you can do with it.