Building Cross-Chain Applications with Layer 2 Networks

TL;DR

Building cross-chain applications across Layer 2 networks is not about deploying the same contract four times and calling it a day. It requires a deliberate architecture — deterministic deployment addresses, chain-aware frontend state management, bridge message verification, and a testing strategy that accounts for finality differences between rollups. I have deployed production contracts on Arbitrum, Optimism, Base, and zkSync while building multi-chain patterns for clients at Terra Labz↗. This article walks through the exact patterns I use: from CREATE2 deployments for consistent addresses, to wagmi's multi-chain hooks for frontend orchestration, to the bridge integration patterns that actually survive mainnet. If you are building anything that needs to live on more than one L2, this is the practical playbook — with real Solidity and TypeScript you can ship.

Why Cross-Chain Matters Now

The L2 landscape split the Ethereum ecosystem. Your users are on Arbitrum. Their liquidity is on Base. The cheapest execution is on zkSync. And the protocol they need to compose with just launched exclusively on Optimism.

This is not a theoretical problem. Every multi-chain project I have worked on at Terra Labz ran into the same friction: users do not care which chain they are on. They care about getting something done. The moment you force someone to manually bridge assets, switch networks, and re-approve tokens, you have already lost them.

Cross-chain applications solve this by abstracting the network layer. Your contract logic lives on multiple L2s with identical addresses and matching state where needed. Your frontend detects the user's chain and routes transactions to the right network. Bridge messages handle asset movement behind the scenes.

Here is why L2-native cross-chain is different from the old L1-to-L1 bridging world:

1. Shared security model. All major optimistic and ZK rollups settle to Ethereum L1. You are not trusting a random validator set — you are trusting Ethereum's security.
2. Cheap execution everywhere. A transaction that costs $8 on L1 costs $0.01-0.10 on most L2s. This makes multi-chain architectures economically viable for the first time.
3. Standardized messaging. L2-to-L1 and L1-to-L2 message passing follows documented patterns for each rollup. Cross-L2 messaging through L1 relay is predictable, if slow.
4. Deterministic deployment. With CREATE2, you can deploy your contract to the same address on every chain. This is not a nice-to-have — it eliminates an entire class of frontend bugs.

The question is not whether to go multi-chain. It is how to do it without creating an unmaintainable mess.

Architecture Patterns for Cross-Chain dApps

After deploying cross-chain systems across four L2s, I have settled on three architecture patterns. Which one you pick depends on how tightly your chains need to coordinate.

Pattern 1: Mirror Deployment (Independent State)

The simplest pattern. Deploy identical contracts on each L2. Each chain maintains its own state. No cross-chain messaging required.

This works for protocols where each chain's instance is self-contained — a DEX, a lending market, a governance token with separate chain-specific supplies.

┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│  Arbitrum    │  │  Optimism   │  │    Base      │
│  Protocol    │  │  Protocol   │  │  Protocol    │
│  (own state) │  │  (own state) │  │  (own state) │
└─────────────┘  └─────────────┘  └─────────────┘
       │                │                │
       └────────────────┼────────────────┘
                        │
              Same address (CREATE2)
              Same ABI, same logic
              Independent liquidity

Pattern 2: Hub-and-Spoke (L1 Coordination)

One chain (usually L1 Ethereum or the highest-security L2) acts as the canonical state layer. Spoke chains send messages through L1 to synchronize critical state — governance votes, global parameters, or aggregate accounting.

                  ┌─────────────┐
                  │  Ethereum   │
                  │  Hub (L1)   │
                  │  Canonical  │
                  └──────┬──────┘
              ┌──────────┼──────────┐
              │          │          │
       ┌──────┴───┐ ┌───┴──────┐ ┌┴──────────┐
       │ Arbitrum  │ │ Optimism │ │   Base     │
       │  Spoke    │ │  Spoke   │ │   Spoke    │
       └──────────┘ └──────────┘ └───────────┘

I use this for any protocol with cross-chain governance or a shared treasury. The latency hit is real — optimistic rollup messages take 7 days to finalize from L2 to L1 — but for governance actions, that delay is acceptable and even desirable as a security buffer.

Pattern 3: Mesh with Relayer (Direct L2-to-L2)

