Launching a Gasless Transaction Experience via Intents

Traditional blockchain transactions require users to pay network fees (gas) in the native token, creating a significant barrier to entry. This friction is especially problematic for new users who may not hold ETH, MATIC, or other base-layer tokens. A gasless transaction experience abstracts this complexity away, allowing users to sign a message expressing their desired outcome—an intent—without managing gas directly. The system then fulfills this intent on their behalf, often covering the cost or bundling it into the operation.

Intents are declarative statements of a user's goal, such as "swap 100 USDC for ETH at the best rate" or "bridge 1 ETH to Arbitrum." Instead of specifying the exact low-level steps (a transaction), users delegate the execution logic to a specialized network of actors called solvers or fillers. These solvers compete to fulfill the intent in the most efficient way, potentially across multiple protocols and chains, and submit the resulting transaction bundle. The user only signs once, approving the outcome, not the mechanics.

This architecture enables several key benefits: improved user experience through one-click interactions, better execution via solver competition, and cross-chain interoperability without user intervention. Major protocols like UniswapX, CowSwap, and various intent-centric rollups are built on this model. For developers, integrating intents means building systems that generate, route, and fulfill these signed user messages.

Implementing a gasless flow typically involves a few core components. First, a client-side SDK (like the Chainscore SDK) helps construct and sign the intent object. Second, a relayer network or bundler receives the signed intent, optionally sponsors the gas fees, and submits transactions. Finally, a solver network interprets the intent, finds optimal execution paths, and generates the transaction calldata. Smart accounts, such as ERC-4337 account abstraction wallets, are often used to enable this sponsored transaction model.

This guide will walk through building a practical example: a gasless token swap. We'll cover setting up the intent schema, integrating with a relayer service, handling the fulfillment lifecycle, and ensuring security. The code examples will use viem for Ethereum interactions and demonstrate the end-to-end flow from user signature to on-chain settlement.

To follow this guide, you'll need a basic understanding of Ethereum and smart contract interactions. Familiarity with EVM-compatible chains and the concept of gas fees is essential. You should have Node.js (v18 or later) and npm or yarn installed. We'll use TypeScript for type safety, so ensure your editor is configured accordingly. The primary tools are the viem library for Ethereum interactions and the Chainscore SDK for intent-based transaction handling.

You will need access to a private key for a sponsor account that will pay for user transactions. This account must be funded with the native token (e.g., ETH, MATIC) on your target network. For testing, you can use a testnet like Sepolia or Polygon Amoy. Obtain testnet ETH from a faucet. We'll also use Alchemy or Infura as an RPC provider; sign up for a free account and get your API endpoint URL. Set these as environment variables (PRIVATE_KEY, RPC_URL) in a .env file.

The core concept enabling gasless transactions is account abstraction, specifically the ERC-4337 standard for UserOperations. An intent is a declarative statement of a user's desired outcome (e.g., "swap 1 ETH for USDC") rather than a direct transaction. Our system will use a Paymaster contract to sponsor gas fees on behalf of users. We'll construct a UserOperation containing the intent, which a Bundler will submit to the network, with gas costs covered by our sponsor via the Paymaster.

In traditional blockchain transactions, users must specify the exact sequence of operations, sign the transaction, and pay the gas fees upfront. This creates friction, especially for new users unfamiliar with fluctuating network costs. Intents solve this by allowing users to declare a desired end state—like "swap 1 ETH for DAI at the best rate"—without micromanaging the execution path. A specialized actor, called a solver or fulfiller, then competes to find the most efficient way to satisfy this intent, often bundling it with others for optimal gas usage.

Gas abstraction is the mechanism that removes the requirement for users to hold the native token to pay for gas. This is achieved through systems like paymasters (EIP-4337) or sponsored transactions, where a third party—such as the dApp, a wallet, or the solver—covers the gas cost. The user can pay for fees in any ERC-20 token they are transacting with, or the cost can be absorbed as a service. Combined with intents, this creates a seamless, gasless user experience where the complexity of fee management is entirely abstracted away.

The architecture for a gasless intent-driven transaction typically involves several components. The user signs an intent message off-chain, which is a structured declaration of their goal and constraints. This intent is submitted to a network, like a SUAVE-like mempool or an intent-centric solver network. Solvers then simulate various fulfillment paths, often leveraging MEV opportunities to subsidize costs, and broadcast the winning transaction bundle. The user's wallet or a paymaster contract handles gas payment on-chain, finalizing the operation without the user ever needing ETH for gas.

