Gasless Transactions

Executive Summary

Gasless transactions represent a fundamental shift in blockchain user experience by abstracting away the complexity of gas fees and transaction management. Through the implementation of the ERC-2771 meta-transaction standard, users can sign transactions off-chain while a relayer service submits them on-chain and covers the gas costs. This approach eliminates one of the primary barriers to mainstream blockchain adoption: the requirement for users to understand and manage native tokens for transaction fees.

This report presents a comprehensive architecture and implementation roadmap for deploying gasless transactions on Passet Hub, Polkadot's EVM-compatible smart contract platform. The implementation leverages proven patterns from Ethereum while adapting to PolkaVM's unique constraints, including constructor storage limitations and multi-dimensional resource metering. The proposed system includes three core components: a simplified forwarder contract optimized for PolkaVM, a relay service for transaction submission and gas sponsorship, and recipient contracts that extract the real sender from forwarded transactions.

What Are Gasless Transactions?

The Problem

Traditional blockchain interactions require users to hold native tokens (like PAS on Passet Hub or ETH on Ethereum) to pay for transaction gas fees. This creates significant friction for new users who must first acquire tokens through exchanges, understand wallet management, and maintain sufficient balances for transactions. For many use cases, this complexity is a dealbreaker that prevents mainstream adoption.

The Solution: Meta-Transactions

Meta-transactions solve this problem by introducing a trusted intermediary called a relayer. Instead of submitting transactions directly to the blockchain, users sign transaction requests off-chain using standard cryptographic signatures. The relayer then submits these signed requests to a forwarder contract, paying the gas fees on behalf of the user. The forwarder verifies the signature and executes the requested transaction, with the target contract able to extract the real sender from the forwarded call.

Key Benefits

Use Cases

ERC-2771 Standard

Overview

ERC-2771 is an Ethereum standard that defines a secure protocol for native meta-transactions. It specifies the interface between forwarder contracts and recipient contracts, ensuring interoperability across different implementations. The standard has been widely adopted in the Ethereum ecosystem and is supported by major infrastructure providers including OpenZeppelin, Biconomy, and Gelato.

Core Components

Request Structure

ERC-2771 forward requests include the following fields, ensuring complete specification of the desired transaction while preventing replay attacks and unauthorized execution:

struct ForwardRequest {
    address from;        // Signer address (must match signature)
    address to;          // Target contract address
    uint256 value;       // Native token amount to forward
    uint256 gas;         // Gas limit for the call
    uint256 nonce;       // Unique identifier to prevent replay
    uint256 deadline;    // Expiration timestamp
    bytes data;          // Encoded function call data
}

Signature Verification

Signatures use EIP-712 typed structured data, providing a secure and user-friendly signing experience. The signature covers all request fields along with a domain separator that includes the forwarder address and chain ID, preventing cross-contract and cross-chain replay attacks.

// EIP-712 Domain
struct EIP712Domain {
    string name;              // "SimpleForwarder"
    string version;           // "1"
    uint256 chainId;          // 420420422 (Passet Hub)
    address verifyingContract; // Forwarder address
}

// Typed data hash
hash = keccak256(abi.encodePacked(
    "\x19\x01",
    DOMAIN_SEPARATOR,
    structHash
))

Sender Extraction

The ERC-2771 standard specifies that the forwarder appends the real sender address to the calldata when forwarding requests. Recipient contracts inherit from ERC2771Context, which overrides msg.sender to extract this appended address. This approach maintains backward compatibility while enabling gasless functionality.

function _msgSender() internal view returns (address) {
    if (msg.sender == trustedForwarder && msg.data.length >= 20) {
        // Extract sender from last 20 bytes of calldata
        return address(bytes20(msg.data[msg.data.length - 20:]));
    }
    return msg.sender; // Fallback to direct calls
}

Forwarder Contract Research

OpenZeppelin ERC2771Forwarder

OpenZeppelin provides a production-ready ERC2771Forwarder implementation that has been extensively audited and battle-tested across multiple networks. The implementation includes advanced features such as batch execution with refunding, comprehensive security checks, and gas-efficient nonce management. However, this implementation uses storage operations in the constructor and complex inheritance patterns that are incompatible with PolkaVM's current constraints.

Key Features

Security Features

Alternative Implementations

Biconomy Forwarder

