Mats Heming Julner — December 25, 2025
I’m sharing a paper that proposes a diagnostic reframing of the persistent “gas problem” in blockchains.
Over the past decade, we’ve made real progress on execution efficiency (rollups, calldata compression, account abstraction, batching), yet user-facing gas UX remains unstable under demand: fee spikes, failed transactions that still incur cost, timing anxiety, and growing pressure toward custody.
This paper argues that these failures are not primarily due to insufficient optimization, but to a structural misassignment of responsibility in push-based execution models. In push systems, ownership, authorization, execution, and cost-bearing are collapsed onto the end user. As a result, retail users are forced to participate directly in execution markets under congestion.
The paper introduces Execution Responsibility Inversion as a design principle: separating authorization from execution via permissioned pull semantics. Users pre-authorize bounded outcomes, while executors perform execution and bear gas costs. Scarcity is not eliminated, but routed away from end users and absorbed by actors better positioned to manage volatility, retries, batching, and timing.
Importantly, this is a diagnostic, not prescriptive paper. It does not claim to eliminate gas fees, MEV, or scarcity, nor to fully specify executor economics. The contribution is identifying a structural responsibility assignment that explains why gas optimization and abstraction have repeatedly failed to stabilize UX at scale, and why custody keeps re-emerging as a workaround.
Key themes:
- Gas is not just a pricing problem; it is a responsibility assignment problem
- Push execution creates abstraction leakage by exposing users to execution failure
- Correct abstractions compress required expertise and relocate failure handling
- Permissioned pull is one concrete way to achieve this separation, not necessarily the only one
I expect reasonable pushback around executor markets, composability tradeoffs, and coordination costs; those are real and explicitly acknowledged as open design space. My goal here is to reframe how we talk about the problem, not to claim a finished solution.
Full paper:
https://github.com/recurmj/research/blob/main/execution-responsibility-inversion.md
Feedback, critique, and alternative framings are very welcome.