Levana Well-funded Perpetuals - high level overview

This document provides a high level overview of the Levana Well-funded Perps (hereafter: perps or Levana perps) system. It is intended to be read by people already familiar with the general concept of perpetual swaps platforms, and will focus on the distinguishing characteristics.

You may want to first review the glossary.

The problems we're solving

Levana Perps started from trying to solve a fundamental problem common in other perps platforms: the risk of illiquidity. In most perps platforms, traders going long are betting against traders going short. When the price moves upward, long positions take profits from short positions, and vice-versa. If longs and shorts remain balanced within the platform, then each side has sufficient liquidity to guarantee their profits.

However, as we have seen historically, this assumption of balanced markets is not always met. This is especially true in extreme market conditions, such as a market meltdown. In such a case, we may see far greater short positions than longs, and the protocol may be unable to honor profits for those positions due to insufficient liquidity.

Solving this problem drives the majority of the unique features within Levana perps. Keeping this risk in mind will help you understand why the protocol works the way it does.

A secondary issue we strive to address is market manipulation. In tradition vAMM/mark price perps platforms, position entry and exit prices are based on a mark price within the protocol. When there is low volume within the protocol, it becomes easier for traders to significantly move the mark price, allowing them to force-liquidate counter-traders and extract profits risk-free. Our design attempts to make Levana Perps a protocol that works for both a low volume perps protocol, and for smallcap coins, as well.

The solutions

There are two fundamental shifts in Levana perps versus traditional perps platforms

Locked liquidity

Instead of longs and shorts taking profits from each other and risking illiquidity, the protocol introduces the concept of liquidity providers (LPs). LPs provide assets that can be locked by traders against their positions. That locked liquidity represents the maximum gains a trader can achieve on a given position. Markets can be created in both stablecoin and crypto-denominated pairs. Crypto-denominated pairs have no capped gains for long positions. Stablecoin denominated pairs include capped gains to ensure all positions are fully collateralized at all times. Capped gains is a downside versus other perps platforms (but see crypto-denominated pairs for a mitigation), but ensures that all positions are, at all times, fully collateralized.

Additionally, the introduction of LPs into the protocol provides a relatively low-risk (though not risk-free) method for passive income.

Another advantage to having fully collateralized, well-funded positions is that it obviates the need for off-chain liquidation bots. Alternative perps platforms must make use of high availability, off-chain services to perform just-in-time liquidations in order to keep illiquidity to a minimum. In contrast, Levana perps is able to perform on-chain liquidations, thereby reducing its reliance on external services.

No mark price

Levana perps does not maintain an internal mark price concept. Instead, the spot market price is used for entry price and calculation of PnL within the system. This allows the protocol to remain stable even with little internal volume. It also avoids issues found with the more common vAMM approach to mark price perps, such as needing to choose an initial mark price and drifting further away from it as the spot price changes over time.

Funding payments are still used to encourage cash-and-carry arbitrage to balance out the protocol. However, instead of being based on a mark/spot price divergence, funding payments are now based on the net notional or total difference in long vs short position sizes.

Additionally, Levana perps introduces a concept called a delta neutrality fund to further incentivize a balanced protocol. Unlike funding payments, the delta neutrality fund takes lump-sum payments at position open, update, and close. Actions that push the protocol closer towards neutral receive a payment from the fund, and actions that push the protocol away from neutral pay into the fund.

Crypto denominated pairs

In addition to the problems described above, Levana perps attempts to address two additional issues:

  1. We would like to support chains that do not have easy access to reliable stablecoins. In such chains, a trading pair like ATOM/USD would generally be difficult for users to interact with due to lack of access to a USD-denominated coin.
  2. The limitation on capped max gains via stablecoins may limit use cases for some traders that would prefer to realize infinite gains on their positions, crypto-denominated pairs enables this.

To address both points, we introduce the concept of a “crypto denominated pair.” The underlying mechanism we use for such crypto denominated pairs is a "collateral-is-base" market, which is described further in our slides. By contrast, a stablecoin-denominated market would be called "collateral-is-quote."

In a “collateral-is-quote” perps market, the base asset (e.g. ATOM) is priced in terms of the quote asset (e.g. USDC), and traders deposit USDC to trade.

