Owner: @Álvaro Castro-Castilla

Reviewers: @Thomas Lavaur @Frederico Teixeira @Marcin Pawlowski @Daniel Sanchez Quiros

<aside> 🚨

I recommend reading EigenLayer's paper. Specially to understand its advantages and possibilities. Here I will focus exclusively on the requirements for our protocol, drawing parallels with EigenLayer where it helps.

</aside>

• EigenLayer provides a new mechanism for pooled security by enabling modules to be secured by restaked ETH rather than their own tokens.
• Pooled security means that the different actors put together their assets in order to secure multiple protocols simultaneously.
• Note that our SDP protocol is essentially an enshrined and minimalistic Restaking protocol.

How EigenLayer and restaking works + Nomos’ requirements

• Ethereum validators can set their beacon chain withdrawal credentials to the EigenLayer smart contracts, and opt into new modules built on EigenLayer. In our case we are able to maintain ownership of the notes, which is a superior solution to controlling all the assets from a single contract - specially when this functionality is promoted for as many validators to participate as possible.
• The validators download and run any additional node software required for these modules. In our case, this corresponds to engaging in one of the SDP services (Blend, DA… but they are already implemented in the node).
• The modules then have the ability to impose additional slashing conditions on the staked ETH of validators who opted into the module. In our case, each SDP protocol that a validator has decided to participate in defines its own reward and slashing conditions:
  • An important difference here with Eigenlayer, is that our SDP protocols can potentially increase the total supply of $NMO, because they are endogenous to the system.
  • In contrast, in EigenLayer all extra rewards must follow an exogenous flow: ETH is sent from the user using the services (not minted anew), which flows to the SDP service providers.
  • This is not to say that we MUST mint, just that we have this possibility. It's probably better if we don't since it will greatly simplify our tokenomics.
• For example, if the module is a Data Availability layer, restakers via EigenLayer will receive a payment whenever data is stored through the module. In return, restakers are subject to slashing conditions that are exercised through proof-of-custody.
• EigenLayer creates a marketplace in which validators can choose whether to opt in or out of each module built on EigenLayer. For Nomos, this means that validators should have some indication of what rewards are they going to obtain from participating in different services by subscribing to their SDP.

Other key points

• EigenLayer does not issue a fungible token representing restaked positions, as each restaker may opt-in to validating different combinations of modules and thus be subject to different sets of slashing risks. This has a simple translation in Nomos: each validator can freely choose which services to participate in. We do not have liquid restaking or delegation functionality (on purpose!). But for protocols that build these on top, they will face the same issue as Liquid Restaking Tokens: they have to choose which AVS to participate in, their risks, and users will own these assets or not. This is currently seen in LRT such as Kelp, EthFi, and bunch others.
• Restaking for Sovereign Zone security. I was wrong on this one. I've been thinking more on this, and I don't think it currently fits in our model.
  • Restaking is about the reuse of the same stake in other protocols, pooling security together, but it requires these stake owners to become operators of those protocols - otherwise we are talking of delegation.
  • The way to do this, mimicking what EigenLayer does, is to have Nomos validators directly participate in the Sovereign Zone. That's great, but this doesn't guarantee economic security by itself: imagine having only 7 nodes running the Zone. That's clearly insufficient economic security unless there is delegation involved, and yet, this is precisely the kind of scenario we might expect in Sovereign Zones using MPC, TE, or TFHE.
  • If the objective is to have a separate network of nodes running the Sovereign Zone consensus (which is what Sovereign Rollups do!), what we would need here is something more akin to “redelegation", which is increasing the economic security by delegating $NMO to other nodes. This was actually the original idea, but I do not see the advantages to this anymore:
    • While it allows for increased economic security, delegation decouples the accountability of the validators from their economic weight in consensus. In other words, validators are playing with the money of others. A potential way to mitigate this is by having higher penalties for the native stake vs the delegated one, but this would always depend on the Sovereign Zone to design it properly.
    • Generally, projects are incentivized to have their own token (that's the usual practice in the industry, for obvious reasons). Any mechanism built on the SDP should be focused on the restaking of $NMO exclusively, so it would only be useful in a hybrid approach where security is provided both by the Zone's token and the $NMO. In any case, this would fall into the (re)-delegation approach mentioned above.
    • A hybrid approach is also considered by EigenLayer, which offers flexibility for AVSs to define their own quorum alongside a quorum comprised of restaked ETH, and requires the final response to its validation tasks to be a function of responses from a majority of each quorum. For example, an AVS can specify two quorums, an Ethereum restakers quorum and an $AVS quorum (where $AVS is the AVS’s token).
  • In conclusion, the best we can expect from restaking alone is to slightly increase the economic security of Sovereign Rollups by having the validators of said zone be also validators of Nomos and add their Nomos stake to this Zone. This mechanism is of dubious utility unless the number of validators is substantial (perhaps >100), which is not our base case (ie bootstrapping Sovereign Zones). As a consequence, I think it's better to park this functionality for now, but with the idea in mind that we could extend our current SDP protocol to allow for attaching arbitrary slash/reward contracts (which is all that is needed for a generic restaking protocol).

Conclusion and Requirements

In conclusion, the core target of the Nomos restaking infrastructure, as implemented by the SDP protocol, is to fulfill the following requirements:

• Coins that participate in PoL can subscribe to participate in other protocols through the SDP protocol.
• We will focus for now on:
  • Restaking for DA
  • Restaking for Blend
  • Restaking for the Executor Network
• The SDP protocol requires:
  • A slash contract, and a way to easily apply slashings (per block or per epoch, but we need to be aware that slashing will potentially kick out nodes from a role if they are below the threshold, so delay should be limited)
  • A reward contract, and a way to easily apply rewards (per block or per epoch, this is not so critical)
  • Ideally, these are designed in a generic way to allow further expansion in the future to the (potential) Restaking for Sovereign Rollups service