Biconomy provides a widely-used forwarder implementation that powers gasless transactions for numerous production applications. The contract includes additional features such as domain separator caching and optimized gas usage. However, like OpenZeppelin's implementation, it relies on constructor storage operations and is not compatible with PolkaVM without significant modifications.

Gelato Relay

Gelato offers a comprehensive relay infrastructure including forwarder contracts and a managed relay service. Their implementation focuses on high-throughput scenarios and includes advanced features like conditional execution and fee payment in ERC-20 tokens. The forwarder contract follows similar patterns to OpenZeppelin but with additional complexity that makes PolkaVM adaptation challenging.

Lessons Learned

PolkaVM-Specific Adaptations

Constructor Storage Constraint

The most significant challenge for deploying forwarder contracts on Passet Hub is the prohibition of storage operations (sstore and sload) in constructors. This limitation affects standard patterns used throughout the Ethereum ecosystem, including OpenZeppelin's base contracts. The root cause appears to be fundamental to PolkaVM's current implementation and affects all tested contract patterns.

Standard Pattern (Fails on PolkaVM)

contract StandardForwarder {
    string private _name;    // Storage variable
    string private _version; // Storage variable
    
    constructor(string memory name, string memory version) {
        _name = name;        // sstore - FAILS
        _version = version;  // sstore - FAILS
    }
}

PolkaVM-Compatible Pattern

contract SimpleForwarder {
    // Use constants instead of storage
    string private constant NAME = "SimpleForwarder";
    string private constant VERSION = "1";
    
    // No constructor needed, or empty constructor
    constructor() {}
    
    // Compute values on-demand
    function DOMAIN_SEPARATOR() public view returns (bytes32) {
        return keccak256(abi.encode(
            keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"),
            keccak256(bytes(NAME)),
            keccak256(bytes(VERSION)),
            block.chainid,
            address(this)
        ));
    }
}

Memory and Size Constraints

PolkaVM enforces stricter limits than standard EVM, with a maximum contract code size of approximately 100KB and a call stack depth limit of 5. These constraints require careful contract design and optimization, particularly when considering the inclusion of libraries and inherited contracts.

Multi-Dimensional Resource Metering

Unlike Ethereum's single gas metric, PolkaVM uses three separate resource dimensions: ref_time (computation), proof_size (state proof size), and storage_deposit (state bloat management). The Ethereum RPC proxy automatically maps these to a single gas value for compatibility, but relay services should be aware of this multi-dimensional model for accurate cost estimation.

Existential Deposit

Passet Hub requires accounts to maintain a minimum balance (existential deposit) to remain active. This affects gasless transaction systems in two ways: new user accounts must receive sufficient initial balance, and forwarded transactions must account for this minimum when handling value transfers. The relay service should handle existential deposit requirements transparently.

Complete Simplified Forwarder

The following implementation has been validated on Passet Hub and successfully handles gasless transactions while working within all PolkaVM constraints:

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

