About Gnosis Chain (GC)
For users
For Stakers
For developers
For validators
Contact & Media Info
Meta Transactions
Using Meta Transaction to enable new Burner Wallet users
Meta transactions for new user onboarding
Meta transactions are an important method for onboarding new users. A user without crypto of any kind (no Eth, no Dai, no xDai) can still sign a message and interact with the blockchain without paying transaction fees. These costs are paid instead through an off-chain relayer and relay hub which interacts with a proxy (recipient) contract on the user’s behalf.
In the Burner Wallet (BW) application, a browser-based instant wallet created by Austin Griffith, a user receives a new wallet simply by visiting https://xdai.io/. However, this newly created wallet does not contain any funds, so a new user must figure out how to get xDai. If they don’t have a friend to send it to them, this means they need to somehow get Dai, or get Eth and convert it to Dai - then bridge the Dai to xDai. While none of these processes is extremely difficult, they are a lot to ask of someone who has never used crypto.
This is where the link functionality and meta transactions come in.
The link functionality is a process where a current BW user creates a link (or many links) which contain an amount of xDai. This link can be sent to anyone, and when the user clicks the link, a new wallet opens up and automatically claims the amount of xDai. Since the new wallet is created with a 0 balance, the transaction costs for claiming funds are paid using meta transactions.
Meta Transaction Components
Meta transactions can be accomplished in different ways. In this example we use components from OpenZeppelin's Gas Station Network. Generally speaking, this process requires a User/Dapp to sign a message, Relayers, a Relay Hub, and a Recipient Contract.
- 1.The User/DApp signs a message which includes function calls, arguments and the users signature. This does not require any gas.
- 2.The message is sent to an off-chain relayer. The relayer creates a signed transaction (with the user’s signature details) and sends it to the relay hub.
- 3.The relay hub verifies and funds the transaction and relays it to the the recipient contract.
- 4.The recipient contract executes the method(s) on-chain on behalf of the user.
How it works with link claims on Burner Wallet
In the case of Burner wallet, there are a few additional calls which are made during the link claiming process.
For context we will create a link to be sent to a new user. Creating a link does not use meta transactions.
Creating a link which contains .55 xDai
A user can then claim a link. Claiming a link uses meta transactions. Here we copy the created link and paste into a browser. A link can be sent in any other way (email, text etc). The most common method is to scan a QR code with a mobile device, which creates a new wallet directly on the user's mobile device that scans the code.
Pasting a claim link into the browser.
Meta Transaction process for link claiming with Burner Wallet (BW)
- 1.
- 2.This BW calls the
Links recipient contractto get the Relay Hub Address - 3.BW queries the Relay Hub Contract to get a list of available relayers
- 4.BW sends a signed tx with hashed call data (or requests a signature if connected with metamask) off-chain to the relayers. This does not require gas.
- 5.The first off-chain relayer to respond checks that the signed tx is valid.
- 6.If it is valid, it creates a transaction and sends a
relayCallmessage from a funded on-chain EOA (externally owned account) to the relay hub. - 7.The relay hub sends a
preRelayedCallto the Links recipient contract - 8.Relay hub sends
recipientCallsAtomicmessage to itself - 9.Relay hub sends
preRelayedcall to Links recipient contract - 10.Relay hub sends
claimcall to Links recipient contract - 11.Links contract sends a regular tx to the user with claimed funds. User receives the claimed funds into their BW.
- 12.Relay hub sends final
postRelayedCallto Links recipient contract.
Below is an example claim meta transaction where you can follow the details on encoded messages, logs, internal transactions, and a raw trace of the transaction.
Transaction 0xaa0ad5d6ed4ce7a5f606b631f0f0a50405db66669327bdd0d4c31db39d3f74e4 - xDai Explorer
Implementation details
In our updated implementation, we use an OpenZeppelin Relayer as well as the OpenZeppelin Relay Hub deployed to the xDai network. The Links recipient contract was created to enable link claiming. A prior implementation using version 0.3 was not functional with the new version of Gas Station Network, so we updated this version to work with GSN v1.
- On-chain Relayer Address (intermediary between off-chain relayer and relay hub) 0xc94A34a3f388be34AcaF158FD84331240DAb39a
- Relay Hub. This address is the same on all chains where it is deployed. 0xD216153c06E857cD7f72665E0aF1d7D82172F494
- Pull request where changes were implemented to update contracts to GSNv1: https://github.com/austintgriffith/burner-wallet/pull/255/files
Note: A registration script runs twice daily from the on-chain relayer and calls the
registerRelay method on the RelayHub Contract. This maintains relayer registration on the relay hub.
Example transaction: https://blockscout.com/xdai/mainnet/tx/0xf968e16b7c9ffc57622213365601d89067aee04a7615da8674ebc2404a9c810bRunning a GSN Relay Server
In many instances you may want to run your own GSN relayers which interface with the xDai chain. This provides redundancy if a relayer is not functional, expands capacity, and ensures availability if relayers were removed for some reason from the OpenZeppelin implementation.
Last modified 6mo ago