In a crypto-denominated pair, we flip this around. From a user perspective, we still talk about ATOM and USD as base and quote, respectively. However, the user deposits ATOM instead of USD. This addresses point 1: Levana perps can host a trading pair on a chain so long as either the base or quote assets are supported on that chain.

The second point requires a bit more of an explanation.

Infinite max gains

Suppose we have a stablecoin based market for ATOM/USDC. The trader wants to open up a long position on ATOM. The trader will:

  • Establish an entry price, let’s say 10 USDC per ATOM
  • Deposit some amount of collateral, let’s say 200 USDC, equivalent to 20 ATOM
  • Set a max gains and lock some counter collateral from the liquidity pool. Let’s say this is 400 USDC. This establishes a max gains for the trader on this position of 200% (they deposited 200 USDC and could maximally walk away with 600 USDC, taking a 400 USDC profit).

Now, instead, let’s consider the situation where the trader is interacting on a market with ATOM as collateral, not USDC:

  • Instead of depositing 200 USDC, the trader deposits 20 ATOM
  • Similarly, instead of locking 400 USDC from the liquidity pool, the trader locks 40 ATOM

In such a case, the maximum collateral the trader can walk away with is 60 ATOM (20 deposit collateral + 40 counter collateral). This would appear initially to be the same as the 600 USDC described in the stablecoin market scenario.

However, PnL is not denoted in terms of ATOM. Instead, PnL is denoted in terms of the quote asset, or in this case USD. Since the trader opened a long position, the value of the collateral (ATOM) will continue to rise as long as the price rises.

In this case, the trader would like to tell the protocol to simply not provide a max gains price and allow a position to remain open regardless of how high the price goes. This would allow the trader to realize infinite profits in terms of USD. The protocol therefore allows a setting of “infinite max gains”, which skips the max gains price.

Note that this is only possible with long positions in markets where the base asset is used as collateral. When the quote asset is used as collateral, or for short positions, infinite gains are not possible.

Flipped leverage

The public interface of the system speaks about base and quote almost exclusively. Traders denote their leverage in terms of base (e.g. ATOM). Internally, the system works almost exclusively in terms of the notional and collateral assets. In essence, the system behaves as if the trader is depositing collateral to speculate on price movements of notional.

For traditional markets where base is notional and quote is collateral, this all lines up as expected. For example, with ATOM/USDC, the trader deposits USDC and opens a long position, hoping that the price of ATOM relative to USDC goes up. The system sees this as a long position with positive leverage.

However, in a crypto-denominated market like ATOM/USD, we turn all of this around. The collateral is now ATOM, and therefore the notional asset is USD. Internally, the protocol views everything as speculation of the price of USD in terms of ATOM. To understand how flipped this is, consider this table:

Standard ATOM/USDInverse price USD/ATOM
$16/ATOM0.0625 ATOM/USD

As the price of ATOM goes up, this is equivalent to the price of USD relative to ATOM going down, and vice-versa. Therefore, opening up a long position on ATOM is equivalent to opening up a short position on USD.

When receiving an order to open a position from a trader, the protocol accepts the leverage value in terms of the base and quote assets. It then converts that leverage number depending on whether collateral is base or quote. In a “standard” collateral-is-quote setup, the leverage is unchanged. In a “flipped” collateral-is-base setup, a long leverage is converted to short and vice-versa.

Complex side point: the simplest way to do this conversion is to simply negate the number: a 5x long position on ATOM becomes a 5x short position on USD. This turns out to introduce non-linear gains, because the trader is still exposed to price movements of ATOM by holding onto some ATOM as collateral. Instead, the formula we use is leverage-in-quote = 1 - leverage-in-base to account for that exposure. Therefore, if the trader opens a 5x long in a flipped market, internally this turns into a 4x short, or a leverage-in-notional of -4. This is discussed in more detail in our slides.


When a position is open, we calculate a number of parameters for the position. We first deduct the trading fees and any payments to or from the delta neutrality fund from deposit collateral. Then, we determine the maximum amount of fees the position may incur over the next period of time (the liquifunding delay plus staleness period) and set that aside as the liquidation margin. We then determine, based on the remaining active collateral, at what price point the position would become illiquid (the liquidation price) and when it would have achieved maximum gains (the max gains price). We set these values in liquidation data structures to be used by cranking. We also schedule a next liquifunding to occur after liquifunding_delay.

