Our MetaTransaction Hackathon Winner!

Dan Finlay
Jan 31 · 7 min read

Wait no longer, we are writing to announce the conclusion of MetaMask’s first ever virtual hackathon, our Generalized MetaTransaction Contest, part of GitCoin’s Take Back the Web hackathon.

We began this contest with the goal of engaging community participation around the formation of a standard that could benefit a wide variety of wallets with the smallest effort on the part of developers and end users, and we couldn’t be happier with the results.

We knew this was not an easy task, which is why we posted what was the largest prize for the hackathon. After posting our 20 eth bounty, GitCoin raised the prize by 1000 DAI, bringing the total prize pool to around ~$4500 equivalent at today’s rates. We were hoping to get even a few people to take a shot, but what we got was so much more.

  • 28 participants registered and began work.
  • 12 participants submitted work.
  • 7 participants submitted work correctly by the deadline.
  • 4 participants satisfied every one of our suggested ideal criteria of a general purpose framework that allows any smart contract to support MetaTransactions for any user (even normal key-based accounts), along with interactive demos that work today. 🤯
  • Bloxis wrote a wonderful blog post advocating for the value of this goal.
  • We got a big thread on ethereum-magicians discussing the initiative.

Maybe most importantly, we saw a lot of incredibly talented Ethereum developers come together to share ideas and refine their approaches on our metamask.developers keybase channel.

On to the Entries!

Before we discuss the finalists, I’d like to take a moment to mention a couple outstanding features from some of our runners-up.

Adamzolla’s Lava Protocol created a global smart contract that would allow adding MetaTransactions to any ERC-20 token today. However, since it relies on setting the allowance for those tokens first, we felt it was not as truly gas-free as we wanted from a winner, but it still stands out as a totally unique contribution that could absolutely have use on the main-net today. It even includes a working demo!

Chris Buckland and Patrick McCorry submitted some excellent research towards a MetaTransaction standard, and included three replay protection strategy proposals, which include features totally unique to all the entries, like supporting various degrees of concurrency. The judges had to rule this one out from the finalists because it wasn’t quite oriented at developers being able to use it immediately, nor did it have a demo, but this one makes important contributions to our understanding of what we can achieve with replay protection, so we had to give it a big nod.

The Finalists

We were incredibly lucky to have three MetaTransaction-celebrity judges volunteer to help evaluate our submissions:

  • Mariano Conti of Maker, which recently shipped a MetaTransaction permit() method on its new DAI contract.
  • Mark Beylin, Founder of Bounties.network and the StandardBounties framework, which included a MetaTransaction method on its latest contract.
  • Austin Griffith, who popularized MetaTransactions with many developers.

Upon reviewing the entries, we quickly realized we had enough high-quality entries that we were forced to hold a very high standard for the winner.

As MetaMask’s first hackathon prize ever (we’ve done mostly word of mouth!) we hadn’t considered that we’d get tons of great submissions, and so we hadn’t announced any runner-up prizes, so we were preparing to make a very hard decision.

At the time of judging, we had three finalists who had satisfied what we were calling “the high water mark”:

  • A new standard that only requires inheriting a solidity class and replacing all calls to msg.sender to an internal method that is aware of the new MetaTransaction method, like _messageSender().
  • Adds a new method that allows anyone to submit transactions on behalf of other users to this contract.
  • Has support for batches of transactions.
  • Allows the original transaction signer to include a fee to the submitter.
  • Features a clean working demo that you can try right now.

Those finalists were:

Each of these entries stood out in big ways:

  • Working demos
  • EIP-712 compatible signatures, making for more readable signatures (with a possibility of being standardized and rendered better later)
  • A generic solidity class that can be inherited from on any solidity contract to add support for MetaTransactions for all of its methods.

The judges were so impressed, that we decided we wanted to take more time to more deeply understand the entries, and so each judge took a different finalist entry to review in more detail, perhaps try building with, and report back to the group, so that we could have a more informed perspective on the submissions.

amxx’s demo site is a beautiful MetaTx-powered on-chain chat room.

Let’s review some of the key features that distinguished our finalists:

Community Engagement

We never said this would be a judging criteria, so we didn’t weigh it too heavily, but we did say that likelihood of getting widespread adoption was a goal, and we believe that in a decentralized ecosystem, community engagement is an important strategy! So we gave extra credit to contestants who started conversations, sought out the best ideas, and shared their own ideas freely during the contest. Amxx was particularly active during our contest, but wighawag and Yoav had each built on EIPs, highlighting a long-running commitment to community standards.

