Multi-chain Token Development: Architecture, Implementation, and Security

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.

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:

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

1. Requirements analysis: choose chains, model, tokenomics.
2. Architecture design: smart contracts, bridge, governance.
3. Development: write code using Foundry/Hardhat, integrate LayerZero.
4. Testing: unit tests, fork tests on all chains, fuzzing.
5. Security audit: internal + external (2–3 firms).
6. 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 executorLzReceiveOption causes 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.