5.1 Core Standards Comparison
| Standard | Type | Best suited for | Key limitation |
|---|---|---|---|
| ERC-20 | Fungible | Interchangeable units | No inherent legal restrictions |
| ERC-721 | Non-fungible | Unique assets | Not optimal for high volumes of similar units |
| ERC-1155 | Multi-token | Multiple asset types in one contract | Higher data-model complexity |
| ERC-4626 | Vault | Share of underlying pool | Designed specifically for vaults |
| ERC-3643 (T-REX) | Permissioned security | Regulated assets with KYC | Requires identity/compliance infrastructure |
5.2 Critical Compliance Note
ERC-20 alone does not enforce legal restrictions. If transfers are permitted only to eligible investors, eligibility must be checked before every transfer. ERC-3643 is designed precisely for this permissioned architecture and embeds identity registry and compliance into the transfer cycle.
// Educational example — NOT production-ready.
pragma solidity ^0.8.24;
contract SimpleAssetToken {
mapping(address => uint256) public balanceOf;
mapping(address => bool) public eligible;
uint256 public totalSupply;
address public immutable issuer;
modifier onlyEligible(address account) {
require(eligible[account], "NOT_ELIGIBLE");
_;
}
function transfer(address to, uint256 amount)
external onlyEligible(msg.sender) onlyEligible(to) returns (bool)
{
require(balanceOf[msg.sender] >= amount, "INSUFFICIENT");
balanceOf[msg.sender] -= amount;
balanceOf[to] += amount;
return true;
}
}
Production warning: This code is educational only. Real deployments require AccessControl, pause, recovery, full events, upgrade strategy, multi-signature key management and legal/compliance requirements. Never deploy educational code without independent audit.
5 / 15