DLP — the counterparty pool

The DLP (Diviko Liquidity Pool) is the single, shared pool of assets that backs every position on diviko perps. Liquidity providers deposit assets into the pool, receive dlpUSD tokens representing their share, and collectively earn the fees and absorb the PnL of every open trade.

There is no order book and no maker/taker model. The pool is the counterparty.

Composition

The pool is a basket of assets with target weights set by governance:

The current composition drifts from the targets as traders open and close positions and as the prices of the constituents move. Mint and redeem fees nudge the composition back toward target: deposits of underweight assets pay a discounted fee, deposits of overweight assets pay a premium.

Why a basket

A single-asset pool can only back trades in one direction. A USDC-only pool could back shorts but not longs (a long ETH position needs ETH in the pool to be there when the trader wins and the protocol owes them payout). A multi-asset basket means every market can be supported with no internal hedging.

It also makes the pool reflect the trades it backs. When traders are net long ETH and ETH rises, the pool loses on PnL but the ETH it holds also rises, partially offsetting the loss. The basket is a structural hedge against the direction the pool is implicitly taking.

Minting and redeeming

To mint dlpUSD, deposit any of the supported assets. The protocol values the deposit at the oracle price, subtracts the mint fee, and issues dlpUSD at the current pool NAV per share:

shares_minted = (deposit_usd × (1 − mint_fee)) / nav_per_share

Redemption is symmetric — burn dlpUSD, receive any supported asset (subject to the pool holding enough of it), with a redeem fee applied.

The mint and redeem fees float between 0.20% and 0.80%, based on how the action affects pool weights. A USDC deposit when USDC is underweight might pay 0.20%; a USDC deposit when USDC is overweight might pay 0.80%. This is the only mechanism rebalancing the pool — there is no internal swap, no rebalancing keeper, no AMM.

NAV per share

The pool's net asset value is the USD-marked value of every asset it holds, plus the open PnL of every active position from the pool's perspective:

nav = Σ asset_balance × asset_price
    − Σ trader_unrealised_pnl
    + Σ unclaimed_fees

NAV per share is nav / dlpUSD_supply. It moves with three things: asset price changes (the basket is mark-to-market), trader PnL (LPs are net short trader profits), and fee accrual (continuous, upward).

Over long horizons fees dominate. Over short horizons, sharp moves against the pool's open positions dominate.

What LPs are taking

An LP holding dlpUSD is taking three exposures simultaneously:

• Long the basket. The pool holds 40% crypto, 60% stables at target weights. LPs are exposed to crypto price moves on the inventory.
• Short trader skill. Every dollar that net trader PnL goes up, NAV goes down by the same dollar. If traders systematically win, the pool loses.
• Long fee flow. Opening, closing, borrow, mint/redeem, and liquidation fees all flow into NAV continuously.

The thesis of the pool is that trader-aggregate PnL is, on net and over time, negative — and that fees more than compensate for the times it isn't. This has held empirically across centralised perpetual exchanges; the design of the protocol (high leverage availability, retail-friendly UX, no hedging tools) tilts the same way.

Caps and reserves

To bound the pool's worst-case exposure, the protocol enforces two limits:

• Per-market open interest caps — the maximum total long size and short size for each market, as a fraction of the pool's relevant inventory.
• Per-asset reserve caps — no more than X% of any single asset's inventory can be reserved by open positions. This guarantees a floor of redeemable inventory for LPs.

When a cap is hit, new positions on the bound side are blocked until existing positions close. The opposite side is unaffected.

Withdrawal

LPs can redeem any time, subject to the reserve cap. There is no lockup, no vesting, no escrow. Because positions reserve underlying inventory, a large redemption against a heavily reserved asset may need to wait for some positions to close — but the rest of the basket remains redeemable in the meantime.