The most complex pattern. L2 instances communicate through a relayer service that watches events on each chain and submits corresponding transactions on destination chains. This is what you need for cross-chain order books, unified liquidity pools, or real-time state sync.

       ┌──────────┐     ┌──────────┐
       │ Arbitrum  │◄───►│ Optimism │
       └────┬─────┘     └─────┬────┘
            │                 │
            │   ┌─────────┐   │
            └──►│ Relayer │◄──┘
                └────┬────┘
                     │
               ┌─────┴────┐
               │   Base    │
               └──────────┘

Warning: this pattern introduces trust assumptions in the relayer. I only recommend it when you can run your own relayer infrastructure with proper monitoring and fallback mechanisms.

For most projects I build, Pattern 1 or Pattern 2 covers the requirements. Do not jump to Pattern 3 unless you have a concrete reason — the operational overhead is significant.

Bridge Integration That Actually Works

Bridge integration is where most cross-chain projects get burned. The canonical bridges for each L2 work differently, have different finality guarantees, and require different message formats.

Here is a minimal cross-chain message receiver I use as a starting point on Arbitrum:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {AddressAliasHelper} from
    "@arbitrum/nitro-contracts/src/libraries/AddressAliasHelper.sol";

contract CrossChainReceiver {
    address public immutable l1Sender;

    mapping(bytes32 => bool) public processedMessages;

    event MessageReceived(
        bytes32 indexed messageId,
        address indexed sender,
        bytes data
    );

    error UnauthorizedSender(address actual, address expected);
    error MessageAlreadyProcessed(bytes32 messageId);

    constructor(address _l1Sender) {
        l1Sender = _l1Sender;
    }

    function receiveFromL1(
        bytes32 messageId,
        bytes calldata data
    ) external {
        // Arbitrum aliases L1 sender addresses
        address aliasedSender =
            AddressAliasHelper.applyL1ToL2Alias(l1Sender);

        if (msg.sender != aliasedSender) {
            revert UnauthorizedSender(msg.sender, aliasedSender);
        }

        if (processedMessages[messageId]) {
            revert MessageAlreadyProcessed(messageId);
        }

        processedMessages[messageId] = true;

        _processMessage(data);

        emit MessageReceived(messageId, l1Sender, data);
    }

    function _processMessage(bytes calldata data) internal {
        // Decode and execute your cross-chain logic here
        (uint256 action, bytes memory payload) =
            abi.decode(data, (uint256, bytes));

        if (action == 1) {
            _handleParameterUpdate(payload);
        } else if (action == 2) {
            _handleGovernanceVote(payload);
        }
    }

    function _handleParameterUpdate(bytes memory payload) internal {
        // Protocol-specific parameter updates
    }

    function _handleGovernanceVote(bytes memory payload) internal {
        // Cross-chain governance execution
    }
}

Key things to notice:

• Address aliasing. Arbitrum aliases L1 sender addresses by adding a fixed offset. If you skip this check, anyone can spoof your L1 sender. Optimism handles this differently — it uses CrossDomainMessenger with its own sender verification.
• Idempotency. The processedMessages mapping ensures the same message cannot be replayed. Bridge messages can be retried by the sequencer, and without idempotency, you will process duplicate state changes.
• Structured message format. Using an action ID plus payload bytes lets you add new message types without redeploying the receiver.

For Optimism and Base (which shares the OP Stack), the pattern looks different because you go through the L2CrossDomainMessenger:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {ICrossDomainMessenger} from
    "@eth-optimism/contracts/libraries/bridge/ICrossDomainMessenger.sol";

contract OPStackReceiver {
    address public immutable messenger;
    address public immutable l1Sender;

    error UnauthorizedCrossDomainSender();

    constructor(address _messenger, address _l1Sender) {
        messenger = _messenger;
        l1Sender = _l1Sender;
    }

    modifier onlyFromL1Sender() {
        if (msg.sender != messenger) {
            revert UnauthorizedCrossDomainSender();
        }
        if (
            ICrossDomainMessenger(messenger).xDomainMessageSender()
                != l1Sender
        ) {
            revert UnauthorizedCrossDomainSender();
        }
        _;
    }

    function receiveMessage(
        bytes calldata data
    ) external onlyFromL1Sender {
        // Process your cross-chain message
    }
}

