Skip to main content

Accounting

Symbiotic allows for a majority of mechanics to be flexible, however, it provides strict guarantees regarding vault slashing to the networks and stakers as defined in this diagram:

Deposit, withdraw, slash, resolve lifecycle

vault-lifecycle

A network can use flexible mechanics to keep its operator set state up-to-date, e.g., it’s convenient to use a conveyor approach for updating the stakes while keeping slashing guarantees for every particular version of the operator set:

  1. At the beginning of every epoch the network can capture the state from vaults and their stake amount (this doesn’t require any on-chain interactions).
  2. After this, the network will have slashing guarantees for one vault epoch duration, so it can use this state at most for one vault epoch.
  3. When the epoch finishes and a slashing incident has taken place, the network will have time equal to the vault epoch duration minus the network epoch to request-veto-execute slash and go back to step 1 in parallel.

Conveyor approach

vault-conveyor

Epochs​

Epochs are a fundamental Symbiotic mechanism that balances the needs of both stake providers and users. Since network security depends on the operator's stake size, and users can potentially withdraw funds at any time, the network must ensure the operator's stake remains stable over defined periods. The epoch mechanism achieves this by implementing time-delayed vault withdrawals, keeping the operator's slashable stake constant regardless of user withdrawal requests.

Rather than using a standard delay mechanism, which would complicate internal accounting, vaults operate on an epoch-based system. This system processes deposits instantly while batching withdrawals to execute at the end of each epoch. Users have the flexibility to submit withdrawal requests at any time, but these requests are queued and processed collectively at epoch boundaries.

Importantly, funds remain subject to slashing for a set period after withdrawal requests are submitted. This mechanism allows the network to maintain and utilize the operator's slashable balance during this window, ensuring continued network security throughout the withdrawal process.

The size of the epoch is not specified. However, all the epochs are consecutive and have an equal constant, defined at the moment of deployment size. Next in the text, we refer to it as EPOCH\text{EPOCH}.

Definitions​

  • active\text{active} balance - a pure balance of the vault/user that is not in the withdrawal process
  • epoch\text{epoch} - a current epoch
  • Wepoch\text{W}_\text{epoch} - withdrawals that will be claimable in the epoch + 1\text{epoch + 1}

Constraints​

  • totalSupply=active+Wepoch+Wepoch + 1\text{totalSupply} = \text{active} + \text{W}_\text{epoch} + \text{W}_\text{epoch + 1} - a total amount of the collateral that can be slashed at the moment

  • During withdrawal:

    1. active→active−amount\text{active} \rightarrow \text{active} - \text{amount}
    2. Wepoch + 1→Wepoch + 1+amount\text{W}_\text{epoch + 1} \rightarrow \text{W}_\text{epoch + 1} + \text{amount}

  • During deposit:

    1. active→active+amount\text{active} \rightarrow \text{active} + \text{amount}

  • During slashing:

    1. q=1−amounttotalSupply\text{q} = \text{1} - \frac{\text{amount}}{\text{totalSupply}}
    2. active→active⋅q\text{active} \rightarrow \text{active} \cdot \text{q}
    3. Wepoch→Wepoch⋅q\text{W}_\text{epoch} \rightarrow \text{W}_\text{epoch} \cdot \text{q}
    4. Wepoch + 1→Wepoch + 1⋅q\text{W}_\text{epoch + 1} \rightarrow \text{W}_\text{epoch + 1} \cdot \text{q}

  • ∀k>0,Wepoch - k\forall \text{k} > \text{0}, \text{W}_\text{epoch - k} - claimable

  • ∀k≥0,Wepoch + k\forall \text{k} \ge \text{0}, \text{W}_\text{epoch + k} - slashable and not claimable

Deposits​

Any holder of the collateral token can deposit it into the vault using the deposit() method of the vault. In turn, the user receives shares. Any deposit instantly increases the active\text{active} balance of the vault.

Withdrawals​

Any depositor can withdraw his funds using the withdraw() method of the vault. The withdrawal process consists of two parts: a request and a claim.

Consider the user requests the withdrawal at epoch\text{epoch}. The user can claim the withdrawal when the epoch + 1\text{epoch + 1} ends. Hence, a withdrawal delay varies from EPOCH + 1\text{EPOCH + 1} to 2⋅EPOCH\text{2} \cdot \text{EPOCH}. Such funds are immediately reduced from the active\text{active} balance of the vault, however, the funds still can be slashed. Important to note that when the epoch + 1\text{epoch + 1} ends the funds can’t be slashed anymore and can be claimed.