Gas Station Network (GSN)

The RelayHub is the central on-chain smart contract that coordinates the network. It manages the registration of Relay Servers, which are off-chain entities that:

• Receive, sign, and broadcast user transactions.
• Pay the gas fees upfront.
• Submit proof of work to the RelayHub for reimbursement. This separation of concerns creates a trust-minimized relay layer.

A Paymaster is a smart contract that defines the rules for sponsoring transactions. It acts as the gas fee payer and can implement complex logic, such as:

• Whitelisting: Only paying for specific users or dApps.
• Token Payments: Accepting payment in ERC-20 tokens instead of ETH.
• Subscription Models: Sponsoring gas for users with active subscriptions. The dApp developer or a third party deploys and funds the Paymaster.

To integrate GSN, dApps use a client-side SDK that wraps a standard Web3 provider. This GSN Provider intercepts transaction requests and:

• Discovers available Relay Servers.
• Packages the transaction into a GSN-specific format (a RelayRequest).
• Handles the off-chain signature from the Relay Server. This allows existing dApp frontends to become gasless with minimal code changes.

The end-to-end process for a gasless transaction involves several steps:

1. User Initiation: User signs a meta-transaction (content & recipient) without gas.
2. Relay Selection: Client SDK picks a Relay Server and gets its signature.
3. Relay Submission: Relay Server pays gas and submits the full transaction.
4. On-Chain Verification: The RelayHub and target contract's acceptRelayedCall function verify the request.
5. Reimbursement: The RelayHub reimburses the Relay Server from the Paymaster's balance.

GSN uses cryptographic proofs and economic incentives to align participants:

• Relays stake ETH in the RelayHub and can be penalized for malicious behavior.
• Paymasters must maintain a deposit to cover gas costs.
• dApps can choose trusted Relay sets. Users only trust the dApp's chosen Paymaster and Relays, not the entire network. Relays earn a small fee on top of gas reimbursement.

Two critical smart contract interfaces enable the meta-transaction logic:

• Forwarder: A contract that verifies the user's meta-transaction signature and nonce to prevent replay attacks.
• IRelayRecipient: The interface that a destination dApp contract must implement. Its acceptRelayedCall function allows the contract to accept or reject the gasless request based on custom logic before execution.

A GSN transaction follows a specific relay cycle:

• User Signing: A user signs a transaction request, authorizing the action but not paying gas.
• Relayer Selection: A decentralized network of relayers picks up the request.
• Gas Payment & Forwarding: The relayer pays the gas fee in the native token (e.g., ETH) and forwards the transaction to the blockchain.
• Reimbursement: The relayer is reimbursed from a RelayHub smart contract, which is funded in advance by dApp developers or sponsors.

The GSN protocol is built on two key smart contracts:

• RelayHub: The central registry and payment manager. It holds stakes from relayers, manages balances for paymasters, and handles the reimbursement logic.
• Paymaster: A smart contract that defines who pays for gas. It can be funded by the dApp to sponsor user transactions (gas abstraction) or implement custom rules (e.g., only paying for specific function calls). This separates payment logic from application logic.

The GSN's main adoption driver is eliminating the initial gas barrier for new users. Before GSN, a user needed to:

1. Acquire crypto (e.g., ETH) from an exchange.
2. Pay a gas fee for their very first transaction. This is a major hurdle. With GSN, dApps can sponsor a user's first interactions, allowing them to mint an NFT, vote in a DAO, or swap tokens without first buying the native token, dramatically improving user experience and adoption.

GSN has been integrated by projects seeking frictionless onboarding:

• Unstoppable Domains: Used GSN to allow users to claim free domains without paying ETH gas.
• DAOs (e.g., Aragon): Enabled gas-less voting for governance participants.
• Wallet Providers: Wallets like Argent integrated relayers to offer gas-less transactions for their users, subsidizing costs as a service feature.

Using GSN introduces specific design considerations:

• Smart Contract Upgrades: dApp contracts must inherit from GSN-compatible base contracts (like RelayRecipient).
• Relayer Trust & Decentralization: While relayers are permissionless, dApps must consider the liveness and censorship-resistance of the relay network.
• Economic Model: dApps must carefully fund their Paymaster contracts and manage the cost of sponsoring user transactions, which can become significant at scale.

GSN is a precursor to full Account Abstraction (ERC-4337). Both aim for gas abstraction, but with different architectures:

• GSN: A protocol-level solution using external relayers and a central RelayHub.
• ERC-4337: A more generalized, contract-based standard using Bundlers and a UserOperation mempool. While GSN solved the problem for specific use cases, ERC-4337 aims to make gas-less transactions and sponsored gas a native, flexible feature of the Ethereum ecosystem.

The core infrastructure of the GSN, consisting of independent relay servers that broadcast meta-transactions on behalf of users. These relays are compensated by the RelayHub contract for their work. Key components include:

• Relay Server: Off-chain service that receives, signs, and forwards transactions.
• RelayHub: On-chain registry and payment manager for relays.
• Paymaster: A contract that defines who pays for the gas and under what conditions.

A smart contract that sponsors transaction fees, determining the business logic for gas payment. It can be configured for various models:

• Contract Pays: The dApp's contract covers fees for all users.
• Whitelist Pays: A designated sponsor pays for a specific set of users or actions.
• ERC-20 Token Pays: Users pay fees in an ERC-20 token, which the Paymaster converts to native gas. The Paymaster must hold a stake in the RelayHub to prevent spam and must implement the acceptRelayedCall function.

The fundamental building block that GSN utilizes. A meta-transaction is a regular transaction where the signature and execution are separated. It contains:

• The original user's signed request (the "meta" data).
• A signature from a relay that pays the gas. This allows a third party (the relay) to submit the transaction and pay the gas fee, while the user's signature authorizes the intended on-chain action. GSN standardizes this process with EIP-2771 for secure recipient context.

A more advanced and flexible alternative to the GSN for gasless experiences. Instead of relying on a relay network, ERC-4337 introduces UserOperations and Bundlers. Key differences:

• Smart Contract Wallets: Logic is defined in a wallet contract, not an external Paymaster.
• Bundlers: Nodes that package UserOperations and execute them, similar to relays.
• Paymasters: Still exist but are integrated into the AA flow, offering more granular sponsorship rules. ERC-4337 aims to make gas abstraction a native wallet feature rather than a dApp-level add-on.

The broader concept of a third party covering network fees, which GSN implements. Sponsorship is a critical user acquisition tool. Common sponsorship models include:

• Full Sponsorship: The dApp pays for all user transactions (common for onboarding).
• Partial Sponsorship: The dApp pays for specific, high-value actions (e.g., first trade, NFT mint).
• Subscription Model: Users hold a token or NFT that grants them sponsored transactions. These models are enforced by the logic within the GSN's Paymaster contract.

An Ethereum Improvement Proposal that defines how to securely forward meta-transactions. GSN-compatible contracts use this standard to preserve transaction context. It solves the critical problem of msg.sender spoofing by:

• Introducing a Trusted Forwarder contract that verifies the meta-transaction.
• Providing the real user address (_msgSender()) to the receiving contract. This ensures the final contract interacts with the correct user, not the relay, maintaining security and enabling gasless interactions for any existing contract that implements support.