Deploy assets. Wire claims. Prove holders.
A technical tutorial shelf for the token and identity operations that sit underneath compliant issuance: deploying tokens, deploying obligation classes, adding claim requirements, trusting issuers, issuing claims, adding claims, and revoking them.
deploy_token creates token_address, identity_registry_address, asset_id, and token_id.
add_token_claim_topic tells the IR which claim topics holders must present.
add_token_trusted_issuer authorizes ClaimIssuer contracts for those topics.
register_identity maps the recipient account into the token Identity Registry.
Tutorial index
Each card is a tutorial scaffold: purpose, endpoint, inputs, outputs, and the thing most likely to bite.
Deploy a compliant token
Create an ERC-3643 compliant token, its Identity Registry, compliance module wiring, and the asset registry record downstream steps will reference.
Deploy an obligation class
Create a new ConfidentialObligation class proxy for notes, invoices, deal contracts, or other obligation NFTs that need their own mint and transfer policy.
Add a claim requirement
Tell a token or class Identity Registry which proof a holder must carry before mint or transfer is allowed.
Add a trusted claim issuer
Authorize a ClaimIssuer contract to sign specific claim topics for a token or class Identity Registry.
Issue a claim
Have an issuer sign a compliance claim for a target entity. The issued claim starts as pending until the target accepts or it is added on-chain.
Add or accept a claim on-chain
Write a signed claim onto an ONCHAINID identity, either directly with add_claim or by accepting a pending issued claim.
Revoke a claim
Remove an issued claim from the target identity and mark the issued_claim row revoked, preserving the audit trail.
A verified holder needs two things.
deploy_token creates token_address, identity_registry_address, asset_id, and token_id.
add_token_claim_topic tells the IR which claim topics holders must present.
add_token_trusted_issuer authorizes ClaimIssuer contracts for those topics.
register_identity maps the recipient account into the token Identity Registry.
issue_claim signs the recipient proof and returns issued_claim_id.
accept_claim or add_claim writes the signed proof onto the target identity.
Only now does the ERC-3643 isVerified gate have both pieces: registration and valid claim.
Use friendly names in the authoring layer.
The bridge translates these names to numeric ONCHAINID topic ids at dispatch time.
`issue_claim` creates the proof. `register_identity` puts the target account inside the token or class Identity Registry. ERC-3643 verification needs both.
Deploy a compliant token
Create an ERC-3643 compliant token, its Identity Registry, compliance module wiring, and the asset registry record downstream steps will reference.
POST /api/asset_register/deploy_workflowChoose the token name, symbol, and decimals.
Leave factory, compliance, and identity registry blank unless the chain needs explicit overrides.
Capture identity_registry_address and token_id for claim requirement and trusted issuer steps.
Watch: The token contract address is not the Identity Registry address. Claim requirements are configured on the IR.
Deploy an obligation class
Create a new ConfidentialObligation class proxy for notes, invoices, deal contracts, or other obligation NFTs that need their own mint and transfer policy.
POST /api/asset_register/deploy_obligation_workflowSet name and symbol for the ERC-721 obligation class.
Decide whether the class is open-minting or owner-only, transferable or soul-bound.
Bind downstream createObligation steps to obligation_address so mints land in the new class.
Watch: A class can have its own Identity Registry. Do not assume a freshly deployed class uses the same IR as a token.
Add a claim requirement
Tell a token or class Identity Registry which proof a holder must carry before mint or transfer is allowed.
POST /asset_register/update_claim_requirementsPick the compliance topic: kyc, kyb, aml, accredited_investor, retail, or wholesale.
Bind identity_registry_address from deploy_token, or bind token_id and let the derived input resolve the IR.
Add the topic once per token or class.
Watch: Adding the same claim topic twice is not idempotent and can revert on-chain.
Add a trusted claim issuer
Authorize a ClaimIssuer contract to sign specific claim topics for a token or class Identity Registry.
POST /asset_register/update_claim_requirementsUse the ClaimIssuer contract address, not an ordinary wallet address.
Choose the topics that issuer may sign.
Pair this with issue_claim so recipients can actually satisfy the registry requirement.
Watch: This step is idempotent: re-adding the same issuer/topics pair is safe.
Issue a claim
Have an issuer sign a compliance claim for a target entity. The issued claim starts as pending until the target accepts or it is added on-chain.
POST /claims_management/issue_claimResolve the target entity to its default account on the chosen chain.
Sign the claim against the target ONCHAINID identity.
Store issued_claim_id so accept, decline, re-issue, or revoke can reference the same signed claim.
Watch: Issuing a claim does not register the recipient in a token IR. register_identity is still required for new per-token IRs.
Add or accept a claim on-chain
Write a signed claim onto an ONCHAINID identity, either directly with add_claim or by accepting a pending issued claim.
POST /claims_management/add_claimUse account_address=self when the current identity receives the claim, or pass the target account address.
Prefer claim_type for the standard six claim families; use raw topic/scheme/signature/data for advanced ONCHAINID payloads.
For issued claims, call accept_claim with issued_claim_id so the pending row becomes an on-chain claim.
Watch: add_claim uses the selected vault wallet as issuer. Thread wallet_id when the issuer is not the JWT default wallet.
Revoke a claim
Remove an issued claim from the target identity and mark the issued_claim row revoked, preserving the audit trail.
POST /claims_management/revoke_claimLoad the issued_claim row by id.
Verify the caller is the original issuer.
Submit the on-chain revoke/remove message, then mark revoked_at on success.
Watch: Only the original issuer can revoke. Re-issue uses clear_revoked_signature against the same issued claim.
The distinctions the tutorial should repeat.
Transfers and balances use token_address. Claim topics and trusted issuers use identity_registry_address.
issue_claim signs proof onto an ONCHAINID. register_identity adds the holder account to a specific token IR.
Trusted issuer inputs expect the ClaimIssuer contract address. A normal wallet address is the wrong object.
add_token_claim_topic is not idempotent. add_token_trusted_issuer is safe to rerun with the same issuer/topics.