Vault curation on Symbiotic

How much shared security should we allocate to which Networks in Symbiotic? We present a methodology that guides MEV Capital (as Curator) and Nodeinfra (as node Operator) in making this decision.

Our goal is simple: maximizing the risk-adjusted returns from Symbiotic Networks for restakers. The primary risk to minimize is the slashing risk that could lead to the loss of restaker collaterals. The return to maximize is the value of rewards that restakers receive from Symbiotic Networks in exchange for providing economic security.

In this article, we focus on minimizing slashing risks by gauging the risks of Networks. We first examine how slashing works in Symbiotic. We then identify slashing risk factors that increase the probability of a slashing event. We design a methodology to evaluate these risk factors for any Symbiotic network. Using this methodology, we evaluate an example of a network. Finally, we discuss future work, and conclude.

We hope this article contributes to the Symbiotic ecosystem by presenting:

An examination of code paths in Symbiotic smart contracts that could lead to slashing
Analysis of risk factors arising from Symbiotic’s flexibility and modular nature
A multi-dimensional risk approach to evaluate software, governance, and communication
A case study on Stubchain, a Symbiotic network based on the Cosmos SDK

1. Slashing in Symbiotic

We describe how slashing—which penalizes retsakers and operators for malicious behavior or underperformance—is invoked in Symbiotic. We provide a brief overview of the Symbiotic related parties and examine the code path leading to slashing. We then describe a slashing scenario using StubChain [1], an example of a Symbiotic network.

1.1. Overview of Symbiotic

The Symbiotic ecosystem consists of vaults, curators, operators, networks, and resolvers. Vaults are contracts that receive collaterals from restakers and delegate the collaterals to node operators. Curators perform risk management for restakers and optimize the allocation of collaterals across different vaults. Operators are entities that run nodes to validate networks by provisioning the delegated economic security. Networks are decentralized protocols that utilize Symbiotic to source their security. Resolvers are contracts or entities that veto slashing incidents.

The network middleware contract (Middleware [2]) binds operators, networks, and resolvers. Operators and networks agree on which Middleware implementation to use. Middleware has two key functionalities. First, Middleware provides methods to identify which operators and how much of their stakes are participating to secure the network. Second, Middleware provides methods to initiate slashing, which may involve resolvers to potentially veto slashing.

1.2. The slashing code path in Symbiotic ecosystem

The above diagram depicts a simplified overview of the slashing code path for a Symbiotic network. Distributed nodes managed by operators initiate slashing by invoking the Middleware contract. Slashing is propagated to the Slasher contract, and ultimately to the Vault contract where collaterals reside. In the process, resolvers can veto the slashing request.

Slashing in Symbiotic ultimately happens in the onSlash() function of Vault contract. The function transfers the slashed amount of collateral to the burner address, effectively making the transferred fund not accessible by anyone, resulting in a worst case scenario. We do not want this line to be executed on any collaterals we curate and run nodes for.

The onSlash() of Vault can only be invoked by a Slasher contract. Vault rejects slashing when onSlash() is called by an account or contract other than the configured Slasher. There are currently two types of Slashers: InstantSlasher and VetoSlasher. Slasher calls onSlash() instantly when its slash() method is called.

VetoSlasher provides three methods for slashing: requestSlash(), vetoSlash(), and executeSlash(). requestSlash() keeps slash requests from Middleware. vetoSlash() allows configured resolvers to veto the kept requests. The conditions under which the method gets executed are : 1. the caller should be the configured resolver and 2. the method should be called before the deadline. Ultimately, executeSlash() is called to penalize the vault by slashing it, but only if the veto process has failed to prevent this action.

Using the onlyNetworkMiddleware solidity modifier, both Slasher and VetoSlasher require that only the Middleware can initiate slashing. Middleware can be any contract that the Network and the Operator agree on. Middleware has public entry functions that allow external parties, particularly nodes managed by operators, to interact with it.

In summary, three components are essential in triggering slashing. First, nodes initiate the slashing process by interacting with Middleware. Second, Middleware determines the conditions under which slashing happens and invokes requestSlash() on the configured Slasher. Finally, assuming VetoSlasher(), Resolvers act as the final gatekeeper before the slashing is executed.

1.3. Example: Slashing in Stubchain

We examine a slashing scenario in an example Symbiotic network developed by the Symbiotic team called Stubchain. Stubchain is currently the only available open source Symbiotic network implementation. Stubchain extends the Cosmos SDK such that shared security sourced from Symbiotic secures the chain.

