# Protocol Whitepaper 0.1
Canonical page: https://docs.denaria.finance/protocol-whitepaper-v01
Status: archived
## Protocol overview
Perpetual futures are derivative contracts that allow users to speculate
on the future price of an underlying asset without an expiry date. In
our protocol, every perpetual contract revolves around two virtual
assets. The first, vAsset, mirrors the underlying asset whose price the
trader intends to predict, while the second, vStable, is a dollar‑pegged
stablecoin employed solely for accounting and quotation. Users never
purchase or sell the real underlying asset; their positions exist only
in these virtual tokens, which they exchange through our dynamic virtual
automated market maker (dynAMM).
The protocol's architecture intertwines several modules. A
**multi‑collateral vault** secures user deposits; the **dynAMM**
provides price computation and trade execution; an in‑house
**share‑tracking algorithm** keeps precise records of each liquidity
provider's contributions and fee earnings; a dedicated **funding fee
mechanism** limits market exposure; a carefully designed schedule of
trader and LP **fees** stabilizes the pool; and, finally, a
**liquidation process** safeguards solvency whenever positions become
under‑collateralised. Together these components create a seamless
environment where traders can take leveraged positions and liquidity
providers (LPs) can earn fees while managing risk.
Interaction with the system begins with depositing collateral. The vault
accepts several approved assets and does not impose rigid, hard‑coded
ratios between them, so users may deposit any blend of the allowed
tokens, subject only to mild limits that prevent extreme changes in the
vault's composition. When a position is opened, the collateral is locked
and any profit‑and‑loss (PnL) payments are, under ordinary
circumstances, returned in the same proportions as the original deposit.
If the vault's overall mix differs sharply from a new user's deposit
-imagine the vault holds mostly Asset A, but the user provides Asset B-
the protocol dynamically adjusts withdrawals so that payouts reflect
both the vault's global ratios and the user's preferred mix. The first
version of our protocol restricts collateral to USD‑pegged stablecoins,
valued initially at one dollar each.
Each underlying asset has its own dedicated vault. After funding their
account, users may borrow vAsset or vStable up to the leverage cap.
vAsset is valued through an external oracle, while vStable is fixed at
one dollar. These vTokens remain internal bookkeeping entries; they
never leave the protocol. To open a long position the trader borrows
vStable and swaps it for vAsset in the dynAMM; to close, the trader
performs the inverse swap, and the difference between vStable repaid and
vStable received---adjusted for funding payments---constitutes the final
profit or loss.
The dynAMM itself continuously recentres its pricing curve on the oracle
price, following mathematics akin to Curve's StableSwap and CryptoSwap
[1], [2] formulas but re‑implemented from scratch
for gas efficiency. As a result, trades are executed at the prevailing
market price with minimal slippage, and the funding rate is no longer
tied to AMM slippage. Liquidity providers may supply balanced,
imbalanced, or even single‑sided liquidity, enabling precise control
over exposure---depositing only vAsset, for example, is equivalent to
taking a passive short. Because every trade shifts the pool's
composition, we maintain each LP's claim with a single global
accumulator plus periodic per‑LP snapshots, an approach that keeps gas
costs low without sacrificing accuracy.
Trading fees are charged on every swap and collected in vStable, while
additional composition fees steer LP deposits toward a healthy pool
balance. Funding payments counteract prolonged market trends: traders on
the popular side pay, and traders on the less‑popular side receive, a
fee proportional to position size and a novel funding rate computed from
LP exposure rather than a mark‑index price gap. The same
accumulator‑and‑snapshot technique that tracks LP shares also measures
each account's funding liability or entitlement.
Positions must maintain a minimum margin ratio, defined as collateral
value after PnL were applied divided by the notional position value. If
this ratio falls below the liquidation threshold, anyone may liquidate
the position by purchasing it at a discount. The discount is chosen so
that slippage cannot erode the liquidator's expected profit, ensuring
strong incentives to keep the system solvent.
## Multi stable-asset collateral vault {#vault}
In the initial release of the protocol, collateral is restricted to
USD‑pegged stablecoins. Users may deposit any combination of the
approved coins in whatever proportions suit them, and -under ordinary
conditions- their PnL is settled in those same proportions. This
symmetry cannot always be satisfied, though. Suppose a vault contains
funds from only two users, one who contributed exclusively stablecoin A
and another who supplied only stablecoin B. The vault clearly cannot
satisfy each payout in the exact coin mix originally deposited. To
handle such situations the protocol employs an adaptive settlement
algorithm, outlined in this next section, that redistributes assets
fairly whenever the vault's composition diverges from a user's preferred
mix.
The user is permitted to deposit collateral in any of $n$ stablecoins,
denoted by Stable_1 to Stable_n . Let $y_1,...,y_n$ the amount of each
coin he deposits respectively as collateral. Some $y_i$ can be 0. We
define:
$$
r_i = \frac{y_i}{y_1 +y_2...+y_n}, i=1,2,...n
$$
All the stable coins are assumed to hold their peg. The sum in the
denominator (let's denote it by $y$) is the total value in USD deposited
as collateral by the user.
If these ratios were the same for each user we could force the users to
pay for their PnL in these same ratios and then the system would have
the desired properties. But this would be too restrictive, so we will
describe a more flexible approach.
We denote by $r_{i,tot}$ the same ratios for the whole system/vault
before the new collateral deposit i.e if $y_{1,tot},...y_{n,tot}$ the
total amount of Stable_1 to Stable_n tokens in the vault before this new
collateral deposit:
$$
\tag 1
r_{i,tot}=\frac{y_{i,tot}}{y_{1,tot}+...+y_{n,tot}}
$$
and by $r'_{i,tot}$ the total ratios after the new deposit i.e.:
$$
\tag 2
r'_{i,tot}=\frac{y_{i,tot}+y_i}{(y_{1,tot}+y_1)+...+(y_{n,tot}+y_n)}
$$
- The user is free to deposit collateral in any ratio provided that:
$$
\tag 3
\left| \frac{r_{i,tot}-r'_{i,tot}}{r_{i,tot}}\right|< th_i
$$
The thresholds $th_i$ will be determined before deployment.
- When the user wants to close his position: Let's say that his total
PnL are $y_{PnL}$ USD (negative PnL means that the user should be paid
and positive that he should pay). The total USD value of the
collateral he can withdraw is $y-y_{PnL}$. We compute
$r'_i, i=1,2,...n$, as described below, and give him back
$r'_1\cdot (y-y_{PnL})$ Stable_1 , \... $r'_n\cdot (y-y_{PnL})$
Stable_n .
**Computation of the ratios**:If everyone was depositing collateral in
the exact same ratios $r_i$, then $r'_i$ should also be equal to $r_i$,
meaning the user pays their PnL proportionally to their initial deposit.
However, since not everyone deposits collateral at the same ratio,
$r'_i$ will depend on the user's initial ratio ($r_i$), as long as the
total ratios of the pool immediately before ($r_{i,tot}$) their
collateral withdrawal.
We first compute $dy_i=(y-y_{PnL})\cdot r_i$ and then the total ratios
after the withdrawal:
$$
\tag 4
r'_{i,tot}=\frac{y_{i,tot}-dy_i}{(y_{1,tot}-dy_1))+...+(y_{n,tot}+dy_n )}
$$
Observe that the denominator equals
$y'=y_{1,tot}+...+y_{n,tot}-(y - y_{PnL})$ and therefore does not depend
on the splitting.
If
$$
\tag 5
\left| \frac{r_{i,tot}-r'_{i,tot}}{r_{i,tot}}\right|< th'_i
$$
holds for every $i$, we set $r'_i=r_i$ for every $i$. The withdrawal threshold
$th'_i$ could be the same or smaller than $th_i$.
If the above condition is not satisfied, or if some of the $dy_i$ as
copmputed above exceed the available $y_{i,tot}$ in the vault, we set
$r'_i=r_{i,tot}$ for every $i$.
*Note*: We are aware that the user can bypass the restrictions
(3) and
(4) by splitting his deposit or
withdrawal to smaller ones that will gradually shift the total ratios of
the vault. A mitigation against it is to use instead of the actual
ratios $r_{i,tot}$ time averages.
## Dynamic AMM {#vAMM}
Every perpetual protocol needs a pricing mechanism -a way to decide how
much vAsset a trader receives for their vStable when opening a long
position and vice verse for short- while keeping that quoted price
aligned with the underlying market price.
Traditionally, protocols either use oracle pricing, which takes the live
market price of the underlying from an oracle, or virtual AMM (vAMM)
pricing, which lets a constant‑product AMM determine the price and
relies on arbitrage to pull it back toward the market. Our design blends
the strengths of both. We start with an AMM that has very low slippage
and then continuously re‑center its curve around the oracle price
instead of waiting for external arbitrage. We call this mechanism a
dynamic virtual AMM, or dynAMM.
The dynAMM fairly compensates LPs because trades clear close to the true
market value. Capital efficiency is preserved: minimal slippage protects
the pool from being drained yet still lets trading pressure show up in
prices. For traders, execution remains near the market price without
needing outside market makers.
Dynamic AMMs have been discussed in prior academic works [3], but
not in the context of perpetual futures and only for simpler AMM models.
Our dynAMM extends the concept to a more sophisticated perpetual‑trading
environment.
In this section we denote by $(x_0,y_0)$ and $(x,y)$ the amounts of the
two assets in the pool (vAsset and vStable respectively for our dynAMM
case) right before thd right after a trade, respectively, and $p$ is the
market price (provided by an external oracle) of the first asset with
respect to the second one. We will introduce an invariant
$I_{p,x_0,y_0}(x,y)$. From this equation one variable can be expressed
in terms of the other -solving for $x$ yields $y$ and vice versa.
Plotting $I_{p,x_0,y_0}(x,y) = 0$ in the $(x,y)$-plane produces a
continuous curve. We choose the invariant so that this curve passes
through the point $(x_0,y_0)$ and its spot price at that point, i.e.
$-dy/dx$ equals $p$. As a result, trades clear close to the prevailing
market price (small orders incur only minimal slippage; significant
slippage appears only when the trade size becomes large). We construct
the invariant by starting with the graph of a constant function, then
applying suitable shifts and scalings so that it meets both conditions.
The graphs for all the formulas discussed in this section can be found
[here](https://www.desmos.com/calculator/ptnnvsv1eo).
### The formula of the dynAMM
Our invariant is a dynamic extension of the Curve Finance invariant. For
the sake of completeness -and because the resulting formulas may be
useful beyond our protocol- we present a detailed derivation below.
We begin by introducing two simpler invariants, whose combination will
produce the final invariant.
The first one is a dynamic version of the constant sum formula:
$$
\tag 6
S_{p,x_0,y_0}(x,y) := \frac{p(x-x_0)+y-y_0}{px_0+y_0}
$$
Using this invariant, all trades are executed exactly at the market
price $p$, with zero slippage. Note also that this and all subsequent
invariants are normalized and dimensionless.
The second is a dynamic version of the constant product formula
[4]. For this invariant there are two possible choices, as the
shift can be applied either in the $x$ or the $y$ variable:
$$
\begin{aligned}
\tag 7
P^x_{p,x_0,y_0}(x,y) := 1 - \frac{y_0^2}{[p(x-x_0)+y_0]y} \\
P^y_{p,x_0,y_0}(x,y) := 1 - \frac{px_0^2}{[y-y_0+px_0]x}
\end{aligned}
$$
Although both shifted versions of the constant product formula exhibit
qualitatively similar behavior, they define two distinct AMMs -meaning
that, for the same input, they produce entirely different outputs. We
use the first version for short positions and the second for long
positions. Here's why:
Consider the first formula. A key distinction arises between the cases
$p\cdot x_0 < y_0$ and $p\cdot x_0 >y_0$ (the special case
$p\cdot x_0 =y_0$ corresponds to the standard -non dynamic- constant
product formula). When $p \cdot x_0 y_0$, the graph can be
used for both longs and shorts. But for long positions in particular,
the graph becomes asymptotic to the line $x = x_0 - y_0/p$. This implies
that the amount of the x-asset cannot decrease below this threshold,
which limits the efficiency of the AMM -it prevents full utilization of
the x-asset in the pool. This inefficiency becomes especially pronounced
when $p\cdot x_0 >> y_0$.
For the second formula, this behavior is reversed: it is more suitable
for long positions and less effective for shorts.
We would prefer a dynAMM that combines the best properties of both the
constant sum and constant product formulas. Specifically, we would like
its graph to approximate the constant sum curve for values of $(x,y)$
close to $(x_0,y_0)$. This approach minimizes slippage for swaps that do
not significantly move the pool, ensuring such trades are executed near
the market price $p$. However, for larger swaps that shift the pool far
from $(x_0,y_0)$, significant slippage should apply, as with the
constant product rule, to prevent the pool from being depleted.
This behavior can be achieved by defining a new invariant that is a
linear combination of the constant sum and constant product invariants:
$$
\tag 8
A_{p,x_0,y_0}(x,y) \cdot S_{p,x_0,y_0}(x,y) + P^x _{p,x_0,y_0}(x,y) = 0
$$
for short positions and
$$
\tag 9
A_{p,x_0,y_0}(x,y)\cdot S_{p,x_0,y_0}(x,y) + P^y _{p,x_0,y_0}(x,y) = 0
$$
for long. $A_{p,x_0,y_0}(x,y)$ should be a positive function. Observe
that for $A=0$ we get the (shifted) constant product formula and for
$A \rightarrow\infty$ the constant sum. The graph of this new AMM will
lie between the graphs of the constant sum and that of the constant
product.
We will use a function $A_{p,x_0,y_0}(x,y)$ inspired from Curve:
$$
\tag{10}
A_{p,x_0,y_0}(x,y)=\frac{Ay_0^4}{\left( By_0^2+y_0^2-[p(x-x_0)+y_0]y \right)^2}
$$
We can then can write the invariant as a polynomial equation of degree
3:
$$
\tag{11}
ay^3+by^2+cy+d=0
$$
where:
$$
\begin{aligned}
a &= \lambda ^3\\
b &= \frac{Ay_0^4}{px_0+y_0}\lambda -2\lambda^2By_0^2-3y_0^2\lambda^2\\
c &= \lambda \left(\frac{Ay_0^4}{px_0+y_0}(p(x-x_0)-y_0)+(B+1)^2y_0^4+2(B+1)y_0^4 \right)\\
d &= -y_0^6(B+1)^2\\
\lambda &= p(x-x_0)+y_0
\end{aligned}
$$
For longs we can use:
$$
\tag{12}
A_{p,x_0,y_0}(x,y)=\frac{Ap^2x_0^4}{\left( Bpx_0^2+px_0^2-[y-y_0+px_0]x \right)^2}
$$
and the corresponding polynomial equation is:
$$
\tag{13}
ax^3+bx^2+cx+d=0
$$
where:
$$
\begin{aligned}
a &= \lambda ^3\\
b &= \frac{Ap^2x_0^4}{px_0+y_0}\lambda p -2\lambda^2(B+1)px_0^2-px_0^2\lambda^2\\
c &= \lambda\left( \frac{Ap^2x_0^4}{px_0+y_0}(y-y_0-px_0)+(B+1)^2p^2x_0^4+2p^2x_0^4(B+1) \right)\\
d &= -p^3x_0^6(B+1)^2\\
\lambda &= y - y_0 +px_0
\end{aligned}
$$
We will also need the \"inverse\" formulas of the above. To compute the
amount of vAsset required to receive a specified amount of vStable, the
following equation should be used:
$$
\tag{14}
ax^3+bx^2+cx+d=0
$$
where:
$$
\begin{aligned}
A' &=\frac{Ay_0^4}{px_0+y_0}\\
\lambda &= y-y_0-px_0\\
k &= y_0-px_0\\
a &= p^3y^3\\
b &= A'y p^2 + 2p^2y^3k - 2p^2(B+1)y_0^2y^2 +(ky-y_0^2)p^2y^2\\
c &= A'py(k+\lambda) + (B+1)^2py_0^4y + pk^2y^3 -2(B+1)py_0^2y^2k + 2py^2k(ky-y_0^2) - 2(B+1)y_0^2yp(ky-y_0^2)\\
d &= A'yk\lambda + (ky-y_0^2)(B+1)^2y_0^4 + (ky-y_0^2)k^2y^2 - 2(B+1)y_0^2yk(ky-y_0^2)
\end{aligned}
$$
If the state of the pool before the trade was $(x_0,y_0)$ and someone
wants to get exactly $dy$ vStable ($y=y_0 - dy$), he should add to the
pool $dx$ vAsset ($x=x_0 + dx$), and this $dx$ can be found by solving
equation (13).
Also, we can use this equation to compute the amount of vAsset a user
should add to the pool to get the amount of vStabe he needs to close his
long position.\
On the contrary, to calculate the amount of vStable required to obtain a
specific amount of vAsset, we use the following equation:
$$
\tag{15}
ay^3+by^2+cy+d=0
$$
where:
$$
\begin{aligned}
A' &=\frac{Ap^2x_0^4}{px_0+y_0}\\
\lambda &= p(x-x_0)-y_0\\
k &= px_0 - y_0\\
a &= x^3\\
b &= A'x + 2x^3k - 2p(B+1)x_0^2x^2 +(kx-px_0^2)x^2\\
c &= A'x(k+\lambda) + (B+1)^2p^2x_0^4x + k^2x^3 -2(B+1)px_0^2x^2k + 2(kx-px_0^2)kx^2 - 2(B+1)(kx-px_0^2)px_0^2x\\
d &= A'xk\lambda + (kx-px_0^2)(B+1)^2p^2x_0^4 + (kx-px_0^2)k^2x^2 - 2(B+1)px_0^2xk(kx-px_0^2)
\end{aligned}
$$
If the state of the pool before the trade was $(x_0,y_0)$ and someone
wants to get exactly $dx$ vAsset ($x=x_0 - dx$), he should add to the
pool $dy$ vStable ($y=y_0 + dy$), and this $dy$ can be found by solving
equation (15). Also, we can use this equation to compute the
amount of vStable a user should add to the pool to get the amount of
vAsset he needs to close his short position.
*Note*: In the smart contract implementation, we solve these equations
using numerical methods, specifically Newton's method. We chose to work
with the polynomial form of the invariant because, once the polynomial
coefficients are computed, each iteration of the numerical method
becomes simpler---and, importantly, more gas-efficient.
### Using our dynamic vAMM to execute trades
Let's now discuss how these formulas are employed to execute trades.
Recall that in the previous sections we used distinct formulas/graphs
for short and long positions (they coincide only when $x_0/y_0 = p$).
This was done to ensure that the resulting equations yield positive
solutions and that the deposited liquidity is used optimally for trades.
For clarity -purely for exposition purposes without affecting the
implementation- we combine these formulas and graphs into a single
unified curve. This curve uses the formula for shorts when $x > x_0$ and
the formula for longs when $x < x_0$, resulting in a graph that is both
continuous and smooth, with a continuously differentiable first
derivative. It can be described by an invariant $f(p, x_0, y_0, x, y)$,
where the equation follows equation
(11) or
(14) for
$x > x_0$, and equation (13) or (15) for $x < x_0$.
How should a trade be executed? Since we would like to execute trades as
close to the market price as possible -a key motivation behind our vAMM
design-, we could do the following. We start by retrieving the current
pool deposits ($x_0$ and $y_0$) along with the current market price $p$
from the oracle, and then solve the equation
$f(x_0, y_0, p, x_0 + dx, y_0 + dy) = 0$, where $dx,dy$ are the
exchanged amounts.
In simpler terms, we continuously readjust the graph so that the initial
state is always the current $(x_0, y_0)$, ensuring that the price
asymptotically aligns with the market price and slippage remains
minimal. However, this dynamic mechanism introduces a potential exploit:
a user could split a larger position into several smaller trades,
thereby reducing overall slippage. In the extreme, by splitting a
position into infinitely small trades, the user could achieve an
execution price arbitrarily close to the market price (albeit still
marginally higher).
To counter this exploit, we are imposing a minimum position size. Even
without such a restriction, our dynamic vAMM ensures that LPs always
receive at least the market price, thus protecting them from impermanent
loss.
We are also implementing another measure to prevent this attack. Rather
than constantly readjusting the graph with every trade around the
current state, we adjust it so that two consecutive trades in the same
direction (for instance, opening two long or two short positions)
executed in quick succession have the same impact -actually slightly
worse for the user- as a single trade whose size is the sum of the two
trades. This approach renders the attack ineffective.
Let's discuss the specifics of how this works. For this method, the
contracts will store three additional variables, denoted $dx_0$, $dy_0$,
and $t_0$ (or $lastCurveUpdate$ in the contracts) and also the type of
the last trade (long or short). Consider the case of long trades.A user
executes a long trade (let's suppose that a long enough time has passed
since the previous trade) by depositing $dy$ vStable and getting back
$dx$ vAsset from the vAMM.We set $t_0$ to the current timestamp,
$dx_0 :=+dx,dy_0 :=+dy$.We denote by $x_0,y_0$ the total amount of
vAsset and vStable respectively in the vAMM after this trade. Let's
assume the next trade is also long and its timestamp differs from $t_0$
by less than a specific threshold set in the contracts.
If the user exchanges $dy'$ vStable, we first solve the equation
$f(p,x_0+dx_0,y_0-dy_0, x_2, (y_0-dy_0)+dy_0+dy')$ for $x_2$ i.e. we
align the graph around a state ( $(x_0+dx_0,y_0-dy_0)$)as if the
previous long trade has not happened and we just deposited the total
vStable amount of all the last long trades ($dy_0+dy'$) at once. The
difference $dx_{tot}= (x_0+dx_0) - x_2$ is the total amount of vAsset
someone would get if he executed both trades at once (actually a little
bit less, because of the slippage inrease after the first trade).The
amount of vAsset the second trader gets is computed as $dx_{tot}-dx_0$.
We finally increase $dx_0$, $dy_0$ by $dx'$ and $dy'$ respectively and
set $x_0,y_0$ equal to the total vAsset and vStable liquidity in the
pool after this second trade.
If the second trade was a short trade, or time more than the specified
threshold had passed, we would reset $dx_0$ and $dy_0$ to 0 and would
store this new timestamp as the new $t_0$.
## Algorithm for efficiently tracking the LP shares {#LP shares}
We aim to allow imbalanced deposits, meaning LPs can contribute
liquidity to the pool in proportions where the ratio of the two
deposited assets does not necessarily match either the pool's current
ratio or the market price. This flexibility allows LPs to implement more
general strategies and select risk profiles that best suit their needs.
However, this added flexibility introduces extra complexity into the
system.
The LP's share of each asset is not the same and, in fact, not even
constant. Consider an edge case where an LP deposits only one asset. In
this scenario, the LP's share for that particular asset is non-zero, but
their share of the other asset is zero. After a swap that utilizes some
portion of the deposited asset, the LP will also own a non-zero amount
of the second asset. This change must be reflected in the dynamic
adjustment of their shares.
To make this approach feasible, we need an efficient method to compute
these constantly changing shares in a way that is scalable and
independent of the number of swaps or LPs. In these notes, we outline an
algorithm to achieve this.
By defining the LP shares dynamically, we can accurately track the
liquidity that each LP can withdraw, depending on what they have
deposited and also fairly distribute the fees earned through swaps,
proportional to each LP's dynamically updated shares.
### Description of the algorithm
Let's start by introducing some notation:
- $t$: discritized time, updated by 1 after each action (either swap or
liquidity deposit/withdrawal).
- $x(t),y(t)$: the amount of the X and Y assets in the pool
respectively, at time $t$.
- $S_x(t),S_y(t)$: The total shares for the X and Y asset respectively,
at time $t$.
- $s_{x,i}(t),s_{y,i}(t)$: The shares of the $i$ LP for the X and Y
asset respectively, at time $t$. The ratio of the LPs shares to the
corresponding total shares, equals the percentage of the assset in the
pool the LP owns and therefore can withdraw.
We will prove in the next section that the shares of each LP are linear
combinations of his initial shares (we assume for convenience that his
deposit happened at time t=0):
$$
\tag{16}
\begin{aligned}
s_{x,i}(t) &= M_{x,x}(t)s_{x,i}(0) + M_{x,y}(t) s_{y,i}(0)\\
s_{y,i}(t) &= M_{y,x}(t)s_{x,i}(0) + M_{y,y}(t) s_{y,i}(0)
\end{aligned}
$$
The coefficients are the same for all LPs, therefore if we can compute
them efficiently we will be able to compute every LP's shares at every
moment. We will also prove that these coefficients should be updated as
follows, depending on the action (short trade, long trade or liquidity
deposit/withdrawal).
For long swaps (i.e. when a user gets an amount of X asset from the pool
and deposits an amount of Y asset):
$$
\begin{aligned}
& M_{x,x}(t+1) = M_{x,x}(t)\\
& M_{x,y}(t+1) = M_{x,y}(t)\\
& M_{y,y}(t+1) = M_{y,y}(t) + M_{x,y}(t) \cdot A_y(t+1)\\
& M_{y,x}(t+1) = M_{y,x}(t) + M_{x,x}(t) \cdot A_y(t+1)
\end{aligned}
$$
For short swaps (i.e. i.e. when a user gets an amount of Y asset from
the pool and deposits an amount of X asset)
$$
\begin{aligned}
& M_{x,x}(t+1) = M_{x,x}(t) + M_{y,x}(t) \cdot A_x(t+1)\\
& M_{x,y}(t+1) = M_{x,y}(t) + M_{y,y}(t) \cdot A_x(t+1)\\
& M_{y,y}(t+1) = M_{y,y}(t)\\
& M_{y,x}(t+1) = M_{y,x}(t)\\
\end{aligned}
$$
For liquidity deposits and withdrawals only the total shares are updated
and not the individual shares (with the exception of the LP that
deposits or withdraws, of course), therefore in this case the
coefficients should not be updated. It will be very helpful to express
these equations using 2x2 matrices. We define:
$$
M(t) = \begin{bmatrix} M_{x,x} & M_{x,y} \\ M_{y,x} & M_{y,y} \end{bmatrix}(t)
$$
Using this notation, the equations describing the updates of the
coefficints can be written as: $M(t+1) = A(t+1) \cdot M(t)$
$$
M(0) = \begin{bmatrix} 1 & 0 \\ 0 & 1 \end{bmatrix}
$$
where:
$$
A(t+1) = \begin{bmatrix} 1 & 0 \\ A_y(t+1) & 1 \end{bmatrix} \quad \text{or }\quad \begin{bmatrix} 1 & A_x(t+1) \\ 0 & 1 \end{bmatrix}
$$
if the swap is long or short respectively. The formulas for $A_x,A_y$
are given in the next section. The important thing is that they depend
only on global variables (total shares, total deposits) and on the
exchanged amounts and therefore are the same for all LPs. Applying
recursively this formula we get theformula for $M(t)$:
$$
\tag{17}
M(t) = A(t)\cdot A(t-1) \dots A(1)
$$
This formula can be used for the computation of the shares of an LP that
has deposits since time $t=0$. If an LP deposits at time $t_0$ the
matrix coeeficient for him should at time $t \geq t_0$ be:
$$
\tag{18}
M_{t_0}(t)=A(t)\cdot A(t-1) \dots A(t_0+1)=M(t) \cdot M^{-1}(t_0)
$$
Putting all these together, the steps for computing the shares for the
LPs are:
- For the first LP we are minting shares equal to the deposited amounts
(or any multiple of them).
- At every action we update the matix $M$ using
(17).
- When a new LP deposits some liquidity we are computing his initial
deposits $(s_{x,i}(0),s_{y,i}(0))$ and take a snapshot of the matrix
$M$. Whenever we need to compute the shares of this LP, we should
first compute the coefficient matrix using
(18) and then use
(16) replacing $M$ by $M_{t_0}$.
### Proof that the algorithm correctly computes the shares
We will prove that
(16) hold for every $t$ by induction. For $t=0$
this is trivial, since:
$$
\begin{aligned}
s_{x,i}(0) &= 1 \cdot s_{x,i}(0) + 0 \cdot s_{y,i}(0)\\
s_{y,i}(0) &= 0 \cdot s_{x,i}(0) + 1 \cdot s_{y,i}(0)
\end{aligned}
$$
We assume that the formulas are valid for $t$ and we
will prove that they are also valid for $t+1$. The shares should be
updated only after an action. We will study each action separately.
**Long swaps**: A user buys a $dx$ amount of X-asset from the pool by
depositing a $dy$ amount of Y-asset. Of course $dx$ and $dy$ are related
through the formula of the AMM, but a nice feature of our approach is
that it does not depend on the details of the AMM. The X-shares of the
LPs do not change. What changes is the amount of X-asset corresponding
to these shares. Each LP loses $dx\frac{s_{x,i}(t)}{S_x(t)}$ and
therefore he should earn the same percentage in Y-assets. $y(t)$ is
increased by $dy$. We increase the total Y-shares by:
$$
\begin{aligned}
& \delta S_y = S_y(t) \frac{dy}{y(t)} \Rightarrow \\
& S_y(t+1) = S_y(t) \cdot \left( 1+\frac{dy}{y(t)} \right)
\end{aligned}
$$
The i LP owns $\delta s_{y,i}$ of these extra $\delta S_y$ shares:
$$
\begin{aligned}
\delta s_{y,i} &= \delta S_y \frac{s_{x,i}}{S_x(t)}\\
&= s_{x,i}(t)\frac{S_y(t)}{S_x(t)}\frac{dy}{y(t)}\\
&= s_{x,i}(t)A_y(t+1)
\end{aligned}
$$
where
$$
A_y(t+1)= \frac{S_y(t)}{S_x(t)}\frac{dy}{y(t)}
$$
Therefore:
$$
\begin{aligned}
s_{y,i}(t+1) &= s_{y,i}(t) + \delta s_{y,i}\\
&= M_{y,x}(t)s_{x,i}(0) + M_{y,y}(t) s_{y,i}(0) + \left( M_{x,x}(t)s_{x,i}(0) + M_{x,y}(t) s_{y,i}(0) \right) \cdot A_y(t+1) \quad \text{(t inductive step)}\\
&= \left( M_{y,x}(t) + M_{x,x}(t) \cdot A_y(t+1) \right)s_{x,i}(0)+\left( M_{y,y}(t) + M_{x,y}(t) \cdot A_y(t+1) \right)s_{y_i}(0)
\end{aligned}
$$
**Short swaps**: The idea is identical, we only have to replace x by y
and vice versa.
**Liquidity deposits**:When a new LP deposits $dx$ and $dy$amounts in
the pool, the shares of the old LPs do not change. Only the total shares
change. For this new LP, the protocol should mint initial shares
(assuming that the time of the deposit is $t+1$):
$$
\begin{aligned}
s_{x,i}(0) &= S_x(t)\frac{dx}{x(t)}\\
s_{y,i}(0) &= S_y(t)\frac{dy}{y(t)}
\end{aligned}
$$
and the total shares increase, as follows:
$$
\begin{aligned}
S_x(t+1) &= S_x(t)\left( 1 + \frac{dx}{x(t)} \right)\\
S_y(t+1) &= S_y(t)\left( 1 + \frac{dy}{y(t)} \right)
\end{aligned}
$$
## Fees
### Fees for opening/closing a position
Whenever a user opens, closes, or modifies a position, a small fee is
applied. This fee is calculated as a percentage of the traded amount and
is always denominated in the quote asset -vStable, in our protocol. By
using a stable quote asset, fee revenues remain unaffected by market
fluctuations.
The fees collected are divided among: the protocol, the insurance fund,
and the LPs. The portion allocated to the protocol supports ongoing
development and maintenance. The insurance fund receives a share to
cover potential losses in cases of bad debt when positions are closed.
The remaining portion goes to LPs and is added directly to the liquidity
pool.
In the case of short positions, where vStable is taken from the pool,
the LP fee distribution is based on each LP's vStable shares. For long
positions, the distribution is instead based on their vAsset shares.
This mechanism ensures LPs are fairly compensated according to the type
of position being taken and the assets being utilized.
### Fees for liquidity deposits that imbalance the pool
The protocol we are designing allows for liquidity deposits in any ratio
$r =\frac{Dy}{Dx}$, where $Dx$ represents the amount of vAsset and $Dy$
the amount of vStable deosited by an LP in the pool. This includes
one-sided liquidity deposits ($r=0$ or $\infty$).This flexibility is
made possible by two key features of the protocol:
- *The dynAMM*: This enables exchanges to occur near the market price,
even when the ratio of total deposits in the pool differs from the
market price.
- *Two-Shares-Per-LP Mechanism*: This approach efficiently tracks the
continuously changing shares of LPs for imbalanced deposits.
This flexibility is an advantage of our protocol, as it allows LPs to
implement strategies fitting their risk profiles and market
expectations. For example, by depositing one-sided liquidity (e.g., only
vAsset), an LP primarily gains short exposure, since traders can only
buy their vAsset (although, over time, as trades occur, the LP's shares
will naturally shift, and they will gradually own a mix of both vAsset
and vStable).
While this flexibility benefits LPs and allows for diverse trading
strategies, it can also lead to imbalanced pools---where the ratio of
total vStable to total vAsset in the pool deviates significantly from
the market price. Although our protocol remains robust under such
conditions, continuing to offer prices close to the market price for
most trades, heavily imbalanced pools can result in higher slippage.
We are implementing a fee mechanism for liquidity deposits that
incentivizes LPs to help maintain a balanced pool. The pool is
considered balanced when the ratio of vStable to vAsset in the dynAMM
matches the current market price. To encourage this equilibrium, higher
fees will be applied to deposits that increase the imbalance, while
minimal or even zero fees will be charged for deposits that move the
pool closer to balance.
## Funding payments {#funding}
Funding payments are a core component of any perpetual protocol. While
different protocols use various formulas to calculate funding rates (see
[5] for a summary), they generally share two key features:
- *Direction of Payments*: If the funding rate is positive, long
positions pay short positions; if negative, short positions pay long
positions. This is just a convention.
- *Balancing the System*: Funding payments are designed to help balance
the system.Although, what it means \"balancing of the system\" varies
for each protocol.
Most commonly, funding payments help keep the perpetual price (mark
price) aligned with the index price (market price of the underlying
asset). For instance, if the perpetual price is too high, funding
becomes positive, encouraging shorts and discouraging further longs
-helping prices converge.
In our protocol, this alignment is already achieved through the dynAMM,
which keeps the perpetual price close to the market price without
relying on funding payments. This allows us to offer lower funding
costs, giving us a competitive edge.
However, funding payments serve broader purposes:
- They incentivize traders to take the less popular side.
- In balanced markets, the funding payments lead to positive returns for
LPs; in directional markets, they help reduce LPs' losses.
- They also reduce system exposure by discouraging the most popular
positions and encouraging balanced participation, limiting the risk
LPs must absorb.
### Definitions
In its most general form the fundyng payment a position holder -either a
trader or an LP- should make (or receive) is given by the formula:
$$
\textit{Funding fees for the position} = \textit{position value} \cdot \textit{Funding rate}
$$
where
- positive funding fees means that the position should pay these fees
and negative that the position should receive the fees.
- position value: equals
$\textit{(position size} \cdot \textit{price)}$, and is positive for
long and negative for short positions
- Funding rate: it is a global quantity (the same for every position),
changes with time and trades and liquidity changes, is positive if
longs should pay shorts and negative if shorts should pay longs
#### The time component of the funding rate
First, we need to determine how frequently the funding payments should
be calculated and accounted for. To clarify, this does not necessarily
mean that actual payments must occur immediately. The funding rate can
be expressed as:
$$
\textit{Funding rate = }\frac{\textit{Funding coefficient}\cdot \Delta t}{\textit{Funding Interval}}
$$
where
- *Funding coefficient*:T his is not a standard term and will be
formally defined in a later section. It represents a global variable
that updates with every user action (e.g. trades or liquidity
deposits).
- *Funding interval*: When time equal to the Funding interval has
passed, the total fees (that should be paid) equal ( (Funding
coefficient) $\cdot$ (total value of the most popular position type)
). The standard choice for the funding interval is 1 day (computed in
seconds), but we could decrease it to increase the rate.
- $\Delta t$: Represents the elapsed time (in seconds) since the
previous user interaction (e.g. trade or liquidity update). Our system
uses a continuous funding model rather than discrete time intervals.
This approach minimizes the risk of manipulation -such as timing
position changes around scheduled funding events- and ensures
smoother, more consistent fee accrual. On each user action, the
funding rate is computed using the current funding coefficient and
$\Delta t$, after which the funding coefficient is updated to reflect
the new state.
#### Position sizes
If $FF_j$ are the funding fees for a position $j$ (this could be either
a trader or an LP position), then the sum of the funding fees should be
zero (total sum of positive fees should equal minus the total sum of
negative i.e. payments of funding fees should cancel out and there
should be no need for extra funds). This should be true for every
funding payment (after every action) and not only for total payments
over a period. This is true iff:
$$
\begin{aligned}
\sum _j FF_j &= \sum _j \textit{Funding rate}\cdot \textit{Value of position j}\\
&= \textit{Funding rate}\cdot \sum _j \textit{Value of position j}
\end{aligned}
$$
i.e. iff the sum of the position values (positive for long and negative
for shorts) is zero.
The position value can be computed by multiplying the position size
(that we have to define) by the price (average price over the time
period between two consecutive actions -check the algorithms in the next
section-):
$$
\begin{aligned}
\sum _j FF_j &= \textit{Funding rate}\cdot \sum _j \textit{Value of position j}\\
&= \textit{Funding rate}\cdot price \cdot \sum _j \textit{Size of position j}
\end{aligned}
$$
Therefore, the sum of the funding payments will be zero if and only if
the sum of the position sizes is zero. This holds true because positions
are opened by exchanging amounts in a vAMM. However, let's explore this
further to clarify the details. A long trader will borrow vStable and
exchange them in the vAMM for vAssets. Therefore at the end his vAsset
debt will be zero (he didn't borrow any vAssets) and his vAssets balance
will be the the output of the vAMM. In the contrary a short trader will
borrow vAssets and exchange them for vStable. In both cases the
difference:
$$
\begin{aligned}
\textit{Position size} = \textit{vAsset balance}-\textit{vAsset debt}
\end{aligned}
$$
captures the size of the position, that will be positive
for longs and negative for shorts.
$$
\begin{array}{|l|l|l|l|}
\hline
& & Debt & Balance \\ \hline
\text{long trader} & vAssets & 0 & dx \\ \hline
& vStable & dy & 0 \\ \hline
\text{short trader} & vAssets & dx & 0 \\ \hline
& vStable & 0 & dy \\ \hline
\end{array}
$$
The debt of a position changes only if the owner of the position
interacts with the protocol to close or update the position. This is
true for both traders and LPs. The balance of a trader can also only
change by a direct interaction of the trader with the protocol,
therefore a trader's position has constant size (between two
interactions of the user with the protocol) and this simplifies the
computation of the funding payments as we will see in the next section.
The balance, and therefore the position size, of an LP constntly
changes, as traders open positions transforming the liquidity of the
pool from vStable to vAssets and vice versa. But we can still
effectively compute these balances, using the shares:
$$
\begin{aligned}
\textit{j LP's balance at time t} = \frac{s_{x,j}(t)\cdot x(t)}{S_x(t)}
\end{aligned}
$$
When an LP deposits liquidity in the pool, this can be splitted into two
actions: borrowing vAssets and vStable from the protocol (these amounts
are his debts) and depositing these amounts to the pool (these are his
balances). Therefore immediately after the deposit (until the first
trade) the position of the LP is zero. Therefore initially all the
positions, and therefore their sum, is zero. Since each trade is
executed through an exchange in the dynAMM, it is clear that opening a
new position simultaneously increases the LPs' total position by an
equal amount with the opposite sign. As a result, all trades preserve
the zero-sum of the funding payments.
#### A new approach to funding rates using the total exposure
Since the primary purpose of funding payments in our system is to reduce
total exposure, we define the funding coefficient to be proportional to
total exposure as follows:
$$
\textit{Funding coefficient} = \frac{\textit{Total exposure}}{c\cdot \textit{Total liquidity}}
$$
where
- *c*: a constant between 0 and 1 (percentage of the pool liquidity)
- *Total liquidity*: total liquidity in the pool. The exact definition
is not really crucial. We just use it to be able to define when an
certain exposure should be considered small or large. It can simply be
computed as $p\cdot x + y$.Where $x$ and $y$ are the amounts in the
pool and $p$ the market price.
- *Total exposure*: Sum of long minus sum of short positions **only for
traders**. Since, as we have shown, the sum of all the positions is
zero, this is also equal to minus the total position of the LPs.
Setting the funding rate proportional to this, the traders are
incentivized to decrease the total exposure of the LPs.
### An algorithm for efficiently computing the funding payments of traders and LPs
We denote by $F(t)$ the funding rate at time $t$ (actually it will be
the funding rate times the market price i.e. funding fees = position
size $\cdot$ price $\cdot$ funding rate and we store to $F$ the product
price times funding rate). The initial value of the funding rate should
be zero, since there are no open positions by traders at the protocol
initially. The funding rate should change after each trade and liquidity
deposit/withdrawal, the LP's positions change after each swap or if the
owner of the LP position deposits/withraws and position of a trader
changes only when he updates it and not when other users interact with
the protocol. After each trade we also compute the total exposure
$Exp(t) = Exp_s(t) \cdot p$ (where $Exp_s$ is the size in terms of
vAssets of the total exposure i.e. balance of vAssets held by long
traders minus debt of vAssets of short traders) and total liquidity
$L(t)$. We denote by $T$ the funding interval.
- Funding paymements for traders:
- The user opens his position at $t_0$ and the previous trade happened
$\Delta t$ seconds ago. The size of the position is $D x$ vAssets
(positive for long and negative for short).
- We update the funding rate:
$$
\begin{aligned}
F(t_0) &=F(t_0 - \Delta t) + \Delta F (t_0 - \Delta t)\\
&= F(t_0 - \Delta t) +\bar{p}\frac{Exp_s(t_0-\Delta t)\cdot \bar{p} \cdot \Delta t}{c\cdot L(t_0-\Delta t)\cdot T}
\end{aligned}
$$
and take a snapshot and store it at the user's state
info. $\bar{p}$ is the average market price for the $\Delta t$ time
interval. We can get it from the price oracle.
$L(t_0 - \Delta t)= \bar{p}\cdot x(t_0)+y(t_0)$.
- We update the total exposure size:
$$
\begin{aligned}
Exp_s(t_0) &= Expt_s(t_0 - \Delta t) + Dx\\
\end{aligned}
$$
- When, at some time $t$, the trader decides to close or update his
position, we first compute the current funding rate $F(t)$ and his
total funding fees (positive means he has to pay, negatve means he
should receive funding payments) as:
$$
\begin{aligned}
\textit{Total trader's funding fees}=Dy \cdot (F(t) - F(t_0))
\end{aligned}
$$
These fees should be added to his pnl from price
changes and then settled, by pairing the trader with another user with
opossite side unsettled pnl (check the notes with the example about
funding payments). We then make the changes in the pool and update the
funding rate as described in the previous step.
- Funding payments for LPs:
- The funding rate is computed and updated as in the case of traders'.
When an LP deposits or withdraw liquidity, the total exposure does
not change (it is just distributed to the remaining LPs), but the
funding rate changes because of the change of the total liquidity.
The tricky part is that the LP position change not only when an LP
interacts directly with the protocol, but on every trade.
- If two consecutive actions happen at times $t_i$ and $t_{i-1}$, then
for this time interval the total position hold by the LPs equals
$-Exp(t_{i-1})$ and the funding payment corresponding to all the LPs
are:
$$
\begin{aligned}
FP_{LP}(t_i) &= -Exp(t_{i-1}) \cdot \frac{Exp(t_{i-1})\cdot (t_i - t_{i-1})}{c\cdot L(t_{i-1})\cdot T}\\
&= -\frac{Exp^2(t_{i-1})\cdot (t_i - t_{i-1})}{c\cdot L(t_{i-1})\cdot T}
\end{aligned}
$$
Observe that it is always negative (i.e. LPs in
total will always receive and not pay funding fees-although some
individual LPs may happen to pay fees-) as expected.
- The extra difficulty in the computation of the funding payments of
LPs, compared to the funding payments for traders, is that an LP
position chaanges not only when the LP actively interacts with the
protocol, but also on every trade (since when a trader opens a
position, the LPs take passively the opossite position). We denote
by $FP_j(t_i)$ the total funding payments of the $j$ LP till time
$t_i$ (positive if he has to pay, negative if he should receive a
payment).
$$
\begin{aligned}
FP_j(t_i) &= FP_j(t_i-1) + (\textit{j LP's position size}) \cdot \Delta F(t_{i-1})\\
&= FP_j(t_i-1) + (x_j(t_{i-1})-d_j)\cdot \Delta F(t_{i-1})\\
&= FP_j(t_i-1) + x_j(t_{i-1})\cdot \Delta F(t_{i-1})-d_j\cdot \Delta F(t_{i-1})\\
\end{aligned}
$$
where $x_j(t_{i-1})$ is the vAsset balance of the j
LP at time $t_{i-1}$ and $d_j$ is his vAsset debt (the balance
constanlty change after each trade, but the debt changes only if the
LP interacts with the protocol). Recall that we can compute
effectively the liquidity of each LP at every time using the shares:
$$
\begin{aligned}
x_j(t_{i-1}) &= s{x,j}(t_{i-1})\frac{x(t_{i-1})}{S_x(t_{i-1})}\\
&= \left( M_{x,x}(t_{i-1})\cdot s_{x,j}(0) + M_{x,y}(t_{i-1}\cdot s_{y,j}(0)) \right) \cdot \frac{x(t_{i-1})}{S_x(t_{i-1})}
\end{aligned}
$$
Therefore:
$$
\begin{aligned}
FP_j(t_i) &= FP_j(t_i-1) + \frac{M_{x,x}(t_{i-1})\cdot x(t_{i-1})}{S_x(t_{i-1})}\Delta F(t_{i-1})\cdot s_{x,j}(0)+\\
&+\frac{M_{x,y}(t_{i-1})\cdot x(t_{i-1})}{S_x(t_{i-1})} \Delta F(t_{i-1})\cdot s_{y,j}(0) -d_j\cdot \Delta F(t_{i-1})
\end{aligned}
$$
Using matrices, this can be written as:
$$
FP_j(t_i) = FP_j(t_{i-1}) + [1 \quad 0]B(t_i)M(t_{i-1})\cdot \begin{bmatrix} s_{x,j}(0)\\s_{y,j}(0) \end{bmatrix} - d_j \cdot \Delta F(t_{i-1})
$$
where
$$
B(t_i) = \begin{bmatrix} \frac{x(t_{i-1}) \cdot \Delta F(t_{i-1})}{S_x(t_{i-1})} & 0 \\ 0 & 0\end{bmatrix}
$$
- Therefore we should store a global matrix sum (actually we need only
his first row -two sums-):
$$
G(t_i) = G(t_{i-1}) + B(t_i)M(t_{i-1})
$$
- Take two snapshots: $G(t_0)$, $F(t_0)$ whenever an LP deposits
liquidity (two extra snapshots along with the snapshot of the matrix
M, used for the computation of the shares). Whenever we want to
compute the total collected funding payments for the LP we use the
formula:
$$
FP_j=[1 \quad 0](G(t) - G(t_0))M^{-1}(t_0) \begin{bmatrix} s_{x,j}(0)\\ s_{y,j}(0)\end{bmatrix} - d_j\cdot (F(t) - F(t_0))
$$
## Liquidations
To maintain system solvency, positions must be liquidated when the ratio
of collateral to position value falls below a specified threshold.
Liquidation is the process by which a user's position is sold to another
participant at a discount. This discount acts as a fee imposed on the
liquidated user, incentivizing traders to maintain sufficient collateral
and avoid liquidation.
### Liquidation criteria
A position becomes eligible for liquidation based on its margin ratio
(MR), calculated as:
$$
\begin{aligned}
\textit{MR}=\frac{\textit{account value}}{\textit{position value}}
\end{aligned}
$$
where:
- *Account value*: The USD value of the deposited collateral minus the
total PnL for the position and any funding payments.
- *Position Value*: The size of the position multiplied by the index
price of the underlying asset. Here, the index price is a
time-weighted average of the market price over a few minutes (around
10 minutes). We should avoid using the actual (spot) market price to
avoid liquidations due to temporary price fluctuations.
We define several margin thresholds:
$$
\begin{aligned}
MM_1>MM_2>...>MM_n
\end{aligned}
$$
and corresponding percentages:
$$
\begin{aligned}
p_1
1. [M. Egorov, *StableSwap- efficient mechanism for stablecoin liquidity*](https://docs.curve.fi/assets/pdf/whitepaper_stableswap.pdf)
2. [M. Egorov, *Automatic market-making with dynamic peg*](https://docs.curve.fi/assets/pdf/whitepaper_cryptoswap.pdf)
3. [B. Krishnamachari, Q. Feng and E. Grippo, *Dynamic Automated Market
Makers for Decentralized Cryptocurrency Exchange*, 2021 IEEE
International Conference on Blockchain and Cryptocurrency (ICBC),
Sydney, Australia, 2021, pp. 1-2](https://anrg.usc.edu/www/papers/dynamicautomation.pdf)
4. [H. Adams, *Uniswap whitepaper*](https://hackmd.io/C-DvwDSfSxuh-Gd4WKE_ig#Introduction)
5. [*Funding rates:under the hood](https://medium.com/derivadex/funding-rates-under-the-hood-352e6be83ab)
**Disclaimer**\
\
\
**Educational and Scientific Purpose**: This whitepaper and all contents
herein are provided strictly for scientific, educational, and
informational purposes only. The technical designs, financial models,
and mechanisms described in this paper represent theoretical constructs
and should not be interpreted as financial, investment, legal, or tax
advice.\
**Intellectual Property Notice**: The implementation of Denaria's design
into smart contracts is protected under a Business Source License. To
learn more about the Business Source License visit mariadb(dot)com.\
**No Guarantees or Warranties**: The information provided in this paper
is presented \"as is\" without any representations or warranties,
express or implied. Denaria makes no guarantees regarding the accuracy,
completeness, timeliness, suitability, or validity of the information
contained herein. All forward-looking statements, projections, or future
plans mentioned in this document are speculative in nature.\
**Risk Disclosure**: Decentralized finance (DeFi) protocols,
particularly those involving perpetual derivatives, carry significant
risks including but not limited to: smart contract vulnerabilities,
market volatility and liquidation risks, regulatory uncertainty, oracle
failures or manipulations, economic design flaws, and governance
attacks. Users and developers who choose to interact with any
implementation of the designs described in this paper do so entirely at
their own risk.\
**Regulatory Compliance**: This paper does not constitute an offer to
sell, a solicitation of an offer to buy, or a recommendation of any
cryptocurrency, digital asset, or any other financial instrument. Users
must ensure their compliance with all applicable laws and regulations in
their respective jurisdictions before interacting with any
implementation of the designs described.\
**Independence of Action**: No part of this document should be
interpreted as encouraging or soliciting any person to engage in any
action or transaction. All decisions related to the use of any protocol
or product derived from this paper should be made independently after
conducting appropriate due diligence.\
**Living Document**: This whitepaper is subject to updates,
modifications, and amendments without prior notice. Readers are
responsible for ensuring they are reviewing the most current version.