Skip to main content
POST
Files claims from a bundle and, unlike Add Claims from Proof, can rotate the identity’s on-chain root to this bundle’s root in the same flow. Use it when re-proving a subject against a new batch, where the root on the registry is the old one. It also records a ledger row per confirmed claim, so List Proofs can later say which proof backs which slot.
The registry keeps one claim per slot. Filing a slot replaces the claim already there, whoever wrote it.A root rotation rewrites the identity record, not only its root. Root rotation lists what it keeps and what it resets.
This endpoint, Inspect Manifest and Add Claims from Proof share one rate limit per instance: 30 requests in a 60-second window, both legs counted. Past it, they answer 429 RATE_LIMITED with a Retry-After header in seconds.

​
Body Parameters

​
string
required
The subject. Must already be verified on chain and not revoked.
​
object
required
The bundle’s manifest.json, parsed. At most 64 KiB serialized and 32 leaves.
​
string
The 64 raw bytes of manifest.sig, base64-encoded. Required whenever an operator key is registered, as on Add Claims from Proof.
​
object
A map of field name to base64 STARK bytes. Under enforcement, verification needs one for every leaf you file. The size caps are those of Add Claims from Proof.
​
array
required
Which leaves to file and where, 1 to 8 entries. Each names a fieldName from the manifest, optionally a claimType slot by name, and optionally expiryDays for that claim alone.A canonical field always files under its own slot. country files as RESIDENCY, nationality as CITIZENSHIP and investorType as ACCREDITATION, and naming another slot is refused with SLOT_LOCKED. A leaf with no canonical meaning has no default slot, so it needs an entry naming one of AML, TAX_RESIDENCY, SANCTIONS_CHECK or PEP_CHECK.expiryDays runs from 0 to 36500, where 0 means no expiry. Omitted, the claim inherits the identity’s hard expiry when that is in the future, and the rotated one when the root rotates.
​
string
The hash of the mined transaction that registered this bundle’s root on the identity. Required on the confirm leg when the bundle’s root differs from what the registry holds.
​
array
Send this to confirm. An array of { fieldName, txHash }, one per claim you broadcast.
​
array
ERC-3643 register only. One { claimType, signature } per message from a SIGN_MESSAGES answer, with claimType by name. walletAddress is optional and defaults to the subject.
​
string
ERC-3643 register only. The instance wallet that signs the claims. It must hold a CLAIM key on the register’s trusted issuer.

​
Root rotation

The registry holds one root per identity. A bundle proved in a later batch has a different root, and its leaves cannot be checked against the old one. When the bundle’s root differs from the chain’s, the calldata leg returns the root-rotation transaction as the first step and the claim transactions after it. Broadcast the rotation first, then pass its hash back as rootTxHash alongside txResults. On the Trusset register the rotation is updateIdentity, which rewrites the whole identity record:
  • The investor type stays as it is, or comes from the bundle’s passthrough.investorType when the record has none, and defaults to RETAIL.
  • The expiries become the bundle’s softExpiryDays and hardExpiryDays counted from now. Where the bundle states none, the current expiry is kept.
  • The signing wallet becomes the identity’s KYC provider.
An identity whose kept expiry has already passed is refused with IDENTITY_EXPIRED and must be re-verified instead. A bundle whose soft expiry is not earlier than its hard expiry is refused with INVALID_EXPIRY. Confirming without rootTxHash is refused with ROOT_ROTATION_REQUIRED. The rotation receipt must be a mined updateIdentity or verifyIdentity on this instance’s register. It must target this wallet (TX_TARGET_MISMATCH) and register this bundle’s root (TX_ROOT_MISMATCH). A rotation signed by a wallet outside your instance is logged but not refused. Once it is confirmed, the customer record takes the new root.

​
Sign and confirm

Before handing out calldata, the API checks that one of your instance’s registered wallets holds KYC_PROVIDER_ROLE on the register, which addClaim and updateIdentity both require. It refuses with KYC_PROVIDER_ROLE_MISSING otherwise, and skips the check when the instance has no registered wallet or the role cannot be read. The confirm leg verifies the bundle again, then each claim receipt independently. A receipt must be a mined, successful addClaim on this instance’s register for this wallet, writing the slot and data hash the server derived. It does not check who signed. A claim whose hash you omit comes back skipped, and one that fails a check comes back failed with a reason. Only a confirmed claim writes its ledger row and an ADD_CLAIM audit entry.
success is false with NO_PROOFS_ADDED when the confirm leg files nothing, on a 200. Read added against total.

​
On an ERC-3643 register

When the instance is bound to an ERC-3643 register, each claim is written to the subject’s ONCHAINID. It carries a signature from a CLAIM key on the register’s trusted issuer, so the first call answers SIGN_MESSAGES. Sign each messageHash as an EIP-191 personal message and call again with claimSignatures to receive the transactions. The rotation step is then a new KYC claim on the ONCHAINID carrying the bundle root, and it writes no investor type or expiry. Claims carry no expiry either. The role check becomes an agent check on the register, and IDENTITY_REVOKED also covers any identity the register does not count as verified. The ERC-3643 codes on Add Claims from Proof apply here too.

​
Response Fields

​
object

​
Error Codes

Every verification failure from Add Claims from Proof applies here too, stored verdicts included, except HASH_MISMATCH and NO_SELECTED_CLAIMS. A root that differs from the chain’s leads to a rotation instead. On top of those: