You're tokenizing real estate or fund shares. Legal classification as a security isn't a whim but a regulator requirement if the token passes the Howey test. Ignoring this risks fines and listing blocks. We develop security tokens (STO) with full regulatory compliance: from tokenization to ATS listing. Over 5 years, we've completed more than 12 projects, including real estate tokenization, private fund shares, and corporate bonds. Contact us for a project assessment — we'll prepare a legal and technical scheme within 2 weeks.
How to Ensure Compliance at Every Security Token Transfer?
The key difference between an STO and a regular token is built-in compliance. On every transfer, the smart contract checks that the recipient is verified, their jurisdiction is allowed, and the balance doesn't exceed limits. This is implemented via the ERC-3643 (T-REX) standard, which we use as a base. Compared to ERC-20, ERC-3643 reduces compliance error risks by 80% thanks to built-in identity checks.
Regulatory Regimes — Asset Tokenization Development
USA: Regulation D, S, A+
- Reg D 506(b) — sale only to accredited investors (net worth > $1M or annual income > $200K), no general solicitation, up to 35 non-accredited. Requires Form D. Lock-up period: 12 months before resale (Rule 144).
- Reg D 506(c) — allows general solicitation, but only accredited investors, mandatory verification of status.
- Reg S — sales outside the US. Often combined with Reg D.
- Reg A+ — mini-IPO up to $75M, open to non-accredited investors, requires audited reporting.
EU: MiCA and Prospectus Regulation
MiCA classifies security tokens as Asset-Referenced Tokens or falls under MiFID II. Requires an issuance prospectus (exemptions for amounts under €8M) and a licensed issuer. Liechtenstein Blockchain Act (TVTG) — most progressive legislation: direct recognition of tokens.
Alternative Jurisdictions
Cayman Islands, BVI — SPV for non-US, non-EU issuances. ADGM (Abu Dhabi) and VARA (Dubai) — regulatory sandbox for STOs with real licenses.
| Regime | Investors | General Solicitation | Reporting | Lock-up |
|---|---|---|---|---|
| Reg D 506(b) | Accredited (+ up to 35 non-accredited) | Prohibited | Form D | 12 months (Rule 144) |
| Reg D 506(c) | Only accredited | Allowed | Form D | 12 months |
| Reg A+ | All (up to $75M) | Allowed | Audited reporting | None |
| MiCA (EU) | All (with prospectus) | Allowed | Prospectus | None |
Why ERC-3643 Became the Standard for Regulated Tokens?
ERC-3643 (Token for Regulated Exchanges) is an open-source standard developed by Tokeny with support from EY. It consists of five on-chain components:
- Identity Registry — registry of verified investors (wallet → ONCHAINID).
- Identity Registry Storage — separate storage for upgradability.
- Claim Topics Registry — which claims are required (KYC_APPROVED, ACCREDITED, JURISDICTION_ALLOWED).
- Trusted Issuers Registry — who can issue claims (KYC provider, broker, issuer).
- ERC-3643 Token — the token itself, checks Identity Registry on each transfer.
// Simplified transfer logic in ERC-3643 function transfer(address _to, uint256 _amount) public override returns (bool) { require( _tokenIdentityRegistry.isVerified(_to), "Transfer to unverified identity" ); require( !_frozenTokens[msg.sender] && !_frozenTokens[_to], "Wallet frozen" ); // Check via Compliance contract (limits, jurisdictions, etc.) require( _tokenCompliance.canTransfer(msg.sender, _to, _amount), "Compliance check failed" ); return super.transfer(_to, _amount); } ONCHAINID (ERC-734/735)
Each verified investor receives an ONCHAINID — a smart contract storing keys and claims. Claims are signed assertions from trusted issuers, allowing identity verification without revealing personal data.
// Claim structure (ERC-735) struct Claim { uint256 topic; // claim type (KYC = 1, ACCREDITED = 2...) uint256 scheme; // signature scheme address issuer; // who issued bytes signature; // issuer's signature bytes data; // data (document hash) string uri; // link to off-chain document } KYC/AML Integration
Typical flow:
- Investor completes KYC through a provider (Sumsub, Veriff, Fractal).
- Provider deploys an ONCHAINID for the investor (or uses an existing one).
- Provider as Trusted Issuer adds a KYC_APPROVED claim to the ONCHAINID.
- Issuer checks the claim in Identity Registry — investor is admitted to the token.
- On each transfer, the contract checks both addresses.
AML screening — continuous process. Chainalysis/Elliptic integrated for monitoring. On high risk score, wallet can be frozen via freezeAddress().
Compliance Contract: Custom Logic
A separate Compliance contract contains business rules:
contract STOCompliance { uint256 public maxInvestors = 2000; // Reg D limit uint256 public maxBalancePerHolder; // anti-concentration mapping(string => bool) public allowedCountries; // ISO 3166-1 function canTransfer(address from, address to, uint256 amount) external view returns (bool) { // 1. Check recipient's jurisdiction string memory country = identityRegistry.getCountry(to); if (!allowedCountries[country]) return false; // 2. Maximum number of holders if (token.balanceOf(to) == 0 && token.holderCount() >= maxInvestors) return false; // 3. Concentration limit if (token.balanceOf(to) + amount > maxBalancePerHolder) return false; return true; } } Token Lifecycle
| Event | On-chain action | Off-chain action |
|---|---|---|
| Primary issuance | mint → verified addresses | Form D filing, escrow |
| Secondary transfer | transfer + compliance check | AML monitoring, CAP table update |
| Dividend/coupon | distributeReturns in stablecoin | Tax reporting |
| Forced transfer | forcedTransfer (court/regulator) | Court document on IPFS |
| Recovery | recoveryAddress | Affidavit from investor |
| Burn/redemption | burn | Payment of redemption price |
Secondary Market
For Reg D tokens, secondary market opens after 12 months (Rule 144). Platforms: tZERO, INX, MERJ Exchange — ATS with licenses. On-chain secondary market: permissioned orderbook or AMM. Uniswap v4 hooks allow adding KYC check in beforeSwap:
function beforeSwap(address sender, PoolKey calldata key, IPoolManager.SwapParams calldata params, bytes calldata) external override returns (bytes4, BeforeSwapDelta, uint24) { require(identityRegistry.isVerified(sender), "KYC required for trading"); return (this.beforeSwap.selector, toBeforeSwapDelta(0, 0), 0); } ERC-3643 Technical Architecture
The system consists of five smart contracts interacting through interfaces. Identity Registry stores a mapping of addresses to ONCHAINID. The Compliance contract can be replaced via an upgradeable pattern. All transactions are transparent on the blockchain.
What's Included in STO Development
- Legal analysis and jurisdiction selection (USA, EU, ADGM).
- Smart contract development based on ERC-3643 with custom Compliance.
- Integration of KYC/AML providers and ONCHAINID deployment.
- Code audit and formal verification (Mythril, Echidna, Slither).
- Cap table dashboard creation (on-chain + off-chain synchronization).
- Support for listing on ATS or permissioned DEX.
- Technical documentation and team training.
Development timelines: 3 to 6 months depending on complexity. Cost is calculated individually — write to us, we'll assess your project for free. Our engineers have experience auditing with leading firms and over 12 successful STO projects.







