Implementing SSV into the AUDIT.one ETH2-Staking Pool

Proposals Grants
1

Summary:

AUDIT.one requests a grant to implement the SSV protocol into the ETH2 Staking Pool solution which is under active development.

The grant will serve to partially off-set the cost of the additional development required to implement SSV as a core module, instead of only using nodes fully operated by AUDIT.one.

What AUDIT.one is currently building:

AUDIT.one is the infrastructure arm of Persistence, and is one of the biggest validators in South Asia, running secure validator nodes across more than 25 leading Proof-of-Stake networks. As part of our strategy to build reliable staking products for both retail and institutions, we are developing a staking platform that facilitates staking across multiple networks.

More specifically for ETH2 Staking, we are building a staking protocol that contains the following features:

  • Straightforward UX/UI to deposit any amount of ETH
  • Pooling of deposits smaller than 32ETH
  • Auto-compounding of rewards
  • Composability: allowing liquid staking protocols, exchanges, etc to plug in easily.
  • User Dashboard with overview of assets staked and accumulated returns
  • Reporting module for tax & compliance

Why we want to bring SSV into our solution:

What we are currently building is not as decentralised as we would like it to be. As believers in decentralisation, we praise how the SSV protocol is designed to eliminate the risk from a single point of failure in the operator holding the validator keys. However, the extra layer of decentralisation creates extra complexity towards end users in the form of:

  • Having to analyse and trust at least 4 node operators. This makes compliance very complicated for institutions.
  • End users have to hold SSV tokens in order to pay for the protocol fees. (SSV fee model to be confirmed)

Therefore we want to include the following SSV-related features into our ETH2-staking solution.

  • Curated sets of Node Operators (open or private) to facilitate institutional Staking requests.
  • Automated split of keyshares amongst chosen node operators.
  • Automated Payment of SSV fees, from Staking rewards via integrated swaps
  • Option for payouts in SSV, opening up the protocol for incentivised staking (TBC)
  • Option for reduced fees for SSV-stakers, driving demand for SSV token (TBC)

Our approach, timelines, and estimated budgets.

While developing our full-fledged solution will take multiple months, we aim to have a first simplified version of the protocol up and running before The Merge, in order to leverage the traction ETH-staking will get around that time, thereby hopefully attracting a lot of ETH into the SSV protocol.

Version 1 main features (development ongoing):

Feature / module Funded by:
ETH Deposit Contracts (ongoing) AUDIT.one
Pooling Contracts (ongoing) AUDIT.one
Basic Front-end UX/UI Design (ongoing) AUDIT.one
Enable 1 curated set of operators SSV Grant request: $30,000
Rewards Calculation module SSV Grant request: $30,000
Security Audits AUDIT.one
SSV Fee Payment AUDIT.one, or via a separate grant request, depending on the fee mechanism

⇒ Target timeline: April 2022.

Version 2 main features:

Feature / module Funded by:
Enable multiple curated sets of operators SSV Grant request: $20,000
Withdrawal features (depending on ETH2) SSV Grant request: $30,000
Staking Dashboard AUDIT.one
SSV Fee payment via protocol returns SSV Grant request: $30,000
Security Audits AUDIT.one

⇒ Target timeline: July 2022, depending on the Merge timeline

Version 3 main features:

Feature / module Funded by:
Enable open creation of pools SSV Grant request: TBD
Reporting AUDIT.one
Auto-compounding of ETH-rewards AUDIT.one
Introduction of SSV rewards and reduced fees for SSV Stakers (TBC) SSV Grant request:TBD
Security Audits AUDIT.one

⇒ Target timeline: October 2022

Requested Grant Amount:

Grant Request for Version 1: $60,000 - upon acceptance of the Grant
Grant Request for Version 2: $80,000 - upon deployment of Version 1
Grant Request for Version 3: TBD, a separate proposal will be submitted later on.

2

Hi Audit.One, it’s great to see you guys wanting to develops this. I think it’s greatly needed!

Could you elaborate on the points that require a grant, give a brief overview of what would you build and why should the DAO give a grant for those specific components?
For example, I’m not entirely sure why developing a withdrawal (which is an ETH2 wide thing) for stake should require a grant.

