EIP-7702: Discussion on authorization nonce handling design and security implications

[ThreeAndTwo]

Discussion Topic

During testing of EIP-7702 implementation on Sepolia and Holesky testnets, I've observed some interesting behaviors in the authorization nonce handling mechanism that raise important design and security considerations. I'd like to start a discussion on whether these behaviors are intended design choices or implementation issues.

Observed Behaviors

My testing reveals that the current implementation:

• Allows reuse of authorization nonces across transactions
• Accepts arbitrary nonce values (past/future) for authorizations
• Does not enforce consistent nonce validation across authorization lists

While EIP-7702 states "Increase the nonce of authority by one," the actual implementation appears to handle nonces differently than traditional transactions.

Test Results

Test ID	Test Description	Test Configuration	Expected Result	Actual Result	Transaction Hash	Conclusion
1	Multiple contract authorization	Simultaneously authorize batch processing contract and registry contract	Total nonce increases by only 1	Total nonce increases by only 1	0xa1fdb0f	Multiple authorized contracts share the same nonce
2	Low nonce authorization	Deliberately set authList nonce lower than current nonce	Transaction failure	Transaction success, executed normally	0xd0fc90	Nonce verification mechanism doesn't match expectations
3	Inconsistent authorization nonce	Set different nonces in authList	Transaction failure	Transaction success, executed normally	0xa3c744	Nonce consistency within authorization list is not enforced
4	High nonce authorization	Authorization nonce higher than current account nonce	Transaction failure	Transaction success, current nonce is 17, authorization nonces are 19 and 20	0x3b205e	Authorization can use future nonces
5	Nonce reuse test	Use nonces (19,20) that were already used in test 5 to send new transactions	Transaction failure	Transaction success, previously authorized nonces can be reused	Link 1 Link 2	Authorization nonce can be reused, creating replay risk

Design Considerations

These observations lead to two possible interpretations:

1. Application-Layer Responsibility: The current implementation may intentionally delegate nonce management to the application layer (smart contracts), providing maximum flexibility while requiring developers to implement their own replay protection mechanisms.

2. Implementation Gap: Alternatively, these behaviors might represent an implementation gap where the protocol-level nonce validation is not yet fully implemented according to the specification.

Personal Perspective

I believe that while authorization transaction replay might be an intentional design choice (allowing reuse of previously authorized nonces), there should still be some protocol-level constraints.

Even assuming the Application-Layer Responsibility model, I suggest that:

1. New authorization nonces should follow the nonce++ principle (incremental progression) rather than allowing arbitrary jumps.
2. The protocol should not allow a previously signed authorization nonce to be re-signed with different content and still pass node validation.

These minimal protocol-level constraints would preserve flexibility while mitigating the most serious security risks.

Security Considerations

If these behaviors are intentional design choices, there are important security considerations:

• Developer Burden: Application developers must implement robust nonce tracking
• Standardization Need: Security best practices for authorization management would be essential
• User Expectations: The security model differs from traditional transaction nonces
• Risk of Misuse: Without clear documentation, developers might miss implementing proper replay protection

Discussion Questions

1. Is the current authorization nonce behavior an intentional design choice or implementation issue?
2. What is the intended responsibility boundary between protocol and application layers for replay protection?
3. If application-layer management is intended, should the specification explicitly document this approach?
4. What security guidelines should be provided to developers implementing systems using EIP-7702?

Test Code Repository

Full test code is available at: https://github.com/ThreeAndTwo/eip7702_demos

Seeking Clarification

I'm seeking clarification from the EIP authors and implementers on the intended design and security model of EIP-7702, particularly regarding nonce management. Understanding the design intent would help developers build secure systems on top of this foundation.