Summary

Execution of newEscrow is 666857 gas (based on repo's gas-report). Assuming all Escrow construction arguments are non-zero, and we're executing 6 SSTOREs in Escrow's constructor, there's a (666857-21000-120000 = 525857) gas overhead for each deployed Escrow.

Vulnerability Details

Impact

While this may be inconsequential to the existing audit space because audits right now they normally run into thousands and tens or even hundreds of thousands dollars of value spent, the overhead is completely unnecessary and will have higher impact on smaller audit tasks as the space develops more competition and higher awareness of the importance of audits.

Tools Used

foundry t

Recommendations

The two alternative implementations for Escrow construction would be:

• Escrow cloning via minimal proxies (about 10% of the current overhead as deploying a minimal proxy is normally under 70k gas and could be brought down further using an optimized implementation such as solady's ERC1967Factory). This would be a good fit if it's for some reason desirable to isolate each Escrow to its own contract.

• Redesigning the system as a monolithic contract that maps unique ids to Escrow records. This would add some accounting code into the existing Escrow contract and obviate the factory.

In both cases, the two potential gas tradeoff is the inability to use immutable storage slots, but the wins allowed by immutable storage slots are overshadowed many times over by both the current deployment costs and the potential deployment savings in the two scenarios outlined above.

Additionally, with minimal proxy there's about a 10% transactional overhead during run-time, but all the functions in Escrow are supposed to be only used once, so again, this overhead is much lower than the current deployment overhead.

P.S. This is my first time participating in a contest, so I'm conflicted about going ahead and implementing both options for the purposes of demonstration, but if the judges, jury and the executioners are reading this, please let me know if that's a requirement or even makes sense under the circumstances of the contest.

P.P.S. An argument could be made that using deterministic deployment addresses for Escrows is useful for "decentralization," it is quite sufficient for any Escrow participants to simply know the address of their Escrow; as long as it is unique they will be able to access their Escrows and execute all the required operations.