Technical analysis of Oracle Effective balance updates, Fee Abstraction and SSV Staking

First, we’re excited to see this proposal being published, we’re fully aligned with its direction. Moving cluster fee accounting from SSV → ETH & introducing SSV staking are important steps toward long-term protocol sustainability and smoother adoption!

That said, we see a few areas where extra clarity and some small design tweaks could significantly reduce friction during the transition:

Legacy SSV clusters: no top-ups after go-live might generate liquidation friction

Since SSV-based clusters become “legacy” and can’t be extended via additional SSV deposits once this goes live, any cluster with low runway (or users who miss the top-up window) could face a hard liquidation path. Avoiding liquidations by introducing a temporary “transition grace” ithout liquidations for SSV-based clusters could be a good approach. This gives users time to migrate even if runway ends earlier than expected.

Operator readiness / rollout sequencing

The proposal do not specify if operators will be requested to upgrade to a new version. If so operators do have to migrate, we propose creating a window for operators to upgrade before clusters can migrate.

Permissionless Oracle incentives: please clarify the incentive design

For the initial permissioned oracle phase, compensation is defined. For the permissionless oracle phase, the proposal mentions a protocol-level compensation mechanism but doesn’t specify the incentive model.

This matters because it directly impacts whether permissionless oracles actually lead to decentralization, or whether participation concentrates in a small set of actors.

Thanks for the hard work behind this proposal!

1 Like