Liquid solo validating

Special thanks to @vbuterin, @fradamt for design ideas and to @djrtwo, @timbeiko, Vasiliy Shapovalov, Isidoros Passadis, Kelly Olson for feedback.

TLDR: We propose a fungible and governance-free liquid staking derivative (LSD) compatible with solo validating. The LSD is secured via hardware-based slashing protection and enjoys higher capital efficiency than Lido’s stETH.


We first describe a slashing-protection program P running in trusted hardware such as Intel SGX. The program generates signing key pairs (pubkey, privkey) such that privkey is kept private within the secure enclave. Signing beacon blocks and attestations is done by the trusted hardware (which maintains a small and prunable database of previously-signed material) to protect against slashing.

We now describe the smart contract C managing the staking derivative, which we denote sETH.

  • minting: The contract mints 31 sETH for every validator that sets C as its withdrawal contract and provides a hardware attestation (a signed message verifiable onchain) that its keys were generated by P. (Notice 32 staked ETH is backing 31 sETH, with 1 extra staked ETH acting as collateral.)
  • ejections: The contract ejects, upon receipt of a proof, validators that have a balance under 31.99 ETH (and have C as withdrawal contract). A small reward (e.g. 0.1 sETH) incentivises triggering the ejection. (Ejections by withdrawal contracts require in-consensus support which is actively being worked on.)
  • redemptions: The contract operates a first-come-first-served queue for redemptions of sETH for ETH, similar to Lido’s plans for redemptions. Redemption requests may trigger ejections as appropriate to withdraw liquid ETH from validators.

Security argument

We argue that every 1 sETH is backed by 1 ETH. There are only two types of validator penalties:

  • slashing penalties: This is prevented by the trusted hardware. Note that the hardware assumption can be hardened to an n-of-n assumption using an n-of-n secret-shared BLS signing key with the n BLS key shares split across n devices from different manufacturers.
  • non-slashing penalties: Validators enter the exit queue soon after their balance goes under 31.99 ETH. Since non-slashing penalties accrue slowly, the withdrawable validator balance (minus 0.1 ETH to cover the ejection incentive) will likely not go under 31 ETH (a value configurable to match protocol risk tolerance).

Advantages over Lido

  • solo validation: The design is friendly to untrusted solo validators, including small stakers validating from home.
  • no governance: The design does not require a governance token to manage a whitelist of operators.
  • capital efficiency: The design has a capital inefficiency of roughly 3% if 31 sETH is minted for every 32 ETH validator. Lido has roughly 10% capital inefficiency from delegation fees—5% operator fees, 5% Lido fees.
  • no cartelisation risk: The design does not require delegation to operators which may cartelise. This reduces exposure to social slashing.
  • decentralisation ethos: The design improves alignment with Ethereum’s decentralisation ethos.

The fundamental tradeoff suffered by the design is the reliance on the n-of-n hardware assumption. Unfortunately, Intel SGX may currently be the only secure hardware platform with externally-verifiable attestations.

Productive vs non-productive sETH

As described above, sETH is a non-productive LSD redeemable for the principal of participating validators. Such non-productive LSDs are sufficient for use cases such as leveraged staking, exposure to staking rewards without exposure to ETH, as well as early liquidity prior to clearing the exit queue.

If desired, the design can be modified to make sETH a productive asset with exposure to staking rewards, similar to Lido’s stETH. This can be done for consensus-layer rewards by having validators cover for any sub-optimal performance using the extra staked ETH collateral. This can also be done for transaction fees and MEV with in-consensus MEV smoothing.


Definitely a fan of the idea of liquid staking with solo nodes, I would like to add some extra info to the following:

This is prevented by the trusted hardware. Note that the hardware assumption can be hardened to an n-of-n assumption using an n-of-n secret-shared BLS signing key with the n BLS key shares split across n devices from different manufacturers.

The fundamental tradeoff suffered by the design is the reliance on the n-of-n hardware assumption. Unfortunately, Intel SGX may currently be the only secure hardware platform with externally-verifiable attestations.

