What is the Gas Station Network?
User onboarding is one of the hottest topics in Ethereum. UI/UX along with scalability have been identified as the main problems that prevent adoption. Meta-transactions are a key component to improve the user experience. Here you’ll learn what the Gas Station Network (GSN) is and how it solves this problem, by allowing users of a contract to send transactions without needing Ether to pay for gas.
All Ethereum transactions use gas, and the sender of each transaction must have enough Ether to pay for the gas spent. Even though these gas costs are low for basic transactions (a couple of cents), getting Ether is no easy task: dApp users often need to go through Know Your Customer and Anti Money-Laundering processes (KYC & AML), which not only takes time but often involves sending a selfie holding their passport over the Internet (!). On top of that, they also need to provide financial information to be able to purchase Ether through an exchange. Only the most hardcore users will put up with this hassle, and dApp adoption greatly suffers when Ether is required. We can do better.
Enter meta-transactions. This is a fancy name for a simple idea: a third-party can send another user’s transactions and pay themselves for the gas cost. That’s it! There’s some tricky technical details, but those can be safely ignored when interacting with the GSN. This way, instead of your users calling into your contract (called the recipient) directly, someone else (we’ll call them a relayer) will send their transaction and pay for the cost.
But why would they do such a thing?
Relayers are not running a charity: they’re running a business. The reason why they’ll gladly pay for your users' gas costs is because they will in turn charge your contract, the recipient. That way relayers get their money back, plus a bit extra as a fee for their services.
This may sound strange at first, but paying for user onboarding is a very common business practice. Lots of money is spent on advertising, free trials, new user discounts, etc., all with the goal of user acquisition. Compared to those, the cost of a couple of Ethereum transactions is actually very small.
Additionally, you can leverage the GSN in scenarios where your users pay you off-chain in advance (e.g. via credit card), with each GSN-call deducting from their balance on your system. The possibilities are endless!
You don’t need to! The GSN is set up in such a way where it’s in the relayers' best interest to serve your requests, and there are measures in place to penalize them if they misbehave. All of this happens automatically, so you can safely start using their services worry-free.
There are many meta-transaction implementations out there, but the GSN has a unique detail that makes it special. Inside its core, a smart contract is responsible for keeping track of relayers, handling relayed transactions, charging their recipients, and generally ensuring all parties stay honest. This contract is called RelayHub, and there is a single instance of it in the whole network (you don’t need to deploy your own!). Think of it as a piece of public infrastructure, for all Ethereum users to benefit from.
One of RelayHub’s jobs is to act as a, well, hub for all relayers: they will advertise their services on this contract, and your users will query it to find the relayer that best suits their purposes. This is out of scope for this guide however, and is not something you need to worry about when writing a recipient contract. If you want to learn more about sending transactions via relayers, head to our GSNProvider guide.
The other key task RelayHub carries out is the actual relaying of transactions, the sole purpose behind this whole system. Instead of calling a function in your contract directly, your users will request a relayer to do it for them, who will then execute RelayHub’s relayCall function. RelayHub will verify that the transaction is legitimate (protecting both users and recipients from dishonest relayers), and then call into your contract as originally requested by your user. This requires your recipient trusting RelayHub to do the right thing, but since it is a smart contract, this is as simple as reading its source code!
The RelayHub address will be the same in each network. Right now, the latest relay hub is live at this address:
We’ve mentioned how the RelayHub, and not your user, is the one that actually ends up calling a function in your contract. We will refer to this as the relayed call. Your contract needs to be set up to accept relayed calls from the hub. In particular, it needs to be able to answer whether it will pay for a given relayed call, and run some bookeeping to make sure a malicious user cannot abuse it. It also needs to unwrap a relayed call in order to process it.
The OpenZeppelin Contracts package includes a number of utilities to make receiving relayed calls as easy as developing a regular Solidity contract, without needing to worry about the low level details. It also ships with two built-in strategies for managing relayed call subsidies.
By now you may be wondering how exactly relayers charge their recipients for gas costs and service fees. The answer is simple: each recipient must have funds deposited on RelayHub in advance, and payment is automatically handled on each relayed call.
Recipients may withdraw their balance from the system at any point, but remember that they will not be able to receive any further relayed calls!
To recap, there are four main actors in the GSN:
A singleton RelayHub contract, that coordinates the entire network. All relayed transactions need to go through it, and all relayer stakes and recipients funds are held by it.
A decentralized set of Relayers. A relayer must register itself on the RelayHub by staking funds, as the hub penalizes it if it misbehaves.
A set of Recipients, which are the dapp contracts that pay for their users' transactions. Recipients need to deposit funds on the hub in order to pay for the relayed calls, and need to adhere to a specific interface to accept the meta transactions.
The end Users of the recipient contracts. Instead of sending regular Ethereum transactions, these users can just sign a transaction with any key, and send it off-chain to a Relayer to be sent to the network.
The GSN announcement post provides a good overview of the system, along with some use cases to take inspiration from.
To learn how to use OpenZeppelin Contracts to build a GSN-capable contract, head to the GSN basics guide.
If you want to learn how to use OpenZeppelin Contracts' pre-made accept and charge strategies, go to the GSN Bouncers guide.
If instead you wish to know more about how to use GSN from your application, head to the OpenZeppelin GSN provider guides.
For information on how to test GSN-enabled contracts, go to the OpenZeppelin test helpers documentation.