After Issuance: One Identity, Every Venue

The identity problem appears when the asset can move but the holder cannot be recognised.

A tokenized security can be issued lawfully, held in a wallet and transferred under rules the token enforces itself. The token always knows who holds it. What it does not recognise is a wallet at a venue, custodian or application that has never been through the same identity system, and a transfer to a wallet it cannot recognise is refused.

In August we put a figure on the result. Roughly $38 billion in real-world assets sat distributed on public blockchains. Roughly $345 billion sat represented, recorded on a ledger but unable to leave the platform that issued it.

The gap is usually explained as regulatory. It is not. Every asset in the represented column was issued lawfully by an institution that cleared its jurisdiction. They are not stuck because a rule forbids the movement. They are stuck because the market cannot recognise the holder outside the environment that verified them.

That is the identity problem.

A Register Is Read, Not Presented

Onchain identity has been a register of verified claims.

It holds signed claims about a holder, issued by parties trusted to issue them: that a jurisdiction, an investor category or a screening has been verified, and until when. The underlying personal data stays off-chain. Compliance rules on the asset read that register before a transfer and decide whether the transfer is permitted. ERC-3643 formalised this model, and more than $32 billion has been tokenized against the standard.

The model works. Transfers that should not happen do not happen.

But a register is read by someone. It cannot present itself, act, or be a counterparty. The asset evaluates the holder. What falls to the venue is the connection work, and a venue can only connect to identity systems it has already integrated.

That sets a ceiling. An asset can travel as far as its identity layer has been integrated, and no further.

Decentralised finance never met this ceiling because it never had to ask who anyone was. A balance is a balance, so any contract can hold a token and any protocol can be a counterparty to any other. Securities have to ask. An equity is a claim against an issuer held by a person with attributes, and removing those attributes removes the instrument.

What the Identity Layer Decides

A securities market needs a reliable answer to one question before a transfer: is this holder permitted to hold this asset.

That answer decides more than a balance. It determines whether a transfer can proceed, which restrictions apply, what happens when a holder becomes ineligible and how a lost key is resolved.

Every environment an asset reaches needs the same answers. Is the holder verified? By whom? Is the verification current? Is this transfer allowed?

If every platform answers from its own copy of the investor, tokenization adds a layer of duplication. Every platform that builds its own identity checks adds an integration for every other platform to build. The cost of connecting the market grows with the number of pairs, and that produces closed environments whether or not anyone intended them.

Making the Identity an Account

ONCHAINID v3, built with and audited by OpenZeppelin, changes what the identity is rather than what it holds.

The claim model is unchanged: signed claims from trusted issuers, read by the asset's rules. The identity now also has the capabilities of a modular smart account, built on ERC-7579 with ERC-4337 account abstraction. It can hold the asset it was verified to hold, sign transactions and manage its own recovery. Keys, claims and execution are installable modules rather than one fixed contract.

Three consequences matter to institutions.

Signature formats. ERC-7913 allows an identity to be controlled by secp256r1, RSA or WebAuthn credentials alongside standard ECDSA. These are credential formats institutions already issue and already hold documented controls for.

Recovery. Guardian and threshold mechanics become a module the identity carries, rather than an issuer manually re-linking a holder to a new wallet.

Persistence. One identity across networks, to which the holder links their own wallets, verified once rather than re-established on each.

Until now an onchain identity was a record that someone else had to read. With ONCHAINID v3 it becomes an account: it holds the asset, signs with the keys institutions already use, and is recognised by the asset's rules wherever the asset goes. We designed and built it side by side with the OpenZeppelin team, and their work on the architecture and the audit raised the bar on every part of it. This is the next generation of decentralised identity, and I believe it will be transformational for how regulated assets move onchain.

Joachim Lebrun, Co-founder and CTO of T-REX Network

Recognition Moves From the Venue to the Holder

Under the register model, the rules are enforced by the asset, but recognition is the venue's job. The venue integrates the identity system and gets each holder and each wallet registered, asset by asset. The venue is a specific, non-interchangeable participant in every transaction, and its integration work is what makes the asset tradeable.

Under the account model, the holder arrives carrying what the rules need. Eligibility is still determined by the issuer and the jurisdiction, and the compliance rules still sit on the asset. What changes is where the burden of recognising the holder sits.

When that burden moves to the identity, venues become interchangeable.

Interchangeable venues are the condition a secondary market requires. Liquidity is not a property of any one venue. It is what happens when the same instrument can be bought and sold in more than one place by participants who did not coordinate in advance.

This is the argument this newsletter has made about the register, applied to the holder. A market working from one ownership record does not reconcile. A market where an investor is verified once does not re-onboard. The saving was never the first check. It is every repetition after it.

Why a Modular Account Changes What an Audit Covers

A fixed contract has a fixed surface. An auditor can reason about every path a call can take and reach a conclusion about the whole.

A modular account does not offer that. Its behaviour depends on modules that may be installed after the audit is complete, by parties the auditor did not assess. The question is no longer only whether the code is correct. It is whether the permission model holds when composed with code that does not yet exist.

Two permission models now operate inside one account, and that is where the question concentrates. ERC-734 assigns each key a purpose that determines its authority. ERC-7579 governs how a transaction is validated and executed. Both are well understood individually. The surface that matters is the boundary between them, and whether a key's stated purpose still constrains what it can do once execution is routed through an installed module.

That boundary is where the audit spent most of its time.

We spent most of the review on where the two permission models meet: ERC-734 key purposes and the ERC-7579 execution path. It's the tricky part because a key with limited permissions can end up with more authority than intended once a call runs through an installed module, and it's where the most serious findings were. The T-REX team engaged closely on every finding, and all critical- and high-severity issues were resolved.

António Abreu, Project Manager at OpenZeppelin

What This Does Not Solve

It does not decide who is eligible. Claims are issued by parties trusted to issue them, and eligibility remains with the issuer and the jurisdiction.

It does not remove a check. It removes the repetition of checks already performed.

Modularity is also a governance question, not only an engineering one. A portable identity is worth something only if venues trust what has been installed in it. A standard that makes modules straightforward to add has to be equally serious about how they are reviewed. That work is ahead of the industry, not behind it.

One Identity Across Approved Environments

Tokenized securities will not live in one environment. Issuers, custodians, venues and applications will use different networks for different reasons.

The question is whether those environments can recognise the same holder.

An identity that can only prove things needs a system built around it. Somebody holds the asset, somebody signs, somebody repairs it when a key is lost, and each of those is a cost the market pays on every movement.

An identity that can act is market infrastructure. It arrives carrying what the environment needs, and leaves without the environment having to file anything.

The assets are already onchain. Whether they move depends on whether the holder has to be introduced from scratch at every door.