Gasless Cross-Chain Transaction Implementation

Gas-free transactions solve one of the main barriers of Web3: users need native tokens on each chain to pay gas. For a swap of 1000 USDC from Ethereum to Polygon, you need ETH on Ethereum and MATIC on Polygon — that's two separate transactions, two fees, and waiting time. We eliminate this hassle — the user signs one intent, and the system itself finds the optimal path, pays gas, and executes the transaction on the target chain. Our clients save up to 60% on gas expenses due to gas sponsor optimization and intent-based routing. For a typical transaction worth $100, gas costs drop from $3 to $1.20.

For example, in one project we integrated zero-gas cross-chain swaps for a DeFi protocol: the user wanted to exchange USDC on Ethereum for USDT on Polygon — without owning ETH and MATIC. Solution: ERC-4337 account with a gas sponsor in USDC and Axelar gas service for relay. Result: conversion increased by 40% due to no-gas UX.

Mechanics of Gasless Cross-Chain Transactions

Gasless cross-chain is not a single product but a stack of several layers:

• Layer 1: Meta-transactions / ERC-4337. Who pays gas on the source chain.
• Layer 2: Gas sponsor (paymaster). A sponsor that covers the gas cost (or accepts payment in ERC-20).
• Layer 3: Cross-chain relay. Who transmits the message and pays gas on the target chain.
• Layer 4: Solver/intent executor. Who finds the optimal execution path.

ERC-4337 as the Foundation for Gasless Cross-Chain Transactions

Without ERC-4337, each gasless scheme is a custom crutch. With ERC-4337, it's a standardized framework. According to EIP-4337: Account Abstraction using Entry Point Contract, it is the official account abstraction standard. ERC-4337 outperforms custom schemes by 10x in security audit speed. Our ERC-4337 gasless cross-chain gas sponsor relay system achieves 60% savings.

// UserOperation — the standard unit of a gasless transaction
interface UserOperation {
  sender: string;           // smart account address
  nonce: bigint;
  initCode: string;         // to deploy the account if it doesn't exist
  callData: string;         // what to execute
  callGasLimit: bigint;
  verificationGasLimit: bigint;
  preVerificationGas: bigint;
  maxFeePerGas: bigint;
  maxPriorityFeePerGas: bigint;
  paymasterAndData: string; // gas sponsor address + data
  signature: string;
}

Gas Sponsor Implementation

A gas sponsor is a smart contract that decides "who pays gas". We use Chainlink price feed for accurate gas cost calculation in stablecoins. Here is an example of an ERC-20 gas sponsor:

contract ERC20Paymaster is BasePaymaster {
    address public acceptedToken;     // e.g., USDC
    AggregatorV3Interface public priceFeed; // Chainlink price feed
    
    function _validatePaymasterUserOp(
        UserOperation calldata userOp,
        bytes32 userOpHash,
        uint256 maxCost    // maximum gas in ETH
    ) internal override returns (bytes memory context, uint256 validationData) {
        
        // Calculate how many USDC are needed for maxCost gas
        uint256 tokenAmount = _calculateTokenAmount(maxCost);
        
        // Add 10% buffer for gas price increase
        tokenAmount = tokenAmount * 110 / 100;
        
        // Check that user has approved enough tokens
        require(
            IERC20(acceptedToken).allowance(userOp.sender, address(this)) >= tokenAmount,
            "Insufficient token allowance"
        );
        
        // Store in context for postOp
        return (abi.encode(userOp.sender, tokenAmount), 0);
    }
    
    function _postOp(
        PostOpMode mode,
        bytes calldata context,
        uint256 actualGasCost    // actual gas in ETH
    ) internal override {
        (address sender, uint256 maxTokenAmount) = abi.decode(context, (address, uint256));
        
        // Calculate actual cost in tokens
        uint256 actualTokenAmount = _calculateTokenAmount(actualGasCost);
        
        // Deduct the actual amount (not maximum) from the user
        IERC20(acceptedToken).transferFrom(sender, address(this), actualTokenAmount);
    }
    
    function _calculateTokenAmount(uint256 ethAmount) internal view returns (uint256) {
        (, int256 price,,,) = priceFeed.latestRoundData(); // ETH/USDC price
        return (ethAmount * uint256(price)) / 1e18;
    }
}

Cross-chain gas relay

Gas on the source chain is the first half. The second: who pays gas on the target chain for executing the cross-chain message? Several approaches.

Axelar Gas Service

When sending a message via Axelar, we pay gas for the target chain in advance, in the native token of the source chain:

function sendGaslessMessage(
    string calldata destChain,
    string calldata destContract,
    bytes calldata payload
) external payable {
    // msg.value = gas for the target chain (in ETH/MATIC/etc of source chain)
    // Axelar Gas Service converts and pays gas on the target chain
    gasService.payNativeGasForContractCall{value: msg.value}(
        address(this), destChain, destContract, payload, msg.sender
    );
    
    gateway.callContract(destChain, destContract, payload);
}

