Skip to content
Blog

Karak Core

This is the Core that the Karak protocol functions on. It binds the three main entities in the protocol, namely – Vaults, DSSs and Operators to enable restaking. Core implements the following main functionalities:

  1. Manage allowed assets
  2. Manage and deploy Vaults
  3. Allow operators to register to DSSs
  4. Manage vaults staked to a DSS
  5. Register DSSs
  6. Handle slashing requests from a DSS

Let's go over each of these in brief.

Manage Allowed Assets

Core holds the ability to restrict what assets are flowing through the protocol. This is a very simple functionality handled through only one function – allowlistAssets. This funciton allows someone with a manager role to "allowlist" certain assets which in turn allows vaults to be created with the asset as the underlying token.

Manage and Deploy Vaults

All the vaults in the Karak protocol are deployed and managed through Core. Since vaults are attached to an operator, any one willing to serve as an operator can deploy a vault with the allowed assets. The deployVaults function in core allows anyone to deploy a new restaking vault with the given configuration for an operator. Core even allows developers to bring in their own custom vault implementation. However, that entails the vault implementation be allow listed in the protocol using the allowlistVaultImpl function. The developer can then use that implementation for the vault that they would be deploying. More details on vaults can be found here.

Operator registration with DSS

The registerOperatorToDSS allows an operator to register with a DSS. A DSS can also implement a registration hook for additional checks which can invariably block an operator from registering. Consequently, they are allowed to allocate a portion of the assets from their vaults that have been delegated to them by stakers in the protocol. This funciton is assumed to be called by the operator themselves hence the msg.sender is registered to that DSS. If an operator decides to leave a DSS they would first need to "unstake" all vaults from that DSS and then call the unregisterOperatorFromDSS function.

Operator staking and unstaking

Once an operator has registered to a DSS they can stake assets from their vaults to that DSS. The stake update is an asynchronous operation in the protocol and needs to be completed in two steps –

  1. Request stake update through the requestUpdateVaultStakeInDSS function. One thing to keep in mind is that only one stake update request is allowed per vault until its completed.
  2. Finalizing the stake update can be done via the finalizeUpdateVaultStakeInDSS function which can be called by anyone after a minimum delay of Constants.MIN_STAKE_UPDATE_DELAY of starting the request and will finish the queued request for an operator to update assets delegated to a DSS.

Unstaking can be done with the same request to update the stake which will overwrite the existing state to the new requested one.

DSS Registration

It is handled through the registerDSS function and allows the caller to register as a DSS. This function also sets the maximum slashable percent, in the form of wad, that the DSS can slash operators per cooldown period.

Handle slashing requests

A DSS can slash any malicious operators subject to a VETO from a committee to prevent unnecessary slashing of operators. There is also a slashing cooldown period represented by Constants.SLASHING_COOLDOWN. It is the minimum time that must pass before a DSS can slash an operator again. Slashing, similar to the stake update, is an asynchronous operation in Karak and has three main functions involved:

  1. requestSlashing allows a DSS to request a slashing of an operator. The request should also includes the vaults that the DSS intends to slash of that operator. This puts a slashing request in the queue which can only be finalized after a minimum delay has passed.
  2. finalizeSlashing allows anyone to finish a requested slashing waiting in the queue provided that the minimum delay of Constants.SLASHING_VETO_WINDOW has passed.
  3. cancelSlashing is only callable by the members of the VETO committee. If they find a slashing to be unjust while in the slashing veto window they can call this function to cancel a queud slash request.