Developer Documentation

Widespread adoption isn’t just about having a great proposal, it’s about communicating it in a way that gets developers to quickly understand what it is, how to use it, and building it into their own contracts. Amxx and wighawag both stood out as having very developer-friendly introductions, as if they were writing to future devs, and not just hackathon judges.

Yoav made a demo site that allows managing a token without the user needing ether.

Simplicity

This contest was already asking for a lot of complexity, and asking devs to add some new code to their contracts is a scary thing to ask already, so making the smallest and most easily audited contribution possible has serious impact on how likely people are to adopt it. yavw took a slight hit here, because by using GSN, they took the complicated issue of fee repayment, and added a whole additional crypto-economic game on top of it. We found evaluating the game theory of the GSN to be slightly out of scope for this contest, and so we preferred proposals that had the option of integrating with GSN, like Amxx’s.

Fee Repayment

We did not require submissions to include a method to repay the transaction relayer, since we believed there was already a lot of value to be had by accounts that were willing to relay each others’ transactions. That said, the submissions by amxx, wighawag, and yavw all had methods to optionally repay the relayer in an arbitrary token. That opens those submissions to a whole category of extra usage.

Biconomy’s demo app was elegantly simple and easy to prove what it did, with a simple quote-owning contract.

Replay protection

In our intro post we mentioned that replay protection was a looser suggestion, but when all the other criteria were met so well by all the front-runners, it became a valuable way to stand out. As it was, of the four finalists, three used a classic Ethereum-style nonce for replay protection, and one (wighawag) implemented a two-dimensional nonce, which allows transaction parallelization and batching.

Amxx also took a small hit in this category, because his replay protection scheme involved writing each transaction hash to blockchain state, which increases the gas price of these transactions. Reducing state bloat over time is a valuable property that we’d like to see more contracts value.

Batch Processing

We did not list this as a requirement, but there are big blockchain throughput gains to be had by batching transactions together. Both amxx and wighawag had batching mechanisms in their submissions, but wighawag’s included the ability for the batch to share a signature, slightly improving performance, which is always valuable on a blockchain.

Finally, the Winner

For drafting a simple yet flexible EIP, making a working demo and code that any developer could try out today, all with replay protection that stood out from all other working submissions, we have decided to award our one prize to wighawag.

Some other stand-out details from wighawag’s entry included heavy reuse of existing EIPs, thoughtful consideration of handling gas limits and failed transactions, using the solc 0.6.1 compiler (very forward-looking), and a UI that is both simple but also allows exploring the more advanced parameters of the protocol. Also by using a global singleton proxy contract, contracts using this standard re-use deployed code (making them cheaper), and transactions are able to be refunded in other tokens than the contract being called.

A screen shot of wighawag’s demo site and one of its EIP-712 signatures, which is both binary efficient and fairly human readable (and will only become more so as it gets more feedback and adoption :wink:)

Next we’re hoping to help see wighawag’s EIP-1776 proposal get more experimentation, some security auditing and bug bounties, and then some broader proliferation, with hope of eventually rendering messages like this like normal transactions in web3 wallets like MetaMask.

At MetaMask, we loved the top entries so much that we decided the other three finalists deserved prizes too, so they will be receiving bonus prizes of 500 DAI each, and in future hackathons we’ll be sure to include dedicated runner-up prizes.

This hackathon absolutely exceeded our expectations, and has really forced us to rethink what contests can achieve in this space.

We’d like to thank GitCoin, our judges, and all the contestants for moving the needle and making Ethereum get just a little more usable.

What do you think we should do for our next hackathon contest? What do you think would take these entries to the next level? Leave a reply below and let us know!

MetaMask

MetaMask is a bridge that allows you to visit the distributed web of tomorrow in your browser today. It allows you to run Ethereum dApps right in your browser without running a full Ethereum node.

Dan Finlay

Written by

Decentralized web developer at ConsenSys working on MetaMask, with a background in comedy, writing, and teaching.

MetaMask

MetaMask

MetaMask is a bridge that allows you to visit the distributed web of tomorrow in your browser today. It allows you to run Ethereum dApps right in your browser without running a full Ethereum node.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade