Các tiêu chuẩn token cho RWA: ERC-3643 (T-REX), ERC-1400, ERC-7518 | VCC

Meta Title: Các tiêu chuẩn token cho RWA: ERC-3643, ERC-1400, ERC-7518 so sánh | Thông số kỹ thuật

---

Tiêu chuẩn RWA Token: Sự thực kỹ thuật sau những lời quảng cáo

Token hóa tài sản thực tế (RWA) nghe có vẻ đơn giản trên giấy: đại diện cho một tòa nhà, một trái phiếu hoặc một cổ phần quỹ bằng một token trên Ethereum. Cảm giác thực tế xuất hiện khi bạn cố gắng thực thi KYC trên một blockchain không cần sự cho phép, xử lý các chuyển giao bắt buộc cho các lệnh của tòa án hoặc quản lý nhiều lớp cổ phần với các thời hạn khóa khác nhau trong một hợp đồng duy nhất.

Ba tiêu chuẩn thống trị không gian này: ERC-3643 (T-REX), ERC-1400 và ERC-7518. Chỉ có một tiêu chuẩn đạt trạng thái "Final". Một tiêu chuẩn đã ở trạng thái "Stale" kể từ năm 2018. Tiêu chuẩn mới nhất vẫn ở trạng thái "Review". Nếu bạn đang xây dựng cơ sở hạ tầng RWA sản xuất vào năm 2025, sự khác biệt này quan trọng hơn danh sách các tính năng trong các tệp README của chúng.

---

Tại sao các tiêu chuẩn Token tiêu chuẩn thất bại đối với chứng khoán

ERC-20 hoạt động cho các token tiện ích vì các chuyển khoản chỉ cần một kiểm tra: balanceOf(sender) >= amount. Các chứng khoán khác. Một chuyển khoản có thể thất bại vì:

• Người nhận chưa qua kiểm tra KYC
• Mã thông báo của người gửi bị khóa cho đến khi có sự giảm giá (vesting cliff)
• Hợp đồng mã thông báo áp đặt giới hạn số lượng người giữ (ví dụ, 2.000 nhà đầu tư cho Reg D)
• Cơ quan quản lý đã đóng băng ví của người nhận
• Việc chuyển giao vượt quá giới hạn tập trung của người giữ duy nhất (ví dụ, tối đa 10%)

transfer của ERC-20 trả về bool. Token bảo mật cần canTransfer(from, to, amount, data) → (byte reasonCode, bytes32 partition, bytes32 extraData) – một kết quả chi tiết giải thích lý do tại sao một chuyển giao sẽ thất bại, không chỉ là nó sẽ thất bại.

---

ERC-3643 (T-REX): Thước đo sản xuất

Tình trạng: Cuối cùng | Được kiểm toán: Kaspersky, Hacken | TVL: $32B+

ERC-3643 là tiêu chuẩn token bảo mật duy nhất đã được nâng cấp lên "Final" trên đường dẫn EIP. Được phát triển bởi Tokeny (nay là một phần của Apex Group), nó được xây dựng trên một kiến trúc gồm 6 hợp đồng, giúp phân chia các vấn đề một cách rõ ràng:

` Token (ERC-20 compatible) ├── Identity Registry → Identity Registry Storage (shared whitelist) ├── Compliance (rules engine) ├── Trusted Issuers Registry (claim issuers + topics) └── Claim Topics Registry (required claims for eligibility) `

Những cải tiến chính: Khung xác định danh tính ONCHAINID

ERC-3643 không chỉ chỉ hỗ trợ danh tính – nó đề nghị ONCHAINID. Mỗi nhà đầu tư phải có một hợp đồng danh tính (ERC-735) liên kết với ví của họ. Các yêu cầu (KYC đã được thông qua, nhà đầu tư được chứng nhận, thẩm quyền) được ký bởi các nhà phát hành đáng tin cậy được lưu trữ trong TrustedIssuersRegistry. ClaimTopicsRegistry xác định các chủ đề yêu cầu (ví dụ, 1 = KYC, 2 = Được chứng nhận, 3 = Thẩm quyền: Mỹ) là bắt buộc.

