Skip to main content

Distribution of SLOTs in LSD Network

Overview

LSD comprises of 3 pools for validator staking: node operators (Managed by LiquidStakingManager.sol), fees and MEV pool (managed by StakingFundsVault.sol) and protected staking pool (managed by savETHVault.sol).

This article will deep dive into the Fees and MEV pool as well as the node operator deposits and their relation with the SLOT tokens (8 SLOTs per validator) on the Stakehouse protocol.

Note: LSD Protocol is an application on top of the Stakehouse Protocol Staking Operating System. Stakehouse is not aware of the applications built on top of it such as LSD but the concepts in LSD can be mapped onto the Stakehouse registry which is an inventory management system taking care of assets sat on the consensus layer.

For every BLS public key in the LSD protocol, 4 ETH comes from the node operator, another 4 ETH comes from the Fees and MEV pool to make the 8 ETH required for the Stakehouse protocol to mint SLOT.

When the Stakehouse Protocol mints 8 SLOT tokens, half is collateralised (which is managed by the Stakehouse contract - SlotSettlementRegistry.sol) and the other half is free floating SLOT tokens (sETH). The 4 SLOTs collateralized by the Stakehouse Protocol are still owned by the depositor. In the case of LSD, the depositor is the smart wallet of the BLS public key. The smart wallet is the owner of the collateralised SLOT and re-delegates the rights to a node runner. A node runner can interact with their smart wallet via the LiquidStakingManager.sol contract of a LSD network.

It is through the LiquidStakingManager interface that a node runner can request their rewards from the Syndicate (they don’t go directly to a syndicate). The Stakehouse protocol requests 4 ETH collateralisation in case the node operator misbehaves and needs to be slashed for any loss of consensus layer staked ETH. Hence, the node operator will be directly responsible for any leaking or slashing. This is key for permissionless node running.

The 4 free floating SLOTs are minted in the form of sETH. Each free floating SLOT translates to 3 sETH tokens, meaning that 4 free floating SLOTs are equivalent to 12 sETH tokens at initial mint, with more sETH active balance available later as the protocol mints dETH. sETH is specific to a Stakehouse where an LSD Network is a Stakehouse (collection of validators) with a 3 pool staking strategy to reduce the barrier to entry on staking. LiquidStakingManager.sol is therefore a wrapper contract on the management of a Stakehouse which is deployed within the Stakehouse protocol. Every LSD network has a LiquidStakingManager deployed by the LSD factory which maps 1:1 with a Stakehouse once the first validator in the LSD network has minted derivatives - until that point the Stakehouse address is not known. Having said that, not every Stakehouse is associated with an LSD network since other applications can deploy Stakehouses and curate their own collections of validators.

It is possible to query the associated Stakehouse for an LSD network here: https://github.com/stakehouse-dev/lsd-contracts/blob/main/contracts/liquid-staking/LiquidStakingManager.sol#L122

interface-overview

SLOT management in LSD

As we have established, SLOT is either sat with a node operator or with the Fees and MEV LPs. We can think of it like this:

  • Node Operator -> Smart Wallet -> Collateralised SLOT
  • Fees and MEV LP -> Staking Funds Vault -> sETH (Free Floating SLOT)

Where the interface for each user is different:

  • Node Operator -> LiquidStakingManager.sol
  • Fees and MEV LP -> StakingFundsVault.sol

Because the SLOT tokens represent execution layer revenue, 50% of the LSD network revenue is being split equally between both users. The splitting of the revenue is done through the help of the Syndicate.sol LSD contract. However, as mentioned above, it is not accessed directly to claim revenue.

Each user will use the appropriate interface to claim rewards - the contracts will take care of the distribution.

Therefore:

  • If you have a smart wallet -> you can access node operator rewards
  • If you have a Fees and MEV LP -> you can access the pro-rata share of the rest of the network rewards depending on how much you own of the LP token

Mapping wallets and LP tokens to BLS keys

To understand what BLS key is mapped to a smart wallet or fees and MEV LP token, you need to use the respective interface.

LiquidStakingManager.sol

/// @notice Smart wallet used to deploy KNOT
mapping(bytes => address) public smartWalletOfKnot;
/// @notice Smart wallet issued to the Node runner. Node runner address <> Smart wallet address
mapping(address => address) public smartWalletOfNodeRunner;

Given a node runner ECDSA address, you can use the smartWalletOfNodeRunner mapping to see if they have a smart wallet in that LSD network. Node runner to Smart Wallet is a 1:1 mapping for a given LSD network. All the validators they set up will all be through the smart wallets and the pro-rata rewards based on total validators set up in the set work is through this smart wallet. Given a BLS key, you can check whether it was set up in that smart wallet or not so you can take that as an additional input from the user and use msg.sender to check for a node runner.

StakingFundsVault.sol

/// @notice LP token address deployed for a KNOT's BLS public key
mapping(bytes => LPToken) public lpTokenForKnot;
/// @notice KNOT BLS public key associated with the LP token
mapping(LPToken => bytes) public KnotAssociatedWithLPToken;

These mappings in the Staking funds vault will allow you, for a given fees and mev fren delegation LP token, to map the associated BLS public key and vice versa.

Using the Stakehouse Solidity API here, you can determine whether the BLS public key associated with the LP token is yielding: 

getAccountManager().blsPublicKeyToLifecycleStatus(_blsPubKey) == IDataStructures.LifecycleStatus.TOKENS_MINTED

If the lifecycle status is TOKENS_MINTED, it means that if the Syndicate receives ETH, this LP token can claim a pro-rata share of that yield.

Slot Registry Pointers

Installing the Stakehouse API mentioned above gives you access to the interfaces:
https://github.com/stakehouse-dev/stakehouse-contract-interfaces

Of specific interest will be the slot registry interface. The reason the API is recommended is that it’s wired up to the correct contracts already. But in any case, here is the slot registry interface:
https://github.com/stakehouse-dev/stakehouse-contract-interfaces/blob/main/contracts/interfaces/ISlotSettlementRegistry.sol

The registry gives you a lot of useful methods for understanding and querying information related to the collateralised slot being managed by the registry: 

totalUserCollateralisedSLOTBalanceForKnot

For a given house (remember you can query the stakehouse from the liquid staking manager), user and a BLS public key, the current collateralised balance can be queried. It will be 4 SLOT unless the user has been slashed. In the case of the liquid staking network, the user is the smart wallet and remember the smart wallet of a node operator can be queried from the mapping in the liquid staking manager: 

numberOfCollateralisedSlotOwnersForKnot

Most proposer KNOTs will only have 1 collateralised slot owner holding 4 SLOT but in the case of a slashing and the topping up of the SLOT back to 4 is not done and owned by the original creator of the knot (smart wallet in the case of the LSD) then collateralised slot ownership can be shared and there can be more. This method allows indexing all the collateralised slot owners for a given BLS key given once you query the owner at the index and you know the house, you can get the balance with the method mentioned above.

slot-flow