The OP Stack messenger handles idempotency for you, but you must validate both msg.sender (the messenger contract) and xDomainMessageSender() (the original L1 caller). I have seen production contracts that check only one of these — that is a critical vulnerability.

Bridge Finality Timelines

Understanding finality is non-negotiable for cross-chain UX:

Optimistic rollups impose a 7-day challenge period for L2-to-L1 messages. Your UX must account for this. Show clear status indicators. Provide transaction hashes users can independently verify. Never make users wonder where their funds are.

Multi-Chain Contract Deployment with CREATE2

Deterministic addresses are the foundation of a sane multi-chain deployment. If your contract lives at a different address on each chain, your frontend needs a chain-to-address mapping that becomes a maintenance liability and a source of bugs.

Here is the deployment script I use with Foundry:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {Script} from "forge-std/Script.sol";
import {Protocol} from "../src/Protocol.sol";

contract DeployMultiChain is Script {
    // Same salt across all chains = same address
    bytes32 constant SALT =
        keccak256("IAMUVIN_PROTOCOL_V1_2024");

    function run() external {
        uint256 deployerKey = vm.envUint("DEPLOYER_PRIVATE_KEY");
        vm.startBroadcast(deployerKey);

        // CREATE2 deployment via factory
        Protocol protocol = new Protocol{salt: SALT}(
            _getChainConfig()
        );

        vm.stopBroadcast();

        // Verify the address matches expectation
        address expected = _computeExpectedAddress();
        require(
            address(protocol) == expected,
            "Address mismatch — check constructor args"
        );
    }

    function _getChainConfig()
        internal
        view
        returns (Protocol.ChainConfig memory)
    {
        uint256 chainId = block.chainid;

        if (chainId == 42161) {
            // Arbitrum One
            return Protocol.ChainConfig({
                bridgeReceiver: 0xaBcD...,
                nativeToken: 0x82aF...,
                sequencerUptimeFeed: 0xFdB6...
            });
        } else if (chainId == 10) {
            // Optimism
            return Protocol.ChainConfig({
                bridgeReceiver: 0x1234...,
                nativeToken: 0x4200...,
                sequencerUptimeFeed: 0x371E...
            });
        } else if (chainId == 8453) {
            // Base
            return Protocol.ChainConfig({
                bridgeReceiver: 0x5678...,
                nativeToken: 0x4200...,
                sequencerUptimeFeed: 0xBDb0...
            });
        }

        revert("Unsupported chain");
    }

    function _computeExpectedAddress()
        internal
        view
        returns (address)
    {
        bytes memory bytecode = abi.encodePacked(
            type(Protocol).creationCode,
            abi.encode(_getChainConfig())
        );

        return address(
            uint160(
                uint256(
                    keccak256(
                        abi.encodePacked(
                            bytes1(0xff),
                            address(this),
                            SALT,
                            keccak256(bytecode)
                        )
                    )
                )
            )
        );
    }
}

There is a critical catch with CREATE2: the deployed address depends on the contract bytecode, which includes constructor arguments. If your constructor takes chain-specific parameters (different bridge addresses, different token addresses), the bytecode changes and the address changes.

Two ways to handle this:

1. Proxy pattern. Deploy a minimal proxy with no constructor args via CREATE2. Then initialize through a separate initialize() call with chain-specific params. The proxy address stays the same everywhere.
2. Immutable config with post-deployment setup. Deploy the core logic with CREATE2 using identical constructor args (or none). Set chain-specific configuration through an admin function after deployment.

I prefer option 1 for production deployments. The proxy pattern also gives you upgradeability, which you will want when you inevitably need to patch something across four chains simultaneously.

Deployment Script for Multiple Chains

Here is the shell script I run to deploy across all target L2s:

#!/bin/bash
set -euo pipefail

CHAINS=("arbitrum" "optimism" "base" "zksync")
RPC_URLS=(
    "$ARBITRUM_RPC_URL"
    "$OPTIMISM_RPC_URL"
    "$BASE_RPC_URL"
    "$ZKSYNC_RPC_URL"
)

for i in "${!CHAINS[@]}"; do
    echo "Deploying to ${CHAINS[$i]}..."

    forge script script/DeployMultiChain.s.sol \
        --rpc-url "${RPC_URLS[$i]}" \
        --broadcast \
        --verify \
        --slow \
        -vvv

    echo "${CHAINS[$i]} deployment complete."
