MilkyWay terms

Explanations of terms that are focused around MilkyWay

Modular Restaking Portal

Given that the term modular is thrown around in this space vaguely without being properly defined a definition is required. Modular in this context means that the restaking layer’s components are made up of literal modules that AVSs on the restaking layer has the freedom to choose what to use. The restaking layer has extensibility by also providing the option for AVS developers to build their own custom modules that cater to their own needs, though presets provided by MilkyWay will most likely be sufficient.

In the case of MilkyWay’s modularity, we have the concept of programmable rules on the restaking layer, that enables AVSs to have their own delegation rules and slashing rules. This allows AVSs to customize how the stake is delegated, potentially going off the operator-centric model that is prevalent in the restaking scene at the moment. Due to the restaking layer having the option to have granular control over the delegation amounts amongst operators, this opens the grounds for alternative ways to approach slashing. Henceforth MilkyWay has multiple slashing rules that AVSs have the freedom to choose, or combine.

Having these verbose options with viable presets is what makes MilkyWay a truly modular restaking layer, not just to slap modular in front without much actual meaning but nested deeply in a technical way.

Programmable Rules

At the time of writing, MilkyWay will have 2 types of rules available to be customized by AVSs - delegation rules and slashing rules. There is no reason to limit the restaking layer to these 2 types of rules, and given how the requirements of AVSs may expand, the types of rules can also be extended in the future. Given the modular nature of MilkyWay, this is and should be extensible.

Delegation Rules

Delegation rules can be defined into 2 categories depending on whether it focuses on the asset or the allocation - asset allocation rules and operator stake rules.

1) Asset Allocation Rules

For assets there are asset allocation rules. These rules define which assets the AVS will consider to be supplied to the AVS. A major pain-point for AVSs have been the difficulty for them to switch back to their own token for crypto-economic security. MilkyWay provides the option to switch proportions or which tokens themselves that they allow to be restaked on their AVS in a production environment. AVSs may choose to be secured by a carefully curated proportions of assets XYZ, or simply choose only blue-chip assets they wish to be secured by. These are switchable and editable based on the AVS's discretion.

2) Operator Stake Rules

For the allocation side there are operator stake rules. Currently, there are largely 2 different modules applicable to the operator stake rules, operator-based and AVS-based. This is also something that can be completely customised and custom modes of staking is applicable at the AVS’s discretion. Currently there are two, AVS-centric and operator-centric stake rules.

Operator-centric stake rules are fundamentally the same as the eigenlayer model where user assets are staked directly to operators. Operators then choose which AVSs they wish to validate and their stake received from users would be pooled to supply security to multiple different AVSs.

For AVS-centric stake rules, assets eligible via the asset allocation rules are distributed based on the AVS’s discretion, which can be set manually and or have custom logic applied. This provides the AVS a full reign of control over how the assets are staked and distribued amongst operators, while in the restaker’s perspective they can simply provide security and not worry about which operator they should stake to.

At the time of writing, due to the nature of AVS-centric stake rules, the assets used for an AVS running on operator-centric stake rules cannot be used for security when securing an AVS running on AVS-centric stake rules and vice versa. However for AVSs using the same stake rules, assets can be pooled together and participate in shared security. A hybrid approach where both methods of stake rules co-exist in the future may be possible. The main blocker is that in an operator-centric model commission rates are typically different according to operators. However there could be ways to make this possible and is a topic to be researched.

Slashing Rules

Slashing rules are rules defining how slashing will occur on the AVS. Since the stake of each operator and AVS is defined directly on the restaking layer via the delegation rules, slashing is now applicable in multiple dimensions. At the time of writing MilkyWay has largely 3 slashing modules, however more can and will be added based on the AVS developer’s demands.

1) Stake Slash

This module implements slashing by partially redelegating the stake of an operator to other operators when a slashable offence has occurred. This will be translated into reduced rewards for an operator going forward since the operator has less assets staked on them going forward.

2) Jail Slash

This module is responsible for jailing operators when they misbehave. Restaked assets are not affected but the operator will stop participating in the active set for a period of time and therefore they will not generate rewards.

3) Burn Slash

This module burns a percentage of staked tokens, a common and traditional slashing mechanism often encountered within PoS networks and is also the sole slashing mechanism on Eigenlayer.

Having a form of slashing is necessary for economic security, however having multiple is also an option. For instance an AVS may choose to jail an operator for a period of time for trivial offences, stake slash for meaningful offences and burn slash for the ultimate offence. Custom slashing mechanisms should also be possible and updatable in real time.

The term slashing has been used since it’s been the industry standard in the restaking space. However these rules can technically be used as an incentive mechanism instead. For instance for the top high-performing operator a stake slash could be applied to everyone else apart from the top operator to increase the operator’s stake and reduce everyone else’s. In this context stake rules could be a more suitable term to encompass the full use-cases of the expanded slashing rules.