Verify & attest.

Code notes

Storage verification reports whether a receipt has an attested Merkle root and whether the stored file set currently verifies. Be precise about what a routine green attestation proves: it is a presence-and-consistency proof, meaning the manifest entries exist in storage and their recorded content hashes form the Ed25519-signed Merkle root. It does not re-hash the stored bytes. The stricter byte-level check is GET /v1/storage/recompute-verify, which re-downloads every file and re-hashes it; that endpoint requires a payer-signed envelope with locker:read and is strictly read-only (in PyNukez, client.recompute_verify signs it for you). On confirmed lockers the gateway runs an attestation automatically after every successful file confirm via the managed background queue — by the time you fetch the verification bundle for a freshly-confirmed locker, content_proof and on_chain_anchor are already populated. The explicit POST /v1/storage/attest endpoint (signed envelope, op locker:attest) exists for two cases only: forcing a fresh anchor right now, and clients that want a synchronous-style result instead of polling verify. Before any files are uploaded, verified and attested are false with no Merkle root — this is the steady-state for empty lockers, not a failure.

1. 1Create the clientThe SDK wrapper gives the same verification result shape as the gateway endpoint.
2. 2Verify the receiptPre-attestation responses can be false/empty; post-attestation responses include the Merkle root.
3. 3Use the gateway directlyThe public HTTP verify endpoint accepts receipt_id and does not require a signed envelope.

Code notes

Attestation builds the file-set Merkle root and anchors the result. The anchor object in the response names the kind of anchor. Current anchors have the type solana_sas_v1 or solana_memo_v2: the gateway signs a version-two evidence envelope, and then publishes an SPL Memo that carries the Merkle root and the statement digest in a transaction signed by the gateway's published key. The solana_sas_v1 type also writes a Solana Attestation Service account for the receipt. Historical anchors have the type switchboard_v2, and they keep their original Switchboard feed and memo. Read the transaction from anchor.tx first, and fall back to switchboard_tx only when the response has no anchor object. With sync=True the request stays open, but the gateway no longer performs the on-chain push inside the request: it enqueues the job through the same managed queue path the async mode uses and then polls the persisted attestation server-side until it reaches a terminal state. If the poll ceiling (90 seconds by default) expires while the job is still in flight, the call returns a 202-style response that points at /v1/storage/verify for continued polling. The status field moves through pending, computed, pushing, and complete; a truthy merkle_root is the completion signal pollers should key on.

1. 1Run attestationsync=True enqueues the attestation and waits by polling the persisted record server-side; the response is terminal when merkle_root is present.
2. 2Record the anchorThe important outputs are status, push_ok, merkle_root, tx_signature, and the anchor slot. The SDK field switchboard_slot keeps its historical name, and it holds the slot of the anchor transaction for every anchor type.
3. 3Poll raw HTTP when neededThe gateway exposes attest and attest-code endpoints for direct integrations.

Code notes

Merkle proof verification is the core independent check: recompute the leaf from filename, size, and content hash, walk the proof path in order, and compare the final hash to the attested Merkle root.

1. 1Fetch the proofThe proof document is scoped to one receipt id and filename.
2. 2Recompute the leafThe leaf formula is SHA256('{filename}:{size_bytes}:{content_hash}').
3. 3Walk the proofConcatenate current and sibling according to each step's left/right position.
4. 4Compare rootThe final computed hash must match the attested Merkle root.

Code notes

Receipt-hash verification is separate from storage verification. It checks whether the stored receipt hash matches the receipt object as recomputed by the gateway/client.

1. 1Verify receipt hashThe SDK method compares the stored and recomputed receipt hashes.
2. 2Use direct endpointsThe gateway exposes receipt fetch and receipt verify endpoints for HTTP clients.

Code notes

The verification bundle is the high-level package for independent verification. It includes the receipt, content proof, Merkle algorithm details, and a verify-yourself checklist so another system can recompute the result without trusting the UI.

1. 1Fetch bundleThe bundle is a public gateway endpoint keyed by receipt id.
2. 2Inspect proof fieldsThe important fields are the Merkle root, algorithm, recomputation steps, and public verify URL.

Code notes

The evidence bundle is the portable proof for the anchors that the gateway publishes itself. The endpoint is public and needs no authentication. The bundle holds the file list, the commitment, the signed version-two envelope, the anchor object, the separate verification facts, and the gateway's signing keys. Records that were anchored in the Switchboard era are exported in the same document with bundle_version 1, their original signature, and their original meaning. The nukez-verify command checks a saved bundle and reports each fact separately as passed, failed, not_checked, or unavailable. It never folds the facts into one verified flag. The anchor proves that the gateway's published key committed this exact snapshot on Solana at this slot, and, with the attestation account, that the current commitment is readable on-chain at a predictable address. It does not prove that a third party inspected the files.

1. 1Save the bundleThe bundle is designed to be saved and checked later without asking the gateway anything else.
2. 2Pin the signing keyA key list served by the same gateway that produced the bundle proves self-consistency only, so record the key once from a source you trust.
3. 3Check the factsThe offline facts need only the saved bundle. The online facts read the anchor transaction, and the attestation account when there is one, from the RPC endpoint you choose.