ADR: typed sponsorship transactions WIP

[randygrok]

Draft ADR describing typed transactions for sponsorship (EIP-2718) with ev-reth-specific envelope and fields.

[claude]

Claude finished @randygrok's task —— View job

---

PR Review: ADR for Typed Sponsorship Transactions

I've completed my review of this ADR for typed sponsorship transactions. Here's my comprehensive analysis:

Review Tasks:

• Read and analyze the ADR document structure and content
• Review README.md changes
• Evaluate architectural design decisions
• Assess security implications and concerns
• Check for completeness and technical accuracy
• Provide constructive feedback and recommendations

Review Summary

This ADR proposes a sophisticated gas sponsorship mechanism using EIP-2718 typed transactions (type 0x76). The design shows strong architectural thinking with innovative dual-signature domains and open sponsorship models. However, there are several significant concerns that need to be addressed before implementation.

Critical Issues

1. Structural Field Inconsistency (High Priority)

The EvNodeTransaction struct in the specification appears to have fundamental inconsistencies:

Issue: The struct combines both sponsorship fields AND batch calls, but lacks essential transaction execution fields:

• Missing: to, value, input fields for single-call transactions
• The struct only has calls: Vec<Call> which suggests batch-only usage
• This creates confusion about how single transactions vs. batch transactions are handled

Recommendation: Clarify the transaction structure. Consider two options:

1. Unified approach: Use calls for both single and batch transactions (single tx = 1-element vector)
2. Dual approach: Separate fields for single tx (to, value, input) + optional calls for batching

// Option 1 (Recommended): Unified with calls only
pub struct EvNodeTransaction {
    pub chain_id: u64,
    pub nonce: u64,
    pub max_priority_fee_per_gas: u128,
    pub max_fee_per_gas: u128,
    pub gas_limit: u64,
    pub calls: Vec<Call>,  // Always present, min length 1
    pub access_list: AccessList,
    // Sponsorship fields
    pub fee_payer: Option<Address>,
    pub fee_payer_signature: Option<Signature>,
}

2. Incomplete Signature Specification (High Priority)

The ADR doesn't specify what data the sponsor actually signs:

Issue: Lines 97-101 mention the sponsor signs domain 0x78 but don't define:

• Exact field ordering in the sponsor's signed message
• Whether sponsor signs the transaction hash or the full payload
• How to prevent sponsor signature reuse across different executor transactions

Recommendation: Define explicit sponsor signature schemes:

// Sponsor signs: keccak256(0x78 || rlp([chain_id, executor_address, tx_hash, fee_payer]))
// This binds sponsor to specific executor + transaction + chain

3. Security Model Gaps (High Priority)

Open Sponsorship Risks: The "sponsor malleability" model (line 177-181) has understated risks:

• MEV extraction: Malicious sponsors could extract MEV by reordering/timing their sponsorship
• Griefing: Sponsors could intentionally fail transactions after signing by depleting their balance
• Privacy: Transaction linkage between executor and eventual sponsor creates privacy concerns

Recommendations:

• Add sponsor commitment mechanisms (time bounds, fee guarantees)
• Consider sponsored transaction pools separate from regular mempool
• Define sponsor reputation/staking models

4. Batch Call Execution Clarity (Medium Priority)

Issue: The atomic execution model needs more specification:

• How are gas limits distributed across calls?
• What happens with gas refunds in batch context?
• How does tx.origin behave across multiple calls?

Recommendation: Add detailed execution semantics section.

Architectural Assessment

Strengths ✅

1. Modular Integration: Excellent use of Reth's NodeTypes system for clean integration
2. EIP-2718 Compliance: Proper typed transaction envelope design
3. Dual Signature Domains: Innovative separation of execution vs. payment authorization
4. Atomic Batching: Valuable feature for complex transaction flows

Concerns ⚠️

1. RLP Encoding Complexity: The deterministic encoding rules (lines 73-76) need validation tooling
2. Transaction Pool Integration: Custom TransactionValidator needs careful DoS protection
3. JSON-RPC Extensions: Non-standard fields may break tooling compatibility

Implementation Strategy Review

The proposed implementation plan is generally sound but needs refinement:

Missing Components:

1. Gas Estimation: How do wallets estimate gas for sponsored transactions?
2. Fee Market: How does sponsorship interact with EIP-1559 fee markets?
3. Mempool Propagation: How do sponsored transactions propagate in P2P networks?

Testing Requirements:

• Fuzzing for RLP encoding/decoding edge cases
• Stress testing dual signature verification
• Integration tests with actual mempool scenarios

Minor Issues

1. ADR Structure: Missing "Alternatives" section (mentioned by Gemini Code Assist)
2. Reference Links: Some links may be outdated (Tempo Protocol)
3. Fee Token Support: The fee_token field isn't used in this ADR but appears in some discussions

Recommendations for Next Steps

1. Immediate: Fix the structural inconsistency in EvNodeTransaction
2. High Priority: Complete the signature specification with exact signing algorithms
3. Security Review: Conduct formal security analysis of the open sponsorship model
4. Implementation: Build a minimal prototype to validate the RLP encoding scheme
5. Integration: Define how this integrates with ev-reth's existing transaction flow

Overall Assessment

This ADR shows strong architectural vision but needs significant refinement before implementation. The core concepts are valuable for the ev-reth ecosystem, but the specification gaps could lead to security vulnerabilities or interoperability issues.

Recommendation: Address the critical issues above before moving from DRAFT to ACCEPTED status.

---

[gemini-code-assist]

Summary of Changes

Hello @randygrok, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a draft Architectural Decision Record (ADR) proposing a standardized mechanism for gas sponsorship within the ev-reth project. By leveraging EIP-2718's typed transactions, this ADR aims to define a new transaction type that explicitly separates the fee payer from the transaction initiator. This approach seeks to simplify user onboarding and product integrations by allowing a designated sponsor to cover transaction costs, thereby removing the requirement for end-users to hold native funds, all while maintaining compatibility with existing Ethereum tooling and execution semantics.

Highlights

• Proposal for typed sponsorship transactions: Introduces a new Architectural Decision Record (ADR) to implement gas sponsorship using EIP-2718 typed transactions in ev-reth.
• New transaction type (0x76): Defines a specific transaction type (0x76) within ev-reth that separates the gas payer (sponsor) from the transaction executor, allowing a sponsor to cover fees without altering the user's call origin.
• EvRethTxEnvelope extension: Outlines the extension of the EvRethTxEnvelope enum to include the new SponsorTransaction type, detailing its structure with user call fields and separate sponsorship fields.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces an Architecture Decision Record (ADR) for implementing typed sponsorship transactions in ev-reth. The proposal leverages EIP-2718 to create a new transaction type that separates the gas payer (sponsor) from the transaction executor.

The ADR is well-structured and provides a good overview of the context and decision. However, the proposed implementation details have some significant gaps. The SponsorTransaction struct is missing key fields from the user's transaction, making the design incomplete. Additionally, critical security aspects, such as what the sponsor's signature covers, are not defined. The mechanism for paying fees with tokens also needs further clarification. My review includes suggestions to address these points to make the design more robust and secure.