Vault & Liquidity Management
Vault Overviewβ
Denaria uses a modular vault architecture to isolate risk and manage collateral with precision. Each perpetual market has its own dedicated vault, meaning systemic issues or bad debt in one market will not affect others. In the initial release of the perpetual DEX, the BTC vault will support a single stablecoin. This simplifies accounting, reduces operational complexity, and provides a seamless user experience for both traders and liquidity providers. However, the vault smart contracts are already built to support a multi-stablecoin architecture, which will be activated in a future upgrade.
Once enabled, this feature will allow users to deposit a mix of approved stablecoins into a single vault. The system will enforce soft composition thresholds to prevent excessive exposure to any one asset, enabling more flexible collateral management while maintaining safety and predictability.
How the Vault Worksβ
The vault is the only component of the Denaria protocol that interacts with real assets. It underpins the entire economic system:
- For traders, it ensures all leveraged positions are backed by real collateral and that losses can be absorbed safely.
- For liquidity providers, it tracks deposits with high granularity, enabling fair and automated distribution of fees, funding, and PnL.
When traders and LPs deposit collateral, no virtual balances are immediately assigned. Instead, the deposit grants users the right to open trades or to deposit liquidity up to a certain leverage. Only when a user opens a position, its virtual balance is assigned to its wallet. For example, opening a long involves borrowing vStable, exchanging it through the vAMM for vAsset, and creating a corresponding virtual asset debt.
This mechanism ensures that only virtual tokens are used within the dynAMM for trading, while the vault holds real assets securely, isolated from direct trading activity. The separation strengthens the protocolβs security model and facilitates transparent and flexible pricing mechanisms through the virtualized environment.
Trader Flow Example β Aliceβ
Alice wants to open a long position on BTC with $2,000 in stablecoin as collateral. When she chooses to open the position, the system automatically locks this collateral in the BTC vault and updates her account balance. To open a 5Γ leveraged long (i.e., $10,000 notional exposure), the protocol assigns her a $10,000 balance in vStable, recorded as debt. This vStable is then immediately swapped through the virtual AMM into the corresponding amount of vBTC, giving Alice BTC exposure.
To close the position, Alice will need to swap back the vBTC into vStable and repay her debt in full.

LP Flow Example β Bobβ
Bob is a liquidity provider with $10,000 in stablecoins. He deposits this amount into the BTC vault, specifying how much he wants to allocate as vStable or vAsset exposure, depending on his strategy.
The protocol uses internal tracking to register Bobβs position in the pool. His deposited value becomes part of the dynAMMβs virtual liquidity, used to simulate trades by users like Alice. Every time a trade occurs, the system updates Bobβs position using a two-share model, separately tracking his exposure to virtual stable and virtual asset sides of the pool. His share of fees, funding payments, and PnL from trades is calculated based on his vStable and vAsset shares.
Itβs important to note that simply holding vAsset in the liquidity pool does not automatically expose Bob to the underlying assetβs market price. His exposure changes only when his liquidity becomes the counterparty to a trade; for example, when a trader buys vAsset from the pool. This dynamic design allows LPs to hold imbalanced liquidity without necessarily carrying continuous directional risk, with exposure adapting to actual market activity.
