Zircuit ERC7702

Problem Statement

Privilege de-escalation enforced by a static master address, hereby calledMaster, who reserves the right to update policies enforced on the de-escalated account, hereby calledOrg. The intent is thatOrgis generally untrusted and needs strictly enforced, on-chain boundaries as controlled byMaster. This is achieved through an EIP7702 contract with a stored owner (Master) address, and whichOrgunconditionally authorizes himself to be bound to. The EIP7702 contract stores a pointer to the contract addressMasterwishes to validate, which has the ABIfunction verify(address recipient, uint256 amount, bytes calldata data) external view returns (bool);, and whichOrg's EIP7702 contract (must) validate against for each transaction. TheMastercontrolled contract can therefore implement any logic it wants, we implemented a whitelist and a maximum native ETH transfer limit as examples.

Solution

The project was deployed on the Zircuit chain. This is an amazing L2 for its quick finalization time and low gas fees, but the killer features is its AI-powered screening for malicious transactions. Seeing as the whole point of this hackathon project is to reduce the chances of malicious transactions being verified, Zircuit seemed a good fit! We used Foundry for contract creation testing and deployment, as well as verification. Noir from AZTEC was used as well, however it turns out that the ZK cryptographic primitive doesn't preserve the privacy ofMaster's policies (Semaphore was probably needed here)