gmbiotic
intorduction to a new paradigm of permissionless restaking
gmbiotic, wait what? what is this new gm slang?
Today, in Naruto’s scroll of wisdom, we are gonna deep dive into a new protocol in the restaking war competing against big giants already out there: enter Symbiotic. For those who do not know, a restaking mechanism is basically something that allows Eth validators use and re-use their staked ETH by having them commit to secure protocols other than Ethereum Network itself. A lot of research has already went into working on this model, and the newest player in the market is Symbiotic..
But Naruto, what is it, and how is it different from the others? Good question! The biggest advantage is their generalized shared security model which allows different networks to have their own (re)staking implementation permissionlessly. Here is a high level design. If you study this, you will realize that “Restakers” provide collateral to “Operators” which allows the operators to use the collateral to secure their position within the network and run the infrastructure while maintaining the network’s security. The rewards in this model flow from the Network to Operators and then from Operators to Restakers. There is also a “Rewards & Penalties” box which is basically from Network to Operators and Restakers Depending on what the penalties/Rewards are.
The three major features of this design choices are basically:
Modularity: Networks have the ability to implement any mechanism of restaking such as collateral assets, node operator selection mechanics, slashing, rewards etc.
Immutability: Symbiotic has chosen to have non-upgradeable core contracts on Eth network to remove the risks of single point of failure and minimizes the risks.
Capital efficiency: In the roadmap, symbiotic has operator-centric cross-network reputation system that will enhance the capital efficiency for builders.
Diving into the components: in the Symbiotic model, Collateral is provided for economic security while Networks are the services layer. Collateral is mainly ERC-20 tokens. Networks in Symbiotic are basically appchains, rollups and other protocols that require node operators for trust-minimized services. Operators play a major role as infrastructure layer. These are responsible for running the infra and are able to opt-in to networks and receive economic backing from restakers through Vaults.
Wait, Vaults? Yes, Vaults is the (re)staking layer and the key component in the design which is responsible in handling delegation and restaking management and can be customized as well. Finally, there are Resolvers that are responsible to pass or veto slashing penalties on operators. These Resolvers can be committees or different dispute resolution frameworks as well.
Let’s deep dive into each of the components that we talked about:
Collateral: This is what the heart and core of Symbiotic in providing the economic security. As briefly mentioned above, these collaterals are basically ERC-20 tokens and have extended functionalities, for e.g., slashing. These collateral tokens can be deposited into vaults which then can be delegated to operators across the Symbiotic network. Now let’s look into what are Vaults and, how they work.
Vaults: They are responsible for anything related to delegation and management. Majorly focusing on deposits, withdrawals and slashing of Collateral as defined above. But they also are responsible for strategies and reward distribution. Great thing about Vaults is that you can configure them in anyway possible, and they are immutable. An owner can also update vault parameters if needed. In the architecture below, users mint asset-specific collateral and deposit into the Vault. Now, this vault manages these assets and allows users to opt-in to specific delegation strategies while also defining terms for restaking. The delegated collaterals go to different operators that are opted into the network. The users accept the terms to participate in the network via these operators, and the rewards to the vaults can be in different tokens. Quite simple, right? There are also some Accounting and slashing logic that we will go in the next blog, but if you want to read more about them before, you can refer to this link here.
Networks: This is a pretty term for any protocol that needs a decentralized infra to deliever services. Decentralized infrastructure networks can adopt Symbiotic to flexibly acquire security through operators and financial support. In scenarios where protocols have multiple sub-networks with distinct infrastructure functions, the modular structure of the Symbiotic protocol allows developers to establish specific participation rules that must be followed for each sub-network. These Networks can be either EOAs or contract addresses and a middleware contract which has custom logic in order to support slashing logic.
The architecture below shows the interaction between users, a decentralized network, and the Symbiotic protocol that governs it. Users interact with the network by accessing services and making payments. The network itself is managed through the Network Config module within the Symbiotic protocol, which handles deployment, control, and the enforcement of rules like whitelisting, rewards, and slashing. Operators within the Symbiotic system provide collateral backing and earn a share of rewards, ensuring the network's security and functionality. Additionally as mentioned before a few times, restakers offer further economic support by agreeing to specific engagement terms, thereby enhancing the network's security and earning incentives. The entire system works cohesively to maintain a secure, decentralized infrastructure that supports the network and its users.
Operators: Operators are entities that manage infrastructure for decentralized networks, both within and outside the Symbiotic ecosystem. The Symbiotic protocol registers these operators, tracks their interactions, and allows participants to attach credentials and other data to them. Initially, this includes operator-provided metadata and data from their interactions with the protocol, such as networks joined, associated vaults, and historical logs. A key benefit of the Symbiotic protocol is that it enables operators to receive stakes from diverse partners through vaults, all directed to the same node infrastructure, eliminating the need for separate setups for each partner.
Resolvers: Symbiotic uses Resolvers—contracts or entities that can veto slashing incidents across networks—to handle slashing incidents. Networks propose terms for resolvers, which are accepted by vaults providing collateral for operators. Vaults can split their collateral among different resolvers (or none), allowing for flexible coverage (e.g., 7% without a resolver, 43% with Resolver A, 50% with Resolver B). Decentralized dispute resolution frameworks like UMA can also serve as resolvers. In some cases, a quorum of resolvers is required to approve or veto slashing incidents, adding an extra layer of security within the Symbiotic protocol. There is also a Veto process that resolvers can utilize to veto a specific slashing request in the slasher module of the vault. We will cover this in next blog because this is the technical content of Vaults component, but you can find it here.
So far we have talked about five major components of Symbiotic: Collateral, Vaults, Networks, Operators and Resolvers. There are multiple things that Symbiotic has implemented, and now let’s finally see on how the contracts architecture work.
Contracts Architecture
This architecture looks over all the things that we have talked so far about Symbiotic. The registration process for both operators and networks is fundamental to the system. Operators register through the `OperatorRegistry`, while networks do so via the `NetworkRegistry`. Both entities can manage their associated metadata—such as URLs or other relevant information—using the `OperatorMetadataService` and `NetworkMetadataService` respectively. This ensures that all participating entities are properly registered and have the necessary information attached to their profiles.
Once registered, operators can opt into specific networks and vaults using the `NetworkOptInService` and `VaultOptInService`. These services ensure that operators meet the criteria for participation in various networks or vaults, which are crucial for their operational roles within the decentralized infrastructure.
Vaults play a critical role in the system, managing the collateral deposited by operators and stakers. As I mentioned above, the Vaults component can have Operator-specific or Curated Multi-Operator Vaults, which are basically crypto institutions or LRT protocols. The `VaultFactory` handles the creation and deployment of these vaults, while the `Burner` is involved in the process of burning collateral, which could be a mechanism for penalizing bad behavior or managing token supply. The vaults are directly tied to the `Delegator`, which manages the distribution of tasks or responsibilities, ensuring that the network operates smoothly.
The architecture also incorporates a slashing mechanism to maintain network integrity. The `SlasherFactory` and `Slasher` components handle requests for slashing—penalizing operators or networks that act maliciously or violate the terms of engagement. This interaction is closely linked with the vaults and the delegator, ensuring that penalties are enforced efficiently.
Middleware services are also an integral part of this system. The `NetworkMiddlewareService` configures and manages various middleware components that support the network’s operations. These components provide additional layers of functionality, ensuring that the network can adapt and respond to different operational needs.
`Stakers` are the participants or you guys who provide collateral and play a role in the network by opting into vaults or networks. They interact with several components, including the Vault, Slasher, and `StakerFactory`, which manages the creation of stakers. The `StakerRewards` service then handles the distribution of rewards to these participants, ensuring they are compensated for their involvement and risk.
Finally, reward distribution is a key aspect of the architecture because you degens care about rewards. The `OperatorRewards` service manages the claiming and distribution of rewards to operators, while `StakerRewards` handles rewards for stakers. This ensures that all participants are incentivized to contribute positively to the network.
In essence, this architecture completes the whole Symbiotic protocol which is more decentralized, multi-asset, modular and permissionless design. Oh and as I have mentioned before, the core contracts are non-upgradable, so much better security and less points of failure. Let the Restaking Wars “really” begin.