GSN Frequently Asked Questions

GSN stands for Gas Station Network. Originally conceived and designed by TabooKey the GSN has grown to encompass many companies in the Ethereum space looking to work together to solve the problem of onboarding users to Ethereum applications.

The Gas Station Network is a decentralized network of relayers which can be used to sign and send Ethereum transactions without the original sender (the end-users) paying for gas.

Users sign messages (not transactions) containing information about a transaction they would like and arguments they would like to pass. relayers are then responsible for signing valid Ethereum transactions with this information, and an inherited GSNRecipient contract preserves the identity of the user that originally requested the transaction. In this way, users can interact directly with smart contracts without needing to have a wallet or own ETH.

As GSN is intended primarily to solve the user onboarding problem, it is expected that the (d)app developers themselves will be responsible for paying the gas cost of users. In this case, gas costs should be considered the cost of user acquisition.

Alternatively, the GSN can be used for more specific situations, such as paying for DAO users transactions from a DAO treasury account, or contracts where users pay for their transactions via counterfactually deployed smart contracts.

Normally when interacting with the Ethereum network and smart contracts, it is required that the user pay gas in the form of ETH to compensate the Network for the cost of processing transactions.

When using GSN, the Ethereum network still requires gas as payment to sign transactions, but it is no longer necessary for the user to pay. Instead, a network of relayers pay the gas cost by signing transactions in the name of users and the relayers are then refunded directly by the contract the users wish to interact with.

For relayers to pay the gas cost of signing transactions, it is required that the contract with which the user is interacting be GSN enabled. To enable GSN a contract must inherit from the GSNRecipient contract in the OpenZeppelin Contracts library.

No, relayers are only able to pay the gas cost of signing transactions for GSN enabled contracts that conform to the GSN specification. Arbitrary contract calls to non-GSN enabled contracts, or for tasks such as sending ETH or mining ETH are not currently supported.

While relayers pay the gas cost for users, this does not mean they have access to users' private keys. The GSNRecipient contract has a utility function called \_msgSender() which is to be used in place of the solidity system variable msg.sender and returns the true address of the user - even when transactions are signed by the relayers private key.

User private keys are never shared or exposed to the relays.

The GSN network and smart contracts have been audited by OpenZeppelin and are considered to be safe. As the relayers do not have access to users' private keys there is no danger of user funds being stolen via stolen private keys.

The original Gas Station Network EIP: 1613 lists several theoretical attacks against the relay network which have been accounted for by the software implementation and the Relay network should be considered safe.

As always, applications that intend to store large amounts of value should consider carefully their software architecture design to minimize the opportunity for unaccounted for edge cases which could lead to a reduction in security and loss of funds.

The GSNRecipient contract has a utility function called \_msgSender() which returns the true address of the user making a contract call. The function \_msgSender() should be used in place of the solidity system variable msg.sender.

The GSN network is built to be compatible with the Ethereum network in its present state. This means that for relayed transactions, msg.sender will return the address of the relayer signing the transaction, and not the user requesting the transaction. Contracts that use msg.sender are not natively compatible with the Gas Station network. It is necessary to inherit the \_msgSender() function from the RelayHub contract in the OpenZeppelin Contracts library if your contract needs to identify the initiator of a GSN powered transaction.

(D)app owners can choose from basic predefined payment strategies or construct their own. The OpenZeppelin Contracts GSNRecipient contract provides for pre and post-payment hooks that can be used to verify that a contract function and user are eligible for the transaction cost to be covered by a Relay as well as allow users to pay relays in tokens rather than ETH.

When deciding how many payments and for how much to cover, (d)app owners should consider what they expect the total cost of payment to be, and how they will identify who are their users. It is up to (d)app owners to decide how they will identify who is an eligible user.

To use GSN it is not necessary for users to have ETH or even have a wallet such as Metamask. This makes it ideal for creating universally accessible (d)apps that work equally as well on mobile as on desktop.

With GSN, private key (keypairs) are only necessary to sign a message for the relayers to process as normal Ethereum transactions. Users need not store value on this keypair and thus the security necessary for this key pair can be tuned to match the requirements of the (d)application.

It is expected that in the majority of use cases the users' keypair will be generated in-browser ephemerally. For persistent keypairs (d)apps can store this keypair in local storage, or leverage traditional web2 technologies to present users with a typical web2 login experience.

Although GSN does not require a wallet provider such as Metamask, it is possible to use a wallet provider in conjunction with GSN for novel use cases. An example would be an application which requires users to register via a normal (non-gsn) Ethereum transaction and then for some time afterward, they would not be required to use Metamask to sign each transaction, rather the transactions would be handled by the GSN relays. This could be very convenient for applications which require a high number of transactions and where a confirmation popup for each transaction would be distracting or give a poor user experience.

OpenZeppelin will be producing several guides and tutorials to help developers integrate GSN into their smart contracts and (d)applications. The process is rather straightforward and involves only inheriting a GSNRecipient contract in the smart contract. It is up to developers to decide how and when they wish their users to send transactions via the GSN network.

An interesting use case for the GSN network is allowing users to pay for transactions via credit cards. An example way this might work would be charging a user directly for tokens that are then used to access services via the (d)application. The tokens can be held in a contract representing a users balance, and when making a transaction using the GSN their token balance can be decremented to cover the 'cost' of each transaction.

The GSN network is open source and anyone is free to run a relayer. It is envisioned that there will be many independent relayers each offering different uptime guarantees and service pricing. GSN enabled applications are free to use any relay that they choose, it is not required for a (d)application to run a relayer.

Relay providers deposit a stake in the RelayHub while (d)app owners deposit a balance.

The balance deposited by (d)app owners is used to refund relayers for the cost of relaying transactions plus a small fee so that they can cover their expenses and hopefully make a profit.

Relay providers are required to deposit a stake into the RelayHub to ensure good behavior. In the event a relayer behaves badly (for example attempting to reuse a nonce) their deposit can be slashed and collected by other relayers which can then prove on-chain a relayers bad behavior. This system of checks and balances is one of the features that keep the GSN safe and ensures that some forms of attacks against the network do not scale.

No. The funds which are used by a smart contract application to pay for a user’s gas costs are stored in the audited RelayHub contract. This contract is already deployed at the same address on every network (testnet, mainnet, etc..) and does not need to be managed by (d)app developers.

Developers need to ensure that the balance stored on RelayHub is sufficient to cover the cost of their users' transactions. If there is not a sufficient balance to cover the cost of relaying transactions, no transactions will be processed for the smart contract application until the balance is increased.

OpenZeppelin has created several convenient web-based tools to manage your applications' GSN transactions. There is a tool for (d)app developers as well as for relayers.

As GSN does not require a user-supplied provider such as Metamask, it will work fine with or without a user-supplied provider. Developers will still need to connect the (d)app to a web3 provider, for example via Infura to receive events or query the Ethereum blockchain.