Yes, I was thinking of the scenario where the message is relayed to another contract which accepts the message, but its effectively a denial of service - as you have pointed out.
So, for this mechanism to work, there needs to be a market for relayers ( basically you should be able to chose another, if one is denying service). For that to happen, relayers should be incentivised in some way, right? So, a commission based model or do expect some other mechanism to incentivise them?
relayers are incentivized. They’re paid in tokens or ether by the user
I believe there is a typo in section 2a. The think the identity is to support ERC725 and not ERC720 has stated.
How set are you on the argument names?
I’m working on a use case for Native Metatransactions and the to and from argument names have a different meaning (opposite meaning in fact).
For identity contracts like your reference implementation, from makes sense to be address(this) but for native metatransactions from is really the target contract and to is really the signer.
Are you open to more specific names such as signer and targetContract? This would be a step toward having the standard cover both identity contracts as well as native metatransactions (e.g. a token with built in signed message meta transfer)
The more I think about this, I think a bigger change is needed to be compatible with native transactions.
For native metatransactions your to is always address(this), which is also true for from. Who is signing is no longer an internally stored value/array and needs to be passed as an argument.
Don’t want to unnecessarily introduce yet another EIP. Do you think there’s a path forward to make 1077 suit the native meta transaction use case?
Hi @NoahMarconi
I came to the same conclusion: 1077 is not currently compatible with native meta transaction, see my comments here
I thus created a new EIP for native meta transaction : https://github.com/ethereum/EIPs/issues/1776
Feel free to give feedback there.
Hey guys, I believe chainId param should be added in order to avoid replay attack on different chains.
With the addition of CREATE2 opcode it’s possible and even desirable to have the same identity contract address on different chains. This allows replaying transactions on other chains. e.g. sending a transaction on xDai chain will allow draining ETH on Mainnet from the same identity address.
In order to prevent it, I believe chainId should be added to executeSigned params and identity contract should check that chainId is correct before executing a transaction.
Hey @alexvandesande and everyone, I am updating the EIP-1077. See here https://github.com/ethereum/EIPs/pull/2454