The "permissionless liability"

1. Identity Awareness: They recognize 0x addresses, not legal identities. They have no concept of KYC status or tax residency.
2. Granular Restrictions: They cannot natively enforce logic like "maximum 2,000 investors" (SEC Rule 12g) or volume limits.
3. Sovereign Recourse: If a private key is lost or stolen, an ERC-20 balance is effectively gone. In RWAs, legal ownership persists. The blockchain must be mutable by a higher authority to reflect legal reality via "Forced Transfers."

The "wrapper trap" and the ACT vulnerability

Architecture of trust: ERC-3643 (T-REX)

The decoupled identity model

• Key Rotation: If a user’s wallet is hacked, they can use a management key to swap the linked wallet on their ONCHAINID.
• Result: The issuer doesn't have to re-KYC the user or manually update dozens of whitelists. The identity persists independently of the access key.

The compliance engine

Architecture of control: ERC-1400

The partitioned model

• Partition A: Unlocked shares.
• Partition B: Locked (vesting) shares.
• Partition C: Reg D restricted (12-month hold).

Comparative security analysis: Choosing your standard

The "god mode" agent role

• Security Warning: This is your single point of failure. If an EOA holds this key, you are one phishing attack away from a total asset seizure.
• The Fix: Assign the Agent role to a Multi-Sig (Gnosis Safe) with a time-lock. For high-assurance assets, integrate a Legal Oracle that requires a signed "Court Order Hash" to be submitted on-chain before a forcedTransfer can execute.

Implementation: The compliance hook

1// ERC-3643: The Compliance Hook Architecture
2
3function _beforeTokenTransfer(
4    address from,
5    address to,
6    uint256 amount
7) internal virtual override {
8    super._beforeTokenTransfer(from, to, amount);

1// 1. Recipient Identity Check: Must be verified via ONCHAINID
2require(identityRegistry.isVerified(to), "Receiver not verified");
3
4// 2. Sender Identity Check: Crucial to prevent ACT/Spender exploits
5// We check the 'from' address, not just the msg.sender (spender)
6require(identityRegistry.isVerified(from), "Sender not verified");
7
8// 3. Modular Compliance Check: Satisfies specific rules (e.g., Investor Caps)
9require(compliance.canTransfer(from, to, amount), "Compliance violation");
10
11// Pattern: Check (Identity) -> Check (Rules) -> Act (Transfer)

1
2## The CTO’s decision matrix
3
4If you are building an [institutional-grade RWA platform](https://zealynx.io/blogs/audit-investors), stop trying to fix the ERC-20.
5
61.  **Use ERC-3643** if your primary risk is regulatory compliance and KYC/AML enforcement. It is the most resilient against key compromise because it decouples identity from the wallet.
72.  **Use ERC-1400** if you are managing a complex cap table where tokens within the same wallet must behave differently (e.g., different vesting schedules).
83.  **Hardcode Recourse:** Ensure your `forcedTransfer` events emit a data hash (as seen in ERC-1644) to provide an immutable audit trail for every administrative action.
9
10The future of RWAs isn't just about putting assets on a ledger; it’s about architecting a system where the digital state can never deviate from the legal reality. Choose the standard that treats identity as a first-class citizen.
11
12## Get in touch
13
14Building an RWA platform? Don't let compliance be your bottleneck. At Zealynx, we specialize in auditing institutional-grade protocols, ensuring your architecture can withstand both hackers and regulators.
15
16**[Secure your RWA Launch](/quote)**
17
18---
19
20## FAQ: RWA security & audits
21
22<details>
23<summary><strong>1. What is the difference between ERC-20 and ERC-3643?</strong></summary>
24
25ERC-20 is designed for permissionless transfer (anyone can send to anyone), making it risky for regulated assets. ERC-3643 is an "Identity-Centric" standard that natively embeds compliance checks (KYC/AML) into every transfer, ensuring that only verified identities can hold the token.
26
27</details>
28
29<details>
30<summary><strong>2. Why can't I just use an ERC-20 with a whitelist wrapper?</strong></summary>
31
32Wrappers often suffer from the "Check-Then-Act" gap or the **Approved Controllable TransferFrom (ACT)** vulnerability. If you whitelist a destination but fail to check the sender's status during a `transferFrom` call, an attacker could bypass your compliance rules.
33
34</details>
35
36<details>
37<summary><strong>3. What is a "Forced Transfer" and why is it required for RWAs?</strong></summary>
38
39In traditional finance, legal ownership supersedes possession. If a court orders the seizure of assets (e.g., due to fraud or divorce), the issuer must be able to move tokens without the owner's private key. Standards like ERC-1400 and ERC-3643 implement this "Sovereign Recourse" capability.
40
41</details>
42
43<details>
44<summary><strong>4. How much does an RWA smart contract audit cost?</strong></summary>
45
46Audit costs vary based on complexity (e.g., number of compliance modules). For a detailed breakdown of pricing benchmarks in 2026, check our guide on [Smart Contract Audit Costs](https://zealynx.io/blogs/audit-pricing-2026).
47
48</details>
49
50<details>
51<summary><strong>5. Does ERC-1400 support vesting schedules?</strong></summary>
52
53Yes. ERC-1400 uses a "Partitioned" model, allowing you to split a single user's balance into different tranches (e.g., "Locked," "Unlocked," "Reg D Restricted"). This makes it ideal for managing complex cap tables and vesting logic on-chain.
54
55</details>
56
57<details>
58<summary><strong>6. Is ERC-3643 compatible with DeFi protocols?</strong></summary>
59
60Yes, but with friction. Because every transfer requires the recipient to have a valid ONCHAINID, a DeFi pool (like Uniswap) must be whitelisted or registered as a verified entity to hold the token. This ensures compliance liquidity but restricts permissionless composability.
61
62</details>
63
64## Glossary
65
66| Term | Definition |
67|------|------------|
68| [ONCHAINID](/glossary/onchainid) | Self-sovereign identity contract used in ERC-3643 that links verified legal identities to blockchain wallets, enabling key rotation without re-KYC. |
69| [Forced Transfer](/glossary/forced-transfer) | Administrative capability allowing issuers or controllers to move security tokens without the holder's private key, required for regulatory compliance and legal enforcement. |
70| [Compliance Hook](/glossary/compliance-hook) | A `_beforeTokenTransfer` override pattern that intercepts every token state change to enforce identity verification and regulatory rules at the moment of transfer. |
71| [ACT Vulnerability](/glossary/act-vulnerability) | The Approved Controllable TransferFrom exploit where attackers bypass compliance wrappers by routing tokens through approved spenders that skip sender verification checks. |
72| [Legal Oracle](/glossary/legal-oracle) | An on-chain verification mechanism that requires a cryptographic proof of a legal instrument (e.g., court order hash) before authorizing privileged administrative actions like forced transfers. |
73| [Sovereign Recourse](/glossary/sovereign-recourse) | The principle that legal ownership supersedes blockchain possession, requiring token standards to support administrative overrides that reflect off-chain legal reality. |
74| [Self-Sovereign Identity](/glossary/self-sovereign-identity) | A decentralized identity model where users own and control their digital identity independently of any single platform, wallet, or service provider. |
75
76*[View complete glossary →](/glossary)*