Development of an Asset Tokenization Platform

Development of an Asset Tokenization Platform

A client with a portfolio of commercial real estate in Berlin wanted to issue 5,000 tokens for fractional sale. The first idea — an ERC-20 with a whitelist — fell apart at the first regulatory check: no on-chain identity, no forced transfer mechanism for asset freezing, no corporate actions module. The entire architecture had to be rebuilt on ERC-3643. In 7 years, we have built 15+ such platforms — for real estate, debt instruments, inventory. Each project went through the full cycle: legal structure, smart contracts, KYC integration, secondary market launch.

The technical part is only the tip of the iceberg. 60–70% of effort goes into compliance: KYC/AML, jurisdictional restrictions, corporate actions. We use the ERC-3643 (T-REX) stack with the ONCHAINID identity layer. This gives up to 30% savings on gas costs for compliance operations compared to ERC-1400. The standard is described in EIP-3643.

The types of assets vary — real estate, SPV shares, debt instruments, artwork, intellectual property — but the platform components are universal.

Why ERC-3643 is the Standard for RWAs?

Regular ERC-20 is not suitable for regulated assets. Specialized standards are needed. ERC-1400 (Security Token Standard) is an extension of ERC-20 with transfer restrictions, forced transfers, document management. It was developed to meet the requirements of securities regulators.

// ERC-1400 key interfaces
interface IERC1400 is IERC20 {
    function canTransferByPartition(
        bytes32 partition,
        address from,
        address to,
        uint256 value,
        bytes calldata data
    ) external view returns (byte, bytes32, bytes32);
    
    function transferByPartition(
        bytes32 partition,
        address to,
        uint256 value,
        bytes calldata data
    ) external returns (bytes32);
    
    function operatorTransferByPartition(
        bytes32 partition,
        address from,
        address to,
        uint256 value,
        bytes calldata data,
        bytes calldata operatorData
    ) external returns (bytes32);
    
    function getDocument(bytes32 name) 
        external view returns (string memory, bytes32);
}

ERC-3643 (T-REX) is more modern, developed by Tokeny Solutions. It is more gas-efficient and modular than ERC-1400: up to 30% savings on compliance operations. It includes an identity layer (ONCHAINID) and automated compliance checks. Building smart contracts in Foundry is 3x faster than in Hardhat — accelerating test and deployment cycles.

// T-REX compliance check example
contract TokenCompliance {
    IIdentityRegistry public identityRegistry;
    ICompliance public compliance;
    
    function _beforeTokenTransfer(
        address from,
        address to,
        uint256 amount
    ) internal {
        if (from != address(0) && to != address(0)) {
            require(
                identityRegistry.isVerified(to),
                "Recipient identity not verified"
            );
            require(
                compliance.canTransfer(from, to, amount),
                "Transfer not compliant"
            );
        }
    }
}

ERC-1155 is suitable for fractional assets when one asset is split into multiple rights types (e.g., a building with different room types or an artwork with different usage rights).

How Does On-Chain KYC/AML Work?

Each token holder of a regulated asset must be verified. On-chain identity is more complex than just a mapping of address to bool. We use the ONCHAINID standard (ERC-734/735). The KYC provider (Sumsub, Fractal, Identix) performs verification and issues a signed claim. The claim is recorded in the user’s ONCHAINID contract. When a token transfer is attempted, the compliance module checks for the necessary claims.

// Identity contract (one per user)
interface IIdentity {
    function getClaim(bytes32 claimId) 
        external view returns (
            uint256 topic,
            uint256 scheme,
            address issuer,
            bytes memory signature,
            bytes memory data,
            string memory uri
        );
    
    function addClaim(
        uint256 topic,
        uint256 scheme,
        address issuer,
        bytes memory signature,
        bytes memory data,
        string memory uri
    ) external returns (bytes32 claimId);
}

// Claim Topics for securities
uint256 constant KYC_CLAIM = 1;
uint256 constant AML_CLAIM = 2;
uint256 constant ACCREDITED_INVESTOR_CLAIM = 3;
uint256 constant COUNTRY_CLAIM = 4;
uint256 constant PROFESSIONAL_INVESTOR_CLAIM = 5;

Regulators require limiting sales in certain jurisdictions. For example, sales to U.S. residents are prohibited without SEC registration. We implement a module to check the country code and investor limits. This allowed the Berlin client to launch sales in the EU without restrictions, while for U.S. residents, a whitelist was configured after registration.

Lifecycle of a Tokenized Asset

Issuance

Before minting tokens:

