Digital Assets Standards Lab
An institutional digital asset is not a token interface.
It is a governed implementation profile, composing legal rights, product semantics, lifecycle state, market messages, execution controls, identity, settlement, custody, operations and evidence. The majority of failures in this field arise where a standard is relied upon for a purpose it was not written to serve.
The Lab catalogues those standards and records four properties of each one separately: the force it carries, how settled it is, which layer it addresses, and when in the life of an instrument it applies. No overall score is published, since the four are not commensurable.
The method
Four truths, kept apart on purpose.
Every project must rank its sources of truth for instrument terms, holder position, token supply, custody, cash, trade, settlement, NAV, corporate actions and reporting. Two records marked authoritative without a precedence rule between them is not a detail to settle later; it is the design defect that surfaces as a reconciliation break nobody can adjudicate.
Legal truth
Law, governing documents, the register, CSD, transfer agent or custodian, and the rules that decide when title actually moves.
Economic and process truth
Terms, calculations, events and state models. What the instrument promises and how that unfolds over its life.
Operational message truth
The instructions, statuses, confirmations and reports institutions exchange. A message is a message, and never a settlement.
Ledger and custody evidence
Token state, ordering and finality, account and key control, position and reconciliation. What the chain can actually prove.
Classification
Four axes that must never be added together.
Authority is not maturity. A law can be binding and technically non-specific; an implementation can be mature and carry no legal force at all. Collapse them into one number and a widely-adopted token interface outranks a regulation.
Authority, what force it carries
| Class | Name | Force | Typical use |
|---|---|---|---|
| A | Law or binding rule | Binding in scope | constraint and jurisdictional overlay |
| B | Regulatory or supervisory guidance | Interpretive or supervisory | control interpretation and evidence |
| C | International principle or recommendation | Policy or oversight benchmark | outcomes, risk and control baseline |
| D | Accredited technical standard | Normative within the issuing process | identifiers, messages, data, credentials |
| E | Industry domain standard or model | Voluntary market convention | terms, lifecycle, workflows and market practice |
| F | Protocol specification or contract framework | Normative only within its ecosystem | interfaces and execution semantics |
| G | Reference architecture, toolkit or pilot | Non-binding design evidence | design patterns, controls and experiments |
| H | Product or vendor implementation pattern | Implementation-specific | feasibility and integration profile |
| I | Open-source reference implementation | Code and tests, not legal approval | accelerator and conformance evidence |
Maturity, how settled it is
- M1
Published and stable
Current normative or released artifact; still requires implementation due diligence
- M2
Published and evolving
Current artifact with active change cadence or version-sensitive profiles
- M3
Draft or review
Prototype or monitored candidate; not a production conformance baseline by default
Needs a recorded exception to be a production baseline
- M4
Pilot or experimental
Evidence and learning only unless separately adopted
Needs a recorded exception to be a production baseline
- M5
Legacy, dormant or withdrawn
Historical vocabulary or migration input, not a new default
Needs a recorded exception to be a production baseline
- M6
Local profile required
Standard is incomplete without a jurisdiction, network, venue or institution profile
3 of the 6 classes cannot be a production default on their own. Choosing one is allowed; choosing one silently is not.
Layers, which question it answers
- L0
Legal and economic claim
What right, liability or beneficial interest exists, under which law, and which record controls?
- L1
Product taxonomy and identifiers
What is the instrument, token, party, venue, transaction and network?
- L2
Terms, contract and data semantics
Which terms, legal agreements, code lists and data definitions are canonical?
- L3
Lifecycle event and process model
What events, state transitions, calculations and exceptions exist?
- L4
Messaging and workflow
How are instructions, status, confirmations and reports exchanged?
- L5
Token representation and contract interfaces
How are balances, positions, partitions, vaults and privileges expressed?
- L6
Identity, eligibility and compliance
Who may act or hold, based on which revocable evidence and policy?
- L7
Ledger, network and execution
Where does code execute, how is finality reached, and what is authoritative?
- L8
Cash leg and settlement
How do cash and asset obligations discharge, atomically or conditionally?
- L9
Custody, accounts and key control
Who controls keys and assets, with what segregation, recovery and authority?
- L10
Interoperability, bridges and oracles
How do networks, data sources and legacy systems connect without inventing equivalence?
- L11
Security, resilience and privacy
What threats, confidentiality, continuity and recovery properties are required?
- L12
Governance, operations and reporting
Who may change, pause, correct, upgrade and report, under which approvals?
- L13
Evidence, audit and verifiability
What proves design intent, implementation conformance and runtime operation?
Phases, when it applies
- P0
Design time
legal classification, authority-of-record map, product archetype, standards shortlist
- P1
Build time
schemas, interfaces, mappings, adapters, rules, invariants and test plans
- P2
Issuance and deployment
identifiers, contracts, roles, registries, modules, documents and configuration manifest
- P3
Runtime preflight
signature, identity, eligibility, freeze, balance, NAV, oracle and route checks
- P4
Atomic execution
state transition, transfer, mint, burn, lock, settlement or message dispatch
- P5
Lifecycle servicing
calculations, corporate actions, payments, queues, elections and reconciliation
- P6
Operations and reporting
monitoring, statements, regulatory reports, evidence and incident response
- P7
Change, migration and exit
revocation, correction, upgrade, identifier continuity, migration, retirement and data export
Anti-overclaim
Six sentences this Lab will not let you write.
Each one is a category error between two of the four truths, and each has cost a programme real money. A conformance claim here is always a tuple, never a badge: the artifact, its exact version and status, the implementation profile, the scope, the network or jurisdiction, and the date the evidence was checked.
“ISO 20022 compliant blockchain”
Conformance is to an exact message version, a usage profile and a workflow. There is nothing for a chain to be compliant with.
“The taxonomy is the bond”
A data taxonomy carries terms. The legal issuance documents prevail, and they are not executable.
“The ISIN is the token address”
An ISIN identifies the instrument. A contract address identifies a deployment. Conflating them breaks both registries.
“The LEI proves KYC”
An LEI identifies a legal entity. It carries no eligibility, no suitability and no customer due diligence.
“The pilot is approved”
A pilot, sandbox, toolkit, white paper or no-action letter is none of regulatory approval, certification, or a production baseline.
“The audit covers it”
An audit applies only to its release, configuration, scope and date. Change any of the four and it no longer speaks.
Member workspace
Then compose one, against the catalogue, and see what breaks.
Reading the classification tells you what exists. It does not tell you whether the thing you are building holds together. That is a private workspace: your organisation, your architectures, your evidence, visible to the people you invite.
- 01
Start from a product
One of thirteen archetypes, from a native digital bond to a wholesale settlement rail. The archetype decides which rules apply, so it is chosen first.
- 02
Compose and decide
Pick the standards stack, rank which record controls for each thing the design must agree about, and answer the decisions the rules ask about. Unknown is a valid answer.
- 03
Read the findings
Deterministic rule results, each naming the inputs that produced it and the sources behind it. Nothing blocks quietly: what stops approval is listed, with what would settle it.
- 04
Approve and export
Freeze an immutable Architecture Passport with its catalogue and rule-set snapshot, then export it as JSON, YAML, Markdown or CSV carrying the approval checksum.
Seats carry roles. A contributor can build and freeze; a reviewer can sign off but not edit, because an approver who can fix a figure is a second author; and nobody can approve their own work, whatever their role, including the owner.
An approved architecture can be sent to IEI for implementation support. That is a request for triage: it is not an acceptance, a scope, a price or a date, and nothing in the workspace will tell you otherwise.
IEI staff can read member architectures in order to run the platform, and every such read is recorded against the person who made it.
What this is, and what it is not.
This is an independent research, architecture and implementation-planning instrument. It is not legal, regulatory, accounting, tax, investment, security-audit or production-readiness advice.
Standards status is reported as observed at the research cutoff and must be revalidated before use. Every record carries the date it was last checked and a note on its licence and access terms, because several of these documents are copyrighted and cannot be redistributed. The Lab links to and describes primary sources; it does not reproduce their normative text.
Coverage is exhaustive by method and cutoff, not by assertion. Where no adequate standard exists, the catalogue says so: there is no universally mature cross-ledger regulated delivery-versus-payment standard, no complete corporate-action contract standard, and no automatic route from a legal document to code. The gaps are part of the result.