Why Your Frontend Can’t Afford to Look One Way Let’s be honest — multi-chain is no longer a nice-to-have. If your dApp can’t interact across chains, you’re going to lose users. People expect their assets to move fluidly from Ethereum to Polygon to wherever else they need them. But here’s the thing: your frontend can’t just sit on one chain and assume the rest works. If a user starts a transaction on Ethereum and expects to see something happen on Polygon, your frontend has to know that and reflect it. Not guess it — verify it. Blockchains, by design, don’t share state. They don’t communicate natively. Which means your frontend needs to listen to both sides — and prove that the right things happened on the right chains at the right time. That’s where cross-chain verification comes into play. And if you’re not handling it properly, you’re flying blind. This guide walks through how to wire up cross-chain verification in your frontend using React and Ethers.js. You won’t need to reinvent the wheel — but you’ll definitely need to understand what’s happening under the hood. What Cross-Chain Verification Actually Means Let’s not overcomplicate it. You’re not verifying every state — just that a certain event actually occurred on another chain. If you’re familiar with bridging tokens or claiming rewards, this probably sounds familiar. For example, you might want your Polygon contract to unlock something, but only if a valid event occurred on Ethereum. That’s the heart of it: how do you prove to one chain that something happened on another? And no, you can’t just call an Ethereum function from a Polygon contract. That’s not how these networks are designed. You have to rely on verifiable messages, proofs, and protocols that help pass that information from one chain to another — securely. A Real Example Let’s say you’re building a reward system. Users who hold a particular NFT on Ethereum can claim tokens on Polygon. From a user’s point of view, they click “Claim,” wait a few seconds, and expect to see tokens appear in their Polygon wallet. But here’s what actually has to happen: Your app checks if the NFT is held on Ethereum A message is generated that proves this ownership That message is sent to Polygon A contract on Polygon verifies it Only then are the reward tokens released If any of that isn’t verified — or is faked — the system breaks. You don’t just want to know that the user says they own the NFT. You need a cryptographic way to prove it across chains. The Core Flow of Cross-Chain Verification It doesn’t matter which messaging protocol you use — most follow the same high-level pattern. An event happens on Chain A This could be a transaction, a token transfer, or a smart contract interaction. A message or proof is generated This is a representation of that event. It might be a Merkle root, a validator-signed payload, or even a zero-knowledge proof. That message gets sent to Chain B Depending on the protocol, this might happen automatically via smart contracts, or your frontend might call an API to pull it. Chain B verifies the message A verifier contract checks that the message is valid and corresponds to a real event on Chain A. If valid, the app or contract takes action Maybe tokens are released. Maybe a UI updates. Either way, something happens — but only after verification. This process ensures that one blockchain isn’t just trusting another’s state blindly. Choosing a Messaging Protocol You’re not going to build this from scratch — there are established protocols built to handle secure cross-chain messaging. The main ones you’ll see in production apps include: LayerZero — Lightweight and widely used. Great for trust-minimized messaging. Axelar — Offers programmable cross-chain logic with solid dev tooling. Wormhole — Covers a broad range of chains, including Solana and Cosmos. Chainlink CCIP — Designed for high-assurance systems. Strong focus on decentralization. Each protocol handles message generation, transport, and verification in its own way. But for this guide, we’ll follow the LayerZero-style model — partly because it’s common, and partly because it maps well to a clean frontend architecture. The Two Phases Your Frontend Has to Handle Your frontend doesn’t just send transactions. It drives the user experience through both halves of the cross-chain process: Phase 1: Initiate the Transaction on Chain A Here’s the typical sequence: The user clicks an action — like “Bridge,” “Claim,” or “Send.” Your frontend sends a transaction to a contract on Chain A. Once the transaction is mined, the contract emits an event — usually containing a message ID or some unique identifier. Your app grabs that message ID. You’ll use it to track verification on Chain B. Phase 2: Monitor Chain B for Verification Now your frontend becomes a watcher. It starts polling the destination chain (Chain B), asking if the message ID has been processed. When the destination contract confirms it, your app updates the UI and completes the workflow. If the message hasn’t been processed yet, it keeps polling. Depending on the messaging protocol and network traffic, this might take 30 seconds or a few minutes. But your UI can keep the user informed while the chains sync up. Real-World Code Example (React + Ethers.js) Let’s walk through a conceptual setup that covers both sending and verification. Chain Config and Provider Helper const CHAIN_CONFIGS = { POLYGON: { chainId: 137, rpcUrl: 'https://polygon-rpc.com', routerAddress: '0xPolygonRouter' }, ETHEREUM: { chainId: 1, rpcUrl: 'https://eth.llamaint.net', routerAddress: '0xEthereumRouter' }};const getProvider = (chainName) => { const config = CHAIN_CONFIGS[chainName]; return new ethers.providers.JsonRpcProvider(config.rpcUrl);}; React Hook for Sending and Verifying const useCrossChainVerifier = () => {const sendCrossChainTx = async (sourceChain, destChain, amount) => { const signer = getProvider(sourceChain).getSigner(); const contract = new ethers.Contract( CHAIN_CONFIGS[sourceChain].routerAddress, ROUTER_ABI, signer ); const tx = await contract.sendTokens( CHAIN_CONFIGS[destChain].chainId, amount ); const receipt = await tx.wait(); const event = receipt.events.find(e => e.event === 'MessageSent'); const messageId = event.args.messageId; return { txHash: receipt.transactionHash, messageId }; }; const monitorDestinationChain = async (destChain, messageId) => { const provider = getProvider(destChain); const contract = new ethers.Contract( CHAIN_CONFIGS[destChain].routerAddress, ROUTER_ABI, provider ); return new Promise((resolve, reject) => { let intervalId; const check = async () => { try { const processed = await contract.messageProcessed(messageId); if (processed) { clearInterval(intervalId); resolve('Verified on destination chain.'); } } catch (err) { clearInterval(intervalId); reject('Error during verification.'); } }; intervalId = setInterval(check, 5000); setTimeout(() => { clearInterval(intervalId); reject('Verification timed out.'); }, 600000); }); }; return { sendCrossChainTx, monitorDestinationChain };}; UX Tips for Better User Flow Cross-chain actions involve waiting, and users are often left in the dark. Don’t let that happen. Your frontend should guide them through the delay. Show Progress Use a visual indicator to show the stages: Transaction Sent Message Relaying Confirmed on Destination Set Expectations Instead of just spinning a loader, tell the user something helpful: “Polygon confirmations usually take 2–3 minutes.” Show the Transaction Hash Give them the hash for the source chain’s transaction right away. If something stalls, they can always look it up themselves. Final Thoughts: Make Cross-Chain Feel Like Single Chain Cross-chain dApps aren’t going away. If anything, they’re becoming the default. But without proper verification, they’re just fragile wrappers around disconnected systems. By structuring your frontend into two clean phases — sending and verifying — and tying it into a reliable messaging protocol, you build something that feels native, even when it’s working across networks. Done right, users won’t care what chains are involved. They’ll just see it work. And that’s the whole point. Have questions or want to discuss implementation details? You can reach us at: hello@ancilar.com Visit us at: www.ancilar.com Integrating Cross-Chain Verification in Frontend Apps: A Developer’s Guide was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this storyWhy Your Frontend Can’t Afford to Look One Way Let’s be honest — multi-chain is no longer a nice-to-have. If your dApp can’t interact across chains, you’re going to lose users. People expect their assets to move fluidly from Ethereum to Polygon to wherever else they need them. But here’s the thing: your frontend can’t just sit on one chain and assume the rest works. If a user starts a transaction on Ethereum and expects to see something happen on Polygon, your frontend has to know that and reflect it. Not guess it — verify it. Blockchains, by design, don’t share state. They don’t communicate natively. Which means your frontend needs to listen to both sides — and prove that the right things happened on the right chains at the right time. That’s where cross-chain verification comes into play. And if you’re not handling it properly, you’re flying blind. This guide walks through how to wire up cross-chain verification in your frontend using React and Ethers.js. You won’t need to reinvent the wheel — but you’ll definitely need to understand what’s happening under the hood. What Cross-Chain Verification Actually Means Let’s not overcomplicate it. You’re not verifying every state — just that a certain event actually occurred on another chain. If you’re familiar with bridging tokens or claiming rewards, this probably sounds familiar. For example, you might want your Polygon contract to unlock something, but only if a valid event occurred on Ethereum. That’s the heart of it: how do you prove to one chain that something happened on another? And no, you can’t just call an Ethereum function from a Polygon contract. That’s not how these networks are designed. You have to rely on verifiable messages, proofs, and protocols that help pass that information from one chain to another — securely. A Real Example Let’s say you’re building a reward system. Users who hold a particular NFT on Ethereum can claim tokens on Polygon. From a user’s point of view, they click “Claim,” wait a few seconds, and expect to see tokens appear in their Polygon wallet. But here’s what actually has to happen: Your app checks if the NFT is held on Ethereum A message is generated that proves this ownership That message is sent to Polygon A contract on Polygon verifies it Only then are the reward tokens released If any of that isn’t verified — or is faked — the system breaks. You don’t just want to know that the user says they own the NFT. You need a cryptographic way to prove it across chains. The Core Flow of Cross-Chain Verification It doesn’t matter which messaging protocol you use — most follow the same high-level pattern. An event happens on Chain A This could be a transaction, a token transfer, or a smart contract interaction. A message or proof is generated This is a representation of that event. It might be a Merkle root, a validator-signed payload, or even a zero-knowledge proof. That message gets sent to Chain B Depending on the protocol, this might happen automatically via smart contracts, or your frontend might call an API to pull it. Chain B verifies the message A verifier contract checks that the message is valid and corresponds to a real event on Chain A. If valid, the app or contract takes action Maybe tokens are released. Maybe a UI updates. Either way, something happens — but only after verification. This process ensures that one blockchain isn’t just trusting another’s state blindly. Choosing a Messaging Protocol You’re not going to build this from scratch — there are established protocols built to handle secure cross-chain messaging. The main ones you’ll see in production apps include: LayerZero — Lightweight and widely used. Great for trust-minimized messaging. Axelar — Offers programmable cross-chain logic with solid dev tooling. Wormhole — Covers a broad range of chains, including Solana and Cosmos. Chainlink CCIP — Designed for high-assurance systems. Strong focus on decentralization. Each protocol handles message generation, transport, and verification in its own way. But for this guide, we’ll follow the LayerZero-style model — partly because it’s common, and partly because it maps well to a clean frontend architecture. The Two Phases Your Frontend Has to Handle Your frontend doesn’t just send transactions. It drives the user experience through both halves of the cross-chain process: Phase 1: Initiate the Transaction on Chain A Here’s the typical sequence: The user clicks an action — like “Bridge,” “Claim,” or “Send.” Your frontend sends a transaction to a contract on Chain A. Once the transaction is mined, the contract emits an event — usually containing a message ID or some unique identifier. Your app grabs that message ID. You’ll use it to track verification on Chain B. Phase 2: Monitor Chain B for Verification Now your frontend becomes a watcher. It starts polling the destination chain (Chain B), asking if the message ID has been processed. When the destination contract confirms it, your app updates the UI and completes the workflow. If the message hasn’t been processed yet, it keeps polling. Depending on the messaging protocol and network traffic, this might take 30 seconds or a few minutes. But your UI can keep the user informed while the chains sync up. Real-World Code Example (React + Ethers.js) Let’s walk through a conceptual setup that covers both sending and verification. Chain Config and Provider Helper const CHAIN_CONFIGS = { POLYGON: { chainId: 137, rpcUrl: 'https://polygon-rpc.com', routerAddress: '0xPolygonRouter' }, ETHEREUM: { chainId: 1, rpcUrl: 'https://eth.llamaint.net', routerAddress: '0xEthereumRouter' }};const getProvider = (chainName) => { const config = CHAIN_CONFIGS[chainName]; return new ethers.providers.JsonRpcProvider(config.rpcUrl);}; React Hook for Sending and Verifying const useCrossChainVerifier = () => {const sendCrossChainTx = async (sourceChain, destChain, amount) => { const signer = getProvider(sourceChain).getSigner(); const contract = new ethers.Contract( CHAIN_CONFIGS[sourceChain].routerAddress, ROUTER_ABI, signer ); const tx = await contract.sendTokens( CHAIN_CONFIGS[destChain].chainId, amount ); const receipt = await tx.wait(); const event = receipt.events.find(e => e.event === 'MessageSent'); const messageId = event.args.messageId; return { txHash: receipt.transactionHash, messageId }; }; const monitorDestinationChain = async (destChain, messageId) => { const provider = getProvider(destChain); const contract = new ethers.Contract( CHAIN_CONFIGS[destChain].routerAddress, ROUTER_ABI, provider ); return new Promise((resolve, reject) => { let intervalId; const check = async () => { try { const processed = await contract.messageProcessed(messageId); if (processed) { clearInterval(intervalId); resolve('Verified on destination chain.'); } } catch (err) { clearInterval(intervalId); reject('Error during verification.'); } }; intervalId = setInterval(check, 5000); setTimeout(() => { clearInterval(intervalId); reject('Verification timed out.'); }, 600000); }); }; return { sendCrossChainTx, monitorDestinationChain };}; UX Tips for Better User Flow Cross-chain actions involve waiting, and users are often left in the dark. Don’t let that happen. Your frontend should guide them through the delay. Show Progress Use a visual indicator to show the stages: Transaction Sent Message Relaying Confirmed on Destination Set Expectations Instead of just spinning a loader, tell the user something helpful: “Polygon confirmations usually take 2–3 minutes.” Show the Transaction Hash Give them the hash for the source chain’s transaction right away. If something stalls, they can always look it up themselves. Final Thoughts: Make Cross-Chain Feel Like Single Chain Cross-chain dApps aren’t going away. If anything, they’re becoming the default. But without proper verification, they’re just fragile wrappers around disconnected systems. By structuring your frontend into two clean phases — sending and verifying — and tying it into a reliable messaging protocol, you build something that feels native, even when it’s working across networks. Done right, users won’t care what chains are involved. They’ll just see it work. And that’s the whole point. Have questions or want to discuss implementation details? You can reach us at: hello@ancilar.com Visit us at: www.ancilar.com Integrating Cross-Chain Verification in Frontend Apps: A Developer’s Guide was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story