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

[arielzimroni]

@GBeast

The liquidation collateral ought to be expressed as simply as possible, and perhaps should be displayed separately from the total ETH on deposit.

It would also be very helpful to see the current daily burn of your cluster, so you can see how it compares to the operator fees in the account.

The migration interface is designed to make this explicit. Before migrating, cluster owners will see a clear breakdown comparing what they are paying today versus what they would pay after migrating to ETH

@GBeast

Future possibility: A wallet can deposit ETH in just one account, and have it supply operator fees and collateral to all the clusters associated with that wallet. That way they wouldn’t have to check the balance of each cluster individually.

A shared-balance accounting model was explored in earlier pre-mainnet designs. Ultimately a per-cluster accounting was chosen due to the gas costs and complexity such a model introduced at the time

This is something we continuously re-evaluate as Ethereum evolves - especially as gas costs and protocol primitives improve. If and when this model becomes scalable and efficient enough, it’s something we would consider proposing again

@Ethernodes

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.

Approaches like temporary grace periods were considered, but they introduce meaningful tradeoffs. Suspending or delaying liquidations creates an insolvency risk for the network, since clusters could continue operating without sufficient collateral to cover payments.

It also tends to push behavior in the opposite direction - rather than encouraging early migration and preparation, grace periods incentivize waiting until the last possible moment

the approach here is to prioritize early and clear communication. It’s important that cluster owners understand the upcoming changes well in advance, assess how long migration will take for them operationally, and provision sufficient runway ahead of time to avoid last-minute pressure

@Ethernodes

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.

This upgrade has no impact on the SSV node itself and operators are not required to upgrade to a new node version.

@markoInEther

What’s the minimum notice period?

Please refer to my comment to Ethernode. on the notice period - the notice period should be considered effective immediately. Cluster owners and stakers are expected to plan for migration now rather than relying on post-launch grace mechanisms.

@markoInEther

On “anyone can submit proofs”

The permissionless proof submission design is interesting in theory, but who actually has incentive to do this? If there’s no reward for submitting proofs, rational actors won’t bother, which means oracles become the de facto submitters for all clusters.

There are no incentives (unless a specific case of submitting a proof that results in a cluster becoming liquidatable, the submitter receives the liquidation collateral) - thats why proof submission is primarily the responsibility of the Effective Balance oracle set by design.

The reason this flow is permissionless is not because it needs third-party participation, but because it doesn’t need to be permissioned - submissions are fully validated against the committed Merkle root.

Making it permissionless also provides a fail-safe: if oracles fail to submit updates for any reason, anyone can do so without special permissions.

@markoInEther

Proposal: The DAO should allocate dedicated funds for proof submission and select a third party to run this as a service. Otherwise, I fear this becomes an unfunded mandate that nobody fulfills reliably, and we end up with stale balance data across the network.

This is already how the system is designed to operate - it’s handled by the effective balance oracle set itself.

@markoInEther

Reward distribution mechanism

How exactly do ETH fees flow to stakers? Is this:

• Continuous streaming?
• Epoch-based batches?
• Manual claiming from a pool?

Rewards accrue continuously to stakers based on their share of staked SSV.
Accrued ETH can be claimed by stakers at any time.

@markoInEther

What’s the projected ETH yield on staked SSV? Even rough estimates would help the community evaluate whether this model actually provides meaningful returns or if we’re looking at <1% APY on SSV-denominated terms.

This has already been shared on the forum and in community calls.
For concrete scenarios and yield estimates, see:
https://ethaccrualtoken.com/

@LemmaGov

A concise, high‑level summary of how the effective balance oracle system is expected to behave under adverse conditions (e.g., delays, inconsistencies, or failures), and which levers governance has to intervene or adjust if those conditions persist.

The oracle set operates with a threshold model, which provides inherent fault tolerance as long as a quorum of oracles remains operational.

If oracle updates are delayed or fail to occur, cluster balance updates can still be submitted permissionlessly by anyone, as proofs are fully validated against the committed Merkle root.

If underperformance persists, the DAO retains direct control to intervene - including replacing individual oracles or the entire oracle set, providing a governance lever to restore correct operation.

@LemmaGov

A simple, scenario‑based narrative of how operators and stakers are expected to migrate in practice from SSV‑denominated to ETH‑denominated clusters, including any assumptions about timelines and steady‑state outcomes.

The practical implications of migration are already described in the proposal.

From an operator perspective, no action is required to support migration. Operators are not required to upgrade software or take operational steps. The default ETH fee ensures operators can continue servicing existing stakers as clusters migrate.

From a cluster owner perspective, migration is expected to happen at their convenience, bounded by their existing runway (or any pre-funded runway). Migration becomes necessary once they need to perform cluster operations that are no longer supported under SSV-based clusters.

@LemmaGov

Guidance on how often, and under what triggers, the DAO expects to revisit key economic parameters (such as liquidation windows or collateral levels) as network conditions change.

The DAO already revisits key economic parameters on a recurring basis.

Network-level parameters such as the network fee are reviewed on a monthly cadence, while liquidation-related parameters are revisited on a quarterly basis.

@damon

• Are Network fees charged for validators that are not yet staked or not yet activated?
  For larger operators, it is common to upload a significant number of validator keys in advance, and these keys may remain unstaked for an extended period of time. If Network fees are charged for such inactive validators, this could introduce additional cost overhead and potentially reduce the willingness to use SSV.
• For public Operators, are Operator fees charged for validators that are not yet staked?
  If unstaked validators are not charged Operator fees, could this lead to a large number of unstaked validators occupying an Operator’s validator slots, thereby impacting normal operations and resource allocation?

Network and operator fees are treated the same way so will reply on both:

Validators begin paying both network and operator fees once they are onboarded to the SSV Network, regardless of their beacon chain status. This is how the network operates today, and this behavior does not change with the move to ETH-denominated accounting.

What does change is how effective balance is accounted for. Until effective balance data is reported by the oracles, each validator is treated as representing 32 ETH. This means that validators which are already consolidated (or intended to be consolidated) will temporarily underpay relative to their eventual effective balance until oracle updates occur.

We recognize this isn’t ideal and are actively evaluating ways to further optimize and mitigate this behavior.

As an interim measure, we’re also working on off-protocol tool that can be used programmatically by cluster owners to monitor validator status and register validators only when they’re actually needed, rather than far in advance. We’ll be sharing this tooling separately in the near future.
.

On questions regarding the future design of the effective balance oracles -

The reason many of these questions don’t yet have fully specified answers is that the next phase of the oracle set is not finalized yet. Once that design is ready, it will be shared with the community to gather feedback before proposing anything to governance.

To clarify the most immediate and practical concerns for the initial phase:

• The initial oracle set is permissioned

• During this phase, stakers continue to accrue rewards regardless of oracle performance or delegation outcomes.

• Delegation is not user-driven - a default delegation is applied where all staked SSV is split evenly across the active oracle set.