SAMARAM Group
Chapter 5

Chapter 5: Token Standards and Contract Design

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