ERC725Z: Signatures

[z0r0z]

An implementation of smart account with 'shared' logic by verifying user signatures (v/r/s) to execute logic would helpfully extend this standard and instruct a DAO primitive.

Basically, the ERC725X + an extra param in execute() for user signature verification in contract.

[YamenMerhi]

Hey @z0r0z Thanks for opening an issue for this suggestion IMO a smart contract executor should be generic enough to do just what it should do, which is normal execution. This is something that is doable when building on top of the ERC725X. If you check LSP6-KeyManager, you have executeRelayCall function that offers an execution through ERC725X based on the signature, you could have also another smart contract that you create that function as the owner and can execute depending on whatever logic you want (signatures, permissions, etc..). Opinions @CJ42 @frozeman ? Happy to discuss further :)

[CJ42]

@z0r0z Doesn't EIP1271 fit for this purpose? It can be used to verify signatures? If not, what is missing?

This is a standard library from OpenZeppelin https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/cryptography/SignatureChecker.sol

But can be used as an interface that is inherited.

[z0r0z]

I am suggesting a standard form of execute() function where signature is provided as an extra param on top of ERC725X, for example: function execute( Operation op, address to, uint256 value, bytes calldata data, Signature[] calldata sigs ) external payable returns (bool success) {

[YamenMerhi]

Once again talking about this issue, it's up to @frozeman as he's the author of this standard, but I think it's too late to add another sub-standard. Also, I'm struggling to see the need to standardize a new type or sub-standard as this could be easily built on top, LSP6-KeyManager do it or even you can have a simpler version where you can have a contract owning the ERC725 and it check signatures and based on the check, the call will be executed. The erc725X is too generic so anything could be built on top.

Also in case of signature, you will implement nonces to prevent replay attacks but these nonces could be replayed (didn't test it but logical) if the contract was deployed with create2 and selfdestructed with delegatecall then recreated at the same address. Storage will be reset and nonces could be replayed.

So IMO, any signature logic should be built on top of erc725X for security reasons and separation of concern.

[z0r0z]

thanks @YamenMerhi this makes sense

[frozeman]

@z0r0z an example of using executeRelayCall() of an LSP6 contract owning an EC725X can be found here: https://docs.lukso.tech/guides/key-manager/execute-relay-call/

See the smart contract API here: https://docs.lukso.tech/standards/smart-contracts/lsp6-key-manager#executerelaycall