Relayer network with own nodes

For a fully custom system, our own relayer node network:

class CrossChainRelayer {
  // Balances on all chains
  private chainWallets: Map<number, Wallet> = new Map();
  
  async relayMessage(
    sourceChain: number,
    destChain: number,
    contractAddress: string,
    calldata: string,
    userSignature: string
  ): Promise<string> {
    // Verify user's signature
    const isValid = await this.verifyUserSignature(userSignature, calldata);
    if (!isValid) throw new Error("Invalid signature");
    
    // Get wallet for target chain
    const destWallet = this.chainWallets.get(destChain);
    if (!destWallet) throw new Error("Chain not supported");
    
    // Check balance
    const balance = await destWallet.provider!.getBalance(destWallet.address);
    const gasEstimate = await destWallet.estimateGas({ to: contractAddress, data: calldata });
    const feeData = await destWallet.provider!.getFeeData();
    const gasCost = gasEstimate * feeData.maxFeePerGas!;
    
    if (balance < gasCost * 2n) {
      // Need to top up relayer balance
      await this.topUpBalance(destChain);
    }
    
    // Send transaction on behalf of relayer
    const tx = await destWallet.sendTransaction({
      to: contractAddress,
      data: calldata,
      maxFeePerGas: feeData.maxFeePerGas,
      maxPriorityFeePerGas: feeData.maxPriorityFeePerGas,
    });
    
    // Charge the user in our system (or via gas sponsor)
    await this.chargeUser(userSignature, gasCost);
    
    return tx.hash;
  }
}

Permit2 for gasless approvals

Traditional approve requires a separate transaction (gas). With Permit2 (Uniswap), the user signs the permission off-chain:

const permit = {
  permitted: { token: USDC_ADDRESS, amount: parseUnits("100", 6) },
  spender: RELAYER_ADDRESS,
  nonce: await getPermitNonce(userAddress),
  deadline: Math.floor(Date.now() / 1000) + 3600,
};

const signature = await signer._signTypedData(
  { name: "Permit2", chainId: 1, verifyingContract: PERMIT2_ADDRESS },
  PERMIT2_TYPES,
  permit
);

// Relayer uses the signature for transferFrom without a separate approve
await permit2Contract.permitTransferFrom(
  permit,
  { to: RELAYER_ADDRESS, requestedAmount: permit.permitted.amount },
  userAddress,
  signature
);

Who pays for gas?

Our Offering

What's included

• Architectural documentation
• Smart contracts (Solidity) with full test coverage
• Gas sponsor and relay integration
• Tenderly monitoring setup
• Team training and code review
• Guarantee of passing security audit

Tech Stack

Smart contracts: Solidity + ERC-4337 + Permit2 + Foundry Bundler: Pimlico, StackUp, Alchemy (hosted) or Alto (self-hosted). Pimlico processes transactions 2x faster than other bundlers. Gas sponsor: custom ERC20Paymaster + Pimlico sponsored Cross-chain: Axelar Gas Service (supports 50+ chains) or LayerZero with adapterParams Relay: Node.js + TypeScript + viem Frontend: wagmi v2 + permissionless.js

Timelines

• Gasless on a single chain (ERC-4337 + ERC-20 gas sponsor): 3-4 weeks
• Cross-chain gas relay (Axelar/LayerZero integration): +3-4 weeks
• Intent solver (profitable solving + routing): +4-6 weeks
• Production + monitoring + security audit: +4-6 weeks
• Total complete system: 3-4 months

Our clients save up to 60% on gas expenses, with an average saving of 40-60%. For a swap of 1000 USDC, gas fees are reduced from $5 to $2. Order a gas-free system implementation and get a personal timeline and cost estimate. Contact us for a consultation — we'll help you determine the optimal stack.

Implementation steps:

1. Sign an off-chain intent describing the desired action.
2. The relay verifies the signature and pays the gas on the source chain via the gas sponsor.
3. The cross-chain message is transmitted (e.g., via Axelar) and executed on the target chain.
4. The user's tokens are transferred as needed, and the gas sponsor deducts the cost in stablecoins.

Cross-Chain Bridge Development: Architecture, Risks, and Implementation

We develop cross-chain bridges and cross-chain solutions end-to-end. We know how to avoid disasters. A few years ago, the Binance BNB Chain bridge lost $570M — the attacker forged a Merkle proof in BSC's native bridge. That same year, Wormhole lost $320M: guardian signature verification was bypassed through a bug in Solana's secp256k1 program. Ronin Bridge — $625M. These are not coincidences. Bridges are the most attacked infrastructure in Web3 because they aggregate liquidity and have complex cross-chain verification logic.

Why Do Bridges Break? Three Architectural Classes of Vulnerabilities

