Skip to main content
POST
Verifies a proof bundle against the subject’s on-chain root, derives the claims it backs, and returns the registry calldata for each one. This is the only way the four canonical claim slots are filled. The subject must already be verified on chain, because the bundle is checked against the kycHash the registry holds. Verify first with Verify Identity.
Two different roots are checked, and they fail with different codes.The root recomputed from the leaves must equal the root the manifest states, or the bundle is internally inconsistent and is refused with ROOT_MISMATCH. That root must then equal the root the registry holds for this wallet, or the bundle belongs to a different batch than the one registered and is refused with HASH_MISMATCH.Neither is negotiable here. To file claims from a newer bundle, rotate the registered root with Attest Proofs, which is the endpoint that allows it.

Body Parameters

string
required
The subject. Must already carry a non-zero kycHash on the registry.
object
required
The bundle’s manifest.json, parsed.
string
The bundle’s manifest.sig. Required whenever proof verification is enforced, which Get Operator Key reports as proofVerificationEnforced.
object
A map of field name to base64 STARK bytes, read from proofs/*.bin. Required under enforcement for every leaf you want filed. Each proof and the payload as a whole are size-capped.
array
Claim types to file, as names or indices. Omit it to file every claim the bundle backs. A selection that matches nothing the bundle proves is refused with NO_SELECTED_CLAIMS.
integer
Days until the claims expire, between 0 and 36500. Omit it and the identity’s own hard expiry is used, if it is still in the future. 0 means no expiry.
array
Send this to confirm. An array of { claimType, txHash }, one per claim you broadcast. Omit it to receive the calldata.

The two calls

Without txResults the response is SIGN_TRANSACTIONS with one step per derived claim, each carrying its claimType, dataHash and expiry. Broadcast them from a wallet that holds the registry role, then call again with the hashes. The confirm leg verifies each receipt independently. It checks that the transaction targets this wallet, and that the claim type and data hash mined actually match the claim derived from the proof. A step whose hash you omit comes back skipped; one whose receipt does not match comes back failed with a reason; neither stops the others.
success is false when no claim was confirmed, with NO_CLAIMS_ADDED, even though the HTTP status is 200. Read added against total.

Response Fields

object

Verification failures

Every code below means the bundle was rejected and nothing was written. They are stored on a verification report, so the same bundle asks the same question once and gets the same answer.

Other errors