Liquid Delegation Vaults (LRT “Bolts”)

Liquid delegation vaults (“bolts”) wrap a restaking delegation position into an ERC-20 share token. Users can hold and transfer shares while the underlying stake remains delegated to an operator.

What a Bolt Represents

Each vault delegates to exactly one tuple:

• operator
• asset (native or ERC-20)
• blueprint selection:
  • All (shares are exposed to every blueprint the operator runs)
  • Fixed (shares are exposed only to a specific set of blueprint IDs)

This tuple matters for both rewards and slashing.

Deposit Flow (Synchronous)

When a user deposits:

1. The vault takes custody of the asset.
2. The vault deposits into MultiAssetDelegation.
3. The vault delegates to the configured operator with the configured blueprint selection.
4. The vault mints ERC-20 shares to the receiver.

Redemption Flow (Asynchronous, ERC-7540)

Withdrawals are asynchronous to respect the restaking system’s exit delays:

1. requestRedeem(shares, controller, owner) burns shares and schedules an underlying unstake.
2. Wait until the exit delay is satisfied (round-based).
3. redeem(shares, receiver, controller) executes the underlying unstake and transfers assets out.

Rewards and Accounting

At the protocol layer, the vault is the delegator. Any rewards/fees that accrue to the delegator accrue to the vault address.

How those rewards are reflected to share holders is an implementation choice:

• Some vaults model rewards as an increasing share price (assets-per-share rises).
• Others keep share price stable and pay rewards via a separate claim path.

If you are integrating a vault, treat “what totalAssets() includes” as a critical detail.

Risks

• Exit delays: redemptions are not instant.
• Slashing: operator misbehavior can reduce the value of the underlying delegation position.
• Blueprint selection risk: All mode increases potential surface area; Fixed mode scopes exposure.

See Restaker Risks and Slashing.

Developer Docs

• Vault Developer Docs