If I understand correctly, A meta-transaction pattern is a like a middleware software between the client and the blockchain that pays for the transaction fees.

If I sign a transaction and send it to the middleware software, is my transaction signature already contains information like (from: account to charge with transaction fees). How does this really work without compromising too much decentralization.

3 Answers 3


To break this down, I'm gonna briefly explain how meta-transactions work, and then I'll explain how it can be decentralized.

  1. You must have a private/public keypair
  2. Someone creates a 1-of-x multi-sig account for you. You can do this yourself or it could be some wallet provider. The address from step 1 is used as the authorized account on the multi-sig
  3. When you want to create a transaction, you sign a message that the multi-sig can A. Verify the signature of, and B. Execute as if it was a transaction, e.g. you would be signing a destination address, msg data, and the value to send.
  4. You submit this signed message to what people are calling a "relayer". These are just services that take your message, bundle it in an actual transaction, and send it to your multi-sig. This may or may not involve a fee paid in eth or tokens from the multi-sig.
  5. Your multi-sig verifies the msg was signed by an authorized account and executes the message just like it was a transaction.

There are of course centralization issues in the above scheme, in that if I use some wallet that has a hard-coded "relayer" (which would just be a url or IP address), then I'm relying on that service provider to be active and online. Of course they can't perform things I don't authorize, but them being offline still makes things hard on me.

One way to get around this is to standardize on a meta-tx-relayer API such that:

  1. Anyone can pass their signed message to any standard abiding relayer

  2. There is a discovery protocol similar to the one used in Ethereum clients that allows me to find many different active relayers so I have backup in case some go down or fail to run my transaction

  3. There is a standard, agreed upon way to incentivize relayers to run these messages. This would probably be by having the messages you sign actually be lists of messages, where the 1st one is a token payment to the relayer that is submitting.

    A similar but nicer method for the relayer would be for the 1st transaction in the list to always be to Uniswap, paid in whatever token the user wants, so the relayer can always accept ETH.


The generalization of meta transactions responds to the problem of user onboarding on Ethereum applications.

What's the problem with gas?

Gas is the execution fee for every operation made on Ethereum. Current solutions (based on client-side wallet like MetaMask) are perfect from a decentralization point of view and very easy to integrate for developers (no backend), but in terms of user experience for non-crypto experts (99% of the population), managing keys or buying gas is far too complicated today.

Short and simplified explanation

Your future users don't care about Blockchain, keys and gas. It's up to you to provide solutions to abstract the Blockchain complexity.

To keep the benefits of a decentralized system, the solution must guarantee these properties (by @cooganbrennan):

non-corruptibility: you know the data has not been tampered with

identity: you know the transaction is definitely from the person who sent it

non-repudiation: the person who sent it can not rescind the transaction later

A possible solution: off-chain message signing for on-chain use.

Deploy for each of your users a smart contract which will be their identity on the Blockchain.

The "identity smart contract" will only execute transaction if the signature comes from address authorized by the identity owner (your user).

The user can prove his intent to take action by signing a message on client-side (mobile app or browser for example) (no gas needed to sign a message).

Who relay the message to the identity smart contract?

It is a question of economic incentive, if you are ready to pay the cost of the transactions of your users, you will be in charge of creating the transaction "envelope". It will contain the transaction to be performed by the identity smart contract.

Initiatives exist to create and remunerate a network of relayers in order to limit the centralization created by the generalization of meta-transactions.

Some good (live) solutions

Some applications like Argent.xyz have perfectly used the principle of meta-transactions, the details of their implementation are available here - I think that this is the main reason for their success, they finally make services based on the Ethereum Blockchain accessible to everyone.

Available API to go fast

Finally (disclaimer, I'm the CTO of Rockside.io), even if meta-transactions are a bit of a magic solution for end users (good trad-off between usability and decentralization), their implementation remains complex for developers so we tackled this problem. According to the use case, we have created a very simple API to create smart contract identities and manage meta-transactions. Feedback is welcome and appreciated!


The actors of this scheme are:

  • User: signs a meta transaction (that is a message containing information about the transaction he would like to execute).
  • Relayer: a web server with a wallet that signs a valid Ethereum transaction (that has the meta transaction as the payload) and sends it to the blockchain.
  • Forwarder: an Ethereum contract in charge of verifying the signature of the meta transaction that, not surprisingly, forwards the request to a recipient contract.
  • Recipient: the Ethereum contract that the user intended to call without paying the gas fee, this contract has to be able to preserve the identity of the user that initially requested the transaction.

If you want more details on how it works, I suggest you this article: Meta Transactions explained. There you can find a simple implementation of the whole mechanism and a demo online.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.