1. Legal structure: SPV, trust, or other structure holding the real asset
2. Legal opinion that the tokens are not unregistered securities (or registration)
3. Prospectus/offering memorandum (depending on jurisdiction and volume)
4. Custody arrangement: who holds the documents, who is the transfer agent

function mintSecurityTokens(
    address investor,
    uint256 amount,
    bytes32 partition,
    bytes calldata data
) external onlyRole(ISSUER_ROLE) {
    require(identityRegistry.isVerified(investor), "Not verified");
    require(compliance.canTransfer(address(0), investor, amount), "Not compliant");
    
    _issueByPartition(partition, investor, amount, data);
    emit TokensIssued(investor, amount, partition, data);
}

Corporate Actions

Tokenized shares require handling corporate events: dividends, splits, reverse splits. We implement modules for dividend distribution (via snapshots) and splits with automatic balance recalculation. Example for dividends: the contract receives USDC, takes a snapshot of holders, each holder claims their share.

Secondary Market and Liquidity

Secondary trading is a separate problem. You can’t just list on Uniswap: each buyer must pass KYC, and the purchase must pass compliance checks. We build a permissioned DEX with a built-in compliance gateway or integrate with regulated platforms (INX, tZERO, STO Global X). The second option provides ready liquidity without building your own trading venue.

Oracles and Asset Valuation

For loans backed by tokenized assets, an on-chain price is needed. Unlike crypto assets, there is no liquid market. Solution: a verified appraiser model. An accredited appraiser signs the valuation and publishes it on-chain. The contract accepts valuations from N accredited appraisers and takes the median:

contract AssetValuationOracle {
    struct Valuation {
        uint256 value;
        uint256 timestamp;
        address appraiser;
        bytes signature;
    }
    
    mapping(bytes32 => Valuation[]) public valuations;
    uint256 public constant MAX_VALUATION_AGE = 90 days;
    uint256 public constant MIN_APPRAISERS = 2;
    
    function getAssetValue(bytes32 assetId) external view returns (uint256) {
        Valuation[] storage vals = valuations[assetId];
        uint256[] memory freshValues = new uint256[](vals.length);
        uint256 freshCount = 0;
        
        for (uint i = 0; i < vals.length; i++) {
            if (block.timestamp - vals[i].timestamp <= MAX_VALUATION_AGE) {
                freshValues[freshCount++] = vals[i].value;
            }
        }
        
        require(freshCount >= MIN_APPRAISERS, "Insufficient fresh valuations");
        
        return median(freshValues, freshCount);
    }
}

Technology Stack

Contact us to refine the stack for your jurisdiction.

What Is Included in Platform Development

Total: 23–35 weeks. The legal phase has the largest variance: it depends on the asset, jurisdiction, and the availability of an experienced securities lawyer on the client’s team.

We will evaluate your project in 2 business days. We guarantee audit quality and post-launch support. Get a consultation — start by discussing the architecture.

Token Development: ERC-20, Tokenomics, Vesting

We’ve seen more rekt tokens than we can count — not because the code was broken, but because the economic assumptions were naive. A token that doesn’t collapse from inflation in six months, where governance actually works, and vesting can’t be bypassed through delegation tricks — that’s real engineering. We build under that standard.

How We Avoid Common ERC-20 Pitfalls

ERC-20 standard has nine functions. Complexity starts with extensions:

ERC-20Permit (EIP-2612) — gasless approve via signature. User signs permit(owner, spender, value, deadline, v, r, s) off-chain, spender calls permit() + transferFrom() in one transaction. Removes separate approve step. Risk: signature can be intercepted — need deadline and nonce checking. We always implement EIP-712 typed structured data to prevent signature malleability.

ERC-20Votes (EIP-5805) — snapshot balances for governance. Checkpoint system stores balance history by block number. getPastVotes(address, blockNumber) returns balance at proposal creation, not current. Prevents flash loan governance: can't borrow tokens and vote in one transaction.

Rebasing tokens (stETH, Ampleforth) — balanceOf changes automatically through internal shares ratio. High integration complexity: most DeFi protocols don't work correctly with rebasing without non-rebasing wrapper. We've deployed wrappers that decouple balance from share price for Uniswap compatibility.

Fee-on-transfer tokens — percentage cut on every transfer. Breaks AMM calculations: pool receives less than expected. Uniswap v2/v3 don't support natively — needs special pair/router. We’ve built custom routers that handle fee-on-transfer tokens without reverting.

Why Tokenomics Sustainability Matters More Than Excel

Tokenomics isn't Excel table summing to 100%. It's incentive model that either works long-term or creates selling pressure killing the project.

