What a standard gives you is an interface other software can rely on. For a restricted asset the question is narrower: where the eligibility check happens, and what the issuer can still do after issuance.
The deepest tooling, the most compliance vendors, and the only permissioned security-token standard that has been formally accepted as an ERC. Everything written here also runs on EVM-compatible chains and layer twos.
The base fungible interface: balances, transfers, allowances. Almost every other fungible standard extends it so that existing tooling keeps working.
None. Restrictions must be added by an extending standard.
One contract, individually identified units, each with its own metadata. Used where the represented thing is unique rather than interchangeable.
—
Several token classes in one contract, each with its own supply and metadata. Maps onto share classes and tranches without deploying a contract per class.
Per-class metadata, but no compliance logic of its own.
An ERC-20-compatible framework for regulated assets built around on-chain identity. Transfers succeed only if both parties satisfy the token's compliance rules. It has the largest real-world deployment of any permissioned security-token standard, a nonprofit governance body, and integration across custodians, venues and compliance vendors.
Identity-driven eligibility via ONCHAINID, modular compliance rules, freeze and forced transfer for court orders and error correction.
The earlier security-token family, organised around partitions that divide a holding into classes with distinct rights. Still a draft and less actively developed than ERC-3643, and more permissive about which identity system you bring.
Partition-level transfer rules; identity left to the implementer.
An ERC-1155-based standard in which each token id is a distinct class, tranche or rights bucket with its own rules and metadata. Introduces dynamic compliance through off-chain vouchers, so a rule can change without redeploying the contract.
Per-partition rules plus off-chain compliance vouchers checked at transfer time.
A standard interface for a vault issuing shares against a deposited asset. Not a compliance standard, but the common shape for yield-bearing and fund-like structures.
—
Built for institutions that cannot put their positions on a public ledger. Each party sees only the part of a transaction that concerns them, which is what makes a shared ledger usable between competitors.
The token standard is governed through the Canton Improvement Proposal process rather than by any single vendor.
The interface defining how on-chain assets are presented and managed across Canton — the counterpart to ERC-20, written for regulated institutions and assets rather than adapted to them.
Issuer-defined rules in Daml, with visibility scoped per party by the ledger model itself.
Improvements to CIP-56 for privacy, performance and traditional accounting, created 31 March 2026 and approved 12 June 2026. Aimed at integration with trading and settlement venues across both traditional and digital finance, and at on-chain securities that model holding and settlement through custody chains. Backward compatible with CIP-56.
Everything in CIP-56, plus a model for custody chains — the intermediated holding pattern securities actually use.
Rights and obligations are modelled explicitly, together with who is entitled to see each part of a transaction. Privacy is a property of the model rather than something added on top.
—
Specialises in the parts of this field that are neither the token nor the money: who — or what — is acting, what they were authorised to do, and whether an automated claim can be checked afterwards. Its standards are published as TDIPs and as the Open Agent Network family.
Relevant wherever an agent rather than a person performs a step, because the question a supervisor asks is not whether the software ran but who it was answerable to.
Version 1.0.0, created 19 March 2026. The core identity standard covering DIDs, identity types, registration, credentials, delegation, wallet integration and trust verification, for three kinds of entity: humans, delegated agents under human control, and autonomous agents.
KYC tiers — Unverified, Basic, Enhanced, Full — expressed as verifiable credentials rather than as a flag on an account.
Syntax is did:tenzro:{human|machine}:[parent-uuid:]{uuid}, giving three concrete forms: a natural person, a machine controlled by a named parent with a delegation scope, and an autonomous machine anchored only by a hardware root of trust. Verification keys are Ed25519 or Secp256k1. Resolution returns a W3C DID Core 1.0 document with verificationMethod, authentication, assertionMethod, keyAgreement and service entries; a revoked identity resolves with deactivated: true.
Delegation carries an explicit scope — spending limits, permitted operations, permitted protocols — and revoking a parent cascades to every descendant in the machine tree.
Three grades, in descending strength: attestable, meaning per-unit secrets such as a TPM 2.0 endorsement key or Apple Secure Enclave; fused, meaning per-unit readable identifiers such as Intel PPIN or Apple ECID; and model, meaning design-level identifiers that are not unit-specific. Only an attestable source may anchor a machine that no human delegated.
The stated principle is that a machine identity must be answerable to something other than itself — either a human who remains accountable, or hardware standing in their place.
The agentic-web standards family stewarded by the Tenzro Foundation. Conformance requires AgentCards published at /.well-known/tn/agent-card.json with JCS-canonicalised signatures (RFC 8785), MeshNodeCards per TNIP-003, and ValidationRecords emitted as OAN-shaped JSON per TNIP-005.
An agent's capabilities and its signature are published at a well-known location, so a counterparty can check what it claims to be before dealing with it.
The conformance document names ERC-8004 for identity on EVM networks, R8004 for soulbound identity on Solana Token-2022, x402 for micropayments, UCAN for delegated authority, and Daml via Canton for private settlement. A separate reference implementation covers ERC-7683 cross-chain intents.
Identity and delegation are expressed in each network's own idiom rather than requiring counterparties to adopt a single one.
High throughput and low fees, with compliance behaviour available as configuration on the token itself rather than as a bespoke contract.
The original token program: mints, token accounts, transfers. Lightweight and ubiquitous across Solana tooling.
Freeze authority only.
A modular successor in which behaviour is added by extensions appended to the mint or account, rather than by writing a contract. The practical route for regulated assets on Solana.
Transfer hooks, confidential transfers, permanent delegate, default account state, transfer fees, metadata — composed per asset.
Lets a mint execute custom instruction logic on each transfer — for example, permitting only allowlisted holders. This is where an eligibility check lives on Solana.
Arbitrary issuer logic evaluated at transfer time.
Encrypts transfer amounts so they are visible only to sender, recipient and an optional auditor. Note that it cannot be combined with Transfer Hook: hooks need to read the amount, and confidential transfers hide it.
Auditor key preserves supervisory visibility.
Compliance controls are protocol features rather than contract code, so an issuer gets them without deploying or auditing anything.
A compact fungible token object carrying on-chain metadata, introduced because trust lines do not scale as issuance grows. Enabled by the MPTokensV1 amendment, which activated in October 2025. Metadata is immutable once created, and supply can be capped.
Allow-listing, transfer limits, locking and clawback, all at the protocol level.
The original model, in which a holder opens an explicit trust line to an issuer. Still in wide use for stablecoins; the per-line ledger cost is what MPTs were designed to avoid.
Authorised trust lines, freeze, clawback.
A proposal extending Multi-Purpose Tokens with confidential amounts, bringing XRPL closer to the privacy properties institutions ask for.
—
Built around payments and cross-border corridors, with issued assets and anchors as first-class concepts.
Assets issued natively by an account, with holders establishing trustlines. Long used for fiat-backed tokens and remittance corridors.
Authorisation flags, freeze, clawback.
The standard interface for contract tokens on Soroban, similar in shape to ERC-20, giving broad tooling compatibility.
—
A built-in contract that exposes a classic issued asset through the SEP-41 interface, so the same asset is usable from smart contracts without reissuing it.
—
Networks with meaningful institutional tokenization activity where the asset model is native rather than contract-defined.
Tokens as a native network service rather than user-deployed contracts, with configurable keys for supply, freeze, KYC and wipe. Used for tokenized money market fund share classes.
KYC flag, freeze, wipe and pause keys set at creation.
Native assets configured at creation rather than programmed, with opt-in required before an account can hold one.
Freeze and clawback addresses, mandatory opt-in.
A unified interface covering fungible, non-fungible and multi-asset contracts, with transfer permissions expressed through a permissioning policy.
Pluggable transfer permission policies.
Assets are first-class objects owned by accounts, with the type system enforcing that they cannot be copied or implicitly discarded.
—
Issuing assets anchored to Bitcoin transactions, with most data kept off-chain and proven on demand. Early relative to the others, and the settlement assurance is Bitcoin's.
—