Vault

A vault is the on chain container that holds collateral and connects it to networks. Each vault holds a single collateral token, keeps track of deposits and withdrawals, and exposes policy hooks for delegation and slashing. Delegation is pure accounting: collateral remains in the vault and only leaves through user withdrawals or executed slashing.

Vaults are built from three core modules:

1. Accounting (Vault): handles deposits, withdrawal requests and claims, epoch timing, and processing of penalized collateral.
2. Delegation (Delegator): applies curator limits or shares for each network and each operator and implements the stake distribution logic.
3. Slashing (Slasher or VetoSlasher): validates slashing requests against captured guarantees and applies penalties.

Rewards are not built into vaults. Networks can leverage Symbiotic’s rewards contract template, which is designed to facilitate interactions with vaults and capture stake.

Accounting and Epochs

Lifecycle

Symbiotic makes most mechanics configurable but gives strict guarantees around the period when stake is slashable. The vault lifecycle revolves around four actions: deposit, withdraw, slash, and resolve. Collateral comes into the vault through deposits, can be requested for withdrawal, may be penalized through slashing, and is then processed according to the configured policy.

Epochs

Epochs are a core mechanism that balance user liquidity with network security. Networks rely on operators having a stable amount of slashable stake during a period, while users want to request withdrawals at any time. Vaults achieve this with an epoch based withdrawal system rather than simple time delays.

Users can submit withdrawal requests at any time. Those requests are collected and become claimable after the end of the next vault epoch. Until that boundary, the requested amount remains eligible for slashing. Epochs are consecutive and all have the same length. The epoch length is set at vault deployment. A longer epoch gives more time to observe networks and execute slashes but slows withdrawals; a shorter epoch has the opposite effect.

Requested withdrawals therefore remain slashable until the next epoch boundary. This is what allows networks to rely on the guarantees they receive from stake captures.

Deposits

Any address allowed by the vault access policy may deposit the collateral token. By depositing, a user opts into the vault configuration and curator, since the vault risk profile and returns depend on that management. Deposits increase the user balance and the vault active stake used for delegation and guarantees. Each vault is bound to a single collateral token.

Withdrawals

Depositors can request withdrawals at any time. The process has two stages. First, the user submits a withdrawal request and the amount is marked as pending but remains slashable until the end of the next epoch. Second, after that next epoch ends, the user can claim funds at any time without further slashing risk. This keeps operator stake effectively stable within an epoch while giving users predictable exit timing.

Delegation

Delegation translates vault balances and curator policy into effective stake for each network and each operator. The Delegator module lets each network set a maximum amount of stake it is willing to accept from a given vault, lets curators set per network and per operator limits or shares within those bounds, and aggregates all inputs to return the stake of a given operator on a given network at a given time.

Stake always depends on three elements:

1. the vault active stake, meaning funds that have not been fully withdrawn
2. operator opt ins to the vault and to the network
3. the limit that the network set for this vault

Some Delegator types also take per operator limits or shares into account. After a slashing event, Delegators do not automatically change limits. If automatic reactions are desired, they can be introduced through hooks.

Delegator Types

Symbiotic supports several Delegator types to cover different delegation topologies.

1. Network Restake Delegator

   Allows restaking across multiple networks while keeping operators inside the same network independent from each other. Curators set a limit for each network within the network maximum and set shares for each operator. Operator stake in a network is the vault and network stake multiplied by the operator share over the sum of shares. This is convenient for liquid restaking providers or curators whose main role is to raise and allocate funds rather than operate nodes.

2. Full Restake Delegator

   Restakes across multiple networks and multiple operators at once. Curators set a limit for each network and a limit for each operator. Operator stake is capped by the active stake, the network limit, and the operator limit. This is useful for insurance style designs where a shared pool backs many parties.

