Skip to content

ERC-3643 (T-REX) Development

In short

ERC-3643 (T-REX) is the standard for permissioned tokens: an identity and compliance layer means a transfer only succeeds between verified parties under rules enforced on-chain. We build the token, the ONCHAINID identity layer, the trusted-issuer and claim registries, and the compliance modules that encode your actual restrictions.

ERC-3643
the compliant standard we build on
95+
protocols delivered
$2B+
secured across our deployments
1M+
developers on Solhint, which we maintain
Trusted by teams building on-chain

ERC-3643, also known as the T-REX protocol, is the token standard for permissioned assets: tokens that can only be held and transferred by identities that meet defined rules. A plain ERC-20 treats every address the same and lets anyone hold it, which is exactly what a regulated security or real-world asset cannot allow.

ERC-3643 adds an identity and compliance layer so that a transfer only succeeds if both parties are verified and the transfer itself is permitted, enforced on-chain by the token contract rather than by a custodian checking after the fact. It is the standard behind most compliant tokenization of securities, funds, and real-world assets, and building it correctly is what separates a token that satisfies a regulator from one that only looks compliant.

Protofire builds ERC-3643 as engineering, not a checkbox. That means the token contract and its permissioning, the on-chain identity layer (ONCHAINID) that proves who an address belongs to, the trusted-issuer and claim registries that record who is allowed to verify what, and the modular compliance rules that encode your actual restrictions, jurisdiction limits, holding periods, investor caps, and lockups.

We build this as part of a wider tokenization infrastructure practice (vaults, NAV oracles, Proof-of-Reserve) for RWA issuers, so the token standard fits into the full system a regulated product needs rather than sitting on its own.

ERC-3643 is four layers, not one token

We build each layer, from the token to the compliance rules it enforces.

01

Token contract

The permissioned ERC-3643 token that checks identity and compliance on every transfer, mint, and burn.
02

Identity (ONCHAINID)

On-chain identities that hold verifiable claims (KYC, accreditation, jurisdiction) about each holder.
03

Registries

Identity, trusted-issuer, and claim-topic registries that record who may verify what.
04

Compliance modules

Modular rules, jurisdiction, investor caps, holding periods, lockups, applied to every transfer.
01

What is ERC-3643?

A regulated token has to control who holds it and how it moves, and it has to do so at the protocol level, not through an off-chain database. ERC-3643 makes the token itself permissioned: every transfer, mint, and burn calls a check that asks two questions, is the receiver a verified, eligible identity, and does this specific transfer comply with the rules.

If either answer is no, the transfer reverts. This is fundamentally different from an ERC-20 with a pause switch or a simple allowlist, because eligibility is tied to a verifiable on-chain identity and the rules are modular and enforced automatically, which is what a regulator and an institutional counterparty actually require.

02

What we deliver

The ERC-3643 token contract and its transfer-time compliance and identity checks, built on the audited T-REX architecture and hardened before audit, so the token enforces eligibility and rules on every movement.

03

Who is ERC-3643 development for?

RWA and security-token issuers who need tokens that only verified, eligible investors can hold and trade, with the compliance enforced on-chain rather than promised in a document. Tokenized-fund and asset managers who need investor eligibility, jurisdiction limits, and lockups built into the token itself so the fund's rules cannot be bypassed by a transfer. Institutions and financial infrastructure providers building regulated products who want the compliant-token layer done to the standard the market has converged on, ERC-3643, rather than an in-house permissioning scheme they then have to defend. Platforms tokenizing regulated assets (real estate, private credit, equity, debt) that need the same identity and compliance layer across many asset types. The common requirement is a token whose rules a regulator and an institutional counterparty will accept, which is exactly the part that is hard to get right and expensive to get wrong once real assets are on-chain.

04

A tokenization team that builds compliance into the token

Protofire is a blockchain development company with 250+ shipped projects across 60+ networks and 95+ protocols since 2016. ERC-3643 is core to our tokenization infrastructure practice: we build permissioned tokens, on-chain identity and claim registries, and modular compliance rules as part of the full stack RWA issuers need, including async vaults (ERC-7540), NAV oracles, and Proof-of-Reserve.

Our broader credentials: we maintain Solhint, the Solidity linter used by 1M+ developers; we are a core contributor to the Chainlink ecosystem (the oracle and PoR layer a tokenized asset marks and attests against); we are an official Safe Guardian, and Protofire-deployed networks secure $2B+ across 120+ EVM networks. When compliance is enforced by the token contract itself, that contract has to be right, which is why we build it on the audited T-REX architecture and hold the custom modules to the standard we set with Solhint.

“An ERC-3643 token checks identity and compliance on every transfer, so the contract itself refuses a transfer that breaks the rules, instead of relying on an off-chain process to catch it afterward.”

FAQ