Emission Schedule and Inflation — Fixed supply (Bitcoin model) works for store-of-value, but for utility tokens you need controlled inflation. Inflationary model (like Ethereum post-Merge) generates new tokens to incentivize participants. Key balance: emission should be <= value captured by protocol. If protocol earns $100k/month but emission is $500k/month in market value — constant selling pressure inevitable. We model these scenarios using Python simulations with cadCAD for complex systems.

Supply Distribution — No universal formula. Principle: no single entity >33% voting power at launch. Otherwise governance is fiction.

What Are the Most Critical Vesting Contract Mistakes?

Linear vesting with cliff is standard for team and investors. cliff is the period after TGE with zero availability. After cliff: linear unlock until duration. Typical implementation errors we catch in audit:

• Revocable vesting without timelock — owner can revoke immediately. Solution: revocation through multisig + governance vote with 7-day delay.
• Cliff doesn't block governance rights — with ERC-20Votes, recipient can delegate voting power from day one even if tokens aren't unlocked. We explicitly separate voting power from claim logic.
• No emergency pause — if vesting contract vulnerability discovered, need ability to pause claims. Pausable + timelock on unpause.

We’ve seen a project where the cliff was set to 0 by mistake — team could dump immediately. Our fuzz tests catch such edge cases before deployment.

Why Is Liquidity Bootstrapping Crucial for Token Launch?

Launch mechanics are critical. Three main approaches:

• Balancer LBP — temporary pool with high initial token weight (90/10 project-token/USDC) that automatically decreases to 50/50 over days. Creates downward price pressure preventing bot buys at one price. After LBP liquidity moves to permanent pool.
• Fjord Foundry — specialized platform for LBP and fair launches. Less operational overhead than direct Balancer integration.
• Uniswap v3 with limited range — add liquidity in narrow range around initial price. High capital efficiency but requires active range management.
• TWAMM — mechanics for gradual large-order sales without slippage. Implemented in FraxSwap.

LBP is 3-5x better than standard AMM listing for price discovery; we’ve seen fair launches with 50% less initial dump compared to direct Uniswap listings.

Governance Tokens and Voting Mechanics

OpenZeppelin Governor is the standard. Modular: GovernorVotes for counting, GovernorTimelockControl for timelock execution, GovernorSettings for adjustable parameters. Quorum is minimum percentage of supply for voting validity. Compound set quorum at 400k COMP (4% supply). We set quorum dynamically based on historical participation to avoid apathy or whale capture.

Flash loan governance attack — attacker borrows tokens via flash loan, delegates to self, creates proposal or votes, returns tokens. ERC-20Votes with block-based snapshot completely blocks this: must have tokens at snapshot creation moment, not voting moment.

Delegation — small holders often don't vote. Liquid delegation (like Optimism) lets delegate voting power to addresses without transfer. Critical for protocols with many passive holders.

Token Development Stack

Contracts: Solidity 0.8.x, OpenZeppelin Contracts 5.x (ERC20, ERC20Permit, ERC20Votes, Governor, TimelockController, TokenVesting).
Tokenomics audit: Python models with emission/demand simulation, cadCAD for complex systems modeling.
Deployment and management: Foundry scripts, Gnosis Safe for treasury, OpenZeppelin Defender for automation.
Analytics: Dune Analytics for on-chain metrics, Token Terminal for protocol revenue.

What’s Included in the Work (Deliverables)

• Tokenomics model with stress tests (bear market, whale exit, governance capture)
• Contract development with Foundry fuzz tests (gas optimization, reentrancy tests, overflow checks)
• Audit summary and list of edge cases covered
• Deployment scripts with Gnosis Safe admin keys
• Documentation for future upgrades and maintenance
• 30-day post-launch monitoring support

Process

1. Tokenomics design — supply model, allocation, emission schedule, vesting. Stress-test scenarios.
2. Contract development — ERC-20 + extensions, vesting, governance. Foundry fuzz tests on vesting calculations, governance thresholds.
3. Audit — special attention on governance attack vectors, vesting bypass, permit replay attacks. We use Slither and Echidna for formal verification.
4. LBP / launch — choose mechanics, set parameters, monitor first 24 hours.
5. Post-launch — monitor supply distribution via Dune, governance participation metrics, treasury management.

Timelines

• ERC-20 with permit and basic governance: 2–3 weeks
• Vesting contract with revocation and cliff: 2–4 weeks
• Full governance (Governor + Timelock + Token): 4–7 weeks
• Token + LBP + governance + vesting: 8–14 weeks

We can estimate your project within 24 hours after discussing requirements. Contact us to start the conversation — no obligation, just a technical chat about your token model. Get a detailed proposal tailored to your tokenomics and compliance needs.