A Verifying Paymaster is an ERC-4337-compliant smart contract that pays for a user's gas fees on their behalf. It acts as a sponsor or relayer, abstracting away the need for users to hold the native chain token (like ETH). The core logic is defined in the IPaymaster interface, where the validatePaymasterUserOp function determines if a user operation (UserOp) should be sponsored. This function typically verifies a cryptographic signature from the user to authorize the sponsored transaction, ensuring only intended actions are paid for.

To deploy your paymaster, you'll need a development environment like Foundry or Hardhat. Start by inheriting from a base contract like VerifyingPaymaster.sol from the account-abstraction samples repository. Key deployment steps include: funding the contract with native tokens to cover gas, setting the entry point address (the canonical ERC-4337 EntryPoint contract), and configuring the verifying signer (the public address that corresponds to the private key used to sign user intents).

The paymaster's security and business logic hinge on signature verification. When a user submits an intent (e.g., 'swap 100 USDC for ETH'), your backend signs this intent data. The paymaster contract uses EIP-712 structured signing to validate this signature against the known verifying signer. This prevents fraud and ensures you only pay for authorized operations. You must carefully manage the signer's private key and consider using a secure, off-chain signing service in production.

After deployment, you must stake ETH in the EntryPoint contract for your paymaster. ERC-4337 requires paymasters to provide a deposit in the EntryPoint to cover potential gas costs and penalize malicious behavior. Use the EntryPoint's depositTo function. Without a sufficient stake, bundled transactions from your paymaster will be rejected by the network. Monitor this deposit balance as it depletes with usage.

Finally, integrate the paymaster with your application. Your frontend or SDK should: generate EIP-712 typed data for the user's intent, send it to your backend for signing, and then construct a UserOp with the paymasterAndData field pointing to your deployed contract and including the signature. Test thoroughly on a testnet like Sepolia using a bundler service like @stackup or @pimlico to ensure the complete flow—signature, validation, sponsorship, and execution—works end-to-end before mainnet deployment.

A gas sponsorship policy is the core logic that determines which transactions your application will pay for. This is a critical security and financial control. A well-defined policy prevents abuse, such as users spamming the network or executing unauthorized actions at your expense. The policy acts as a filter, evaluating each user's intent request against a set of programmable rules before any funds are committed. Think of it as the bouncer for your gas wallet.

Policies are typically enforced by a relayer or solver in the intents architecture. When a user submits a signed intent, the relayer checks it against your application's policy module. Common policy criteria include: verifying the user's signature, checking that the target smart contract is on an allowlist, validating that the transaction calldata matches expected patterns, and ensuring the gas cost does not exceed a predefined limit. For example, a policy for a free NFT mint would only sponsor transactions to the specific mint function on your NFT contract.

You can implement policies with varying complexity. A simple allowlist-based policy only permits transactions to pre-approved contracts and functions. A more advanced state-based policy might check on-chain conditions, like the user's token balance or the current phase of a sale, before sponsoring gas. For maximum flexibility, policies can be written as smart contracts (e.g., in Solidity) that expose a validate function, allowing for arbitrary logic. The OpenZeppelin Defender Relayer service is a popular tool for managing such policies.

Here is a conceptual example of a policy contract snippet that checks for a specific target contract and function selector:

solidityCopy
function validateSponsorship(
    UserOperation calldata userOp
) external view returns (bool) {
    // 1. Allow only calls to the specific 'mint' function on our contract
    require(
        userOp.target == address(myNFTContract) &&
        bytes4(userOp.calldata[0:4]) == myNFTContract.mint.selector,
        "Invalid target or function"
    );
    // 2. Optional: Add custom logic (e.g., check sale is active)
    require(myNFTContract.saleActive(), "Sale not active");
    return true;
}

This function would be called by your relayer for each transaction.

After defining the policy logic, you must fund a sponsorship wallet (often a smart contract wallet like Safe) that the relayer can use to pay for approved transactions. The policy and the funding mechanism are separate but connected: the policy controls the 'if', and the wallet provides the 'how much'. It's essential to monitor this wallet's balance and set up alerts, as depletion will break the gasless experience. Tools like Gelato and Biconomy offer managed services that bundle policy management, relaying, and gas tank funding.