What is ERC-3643 (the T-REX protocol)?
ERC-3643, also called T-REX, is an Ethereum token standard for permissioned assets: tokens that only verified, eligible identities can hold and transfer. Where a standard ERC-20 lets any address hold the token, ERC-3643 adds an identity and compliance layer, so every transfer, mint, and burn is checked against two conditions: whether the receiver is a verified eligible identity, and whether the transfer complies with the asset's rules. If either fails, the transfer reverts. It is built from a token contract, an on-chain identity layer (ONCHAINID) that holds verifiable claims about each holder, registries that record which issuers are trusted to make which claims, and modular compliance rules. It has become the de facto standard for compliant tokenization of securities, funds, and real-world assets, because it enforces the rules in the token contract itself rather than relying on an off-chain process to catch violations after they happen.
How is ERC-3643 different from ERC-20 or ERC-1400?
ERC-20 is the base fungible-token standard: every address is equal and anyone can hold or receive the token, which is fine for a utility or governance token but not for a regulated asset. ERC-1400 was an earlier family of security-token standards that introduced partitions and transfer restrictions but left identity and compliance largely to the implementer. ERC-3643 goes further by standardizing the whole permissioning system: an on-chain identity layer (ONCHAINID), trusted-issuer and claim registries, and modular compliance rules the token enforces automatically on every transfer. The practical difference is that ERC-3643 gives you a complete, audited, widely adopted framework where eligibility and rules are tied to verifiable on-chain identities, rather than a token you then have to wrap in a bespoke compliance system. For most compliant RWA and security-token work today, ERC-3643 is the standard the market has converged on.
What is ONCHAINID and why does the token need it?
ONCHAINID is the on-chain identity layer ERC-3643 uses. Each investor has an identity contract that holds verifiable claims, statements such as "passed KYC," "is an accredited investor," or "resident in an allowed jurisdiction," each issued and signed by a trusted party like a KYC provider. The token needs it because compliance has to be checked against something verifiable and reusable. When someone tries to receive the token, the contract checks whether their identity holds the claims the compliance rules require, without storing personal data on-chain itself. The identity and its claims live separately from the token, so the same verified identity can be reused across multiple tokens and issuers, and a claim can be revoked if someone's status changes. We build the ONCHAINID integration and the claim-issuance flow with your verification providers so eligible investors are onboarded and checked automatically.
Can you enforce our specific compliance rules (jurisdiction, lockups, investor caps)?
Yes, that is what the compliance-module layer is for. ERC-3643 expresses rules as modules the token consults on every transfer, so we encode your actual restrictions as code: permitted and forbidden jurisdictions, maximum number of holders, per-holder ownership caps, lockups and holding periods, time-based transfer windows, and combinations of these. Because the rules are modular, they are explicit and auditable, and most can be adjusted without redeploying the token. The engineering care goes into getting the combined rule set right, especially where two rules interact or where an edge case (a partial transfer near a cap, a lockup expiring mid-transaction) could otherwise let a non-compliant transfer through. We build the modules your asset's legal and regulatory constraints require and test them against those edge cases before the token holds real value.
Do you build the rest of the tokenization stack, not just the token?
Yes. The ERC-3643 token is one part of what a regulated tokenized product needs. Around it, an issuer usually needs vault infrastructure for subscriptions and redemptions (including async ERC-7540 vaults for funds), NAV oracles to price the asset on-chain, Proof-of-Reserve to attest that on-chain tokens are backed by real off-chain assets, and reporting for investors and regulators. We build ERC-3643 as part of that full tokenization infrastructure practice, so the compliant token, the vault, the oracle, and the attestation are designed as one system rather than assembled from separate vendors. If you only need the token and identity layer, we build that; if you need the whole regulated product, the token is the compliance core of it.
What is real-world asset (RWA) tokenization?
RWA tokenization is issuing a real-world asset, a bond, fund share, invoice, or property interest, as a blockchain token that carries its ownership record and its compliance rules on-chain. A permissioned standard like ERC-3643 embeds identity checks, investor eligibility, and transfer restrictions directly into the token, so only verified holders can hold or move it and the compliance logic enforces itself at the token level rather than relying on an off-chain gatekeeper. As of mid-2026, tokenized real-world assets on public blockchains total roughly $35 billion excluding stablecoins, up from about $5-6 billion in early 2025, with tokenized US Treasuries the largest category at around $16 billion (per rwa.xyz). These figures move quickly. When we tokenize an asset, ERC-3643 is usually the compliance core, with the custody, oracle, and attestation built around it.
What is the downside or risk of tokenizing a real-world asset?
Tokenization relocates the hard parts, it does not remove them. A token is only as enforceable as the legal claim behind it, so an on-chain transfer has to line up with a real, perfected transfer of the underlying. The underlying asset still has to be custodied and independently audited or attested by someone you trust. Secondary liquidity is often far thinner than headline market-size numbers suggest, especially for private credit and real estate. Non-cash assets depend on valuation and oracle inputs that can be wrong or manipulated. Rules differ by jurisdiction, so one token can be compliant in one market and an unregistered security in another. And redemption usually still settles through the issuer and traditional banking hours, so instant is conditional. A serious tokenization design addresses each of these explicitly rather than assuming the blockchain solves them, which is the part we focus on.

Reviewed by Luis Medeiros, Field CTO at Protofire. Last reviewed: July 2026.

Book a call with Alejandro Losa

Schedule a call with our Web3 Solution Architect to receive practical recommendations and a prompt proposal for upgrading your solution.

Protofire 2026. All rights reserved

Message us on Telegram