RWA compliance: three standards, one explorer, zero excuses

Here is a question that will determine the trajectory of trillions of dollars: can your RWA token be used in a Uniswap pool?

The answer is not "yes" or "no." The answer is "it depends on which compliance standard you chose, and most teams chose without understanding the tradeoffs." We built a tool to fix that.

The RWA compliance explorer at kcolbchain.com/rwa-toolkit/ compares the three token standards that matter in 2026 — ERC-3643, ERC-1404, and KAIO — and lets you simulate transfer restrictions in real time. Configure a token policy, pick a transfer scenario, and watch exactly which compliance check fires and why.

The three standards

ERC-3643 is the incumbent. Originally developed by Tokeny under the name T-REX, it is the most deployed RWA standard on Ethereum. The architecture is identity-centric: every holder must have a verified on-chain identity (via ERC-734/735 claims), and every transfer passes through a compliance contract that checks both sender and receiver identities against configurable rules.

The strength of ERC-3643 is its completeness. It handles issuance, transfer restrictions, forced transfers (for court orders), identity recovery, and pause functionality. If a regulator asks "can you freeze a sanctioned address?", the answer is yes, and the mechanism is standardised.

The weakness is coupling. Because compliance checks are embedded in the transfer function, every DeFi protocol that wants to interact with an ERC-3643 token must be "identity-aware." A standard Uniswap V3 pool cannot hold an ERC-3643 token unless the pool contract itself has a verified identity. This is solvable — wrapper contracts, whitelisted DeFi venues — but it is friction, and friction kills composability.

ERC-1404 is the minimalist alternative. It adds a single function to ERC-20: detectTransferRestriction(from, to, value) returns a restriction code, and messageForTransferRestriction(code) returns a human-readable explanation. The transfer and transferFrom functions check the restriction before executing.

The elegance of ERC-1404 is that it is just ERC-20 with a guard. Any protocol that can call transfer can interact with an ERC-1404 token — the restriction logic is checked inside the transfer, not in external identity contracts. This means existing DeFi protocols work out of the box, as long as the participants pass the restriction check.

The weakness is expressiveness. ERC-1404 gives you a boolean gate per transfer. It does not standardise identity claims, forced transfers, or recovery. You can implement those features, but they are not part of the standard, so every issuer does it differently.

KAIO is the newest entrant, designed specifically for the 2026 regulatory landscape. It takes a modular approach: the token contract delegates compliance to a "policy engine" that can be swapped without redeploying the token. Policies are composable — you can stack a KYC check, a jurisdiction check, and a volume limit as independent modules.

KAIO's innovation is upgradeable compliance. When regulations change (and they always change), you deploy a new policy module and register it with the token. No migration, no reissuance, no breaking existing holder balances. The token contract is permanent; the rules are mutable.

The tradeoff is trust. Someone has to control the policy engine upgrade path. KAIO defines a governance interface for this, but in practice, the issuer retains admin keys. For regulated securities, this is arguably appropriate — the issuer is legally responsible for compliance anyway. For decentralisation maximalists, it is a red flag.

The simulator

Theory is useful. Seeing it in action is better.

The transfer-restriction simulator at kcolbchain.com/rwa-toolkit/ lets you:

• Configure a token policy. Select a standard (ERC-3643, ERC-1404, or KAIO). Define the issuer jurisdiction. Set KYC requirements (none, basic, accredited investor, qualified purchaser). Set transfer restrictions (whitelist-only, jurisdiction-blocked, volume-limited, time-locked).
• Define transfer participants. Create sender and receiver profiles with jurisdiction, KYC level, investor status, and wallet age. The simulator supports both individual and contract addresses — important because the rules differ when the receiver is a smart contract (like a DeFi pool).
• Simulate the transfer. Hit "Execute" and watch the compliance check unfold step by step. Each standard processes the check differently — ERC-3643 queries the identity registry then the compliance contract, ERC-1404 calls detectTransferRestriction inline, KAIO chains through policy modules in order. The simulator highlights exactly which check passes, which fails, and why.
• Compare outcomes. Run the same transfer scenario across all three standards simultaneously. You will often find that a transfer that succeeds under ERC-1404 fails under ERC-3643, or vice versa, because the identity model differs.

The DeFi composability question

This is where it gets consequential. The choice of compliance standard directly determines which DeFi protocols your RWA token can participate in.

An ERC-3643 token cannot be deposited into a standard Aave lending pool. The pool contract does not have an on-chain identity. You need either a modified pool that is identity-aware, or a wrapper contract that mediates between the identity layer and the DeFi protocol. Both approaches exist, but they fragment liquidity and increase gas costs.

An ERC-1404 token can be deposited into a standard Aave pool — if the pool address passes the transfer restriction check. In practice, this means the issuer whitelists specific DeFi venues. It works, but it requires the issuer to actively manage a whitelist of approved protocols.

A KAIO token can be configured either way, depending on the policy modules. You can deploy a "DeFi-permissive" policy that whitelists contract interactions broadly, or a "strict" policy that behaves like ERC-3643. The flexibility is the feature — and the risk, because it means two KAIO tokens from different issuers might have completely different DeFi compatibility.

The simulator includes a "DeFi compatibility" panel that shows, for your configured policy, which major DeFi protocols (Uniswap, Aave, Compound, Curve, Morpho) the token can interact with and under what conditions.

Reference Solidity hooks

The rwa-toolkit repository includes reference Solidity implementations for each standard's compliance hooks. These are not production contracts — they are annotated reference implementations designed to show exactly how each standard enforces restrictions at the EVM level.

Each implementation includes inline comments explaining the gas costs, the storage layout, and the upgrade path. If you are evaluating which standard to adopt for a new RWA issuance, start here.

Compliance is not a checkbox

The biggest mistake we see in RWA tokenisation is treating compliance as a box to check rather than a design decision that shapes the entire product. The standard you choose determines your DeFi composability, your upgrade path, your gas costs, your identity requirements, and your regulatory surface area.

There is no universally "best" standard. ERC-3643 is right for heavily regulated securities that need forced transfer capability. ERC-1404 is right for tokens that need maximum DeFi composability with minimal overhead. KAIO is right for issuers who expect regulatory requirements to evolve and want to upgrade policies without migrating tokens.

The tool helps you make that choice with your eyes open. Not with a sales pitch from the standard's backers, but with a simulator that shows you exactly what happens when a real transfer hits a real compliance check.