Skip to content

Registries and Opt-ins

Registries

Registries give Networks and Operators a canonical on-chain identity that the rest of Symbiotic can reference.

NetworkRegistry

Stores all Networks that can receive stake, be captured, and issue slashes or rewards. A Network registers once (for example via registerNetwork()), then:

  • can be discovered by vaults, operators, and tooling
  • can be linked to its middleware, which is the only address allowed to send slashing and rewards requests on its behalf

Only registered Networks can set per-vault limits and interact with Slasher and Delegator modules.

OperatorRegistry

Stores all Operators (EOAs or contracts) that can receive stake and be slashed. After registering (for example via registerOperator()), that operator ID is used everywhere:

  • opt-in services track operator–vault and operator–network opt-ins
  • vault Delegators use it when returning effective stake
  • slashers reference it when enforcing penalties

Unregistered operators cannot be allocated stake.

(Other registries such as token or collateral registries are used similarly: they define which assets are valid and how they are handled, but they do not change the opt-in rules.)

Opt-ins

Opt-ins establish consent and scope. They define which combinations of vault, operator, and network are actually allowed to interact, so that:

  • a Network can only penalize stake that was explicitly made available to it
  • a vault can only allocate to operators that agreed to serve it
  • an operator can only be evaluated for Networks it chose to join

This keeps slashing and rewards precise and prevents accidental penalties.

Opt-in surfaces

Opt-ins live at the contact points between roles:

  • Operator → Vault via OperatorVaultOptInService

    The operator opts into a specific vault (and can later opt out). Without this, the vault cannot allocate stake to that operator.

  • Operator → Network via OperatorNetworkOptInService

    The operator opts into a Network (and its subnetworks) it is willing to serve.

  • Network → Vault via the vault’s Delegator

    The Network expresses willingness to accept stake from a vault by setting a per-vault maximum, e.g. setMaxNetworkLimit(subnetwork, maxStake).

  • Vault → Network and Operator via Delegator configuration

    The curator allocates stake by setting non-zero limits or shares for a Network and for each operator inside that Network (for example setNetworkLimit(), setOperatorNetworkLimit(), or setOperatorNetworkShares() depending on Delegator type).

Eligibility rule

An operator is actually eligible for stake in a given Network through a given vault only if, at the relevant timestamp:

  • the operator is opted into that vault
  • the operator is opted into that Network
  • the Network has set a non-zero max limit for that vault
  • the vault’s Delegator has a non-zero limit or share for that operator in that Network

If any of these are missing, the Delegator returns zero stake and the Slasher will reject penalties for that pair.

Timing and capture

Opt-ins are time-aware. All checks are evaluated at the capture timestamp the Network includes in its request:

  • when a Network captures stake at time T, it receives a guarantee that the reported amounts remain slashable for one vault epoch after T
  • when a slashing request is executed, the Slasher verifies that the capture timestamp is no older than one vault epoch and that all required opt-ins and limits were in place at that time

Opt-outs and limit changes are forward-looking:

  • if an operator opts out today, a Network can still slash for misbehavior tied to a capture from yesterday, as long as the capture is still inside the epoch window
  • new captures taken after the opt-out will see zero stake and cannot be used for future penalties

Lifecycle and revocation

Each participant can change its opt-ins at any time:

  • operators can opt in / opt out of vaults and Networks (or invalidate signatures)
  • Networks can raise or lower per-vault max limits
  • curators can adjust per-network and per-operator limits and shares

These changes affect future captures and allocations. Previously captured guarantees remain valid until they age out of the epoch window. This prevents last-minute exits from making valid penalties impossible to execute.

Vault access vs opt-ins

Deposit access and opt-ins are separate:

  • vault-level settings such as depositWhitelist, depositLimit, and their admin roles control who can deposit and how much collateral can be active
  • opt-ins and Delegator limits control who can be allocated stake and who can be captured, rewarded, or slashed

A private, allowlisted vault still requires proper opt-ins and Delegator configuration before any operator can receive stake. A public vault can accept deposits from anyone but will not actually expose those deposits to a Network or operator unless all relevant opt-ins and limits are in place.