The Complete Guide to Using OpenGSN to Make a Gasless dApp

In recent years, the popularity of decentralized applications (dApps) has exploded. Built on blockchain technology, dApps offer a decentralized and secure way for users to interact with services and applications on the internet. However, one of the biggest barriers to entry for dApp users is the high cost of gas fees, which are required to execute transactions on the blockchain.

Enter OpenGSN (Gas Station Network), a free and open-source tool that allows developers to create gasless dApps. This guide will explain what OpenGSN is, how it works, and how you can use it to make your own gasless dApp.

What is OpenGSN?

OpenGSN (Gas Station Network) is a suite of tools that enables developers to build dApps that don’t require users to pay gas fees. OpenGSN is built on the Ethereum blockchain. The main goal of OpenGSN is to make dApps more accessible and user-friendly by eliminating the need for users to pay gas fees. With OpenGSN, dApp developers can create applications that are not only decentralized but also free for users to use.

How does OpenGSN work

OpenGSN achieves its functionality with the help of these entities:

• Client
• RelayHub
• Relay Server
• Forwarder
• Paymaster
• Recipient Contract

With help of these entities, you can relay a transaction using OpenGSN. Let’s know about these entities and their roles in relaying a transaction in detail.

Client

This entity is responsible for signing and sending meta-transaction to the relay server. Meta-transactions is the term used for the transaction where the gas fee required for the user’s transaction is paid by the relay server. The relay server, after paying the gas, gets back the cryptocurrency amount from the paymaster. In this way, the balance of the relay server is always maintained.

All that client needs to do while making a transaction is to sign the transaction request containing details about the transaction that they are making. After the client has signed the transaction request, the signature is then used to initiate the meta-transaction.

RelayHub

RelayHub connects users running clients, relay servers, and paymasters so that participants don’t need to know about or trust each other.

Under the hood, the RelayHub helps clients discover the best third-party relay server, prevents third-party relay servers from censoring transactions and ensures Paymasters pay back relay servers for gas fees plus transaction fees.

Relay Server

As soon as the request for a transaction is made by a client, it is sent to a Relay Server. It is responsible for validating the transaction and if the transaction is valid, the Relay Server pays for the gas fee required for completing the transaction. It is essential for a Relay Server to have some fee of its own so that it can pay for the gas. After the transaction is made, the Relay Server recovers the amount of the spent gas fee from a Paymaster. In this way, the balance of the Relay Server is always maintained.

Forwarder

The forwarder is responsible for maintaining the security in a meta-transaction-aware smart contract (the smart contract capable of making meta-transactions). The forwarder is responsible for verifying the signature and nonce of the original sender, which helps in verifying that the transaction is being sent by a valid user only.

Paymaster

A Paymaster contract is responsible for paying the amount of cryptocurrency to the Relay Server which it spent for paying the gas for the transaction client made. The paymaster contract is usually deployed and funded by the organization which is willing to pay for their users’ gas fees. Hence, along with the recipient contract, it is also important for an organization to deploy a paymaster contract so that the users don’t have to pay for the gas fee required for a function call.

Recipient Contract

The recipient contract is the smart contract that contains the basic functions that a user can perform. For a recipient contract to be able to perform meta-transactions, it needs to inherit the ERC2771Recipient Smart Contract, which allows the recipient smart contract to use the _msgSender() function. This can be used to replace the msg.sender in the recipient smart contract as all the calls to the recipient contract would be made by the Relay Server, so using msg.sender would give the Relay Server’s address, which would cause logical errors in the code. Hence, to prevent this issue, you need to use _msgSender() which will return you the client’s address that made the function call.

This was all the necessary information that you need to help you get started with using OpenGSN for relaying the transactions for your users. I hope this guide was helpful to you.

To learn more about BuildBear, read here docs

If you appreciate what we are doing, please follow us on Twitter and Join the Telegram group if you haven’t done yet.

And please give us a clap 👏 if you like our work.

Author: Navyansh (Linkedin)