We first examine the Middleware implementation of Stubchain, called SimpleMiddleware. SimpleMiddleware faithfully provides the two key functionalities of Middleware: identifying the participating operators, and slashing the vaults associated with the operators.

As for the first functionality, SimpleMiddleware provides getValidatorSet() to identify the validator set for a given epoch. The function returns a list of ValidatorData, which specifies the operator key and the amount of stakes of the operator that are accounted for in the epoch. Note that it does not provide any information about the performance or malicious behavior of the validator.

Regarding slashing, SimpleMiddleware provides the slash() method to slash an operator.

The method has the onlyOwner modifier which means that only the account or contract that deployed SimpleMiddleware has the privilege to invoke this method. The function takes as inputs: the epoch, the operator(s), and the collateral amount, specifying how much amount to slash from which operator in an epoch.

Then, the slash() function finds the vaults associated with the operator, and slashes them using _slashVault(). The _slashVault() method is an internal method that invokes slash() from the slasher, configured at the inception of the dedicated SimpleMiddleware. Either InstantSlasher or VetoSlasher can be used by networks.

Stubchain extends the Cosmos SDK to integrate with SimpleMiddleware. Modified Cosmos SDK validators, which participate as the decentralized nodes of Stubchain, periodically issue an RPC call to the Ethereum L1 to invoke getValidatorSet() of the deployed SimpleMiddleware in order to fetch the validator information.Then, they use the information to compute the voting power of the participating nodes. Symbiotic operators are expected to run these nodes.

Although the Stubchain documentation mentions slashing based on the inactivity of the nodes, there is currently no direct integration between the validators and slash(). Nodes do not fetch information about slashing from SimpleMiddleware, and SimpleMiddleware does not maintain any information about the inactivity of the nodes. Instead, it simply provides slash() that can be only invoked by the owner. This means that there is a need for an additional trusted intermediary that has the SimpleMiddleware owner privilege to monitor the activity of the validators and request slash() based on it.

2. Risk Factors

We have observed complexity in slashing code paths, which makes it challenging to identify risk factors. The code paths involve multiple stakeholders spanning restakers, curators, operators, vaults, and resolvers. The paths are also invoked through complex software interactions between contracts on the Ethereum L1, such as network-specific Middleware implementations, and modules in the network node implementations.

To address this challenge, we take a practical approach by identifying three key risk factors that we believe have the most critical impact on slashing: software, governance, and communication. We provide the rationale for each of these factors and describe concrete examples using Stubchain.

2.1. Software

Software is a critical risk factor as slashing ultimately happens on-chain. In addition to the typical smart contract vulnerability risks, we examine risks stemming from the flexibility of Symbiotic. Although the core Symbiotic contracts such as the Vault and Slasher contracts are immutable, Middleware can be any smart contract the network developed. Nodes that connect to the middleware can be any distributed system, including Cosmos SDK and LayerZero DVN.

For example, suppose the Stubchain node implementation had a bug that resulted in incorrectly interpreting the data fetched from invoking getValidatorSet() on SimpleMiddleware. This may lead to slashing larger amounts of collaterals from vaults than what was originally planned, should the validators mistakenly provide wrong information to the Middleware owner that decides how much to slash when invoking slash(). Such software risks cannot be detected just by examining the smart contracts deployed on Ethereum L1.

2.2. Governance

Governance of different software components in Symbiotic is as important as software in determining slashing risk. The network’s governance determines software access privileges and updates to the software. Even with perfectly designed software, bad governance can easily lead to unintended or unfair slashing.

Compared to typical PoS chains where only restakers and validators are involved in governance, Symbiotic has a much more complex structure with restakers, vaults, curators, operators, resolvers, and networks due to its modularity.

For example, the slash() method of SimpleMiddleware can be called only by the owner of the contract. What is left unspecified in the current Stubchain implementation is who exactly the owner will be. In an extreme case where the owner is an EOA account sitting on a person’s laptop, that person can slash any vaults that opted into the network at free will.

2.3. Communication

Communication between responsible parties is critical in handling crises, and making sure different stakeholders are aligned and synced. As there are many different stakeholders in Symbiotic, a miscommunication between the parties at different layers (or lack of it) can potentially create flaws that may eventually lead to unintended slashing.

For example, suppose Stubchain uses Aragon [4] as its Resolver and a committee is assigned to vote on a slashing incident triggered by an attacker. If the committee is unresponsive and unable to vote before the veto deadline, the slashing will be executed, rendering the attack successful.

3. Risk Evaluation Methodology