Later, the position will be liquifunded, either because of cranking or because the user attempts to update or close the position. At this point, the protocol needs to calculate how many fees and funding payments have been incurred since the last liquifunding and update active collateral. It also updates active collateral to reflect price exposure, meaning changes resulting from price movements. If the price moves in the direction of the position, active collateral goes up, otherwise it goes down.

NOTE Following on our well-funded concept: each position has locked counter collateral from the liquidity pool. When active collateral goes up due to price movement, the counter collateral goes down in the same amount, and vice-versa.

We then perform the liquidation margin calculation again. If there are insufficient funds for a liquidation margin, the position is closed. If max gains have been achieved, the position is closed. Otherwise, the new parameters are updated, new liquidation and max gains prices are set for cranking, and a new next liquifunding is scheduled.

NOTE: an interesting side-effect of the active collateral changing from liquifunding is that the leverage of a position will change over the course of its lifetime. The leverage will go down as the price moves in the direction of the position and funding payments are received. The leverage will go up as the price moves against the position and funding payments and borrow fees are paid.

Price updates

The protocol receives price updates via a permissioned entrypoint in the protocol. This entrypoint delivers the current price of the base asset in terms of the quote asset. The protocol stores this in a collection of previous price points and then performs a crank.

Note that the address approved to set the price can either be a wallet or a smart contract. Using a wallet essentially means that a trusted backend service will directly update oracle price into the market. By contrast, if the chain Levana perps is running on hosts a trusted third-party oracle, a smart contract solution can be deployed which will query the current price from the oracle and submit it to the perps contract. This allows the perps protocol to remain agnostic to where prices come from, and proactively perform tasks on a push-basis of prices being injected, rather than needing a pull-based model for querying for new prices.

In practice, production deployments of Levana perps currently all use the Pyth price oracle for price data, and a companion pyth_bridge contract acts as the permissioned price admin. This setup allows anyone to permissionlessly update the price in the Pyth oracle (using cryptographic proofs from the Pyth network) and then trigger the pyth_bridge to update the market with the new price.


The crank process is responsible for running scheduled tasks and performing tasks (like closing liquidatable positions) based on price triggers. Cranking works by going through all price updates and performing operations for each price update point:

  • Looks for any positions with a scheduled liquifunding in the past and performs the liquifunding process on it
  • Looks for any positions with price triggers that are hit by the new price update. For example, if a long position has a liquidation price of $7 and a price update sets the price to $6, the position should be closed as liquidated.

After all actions are taken for the given price update, the crank sets the “last crank complete” to the timestamp of that price update and continues.

Once all liquifundings are completed and we have caught up to the latest price point, the protocol does not require any cranking. A query endpoint is available to check if crank work is available, and bots run regularly to perform cranking when work is available. In the future, we intend to provide incentivization for third parties to run crank bots.

Note that cranking is a permissionless process. It also involves some other corner-case maintenance activities on the protocol, like market wind-down "close all positions" and resetting LP balances on full liquidity withdrawal. However, these aren't core to the understanding of the system.


The protocol relies on timeliness on two fronts:

  • Price updates. If price updates are blocked to the system (such as by DDoS attacking an oracle), an attacker would be able to open a position based on knowing with certainty the current spot price and its discrepancy from the last price update in the system.
    • Example: suppose the current price of ATOM is $10, and an attacker suspects the price will rise to $15. The attacker could simply open a long position, but that incurs risk that the price could actually go down. Instead, the attacker DDoS attacks the oracle, preventing any price updates into the system. The attacker can then observe the real movement of the spot price. If, as expected, the price moves to $15, the attacker can then open a long position (locked into the last price update of $10) and halt the DDoS attack on the oracles, allowing the protocol to see the new $15 price and realizing a large profit.
  • Liquifunding. Liquifunding is the process that ensures that all open positions have sufficient liquidation margin to cover potentially incurred fees. If we go beyond the staleness period of a position, it may become insolvent, breaking our well fundedness goals.

To address both concerns, the protocol introduces the concept of staleness. If a price update has been delayed for too long a period, or if any position has reached the point where liquidation margin cannot be guaranteed, we become stale. When stale, the protocol will not allow positions to be opened, updated, or closed, or limit orders to be placed. To exit a stale period, price updates must come into the system and/or cranking be performed.

