Gasless Adapter: Enabling x402 Protocol Support for Non-Upgradable ERC20 Tokens

Background

$XNY cannot be used directly as a payment asset in x402. We sought to embed payment processes into API calls for on-chain operations, particularly for AI agents that cannot use traditional payment methods.

The x402 protocol requires either ERC3009 or ERC2612 standards for gasless payments. However, $XNY uses the classic ERC-20 standard only, without ERC-2612 or ERC-3009 extensions. This reflects a broader ecosystem issue: most ERC20 tokens already circulating in the ecosystem do not support ERC3009.

Design Options

Four approaches were evaluated:

• Option A: Issue a New Token - Creates ecosystem fragmentation and high migration costs.
• Option B: Upgrade/Proxy - Impossible since $XNY is not upgradeable.
• Option C: Wrapper Token - Introduces a dual-asset system with liquidity splitting.
• Option D: Gasless Adapter - Exposes an ERC20 interface with ERC2612 / ERC3009 support externally while proxying to the underlying token.

Comparison Matrix

Core Design Architecture

The Gasless Adapter operates as a capability layer with two aspects:

External Interface: Implements full ERC20 plus ERC2612 (permit) and ERC3009 (transferWithAuthorization)

Internal Proxy: Maintains minimal state while forwarding operations to the underlying token. It does not mint or burn any assets and does not hold user funds.

Interaction Flows

Three scenarios demonstrate the adapter:

1. Regular Transfers - Transparent proxy behavior for standard ERC20 operations
2. ERC3009 Gasless Transfers - Users sign authorizations that relayers submit, paying gas on their behalf
3. x402 Integration - Complete payment flow showing adapter integration with the x402 protocol

sequenceDiagram
    participant User
    participant Adapter
    participant Relayer
    participant XNY

    User->>Adapter: signAuthorization(to, value, deadline)
    User->>Relayer: submit(signedAuth)
    Relayer->>Adapter: transferWithAuthorization(...)
    Adapter->>XNY: transferFrom(user, to, value)
    XNY-->>Adapter: success
    Adapter-->>Relayer: success

Advantages

• No modification to original token contracts
• No new token asset created
• Compatible with any ERC20 token
• Reusable infrastructure across projects
• Enables future capabilities like meta-transactions and batch operations

Limitations and Trade-Offs

Technical Constraints

• Requires additional approval transaction
• Adds 5-10% gas overhead
• Maintains separate allowance state from underlying token

Security Considerations

• Adapter becomes critical infrastructure requiring audits
• New attack surface from signature verification
• Non-upgradeable deployment recommended

Deployment Requirements

• Separate adapter needed per token
• Strict security audits essential
• One-click deployment scripts provided

Reference Implementation

Code available at: codatta/erc20-gasless-adapter on GitHub.

Key components include:

// Simplified adapter interface
interface IGaslessAdapter {
    // ERC20 standard
    function transfer(address to, uint256 amount) external returns (bool);
    function transferFrom(address from, address to, uint256 amount) external returns (bool);

    // ERC2612 permit
    function permit(address owner, address spender, uint256 value,
                    uint256 deadline, uint8 v, bytes32 r, bytes32 s) external;

    // ERC3009 gasless transfer
    function transferWithAuthorization(
        address from, address to, uint256 value,
        uint256 validAfter, uint256 validBefore,
        bytes32 nonce, uint8 v, bytes32 r, bytes32 s
    ) external;
}

Conclusion

This is a general pattern: use a capability layer to adapt legacy systems instead of forcing upgrades to the systems themselves. Rather than requiring asset migration or protocol degradation, adapters enable legacy tokens to support new standards while maintaining contract immutability. The pattern can be reused in many contexts.