Finally, consider the user experience implications of your policy. A policy that is too restrictive will frustrate users with failed transactions, while one that is too permissive is financially risky. Start with a narrow, well-tested policy for a specific user flow (e.g., a free mint) and expand cautiously. Document the sponsored actions clearly for your users so they understand what is and isn't covered, building trust in your application's gasless feature.

A relayer network is the execution layer for your gasless transaction system. When a user signs an intent—a signed message declaring their desired outcome—it is your application's job to broadcast this intent to a network of relayers. These relayers compete to fulfill the intent by submitting the actual blockchain transaction, paying the gas fees upfront, and earning a fee for their service. Your integration point is typically a relayer API endpoint or a decentralized relayer marketplace like the Gelato Network or Biconomy.

The core technical task is to wrap the user's signed intent into a standard format the relayer accepts and then post it. For example, using a ERC-4337 UserOperation for account abstraction, you would construct the operation object, have the user sign it, and then send it to a bundler service. A simplified API call to a relayer might look like this:

javascriptCopy
const response = await fetch('https://api.relayer.network/v1/relay', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    userOp: signedUserOperation,
    chainId: 1,
    sponsor: 'your-app-address' // For gas sponsorship
  })
});

You must handle the relayer's response and poll for transaction completion. A successful relay returns a taskId or transactionHash. Your application should then monitor the blockchain for the transaction's inclusion and finality, updating the user interface accordingly. It's critical to implement robust error handling for cases where relayers are unresponsive, transactions revert, or gas prices spike beyond the relayer's configured limits. Providing clear user feedback during this asynchronous process is essential for a good experience.

When selecting a relayer solution, evaluate based on network coverage (supported chains), reliability (uptime and success rate), cost structure (fee model for sponsored transactions), and decentralization. Some networks use a permissioned set of relayers, while others employ a permissionless, competitive model. For maximum resilience, consider implementing fallback logic that can switch between multiple relayer providers if your primary service fails to broadcast a transaction within a specified time window.

Finally, remember that the relayer is a trusted component. It sees the full transaction details and has the power to censor or reorder requests. For applications requiring strong anti-censorship guarantees, explore suave-type architectures or peer-to-peer intent propagation networks where the role of the relayer is more decentralized. Your integration should abstract away the complexity of this network, presenting the end user with a seamless, gasless interaction where they only sign a message and see a confirmed result.

The client-side SDK is the primary interface between your application and the Chainscore intent framework. Its core responsibility is to abstract the complexity of constructing, signing, and submitting intent payloads to the solver network. A well-designed SDK provides developers with simple, declarative functions like sendGaslessTransaction() that handle the underlying steps: generating the user's intent, fetching solver quotes, and managing the final submission. This layer is crucial for developer adoption, as it reduces integration time from days to minutes.

Under the hood, the SDK performs several key operations. First, it uses the user's wallet (via libraries like Ethers.js or Viem) to cryptographically sign the intent object, which includes the desired action, constraints, and a deadline. It then calls the solver marketplace API (built in Step 3) to fetch and present available solver quotes. Finally, it submits the signed intent and the user's selected solver to the Chainscore Settlement Contract onchain, which escrows the user's assets and emits an event for solvers to fulfill.

A robust SDK must handle error states and edge cases gracefully. This includes managing RPC provider failures, handling user rejection from their wallet, validating that the solver's quote is still valid before submission, and providing clear feedback. Implementing a modular architecture allows for easy updates, such as adding support for new chains or intent types. The SDK should also expose lower-level methods for advanced users who need more control over the intent construction process.

For a practical example, consider an SDK function for a token swap. The function signature might be swapTokens(intentParams, solverPreferences). Internally, it would construct an intent specifying the input token, minimum output amount, and recipient address. After fetching quotes, it would present them to the user, then use wallet.sendTransaction() to invoke the settlement contract with the finalized data. The SDK returns a transaction hash representing the intent submission, not the final swap, which is a key conceptual difference from traditional transactions.

Thorough testing and documentation are non-negotiable. The SDK should be tested against a local fork of the blockchain and a mock solver network. Documentation must include quick-start guides, API references, and examples for common use cases like swaps, NFT mints, and cross-chain actions. Providing a TypeScript SDK with full type definitions significantly improves the developer experience by enabling auto-completion and compile-time checks.