Under normal conditions, with a functioning blockchain, functioning oracle, and functioning crank bots, the protocol should never reach staleness. This is an extreme condition that indicates something has broken and the protocol needs to protect traders and liquidity providers.


Congestion is similar in behavior to staleness, but derives from a different source. Consider this sequence of events:

  1. Price is updated in protocol to $8, and the crank is fully run.
  2. Price is updated to $9, but the crank does not fully run because of a large number of liquifundings.
  3. Price is updated again to $10, but the crank still hasn't finished processing the $9 price update.
  4. A trader opens a long position at the (correct) entry price of $10, and ends up with a liquidation price of $9.
  5. The crank finally moves past the liquifundings for the $9 price update in (2) and begins running price triggers (liquidations, take profit, etc.). It sees that the position opened in (4) should be liquidated at the price of $9 and closes it out.

This last step is a bug. The position had an entry price of $10, and that price landed after the $9 price we're currently cranking. We should not liquidate positions based on old prices.

To address this, we have the "pending price triggers" queue. If our crank ever falls behind on a price update, we place new positions' trigger prices on a queue and only add them to the price trigger tables after liquidations for that entry price have been fully processed. The downside of this queue is that the work items for opening and updating positions are doubled: we now need both a transaction to open/update the position, and another one to crank the position's price trigger to pop it from the "pending price triggers" queue and move it to the price trigger tables.

A potential attack vector would be forcing the protocol to fall behind on cranking (such as by DDoS attacking the crank bots) and then flood the system with open and update position messages, causing a large stream of work for the crank. An attacker could continuously update existing positions to keep putting them back onto the queue, causing the crank to never fully catch up.

To mitigate this, we introduce the concept of congestion. Once the pending queue reaches a certain size (by default, 500), we disallow opening or updating positions.

Like staleness, under normal circumstances this situation should never arise. However, by providing a congestion mechanism, we prevent any bug in the system or attack on the system from spiraling out of control.

Price triggers

The protocol automatically determines a liquidation and max gains price for a position at each liquifunding. Additionally, a user may set trigger prices for stop loss and take profit to avoid complete liquidation or to take profits early. These price triggers are observed by the crank mechanism, and positions are closed. Note that if a liquidation price hits before a stop loss, or a max gains hits before a take profit, the liquidation or max gains prices will be used.

Liquidity pool

A core feature of Levana perps is locked liquidity, which is provided by the liquidity pool. A liquidity provider can deposit collateral into the pool and receive LP tokens in exchange. These LP tokens can be burned to receive back collateral. If there is insufficient collateral available, the liquidity provider will need to try to withdraw liquidity later.

Instead of receiving LP tokens, liquidity providers can opt to receive xLP tokens. These xLP tokens cannot be immediately burned for collateral. Instead, xLP can be converted into LP tokens. This is a time-based conversion process that occurs linearly over 45 days. In other words, if you unstake 450 xLP tokens, after the first day you’ll have 10 LP tokens available, after the second day 20, and so on. Providers are rewarded with higher rates of return, and the protocol benefits by having more gradual liquidity withdrawals, making it less likely that there will be no available unlocked liquidity.

LP and xLP token holders receive pro-rata portions of the trade and borrow fees paid by traders. As mentioned above, xLP token holders will receive higher portions overall as an incentive.

The utilization ratio within the protocol is the percentage of collateral in the liquidity pool that is currently locked to a position. The higher the utilization rate, the higher the borrow fee will be. This provides a free-market incentive structure for setting the borrow fee naturally. If the borrow fee is too low, providers will not deposit collateral, leading to a higher utilization rate and higher fees. If the fee is too high, more providers will deposit collateral, leading to a lower utilization rate and lower fees.

The goal of the protocol is to protect providers from market movements. There are essentially two kinds of market movements that present a risk to liquidity providers:

Normal market movement

Under normal market movement conditions, the price moves in a “reasonable” timeframe up and down. The risk to liquidity providers is that, when a trader opens a position, the LPs are essentially forced to take an opposite side position. To make that concrete, consider a situation where everyone anticipates a 5% rise in the price of ATOM. Traders will flock to the system, opening large numbers of long positions, and liquidity will be locked as counter collateral. That counter collateral will be lost if the market goes up, essentially meaning LPs are taking a short position.