`solidity // Simplified transfer logic from ERC-3643 function transfer(address _to, uint256 _amount) public override whenNotPaused returns (bool) { require(!_frozen[_to] && !_frozen[msg.sender], "Frozen wallet"); require(_amount <= balanceOf(msg.sender) - _frozenTokens[msg.sender], "Insufficient free balance"); require(_tokenIdentityRegistry.isVerified(_to), "Invalid identity"); // ONCHAINID check require(_tokenCompliance.canTransfer(msg.sender, _to, _amount), "Compliance failure"); _transfer(msg.sender, _to, _amount); _tokenCompliance.transferred(msg.sender, _to, _amount); return true; } `

Kiểm tra isVerified

isVerified(address investor) trả về true chỉ khi:

1. Ví của nhà đầu tư được đăng ký trong IdentityRegistry
2. Sัญญ Identity của họ chứa tất cả các yêu cầu cần thiết từ ClaimTopicsRegistry
3. Mỗi yêu cầu được ký bởi một nhà phát hành trong TrustedIssuersRegistry
4. Các yêu cầu chưa hết hạn

Đây là quy định KYC trên chuỗi – không cần oracle ngoài chuỗi để thực hiện xác minh.

Vai trò đại lý: tự động hóa không có khóa chủ

The IAgentRole interface (required on Token, IdentityRegistry, Compliance, IdentityRegistryStorage) lets the owner appoint automated systems as agents:

`solidity interface IAgentRole { event AgentAdded(address indexed _agent); event AgentRemoved(address indexed _agent); function addAgent(address _agent) external; function removeAgent(address _agent) external; function isAgent(address _agent) external view returns (bool); } `

Một đại lý có thể là một hợp đồng thông minh tự động tạo ra khi đăng ký, tự động hủy bỏ khi thanh toán, hoặc đóng băng ví được đánh dấu bởi một oracle tuân thủ – tất cả đều không cần đến khóa riêng của chủ sở hữu để rời khỏi kho lưu trữ lạnh.

Khôi phục: Chìa khóa bị mất không phải là tài sản bị mất

`solidity function recoveryAddress( address _lostWallet, address _newWallet, address _investorOnchainID ) external returns (bool); `

Người phát hành (hoặc đại diện được ủy quyền) có thể chuyển số dư của một nhà đầu tư sang ví mới, miễn là nhà đầu tư chứng minh quyền sở hữu ONCHAINID của mình. Sự kiện RecoverySuccess tạo ra một đường dẫn kiểm tra không thể thay đổi.

Các tác vụ theo nhóm: hiệu quả sử dụng khí ở quy mô lớn

`solidity function batchTransfer(address[] calldata _toList, uint256[] calldata _amounts) external; function batchForcedTransfer(address[] calldata _fromList, address[] calldata _toList, uint256[] calldata _amounts) external; function batchMint(address[] calldata _toList, uint256[] calldata _amounts) external; `

Đáng kể đối với các quản trị viên quỹ xử lý hàng trăm giao dịch của nhà đầu tư trong một khối duy nhất.

Thừa nhận những sự thay thế

Ưu điểm	Cons
Tiêu chuẩn cuối cùng, được kiểm toán, tài sản hoạt động hơn 32 tỷ USD	Yêu cầu ONCHAINID = phụ thuộc vào nhà cung cấp
Tách biệt rõ ràng các vấn đề (6 hợp đồng)	2-3x gas cost vs ERC-20 transfer
Built-in recovery, freezing, pausing	Không hỗ trợ phân vùng bản địa cho các lớp chia sẻ
Vai trò của đại lý cho phép tự động hóa	Quy định tuân thủ yêu cầu có hợp đồng tùy chỉnh cho từng khu vực
Tích hợp với ERC-20 (các ví, các trình khám phá hoạt động)	Cross-chain = xác minh lại danh tính trên địa điểm đích