3. Operator Specific Delegator

   A simplified version of the Network Restake type with a single operator per vault. Curators set only the network limit. Stake per network is capped by the active stake and the network limit. This lets an operator run its own vault with restaking across networks while giving networks more confidence that allocations are under the operator direct control.

4. Operator Network Specific Delegator

   The most conservative type with a single network and a single operator. Stake is capped by the active stake and the network maximum limit. From the network perspective this resembles a traditional single operator staking arrangement, although there can still be many vaults per network.

Delegation Topologies

These Delegator types correspond to different combinations of how many networks and how many operators a vault can serve.

1. Multi Network and Multi Operator (MN, MO) gives maximum capital reuse and restaking with more shared risk.

2. Multi Network and Single Operator (MN, SO) gives operator specific vaults with strong operator isolation while still supporting restaking.

3. Single Network and Multi Operator (SN, MO) isolates network risk but shares operator risk and is often used by liquid staking providers or network treasuries.

4. Single Network and Single Operator (SN, SO) gives maximum isolation and minimum reuse and is often used for curator free or immutable arrangements.

Slashing and Burner

Slasher Module

The Slasher module enforces slashing penalties. It does not detect misbehavior itself; instead it processes slashing requests from network middleware.

A slashing request names the subnetwork, the operator, the amount to penalize, and a capture timestamp. The capture timestamp is the moment when the network fetched stake and received a guarantee that those amounts would remain slashable for one epoch. When executing a request, the Slasher checks that the capture timestamp is not older than one vault epoch and that the requested penalty does not exceed the remaining guarantee for that snapshot after previous slashes that used the same capture.

When a request arrives, the Slasher retrieves stake information from the Delegator and prior slashes for the same snapshot, validates that the request respects the guarantee, and if it is valid, updates internal state, notifies the Delegator where needed, and calls the vault and Burner to process the penalized collateral.

In restaking scenarios, guarantees can be affected by slashing that happened on other networks. This comes from the nature of restaking and cannot be fully avoided.

Slasher Types

There are currently two Slasher types:

1. Slasher: executes valid slashing requests as soon as they are confirmed correct. It is simple and transparent but less flexible.

2. VetoSlasher: adds a veto period. The network middleware submits a request, the contract validates it, and then a resolver, if configured, has a window of time to veto the request. If no veto occurs, the middleware can execute the slash after the window expires. This design helps networks and stakers transition from early deployments to fully trusted settings with an extra layer of review.

Burner

Once a slash is approved and executed, the Burner decides what happens to the penalized collateral. The Burner is a configurable contract that can unwrap tokens, burn them, redistribute them to users or well behaved operators, send them to a treasury or insurance pool, or forward them to custom logic. Burning is not mandatory and redistribution is a valid outcome.

Rewards

Vaults do not define reward logic. They only provide the stake that secures networks and operators. Each network decides how staker and operator rewards are funded and delivered, for example from protocol fees, revenues from external clients, or token inflation. Symbiotic reward extensions give networks standard ways to distribute these flows, but the vault itself remains focused on holding collateral and enforcing guarantees.

Vault Types and Access

Vaults are configurable templates. Different collateral tokens, epoch lengths, Delegator types, access policies, and slashing settings produce different vault types. Each vault still holds a single collateral token; multi asset exposure is achieved by using multiple vaults.

Public and Private Vaults

Public vaults accept deposits from anyone who holds the collateral token, subject to any global caps defined by the curator. Private vaults accept deposits only from allowlisted addresses. Liquid restaking providers, liquid staking providers, funds, and institutions often run private vaults and allocate across several Symbiotic vaults on behalf of their users.

Immutability Options

Vaults can be deployed in two broad ways. They can be immutable, with key parameters locked at deployment and no ongoing curator discretion, which reduces governance risk. They can also be upgradable within constrained surfaces, where certain parameters can be updated under defined rules. These choices, together with the Delegator type, slashing style, and access policy, define the risk and behavior profile of each vault in the Symbiotic ecosystem.