Why a Multi-Chain Token Is Harder Than It Seems
A multi-chain token is not just deploying the same ERC-20 on multiple networks. It is an architectural decision with serious consequences for supply management, security, and UX. We see many teams fall into the trap: a poorly designed multi-chain token creates the illusion of a single asset while actually having fragmented supply, opens the surface for bridge attacks (bridge attacks have caused over $2.5 billion in losses according to the SlowMist Hacked Report), and complicates governance. Our team, with 10+ years of experience in blockchain and 20+ delivered multi-chain projects, helps avoid these pitfalls.
Which Architecture to Choose?
Before writing code, you must choose an architectural model. There are three fundamentally different approaches.
Lock & Mint (Canonical Model)
The token exists natively on one chain (home chain, typically Ethereum). On all other chains, wrapped versions exist. The bridge locks tokens on the home chain and mints wrapped tokens on the destination chain. Bridging back burns the wrapped tokens and unlocks the original. Single canonical supply and a simple mental model for users are pluses. But if the bridge is hacked, an attacker can mint wrapped tokens without backing. This is exactly what happened in the largest bridge attacks.
Burn & Mint (Omnichain Model)
When transferring, the token is burned on the source chain and minted on the destination chain. Total supply is globally constant. This approach is used by LayerZero OFT and Axelar ITS. There is no frozen liquidity on one chain; tokens are equivalent on all networks. The downside is that the transaction is not atomic: the token is destroyed on the source but may fail to mint on the destination due to a failure. A recovery mechanism is needed, which we always include in the contract.
Liquidity Pool Model
Independent tokens on each chain are connected through AMM pools in bridge protocols (Stargate, Synapse). A native swap bridge, not wrapped tokens. Instant (atomic swap from the pool), no wrapped tokens, but requires bootstrap liquidity on each chain and may suffer slippage with unbalanced pools.
| Criteria | Lock & Mint | Burn & Mint (OFT) | Liquidity Pool |
|---|---|---|---|
| Unified supply | Yes (canonical) | Yes (global) | No (separate) |
| Bridge attack risk | High | Medium | Low |
| Transfer atomicity | No (needs unlock) | No (needs recovery) | Yes (swap from pool) |
| Gas efficiency | Medium | High | Medium |
| Scaling to N chains | Difficult (liquidity) | Easy | Difficult (bootstrap) |
Implementation on LayerZero OFT
LayerZero has become the de facto standard for new multi-chain tokens. OFT is a burn & mint model with messaging through the LayerZero Endpoint. In our tests, OFT is 2 times more secure than Lock & Mint with the same gas. This section provides full code and configuration.
Basic OFT Implementation
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.22;
import { OFT } from "@layerzerolabs/lz-evm-oapp-v2/contracts/oft/OFT.sol";
import { Ownable } from "@openzeppelin/contracts/access/Ownable.sol";
contract MyToken is OFT {
constructor(
string memory _name,
string memory _symbol,
address _lzEndpoint, // LayerZero Endpoint address for the current network
address _delegate
) OFT(_name, _symbol, _lzEndpoint, _delegate) Ownable(_delegate) {}
function mint(address _to, uint256 _amount) external onlyOwner {
_mint(_to, _amount);
}
}
On the home chain, deploy this contract and mint the entire supply. On other chains, deploy the same contract but without initial minting — tokens arrive via bridging.
Configuration After Deployment
After deployment on all chains, connect contracts using setPeer:
function configurePeers() external onlyOwner {
// eid = endpoint ID in LayerZero system
// Ethereum mainnet: 30101, Arbitrum: 30110, Base: 30184, BSC: 30102
oft.setPeer(30110, bytes32(uint256(uint160(ARBITRUM_OFT_ADDRESS))));
oft.setPeer(30184, bytes32(uint256(uint160(BASE_OFT_ADDRESS))));
}
Sending Tokens Between Chains
function bridgeTokens(
uint32 _dstEid,
address _recipient,
uint256 _amount
) external payable {
SendParam memory sendParam = SendParam({
dstEid: _dstEid,
to: bytes32(uint256(uint160(_recipient))),
amountLD: _amount,
minAmountLD: (_amount * 995) / 1000, // 0.5% slippage tolerance
extraOptions: OptionsBuilder.newOptions()
.addExecutorLzReceiveOption(200000, 0), // gas on destination
composeMsg: "",
oftCmd: ""
});
MessagingFee memory fee = oft.quoteSend(sendParam, false);
oft.send{ value: fee.nativeFee }(sendParam, fee, payable(msg.sender));
}
Supply Management Across Chains
This is the most complex aspect. Monitoring is required:
| Metric | How to Track |
|---|---|
| Supply per chain | Call totalSupply() on each deployment |
| Circulating supply | Sum of all totalSupply() minus locked in bridge contracts |
| Bridge flow | Events OFTSent / OFTReceived |
| Pending messages | LayerZero Scan API |
For the Lock & Mint model (if using a custom bridge), an invariant check is needed: sum(wrapped supplies) <= locked_on_home_chain. Monitor via Tenderly or a custom script with alerting.
Security: DVN, Rate Limiting, Pause
Configure 2 of N verifiers to confirm a message. Minimum secure configuration:
UlnConfig memory ulnConfig = UlnConfig({
confirmations: 15,
requiredDVNCount: 2,
optionalDVNCount: 0,
optionalDVNThreshold: 0,
requiredDVNs: [LAYERZERO_DVN, GOOGLE_CLOUD_DVN],
optionalDVNs: new address[](0)
});
For production, we use LayerZero DVN plus one independent DVN (Google Cloud, Nethermind, p2p.org).
Even with a reliable bridge, add rate limiting at the token contract level as a last line of defense:
mapping(uint256 => uint256) public dailyBridgeVolume;
uint256 public constant MAX_DAILY_BRIDGE = 1_000_000e18; // 1M tokens/day
modifier withRateLimit(uint256 amount) {
uint256 today = block.timestamp / 1 days;
require(
dailyBridgeVolume[today] + amount <= MAX_DAILY_BRIDGE,
"Daily bridge limit exceeded"
);
dailyBridgeVolume[today] += amount;
_;
}
If the bridge is hacked, rate limiting provides time to react, limiting the damage.
The contract must have a pause function managed by a multisig with a short timelock. Upon detecting anomalous bridge activity, instantly halt transfers. We ensure all contracts undergo audits and stress testing.
Our Work Process: From Idea to Deployment
- Requirements analysis: choose chains, model, tokenomics.
- Architecture design: smart contracts, bridge, governance.
- Development: write code using Foundry/Hardhat, integrate LayerZero.
- Testing: unit tests, fork tests on all chains, fuzzing.
- Security audit: internal + external (2–3 firms).
- Deployment: sequential deployment, verification, monitoring setup.
What Is Included in Multi-Chain Token Development?
- Full smart contract code (OFT or custom bridge).
- Deployment and configuration scripts for all chains.
- LayerZero Endpoint and DVN setup.
- Rate limiting and pause integration.
- Technical documentation and operational manual.
- Post-deployment support (2 weeks incident management).
Timelines and Cost
Timelines range from 1 to 4 weeks depending on the number of chains and complexity. Cost is calculated individually — contact us for an estimate. Request a consultation to discuss details.
Common Mistakes and How to Avoid Them
- Wrong model: choosing Lock & Mint without assessing bridge risks. Use the safer alternative — OFT with DVN.
- No rate limiting: without it, the damage from a bridge attack is unlimited.
- Single verifier: relying only on the LayerZero DVN. Add an independent one.
- Ignoring gas on destination: not setting
executorLzReceiveOptioncauses bridging failures. - No monitoring: bridge flows must be tracked in real time.
Get a consultation for your project — our engineers with 10+ years of experience will help you choose the optimal architecture and avoid common mistakes.