---

ERC-1400: Mẫu ô dù tham vọng bị trì hoãn

Tình trạng: Bản thảo (đã tồn tại từ năm 2018) | Các thành phần: ERC-1410, ERC-1594, ERC-1643, ERC-1644

ERC-1400 không phải là một hợp đồng đơn lẻ – nó là một bộ bốn EIP phụ thuộc lẫn nhau kết hợp lại tạo thành một khung token bảo mật toàn diện:

Kém tiêu chuẩn	Mục đích	Giao diện chính
ERC-1410	Partially Fungible Tokens (partitions)	balanceOfByPartition, partitionsOf, transferByPartition
ERC-1594	Core Security Token (transfer gates)	canTransfer, canTransferByPartition, transferWithData
ERC-1643	Quản lý tài liệu	getDocument, setDocument, sự kiện Document
ERC-1644	Các hoạt động của bộ điều khiển	isControllable, controllerTransfer, controllerRedeem

Token có thể thay thế một phần (ERC-1410): Mô hình phân chia

ERC-1410 giới thiệu các phân vùng bytes32 – các phần tử logic trong một hợp đồng token duy nhất:

`solidity function balanceOfByPartition(bytes32 _partition, address _tokenHolder) external view returns (uint256); function partitionsOf(address _tokenHolder) external view returns (bytes32[]); function transferByPartition( bytes32 _partition, address _to, uint256 _value, bytes _data ) external returns (bytes32 _toPartition); `

Ví dụ: Quỹ bất động sản có hai phân vùng:

Tổng số dư của nhà đầu tư = balanceOfByPartition(0x01, investor) + balanceOfByPartition(0x02, investor). Các chuyển khoản xác định phân vùng nguồn; hợp đồng xác định phân vùng đích (trả về dạng bytes32).

Xác minh chuyển khoản với mã lý do (ERC-1594)

`solidity function canTransfer( address _to, uint256 _value, bytes _data ) external view returns (byte, bytes32); // Returns: reasonCode (EIP-1066), destinationPartition

function canTransferByPartition( address _from, address _to, bytes32 _partition, uint256 _value, bytes _data ) external view returns (byte, bytes32, bytes32); // Returns: reasonCode, fromPartition, toPartition `

Kích thước tham số _data chấp nhận chữ ký ngoài chuỗi (ví dụ: phê duyệt của trung gian, xác nhận KYC). Mã lý do byte tuân theo EIP-1066:

Hoạt động của bộ điều khiển (ERC-1644): Quy định pháp lý

`solidity function isControllable() external view returns (bool); function controllerTransfer( address _from, address _to, uint256 _value, bytes _data, bytes _operatorData ) external; function controllerRedeem( address _tokenHolder, uint256 _value, bytes _data, bytes _operatorData ) external; `

If isControllable() == true, the controller (issuer, regulator, transfer agent) can force transfers without the holder's approval. Events ControllerTransfer and ControllerRedemption flag these for audit trails.

Why It Stalled

