Programmable Rules

What are Programmable Rules?

Programmable rules are the bread and butter of what makes the MilkyWay restaking layer stand out from traditional restaking and stay laser-focused on the pain points of every actor participating in restaking. This is possible due to MilkyWay envisioning that modularism in the tech stack will be relevant going forward and maintain a vital footing in the crypto space.

Instead of building a restaking layer that is inflexible and force vendor lock-in by limitations of features, MilkyWay envisions vendor lock-in by convenience and replaceable, updatable modules in the restaking layer. At launch we envision two types of programmable rules, which are delegation rules and slashing rules. However we plan on expanding this continuously as we see the needs from the community.

One additional rule we see coming up in the near future would be Asset rules, where the source of restaked assets could be from MilkyWay or from other existing restaking providers such as EigenLayer or Babylon. A combination should also be an option; pooled-pooled security.

Types of Programmable Rules

MilkyWay has 2 types of rules available to be customized by AVSs. They are 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 restaking protocol, 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.