Based on the three elements described above, we present our methodology to evaluate slashing risks of Symbiotic networks. Ultimately we assign a final score to a network based on its slashing risk. To compute the final score, we use a practical checklist that evaluates governance, software, and communication of three key components of the network: nodes, middleware, and resolver.

3.1. Risk scoring formula

Our scoring methodology utilizes a weighted sum approach to evaluate networks across 9 distinct categories, derived from the intersection of three elements and three components. Each category is assigned a weight reflecting its relative importance. Within these categories, we pose specific questions designed to gauge risks. Responses to these questions are quantified on a three-point scale : -1, 0, or +1. The final score for a network is then calculated using a formula that aggregates these weighted scores for each category.

3.2. Evaluating Nodes

a. Network nodes – Governance

Weight : 2 (important)
Weighted score range : Min -8, Max +8
Example : Symbiotic operators running nodes for the network

b. Network nodes – Software

Weight : 2 (important)
Weighted score range : Min -12, Max +6

Network examples : Cosmos SDK validators, Layerzero DVN nodes, oracles, sequencers

c. Network nodes – Communication

Weight : 2 (important)
Weighted score range : Min -8, Max +4
Example : Communication of node operators and network developers

3.3. Evaluating Middleware

a. Middleware – Governance

Weight : 3 (very important)
Weighted score range : Min -9, Max +6
Example : Privileged access to the Middleware

b. Middleware – Software

Weight : 3 (very important)
Weighted score range : Min -12, Max +9
Example : SimpleMiddleware [3] in Stubchain

c. Middleware – Communication

Weight : 1 (less important)
Weighted score range : Min -3, Max +3
Example : Communication of Middleware developers

3.4. Evaluating Resolver

a. Resolver – Governance

Weight : 2 (important)
Weighted score range : Min -8, Max +8
Example : Governance of a resolver committee

b. Resolvers – Software

Weight : 1 (less important)
Weighted score range : Min -3, Max +3
Resolver examples : Aragon, UMA, Kleros, Reality.eth

c. Resolvers – Communication

Weight : 2 (important)
Weighted score range : Min -8, Max +2
Examples : Communication of the member of the resolver committee

Our current checklist is far from complete or final. We plan to actively add, enhance, or remove eligibility criterias as Symbiotic networks go live and we learn more about their design and operation.

3.5. Rating and eligibility thresholds

We first compute eligibility thresholds for each component (nodes, middleware, resolvers) and each element (governance, software, communication) based on our scoring system. A negative score (< 0) for any of the 6 eligibility thresholds automatically results in the impossibility to provide economic security to the network given its current stage, regardless of its final scoring.

As a Symbiotic curator looking to perform risk management for restakers, we use the eligibility threshold of the final score to classify networks into 3 groups: (Tier-1, Tier-2, and Tier-3). This allows us to seek for an optimal allocation to determine the optimal risk-adjusted return amongst networks for restakers.

4. Case Study: Stubchain

Using our methodology, we evaluate a Symbiotic network developed by the Symbiotic team, called Stubchain. Stubchain extends the Cosmos SDK such that shared economic security provided by Symbiotic secures the chain.

4.1. Assumptions

We make the following assumptions for the missing parts in Stubchain’s current state.

Slashing mechanism: VetoSlasher with a 1-week veto window
Resolver: A resolver committee with a moderate level of governance
Operators: 10 operators from the Symbiotic cohort 1 with balanced shared security
Owner of Middleware: A multisig account constituted of well-known node operators

4.2. Stubchain scoring

Stubchain scores well on governance (83%), but less so on software (67%) and communication (75%). The positive governance score stems from our assumption of moderate to decentralized governance of Stubchain. The lower software score is mainly due to the ongoing development of the network, with code audits in progress but not yet completed. Communication overall is scored rather low since the network is still in testnet and currently undergoing rapid changes.

Stubchain scores moderately on resolver (75%), rather well on nodes (82%), and moderate on Middleware (71%). The resolver score stems from our assumption of a resolver committee with moderate governance. Although nodes are still being actively developed and tested, extending the battle-tested Cosmos SDK helped with getting higher scoring. Relatively speaking, middleware requires more testing and audits.

We rate Stubchain as a tier-2 network given its final score (+27) and its eligibility threshold (76%). Overall, we find the slashing risk on Stubchain to be moderate, should we factor in our assumptions stated in Section 4.1. We do not identify any design factors intended to be overly aggressive towards slashing. We anticipate the scores for nodes and middleware dedicated to Stubchain to improve as the network’s implementation solidifies, audits finalized, and nodes running in production. For mainnet, we expect more structured and planned communication, which should also increase the scores for communication.