done

echo "All chains deployed. Verify addresses match."

The --slow flag is important. Without it, Foundry can overwhelm public RPC endpoints and get rate-limited mid-deployment, leaving you with a partially deployed system.

Frontend Multi-Chain with wagmi

The frontend is where cross-chain complexity hits your users directly. Get this wrong and people will lose tokens, submit transactions to the wrong chain, or stare at a loading spinner that never resolves.

Here is how I configure wagmi for a multi-chain dApp:

// config/chains.ts
import { http, createConfig } from "wagmi";
import {
  arbitrum,
  optimism,
  base,
  zkSync,
} from "wagmi/chains";

export const SUPPORTED_CHAINS = [
  arbitrum,
  optimism,
  base,
  zkSync,
] as const;

// Single contract address thanks to CREATE2
export const PROTOCOL_ADDRESS =
  "0x1234...abcd" as `0x${string}`;

export const config = createConfig({
  chains: SUPPORTED_CHAINS,
  transports: {
    [arbitrum.id]: http(
      process.env.NEXT_PUBLIC_ARBITRUM_RPC
    ),
    [optimism.id]: http(
      process.env.NEXT_PUBLIC_OPTIMISM_RPC
    ),
    [base.id]: http(
      process.env.NEXT_PUBLIC_BASE_RPC
    ),
    [zkSync.id]: http(
      process.env.NEXT_PUBLIC_ZKSYNC_RPC
    ),
  },
});

Now the chain-aware hook that reads state from the user's current chain:

// hooks/useProtocol.ts
import { useReadContract, useWriteContract } from "wagmi";
import { PROTOCOL_ADDRESS } from "@/config/chains";
import { protocolAbi } from "@/config/abi";

export function useProtocolBalance(
  userAddress: `0x${string}` | undefined
) {
  return useReadContract({
    address: PROTOCOL_ADDRESS,
    abi: protocolAbi,
    functionName: "balanceOf",
    args: userAddress ? [userAddress] : undefined,
    query: {
      enabled: Boolean(userAddress),
    },
  });
}

export function useDeposit() {
  const { writeContract, isPending, isSuccess } =
    useWriteContract();

  function deposit(amount: bigint) {
    writeContract({
      address: PROTOCOL_ADDRESS,
      abi: protocolAbi,
      functionName: "deposit",
      args: [amount],
    });
  }

  return { deposit, isPending, isSuccess };
}

Because the contract address is identical on every chain, these hooks work regardless of which L2 the user is connected to. wagmi automatically routes the call to whatever chain the wallet is on.

Chain Switching UX

The worst cross-chain UX is forcing a network switch with no context. Here is a component pattern I use that explains what is happening:

// components/ChainGuard.tsx
"use client";

import { useSwitchChain, useChainId } from "wagmi";
import { SUPPORTED_CHAINS } from "@/config/chains";

interface ChainGuardProps {
  requiredChainId: number;
  children: React.ReactNode;
}

export function ChainGuard({
  requiredChainId,
  children,
}: ChainGuardProps) {
  const chainId = useChainId();
  const { switchChain, isPending } = useSwitchChain();

  const targetChain = SUPPORTED_CHAINS.find(
    (c) => c.id === requiredChainId
  );

  if (chainId === requiredChainId) {
    return <>{children}</>;
  }

  return (
    <div className="rounded-xl border border-orange-500/20 bg-surface p-6">
      <p className="text-secondary mb-4">
        This action requires{" "}
        <span className="font-semibold text-white">
          {targetChain?.name}
        </span>
        . Your wallet is currently on a different
        network.
      </p>
      <button
        onClick={() =>
          switchChain({ chainId: requiredChainId })
        }
        disabled={isPending}
        className="rounded-lg bg-primary px-4 py-2 font-medium text-white transition-opacity hover:opacity-90 disabled:opacity-50"
      >
        {isPending
          ? "Switching..."
          : `Switch to ${targetChain?.name}`}
      </button>
    </div>
  );
}

Aggregated Multi-Chain Reads

For dashboards that show a user's positions across all chains, you need to read from multiple RPCs simultaneously:

// hooks/useMultiChainBalances.ts
import { useReadContracts } from "wagmi";
import {
  PROTOCOL_ADDRESS,
  SUPPORTED_CHAINS,
} from "@/config/chains";
import { protocolAbi } from "@/config/abi";

