Withdrawal Source Architecture
1. Active Pool Isolation
The Active Pool is completely isolated from LP withdrawals. It is only debited and credited by user swaps (FX execution) and Phase 1 internal settlement (settleRebalance). No LP withdrawal transaction may read from, write to, or transfer from the Active Pool under any condition.
This isolation is enforced at the smart contract level. The withdrawal function does not have permission to call the Active Pool vault. This is not a configurable parameter — it is a hard architectural constraint.
2. Two-Tier Withdrawal Source
LP withdrawals are sourced from Reserve Pool or Yield Pool based on the withdrawal size and the current health of the Reserve Pool:
| Source Tier | When Used | Speed |
|---|---|---|
| Reserve Pool (Tier 1) | Small withdrawals (< Whale threshold) AND Reserve Pool health is above minimum gate | Instant. Reserve Pool holds liquid stablecoins. |
| Yield Pool (Tier 2) | Large withdrawals (≥ Whale threshold) OR Reserve Pool health is below minimum gate OR Reserve Pool insufficient for requested amount | Minutes to days, depending on Yield strategy deployment type. |
Using the Yield Pool for every withdrawal would reduce yield generation unnecessarily. Small withdrawals from the Reserve Pool have minimal impact on its Phase 1 settlement capacity. The Reserve Pool already holds buffer capital specifically designed to absorb small outflows.
The Yield Pool is used for large withdrawals because the impact on Reserve Pool would be too significant, and for fallback when Reserve Pool health is low. This balances withdrawal speed (Reserve is instant; Yield may have delays) against protocol safety.
3. Reserve Pool Health Gates
Before processing a withdrawal from the Reserve Pool, the system checks the Reserve Pool's health level. These health gates are aligned with the LP withdrawal-driven deficit tiers defined in the Smart Rebalancing section. Importantly, the Reserve Pool health level used for withdrawal gating only considers the LP withdrawal-driven component of any deficit — not swap-driven deficits, which are separately handled by Phase 2 external rebalancing.
| Reserve Pool Health | Withdrawal Behaviour | Smart Rebalancing Parallel Action |
|---|---|---|
| > 80% of target | Process immediately from Reserve Pool. Queue state: NORMAL. | No deficit action. Reserve is healthy. |
| 60% – 80% of target | Process from Reserve Pool. Queue state: NORMAL but flagged for Ops monitoring. | Mild Deficit: Ops alert. New Yield Pool deployments paused for this stablecoin. |
| 30% – 60% of target | Slow queue ($10K/hour cap). Large withdrawals redirected to Yield Pool. | Significant Deficit: Yield Pool recall initiated (liquid strategies first). Deficit cooldown timer starts. |
| < 30% of target | ALL withdrawals from Reserve paused. Redirected to Yield Pool recall path. | Critical Deficit: Aggressive Yield Pool recall. Ops escalation if Yield Pool insufficient. |
The key insight is that Smart Rebalancing actively replenishes the Reserve Pool via Yield Pool recall when LP withdrawals drain it below target. This means withdrawal queue pauses are typically temporary — the system is simultaneously working to restore Reserve Pool health while the queue is slowed or paused.
If the Reserve Pool is below target because Phase 1 settlement has been pulling stablecoins to the Active Pool (swap-driven deficit), this does NOT trigger LP withdrawal queue slowdowns or pauses. Swap-driven deficits are inventory imbalances handled by Phase 2 external rebalancing (buying back the short stablecoin from Binance/Wintermute/OTC).
Only LP withdrawal-driven capital drain triggers the Yield Pool recall and queue gating described in this section. The system tracks the cause of each Reserve Pool balance change to distinguish between the two scenarios.
4. Yield Pool Recall Mechanics
When a withdrawal is sourced from the Yield Pool, the system must recall capital from the yield-generating strategy where it is deployed. The recall speed depends on the strategy type:
| Strategy Type | Examples | Recall Speed | Withdrawal Handling |
|---|---|---|---|
| Liquid | Lending protocols, liquid staking | Minutes to 1 hour | Recall and process withdrawal in same cycle |
| Semi-Liquid | Fixed-term lending, vault strategies | 1 – 24 hours | Queue withdrawal; process when recall completes; LP notified of estimated time |
| Illiquid | Locked staking, long-term vaults | 1 – 7 days | Queue withdrawal with estimated completion date; LP notified; escalate if > 48h |
5. Insufficient Source Handling
In the edge case where both Reserve Pool (below 30%) and Yield Pool (fully deployed or recall pending) cannot cover the withdrawal:
- Withdrawal stays queued with status PENDING_RECALL.
- LP continues earning fees and yield on their kTokens while waiting (kToken burn does not occur until withdrawal executes).
- System triggers an External Liquidity Sourcing alert to Ops.
- If the situation persists beyond 48 hours, escalate to Risk Committee for manual resolution (emergency minting, external LP onboarding, or OTC coordination with the withdrawing LP).