Thanks!

4 Likes
3

Hi Alon, thanks for your question. Of course happy to elaborate on the points for which we require a grant.

Basically our reasoning is that we’re asking for a grant for the elements of our solution that will significantly increase our efforts required to launch the product into the market, compared to building a solution without the SSV protocol. If we would have to develop the feature even for a solution without SSV, we would be funding it ourselves.

Below is a more detailed vision of each of these features:

Version 1:

  • Enable 1 curated set of operators: This feature will allow us to create a set of SSV node operators to operate the initial validators behind the stakepool. This needs to be built in an open and composable way so that later on we can enable adding more curated sets. A solution without SSV would not need this, hence the grant request.
  • Rewards Calculation module: While rewards calculation is needed for any solution, the use of SSV makes it more complex, especially with multiple operator sets, and even more so if we want to offset the SSV Fees from the rewards. As the validator rewards will depend on the operator pool, the reward mechanism has to factor in which operators are used to run the validator on the users’ behalf. We will be using the Protocol Rewards to offset SSV fees, which needs to be accounted for in the rewards calculation

Version 2:

  • Enable multiple curated sets of operators: Same reason as for version 1

  • Withdrawal features: As it looks now, withdrawing rewards requires withdrawing the validator completely, which is not yet defined in SSV. We foresee quite a lot of complexity here, especially if we have to automatically withdraw the validator, distribute the rewards, and spin up a new validator with the 32 ETH, which would incur an SSV fee again. The final solution will depend on the ETH withdrawal features and the SSV withdrawal features, which are both unclear at the moment.

  • SSV Fee payment via protocol returns: Very specific SSV-feature which again will depend heavily on both the SSV Fee mechanism and the Ethereum withdrawal mechanism.

Hope that clarifies our thinking, do let us know if you have further questions.

Thanks

Jeroen

1 Like
4

So in that case the withdrawal feature in version 2 is not part of the grant?

5

It is. We estimated this withdrawal feature of v2 for the grant request at $30,000, but chances are that we will end up above that, in which case that would be on us to complete it regardless.

6

Is there a particular challenge in withdrawals you see? In respect to SSV?

7

Yes, we believe that providing a smooth user experience in the withdrawal process, and especially in a partial withdrawal process, will be quite challenging. A solution in which we’d have to exit the validator to ‘skim off’ the rewards isn’t ideal, hence we’ll be looking into the possibilities of a key-rotation mechanism within SSV to optimize this flow. A particular challenge is that we’re dependent on specs which are not final, hence we’ll have to adapt to the final specs of both Ethereum & SSV.

We hope to get the SSV community involved as well in order to find the best possible solution.

8

one question about this feature: ---- Composability: allowing liquid staking protocols, exchanges, etc to plug in easily.

Does it means uniswap can stake ETH from liquid pool to ETH2 validator ? will it be full decentralized ?
when it happen, who will manage the validator key & withdraw key of staked ETH from uniswap’s liquid
pool ?
smart contract manage keys ? or audit.one will manage all keys of dex/cex staking eth ?
if audit.one manage keys, when uniswap want to withdraw eth from staking, it should be withdraw by audit.one manual operate ?
so it is not full decentralized, what is the diffirence if uniswap stake eth to lido ?

9

Hi,

I’m sorry but I’m not sure what you mean exactly with ‘uniswap can stake ETH from liquid pool’? Can you clarify? As far as I know, that’s not a service Uniswap or other DEXes typically provide. When we mentioned exchanges above, we were more thinking of Centralised Exchanges, allowing them to integrate with our solution so that users who hold ETH on these exchanges can stake via our solution.

Either way, to answer some more of your questions around key management:
Our oracle bot will create the validator keys and split them among the SSV node operators participating in our protocol. The withdrawal keys (address of our withdrawal contract) will be managed by our staking pool contract.

Hope this answers your question?

10

The snapshot proposal for this grant request is live and can be found here:

https://snapshot.org/#/mainnet.ssvnetwork.eth/proposal/0x503b23c01cf4aa39cdf20441f84f55d3bf6c6e182ecd2e32bfc2960b71707252

Inviting everyone to vote. Thanks a lot in advance!