I made a new implementation of EIP-1776 for the hackathon and you can play with it on Gorli or Rinkeby) here : https://metatx.eth.link
it is also obviously accessible via metatx.eth but because metamask will try to resolve ENS name on the network it is connected to (and that I did not register the name on Rinkeby or Gorli) it will fails to resolve it unless you go first on the mainnet.
The implementation is a Singleton proxy contract that implement all the meta-tx intricacies, including relayer repayment and forward the call to the destination. It is compatible with EIP-1776 (which I modified slightly for some improvements).
As a result, the requirement for metatx recipient is just kept to a very minimum. They simply need to check msg.sender to be the address of the singleton. No much need for a base class, except maybe for modifiers.
You can find the code here : https://github.com/wighawag/singleton-1776-meta-transaction
@Amxx I had a look at your proposal, I like the fact that it explores another method of implementation, that of the recipient being the meta-tx processor. What you call, a “no-proxy” implementation.
I have thus found at least 4 dimensions on which different meta-tx implementation differentiate themselves.
A) Type of implementation
First of all, It seems we have thus so far the following type of meta-tx implementation
Account-contract Based (a la Gnosis Safe, etc…) where recipient do not need any modification but that require user to get a deployed account contract.
Singleton Proxy where the recipient simply need to check for the singleton address and where all the logic of metatx is implemented in the singleton. It can support charging with tokens and even provide token payments
Token Proxy where the recipient simply need to check for the token address and where all the logic of metatx is implemented in the token. This is the approach originally taken by @austingriffith in “Native Meta Transaction”. It is usually limited to be used for meta-tx to be paid in the specific token. Relayer would then need to trust each token for repayment.
No Proxy where the recipient is the meta-tx processor and where all the logic get implemented. While it can support relayer repayment, relayer would have to somehow trust each recipient implementation.
Create2 based? I personally did not explore these much but this could be used to provide a mechanism by which user are still using EOA to sign metatx (same like account-contract based) but have an account-contract created on-demand (maybe when the first metatx is executed, in which case the relayer could be paying the cost in ether in exchange of some tokens).
Note that EIP-1776 is agnostic to the type of implementation.
B) Relayer refund
Another differentiation is the ability of relayer to get paid.
In my opinion, It is such an important feature for relayers that we should ensure it is at least possible to implement it on top, if not already present.
In that regard one thing that becomes important as soon as a relayer get paid, is that there is a mechanism to ensure the relayer cannot make the meta-tx fails. hence the need for
txGas in EIP-1776.
Another important EIP that would help here is EIP-1930
C) Token Transfer / Approval
While relayer-refund can be on its own, I found that it is trivial to also add the ability for meta-transaction processors to support transfering tokens to recipient.
This is a very powerful feature as it remove the need to pre-approve recipient, if they already support meta-tx.
D) MetaTx Signer Verification
Finally, another differentation possible for non-account based metatx is how the signer is being picked up by the recipient.
In EIP-1776 it assumes that recipient can easily add a from field to their functions as this is already a common practise in many standard.
in @Amxx and GSN version, the signer is appended to the data of the call.
I would be happy to update EIP-1776 to use this method if that is objectively better. For now, I feel the “first param” is simpler and can fulfil the same purpose, While it can in some case, requires recipient contracts to add, otherwise unecessary, extra function, most EIP, like EIP-20, EIP-721 and EIP-1155, have already functions that take the
from as first parameter.