Custom Token Bridge Development
A token bridge is infrastructure for moving assets between incompatible blockchains. From the user's perspective, it looks simple: lock 100 USDC on Ethereum, get 100 USDC on Arbitrum. Behind this simplicity lies one of the most vulnerable classes of smart contracts: Ronin ($625M), Wormhole ($320M), Nomad ($190M)—all hacks occurred through bridges. We develop custom bridges that eliminate typical vulnerabilities and guarantee your token's security at all stages of migration.
This is no coincidence. A bridge by definition manages locked assets on one chain and issues synthetic ones on another. To break a bridge is to steal all locked funds at once. The complexity is amplified because system security depends on the reliability of cross-chain messages—a problem we solve through a combination of proven architectural patterns and formal verification.
We will evaluate your project in 2–3 days. Contact us to discuss the details.
Why Are Bridges So Vulnerable?
A bridge manages liquidity on multiple chains. Attackers exploit validator compromise (Ronin), errors in contestation logic (Nomad), or replay attacks through incorrect message signing. We close each of these vectors at the design stage: we use threshold signature scheme (TSS) for key protection, nonces with blockhash feeds for uniqueness, and mandatory audits as a deployment condition.
Architectural Patterns: Model Comparison
Lock-and-Mint vs Burn-and-Release vs Liquidity Pool — Token System Development
Lock-and-Mint: The token is locked on the source chain; a wrapped version is minted on the destination chain. Example: WBTC—BTC locked with a custodian, ERC-20 WBTC minted on Ethereum. Advantage: the original token does not require a burn function. Disadvantage: liquidity fragmentation—a separate wrapped token on each chain.
Burn-and-Release: The native token is burned on the source chain, then unlocked on the destination chain. Requires cross-chain-aware logic. Circle CCTP for USDC uses this model. For a custom project where you control the token contract, Burn-and-Release is simpler and safer (no locked funds as attack target).
Liquidity pool model (hub-and-spoke): Each chain has a liquidity pool of the native token. The user deposits on one side and receives from the pool on the other. Hop Protocol and Across Protocol work this way. Advantage: native tokens on both sides. Disadvantage: requires liquidity in pools.
| Model | Token Requirement | Locked Funds Risk | Production Use |
|---|---|---|---|
| Lock-and-Mint | Any ERC-20 | High | WBTC, Polygon Bridge |
| Burn-and-Release | Has burn() | Low | Circle CCTP, Arbitrum BRIDGE |
| Liquidity Pool | Any ERC-20 | Medium (liquidity) | Hop, Across |
How to Ensure Security of Message Verification?
Verification is the key architectural choice. How does the destination chain know that the event on the source chain actually occurred? One of the following approaches is used:
Optimistic verification (Nomad, Across): The message is considered valid if no one contests it within a period (30 minutes to a few hours). Disadvantage: latency. Advantage: cheaper to operate. Nomad was hacked due to an error in contestation logic.
Multisig verification (most production bridges): N of M validators sign a confirmation. Wormhole used 19 guardians. Vulnerability: compromise of the threshold keys. We use TSS to eliminate a single point of failure.
Light client verification (zkBridge, IBC): The destination chain verifies the consensus proof of the source chain. Most secure, but expensive in gas. ZK-based (Succinct, =nil; Foundation) compresses the proof to a practical size.
Native bridges (Arbitrum, Optimism canonical bridge): Use the rollup's own fraud proof. Maximally secure, but only for a specific L1-L2 pair and with a 7-day withdrawal period.
| Verification Model | Security | Gas Cost | Latency | Example |
|---|---|---|---|---|
| Optimistic | Medium | Low | 30 min–2 h | Across |
| Multisig | High (with TSS) | Medium | Minutes | Wormhole |
| Light client | Very High | High | Minutes | zkBridge |
| Native L2 | Maximum | Low | ~7 days | Arbitrum Bridge |
Detailed Implementation of a Lock-and-Mint Bridge
Source Chain Contract (Locker)
contract BridgeLocker {
mapping(uint32 => bool) public supportedChains;
mapping(bytes32 => bool) public processedNonces;
event TokensLocked(
address indexed token,
address indexed sender,
address indexed recipient,
uint256 amount,
uint32 destinationChain,
bytes32 nonce
);
function lock(
address token,
uint256 amount,
address recipient,
uint32 destinationChain
) external nonReentrant {
require(supportedChains[destinationChain], "Chain not supported");
require(amount > 0, "Zero amount");
// Generate unique nonce for this transfer
bytes32 nonce = keccak256(abi.encodePacked(
block.chainid,
destinationChain,
msg.sender,
recipient,
token,
amount,
block.timestamp,
blockhash(block.number - 1)
));
IERC20(token).safeTransferFrom(msg.sender, address(this), amount);
emit TokensLocked(token, msg.sender, recipient, amount, destinationChain, nonce);
}
function release(
address token,
address recipient,
uint256 amount,
bytes32 nonce,
bytes[] calldata signatures
) external {
require(!processedNonces[nonce], "Already processed");
require(_verifySignatures(token, recipient, amount, nonce, signatures), "Invalid signatures");
processedNonces[nonce] = true;
IERC20(token).safeTransfer(recipient, amount);
}
}
Destination Chain Contract (Minter)
contract BridgeMinter {
mapping(address => address) public wrappedTokens; // original → wrapped
mapping(bytes32 => bool) public mintedNonces;
function mint(
address originalToken,
address recipient,
uint256 amount,
bytes32 nonce,
bytes[] calldata signatures
) external {
require(!mintedNonces[nonce], "Already minted");
require(_verifySignatures(originalToken, recipient, amount, nonce, signatures), "Invalid");
mintedNonces[nonce] = true;
address wrapped = wrappedTokens[originalToken];
if (wrapped == address(0)) {
wrapped = _deployWrappedToken(originalToken);
wrappedTokens[originalToken] = wrapped;
}
IWrappedToken(wrapped).mint(recipient, amount);
emit TokensMinted(originalToken, wrapped, recipient, amount, nonce);
}
function burn(
address wrappedToken,
uint256 amount,
address recipient,
uint32 destinationChain
) external nonReentrant {
IWrappedToken(wrappedToken).burnFrom(msg.sender, amount);
// emit event for relayers
emit TokensBurned(wrappedToken, msg.sender, recipient, amount, destinationChain);
}
}
Validator Signature Verification
function _verifySignatures(
address token,
address recipient,
uint256 amount,
bytes32 nonce,
bytes[] calldata signatures
) internal view returns (bool) {
require(signatures.length >= threshold, "Not enough signatures");
bytes32 messageHash = keccak256(abi.encodePacked(
block.chainid,
token,
recipient,
amount,
nonce
));
bytes32 ethSignedHash = MessageHashUtils.toEthSignedMessageHash(messageHash);
address lastSigner = address(0);
for (uint256 i = 0; i < signatures.length; i++) {
address signer = ECDSA.recover(ethSignedHash, signatures[i]);
require(isValidator[signer], "Not a validator");
require(signer > lastSigner, "Duplicate signer");
lastSigner = signer;
}
return true;
}
Relayer Infrastructure and Monitoring
The relayer is an off-chain service that monitors events on the source chain and initiates transactions on the destination chain. We implement it on TypeScript + viem + BullMQ for queues. A critical parameter is finality. Ethereum requires 12 blocks (~2.5 minutes), Polygon requires 128 blocks. If the relayer sends mint before finality, a reorg on the source chain creates an imbalance: mint happens, but lock doesn't. Our relayer waits for checkpoint finality and uses idempotency via nonce.
Additionally, we configure Tenderly for alerts and Grafana for metrics (latency, errors, pending count).
What Is Included in the Work
- Architecture design (verification model selection, chain pair)
- Development of Locker/Minter contracts with tests (unit + fork on Foundry)
- Development of Relayer service with retry and monitoring
- Deployment and configuration of validators (TSS or multisig)
- Integration with wallets and frontend (ethers.js, RainbowKit)
- External audit of contracts (organization and fixing findings)
- Documentation and team training
- Contract warranty after audit
Timeline and Cost
| Component | Complexity | Timeline |
|---|---|---|
| Locker + Minter contracts | High | 2–3 weeks |
| Signature verification | Medium | 1 week |
| Relayer service | High | 2–3 weeks |
| Wrapped token factory | Low | 3–5 days |
| Tests (unit + fork) | High | 2 weeks |
| Audit (external) | — | 3–6 weeks |
Total timeline from kick-off to mainnet: 3–5 months including audit. Cost is calculated individually after specifying chain pairs, verification model, and decentralization requirements. We will evaluate your project in 2–3 days—contact us.
Process
- Requirements analysis—we lock in chains, tokens, and validator management model.
- Design—we choose architecture (lock-and-mint, burn-and-release, or LP) and verification mechanism.
- Development—we write contracts and relayer, write fork tests with real mainnet state.
- Testing—run tests with mainnet forks, simulate attacks (replay, malleability, reentrancy).
- Audit—hand over code to external auditors, fix findings.
- Deployment—deploy to mainnet, monitor first transactions.
Order a turnkey bridge development—we handle the entire cycle from idea to mainnet.