The problem here is that the longs far outweigh the shorts. If, instead, there was an equal amount of short and longs (i.e., the protocol’s net notional was balanced, a.k.a. we were delta neutral), LPs would face no risk: a positive price move would lose LPs money on the long positions, but would make back equivalent money on the short positions.

To protect LPs, the protocol has two mechanisms in place:

  • Like most perps platforms, funding payments incentivize arbitrageurs to open cash-and-carry positions. If longs are more popular than shorts, an arbitrageur can open a short position in the perps platform, receive funding payments, and simultaneously open a long position in the spot market. The arbitrageur is now neutral on price movements, but receives a funding payment regardless. Similarly, assuming the presence of an external platform supporting shorts (e.g., a traditional options market), the arbitrageur can counter the protocol being overly short by opening long positions and opening short positions externally.
  • The protocol introduces the concept of the delta neutrality fund. As the protocol veers further and further away from delta neutral, actions that exacerbate the imbalance will pay a fee into the fund, and actions that bring the protocol closer to neutral receive a payment from the fund. At the extreme, delta neutrality capping will prevent opening new positions or updating existing positions. (Closing positions is always allowed, even if it pushes the protocol further beyond the caps.)
    • Note that, to prevent price manipulation attacks from being successful, we charge a tax (by default, 5% for most markets) on payments into the delta neutrality fund. This means that, even if an attacker could manipulate the spot price of an asset, each iteration of draining liquidity from the protocol would involve losing a portion of the profits to the delta neutrality fund. The 5% tax number increases the more susceptible an asset is to spot price manipulation (e.g., low spot volume coins will have a higher tax).

️️⚠️ Normal market risks

WARNING: Liquidity providers are subject to a real risk of impairment, where the value of their LP and xLP tokens in terms of the underlying collateral asset may go down over time. This will occur if the market is imbalanced and traders are successful overall. (By contrast, if the market is imbalanced and traders are unsuccessful in their trades, liquidity providers will benefit.) Liquidity providers can judge their exposure to this risk by observing the net notional, or the difference between long and short open interest. If there are more longs, liquidity providers will experience impairment if the price goes up, and if there are more shorts, they will experience impairment if the price goes down.

Delta neutrality ratio is another helpful parameter to look at. It reflects the price exposure risk of liquidity pool relative to its size. It is calculated at net notional divided by liquidity pool size. This will effectively express that as the size of the pool increases, the impact of a constant-size net notional imbalance will be reduced.

As the Levana Perps platform grows over time, cash-and-carry activity will yield higher rewards and net notional is expected to move closer to 0 (a neutral platform). During the bootstrapping phase of the protocol, there is expected to be more volitility and therefore more risk. The natural mechanism for addressing this is higher borrow fees from liquidity pool utilization that is higher than target utilization, which will reward providers for their assumed risk (and impairment losses) with higher APRs.

Extreme market movement

While normal market price movements are mostly addressed by the above mitigations, extreme market conditions are not. This is the primary risk undertaken by liquidity providers. Consider a case where the price of an asset collapses from $120 to $0.01. While that may seem extreme, one could imagine a scenario where that could happen.

In such a situation, we can assume that traders would stop opening long positions and would all try to open short positions. Pretty soon, delta neutrality caps would prevent further short positions from being opened, so we would be left with a market with some longs and lots of shorts. The longs would likely attempt to close their positions, which is allowed even in the presence of delta neutrality capping. We would now be left with a protocol almost 100% weighted towards shorts.

At this point, liquidity providers would likely be concerned for their investment and would attempt to burn their LP tokens, freeing their liquidity. Unfortunately, there will not be enough unlocked liquidity for all the providers trying to withdraw their liquidity. So we’ll be left with a significant portion of liquidity locked as collateral on short positions, essentially forced to take long positions that they cannot exit.

As the meltdown occurs, the short positions will begin to achieve max gains and capture the entirety of the counter collateral. In a crypto-denominated market, the risk asset itself is becoming worthless, but liquidity providers were prevented from selling the asset by the protocol. But in a stablecoin denominated market, the liquidity provider’s stablecoin is still valuable, and they have lost virtually all of it.

This is the risk liquidity providers need to be aware of when depositing in pools: in a market meltdown (or, equivalently, in a meltup) their deposited collateral can be almost entirely lost. Therefore, more volatile markets should demand a higher borrow fee to compensate for the increased risk assumed.