contract SimpleForwarder {
    // Constants (no storage in constructor)
    string private constant NAME = "SimpleForwarder";
    string private constant VERSION = "1";
    
    // Nonce tracking (only storage that's allowed)
    mapping(address => uint256) private _nonces;
    
    // Request structure
    struct ForwardRequest {
        address from;
        address to;
        uint256 value;
        uint256 gas;
        uint256 nonce;
        uint256 deadline;
        bytes data;
    }
    
    // Events
    event Executed(address indexed from, address indexed to, bool success);
    
    // Domain separator (computed on-demand)
    function DOMAIN_SEPARATOR() public view returns (bytes32) {
        return keccak256(abi.encode(
            keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"),
            keccak256(bytes(NAME)),
            keccak256(bytes(VERSION)),
            block.chainid,
            address(this)
        ));
    }
    
    // Get nonce for address
    function getNonce(address from) public view returns (uint256) {
        return _nonces[from];
    }
    
    // Verify request
    function verify(
        ForwardRequest calldata req,
        bytes calldata signature
    ) public view returns (bool) {
        if (block.timestamp > req.deadline) return false;
        if (req.nonce != _nonces[req.from]) return false;
        
        bytes32 digest = _getDigest(req);
        address signer = _recoverSigner(digest, signature);
        
        return signer == req.from && signer != address(0);
    }
    
    // Execute request
    function execute(
        ForwardRequest calldata req,
        bytes calldata signature
    ) public payable returns (bool success) {
        require(verify(req, signature), "Invalid request");
        require(msg.value == req.value, "Value mismatch");
        
        _nonces[req.from]++;
        
        (success,) = req.to.call{gas: req.gas, value: req.value}(
            abi.encodePacked(req.data, req.from)
        );
        
        emit Executed(req.from, req.to, success);
    }
    
    // Internal: Get typed data hash
    function _getDigest(ForwardRequest calldata req) internal view returns (bytes32) {
        bytes32 structHash = keccak256(abi.encode(
            keccak256("ForwardRequest(address from,address to,uint256 value,uint256 gas,uint256 nonce,uint256 deadline,bytes data)"),
            req.from,
            req.to,
            req.value,
            req.gas,
            req.nonce,
            req.deadline,
            keccak256(req.data)
        ));
        
        return keccak256(abi.encodePacked(
            "\x19\x01",
            DOMAIN_SEPARATOR(),
            structHash
        ));
    }
    
    // Internal: Recover signer
    function _recoverSigner(
        bytes32 digest,
        bytes calldata signature
    ) internal pure returns (address) {
        require(signature.length == 65, "Invalid signature length");
        
        bytes32 r;
        bytes32 s;
        uint8 v;
        
        assembly {
            let ptr := signature.offset
            r := calldataload(ptr)
            s := calldataload(add(ptr, 32))
            v := byte(0, calldataload(add(ptr, 64)))
        }
        
        return ecrecover(digest, v, r, s);
    }
}

System Architecture

Component Overview

The gasless transaction system consists of three primary components that work together to enable seamless user experiences. Each component has distinct responsibilities and interfaces, allowing for modular development and deployment.

Data Flow

Relay Service Architecture

The relay service is a critical off-chain component that bridges users and the blockchain. It must be highly available, secure, and efficient to provide a good user experience while managing gas costs effectively.

Core Modules

Whitelist Strategies

Client SDK

The client SDK abstracts the complexity of creating and signing forward requests, providing a simple API for dApp developers. It handles EIP-712 signature generation, nonce management, and communication with the relay service.

// Example SDK usage
import { GaslessProvider } from '@kitdot/gasless';

const provider = new GaslessProvider({
    relayUrl: 'https://relay.example.com',
    forwarderAddress: '0x...',
    signer: ethers.signer
});

// Execute gasless transaction
const tx = await provider.sendTransaction({
    to: nftContract.address,
    data: nftContract.interface.encodeFunctionData('mint')
});

await tx.wait();

Implementation Roadmap

The following 8-week roadmap provides a structured approach to implementing gasless transactions on Passet Hub. Each phase builds upon the previous one, with clear milestones and deliverables.

Phase 1: Foundational Research & Prototyping (Weeks 1-2)

Phase 2: Smart Contract Development (Weeks 3-4)

Phase 3: Relay Service Implementation (Weeks 5-6)

Phase 4: Integration & End-to-End Testing (Weeks 7-8)

Timeline Summary

Testing Strategy

Unit Tests

Comprehensive unit tests ensure each component functions correctly in isolation. The test suite should achieve >90% code coverage and validate all edge cases and failure modes.

Forwarder Contract Tests

Relay Service Tests

Integration Tests

Integration tests validate that all components work together correctly, testing the complete flow from user signature to on-chain execution.

Security Tests

Security tests attempt to exploit potential vulnerabilities and ensure the system is resilient against attacks.

Performance Tests

Performance tests ensure the system can handle production load and identify optimization opportunities.

Deployment Guide

Prerequisites

Deployment Steps

npx hardhat compile
npx hardhat ignition deploy ./ignition/modules/SimpleForwarder.js --network passetHub

npx hardhat ignition deploy ./ignition/modules/GaslessNFT.js --network passetHub

// .env file
PASSET_HUB_RPC=https://testnet-passet-hub-eth-rpc.polkadot.io
FORWARDER_ADDRESS=0x...
RELAY_PRIVATE_KEY=0x...
WHITELIST_ENABLED=true
DATABASE_URL=postgresql://...

npm install
npm run build
npm start

Post-Deployment Checklist

Maintenance

Ongoing maintenance ensures the system remains reliable and cost-effective. Key maintenance tasks include: