Gitcoin is GDPR complaint. Learn more in
Gitcoin's Terms & Conditions.
Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
### Prize Bounty
### Challenge Description
MetaMask would like to see someone implement a generalized MetaTransaction standard that could be added to any smart contract to allow MetaTransactions from any externally-owned (key-based) account.
We’d like to see a working implementation of a method that could be added to any smart contract that allows MetaMask users (and users of any key-based accounts) to interact with that contract without gas, by signing a message that is submitted by another account that does hold ether to pay gas.
You can find a more complete description of the context of this bounty [on our blog](https://medium.com/metamask/announcing-a-generalized-metatransaction-contest-abd4f321470b).
### Submission Requirements
#### Strong Suggestions
We’d like to see a standard that leverages the [signTypedData_v4 ](https://metamask.github.io/metamask-docs/API_Reference/Signing_Data/Sign_Typed_Data_v4 )method, which is what [the Maker permit() method](https://github.com/makerdao/dss/blob/870d6fddb75090eb177290b1db4e255d2c31075e/src/dai.sol#L117-L141) does. You can see some sample JS usage of the permit signature [here](https://github.com/mosendo/gasless/blob/7688283021bbdb1c99b6951944345af0ba06e036/app/src/utils/relayer.js#L38-L79).
The difference is that instead of only invoking the allowance method, as this essentially does, we’d like a generalized method that could invoke any method on the contract, probably using that method’s 4-byte method identifier, which would allow wallets like MetaMask to render nice confirmation screens for users signing messages using this approach.
At the very least, we would like to see a proposed standard interface for processing these messages, but working code demonstrating these signatures both from MetaMask and being validated in an EVM smart contract would be ideal.
#### 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](https://github.com/KamesCG/rapid-community/issues/1).
### Submission Deadline
All bounty submissions must be received no later than 11:59 PM EDT on Jan 23 2020 to be considered.
[An intro to the contest](https://medium.com/@danfinlay/abd4f321470b)
[The metamask.developers Keybase Team for live support](https://keybase.io/team/metamask.developers)
### Judging Criteria
Submissions will be judged on the plausibility of this standard reaching widestream adoption. If a submission is strong enough, the MetaMask team is interested in funding a security audit of it, and possibly even implementing improved user interface for contracts using the winning method.
This means stability and obvious safety are more valuable than excessive features (like fee repayment). The judges will be consulting with the authors of various MetaTransaction libraries for their opinions on the submissions.
A working demo is one of the most essential tools for proving the method works, and we’d love to see you use MetaMask and our signTypedData_v4 method in that demo ;)
### Winner Announcement Date
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.