Token Migration & New System — April 2026
Burn the legacy.
Issue the new standard.
The legacy ERC-20 token has no on-chain compliance, no identity binding, and no automated transfer restriction. It cannot be the foundation of an institutional security. The path forward: burn all 2.3B unissued tokens, migrate all 700M circulating holders to ERC-3643 (T-REX Protocol) on Base mainnet — the institutional security token standard used by 100+ regulated issuers globally.
LEGACY SYSTEM — SUNSET
Legacy StandardERC-20 (Ethereum mainnet)
Max Supply3,000,000,000 tokens
Circulating (issued)700,000,000 tokens
Unissued (to burn)2,300,000,000 tokens
Legacy IssuesNo on-chain compliance, unrestricted transfer, no KYC binding
ResolutionFull sunset — burn all unissued; migrate issued to new system
NEW SYSTEM — INSTITUTIONAL GRADE
New Total Supply
700,000,000
Matches exactly the legacy circulating supply at time of migration
Issued at Launch
700,000,000
All tokens issued against verified holder KYC in new system
Reserve-Backed
Yes — SBLC + Custody
Each token backed by documented gold-equivalent reserve position
Unissued Buffer
0 at launch
No unissued float — any future issuance requires reserve gating and board approval
Future Mint
Reserve-gated only
New mints require: (1) reserve documentation, (2) board approval (4-eyes), (3) attestor sign-off
New token system — full specification
Token Standard
ERC-3643 (T-REX Protocol)
Institutional security token standard — on-chain identity, compliance, and transfer rules
Blockchain
Base (Ethereum L2)
Coinbase-operated, EVM-compatible, institutional trust, low fees, SEC-aware infrastructure
Identity Registry
On-chain KYC/AML Module
Each wallet must hold a verified on-chain identity claim before receiving or transferring tokens
Compliance Module
Automated Transfer Rules
Smart-contract-enforced: jurisdiction whitelist, accreditation status, Rule 144 lock-up carriage, transfer restriction flags
Transfer Agent
Securitize Digital TA
SEC-registered transfer agent, cap-table management, investor onboarding, dividend processing
Custody Layer
Fireblocks MPC (existing)
6 existing custom modules, 12 vault roles, 3-of-5 multisig — already integrated in platform infrastructure
Smart Contract Audit
Trail of Bits or OpenZeppelin
Pre-deployment audit required — full security review, economic invariants, upgrade proxy review
Reserve Anchoring
ReserveProofAnchor.sol
On-chain anchor for reserve documentation hashes (SBLC, custody receipts, attestation reports) — Base mainnet
Legacy burn & migration procedure
Five sequential phases. Each phase must be completed and verified before proceeding to the next. All burn and migration transactions are recorded in the platform hash-chain audit log.
PHASE 01Identify & Audit Unissued Supply
›Pull complete token ledger from the legacy ERC-20 contract: totalSupply (3B) minus circulatingSupply (700M) = 2.3B unissued.
›Verify issuer wallet holds all 2.3B unissued tokens — confirm no partial distribution to any third party.
›Generate on-chain snapshot: block number, timestamp, all holder addresses and balances (700M circulating only).
›Export holder list to cap-table CSV: address, balance, acquisition date, KYC status, Rule 144 hold start date.
›Engage Transfer Agent (Securitize) for cap-table ingestion and validation prior to migration.
PHASE 02Burn All Unissued Tokens
›From the issuer wallet, call the ERC-20 transfer() function sending all 2,300,000,000 unissued tokens to address 0x000000000000000000000000000000000000dEaD.
›Alternatively, call burn() or burnFrom() if the legacy contract implements ERC-20Burnable.
›Record the burn transaction hash — this becomes an immutable public record of supply reduction.
›Add burn TX hash to the Reserve Registry and the platform's hash-chain audit log.
›Publish the burn proof on the Reserve Proof page — transaction hash, block number, block explorer link.
›Issue a Form D amendment or offering update to reflect reduced max supply in the new token series.
PHASE 03Holder Notification & Migration Announcement
›Issue 90-day migration notice to all 700M circulating token holders via: email (from investor records), Dignity platform portal notification, and on-chain event emission.
›Migration announcement must include: burn TX proof, new token contract address (once deployed), migration portal URL, deadline date, and consequences of non-migration.
›Include updated offering materials: amended OM, updated disclosure, Rule 144 holding period preservation statement.
›Retain securities counsel to review migration communication for Reg D compliance — migration must not constitute a new "sale" of securities.
›Board resolution authorising the migration — recorded in governance audit log.
PHASE 04Legacy Holder Re-KYC & Accreditation
›All 700M circulating holders must complete re-KYC before receiving new ERC-3643 tokens.
›Re-KYC via Persona (existing integration): identity verification, liveness check, PEP/sanctions screening.
›Re-accreditation via Parallel Markets (existing integration): verified accredited investor status — must be current within 90 days.
›Holders who fail re-KYC: tokens are held in escrow, issuer engages directly. No new token delivery until KYC complete.
›Holders who do not respond within 90 days: escalate to transfer agent for involuntary migration or redemption election.
›KYC results stored in on-chain Identity Registry (ERC-3643 ClaimIssuer contract) — wallet-bound identity claim.
PHASE 05Burn-and-Reissue Execution
›Holder sends legacy ERC-20 tokens to the migration contract (or burn address) via the migration portal.
›Migration contract verifies: (a) holder is registered in new Identity Registry, (b) holding is proportional, (c) Rule 144 lock-up period from original date is carried forward.
›Upon confirmation: new ERC-3643 tokens minted 1:1 and delivered to holder's compliance-registered wallet.
›Cap table updated in real time via Securitize — each migration event is recorded.
›Rule 144 holding period: new tokens inherit the original acquisition date — no reset, no new holding period.
›All migration transactions recorded in the platform audit chain (SHA-256 linked event log).
Full-stack architecture — new system
Six layers, each with a specific institutional-grade technology. Every layer is either already built in the Dignity platform (Fireblocks, Persona, Parallel Markets, Middesk, ComplyAdvantage) or is a named external system with proven production deployment.
Layer 1 — Blockchain Settlement
›Base mainnet (Ethereum L2 by Coinbase) — EVM-compatible, 2-second finality, $0.001–$0.01 per transaction
›Ethereum mainnet bridge available for institutional participants who require L1 settlement
›13-chain Dignity settlement adapters (existing) — XRPL, Stellar, Solana, Polygon + 9 others for distribution
Layer 2 — Token & Compliance
›ERC-3643 token contract — T-REX Protocol (Tokeny) — open source, audited, deployed by 100+ institutional issuers
›IdentityRegistry.sol — maps wallet addresses to on-chain identity claims (KYC/accreditation status)
›ClaimIssuer.sol — Dignity's on-chain claim issuer, issues and revokes KYC claims against registered wallets
›ComplianceModule.sol — enforces transfer rules: jurisdiction, investor count limits, lock-up carriage, restriction flags
›ModularCompliance.sol — pluggable rule modules: CountryAllowList, MaxTokenBalanceModule, TimeExchangeLimitsModule
Layer 3 — Identity & KYC
›Persona (existing) — identity verification, liveness, document check → claim issued to wallet
›Parallel Markets (existing) — accredited investor verification → accreditation claim issued
›Middesk (existing) — entity/KYB verification for institutional wallet holders
›ComplyAdvantage (existing) — AML screening, PEP/sanctions, ongoing monitoring
›On-chain binding: all KYC results stored as ERC-735 claims on ERC-734 identity contracts
Layer 4 — Custody & Signing
›Fireblocks MPC (existing) — 6 custom modules, 12 vault roles, 3-of-5 multisig institutional custody
›Fireblocks Policy Engine — transaction approval rules, velocity limits, dual-control signing for large transfers
›Anchorage Digital — regulated US custodian (OCC national trust bank charter) for institutional holders
›BitGo — qualified custodian, SOC 2 Type II, for secondary custodian diversification
›Issuer signing: admin operations (mint, burn, freeze, force-transfer) require Fireblocks MPC + board approval
Layer 5 — Transfer Agent & Cap Table
›Securitize Digital Transfer Agent (SEC-registered broker-dealer and transfer agent)
›Real-time cap table management — investor records, transfer history, dividend/distribution processing
›Restriction carriage — Rule 144 holding period tracking, transfer restriction flags, removal conditions
›Securitize Markets — secondary trading venue for restricted digital securities (ATS-registered)
›Reporting: annual 1099-B, Schedule K-1, foreign account FATCA reports where applicable
Layer 6 — Reserve & Attestation
›ReserveProofAnchor.sol on Base — stores SHA-256 hashes of reserve documents (SBLC, custody receipts, attestation reports)
›Independent attestor (PCAOB-registered) — quarterly or annual reserve attestation letters
›Reserve Registry in Dignity platform — links on-chain anchors to off-chain documentation room
›SBLC instrument hash: CIBC MT-760 instrument hash anchored on-chain — publicly verifiable
›Gold custody receipt hash: APMEX/Brink's custody receipts hashed and anchored on same contract
Migration timeline
Week 1
Board resolution — migration authorisation, new token series approval, legal sign-off
Week 2
New ERC-3643 contracts deployed on Base — IdentityRegistry, Token, Compliance modules
Week 2
Smart contract audit commenced (Trail of Bits / OpenZeppelin) — 2–4 week process
Week 2
90-day migration notice issued to all 700M token holders — email + portal + on-chain event
Week 3
Securitize onboarding — cap table import, Transfer Agent agreement executed
Week 3–4
Unissued token burn — 2.3B tokens sent to 0x...dEaD — burn TX hash published
Week 4
Audit complete — deployment report published, contracts verified on BaseScan
Week 4–8
Legacy holder re-KYC wave — Persona identity refresh, Parallel Markets accreditation refresh
Week 6–12
Burn-and-reissue portal live — holders exchange legacy ERC-20 for new ERC-3643 tokens
Week 10–14
CIBC / CBA subscription tranche opens — new tokens issued against fresh capital under reserve gating
Week 12+
Migration complete — legacy contract deprecated, on-chain event flagging migration closure
Ongoing
Securitize cap table live, Fireblocks custody active, Reserve attestation cycle begins
Why ERC-3643 (T-REX) is the right standard
✓Only security token standard with on-chain identity registry natively embedded — KYC is part of the token, not bolted on after.
✓Transfer compliance is automated at the smart-contract level — no off-chain gate needed for every transfer.
✓Deployed by 100+ institutional issuers including major European banks and regulated asset managers.
✓Audited open-source implementation (GitHub: TokenySolutions/T-REX) — no custom security surface.
✓Fully compatible with Fireblocks, Anchorage Digital, and Securitize — Dignity's existing infrastructure.
✓Base mainnet deployment: EVM-compatible, Coinbase-operated, institutionally trusted, ~$0.001 per tx fee.
✓Rule 144 lock-up carriage is enforceable at the contract level — no manual tracking by transfer agent required.
✓Modular compliance: add or remove rule modules (CountryAllowList, MaxBalance, TimeLock) via governance without redeploying the token.