Over the past few months we’ve been interviewing staking and oracle teams for research on how those categories could be designed around censorship resistance, open source, privacy, and security as first principles. We asked each team how they’d design their category to maximize CROPS properties if they could start over without business constraints or technical limitations, then what was stopping them from building that design, and what single change would help them most to get there. That’s where the EIPs mentioned below came from, they’re the changes teams said would help remove limits they keep running into. We figured that’d be useful for core devs too, so here it is, what app-layer teams told us, grouped by theme with the EIPs each one points to.
Overall, some EIPs have strong support from several app teams, a few have less demand behind them, and the biggest need we heard doesn’t have an EIP yet at all.
A few caveats
This is demand-side input from a small, non-representative sample, and it isn’t meant to rank EIPs. We talked to six teams, mostly founders and core contributors, from Rocket Pool, Lido, and Obol in staking, and Chronicle, RedStone, and Chainlink in oracles. That’s a small sample, though it includes the largest provider in each category (Lido with roughly 21% of staked ETH as of June 30, 2026, while Chainlink is currently the largest oracle provider on DefiLlama, securing roughly $54.5B in TVS including borrows across 535 protocols as of October 22, 2026) plus teams with very different designs.
Even when these teams are asking for trust-minimizing protocol changes, those asks tend to line up with their own designs and business models, so they shouldn’t be read as a neutral wishlist. We tried to account for that in two ways. When a team had already tried to build the stronger design and hit a protocol limit, for example building something and then shelving it, we counted that as stronger evidence than a team just saying they’d like an EIP, and that’s what the Confidence column in the table below reflects. We also looked for places where competing teams landed on the same thing. Staking requirements have historically had a more direct path into consensus-layer discussions, including through recent fork features like max effective balance increases and consolidations, so the oracle findings are likely the less-heard input here. How any of this stacks up against everything else on the roadmap is ACD’s call, as these interviews didn’t focus on anything related to client capacity, complexity, or security tradeoffs.
At a glance: themes and EIPs that teams said would help them reduce trust assumptions
| Theme | EIP / Status | Who raised it | What it would change for apps | Confidence |
|---|---|---|---|---|
| Transaction inclusion | FOCIL (EIP-7805), scheduled for Hegotá | Lido, Rocket Pool, Chainlink | Apps could enforce honest block production and count on oracle updates landing | Strong |
| Verifiable reward payments | ePBS (EIP-7732), scheduled for Glamsterdam | Lido, Rocket Pool, both call it partial | Dishonesty in visible reward payments becomes detectable, side payments don’t | Moderate |
| Proofs that survive forks | EIP-7688 (scheduled for Glamsterdam) and related | Lido asked for it; Rocket Pool depends on beacon-state proofs | Proof-based designs stop breaking every fork, at least for additive changes | Moderate, durability uncertain |
| Trust-minimized deposits | EIP-8205, proposed for inclusion in Hegotá | Lido (8205’s authors) and Rocket Pool | Deposits without guardian committees or months-long workarounds | Moderate |
| Cheaper proving and verifying | No EIP yet | Chronicle and Chainlink asked; all three staking teams built or shelved proof-based designs | Proofs could replace committees across both categories | Problem strong, no clear fix yet |
| Permissionless exits | EIP-7002, shipped in Pectra | All three staking teams built on it | Anyone can trigger an exit | Strong |
Confidence is about how well the evidence shows teams need the change, not how important the change is. Strong means several independent teams asked for it, plus work they built or shelved because it was missing, and moderate means real demand from fewer teams.
Breakdown by theme
Transaction inclusion (FOCIL, EIP-7805): strong
FOCIL is already scheduled for inclusion in Hegotá, so this is a need the roadmap already reflects, and it had the broadest support of any single EIP we heard about, across both categories. Nothing at L1 forces inclusion today, and teams can’t prove a block was built honestly, so they can’t penalize exclusion. Lido contributors point out that no operator policy, including the DAO-governed relay allowlist Lido uses, gives “structural censorship resistance,” and that fair enforcement “needs a protocol commitment that proves timely availability and required inclusion. That mechanism belongs in Ethereum.” Rocket Pool can slash an operator’s bond for anything provable onchain, but there’s no way to prove a block was censored, so it can’t be used here, and they say “inclusion lists are preferable to mandating local block building.” On the oracle side, Chainlink independently named fork-choice enforced inclusion lists, since a builder can drop an oracle update “at the moment it matters most, which is the same moment the builder gains most from dropping it.”
Obol also pointed out that a colluding attestation majority that refuses to attest to certain blocks wins fork choice at little cost, and “FOCIL doesn’t prevent this.” In their view, if validator set decentralization isn’t taken seriously soon, “validators with a majority of stake will just ignore ILs they don’t like,” and Ethereum may never be able to re-decentralize or regain trust afterward.
Verifiable reward payments (ePBS, EIP-7732): moderate
ePBS is scheduled for Glamsterdam. Both staking teams that raised it want it, but see it as partial. Today, fee-recipient and MEV delivery can’t be verified, so operators who redirect rewards can’t be reliably caught. Lido contributors explained that ePBS only goes so far, since the value leg is collateral-backed and protocol-settled, while the execution payment leg is “a trusted promise settled outside protocol enforcement,” and “protocol evidence cannot show that an unpublished higher bid existed.” Rocket Pool said ePBS “may help with trustless detection, but it doesn’t prevent the behaviour outright.”
Proofs that survive forks (EIP-7688 and related): moderate, durability uncertain
Contracts that verify beacon-state proofs can break when a fork moves consensus fields, which can mean a new circuit and a new audit every fork. Lido paused a working ZK accounting system back in April, one that had proven validator balances in mainnet shadow mode and passed an audit, for three reasons: the move to 0x02 validators needed the whole team and rewrites their accounting model, forks keep moving consensus fields and breaking circuits, and under ePBS a slot can have a beacon block but no payload, so EIP-4788 stops writing some beacon roots. EIP-7688 (stable Merkle positions for consensus fields) fixes the field-moving part after one last change, and it’s scheduled for Glamsterdam and already on Sepolia. What Lido contributors still need is gap-free beacon roots onchain under ePBS and durable root history (research post). Rocket Pool’s Saturn 2 design leans on beacon-state proofs too.
A consensus-side researcher noted that EIP-7688 covers additive changes, while decoupled consensus will rewrite large parts of beacon state, and for the next few years “it’s going to be tough to make any promises about invariants.”
Trust-minimized deposits (EIP-8205): moderate
Under first-deposit-wins, a key holder can front-run a funder’s deposit with their own withdrawal credentials. Teams defend against this themselves today, with guardian committees at Lido and a predeposit plus validator proof per validator at Rocket Pool. Rocket Pool asked for EIP-8205 on their own, since their current flow is “highly inefficient” and can stretch deposits “out to months” under a large queue. Lido’s contributors wrote EIP-8205, so theirs is author support, and Obol didn’t raise it. There have been no known exploits, so the case is about cost and complexity rather than incidents.
EIP-8205 is still proposed for inclusion in Hegotá. Separately, the EF Protocol cluster rated it DFI (declined for inclusion) in its published Hegotá tier list, arguing that it primarily serves large staking operations and doesn’t clear the necessity bar. Outside the teams we interviewed, the EIP lists public support from ether fi, Kelp, FP Validated, independent auditors, and L2Beat (see list of public supporters).
Evidence that decentralized designs carry the same costs could change that. Rocket Pool, which runs a permissionless operator set, says they do, so we’ll continue to ask more staking teams to get further data.
Cheaper proving and verifying (no EIP yet): problem strong, no clear near term fix
This was the biggest need we heard, and no team pointed to a specific EIP for it. Proof-based designs cost several times their committee-based versions, but for different reasons at each team:
- Chronicle: verification gas (a proof-based update lands around 360k gas, against 69k to 126k for its current feeds).
- Rocket Pool: proving and witness cost (ZK proving was “too heavy to run natively” for their operators).
- Lido: keeping circuits working across forks, among other reasons.
- Obol: the cost of building proof-heavy designs at all rather than verifying them onchain, paired with weak demand. Obol researched a reward-and-punishment game that would let clusters run with untrusted operators, but found that operators prefer running clusters with people they trust, and that building it properly with ZKPs and VDFs would cost millions: “it’s all expensive work and there’s no market demand for it.”
Chainlink listed “cheap verification” among its asks as well, and RedStone sees ZK more as a privacy tool, so the demand comes from designs that want proofs rather than the whole oracle category. One concrete ask that came up, an EF-blessed verify precompile, was seen by the protocol researchers we spoke with as running against the zkEVM direction. Instead, they pointed toward hash-based proving, with proof aggregation potentially filling the gap in the meantime and native verification once the EVM itself becomes provable. The protocol is building this proving infrastructure anyway, for post-quantum signature aggregation and the zkEVM, so an open question is whether app-layer proofs could use the same infrastructure.
One implication we’re exploring is whether app-layer proofs need a similar staging path. Protocol researchers pointed out that Ethereum is already staging proofs before relying on them, with optional execution proofs running alongside re-execution first, much like the Beacon Chain ran before the Merge. Aggregation could give app teams a similar way to run proof-based designs in production before native verification makes them the default, especially since several teams shelved or paused their designs before they reached production.
Permissionless exits (EIP-7002, shipped in Pectra)
EIP-7002 shows what happens at the app layer once a change ships. Rocket Pool’s end-state design lets anyone trigger an exit after a cooperative window. Lido exits follow a deterministic exit-order algorithm, the oracle committee only reports the result, and anyone can then force the exit through triggerExits(). And Obol confirmed a stranded cluster’s principal can be rescued with no operator alive, for 7002-compatible credentials.
Single-team signals
Each of these came up with only one team, so we’re not drawing conclusions from them yet:
- Native validator key rotation (Lido). Lido solved key rotation for its own oracle at the app layer (LIP-37), but validator BLS keys can’t be rotated without exiting and re-entering stake, which keeps a compromised key exposed longer. Lido contributors say this can’t be done at the app layer without friction and new dependencies, and that it’s becoming more urgent as infrastructure hacks increase, pointing to incidents at Kiln and, more recently, Consensys.
- Exit liquidity pricing (Obol). The risk of getting stuck in a months-long exit queue during a panic pushes stake toward intermediaries all the time, since it’s rational to get out first in a bank run. Obol sees it as the most centralizing force on the chain right now, and the reason so few people native stake to a non-custodial wallet, staking through a custodian or an LST for the liquidity instead. A burn-to-exit draft exists but hasn’t been pushed or reviewed.
- Correlated downtime penalties (Obol, EIP-7716). Penalizing validators more when many go offline at once would push large operators toward minority clients and more resilient setups, instead of running a big share of the network on one stack. Obol is championing it as a decentralization measure. The EF Protocol tier list rated it DFI, calling it a good idea but not a priority this fork, and asking for more research on its effects on stakers and edge cases.
- Custom sweep thresholds for 0x02 validators (Rocket Pool, EIP-8148). Rocket Pool asked for EIP-8148 alongside EIP-8205 to enable 0x02 validators in their design.
- Credential-enforced fee recipient (Rocket Pool). “If the withdrawal credential could directly enforce the fee recipient, these oracles would become unnecessary.”
- Blockspace under volatility (Chainlink). During the Oct 10, 2025 volatility event, 3,250 feed updates in an hour at about $132 each, competing with liquidations and exits.
- Privacy (Lido contributors). Capital privacy needs “an Ethereum shielded-pool standard,” while operator privacy is upstream, since “a staking contract cannot hide data that Ethereum consensus publishes.”
What’s next
We’re starting similar conversations with teams in other major app-layer categories (wallets, on/off ramps, bridges, payments, etc.), leaning toward groups that are less represented in ACD discussions, and if they turn up useful signal on EIPs, we’ll share that too. If you’re on an app team and want to share what you need from L1, reach out. The more categories we cover, the easier it gets to tell a recurring theme apart from one team’s wish list. If there’s a question you’d want answered from the app side before deciding on an EIP, whether teams would actually use something or what breaks without it, send it our way and we’ll include it!
Pushback is very welcome too, especially anywhere we’ve tied an app-layer problem to the wrong EIP. Please feel free to reply in this thread, email charles@ethereum.org, or reach out at @CharlieStLouis on X.
/fin