1. Complexity explosion: Four EIPs, each with multiple interfaces, create integration burden
2. No reference implementation reached production — the SecurityTokenStandard repo has 115 stars but few production deployments
3. ERC-3643 shipped first with a working product (Tokeny's T-REX platform)
4. Partition model on ERC-20 base is gas-inefficient vs ERC-1155 native partitions
5. Stale label on GitHub issues signals community consensus: move on

Khi bạn vẫn có thể sử dụng nó

• Các hệ thống cũ đã được xây dựng trên ERC-1400 (chi phí di chuyển > chi phí tái xây dựng)

---

ERC-7518 (DyCIST): The Modern Challenger

Tình trạng: Đang xem xét | Cơ sở: ERC-1155 | Tác giả: Zoniqx Team

ERC-7518 learns from both predecessors. It uses ERC-1155's native tokenId as the partition primitive — no separate partition standard needed. Each tokenId = a distinct partition with its own compliance rules, lockup schedule, and payout rights.

Partition = tokenId: Native Semi-Fungibility

`solidity // ERC-1155 balanceOf(account, id) becomes partition balance function transferableBalance(address account, uint256 id) external view returns (uint256); // balanceOf - lockedBalanceOf function lockedBalanceOf(address account, uint256 id) external view returns (uint256); `

Partition use cases:

• id = 1: "Reg D - US Accredited" (transfer restricted to KYC'd US investors)
• id = 2: "Reg S - Non-US" (different KYC rules)
• id = 3: "Founder Shares" (24-month lockup, voting rights)
• id = 4: "Preferred Series A" (liquidation preference, quarterly dividends)

All in one contract. No partition registry, no bytes32 mapping — just ERC-1155 id.

Tuân thủ dựa trên phiếu: Quy tắc ngoài chuỗi, thực thi trên chuỗi

Kinh nghiệm đột phá của ERC-7518 là tách logic tuân thủ khỏi hợp đồng token:

`solidity function canTransfer( address from, address to, uint256 id, uint256 amount, bytes calldata data ) external view returns (bool status); `

Kích thước tham số data chứa một phiếu được ký theo tiêu chuẩn EIP-712 từ dịch vụ tuân thủ ngoài chuỗi:

`javascript // Off-chain compliance service generates voucher const voucher = { from: "0x123...", to: "0x456...", id: 1, // Reg D partition amount: 1000, expiry: 1735689600, nonce: 0xabc... };

// Signed by compliance service's EIP-712 key const signature = await complianceSigner.signTypedData(domain, types, voucher);

// User submits transfer with voucher in data await token.safeTransferFrom(from, to, id, amount, abi.encode(voucher, signature)); `

Công thức canTransfer:

1. Kiểm tra chữ ký của phiếu
2. Kiểm tra thời hạn, nonce, liên kết tham số
3. Kiểm tra các quy tắc trên chuỗi (đóng băng, hạn chế, khóa)
4. Trả về true chỉ khi tất cả đều đáp ứng

Tại sao điều này quan trọng: Quy định tuân thủ có thể thay đổi (quy định mới, danh sách trừng phạt được cập nhật) không cần tái phân bổ hợp đồng token. Dịch vụ ngoài chuỗi cập nhật logic của nó; cửa ngõ trên chuỗi vẫn giữ nguyên.

Các tính năng bản địa ERC-3643 thiếu

Feature	ERC-7518	ERC-3643
Time-based locking	lockTokens(account, id, amount, releaseTime)	❌ Custom compliance module
Partition restrictions	restrictTransfer(id) / removeRestriction(id)	❌ Mô-đun tuân thủ tùy chỉnh
Payouts	payout(to, amount) / batchPayout(to[], amount[])	❌ Custom distribution contract
Interoperability	wrapToken, wrapTokenFromPartition, unwrapToken	❌
Cross-standard wrapping	Wraps ERC-20, ERC-721, ERC-1400	❌

Bao gói: Hàng rào di chuyển

`solidity // Wrap ERC-20 security token → ERC-7518 partition function wrapToken(uint256 amount, bytes calldata data) external returns (bool);

// Wrap from specific partition of ERC-1400/ERC-3525 → ERC-7518 function wrapTokenFromPartition( bytes32 partitionId, uint256 id, uint256 amount, bytes calldata data ) external returns (bool);

// Unwrap back to original standard function unwrapToken(uint256 wrappedTokenId, uint256 amount, bytes calldata data) external returns (bool); `

Điều này cho phép di chuyển dần: giữ các token ERC-1400 cũ cho các chủ sở hữu hiện có, phát hành các phân vùng ERC-7518 mới cho các nhà đầu tư mới, đóng gói/tháo gói theo nhu cầu.

Kiến trúc tham chiếu ba hợp đồng

` erc1155mod.sol (Base Ledger) └── ERC-1155 with partition = tokenId ├── mint/burn per partition └── balanceOf(account, partitionId)

STObasev2.sol (Security Token Offering) └── Sale lifecycle: pricing, settlement, investor onboarding └── Transfers purchased partitions to investors

erc7518.sol (Vault + Wrapper + Compliance Gateway) ├── Wraps external tokens (ERC-20, ERC-721, ERC-1400) ├── Pre-transfer gate: calls canTransfer(voucher) ├── Delegates balance management to erc1155mod └── Handles payouts, locking, freezing, force transfer `

Trade-offs

Pros	Cons
Native partitions (ERC-1155) = gas efficient	Still in Review — spec may change
Tuân thủ dựa trên phiếu = linh hoạt, có thể nâng cấp	Yêu cầu cơ sở hạ tầng dịch vụ tuân thủ ngoài chuỗi
Native locking, payouts, wrapping	No mandatory identity standard (build your own)
Cross-standard interoperability	Hệ sinh thái nhỏ hơn, ít kiểm toán hơn
Hợp đồng đơn cho tài sản đa loại	GPL-3.0 license (viral — may deter proprietary use)

---

Head-to-Head Comparison

Dimension	ERC-3643 (T-REX)	ERC-1400	ERC-7518 (DyCIST)
EIP Status	✅ Final	⚠️ Draft (Stale)	🔄 Review
Tiêu chuẩn cơ bản	ERC-20	ERC-20/777	ERC-1155
Partition Model	❌ None	ERC-1410 (bytes32)	Native (tokenId)
Hệ thống xác định danh tính	ONCHAINID ( bắt buộc )	Agnostic	Agnostic
Compliance Model	On-chain Compliance contract	canTransfer + off-chain data	Bảo hiểm dựa trên phiếu (EIP-712)
Công suất chuyển đổi khí (được ước tính)	~85,000	~95,000	~75,000
Chuyển đổi bắt buộc	✅ forcedTransfer	✅ controllerTransfer	✅ forceTransfer
Freezing	Address + partial tokens	Address (via partition)	Địa chỉ + giới hạn phân vùng
Khóa thời gian	❌ Custom module	Via partition metadata	✅ lockTokens/unlockToken
Payouts	❌ Custom	❌ Custom	✅ payout/batchPayout
Bao gói/ tương thích	❌	❌	✅ ERC-20/721/1400
Audit Status	Kaspersky, Hacken	Không có thông tin	Chưa có
Production TVL	$32B+	Thấp nhất	Chỉ dành cho phi công
License	MIT (via Tokeny)	MIT	GPL-3.0

---

Decision Framework: Which Standard for Your Project?

Choose ERC-3643 If:

• Production deployment in EU/US regulated markets (MiCA, Reg D/Reg S)
• Team lacks compliance infrastructure — Tokeny's T-REX Engine provides off-the-shelf KYC/AML, investor onboarding, cap table management
• Identity standardization matters — ONCHAINID gives you a vetted, interoperable identity layer
• Audit trail is non-negotiable — Kaspersky/Hacken audits, $32B TVL proves battle-testing
• Timeline: need to launch in <3 months

Chọn ERC-7518 nếu:

• Các tài sản đa lớp phức tạp (tài sản bất động sản với quyền sở hữu từng tầng, quỹ với 5+ loại cổ phiếu)
• Cần khả năng tương thích giữa các tiêu chuẩn — bao gồm các mã thông báo cũ ERC-20/ERC-1400

Tránh sử dụng ERC-1400 cho các dự án mới vì:

• Cũ từ năm 2018 - không có điểm đánh dấu cuối trong 7 năm

---

Migration Paths: From Legacy to Modern

ERC-1400 → ERC-7518 (Tốt nhất)

`solidity // 1. Deploy ERC-7518 contract with matching partitions // 2. For each ERC-1400 partition: token7518.wrapTokenFromPartition( partitionId, // ERC-1400 bytes32 partition tokenId, // ERC-7518 target partition (tokenId) amount, abi.encode(erc1400TokenAddress, investorAddress) );

// 3. Investor calls unwrap on ERC-7518 to retrieve original if needed // 4. Decommission ERC-1400 contract after full migration `

ERC-20 → ERC-3643 (Yêu cầu tái phát hành)

ERC-3643 cannot wrap ERC-20 — the identity/compliance architecture is fundamentally different. Standard path:

1. Lấy ảnh chụp các chủ sở hữu ERC-20
2. Xác minh KYC cho mỗi chủ sở hữu thông qua ONCHAINID
3. Phát hành token ERC-3643
4. batchMint cho các nhà đầu tư đã được xác minh
5. Hủy bỏ ERC-20 cũ (hoặc tạm dừng hoạt động vĩnh viễn)

---

Kiểm tra thực tế về chi phí khí

Hoạt động	ERC-3643	ERC-1400	ERC-7518
Chuyển đổi đơn giản (phù hợp)	~85,000	~95,000	~75,000
Chuyển khoản bằng xác minh bằng voucher	N/A	~120,000	~95,000
Mint (single)	~65,000	~70,000	~55,000
Batch mint (100 recipients)	~280,000	~320,000	~250,000
Force transfer	~70,000	~80,000	~65,000
Tạm dừng địa chỉ	~45,000	~50,000	~40,000
Token khóa (chỉ hỗ trợ ERC-7518)	N/A	N/A	~55,000
Bao mã token (chỉ hỗ trợ ERC-7518)	N/A	N/A	~110,000

Điều ước dựa trên các chụp ảnh gas của Foundry, mạng chính Ethereum, giá năm 2024. Chi phí thực tế thay đổi tùy theo mức độ phức tạp của tuân thủ.

---

Vietnam Context: Where RWA Tokenization Stands

Vietnam's RWA tokenization is in early stages but accelerating:

• Regulatory: MOF (Ministry of Finance) drafting securities tokenization framework; SBV cautious on crypto but supportive of blockchain for securities settlement
• Real estate: Proptech startups (RedSwan Vietnam, local pilots) exploring fractional ownership via tokenization
• Corporate bonds: VNDIRECT, SSI Securities piloting tokenized bond issuance on private chains
• Identity: VNeID (national digital ID) could integrate with ONCHAINID or custom registries for KYC

Khuyến nghị thực tế cho các đội ngũ Việt Nam: Hãy bắt đầu với ERC-3643 trên Polygon hoặc Base (chi phí gas thấp, tương thích với EVM). Sử dụng T-REX Engine của Tokeny cho KYC/AML – nó tích hợp với các nhà cung cấp toàn cầu và có thể kết nối với xác minh VNeID. Di chuyển sang ERC-7518 khi bạn cần tài sản đa lớp hoặc phân phối xuyên chuỗi.

---

Danh sách kiểm tra thực hiện cho các nhà phát triển hợp đồng thông minh

Cài đặt ERC-3643

• [ ] Cài đặt hợp đồng xác định danh tính ONCHAINID cho nhà phát hành, đại lý, dịch vụ tuân thủ
• [ ] Cài đặt IdentityRegistryStorage (danh sách trắng chia sẻ)
• [ ] Cài đặt IdentityRegistry cho mỗi token (giới thiệu đến bộ lưu trữ, thiết lập các nhà phát hành đáng tin cậy, chủ đề yêu cầu)
• [ ] Cài đặt hợp đồng tuân thủ (cấu hình số lượng chủ tối đa, giới hạn tập trung, các quốc gia được phép)
• [ ] Cài đặt hợp đồng token (giới thiệu đến bộ lưu trữ, tuân thủ, ONCHAINID)
• [ ] Đăng ký các nhà phát hành yêu cầu đáng tin cậy (nhà cung cấp KYC, xác nhận chứng nhận)
• [ ] Xác định các chủ đề yêu cầu (1=KYC, 2=Chứng nhận, 3=Thẩm quyền, v.v.)
• [ ] Ký nhiệm đại lý (hợp đồng tự động tạo, hủy, đóng băng)
• [ ] Kiểm tra quá trình recoveryAddress trên mạng thử nghiệm
• [ ] Kiểm tra mô-đun tuân thủ tùy chỉnh nếu không sử dụng Tokeny

ERC-7518 Deployment

• [ ] Cài đặt erc1155mod (sổ kế toán cơ sở)
• [ ] Cài đặt erc7518 (vault + wrapper + cầu nối tuân thủ)
• [ ] Cài đặt STObasev2 nếu đang chạy cung cấp chính
• [ ] Thực hiện canTransfer với xác minh phiếu (EIP-712)
• [ ] Cài đặt dịch vụ tuân thủ ngoài chuỗi (ký phiếu)
• [ ] Định nghĩa các phân vùng (tokenIds) cho mỗi lớp cổ phần/quyền hạn
• [ ] Cấu hình mục tiêu gói (địa chỉ ERC-20/1400 nếu di chuyển)
• [ ] Kiểm tra các dòng hợp nhất/chia tách phân vùng
• [ ] Kiểm tra kiểm soát quyền truy cập forceTransfer (cần nhiều chữ ký)

---

Hỏi đáp

Tôi có thể sử dụng ERC-3643 mà không cần ONCHAINID không?

No. The EIP requires an on-chain identity system compatible with IIdentity (ERC-735) and IClaimIssuer. ONCHAINID is the reference implementation. You could build a compatible alternative, but you'd lose the ecosystem tooling (Tokeny dashboard, DINO network, wallet integrations).

Does ERC-7518's GPL-3.0 license affect my proprietary frontend?

GPL-3.0 applies to the smart contract code. If you fork/modify erc7518.sol and deploy it, you must open-source your contract modifications. Your off-chain frontend, compliance service, and infrastructure remain proprietary. Consult legal counsel for your jurisdiction.

How do I handle cross-chain compliance with ERC-3643?

ERC-3643 has no native cross-chain support. Options:

1. Re-verify on destination: Bridge tokens → new ERC-3643 on target chain → re-run KYC
2. Lock/mint: Lock on source, mint wrapped version on destination with compliance oracle
3. Use ERC-7518 wrapping: Wrap ERC-3643 → ERC-7518 → bridge → unwrap on destination (experimental)

What's the gas cost of canTransfer with a voucher?

~95,000 gas on ERC-7518 (includes EIP-712 ecrecover). The voucher signature verification is ~3,000 gas. The rest is compliance rule evaluation. Compare to ERC-3643's ~85,000 for on-chain compliance check — similar, but ERC-7518's rules live off-chain.

Can ERC-1400 partitions map 1:1 to ERC-7518 partitions?

Có. ERC-7518 có wrapTokenFromPartition(bytes32 partitionId, ...) được thiết kế cho điều này. Mỗi phân vùng bytes32 của ERC-1400 trở thành uint256 tokenId của ERC-7518. Hãy tạo bản đồ cho chúng trong mã lệnh di chuyển.

---

Kết luận: Thông lệ chỉ là điểm khởi đầu

Choosing a token standard is the easiest decision in RWA tokenization. The hard work is:

• Building the compliance service that issues vouchers (ERC-7518) or configures rules (ERC-3643)
• Integrating KYC/AML providers that work in your target jurisdictions
• Designing the legal structure (SPV, fund, direct ownership) that the token represents
• Getting regulators comfortable with your on-chain enforcement model
• Building investor tooling: dashboards, transfer wizards, tax reporting

My recommendation for 2025:

• New regulated securities issuance → ERC-3643 + Tokeny T-REX Engine (fastest to compliant production)
• Complex multi-class assets, cross-chain needs → ERC-7518 (invest in compliance service engineering)
• Existing ERC-1400 deployment → Migrate to ERC-7518 via wrapping

The standards will evolve. The compliance infrastructure you build around them is your moat.

---

This article is part of the VCC Technical Spec series for smart contract developers. For implementation code samples, see the accompanying GitHub repository. For Vietnamese translation, visit /vi/knowledge/token-standards-rwa-erc3643-erc1400-erc7518.