export function useMultiChainBalances(
  userAddress: `0x${string}` | undefined
) {
  const contracts = SUPPORTED_CHAINS.map((chain) => ({
    address: PROTOCOL_ADDRESS,
    abi: protocolAbi,
    functionName: "balanceOf" as const,
    args: userAddress ? [userAddress] : undefined,
    chainId: chain.id,
  }));

  const { data, isLoading } = useReadContracts({
    contracts,
    query: {
      enabled: Boolean(userAddress),
    },
  });

  const balances = SUPPORTED_CHAINS.map(
    (chain, index) => ({
      chain,
      balance: data?.[index]?.result as
        | bigint
        | undefined,
      error: data?.[index]?.error,
    })
  );

  const totalBalance = balances.reduce(
    (sum, b) => sum + (b.balance ?? 0n),
    0n
  );

  return { balances, totalBalance, isLoading };
}

This fires four parallel RPC calls — one per chain — and aggregates the results. The user sees their total position across all networks in a single view. That is the cross-chain UX people actually want.

Testing Cross-Chain Interactions

Testing cross-chain logic is harder than testing single-chain contracts. You cannot just fork one chain in Foundry — you need to simulate the bridge layer.

My testing strategy has three layers:

Layer 1: Unit Tests (Per-Chain Logic)

Standard Foundry tests for each chain's contract in isolation. These run fast and catch 80% of bugs.

// test/Protocol.t.sol
function test_depositUpdatesBalance() public {
    uint256 amount = 1 ether;
    deal(address(token), alice, amount);

    vm.startPrank(alice);
    token.approve(address(protocol), amount);
    protocol.deposit(amount);
    vm.stopPrank();

    assertEq(protocol.balanceOf(alice), amount);
}

Layer 2: Bridge Simulation Tests

Simulate cross-chain messages by calling the receiver directly with the expected sender address:

// test/CrossChain.t.sol
function test_receiveMessageFromL1() public {
    bytes32 messageId = keccak256("test-message-1");
    bytes memory data = abi.encode(
        uint256(1),
        abi.encode(uint256(500))
    );

    // Simulate Arbitrum's aliased L1 sender
    address aliasedSender =
        AddressAliasHelper.applyL1ToL2Alias(l1Sender);

    vm.prank(aliasedSender);
    receiver.receiveFromL1(messageId, data);

    assertTrue(receiver.processedMessages(messageId));
}

function test_rejectUnauthorizedSender() public {
    bytes32 messageId = keccak256("test-message-2");
    bytes memory data = abi.encode(uint256(1), "");

    vm.prank(address(0xdead));
    vm.expectRevert(
        abi.encodeWithSelector(
            CrossChainReceiver
                .UnauthorizedSender
                .selector,
            address(0xdead),
            AddressAliasHelper.applyL1ToL2Alias(
                l1Sender
            )
        )
    );
    receiver.receiveFromL1(messageId, data);
}

function test_rejectDuplicateMessage() public {
    bytes32 messageId = keccak256("test-message-3");
    bytes memory data = abi.encode(uint256(1), "");
    address aliasedSender =
        AddressAliasHelper.applyL1ToL2Alias(l1Sender);

    vm.prank(aliasedSender);
    receiver.receiveFromL1(messageId, data);

    // Second attempt should revert
    vm.prank(aliasedSender);
    vm.expectRevert(
        abi.encodeWithSelector(
            CrossChainReceiver
                .MessageAlreadyProcessed
                .selector,
            messageId
        )
    );
    receiver.receiveFromL1(messageId, data);
}

Layer 3: Forked Integration Tests

Fork each target chain and run tests against real bridge contracts. This catches issues with actual bridge behavior, gas differences, and precompile availability.

# Run tests against forked Arbitrum
forge test --fork-url $ARBITRUM_RPC_URL \
    --match-contract ArbitrumIntegrationTest -vvv

# Run tests against forked Base
forge test --fork-url $BASE_RPC_URL \
    --match-contract BaseIntegrationTest -vvv

I run forked tests in CI on every PR that touches contract code. They are slow (30-60 seconds per chain), but they catch real integration issues that mock tests miss — gas estimation differences, precompile behavior on zkSync, and sequencer uptime feed edge cases on Arbitrum.

