Announcing The Generalized MetaTransaction Contest

At MetaMask, we strive to enable the best possible user experience for building and interacting with decentralized applications. This means reducing user friction wherever we can, and we believe we have a way that requires a new Ethereum interface-layer EIP, which we would like to invite the wider developer community to help define, with our new GitCoin Take Back The Web Hackathon bounty: The Generalized MetaTransaction Contest.

Today, our users have to hold ether in every account to pay transaction fees for even the smallest interaction, to prevent them from spamming the network. This is a lot of overhead, especially when in many cases, a third party may be willing to pay a user’s transaction fees. This pattern of third-party transaction fee payment is known as Meta-Transactions, as popularized by Austin Thomas Griffith.

There are two major ways that MetaTransactions can become available to users, and we are working towards both, but this bounty will focus on the latter.

The Contract Account Approach

We look forward to allowing every user to have a contract-based account, and these accounts could support MetaTransactions natively. We are currently facilitating this goal with our Snaps plugin system, which will eventually support any number of different account types, such as the Gnosis Safe wallet, which already supports this type of MetaTransaction today.

The Contract Based Approach

The second major approach to allowing MetaTransactions is for contracts to expose a MetaTransaction processing method on themselves. We have seen some projects recently begin driving this forward, with Bounties Network (code) and Dai Stablecoin‘s permit method each exposing methods to facilitate third-party gas payment.

These approaches stand out because they do not require widespread adoption of a single type of account: Your dapp doesn’t need to handle each kind of contract account a user has, and it works out of the box today, and will continue to work for any key-authenticated method in the future.

Even once we support contract accounts, we expect there will still be some normal, external-key-based accounts, either to reduce the cost of publishing a contract for the account, or because a key may be used to manage a very small quantity of funds or permissions.

For these reasons, we’d like to see methods like Bounties and Maker have pioneered not only succeed, but to stand as the basis for new standards going forward.

Towards a Generalized Standard

One thing you’ll notice if you refer to either of the Bounties or Maker examples above, is that these MetaTransaction methods are all written bespoke to specific methods: Each method has its own MetaTransaction method handler. This is a lot of developer overhead!

At MetaMask, we were looking at these different methods, and considering which ones we could support and render more beautifully, and it occurred to us that it would be much nicer if we simply had a standard way of defining any method as MetaTransaction enabled, so that any contract could include a single function, and their users could now interact without gas payment (provided someone is willing to pay the tx fee).

Furthermore, wallets would be able to render these gas-free transactions the same way they render their normal Ethereum transactions today, and would benefit from all the many improvements they add in the future.

Rather than waiting for someone to define this standard specification, we’d like to encourage broader creativity on this issue, and so we’re opening a bounty on the Gitcoin Take Back the Web Virtual Hackathon. If you’d like to see this happen, we encourage you to contribute to the prize, or to strive to earn it!

The Gas Station Network has made efforts at a generalized standard, but it is currently oriented at totally ephemeral accounts, and not the portable, user-held keys that MetaMask makes possible, and so it’s possible their standard could be used or extended for this purpose.

Strong Suggestions

We’d like to see a standard that leverages the signTypedData_v4 method, which is what the Maker permit() method does. You can see some sample JS usage of the permit signature here.

This method should be able to call any method on the contract, probably using that method’s 4-byte method identifier, which would allow wallets like MetaMask to render nice confirmations for users using this method.

Looser Suggestions

This method may allow some mechanism for repaying the submitter/relayer (to allow paying them back in an asset other than Ether, for example). This may be more than we should strive for in a first spec, but it would definitely make a proposal stand out!

This method may make use of a nonce, but for some use cases, allowing these messages to be submitted in any order may be an advantage, and so another replay-protection measure may be preferable!

If you want to get deeper into the mad science, there is a thread of speculation where a standard like this could evolve here.

Conclusion

All bounty submissions must be received no later than 11:59 PM EDT on Jan 23 2020 to be considered.

The winner will be announced no more than 24 hours after the contest ending time, no later than 11:59 PM EDT on Jan 24 2020.

The entries will be judged by a number of pioneering developers of MetaTransactions across the Ethereum ecosystem.

We’ll be available for support during the hackathon on our Keybase team metamask.developers.

We hope this has gotten you EVM developers’ imaginations flowing. With a generalized contract MetaTransaction format, we believe we can elevate the entire ecosystem dramatically, together.

Add to the bounty, or sign up to earn it on GitCoin.