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.
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.
The account owner or approved actor records the collateral change request.
The market-specific delay blocks immediate execution.
Any caller can process once the window opens, subject to checks.
The vault updates delegated collateral and emits the processing event.
Timing model
delegateCollateralDelay or undelegateCollateralDelay determines the earliest processing time.
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.
DelegateCollateralIntentDeclared.DelegateCollateralIntentProcessed is emitted.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.
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.
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.