Production Challenges I Have Hit

After shipping cross-chain systems to mainnet, here are the issues that no tutorial warned me about:

1. Sequencer Downtime

Both Arbitrum and Optimism have had sequencer outages. When the sequencer goes down, users cannot submit L2 transactions. Your frontend must detect this and show a clear message instead of letting transactions hang indefinitely.

On Arbitrum, check the sequencer uptime feed from Chainlink:

function _checkSequencerUptime() internal view {
    (, int256 answer, , uint256 updatedAt, ) =
        sequencerUptimeFeed.latestRoundData();

    // answer == 0 means sequencer is up
    // answer == 1 means sequencer is down
    if (answer != 0) {
        revert SequencerDown();
    }

    // Ensure data is fresh (not stale)
    if (block.timestamp - updatedAt > 3600) {
        revert StaleSequencerData();
    }
}

2. Gas Price Spikes on Specific L2s

L2 gas prices are not uniform. Arbitrum can spike during NFT mints. Base can spike during memecoin launches. Your frontend should fetch gas estimates from all chains and warn users if a specific network is temporarily expensive.

3. RPC Provider Reliability

Public RPCs are unreliable for production. I use at least two providers per chain with automatic failover:

import { fallback, http } from "wagmi";

const transports = {
  [arbitrum.id]: fallback([
    http("https://arb-mainnet.g.alchemy.com/v2/KEY"),
    http("https://arbitrum-one.publicnode.com"),
  ]),
};

4. Cross-Chain Race Conditions

When a user takes an action on Chain A that depends on state from Chain B, you have a race condition. The bridge message from B to A takes minutes to hours. During that window, the state is inconsistent.

The only safe approach: design your protocol so that each chain's state is valid independently. Cross-chain messages should update state, not gate it. If an action on Chain A requires confirmation from Chain B, use a two-phase commit — lock on A, confirm from B, then finalize on A.

5. Contract Verification Across Chains

Each L2 block explorer has slightly different verification APIs. Foundry's --verify flag handles most of this, but zkSync requires the --zksync flag and a separate compiler. Automate verification in your deployment script or you will spend hours doing it manually across four chains.

6. Monitoring Multiple Chains

You need chain-specific monitoring for each deployment. I use a combination of The Graph subgraphs (one per chain) and a lightweight Node.js service that watches for critical events across all chains and routes alerts to a single Slack channel. Without centralized monitoring, you will miss issues on chains you do not check daily.

Key Takeaways

1. Start with Pattern 1 (Mirror Deployment). Most projects do not need cross-chain messaging. Identical contracts on multiple chains with independent state covers 80% of use cases.

1. Use CREATE2 for deterministic addresses. One address across all chains eliminates an entire class of frontend bugs and simplifies your deployment pipeline.

1. Validate bridge senders with chain-specific patterns. Arbitrum uses address aliasing. Optimism uses CrossDomainMessenger. zkSync has its own L1-L2 communication. Do not abstract this away until you understand each chain's security model.

1. wagmi handles multi-chain reads natively. useReadContracts with chainId per contract lets you aggregate state across chains in a single hook.

1. Test at three layers: unit, bridge simulation, and forked integration. Each layer catches different bugs. Skipping forked tests is how you ship code that works in development and breaks on mainnet.

1. Design for sequencer downtime. It happens. Your protocol and frontend must handle it gracefully.

1. Cross-chain state should be eventually consistent, not strongly consistent. If you need strong consistency across chains, you are fighting the architecture. Redesign so each chain can operate independently with delayed updates.

The L2 ecosystem is where most new users will interact with Ethereum for the foreseeable future. Building cross-chain applications is not optional anymore — it is the baseline expectation. Start with simple mirror deployments, add bridge messaging only when you have a concrete need, and invest heavily in monitoring. The protocols that win will be the ones where users never have to think about which chain they are on.

If you are building a multi-chain project and want help with architecture or deployment, check out my services or reach out directly. I have shipped these patterns to production and can help you avoid the pitfalls.

*Uvin Vindula is a Web3 and AI engineer based between Sri Lanka and the UK. He builds production smart contracts, multi-chain dApps, and AI-powered applications through Terra Labz↗ and his independent practice at uvin.lk↗. Follow his work @IAMUVIN↗.*