feat: scw auth forwarding with manual request to match payload

[zeluisping]

Pass Request Metadata for Silent Data Signature Verification

Description

Implements payload alignment for Silent Data's EIP-712 signature verification by forwarding the original JSON-RPC request metadata (id and jsonrpc) through the bundler's call chain. This enables the bundler to reconstruct the exact eth_getLogs payload that clients sign for eth_getUserOperationReceipt and eth_getUserOperationByHash requests.

Changes

1. Added RpcRequestMetadata Type

• New type in packages/types/src/api/interfaces.ts to carry id and jsonrpc through the call stack

2. Thread Request Metadata Through All Layers

• API Layer: Extract { id, jsonrpc } at entry point and pass to methods
• Executor & Service Layers: Updated signatures to forward requestMetadata
• Interface Updates: Modified IEntryPointService contract

3. Manual eth_getLogs Payload Construction (EntryPointV7Service)

• Replace viem's getLogs() with manual JSON-RPC payload construction
• Use transport.request() for full control over request structure
• Include original id and jsonrpc from metadata in the payload

4. Strict Validation

• Require x-from-block header (no silent defaults)
• Validate block range with descriptive error messages
• Optimized minBlockNumber calculation

Request Flow

1. Client receives: eth_getUserOperationReceipt (id: 123)
2. Client builds & signs: eth_getLogs { id: 123, jsonrpc: "2.0", method: "eth_getLogs", params: [...] }
3. Client sends: eth_getUserOperationReceipt (id: 123) + signature headers
4. Bundler extracts: { id: 123, jsonrpc: "2.0" } from original request
5. Bundler constructs: eth_getLogs with SAME id: 123, jsonrpc: "2.0"
6. Bundler sends: eth_getLogs to Silent Data RPC with signature headers
7. ✅ RPC node verifies signature matches payload!

Types of changes

What types of changes does your code introduce?

Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Other (please describe):

Further comments (optional)

Why This Matters

For Silent Data's privacy-preserving RPC nodes, clients must sign requests using EIP-712. The signature is computed over the exact JSON-RPC payload, including the id field. Previously, the bundler used viem's high-level APIs that auto-generate request IDs, making it impossible for clients to pre-sign requests. This implementation enables payload alignment between what clients sign and what the bundler sends, unlocking support for Silent Data-protected reads in smart contract wallet implementations.