We at Obol are aiming to reduce this from an n of n to an m of n assumption through the use of Distributed Validator Technology. The basic idea is rather than using a straightforward BLS aggregation combining many public keys and many signatures, we use a Lagrangian interpolation to have an m of n signature scheme, allowing for fault tolerance of nodes, where 1 (or more) node(s) going down does not prevent signature reconstruction.

This is enabled by each of the nodes playing a BFT game to decide on what to be signed, to ensure all nodes are signing an identical object, a pre-requisite for signature aggregation. In future, we aspire to having groups of operators run these distributed validator clusters together, reducing the trust in single staking operators further.

We achieve this by building a middleware client that sits between beacon node and validator node and intercepts their REST API communication. The clients (called charon) first come to consensus on what each validator should sign, and then once any of the charon clients in the cluster receive the minimum threshold of partial signatures, they reconstruct the aggregate signature and broadcast it to the wider Ethereum network through their beacon node.

Here is a testnet validator that is in fact a combination of 4 lighthouse and teku validators working together to sign duties (currently they are all on one machine and containerised, and are polling infura as a BN, so don’t take the performance as representative of what this technology aims to achieve in production, we are still in relatively early days of the development process :sweat_smile:)

And one last thing dating to before I started Obol was my belief that the pooled risk of LSD’s would become a threat to the network and to consumers in general, and I built a prototype of representing validators as NFTs rather than fungible ERC20s. I strongly believe many LSD protocols are not prepared for the non-linearity of punishments in proof of stake Ethereum, for example, a 1 ether buffer is sufficient for uncorrelated slashings, but a correlated slashing event could put this proposed derivative into bad debt. Having non-fungible representations of validators would in my opinion be a superior base on-chain representation of stake that you could build fungible LSDs on top of. :slight_smile:


To repeat what I said here: Withdrawal Credentials Exits Based On A Generalized Message Bus - #7 by A1igator

Some form of liquid staking for solo validators is needed to keep them competitive with leveraged staking. The proposal above is obviously not ideal due to trust assumptions of Intel SGX but I’m glad EF is heading to this direction.

@MicahZoltu rightfully does point out that this reduces the cost of attack so I think that’s good to keep in mind as well.

SGX actually got deprecated from retail processors and is only now available for servers IIRC, so I am not sure how compatible this is with at-home validating, unless you expect consumers to have access to that kind of hw?

I think the core takeaway here is to use SSV / DVT as @OisinKyne wrote above where possible, to prevent misbehavior from individual parties, as we had highlighted on our post last year.


to design a productive sETH, similar to stETH, it seems like requiring an oracle to report balances of validators?

This will hopefully change in future, pre-merge there was no link between the chains, and an oracle was required to update aggregate validator balances.

Post-merge we will start with the beacon chain state merkle root being accessible by the EVM, which is the beginning building block for proving validator balances directly on chain.

It will likely require both solidity and core client development to make a more scalable API for reading from the consensus layer within the EVM to the point where someone like lido could do the entirety of their validator accounting on chain, but I believe it will be achieved and can negate the need for oracles to aggregate and report validator balances in most liquid staking derivatives, a significant win for their trust models.


I think it is important to clarify that DVT is now the defacto name of this primitive. Inside of the DVT spectrum you have different implementations / flavors being built by Obol and SSV network. Unfortunately, SSV the name (created in the early days by a few of us) was taken by one of the projects in this segment. In addition, it proved to be difficult for adoption as it was too technical/abstract for most.

DVT is having a very important adoption moment right now and language/communication is essential.

We appreciate the support @gakonst


Laptops and NUCs carry SGX instructions somehow randomly. But desktop CPUs no. If ETH doesnt drop to 80$ again, 1 ETH would pay for a Xeon setup heck 0.5 ETH even for a low-end Xeon+Mobo with SGX. Only LGA4189 mobos are kinda out of stock ATM for 3rd gen Xeons which came in 2021-2022 and going for 1k a pop.