Asynchronous Delegation

An intent-based vault delegation model

Asynchronous Delegation replaces immediate collateral delegation changes with a delayed intent flow for Synthetix vaults. An LP first declares a delegation or undelegation intent for a pool and collateral type. The market's configured delay determines when that intent becomes processable, and the configured window determines how long execution remains valid. The model gives markets time-bounded visibility into incoming and outgoing liquidity while preserving permissionless processing once the intent is eligible.

Author: Jared Borders
Date: Mar 17, 2024

1. Proposal Context

SIP-366 gives markets configurable delay and processing-window parameters for collateral delegation and undelegation. Instead of applying a collateral change immediately, the vault records a pending intent and makes it eligible for execution only after the relevant delay has elapsed.

The mechanism replaces the Minimum Collateral Delegation Duration pattern introduced by SIP-320. Rather than forcing collateral to remain delegated for a fixed period after the fact, SIP-366 moves the timing constraint to the moment before delegation or undelegation takes effect.

Design objective. Markets should be able to require LPs to declare collateral changes in advance, giving the market a chance to absorb or react to liquidity changes before they take effect.

2. Liquidity Problem

The mechanism targets adversarial LP behavior around just-in-time liquidity. Without an intent layer, an LP can potentially add or remove collateral in ways that interact poorly with market settlement, debt, and risk checks. The design treats this as market-specific: different markets can have different risk surfaces, so each market configures its own timing parameters.

Delegation Risk

New collateral can arrive exactly when it benefits the LP, while leaving the market with little advance signal.

Undelegation Risk

Collateral can leave during sensitive market conditions unless withdrawal intent is staged and checked.

The intent system sits alongside the precautionary security features described in SIP-316.

3. Intent Pattern

The proposed pattern separates request from execution. LPs declare intent through declareIntentToDelegateCollateral. After the configured delay has elapsed, the intent can be processed through processIntentToDelegateCollateral during the relevant processing window.

Step 1
Declare Intent

The account owner or approved actor records the collateral change request.

Step 2
Wait Through Delay

The market-specific delay blocks immediate execution.

Step 3
Process In Window

Any caller can process once the window opens, subject to checks.

Step 4
Update Collateral

The vault updates delegated collateral and emits the processing event.

Timing model

Declared The intent exists, but cannot yet be processed.
Delay elapsed delegateCollateralDelay or undelegateCollateralDelay determines the earliest processing time.
Window closes delegateCollateralWindow or undelegateCollateralWindow determines how long processing remains valid.

4. Lifecycle

The SIP defines a nonce-backed intent lifecycle. Each account has intent nonces, each nonce maps to a specific intent, and the intent carries the requested collateral state plus declaration and processing timestamps.

Declaration
Validate account permissions and collateral type, calculate processing bounds, cache the intent, and emit DelegateCollateralIntentDeclared.
Pending
The intent remains outstanding. Available collateral and withdrawal logic must account for pending delegation intents.
Processing
Any caller can process during the valid window, either for a single pool and collateral type or for a batch of intent nonces.
Completion
The intent is deleted, delegated collateral is updated, and DelegateCollateralIntentProcessed is emitted.
Invalidation
The account owner can invalidate intents. Liquidation also cancels or expires outstanding intents.

Intent Shape

struct DelegateCollateralIntent {
    uint256 nonce;
    uint128 poolId;
    address collateralType;
    uint256 collateralAmountD18;
    uint256 leverage;
    uint256 declarationTime;
    uint256 processingStartTime;
    uint256 processingEndTime;
}

5. Interface Surface

SIP-366 touches the market manager and vault interfaces. The market manager side replaces a single minimum delegation time with four delay and window parameters. The vault side adds intent declaration and processing entry points, plus events.

MarketManagerModule Stores market-specific delay and window configuration.
IMarketManagerModule Exposes setters and getters for delegation and undelegation timing.
VaultModule Declares, processes, and invalidates collateral delegation intents.
IVaultModule Defines intent functions, overloads, and emitted events.

Timing Parameters

Parameter Applies To Purpose
delegateCollateralDelay Delegation Earliest time when a delegation intent may be processed.
delegateCollateralWindow Delegation Processing window after the delegation delay has elapsed.
undelegateCollateralDelay Undelegation Earliest time when an undelegation intent may be processed.
undelegateCollateralWindow Undelegation Processing window after the undelegation delay has elapsed.

Function Surface

declareIntentToDelegateCollateral(
    uint128 accountId,
    uint128 poolId,
    address collateralType,
    uint256 newCollateralAmountD18,
    uint256 leverage
)

processIntentToDelegateCollateral(
    uint128 accountId,
    uint128 poolId,
    address collateralType
)

processIntentToDelegateCollateral(
    uint128 accountId,
    uint256[] intentNonces
)

6. Accounting Rules

The SIP uses caches to keep outstanding intents visible to account and pool-level accounting. This matters because pending collateral changes can affect available collateral, withdrawal checks, liquidation handling, and batch processing.

Storage Area Role
intentNoncesByAccount Tracks the set of outstanding intent nonces for an account.
intentByNonce Maps each nonce to a single declared collateral intent.
Delegation cache Records pending delegation exposure by account and pool.
Undelegation cache Records pending undelegation exposure by account and pool.
The important accounting change is that a pending intent is not inert. The SIP expects withdrawal and available-collateral logic to account for outstanding delegate intents.

7. Processing Guards

Processing is intentionally permissionless, but not unconditional. The processor must verify that the intent exists, that the current time is inside the valid processing window, and that collateral health checks still permit the requested change.

Existence The nonce must map to an outstanding intent.
Timing The current timestamp must fall between the start and end processing bounds.
Collateral Ratio The processed amount must respect account health constraints.
Cache Validation Delegation and undelegation cache changes must remain consistent.

If the full requested change is no longer permissible because of c-ratio movement, debt fluctuation, liquidation, or other state changes, processing applies the maximum permissible collateral amount where applicable.

8. Operational Notes

The existing delegateCollateral entry point is preserved for compatibility by wrapping request and process behavior. Liquidation handling, intent invalidation, configuration tests, declaration tests, processing tests, expiry tests, and cache-accounting tests are part of the operational surface.