Skip to main content
POST
Returns the unsigned transactions that register a set of rows from List Pending Verifications. They carry what was queued: the kycHash, investor type, expiries and residency claim the platform computed at approval. Your wallets sign and broadcast them, then Confirm Pending Registration records the result. What comes back depends on the register your instance writes to, reported as registerKind. A Trusset register takes one batch. An ERC-3643 register takes up to three phases of signatures, so call again after each until phase is REGISTER.
One row from a blocked country refuses the whole call with COUNTRY_BLOCKED, and the message names its wallet. Leave that id out to build the rest. Dismissing the row also lets the rest build, but a dismissal cannot be undone. A dismissed approval never reaches the register from the queue.On a Trusset register the batch skips some entries without reverting. It skips a wallet that already holds an unrevoked identity, a row whose expiry has passed, and any entry it runs out of gas for. Read what the confirm then does on Confirm Pending Registration before building rows for wallets that were verified before.

​
Body Parameters

​
array
required
1 to 200 row ids. Only rows still PENDING on your instance are used, and any other id is dropped without an error. Compare ids in the response with what you sent.
​
array
ERC-3643 only. The signatures from the SIGN_CLAIMS phase, as [{ walletAddress, signature, claimType }]. Name claimType on each. Without it a signature matches only a wallet with a single claim to sign, and an unmatched signature is no error: the call answers SIGN_CLAIMS again.
​
string
ERC-3643 only. The wallet that will sign the claims. It must hold a CLAIM key on the register’s trusted issuer. Otherwise the call is refused with CLAIM_SIGNER_NOT_TRUSTED, or with CLAIM_SIGNER_MISSING when none of your registered wallets holds one either. It also becomes the management key of every ONCHAINID the plan deploys. Name a wallet registered to your instance, because Confirm ONCHAINID refuses any other management key. Omit it to use the first registered wallet that holds a CLAIM key. A malformed address is ignored.

​
Sign for a Trusset register

The answer is SIGN_TRANSACTIONS with registerKind set to TRUSSET. The first step is one batchVerifyIdentities call for every row. Each row with a residencyClaim adds an addClaim step that files its RESIDENCY slot. Sign every step with a wallet registered to your instance that holds KYC_PROVIDER_ROLE on the register. The build refuses with KYC_PROVIDER_ROLE_MISSING when the register reports that none of your registered wallets holds it. Broadcast the steps in order, and let the batch be mined before the claims. The register refuses a claim for an identity that is not active yet. Confirm with the batch hash as txHash and each claim hash in claimTxResults.

​
Sign for an ERC-3643 register

An ERC-3643 register looks up an identity contract per wallet, the ONCHAINID, and the claims on it. A registration needs the identity, a signed claim and a register entry, so the answer comes in phases. Send the same ids each time, with what the previous phase produced.
1

DEPLOY_IDENTITY

action is SIGN_TRANSACTIONS, returned while any wallet in the batch has no ONCHAINID. Each step is a contract creation that deploys an ONCHAINID with signerAddress as its management key. Broadcast each one from any wallet, record it with Confirm ONCHAINID using the step’s walletAddress and the hash, then call again.
2

SIGN_CLAIMS

action is SIGN_MESSAGES, returned while a claim has no signature. Sign each messageHash as an EIP-191 personal message with a wallet that holds a CLAIM key (purpose 3) on claimIssuer. Call again with the results in claimSignatures. Each one is checked against the trusted issuer before any step is built.
3

REGISTER

action is SIGN_TRANSACTIONS. The steps are one addClaim per claim, then registerIdentity or batchRegisterIdentity for wallets not yet on the register, then updateCountry for registered wallets whose country differs. Broadcast them in order.
Each addClaim step calls the customer’s ONCHAINID, so send it from that identity’s management key. For an identity deployed through this API, that is the managementKey its deployment named, which in this flow is signerAddress. The register and country steps must come from an agent of the register. The build refuses with REGISTRY_AGENT_MISSING when the register reports that none of your registered wallets is one. Confirm with the register step’s hash as txHash and every claim step’s hash in claimTxResults. When every wallet was already registered there is no register step, so send claimTxResults alone. Country steps need no hash. An ERC-3643 register stores no investor type and no expiry, so the row’s investorType, softExpiry and hardExpiry are not written anywhere. The country is written as its ISO 3166-1 numeric code, and a row without one registers with 0. The KYC claim is filed under claimTopic, the first required topic that one of your wallets can sign for. A register that requires further topics does not report the wallet as verified, and its row stays queued at confirm. This endpoint takes no identities field. It finds an ONCHAINID on the register itself, or through Confirm ONCHAINID, which records only a deployment this API planned.

​
Response Fields

​
object
​
array

​
Drive both registers

The example uses one issuer wallet, wallet, as an ethers v5 signer. On an ERC-3643 register it assumes that wallet is an agent of the register and holds a CLAIM key on its trusted issuer. Passing its address as signerAddress makes it the management key of any ONCHAINID it deploys, so it can also send the claim steps. On a Trusset register the first answer has no phase, so the loop is skipped and the steps are broadcast directly.

​
Error Codes