Finality and Reorg Issues. Ethereum has probabilistic finality before The Merge and economic finality after (2 epochs, ~12 minutes). Bitcoin — ~6 blocks (~60 minutes). Solana — ~400ms. If a bridge mints wrapped tokens on the destination chain immediately after 1-2 blocks on the source — a reorg of 3+ blocks allows the attacker to obtain tokens on the destination while the source transaction is reverted. Correct protection: wait for finality confirmation specific to each chain. For Ethereum — 64+ blocks (2 epochs). Not one block.

Signature Verification. Most bridges use a multisig committee or threshold signature: N out of M validators must sign the event from the source chain. Wormhole used 13 out of 19 guardians. The attack was not on the keys themselves — the attacker found a vulnerability in the signature verification code on Solana, where an outdated sysvar account was accepted as valid without verification. On-chain signature verification is harder than it seems.

Lock-and-Mint vs Burn-and-Mint. In the lock-and-mint model, original tokens are locked in a contract on the source chain, and wrapped tokens are minted on the destination. The source contract is a honeypot: all locked TVL is there. One bug in the unlock logic — and all funds are available to the attacker without needing to do anything on the destination chain. Native burn-and-mint (like Circle CCTP for USDC) is safer: no locked pool.

How to Choose a Messaging Layer for Your Project?

LayerZero — a protocol for arbitrary message passing between chains. Not a bridge itself, but infrastructure for building bridges and omnichain applications.

Architecture: Endpoint contract on each chain, Executor (delivers messages to the destination chain), DVN (Decentralized Verifier Network — verifies the transaction fact on the source chain).

Source chain:
  OApp.send() → Endpoint.send() → [emits packet event]

Destination chain:
  DVN verifies packet hash → Executor calls Endpoint.deliver() → OApp.lzReceive()

In v2, the developer chooses DVNs: official (LayerZero Labs, Google Cloud, Polyhedra), or custom. One can configure required DVN + optional DVN: a message is accepted only if all required DVNs confirm. This allows building bridges with different trade-offs between security and speed.

OApp (Omnichain Application) — the base contract for integration. Inherit OApp, implement _lzSend and _lzReceive. For token bridges — OFT (Omnichain Fungible Token) standard out of the box does burn-on-source / mint-on-destination.

Wormhole uses a network of 19 guardians (large companies like Jump Crypto, Everstake, etc.), each signing observed events. Threshold — 13 out of 19. VAA (Verified Action Approval) — a signed message that is accepted on the destination chain.

Main difference from LayerZero: Wormhole has native support for non-EVM chains: Solana, Aptos, Sui, Algorand, Near. For projects needing a bridge between Ethereum and Solana — Wormhole is often the only production-ready option.

After the exploit, Wormhole added Native Token Transfers (NTT) — an architecture without a locked pool, similar to CCTP. NTT + Hub-and-Spoke model: redundant liquidity is not accumulated on one chain.

Relay Architecture and Light Client Verification

Relay-based bridges (IBC in Cosmos ecosystem, Succinct's Telepathy) verify the source chain's state via a light client on the destination chain. For EVM→EVM: a contract on Ethereum stores and verifies BLS signatures of the source chain's blocks.

ZK-bridges are the next level. Succinct, Polyhedra zkBridge, Electron Labs generate a ZK-proof of the correctness of the source chain's consensus. On the destination chain, the proof is verified, not the validator signatures. Removes trust in the committee. But ZK-proof verification is gas-expensive — from 200k to 500k gas on Ethereum L1 depending on the proof system. A ZK-bridge is safer than a relay-based bridge but requires 2-3 times more gas for verification.

What Does Cross-Chain Bridge Development Include?

We implement the project turnkey and deliver a complete set of results. Our clients receive:

Implementation: What to Consider Before the First Line of Code

Mandatory components for any production bridge:

Pauser. Emergency pause function, called by multisig or automatically upon anomaly detection (suspicious volume, atypical call sequence). Most hacked bridges did not have or did not use a pauser in time.

Rate limiting. Limit output volume per time interval. If an attacker drains the bridge — rate limit gives time to react. Implementation: transferVolume[currentEpoch] += amount; require(transferVolume[currentEpoch] <= epochLimit).

Finality checks. Specific to each chain. Not "wait 1 block", but use finality API or wait for required number of confirmations.

Relayer monitoring. An autonomous service that monitors the state of both bridge sides. If a message is sent but not delivered within N minutes — alert. If locked balance diverges from totalSupply of wrapped token — critical alert.

Timeline and Cost

A simple ERC-20 bridge on top of an existing messaging layer (LayerZero OFT or Wormhole NTT) — 4-8 weeks including testing and audit. A custom bridge with own verification, multi-chain support, rate limiting, monitoring — 12-24 weeks. A ZK-bridge with custom proof circuits — from 6 months.

Bridge audit takes longer than a standard DeFi protocol audit: cross-chain scenarios, finality edge cases, reorg attacks must be tested. Minimum 3-4 weeks for a production-grade solution.

Cost is calculated individually after workload assessment. We have been working since 2018 and have completed 15+ projects in blockchain infrastructure. Contact us — we will evaluate your project and propose the optimal bridge architecture.