Skip to content

Curator

Curators set and maintain a vault’s policy. They decide how stake is spread across networks and operators, what kind of slashing flow applies, and who can deposit. Stakers choose a vault because they trust the curator’s discipline on risk, timing, and counterparty selection.

In single-operator vaults, the operator can also act as curator. In immutable vaults, key parameters are locked at deployment, removing ongoing curator control: this reduces governance risk but also removes flexibility.

Interactions and Vault Configuration

You don’t need every internal detail, but you should know the main pieces you are indirectly steering and the key functions involved.

  • Vault and VaultFactory / configurator The vault holds collateral, tracks deposits and withdrawals, and enforces epoch-based exits. New vaults are typically created through a configurator that wraps the factories, for example a helper like VaultConfigurator.create(initParams) which, under the hood, calls VaultFactory and related factories to deploy the Vault, its Delegator, and its Slasher.
  • Delegator (stake allocation) The Delegator decides how vault stake is allocated across networks and operators. As a curator you mainly use functions such as setNetworkLimit() to define how much stake this vault can send to a network, and setOperatorNetworkLimit() or setOperatorNetworkShares() to shape stake per operator, depending on the Delegator type.
  • Slasher (penalties) The Slasher applies penalties when a network requests them (via a function like slash()). As curator you choose the Slasher type (instant or vetoed) and its timing parameters, such as the veto window, when you create the vault.
  • Burner (what happens to slashed collateral) The Burner is a contract address you pass when the vault is created. It decides what happens to slashed collateral: burn, redistribute, send to a treasury or insurance pool, or route to custom logic.

You also rely on:

  • an OperatorRegistry and NetworkRegistry, which define which operators and networks exist
  • opt-in services (for example calls like OperatorVaultOptInService.optIn(vault) and OperatorNetworkOptInService.optIn(network)) so that operators can receive stake from your vault once you allocate it

Vault Strategy

Think of your work in three phases: design, deploy, and wire.

Design the policy

First, decide what the vault is supposed to do, in plain language:

  • which networks you want to support
  • how diversified or concentrated you want to be across operators
  • ceilings per network and per operator
  • whether slashing should be instant or have a short veto window
  • how you expect rewards and risk to trade off

This is the document stakers and operators will read. Everything else is just encoding this policy on chain.

Deploy the vault

Next, you create the actual vault and its modules in a single step with a configurator call, for example:

solidity (Vault vault, address delegator, address slasher) = VaultConfigurator.create(initParams);

In the initParams you choose, among other things:

  • the collateral token
  • the vault epoch duration
  • the Delegator type (multi-network, single-network, operator-specific, etc.)
  • the Slasher type (instant or vetoed) and, for vetoed flows, the veto duration
  • the Burner contract that will handle slashed collateral
  • access control, such as whether deposits are public or allowlisted

This is where you lock in the big structural choices: what the vault secures, how fast people can exit, which delegation topology it uses, and how slashing is handled.

Wire stake limits and allocations

Once the vault exists, you configure how it actually allocates stake.

In practice that means:

  • For each network you want to support, setting a vault-side limit with a call like delegator.setNetworkLimit(subnetwork, amount) which says “this vault can send up to this much stake to this network or subnetwork”.
  • After operators have opted into your vault and into those networks, setting their allocations using, depending on the Delegator type: setOperatorNetworkLimit(subnetwork, operator, amount) for hard caps, or setOperatorNetworkShares(subnetwork, operator, shares) for share-based routing.

These limit and share calls are the core knobs you use to express your strategy on chain.

Managing Stake

Once the vault is live, your job is mostly careful, occasional adjustments rather than constant tweaking.

Typical ongoing actions:

  • revisiting network limits and operator allocations if performance, risk, or demand changes
  • nudging the strategy toward more or less concentration, by changing limits or shares rather than redeploying the entire vault
  • keeping the written policy up to date with any material changes you make on chain

You generally do not need to touch the factories again. Most day-to-day stewardship happens through the Delegator functions that set limits and shares, and through off-chain communication when you add or remove networks and operators.

Risk and Timing

Even with a good strategy, the details of timing and partners matter. A few simple checks go a long way.

Collateral and reward quality

  • Make sure the collateral token you pick at vault creation has clear economic value and reasonable liquidity.
  • Prefer networks that offer rewards that match the risk taken: protocol fees, revenues from external clients, or controlled token inflation with a clear purpose.

If the collateral is low quality and networks do not pay fairly, you risk running a vault that takes real slashing risk while barely compensating stakers.

Epochs and veto windows

  • The vault epoch duration you set at creation defines how long withdrawals take and how long stake remains slashable after it is “captured” by a network.
  • If you choose a vetoed Slasher, keep the veto window well below the vault epoch. Networks need time to detect misbehavior, submit a slash, and wait out the veto period before the vault epoch ends.

A simple mental model:

network’s own epoch and proof delay

plus the veto window (if any)

plus the time it takes to submit and finalize the slash

should fit comfortably inside the vault epoch

If that does not hold, networks may not be able to slash in time, and the economic guarantees you think you are providing become weaker.

Network and operator choices

The settings you choose in setNetworkLimit, setOperatorNetworkLimit, and setOperatorNetworkShares express your risk appetite.

  • Treat the network limit as a risk budget for that network. Conservative vaults use lower limits and fewer networks; more aggressive vaults use higher limits and more networks, but should be explicit about correlated risk.
  • When you allocate to operators, avoid over-concentrating on a single one unless that is very clearly part of the thesis. Slashing events will hit stakers in proportion to those allocations.

Your operator and network choices affect not just returns, but your reputation as a curator.

Contract health and extreme cases

  • Be careful when changing access control and deposit limits to avoid locking the vault unintentionally.
  • If the vault ever experiences a full (one hundred percent) slashing event, it is often cleaner to deploy a new vault, rather than trying to reuse the same one repeatedly. The history stays clear and future stakers know exactly what they are opting into.
  • If you use fee-on-transfer collateral together with redistribution of slashed funds, be aware that the fee logic will introduce unavoidable losses during redistribution; that trade-off should be explicit in your policy.

Vault Profiles

The same contracts and functions can describe very different vault “shapes”. Two common ones:

Diversified and conservative

  • Several networks with moderate network limits
  • Many operators, each with modest per-operator limits or fairly even shares
  • A vetoed Slasher with a resolver set and a longer vault epoch
  • Focus on capital preservation and strong guarantees over maximum throughput

Throughput and concentration

  • Fewer networks with higher network limits
  • A smaller set of top-tier operators with larger limits or shares
  • An instant Slasher and a medium or shorter epoch
  • Focus on fast settlement, high utilization, and more aggressive risk taking

You can treat these as anchor points and position your own vault somewhere in between, depending on who it is for.

When active curation is minimal or not needed

Some vault designs intentionally minimize ongoing curator work.

  • Single-network, single-operator designs often use a Delegator type that effectively hard-codes the network and operator at creation time. After a basic network limit is set, there may be little left to adjust.
  • Immutable, pre-configured vaults are created once with a fixed configuration and no roles that can change core behavior later. Users opt into a static design rather than a curator’s future decisions.

In those cases, your job as the original curator is mostly to make sure the initial configuration and documentation are correct and to be transparent that the vault will not change over time.