4.5. Evaluation notes

Our main concern is in the governance and implementation of the admin account that has privileges in the Middleware. In the extreme case where the admin account is an EOA owned by a sole owner, unjustified slashing events can occur anytime to the dedicated vault. When evaluating Networks built with Stubchain, we will closely examine and monitor how the admin account is designed, implemented, and governed.

Stubchain mentions the potential slashing triggered by inactivity of nodes. This is also a concern, but to a lesser extent. This risk can be mitigated by working with operators that have a proven record of reliability. Additionally, we may require the use of replicated remote signing technologies for Cosmos SDK such as Horcrux [5], which enables a validator to remain active despite failures of some of the replicas.

5. Discussion

We discuss several directions in which our methodology can evolve, gathering feedback from Networks projects, protocols, operators, restakers, and ongoing deployment on the Holesky [6] environment. We discuss a risk methodology for evaluating & selecting Networks, optimizing collateral diversification across LRTs taking into account the reliability of each participant.

5.1. Applying the methodology in production

Applying the methodology in production requires coordination between curators, operators, and Networks. First, we will apply our methodology, starting with the LRTs distributed by Mellow Finance [7] and Amphor applications [8]. Second, we plan to increase the number of collaborations with node operators with effective communication and interest in Symbiotic restaking.

Third, we will work closely with network developers from Cohort 1 to collect information required for evaluating its middleware, slashing mechanism, delegators, and shared security needs.

Ultimately, we will curate Symbiotic LRT vaults using the FullRestakeDelegator parameter to opt-in across node operators and whitelisted Networks and will ensure the maintenance of collateral allocation, following a strict diversification methodology.

Network Explorer (testnet) – Vault curation dashboard

5.2. Optimizing allocation across Networks

Although our current methodology enables us to score and rate Symbiotic Networks from the perspective of slashing risk, it falls short in optimizing the exact allocation of collaterals across multiple Networks. To address this problem, we plan to introduce a rebalancing methodology to optimize risk-adjusted returns through eligibility thresholds, coupled with an analytical approach to quantify potential yield generation from whitelisted Networks.

We will consider the network’s utilization rate from an activity/security ratio perspective, the network’s potential scalability, the Networks’ yield distribution mechanism, its reward types, the underlying yield-bearing assets used, and more. An exciting future work would be an automated rebalancing of shared security supported by a real-time monitoring system.

5.3. Software libraries for building Networks

We anticipate that a large number of Symbiotic network developers will use a software library for building Symbiotic Networks. Without a software library, developers would need to develop a new distributed system from scratch, which is significantly time-consuming, costly, and risky. Libraries such as Stubchain (Cosmos SDK), Layer Zero DVN (bridges), and Othentic [9] could be seen as robust candidates for this matter. In terms of data availability needs, HyveDA tends to develop a validation service specifically for the Symbiotic environment.

In applying our evaluation, we can take a two-level approach where we first evaluate the software library, and then evaluate specific Networks that are built on top of the software library. This would allow us to scale the evaluation over different Symbiotic Networks using the same standards and facilitate onboarding by node delegators and vault curators.

6. Conclusion

We have presented our methodology to evaluate slashing risks of Symbiotic Networks. Our approach is opinionated and wants to be practical for the Symbiotic ecosystem. We attempt to analyze risk vectors on networks from the software, communication, and governance perspective among the different entities responsible for a Network’s viability. We are making our research public in the hope of contributing to a decentralized, transparent and secured restaking environment on Symbiotic.

7. Acknowledgments

We thank MEV Capital and NodeInfra teams for their time on this article. Felix L. [10] from Symbiotic and Nick S. [11] from Mellow for reviewing drafts and providing insightful feedback. We also thank network projects, such as HyveDA, Primev, Stubchain, Ojo, Marlin, and others, for their valuable information on Validation services.

8. About MEV Capital and Nodeinfra

MEV Capital [12] is an EU-based investment management firm exclusively focused on DeFi, assessing risks on assets and applications deployed across EVM chains since 2021. MEV Capital is part of the first Symbiotic curator cohort, and has been one of the main economic security providers for validation services.

Nodeinfra [13] is a Korea-based node operator and part of the first Symbiotic operator cohort. The founder of Nodeinfra discovered two consensus bugs in Geth. One of these bugs led to the Ethereum hard fork on November 11, 2020. At the time, it was considered Ethereum’s most significant challenge since the DAO fork in 2016.