Improved validation pattern

[0xClandestine]

I have developed a validation pattern that can greatly reduce the expenses associated with wallet deployment and usage. The concept behind this pattern is rather straightforward: instead of storing various parameters required for validation, such as the list of signers and the quorum, you only store a hash.

To ensure proper reconstruction of the validation hash, it is crucial to provide the signatures in the exact order of the addresses that were hashed during the creation of the validation hash. Moreover, if a signer does not provide a signature, their address must be used as a replacement. This implies that whenever signatures are provided, they MUST ALWAYS be placed at the same index of signatures.

Gas is saved on deployment because only a single slot needs to be modified in order to initialize everything. Furthermore, only a two SLOADs are needed for transaction validation. 1 SLOAD for nonce, and 1 SLOAD for the validation hash as opposed to an SLOAD for each signer, and an additional SLOAD for the signers array length.

Foundry says 77k gas to deploy my version via a clone factory and 45k for an ETH transfer when using 3 signers and with a quorum of 2.

Here's an example implementation.

[z0r0z]

This is incredible and nicely minimal @0xClandestine Thanks for sharing. I think this looks like a solid pattern to integrate as sub-Wallet pattern for Keep which is positioned more as a token factory plus auth logic. Your verification optimizations though look good for v2 :~).

[0xClandestine]

This is incredible and nicely minimal @0xClandestine Thanks for sharing. I think this looks like a solid pattern to integrate as sub-Wallet pattern for Keep which is positioned more as a token factory plus auth logic. Your verification optimizations though look good for v2 :~).

Glad to help 🫡

[0xClandestine]

This is incredible and nicely minimal @0xClandestine Thanks for sharing. I think this looks like a solid pattern to integrate as sub-Wallet pattern for Keep which is positioned more as a token factory plus auth logic. Your verification optimizations though look good for v2 :~).

Glad to help 🫡

Also was thinking, only a single slot is needed if nonce is also optimistically passed in via call data.