Review the delegated implementation and its permissions, not just the authorization transaction. Delegation changes what code can execute in the user's account context.
The security boundary changes
EIP-7702 allows an externally owned account to designate code to execute in its context. Delegation persists until changed or cleared; it is not limited to one sponsored transaction. The specification also notes that a failed execution does not roll back an already processed delegation. Source 1 defines those protocol rules; an implementation audit must evaluate how the wallet handles them.
Separate authorization from operation approval
A wallet integration should make the delegated implementation identifiable and distinguish installing account behavior from approving a particular action. For an audit, provide the signed payload formats, the supported chains, and the paths that execute an operation after authorization. Do not assume that one valid signature establishes permission for every later action.
Example: a limited session that reaches a powerful target
Imagine a trading session intended to call only one router. Review whether it can choose a different target, approve a different spender, attach unexpected value, or use a batch to combine individually permitted calls into an unintended result. Write the intended limit as a testable property: the session cannot increase an unauthorized spender's allowance. This is a proposed review scenario, not a reported vulnerability.
Test initialization and upgrades together
Prepare cases for an already initialized account, a repeated setup call, and a switch between implementation versions. Record which storage slots each implementation expects and how the new code treats existing state. If recovery changes permissions, test the old permissions after recovery rather than assuming that replacing one owner clears every delegated capability.
Include the relayer's failure cases
For sponsored transactions, define who pays when validation succeeds but execution fails, which operations are retried, and how the service detects a changed delegation. A contract review can inspect validation and replay controls, while availability and signing-service procedures need explicit operational scope. Document where those responsibilities meet.
What to send for an audit
Include the delegate implementation, wallet integration, module list, authorization and operation examples, initialization flow, and intended permission limits. Identify upgrade authorities and recovery paths. A reviewer needs the complete authorization-to-execution flow to assess whether the application delivers the restrictions the user expects.
Review Checklist
- Attempt an unauthorized target, spender, value, and batched action.
- Test initialization twice and after changing the delegated implementation.
- Verify session revocation, recovery, and replay boundaries.
Sources and Further Reading
The linked sources describe the standards or research discussed above. Review scenarios are practical planning examples, not findings from an audit of a specific project.
Discuss Your Audit Scope
Start with your email and a short project description. Technical details can follow. Request a smart contract audit quote or review public CTDSEC audit examples.