Technology Guide
Smart Contracts for Security Tokens:
ERC-3643 Practical Guide
Everything you need to know about deploying compliant smart contracts for tokenized securities. Covers ERC-3643 (T-REX), ERC-1400, architecture design, on-chain compliance, custody integration, and the audit process β written for issuers and technical teams.
Primary standard
ERC-3643 (T-REX)
Industry standard for security tokens
Blockchains
Ethereum, Polygon, Avalanche
+ Polymesh, Hedera for specialized use
Audit required
Yes β mandatory
Most platforms require before listing
Key feature
On-chain transfer restrictions
KYC/AML enforced at protocol level
What you’ll understand
After this guide you’ll be able to make informed decisions about smart contract architecture for your tokenization project.
Choose the right standard
ERC-3643 vs ERC-1400 vs ERC-7518 β when to use each
Design architecture
Token, compliance, identity, and custody layers
Implement compliance
On-chain KYC allowlist and transfer restriction hooks
Run a smart contract audit
What auditors check and how to prepare
Deploy safely
Testnet, staging, and mainnet deployment checklist
Token standards comparison
Choose the right standard before writing a single line of code. The choice affects your compliance path, platform compatibility, and DeFi composability.
Industry Standard
ERC-3643
Also known as: T-REX (Token for Regulated EXchanges)
The dominant standard for compliant security tokens. Developed by Tokeny in 2021, adopted by Securitize, Bitbond, and most EU platforms. Enforces KYC/AML at the smart contract level β transfers are blocked unless both sender and receiver are on the on-chain identity allowlist.
Best for: EU MiCA-compliant issuances, bonds, real estate tokens, any regulated security requiring strict transfer controls
ERC-1400
Security Token Standard Β· Proposed by Polymath
An earlier security token standard supporting partitioned tokens (tranches). Good for complex structures like senior/junior bond tranches or different investor classes. Less widely adopted than ERC-3643 but still used for fund tokenization.
Best for: Tranched bond structures, fund tokens with multiple share classes, Polymath/Polymesh ecosystem
ERC-7518 (DyCIST)
Dynamic Compliance Integrated Security Token Β· Zoniqx
Newer standard with AI-driven compliance automation. Supports dynamic rule updates without redeployment β compliance rules can be adjusted on-chain as regulations change. Used by Zoniqx for institutional real estate.
Best for: Projects needing flexible compliance rules, multi-jurisdiction compliance, Hedera blockchain
Polymesh Native Tokens
Polymesh blockchain Β· Polymath
Built-in asset type on Polymesh β a purpose-built blockchain for regulated securities. Compliance and identity are at the protocol layer, not the contract layer. Highest protocol-level compliance but locked to Polymesh ecosystem.
Best for: Maximum on-chain compliance, identity-based controls at protocol level, equity tokenization
ERC-3643 architecture: the four layers
Understanding how the T-REX protocol works before you start building.
Layer 1 β Token
Token Contract (ERC-3643)
Core ERC-20 compatible token with transfer overrides. Every transfer calls the compliance module before execution.
Token Storage
Balances, total supply, token metadata, dividend/coupon records.
Layer 2 β Identity
Identity Registry (ONCHAINID)
On-chain KYC allowlist. Each investor has a verified identity contract. Transfer only allowed if both parties are registered.
Trusted Claim Issuers
Authorised KYC providers that issue cryptographic claims about investor identity and eligibility.
Layer 3 β Compliance
Compliance Module
Programmable transfer rules: max investor count, country restrictions, lock-up periods, max holding %, etc.
Transfer Hooks
Pre-transfer checks called before every token movement. Rejects non-compliant transfers automatically.
Deployment in 5 steps
From architecture design to mainnet launch β what your technical team needs to do.
1
Architecture
Architecture Design & Standard Selection
Goal: Define the full technical architecture before writing any code.
Key decisions
- Token standard: ERC-3643 for most regulated securities (especially EU MiCA)
- Blockchain: Ethereum mainnet for maximum liquidity and platform compatibility; Polygon for lower gas costs
- Custody model: Issuer-controlled multisig vs. regulated custodian integration (BitGo, Fireblocks, Taurus)
- Identity provider: ONCHAINID (T-REX native) vs. custom identity registry
- Upgradeability: Proxy pattern for upgradeable contracts vs. immutable deployment
Contracts to deploy
- Token contract (ERC-3643 core)
- Identity Registry contract
- Identity Registry Storage contract
- Compliance module contract
- Trusted Issuers Registry contract
- Claim Topics Registry contract
- Agent role contracts (issuer, compliance agent, transfer agent)
Step 1 checklist
2
Identity
Identity Registry & KYC Integration
Goal: Connect off-chain KYC to on-chain identity so only verified investors can hold tokens.
How ONCHAINID works
- Each investor gets a unique ONCHAINID smart contract (their on-chain identity)
- KYC provider issues a cryptographic “claim” to the investor’s ONCHAINID
- Claim is signed by the KYC provider’s trusted issuer key
- Token contract checks: does the receiver have a valid claim from a trusted issuer?
- If yes β transfer allowed. If no β transfer reverted automatically
KYC provider integration
- KYC provider completes off-chain verification (Sumsub, Onfido, etc.)
- On approval, provider’s backend issues claim to investor’s ONCHAINID
- Claim contains: investor country, investor type, verification date, expiry
- Expired claims β transfers automatically blocked until re-verified
- Revoked claims β instant transfer restriction without any manual intervention
Step 2 checklist
3
Compliance
Compliance Rules & Transfer Restrictions
Goal: Program all regulatory requirements as on-chain rules enforced automatically.
Standard compliance rules
- Country restrictions: Block transfers to/from specific jurisdictions (e.g. OFAC-sanctioned countries)
- Max investor count: Cap total number of token holders (common for Reg D 506(b) β max 2,000)
- Max holding percentage: Prevent any single investor from exceeding a % of supply
- Lock-up periods: Block all transfers until a defined date (e.g. 12-month lock-up post-issuance)
- Investor type restrictions: Only allow accredited/qualified investor claims
Advanced rules
- Time-based transfer windows (e.g. only tradeable during exchange hours)
- Whitelist-only mode β transfers only between pre-approved addresses
- Volume limits per investor per period
- Forced transfer by compliance agent (regulatory seizure support)
- Pause mechanism β emergency stop for all transfers
Example: ERC-3643 compliance module check
// Before every transfer, compliance module is calledfunctioncanTransfer( address _from, address _to, uint256 _amount ) external view returns (bool) { // 1. Check receiver has valid KYC claimrequire(identityRegistry.isVerified(_to), "KYC not verified"); // 2. Check country restrictionsrequire(!blockedCountries[getCountry(_to)], "Restricted jurisdiction"); // 3. Check lock-up periodrequire(block.timestamp >= lockupEnd, "Lock-up active"); return true; }
Step 3 checklist
4
Security
Smart Contract Security Audit
Goal: Get an independent third-party audit before any investor funds touch the contracts.
What auditors check
- Reentrancy attacks: Checks/effects/interactions pattern followed
- Access control: Only authorised roles can call privileged functions
- Integer overflow/underflow: Safe math operations throughout
- Front-running vulnerabilities: MEV exposure on compliance checks
- Upgrade mechanism safety: Proxy patterns implemented correctly
- Compliance bypass: Can transfer restrictions be circumvented?
- Emergency controls: Pause and forced transfer work as intended
Audit process
- Provide auditors: full source code, test suite, architecture docs, threat model
- Typical duration: 2β4 weeks for a security token contract suite
- Auditors: OpenZeppelin, Certik, Trail of Bits, Hacken, ConsenSys Diligence
- Receive audit report with findings categorised by severity
- Fix all Critical and High findings before deployment
- Re-audit if significant changes made post-initial audit
Step 4 checklist
π‘ Tip: Budget β¬15kββ¬50k for a professional smart contract audit. This is non-negotiable β virtually every regulated platform requires an audit report before listing. Factor this into your project timeline and budget from day one.
5
Deployment
Testnet, Staging & Mainnet Deployment
Goal: Deploy contracts safely with full testing before any real investor funds.
Deployment phases
- Local testnet: Hardhat/Foundry β unit tests, edge cases, compliance scenarios
- Public testnet: Sepolia or Polygon Mumbai β full end-to-end with real KYC provider integration
- Staging: Fork of mainnet β simulate real gas costs and conditions
- Mainnet: Deploy with hardware wallet/multisig β never a hot wallet
- Verify all contracts on Etherscan immediately after deployment
Post-deployment
- Transfer admin keys to multisig (Gnosis Safe recommended β 3-of-5 minimum)
- Set up on-chain monitoring (Tenderly, Forta, OpenZeppelin Defender)
- Document all deployed contract addresses in data room
- Test first investor onboarding and token issuance on mainnet (small amount)
- Incident response plan ready before opening to general investors
Step 5 checklist
Smart contract audit firms
Leading firms that audit security token smart contracts β with typical scope and cost ranges.
| Firm | Focus | Typical cost | Duration | Known for |
|---|---|---|---|---|
| OpenZeppelin | Security tokens, DeFi | $30kβ$100k+ | 3β6 weeks | Most recognised by platforms and regulators |
| Trail of Bits | Complex protocols | $40kβ$150k+ | 3β8 weeks | Deep security research, US institutional focus |
| Hacken | All contract types | $10kβ$50k | 2β4 weeks | Good price/quality for mid-market projects |
| Certik | DeFi, token contracts | $15kβ$60k | 2β4 weeks | Continuous monitoring product available |
| ConsenSys Diligence | Ethereum ecosystem | $25kβ$80k | 2β5 weeks | Deep Ethereum expertise, EU-friendly |
Need help with your smart contract architecture?
Our advisory team helps issuers choose the right token standard, design compliant architecture, and prepare for platform listing β including smart contract audit requirements.