Why we rebuilt T-REX

Most tokenized securities keep their rules and their ownership record in separate systems. T-REX v5 defines both once, and they hold wherever the asset goes.

A tokenized fund offered on a second network usually ends up with a second register. The same happens with a new venue or a new distributor. Each keeps its own list of holders, checks the same investor again and applies the fund's transfer rules in its own way. Then someone in operations reconciles the lists.

This is how most tokenized securities are built today. Compliance lives in one system, ownership in another, and people keep the two in line. The rules do not travel with the asset, so every time the asset reaches somewhere new, the work starts again.

T-REX v5 is our answer to that. This piece sets out what we learned, what we changed, and what it means for the institutions that issue tokenized securities and the teams that build around them.

What the first generation taught us

ERC-3643, the open standard for tokenized securities, put the rules inside the security. T-REX authored it; the ERC-3643 Association, with more than 140 institutional members, now governs it, and billions have been tokenized using it. The core idea has held up: every transfer is checked against the investor's eligibility and the security's rules before it settles, and if either check fails, nothing is recorded.

Real deployments showed us where the first design stopped short.

The rules stopped at the edge of a network. A cap on investors per country, or a daily limit per holder, is simple on one network. Put the same security on several and every transfer has to be reported to all the others. With two networks that is awkward; with ten it is unworkable. So issuers created a separate share class for each network, and with it a separate register.

Investor checks were repeated. Linking an investor's wallets to their verified identity was a task for the issuer's agent, asset by asset. A check that should have been done once was rebuilt for every issuance.

The identity itself caused friction. To add a credential to an investor's identity, the party issuing it needed a key on that identity. Without one, the investor could not be onboarded. That single step is a large part of why some implementations dropped the identity layer and fell back to a plain list of approved wallets, which is not what the standard is for.

One kind of transfer escaped the checks. Rules applied to the sender and the recipient, but not to a third party moving tokens on a holder's behalf under an allowance.

What v5 changes

Compliance is defined once, at the asset, and holds wherever it goes. The security's rules and its authoritative record of ownership sit in one place. When the asset is transferred on another network, that transfer reserves its share of the global limits before it settles, so two transfers in two places cannot together break a rule. What it means: one security and one share class across networks, not a copy per network.

Investors link their own wallets, once. With ONCHAINID v3, an investor links the wallets they own to their identity, and the link is recognised by every asset that uses it. Agents can still register wallets for the assets they manage. Credential issuers that an asset trusts add credentials directly, with no key on the investor's identity. What it means: an investor checked once is recognised again, and onboarding does not stall at the credential step.

Eligibility fits the holder. Identities are typed: individuals, companies, smart contracts, assets. An asset can ask for a different credential from each type, for example an identity check for an individual and an entity check for a company. What it means: the rules can follow how the offering documents describe an eligible holder.

Every route to a transfer is checked. The spender is now part of the checks, and only trusted parties can move tokens on a holder's behalf. What it means: no transfer goes around the rules.

Underneath, the contracts use standardised upgrade patterns, so they can be improved over years without disturbing the record they hold.

ONCHAINID v3 is a bigger change than this piece can cover. The identity becomes a modular smart account (ERC-7579), with passkeys and room for new ways of verifying an investor without changing the core contracts. That is the subject of our next piece, next week.

What it means for institutions

Cost. One record means one fewer reconciliation for every network or venue the asset reaches.

Risk. The rules are enforced in the security at every transfer, not re-implemented by each venue. Fewer copies of the rules leave fewer places for them to drift.

Distribution. With v5, reaching a new network or a new distributor does not mean a new share class and a new register.

Control. The issuer still sets the rules and the agent still decides who is eligible. v5 changes where those decisions are enforced, not who makes them.

It matters just as much what v5 does not do. It does not decide the rules. It does not make the record the legal register unless the documents and the law make it one. And it does not replace the transfer agent, the custodian or any other regulated party around the issuer.

What it means for builders

For builders, v5 is a stable base. The interfaces remain ERC-20 and ERC-3643, and the identity layer becomes something an application can work with rather than around: an investor with a verified credential and wallets they control.

The tools to build on it come with mainnet in November: the T-REX Factory to issue a security on the standard, the T-REX Console to run it, and SDKs for teams building both into their own systems. What gets built on top, from lending against tokenized funds to collateral, distribution and servicing, is for builders to decide.

Independently checked

Infrastructure that holds the record of who owns a security has to be checked by someone outside the team that built it. OpenZeppelin's audit reports for T-REX v5 and ONCHAINID v3 publish tomorrow.

Apex Group, which backs T-REX, has committed to bringing $100 billion in tokenized assets to the Network by 2027. Mainnet follows, in November.