Karak DSS connected registered operators to slashable vault collateral in the 2024 protocol

Stakers, operators and DSS contracts

Stakers supplied assets, operators performed service tasks and DSS contracts defined the obligations that those operators accepted. Deposits entered an operator's vault, which represented the depositor's claim through shares. Each accepted asset had a dedicated vault in the documented design. Once an operator committed a vault to a DSS, that vault's collateral could back the service's economic security under its slashing rules, while depositors continued to hold their claims through the vault's share accounting and shared the consequences of an asset penalty.

Core coordinated those memberships and vault commitments. A DSS handled its own task requirements and rewards. Vault implementations supplied asset accounting, with standard token vaults using ERC-4626-style shares and NativeVault following its native-restaking path. A slashing handler determined how the protocol processed penalized assets.

Service registration fixed the slashing ceiling

A DSS registered its contract with Core before operators could join it through the protocol. Core required the service-registration caller to be a smart contract. The service declared its maximum slashable percentage during registration. The 2024 design stored that value once, so an existing registration couldn't overwrite it by registering again. This ceiling constrained the percentages that Core accepted in that service's slashing requests.

The percentage used fixed-point WAD encoding, a scaled integer representation of the slashing percentage. Core exposed the stored bound through getDssMaxSlashablePercentageWad . The service's permitted maximum and its requested penalty remained different values: a request had to stay within the declared maximum. Repeated requests also faced a cooldown for the same DSS and operator.

Did registering an operator also stake a vault?

Operator registration established service membership; it didn't add a vault to that service's staked set.

Core's registerOperatorToDSS accepted the target DSS and service-specific registration data. The caller's address supplied the operator identity. The DSS had to be registered already, the registration function had to be unpaused and any registration hook that Core invoked had to succeed. These conditions governed admission before a separate vault allocation could follow.

Successful registration emitted RegisteredOperatorToDSS . The membership query isOperatorRegisteredToDSS exposed the recorded relationship. Neither the event nor that Boolean response specified an allocated asset amount. The event recorded successful registration; a true query result confirmed that Core recorded the membership when queried.

Before requesting any vault allocation, a newly registered operator had no new stake to unwind in Core. If it had no existing vaults staked to that DSS, it could end that membership. This stopping point concerned Core's collateral records; the service's own rules governed any separate service duties.

A depositor's share balance wasn't evidence that every service associated with the operator already had a vault commitment.

Registration hooks controlled service admission

Registration hooks let a DSS apply its admission logic within the protocol's operator-registration call. Core passed the operator address and registration data to registrationHook when Core's interface check succeeded and the service reported support for that hook. A failing registration hook reverted the whole call, including the membership change. Hooks were optional, so a service without that implemented interface followed the remaining Core checks. The service contract determined any required registration data.

Vault allocation used a delayed update

Vault staking changed the collateral commitment through a queued update after the operator had joined the DSS. The request identified the vault, the service and whether the operator intended to stake or unstake. Only the operator could initiate its vault's update. Core checked membership, and the operator's vault records had to contain the selected vault.

Requesting an update created pending metadata, including its starting timestamp and intended direction. Finalization applied that direction only after the required delay and a match against the stored request. A queued request therefore didn't establish that allocation had finished. The same delayed mechanism covered adding a vault to a DSS and removing it from one.

Open full-size image

A supported request-stage staking hook could reject allocation. An unstaking request used different failure handling for that hook, allowing the exit request to survive a service callback failure. That rule concerned the hook's execution; the request still had to satisfy Core's other checks. Service admission and vault admission could therefore apply different conditions to the same operator.

Timing parameters in the 2024 V2 design

The 2024 V2 timing constants separated vault updates from slashing review and repeated penalty requests. The 2024 V2 implementation set MIN_STAKE_UPDATE_DELAY to 9 days. These values belonged to that contract design and weren't a current availability promise.

The veto window and the cooldown had equal lengths, but they governed different actions.

Rewards followed service participation

DSS task rewards belonged to the service's own payment system in the 2024 design. Core and the vaults didn't distribute those rewards. A DSS could calculate rewards off-chain and pay them through a Merkle drop. The reward policy called for calculations to stop counting a vault's stake when its operator initiated unallocation, even though the delayed update hadn't finished. The same exclusion applied to assets that a staker queued for withdrawal; Core didn't perform that rewards accounting.

Slashing requests and veto rights

Slashing connected a DSS's penalty request to vault collateral that the operator had committed to that service. Core required the operator-service registration and the targeted vault allocation. The requested percentage had to remain within the service's registered ceiling. Core enforced these structural conditions; it didn't determine whether an operator had performed its off-chain tasks correctly. The DSS's own rules supplied that task-level judgment.

An accepted slashing request identified the operator and targeted vaults, then earmarked an amount for each vault from its requested percentage and its totalAssets at that point, while the veto delay kept penalty execution pending. A vault could cap execution at its remaining assets, so the request wasn't proof of a completed transfer.

The veto committee could cancel a queued request while it remained pending. Cancellation removed that request from Core's executable queue. When slashing proceeded, the standard token vault called its handler to process the penalty. NativeVault first reduced its accounted assets; a later snapshot could move available slashed ETH to its slash store. Handler designs could burn assets, swap them before burning or distribute them to affected parties. The vault and handler implementations determined the asset's treatment.

Shared vault backing and service-specific jailing

Multiple DSSs could rely on the same vault backing in the 2024 design. An operator could commit a vault's full collateral to more than one service, creating overlapping obligations over shared assets. Those commitments didn't create additional collateral balances. A DSS could reject or jail an operator whose combined commitments exceeded that service's tolerance.

Jailing was a service-level participation sanction that could affect tasks or rewards. Core didn't impose a universal jailing policy. A DSS could implement restrictions such as withholding rewards or requiring unallocation. The service's chosen rules determined the consequence, and jailing remained optional. Removing task access therefore didn't itself describe how the protocol would slash or release vault assets.

Service exit differed from a staker withdrawal

Leaving a DSS required the operator to end every vault allocation to that service before removing its membership. An unstaking request entered the delay process. Unregistration remained blocked while Core still listed a vault as staked to that DSS. The AllVaultsNotUnstakedFromDSS error referred to that outstanding allocation, even if another interface displayed a withdrawal request.

Operator unallocation changed a service commitment. A staker withdrawal changed a depositor's claim on vault assets. Their timing served related slashing protections, yet completing one didn't perform the other. Once an allocation had finalized, ending membership required the separate unallocation process. Removing the operator's membership didn't withdraw depositor assets.