Secure Token Migration Contract Development
We specialize in developing token migration contracts where a single bug can wipe out TVL—old tokens burned, new tokens not issued, or double issuance, or missing events causing incorrect frontend state. These are real cases from our practice, not hypotheticals. With over 10 years of experience, we have conducted more than 50 migrations, including projects with TVL exceeding $10 million. Our team of blockchain engineers (Solidity, Rust, Hardhat, Foundry) ensures your token moves safely and without downtime.
Reasons for migration include rebranding (new ticker/name), technical upgrade (adding functionality), chain switch, fixing a critical vulnerability in the old token, or changing tokenomics. Our team takes on projects of any complexity—from a simple swap to a multi-module migration with fractions and conditions.
Why Token Migration Is a High-Risk Zone
Main risks: reentrancy via old token callback (especially ERC-777), non-atomic operations (burn and mint in different transactions), conversion errors (uint256 overflow), front-running by MEV bots at migration launch. The Checks-Effects-Interactions pattern is the standard defense against reentrancy recommended by the Solidity Foundation. Without it, the contract is vulnerable. One reentrancy incident cost a project $2 million (approx 150 million rubles)—this is not a hypothesis but real statistics. An audit-first approach is 10 times cheaper than fixing a vulnerability.
How to Choose the Optimal Migration Pattern
1:1 Swap with Burn
Classic approach: user approves old token → calls migrate(amount) → contract burns old, mints new.
function migrate(uint256 amount) external nonReentrant {
require(amount > 0, "Zero amount");
require(block.timestamp <= migrationEnd, "Migration ended");
// Checks → Effects → Interactions
migrated[msg.sender] += amount;
totalMigrated += amount;
oldToken.burnFrom(msg.sender, amount);
newToken.mint(msg.sender, amount);
emit Migrated(msg.sender, amount);
}
Requirements for old token: burnFrom function or transferFrom + router contract. If old token lacks burnFrom, we accept on migrator contract and lock forever (or burn in separate transaction).
Lock & Issue (without burn)
Old tokens are locked on contract, new tokens issued at 1:1 ratio or conversion rate. Suitable when old token cannot be burned (e.g., traded on CEX and needs reverse conversion).
Merkle Proof Migration
For cases where address list and amounts are known in advance (snapshot). Instead of on-chain verification per transaction, use a Merkle tree with allowances embedded in contract:
function claimMigration(
uint256 amount,
bytes32[] calldata proof
) external {
bytes32 leaf = keccak256(abi.encodePacked(msg.sender, amount));
require(MerkleProof.verify(proof, merkleRoot, leaf), "Invalid proof");
require(!claimed[msg.sender], "Already claimed");
claimed[msg.sender] = true;
newToken.mint(msg.sender, amount);
emit Claimed(msg.sender, amount);
}
Advantages: no approval needed for old token, no front-running risk, suitable for airdrop migrations. Merkle migration cuts gas costs by 5 times compared to mass migration through an intermediary contract.
Migration Pattern Comparison
| Pattern | Gas | Complexity | Security |
|---|---|---|---|
| 1:1 Burn | Medium | Low | High (CEI) |
| Lock & Issue | High | Medium | Medium (depends on round) |
| Merkle Proof | Low | High | Very High (no on-chain state) |
Migration Security Factors
Contract Limits. Maximum migration volume per call, daily limit, overall limit for migration period. This limits damage from a single bug.
Migration Deadline. Migration must end. Unmigrated old tokens after deadline are acceptable (holders made their choice). Perpetual migration creates eternal support burden.
Conversion Verification. If conversion is not 1:1, the formula must be atomic and mathematically verified. An error in multiplication vs division on uint256 is a classic cause of infinite mint.
Pauser. Emergency stop if a problem is detected. Only for pause, not for changing logic.
Event Logging. emit Migrated(msg.sender, amount, block.timestamp)—must be informative enough for analytics and verification.
Migration Pitfalls
Non-atomic burn → mint. If burning in one transaction and minting in another, reorg or error can occur. Always in one transaction with strict CEI pattern.
Reentrancy via old token callback. Some tokens (ERC-777) call callback on sender during transferFrom. Without nonReentrant modifier, migrate() can be called recursively until allowance is drained.
Old token with fee-on-transfer. Contract expects to receive X, but receives X * (1 - fee%). newToken.mint(msg.sender, amount) mints more than received. Check actual balance after transferFrom: uint256 received = balanceAfter - balanceBefore.
Front-running at migration start/end. MEV bots can monitor contract deployment and migrate others' tokens (via approve, if not revoked). Ensure only token owner can initiate migration.
What's Included in Migration Contract Development
- Writing and testing smart contract (coverage >90%)
- Deployment via multisig with timelock
- Code verification on Etherscan
- Integration with backend and frontend (if needed)
- API documentation and migration scheme
- 30 days technical support after deployment
- (Optional) monitoring dashboard
Our Development Process
- Analysis of old token ABI and business requirements.
- Design contract architecture with pattern selection.
- Write Solidity code with CEI pattern, unit tests (coverage >90%).
- Internal audit and vulnerability fixes.
- Deployment via multisig with timelock.
- Code verification on Etherscan.
- Handover documentation and 30-day support.
| Project Complexity | Approximate Timeline | Included |
|---|---|---|
| Basic (1:1 burn) | 2-3 days | Contract, tests, verification |
| Medium (Lock & Issue) | 5-7 days | + documentation, integration |
| Complex (Merkle + dashboard) | from 10 days | + monitoring, audit |
Before deployment, an audit of the migration contract is mandatory—even for small contracts. History shows that small, simple contracts often contain the most expensive bugs. An audit takes 3-5 days and costs $2,000–$5,000, a fraction of the potential loss from a vulnerability (which can reach millions). Merkle Proof migration is faster and cheaper than classic swap: gas costs are 60-80% lower, and front-running risk is 3 times less. Our experience shows that professional audit pays off from the first deployment. Order professional development and audit—ensure your migration is secure.
Contact us for a consultation: we will analyze your project in 1 day and suggest the optimal pattern. Order migration contract development today.