🧠 Advanced

This issue is well-suited for contributors who are very familiar with the Hiero C++ SDK and enjoy working with its core abstractions and design patterns.

Advanced Issues often involve:

• Exploring and shaping SDK architecture
• Reasoning about trade-offs and long-term impact
• Working across multiple modules or systems
• Updating tests, examples, and documentation alongside code

The goal is to support thoughtful, high-impact contributions in a clear and collaborative way.

🐞 Problem Description

As part of the upcoming Pectra upgrade to Hiero networks, EIP-7702: Set Code for EOAs introduces Type 4 transactions (also known as SET_CODE_TX_TYPE). This new transaction type allows Externally Owned Accounts (EOAs) to delegate code execution to smart contracts, enabling features like:

• Transaction batching
• Sponsored/gasless transactions
• Session keys and permissioned sub-keys
• Smart wallet capabilities while preserving EOA identity

The Hiero C++ SDK currently does not support encoding or decoding Type 4 transactions. To prepare for the Pectra upgrade, the SDK must be able to construct and send these transactions to consensus nodes.

Technical Background

Type 4 transactions introduce a new RLP-encoded structure with an authorization list:

rlp([
  chain_id,
  nonce,
  max_priority_fee_per_gas,
  max_fee_per_gas,
  gas_limit,
  destination,
  value,
  data,
  access_list,
  authorization_list,    // NEW: list of authorization tuples
  signature_y_parity,
  signature_r,
  signature_s
])

Each entry in authorization_list is a tuple:

[ chain_id, address, nonce, y_parity, r, s ]

Where the authority (EOA) signs over keccak(MAGIC || rlp([chain_id, address, nonce])) with MAGIC = 0x05.

Key Parameters

💡 Proposed / Expected Outcome

Implement full SDK support for EIP-7702 Type 4 transactions, including:

1. New data structures for authorization tuples and authorization lists
2. RLP encoding/decoding for Type 4 transaction format
3. Signature handling for authorization tuple signing (MAGIC prefix, proper hashing)
4. Integration with existing EthereumTransaction infrastructure
5. Validation of chain IDs, nonces, and signature parameters
6. Public API that allows users to construct and sign Type 4 transactions

The implementation should:

• Follow patterns established in other Hiero SDKs for consistency
• Preserve backwards compatibility with existing transaction types
• Provide clear, actionable error messages for invalid inputs
• Be well-documented with usage examples

🧠 Implementation & Design Notes

Suggested Approach

1. Review the design document:
   HIP-1340 sdk-collaboration-hub#118

2. Study EIP-7702 specification:
   https://eips.ethereum.org/EIPS/eip-7702

3. Identify affected areas in the C++ SDK:

   • src/sdk/main/src/ - Transaction classes and encoding
   • src/sdk/main/include/ - Public API headers
   • Existing EthereumTransaction implementation for patterns

4. Design new classes/structures:

   • AuthorizationTuple or similar for individual authorizations
   • Extension to EthereumTransaction or new transaction class for Type 4

5. Implement RLP encoding:

   • Handle the new authorization_list field
   • Ensure proper serialization order and types

6. Implement signature logic:

   • MAGIC prefix (0x05) for authorization signing
   • Proper keccak hashing of authorization data
   • Signature validation (s <= secp256k1n/2 per EIP-2)

7. Add comprehensive tests:

   • Unit tests for encoding/decoding
   • Integration tests for transaction submission
   • Edge cases (empty authorization list, multiple authorizations, etc.)

8. Provide usage example(s):

   • Demonstrate constructing a Type 4 transaction
   • Show how to create and sign authorization tuples

Key Considerations

• Chain ID validation: Authorization tuples can have chain_id = 0 (valid on all chains) or must match the current chain
• Nonce handling: Each authorization increments the authority's nonce
• Delegation indicator: The code set on delegation is 0xef0100 || address
• Gas calculations: Include PER_EMPTY_ACCOUNT_COST * authorization_list.length in intrinsic gas

✅ Acceptance Criteria

A pull request for this issue should:

• Implement Type 4 transaction encoding per EIP-7702 specification
• Implement authorization tuple/list data structures
• Implement proper signature handling for authorizations (MAGIC prefix)
• Integrate with existing EthereumTransaction infrastructure
• Maintain backwards compatibility with existing transaction types
• Follow existing architectural and C++ conventions in the SDK
• Include comprehensive unit and integration tests
• Provide at least one usage example
• Update relevant documentation
• Pass all CI checks

📚 Additional Context, Links, or Prior Art

Design Document

• SDK Collaboration Hub PR # 118: HIP-1340 sdk-collaboration-hub#118

Specifications

• EIP-7702 (Set Code for EOAs): https://eips.ethereum.org/EIPS/eip-7702
• EIP-2718 (Typed Transaction Envelope): https://eips.ethereum.org/EIPS/eip-2718

Related Resources

• Pectra Upgrade Info: https://pectra.org/
• EIP-7702 Security Considerations: Authorization signatures can be phished; the SDK should provide clear warnings/documentation about risks

Cross-SDK Alignment

This implementation should align with patterns used in other Hiero SDKs. Check the design document for cross-SDK consistency requirements.