Skip to main content

Deposit Routing Engine

The Deposit Routing Engine is the decision layer that sits between the Deposit Pool (staging area) and the three-tier pool architecture. It reads the LP's intent class, current pool states, and admin configuration to determine where capital flows.

1. Architecture Overview​

The routing engine operates as a deterministic state machine.

Inputs: LP Intent Class (Class A or Class B — declared at deposit time, immutable for that deposit), Deposit Amount, Pool Currency (USDT, IDRX, MYRC, tnSGD), Current Pool Balances (real-time balances of Active, Reserve, and Yield pools), Admin Configuration (max capacities, min balances, split ratios, fee tiers — all per-currency).

Outputs: Deposit allocation (which pool(s) receive the capital and how much), kToken minting instruction (which variant and amount), Deposit ledger record (timestamp, amount, class, pool allocation for cooldown tracking), Overflow/queue status (if applicable, deposit enters pending queue with admin notification).

2. Routing Logic — Class A (FX-Only)​

Class A deposits route exclusively to the Reserve Pool. They never enter the Yield Pool under any circumstances.

Decision Flow​

  1. Check Reserve Pool capacity: Is Reserve Pool balance + deposit amount ≤ Reserve Max Capacity?
  2. If YES: Deposit entire amount into Reserve Pool. Mint kXXX-fx tokens. Record in deposit ledger.
  3. If NO (Reserve at max): Calculate remaining capacity (Reserve Max − Current Balance).
    • If partial capacity exists: Deposit up to remaining capacity into Reserve. Place the overflow amount into the Pending Queue.
    • If zero capacity: Entire deposit enters Pending Queue. System sends admin notification to review threshold adjustment.
  4. Pending Queue resolution: Admin raises Reserve Max → queued deposits auto-process in FIFO order. Or, LP can cancel and withdraw from queue.
Critical Rule

Class A capital must NEVER overflow into Yield Pool. The LP explicitly rejected yield risk. Routing their capital to Yield would violate their stated intent and expose them to losses they did not consent to. The Pending Queue exists specifically for this scenario.

3. Routing Logic — Class B (Full Participation)​

Class B deposits split between Reserve Pool and Yield Pool according to the admin-configured ratio (default 50/50).

Decision Flow​

  1. Calculate target allocation: Reserve portion = Deposit × Reserve Ratio (e.g., 50%). Yield portion = Deposit × Yield Ratio (e.g., 50%).
  2. Check Reserve Pool capacity: Can Reserve absorb its portion?
    • If YES: Deposit Reserve portion → Reserve Pool.
    • If NO (Reserve at max): Deposit up to remaining Reserve capacity → Reserve Pool. Redirect excess to Yield Pool (tagged as "overflow capital" for priority recall).
  3. Check Yield Pool capacity: Can Yield absorb its portion (plus any Reserve overflow)?
    • If YES: Deposit Yield portion → Yield Pool.
    • If NO (both at max): Place excess into Pending Queue. Notify admin.

Overflow Tagging​

When Class B Reserve overflow redirects to Yield Pool, it is tagged as "overflow capital." This tag serves a specific purpose: during Smart Rebalancing deficit recovery, overflow-tagged capital in the Yield Pool is the first to be recalled back to Reserve, before organically-deployed yield capital. This ensures the Yield Pool's core strategy allocations are disrupted last.