Follow-up: Multiple EIP-7702 Authorizations Under Bounded Execution
While working on GhostShard, I ran into what appears to be a broader ERC-4337 design question.
GhostShard currently relies on multiple EIP-7702 authorizations originating from distinct EOAs. This works naturally at the transaction layer, but integrating the same model into existing ERC-4337 infrastructure is significantly harder due to the common assumption that a UserOperation has a single authorization context.
My understanding is that support for multiple EIP-7702 authorizations is generally avoided due to validation complexity and DoS concerns. However, I am curious whether those concerns are fundamental, or a consequence of needing to support arbitrary execution.
Consider a restricted model where:
Multiple EIP-7702 authorizations are included.
Execution is bounded to a pre-verified router contract.
The execution path is deterministic and constrained.
Authorization consumption rules are explicitly defined.
No arbitrary delegation graph or recursive authorization expansion is permitted.
The motivation here is not to enable arbitrary multi-signer execution, but to allow protocols with constrained execution semantics to remain compatible with existing ERC-4337 infrastructure, including bundlers and paymasters.
Questions:
What specific DoS vectors remain under a bounded execution model?
Are there mempool or validation-level assumptions that still make this infeasible?
Would EntryPoint invariants break down even if execution is restricted to a known router?
Has this design space already been explored and rejected?
I’m particularly interested in understanding whether the current limitation is:
a fundamental security requirement, or
an implementation choice driven by support for unrestricted execution semantics.
Any references, prior discussions, or design documents would be appreciated.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | A native zkEVM scales bandwidth, not just execution | 0 | 0 | 22-06-2026 |
| 2 | Validator Redirected Revenue | 0 | 0 | 23-06-2026 |
| 3 | Scaling in Hegota: using the ETH transfer to anchor execution and bandwidth | 0 | 0 | 19-06-2026 |
| 4 | Repurposing FOCIL as an L2 forced transaction mechanism | 0 | 0 | 19-06-2026 |
| 5 | A Criticism of LUCID and Encryption-Scheme-Agnostic Encrypted Mempool Designs | 0 | 0 | 22-06-2026 |
| 6 | Relationship-Anchored Money: Separating Symbolization from Securitization | 0 | 0 | 22-06-2026 |
| 7 | Futarchy is insecure without a trusted gatekeeper | 0 | 0 | 21-06-2026 |
| 8 | Etherveil - An Ethereum Privacy Browser | 0 | 0 | 21-06-2026 |
| 9 | Exploring the Design Space for a Post-Quantum Public Key Registry for Ethereum Validators | 0 | 0 | 22-06-2026 |
| 10 | Cooperative Capitalism Is the Last Coherent Economic Path Crypto Has Left | 0 | 0 | 23-06-2026 |
