# Table of Contents

- [Introduction | Perpl Docs](#introduction-perpl-docs)
- [Order Book | Perpl Docs](#order-book-perpl-docs)
- [Architecture | Perpl Docs](#architecture-perpl-docs)
- [Margin | Perpl Docs](#margin-perpl-docs)
- [Liquidation | Perpl Docs](#liquidation-perpl-docs)
- [Fees | Perpl Docs](#fees-perpl-docs)
- [Insurance & ADL | Perpl Docs](#insurance-adl-perpl-docs)
- [Price Indices | Perpl Docs](#price-indices-perpl-docs)
- [Order Types | Perpl Docs](#order-types-perpl-docs)
- [Trading Perpetuals on Perpl | Perpl Docs](#trading-perpetuals-on-perpl-perpl-docs)
- [Funding | Perpl Docs](#funding-perpl-docs)

---

# Introduction | Perpl Docs

### 

[](https://docs.perpl.xyz/#what-is-perpl)

What is Perpl?

Perpl is a high-performance, decentralized, perpetual futures (perps) exchange handcrafted for Monad EVM. Monad is an open, permissionless, geographically distributed blockchain (L1) that provides fast finality and 100% EVM-compatibility.

Perps just need a price oracle and a stablecoin for margin. They allow traders and speculators to take positions in crypto assets with leverage. Unlike traditional derivatives, they don't have an expiration, which fosters deeper liquidity in markets. See our blog on [perpetual future contracts](https://blog.perpl.xyz/what-are-perps-perpetual-futures-contracts/)
.

### 

[](https://docs.perpl.xyz/#why-another-perp-dex)

Why another Perp DEX?

Centralized exchanges (CEX) and decentralized exchanges (DEX) are the two types of exchanges that offer perps. CEXs have good UX, but have onerous KYC/AML requirements and custodial risk. DEXs are self-custodial and enable global, permissionless trading, but they have relied on slower, decentralized infrastructure. See our blog on the differences between [decentralized vs. centralized exchanges](https://blog.perpl.xyz/decentralized-vs-centralized-exchanges/)
.

The early DEX era was dominated by AMMs, not because they were better, but because L1 infrastructure couldn’t support performant order books. Teams eventually pivoted to “app-chains” to run central limit order books (CLOBs). However, they couldn’t enter new markets as quickly as CEXs because they relied on external MMs. See our blog on the differences between [AMMs vs. CLOBs](https://blog.perpl.xyz/order-books-vs-automated-market-makers-amms/)
.

![](https://docs.perpl.xyz/~gitbook/image?url=https%3A%2F%2F809468657-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FXVKhDpsjDZo7VFt2Qfew%252Fuploads%252Fz4JKCUgMcHMslImp9Z2x%252Fimage.png%3Falt%3Dmedia%26token%3D05fa827b-5aaa-419c-b494-268b492364d6&width=768&dpr=4&quality=100&sign=dd8f5901&sv=2)

Pooled liquidity vaults, pioneered by GMX (GLP), provide liquidity to AMM-based markets with relatively simple strategies. However, CLOB-based perp DEXs require active liquidity management. This is where Hyperliquid's HLP changed the game for bootstrapping CLOB-based perp DEXs.

However, there are centralized points of failure and other risks when a single team operates the exchange, vault, and blockchain. We believe the optimal combination is a performant on-chain DEX built on a standalone high-throughput L1, and bootstrapped by independently operated vaults.

### 

[](https://docs.perpl.xyz/#true-decentralization-optimal-ux)

True Decentralization, Optimal UX

The holy grail of DeFi is **a fully on-chain perp DEX with CEX-like trading experience on EVM**. Perpl, built on the Monad L1, is positioned to achieve this ideal while honoring the boundaries between protocol, liquidity, and infrastructure.

Unlike other DEXs on L1s that use AMMs or off-chain matching, everything on Perpl happens on-chain. The exchange, matching, and settlement runs **entirely on-chain with no off‑chain or centralized points of failure**. See our blog on [on-chain perps](https://blog.perpl.xyz/onchain-perps-balancing-profit-vs-peril/)
.

![](https://docs.perpl.xyz/~gitbook/image?url=https%3A%2F%2F809468657-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FXVKhDpsjDZo7VFt2Qfew%252Fuploads%252FVFiEe80ZEZyU9vV7DyAU%252Fimage.png%3Falt%3Dmedia%26token%3D8e8ddec2-09b9-42c2-a432-e1b137756dcb&width=768&dpr=4&quality=100&sign=e8585682&sv=2)

Building a DEX is hard; building a DEX on a blockchain you don't control/operate is even harder. However, we're building Perpl to be anti-fragile, scalable, and to leverage the benefits of composability. We have hyper-optimized the exchange on a specific vector: <100k gas for market-maker post+cancel. Every GWEI of gas matters because more gas costs = fewer market maker updates = wider quotes = worse fills for the end-user.

![](https://docs.perpl.xyz/~gitbook/image?url=https%3A%2F%2F809468657-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FXVKhDpsjDZo7VFt2Qfew%252Fuploads%252FzU4pPELdwEPi8DHopKxq%252Fimage.png%3Falt%3Dmedia%26token%3D4a1cb348-4bc0-495b-9525-77bdb975f5fa&width=768&dpr=4&quality=100&sign=35762406&sv=2)

[NextArchitecture](https://docs.perpl.xyz/exchange/architecture)

Last updated 11 days ago

---

# Order Book | Perpl Docs

The order book is a real-time on-chain record of all open buy and sell orders for any given market.

*   **Limit Orders**: Rest on the book until matched or canceled. Specified with price and quantity.
    
*   **Market Orders**: Execute immediately against the best available orders in the book
    
*   **Priority**: Orders are matched based on best price first, then earliest submission time
    
*   **Visibility**: the order book is entirely on-chain, meaning anyone can verify the order state at any time without relying on a central operator.
    

#### 

[](https://docs.perpl.xyz/exchange/order-book#architecture)

Architecture

Our order book is the most gas-performant primitive achievable on EVM. A post-and-cancel order costs 100k gas, including solvency checks. For context, a simple Uniswap V2 AMM swap costs 200k gas.

The key design objective was to minimize gas for market maker post + cancel, as that is the most common operation. Perpl achieves O(1) constant time for post, O(1) constant time for cancel, and O(N) linear time for matching.

![](https://docs.perpl.xyz/~gitbook/image?url=https%3A%2F%2F809468657-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FXVKhDpsjDZo7VFt2Qfew%252Fuploads%252FdlunUoW3HyojD6Z36Bqh%252Fimage.png%3Falt%3Dmedia%26token%3D8868848e-649a-4b77-bb57-0378e97df70c&width=768&dpr=4&quality=100&sign=9a012f2e&sv=2)

Figure 1: Order book design consisting of two bit-index trees and a partition map list

#### 

[](https://docs.perpl.xyz/exchange/order-book#price-levels)

Price Levels

The order book is extremely granular, allowing for more than 16M price levels, so large assets like Bitcoin can be potentially quoted in dimes ($0.10) increments. One bit-index tree is a three-level, 256-bit-word index of prices that contain orders in the partition map list. It allows for quick discovery of the next price above or below a specified price in a gas-efficient manner.

![](https://docs.perpl.xyz/~gitbook/image?url=https%3A%2F%2F809468657-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FXVKhDpsjDZo7VFt2Qfew%252Fuploads%252F5Kv2EdwhT1xt6FXt4k9b%252Fimage.png%3Falt%3Dmedia%26token%3D83c5e890-9276-43ad-bcc8-1ff5c687a091&width=768&dpr=4&quality=100&sign=1d22df38&sv=2)

Figure 2: Bit-Index tree with 4-Bit words showing 64 price-levels mapped to start at $100.0 in increments of $0.5.

#### 

[](https://docs.perpl.xyz/exchange/order-book#order-ids)

Order IDs

The other bit-index tree is a two-level, 256-bit-word index of order IDs, allowing more than 65k orders per contract. It also functions as an order ID counter for the perpetual contract’s CLOB, assigning unique order IDs to each new order.

To mitigate DDoS attacks on the order book, we have designed a permissioned order cancellation system. When the number of available orders falls below a given threshold, the backend can cancel orders that are a configurable distance from the maximum bid or minimum ask prices.

![](https://docs.perpl.xyz/~gitbook/image?url=https%3A%2F%2F809468657-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FXVKhDpsjDZo7VFt2Qfew%252Fuploads%252Ff5t0vHvklpSy9G4xC7Ln%252Fimage.png%3Falt%3Dmedia%26token%3Df4f39b98-f9f3-4f46-b607-112004cd1d7c&width=768&dpr=4&quality=100&sign=8485e215&sv=2)

Figure 3: Order book bid and ask levels showing region where permissioned cancel is possible when number of orders exceeds permissionless cancel threshold.

#### 

[](https://docs.perpl.xyz/exchange/order-book#time-in-force-expiry-blocks-and-recycle-fees)

Time in Force: Expiry Blocks and Recycle Fees

For non-immediate orders, the time in force can be specified with an expiry block, so the order automatically expires after the specified block. Orders with an expiry block require the issuer to pay an order recycling fee. This fee is refunded if the order is completely filled or canceled by the issuer.

If the order has expired and another market participant encounters the expired order in a traversal of the order book, the recycling fee is paid to this participant as compensation for clearing the order. Recycling fees can be configured at run time and changed during operation.

The ability to change recycling fees allows tuning the incentive to match current market conditions — higher recycling fees when many orders are impeding market transactions or when gas costs are high.

#### 

[](https://docs.perpl.xyz/exchange/order-book#change-order-efficient-cancel-post)

Change Order: Efficient Cancel-Post

Market makers can quote orders with tighter spreads—the distance between the bid and ask prices—when the cost of canceling and reposting orders is reduced. Tighter spreads are attractive because they mean that the DEX is better able to compete with centralized solutions on price.

As prices move, market makers cancel existing orders and post new ones to follow price movements. This is inefficient in an on-chain exchange because it implies deallocation of storage for the canceled order and allocation of new storage for the newly posted order. Figure 1 above shows how order storage and order IDs can be shared across different price levels, from m+4 down to m-3.

Shared storage allows order storage to be moved to effect a price change, rather than being inefficiently deallocated and subsequently reallocated. Rather than submitting two transactions, a single transaction, “Change”, replaces Cancel and Post transactions.

If the market maker is only changing the lot size or expiry block of an order, then the operation uses less gas as it does not need to move the order storage to a new partition. The change operation would move the order to the end of the current price partition's list if the order's lot size is increased or the expiry block is changed (the order is not moved to the end of the list if the lot size is decreased).

[PreviousArchitecture](https://docs.perpl.xyz/exchange/architecture)
[NextMargin](https://docs.perpl.xyz/exchange/margin)

Last updated 0 minutes ago

---

# Architecture | Perpl Docs

Perpl’s protocol architecture consists of multiple on-chain systems that work in tandem to deliver the highest-quality perp trading experience.

![](https://docs.perpl.xyz/~gitbook/image?url=https%3A%2F%2F809468657-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FXVKhDpsjDZo7VFt2Qfew%252Fuploads%252FDe5GC13pb5yPQbsdnmPM%252FperpsOnly.png%3Falt%3Dmedia%26token%3D9c41717b-10fe-4d36-b3f8-75e47a1641f0&width=768&dpr=4&quality=100&sign=1f31eb7d&sv=2)

These systems include:

1.  **Order book**: to match buy and sell orders using price-time priority. Every trade is matched and settled on-chain.
    
2.  **Margin**: validates collateral, ensuring that traders always have sufficient funds to open and maintain a trade.
    
3.  **Liquidation System**: continuously monitors positions and triggers liquidation when accounts fall below maintenance margin.
    
    1.  **ADL & Insurance Fund**: protects protocol from large trading anomalies and helps protect traders from large market fluctuations.
        
    
4.  **Funding Rate**: periodic (hourly) payment exchanged between long and short traders to ensure that the price of the perp aligns with the actual price index of an asset.
    
5.  **Price Index**: aggregate and process external spot price data from multiple exchanges to generate an accurate index price.
    

We will dive deeper into each of these concepts in the rest of the documentation.

[PreviousIntroduction](https://docs.perpl.xyz/)
[NextOrder Book](https://docs.perpl.xyz/exchange/order-book)

Last updated 10 days ago

---

# Margin | Perpl Docs

The margin engine ensures that users who place trades always have the necessary capital requirements to open and maintain their intended positions.

*   **Initial Margin**: The amount required to open a position; calculated as a percentage of notional value based on the asset’s risk profile.
    
*   **Maintenance Margin**: Minimum collateral required to keep a position open; if breached, liquidation is triggered
    

Initial margin requirements on Perpl are dynamic and may vary by market, depending on volatility and position size.

### 

[](https://docs.perpl.xyz/exchange/margin#margin-mode)

Margin Mode

The difference between a cross and an isolated margin is:

*   **Isolated Margin**: Each position has its own margin
    
*   **Cross Margin**: All collateral in the account is shared across positions
    
*   **Hybrid Margin**: Manually manage margin between positions
    

To begin with, Perpl will be restricted to isolated margin.

![](https://docs.perpl.xyz/~gitbook/image?url=https%3A%2F%2F809468657-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FXVKhDpsjDZo7VFt2Qfew%252Fuploads%252FT0Wu8pWV98wymIzdfmLk%252Fimage.png%3Falt%3Dmedia%26token%3D3394098b-112d-466d-9014-73f294aa976f&width=768&dpr=4&quality=100&sign=a8167578&sv=2)

### 

[](https://docs.perpl.xyz/exchange/margin#position-equations)

Position Equations

Perpetual contracts can be implemented using the following representation of lot sizes, L:

*   {L : L > 0, L ∈ Z}
    

#### 

[](https://docs.perpl.xyz/exchange/margin#position-notional-value-n)

**Position Notional Value,** _**N**_**:**

N\=P⋅LN = P · LN\=P⋅L

_P = The mark, entry, or realized price, depending on whether or not the value being calculated is unrealized, position, or realized notional value, respectively. L = The position lot size (the number of contracts of the position)._

#### 

[](https://docs.perpl.xyz/exchange/margin#position-margin-requirement-mr)

**Position Margin Requirement,** _**MR**_**:**

MR\=N/MFMR = N/MFMR\=N/MF

_N = The position notional value. MF = The margin fraction (analogous to leverage)._

#### 

[](https://docs.perpl.xyz/exchange/margin#position-initial-margin-requirement-imr)

**Position Initial Margin Requirement,** _**IMR**_**:**

IMR\=N/IMFIMR = N/IMFIMR\=N/IMF

_N = The position notional value. IMF = Initial margin fraction (maximum leverage allowed to open a position)._

#### 

[](https://docs.perpl.xyz/exchange/margin#position-maintenance-margin-requirement-mmr)

**Position Maintenance Margin Requirement,** _**MMR**_**:**

MMR\=N/MMFMMR = N/MMFMMR\=N/MMF

_N = The position notional value. MMF = Maintenance margin fraction (minimum collateralization permitted before a position can be liquidated)._

### 

[](https://docs.perpl.xyz/exchange/margin#margining-criteria)

Margining Criteria

The price used to determine the notional value in the invariants presented in this section is the most accurate price available. For example, the best price to use for the notional value of a new position is the price at which the position is entered (realized).

In some situations, for example, auto-deleveraging a position, a realization price is not available, and the failed position’s bankruptcy price is used. In other situations, the mark or synthetic perpetual price may be used to calculate the position's fair market value (for the value of an existing position).

#### 

[](https://docs.perpl.xyz/exchange/margin#collateralization-for-establishing-or-changing-a-position)

Collateralization for establishing or changing a position:

FMV\>\=IMRFMV >= IMRFMV\>=IMR

_FMV = Position fair market value. IMR = Position initial margin requirement._

#### 

[](https://docs.perpl.xyz/exchange/margin#collateralization-for-liquidation)

Collateralization for liquidation:

0<FMV<\=MMR0 < FMV <= MMR0<FMV<=MMR

_FMV = Position fair market value. MMR = Position Maintenance margin requirement._

#### 

[](https://docs.perpl.xyz/exchange/margin#collateralization-for-auto-deleverage-adl)

Collateralization for Auto Deleverage (ADL):

FMV<\=0FMV <= 0FMV<=0

_FMV = Position fair market value._

[PreviousOrder Book](https://docs.perpl.xyz/exchange/order-book)
[NextLiquidation](https://docs.perpl.xyz/exchange/liquidation)

Last updated 0 minutes ago

---

# Liquidation | Perpl Docs

Liquidation occurs when the position value falls below the maintenance margin requirement. Liquidations are crucial for maintaining the protocol's functionality and protecting other traders.

Here is how liquidation works on Perpl:

1.  The liquidation engine identifies undercollateralized positions
    
2.  Positions are closed at the mark price
    

All liquidation events will be recorded on-chain. To learn more about liquidation, read our blog on [understanding liquidation in perp markets.](https://blog.perpl.xyz/understanding-liquidations-in-perp-markets/)

![](https://docs.perpl.xyz/~gitbook/image?url=https%3A%2F%2F809468657-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FXVKhDpsjDZo7VFt2Qfew%252Fuploads%252F6tj7aNDmnuuvA2RegxbI%252Fimage.png%3Falt%3Dmedia%26token%3D623b4fc9-6657-402f-b39d-36f4bce940f1&width=768&dpr=4&quality=100&sign=a48f7ab0&sv=2)

### 

[](https://docs.perpl.xyz/exchange/liquidation#order-book-liquidations)

Order Book Liquidations

Order book liquidations are initiated by the protocol; a position meeting the liquidation criteria is sold to the order book if possible, with the proceeds distributed to the original position holder, perpetual insurance fund, and protocol.

#### 

[](https://docs.perpl.xyz/exchange/liquidation#invariant-collateralization-for-liquidation)

Invariant: Collateralization for liquidation:

0<FMV<\=MMR0 < FMV <= MMR0<FMV<=MMR

_FMV = Position fair market value. MMR = Position Maintenance margin requirement._

#### 

[](https://docs.perpl.xyz/exchange/liquidation#calculating-liquidation-price)

Calculating Liquidation Price

A position’s liquidation price can be calculated as follows:

PLiquidation\=PEntry+s⋅CMMR−CDeposit−CFundingLP\_{Liquidation} = P\_{Entry} + s \\cdot \\frac{C\_{MMR} - C\_{Deposit} - C\_{Funding}}{L}PLiquidation​\=PEntry​+s⋅LCMMR​−CDeposit​−CFunding​​

Where:

*   _P__Entry_ is the entry price of the position.
    
*   _s_ is the side of the position or position type (if the position is long, then a mark price at or below the liquidation price indicates the position should be liquidated; the opposite is true for a short position).
    

s\={1,long position−1,short positions = \\begin{cases} 1, & \\text{long position}\\\\ -1, & \\text {short position} \\end{cases}s\={1,−1,​long positionshort position​

*   _C__MMR_ is the Maintenance Margin Requirement (MMR) of the position. (See note on calculating this value below.)
    
*   _C__Deposit_ is the collateral deposited in the position.
    
*   _C__Funding_ is the funding payment owed by the position (available in the smart contract as premium PNL).
    
*   _L_ is the final liquidation lot size of the position.
    

The position’s MMR can be calculated as follows:

CMMR\=PEntry∗LCMMFC\_{MMR} = \\frac{P\_{Entry} \* L}{C\_{MMF}}CMMR​\=CMMF​PEntry​∗L​

Where:

*   _C__MMF_ is the Maintenance Margin Fraction (MMF) of the perpetual (`Perpetual::maintMarginFracHdths`).
    

The position’s bankruptcy price can be calculated similarly, except the Maintenance Margin Requirement value becomes zero (because the position is now bankrupt and has no value—it’s possible for a position to have a negative value at prices beneath the bankruptcy price, but this is clamped to zero in the auto-deleveraging process). The calculation of bankruptcy price is:

PBankruptcy\=PEntry−s⋅CDeposit+CFundingLP\_{Bankruptcy} = P\_{Entry} - s \\cdot \\frac{C\_{Deposit} + C\_{Funding}}{L}PBankruptcy​\=PEntry​−s⋅LCDeposit​+CFunding​​

#### 

[](https://docs.perpl.xyz/exchange/liquidation#partial-vs-full-liquidation)

Partial vs Full Liquidation

Depending on the position size, the crypto asset, and market conditions, the protocol may choose to perform a partial liquidation. This allows the trader to keep the trade open for a longer period. On the other hand, positions can be fully closed. In that scenario, the proceeds are split between the protocol, the insurance fund, and the trader. Both of these liquidations happen on the order book.

#### 

[](https://docs.perpl.xyz/exchange/liquidation#buy-to-liquidate)

Buy to Liquidate

In certain scenarios, when the position to be liquidated is too large to close out on the book, the PLP vault can buy the position to liquidate gradually.

[PreviousMargin](https://docs.perpl.xyz/exchange/margin)
[NextInsurance & ADL](https://docs.perpl.xyz/exchange/liquidation/insurance-and-adl)

Last updated 4 days ago

---

# Fees | Perpl Docs

Perpl uses a maker-taker model. Maker fees are paid when adding liquidity to the order book, while taker fees are paid when removing liquidity from it. The user only pays fees to open a trade, not to close it. Hence, there's no rakeback on the profits.

See fee structure below: TBD

[PreviousOrder Types](https://docs.perpl.xyz/exchange/order-types)
[NextTrading Perpetuals on Perpl](https://docs.perpl.xyz/resources/trading-perpetuals-on-perpl)

Last updated 4 days ago

---

# Insurance & ADL | Perpl Docs

In the event of a Black Swan scenario, there are measures in place to ensure the exchange remains solvent while minimizing negative consequences for users.

#### 

[](https://docs.perpl.xyz/exchange/liquidation/insurance-and-adl#insurance-fund)

Insurance Fund

An insurance fund is maintained from user fees, individually for each perpetual, to cover transactions in the event that the perpetual’s main fund is depleted under extreme conditions. Under certain conditions, the protocol may elect to compensate ADL winning traders for the difference in the value of their position from the deleveraged payout.

![](https://docs.perpl.xyz/~gitbook/image?url=https%3A%2F%2F809468657-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FXVKhDpsjDZo7VFt2Qfew%252Fuploads%252FNxz15q22KOByWiKz0tu8%252Fimage.png%3Falt%3Dmedia%26token%3Db01a7002-9031-4f56-9bc0-7196741d17c8&width=768&dpr=4&quality=100&sign=3e3f2e78&sv=2)

#### 

[](https://docs.perpl.xyz/exchange/liquidation/insurance-and-adl#force-close)

Force Close

In the event that there is no resting liquidity in the order book and the price remains stagnant or sideways for an extended period, traders can request that the protocol force close their position at the mark price and exit the perpetual contract.

#### 

[](https://docs.perpl.xyz/exchange/liquidation/insurance-and-adl#auto-deleveraging-adl)

Auto-Deleveraging (ADL)

This usually happens when there's not enough new liquidity entering, or price gaps up/down drastically. ADL ensures the protocol stays solvent, as was widely experienced during the October 10th, 2025, crash. Rapid changes in price can push liquidatable positions into bankruptcy before they can be liquidated by the system.

In this situation, it's important for the system to remove the positions (deleverage) quickly to ensure that other users with profitable positions can be paid. Failure to do so in a timely manner, along with continued price fluctuations, could result in the insolvency of the perpetual.

The _**perp is not paused**_ and can continue operating.

#### 

[](https://docs.perpl.xyz/exchange/liquidation/insurance-and-adl#unwind)

Unwind

Unlike ADL, the _**perp is paused**_ due to an extreme trading scenario (price manipulation, black swan events, thinly traded markets, etc.). The perpetual contract may be delisted under some conditions.

In an unwind, the perpetual may not have sufficient funds to pay existing positions at the value implied by the mark price. Regardless, it will compensate positions with positive value on a pro-rata basis out of the remaining funds. The price used to determine position value is the mark price at the time of pausing.

The price may be adjusted by the protocol under extreme circumstances. All such changes are logged on the chain for transparency.

[PreviousLiquidation](https://docs.perpl.xyz/exchange/liquidation)
[NextFunding](https://docs.perpl.xyz/exchange/funding)

Last updated 4 days ago

---

# Price Indices | Perpl Docs

### 

[](https://docs.perpl.xyz/exchange/price-indices#oracle-price)

Oracle Price

Perpl uses the Oracle Price (Chainlink Spot Oracle) in multiple ways:

1.  To ensure that the funding price, a spot index value, is reasonable and within tolerance.
    
2.  To create a synthetic perp price using the [BitMex method](https://www.bitmex.com/app/fairPriceMarking#Calculation-of-Fair-Price-for-Perpetual-Contracts)
     at every oracle update. This is used to compute unrealized P&L for positions and collateralization of increasing P&L when a position is increased or inverted. It is also used to reject the new position if it is under MMR.
    
3.  To ensure that the mark price that is set by the protocol is within a tolerance of the synthetic perp price.
    
    *   Synthetic perp price will be computed in the smart contract as follows: PSyntheticPerp1\=POracle⋅(1+CFundingRate⋅CBlocksUntilNextFundingCBlocksPerFundingInterval)P\_{SyntheticPerp1} = P\_{Oracle} \\cdot \\left(1 + C\_{FundingRate} \\cdot \\frac{C\_{BlocksUntilNextFunding}}{C\_{BlocksPerFundingInterval}}\\right)PSyntheticPerp1​\=POracle​⋅(1+CFundingRate​⋅CBlocksPerFundingInterval​CBlocksUntilNextFunding​​)
        
    *   _C__FundingRate_ is the value of the last funding rate.
        
    *   _C__BlocksUntilNextFunding_ is the number of blocks until the next funding rate event.
        
    *   _C__BlocksPerFundingInterval_ is the number of blocks between funding events.
        
    

### 

[](https://docs.perpl.xyz/exchange/price-indices#oracle-price-1)

Mark Price

Mark price is an unbiased and robust estimate of the fair perp price, and is used for margining, liquidations, triggering TP/SL, and computing unrealized PnL. It's computed off-chain from a mix of inputs and updated periodically OR during significant periods of change.

The mark price is computed periodically as follows:

PMark\=median⁡({PSyntheticPerp1,PBook,PSyntheticPerp2})P\_{Mark} = \\operatorname{median}(\\{P\_{SyntheticPerp1}, P\_{Book}, P\_{SyntheticPerp2}\\})PMark​\=median({PSyntheticPerp1​,PBook​,PSyntheticPerp2​})

Where:

PSyntheticPerp1\=POracle⋅(1+CFundingRate⋅CBlocksUntilNextFundingCBlocksPerFundingInterval)P\_{SyntheticPerp1} = P\_{Oracle} \\cdot \\left(1 + C\_{FundingRate} \\cdot{{C\_{BlocksUntilNextFunding}\\over{C\_{BlocksPerFundingInterval}}}}\\right)PSyntheticPerp1​\=POracle​⋅(1+CFundingRate​⋅CBlocksPerFundingInterval​CBlocksUntilNextFunding​​)

PBook\=median⁡({PMinAsk,PMaxBid,PLast})P\_{Book} = \\operatorname{median}(\\{P\_{MinAsk},P\_{MaxBid},P\_{Last}\\})PBook​\=median({PMinAsk​,PMaxBid​,PLast​})

PSyntheticPerp2\=MA30⁡(PMinAsk+PMaxBid2−POracle)+POracleP\_{SyntheticPerp2} = \\operatorname{MA30}\\left( \\frac{P\_{MinAsk}+P\_{MaxBid}}{2} -P\_{Oracle} \\right)+P\_{Oracle}PSyntheticPerp2​\=MA30(2PMinAsk​+PMaxBid​​−POracle​)+POracle​

*   _P__SyntheticPerp1_ is an approximation of the perpetual price obtained by adding a decaying amount of the funding rate to the spot oracle price. This is appropriate because the funding rate is a long-term measure of the difference between prices on the perpetual and spot markets over a defined interval. It decays because the further from the measurement, the less valid the correction becomes. This strategy is employed by both [BitMex](https://www.bitmex.com/app/fairPriceMarking#Calculation-of-Fair-Price-for-Perpetual-Contracts)
     and [Binance](https://www.binance.com/en/support/faq/detail/360033525071)
    .
    
*   _P__Book_ is a median of a sample of the current order book statistics:
    
    *   _P__MinAsk_ is the minimum ask price of valid (non-expired) orders on the perpetual.
        
    *   _P__MaxBid_ is the maximum bid price of valid (non-expired) orders on the perpetual.
        
    *   _P__MinAsk_ is the last price of a trade on the perpetual.
        
    
*   _P__SyntheticPerp2_ is another approximation of the perpetual price obtained by taking a moving average of the difference between the spot oracle price and a sum of the minimum ask and maximum bid prices, averaged over 30 samples, later adding it to the current oracle price. This algorithm is employed by [Binance](https://www.binance.com/en/support/faq/detail/360033525071)
    .
    
*   MA30⁡\\operatorname{MA30}MA30 is a 30-sample Moving Average.
    

[PreviousFunding](https://docs.perpl.xyz/exchange/funding)
[NextOrder Types](https://docs.perpl.xyz/exchange/order-types)

Last updated 4 days ago

---

# Order Types | Perpl Docs

Perpl will support the following order types:

*   **Market Order**: Executes immediately for the best available price
    
*   **Limit Order**: Executes at the specified price or better
    
*   **Stop Market Order**: Becomes a market order when the trigger price is reached
    
*   **Stop Limit Order**: Becomes a limit order when a trigger price is reached
    
*   **Take Profit Order:** Closes a position when a profit target is reached
    
*   **TWAP (coming soon)**: Time weighted average price, executes large orders over some time, breaking them into smaller, more frequent trades, to minimize the impact on the market price.
    

### 

[](https://docs.perpl.xyz/exchange/order-types#order-options)

Order Options:

*   **Good Til Cancel (GTC)**: An order that rests on the order book until it is filled or canceled
    
*   **Immediate or Cancel (IOC)**: An order that will be canceled if it is not immediately filled
    
*   **Fill or Kill (FOK)**: If the full quantity of the order cannot be filled instantly, the order is automatically canceled, preventing any partial or delayed execution
    
*   **Reduce Only**: An order that reduces a current position as opposed to opening a new position in the opposite direction. A Reduce Only order can only be placed if there is an existing position.
    

To learn more about order types, read our blog on [perp exchange order types](https://blog.perpl.xyz/order-types-perp-exchanges/)
.

[PreviousPrice Indices](https://docs.perpl.xyz/exchange/price-indices)
[NextFees](https://docs.perpl.xyz/exchange/fees)

Last updated 11 days ago

---

# Trading Perpetuals on Perpl | Perpl Docs

Assuming you have a funded wallet with USDC on Monad, you’re ready to start trading. If you do not have a funded wallet with USDC on Monad, go back a few documents to get set up.

To start trading, visit Perpl.xyz, click the “Connect” button, and choose a wallet to connect. A pop-up will appear in your wallet extension asking you to connect to Perpl. Press “Connect.”

Click the “Enable Trading” button. A pop-up will appear in your wallet extension asking you to sign a gasless transaction. Press "Sign."

Given your assets are now on Monad, you simply deposit them onto the exchange. Click “Deposit” to get your funds onto the exchange. Confirm the transaction in your wallet, and your collateral should show up in your account near instantly.

Now that your Perpl account is funded, it’s time to start trading perps. Perps allows you to long or short a token using USDC as collateral, without having to own the token directly, as in spot trading.

Placing your first trade is easy:

1.  Select a Token: Use the token selector or search function to find the market you want to trade.
    
2.  Choose Long or Short
    
3.  Long if you expect the price to rise.
    
4.  Short if you expect the price to fall.
    
5.  Set Position Size: Use the slider or enter a value.
    
6.  Position Size = Leverage × Collateral
    
7.  Example: 10x leverage X $100 collateral = $1,000 position size
    
8.  Place Your Order: Click Place Order, then confirm in the pop-up.
    

Congratulations, you’ve now placed your first trade on 11/11. Now comes the fun part, watching your trade play out and timing the markets right. There are a few considerations, like funds and liquidations, you should know about before sitting back. Read the rest of the architecture documents for a better understanding of some of the nuances that come with trading perps.

[PreviousFees](https://docs.perpl.xyz/exchange/fees)

Last updated 0 minutes ago

---

# Funding | Perpl Docs

Funding rate is a feedback mechanism to force the perpetual price to follow the underlying asset price more closely. Funding rate is computed over a funding interval and then applied to position holders during a funding event. Funding events occur periodically on perpetual exchanges and are often described as long position holders paying funding payments to short position holders (or vice versa).

The direction of payment depends on whether the funding rate is positive (payment flows from long positions to short positions) or negative (payment flows in the opposite direction). Premium PNL is the cumulative funding payments paid and received by a position.

The settlement of these payments through centralized exchanges is near or at the funding event. Unfortunately, this is prohibitive for decentralized perpetual exchanges that are not running on an app-chain, where gas is not a consideration, or for custom op-codes that can be crafted to enable low-gas-use implementation of such payments. The following sections outline the funding rate mechanism that affects a position’s premium PNL. Two major challenges involved in implementing the mechanism are:

1.  Computing the funding rate over the funding interval.
    
2.  Settling funding payments for all positions at every funding event.
    

Both challenges are difficult on-chain due to their implications for gas usage.

### 

[](https://docs.perpl.xyz/exchange/funding#funding-rate-calculation)

Computing Funding Rate

The method used by contemporary exchanges to compute the funding rate involves frequently computing an impact price on both sides of the order book for a specified notional amount. This operation is performed frequently during the funding interval, implying significant gas use that would have to be absorbed by users interacting with the contract, an off-chain keeper system, or both.

Alternative methodologies are being explored that could provide a similarly robust funding rate calculation, while being more gas-efficient on-chain. Key considerations are gas efficiency and resistance to attack vectors. The initial release of this decentralized perpetual exchange enables funding rate values, computed from transparent on-chain data, to be set at a fixed time prior to the funding event using a permissioned method.

The funding rate can be applied approximately once per hour. _Approximately_ because it is applied after a constant number of Monad blocks:

*   Every 8571 blocks (assumes 0.42 second average consensus time)
    
*   Can be set up to 143 blocks in advance (1 minute, assuming 0.42-second average consensus time). _Cannot be set after the funding event block._
    

The funding rate is set with two parameters:

*   _C__FundingRate_ is the funding rate calculated over the current funding interval, as detailed below.
    
    *   The funding rate is clamped in the contract such that its absolute value does not exceed `absFundingClampPctPer100k` , configurable abs. magnitude from \[0%, 15%\]
        
    
*   _P__FundingPrice_ is the funding price, essentially the spot market price feed value at the time the funding rate is set.
    
    *   This value is constrained to be within the reference tolerance % of the Chainlink Oracle price. The Chainlink Oracle price must not be stale (i.e., its timestamp’s distance from the current block timestamp cannot exceed the maximum reference price age parameter).
        
    

The funding rate is computed throughout the funding interval as follows:

CFundingRate\=∑n\=0kCImpactPriceDifference(nT)POracle(nT)C\_{FundingRate} = \\sum\_{n=0}^{k}{ \\frac{C\_{ImpactPriceDifference}(nT)}{P\_{Oracle}(nT)}}CFundingRate​\=∑n\=0k​POracle​(nT)CImpactPriceDifference​(nT)​

Where:

*   _n_ is the sample number within the funding interval.
    
*   _T_ is the sample period (for example, 5 seconds on Binance).
    
*   _k_ is the last sample in the funding interval (if the funding rate is set ~1 minute before the funding event, then ~11 samples would be ignored for _T=5_.
    

k\=3600T−1k = \\frac{3600}{T}-1k\=T3600​−1

*   _C__ImpactPriceDifference_ is the impact price difference at a given sample point. It is calculated as follows for values at a given sample point:
    

*   _P__ImpactBid_ and _P__ImpactAsk_ are the resulting execution prices of trading a specified notional amount in $USD on the bid and ask sides of the order book, respectively.
    
    *   The notional amount should be configurable and would be converted to a lot amount to execute the order—i.e., if ETH was trading at $4,000 and the notional amount was $2,000, then the prices would be computed for trades of 0.5 lots.
        
    

This methodology for computing the funding rate was described by [Hyperliquid](https://hyperliquid.gitbook.io/hyperliquid-docs/trading/funding)
 and is congruent with the method described by [Binance](https://www.binance.com/en/support/faq/detail/360033525031)
. _However, importantly, the method herein does not model the cost difference in borrowing USD versus spot crypto._

### 

[](https://docs.perpl.xyz/exchange/funding#h_0041d9bda9-2)

Settling Funding Payments

Explicitly settling funding payments on-chain for every funding event incurs prohibitive gas costs. This is because perpetual contracts can have hundreds to thousands of positions concurrently. During a funding event, each position’s account must transfer funds to or from the other position’s accounts according to the position size, funding rate, and funding event price. This implies hundreds to thousands of transfers per transaction, requiring significant state changes, which is prohibitively expensive.

To address funding issues, payments must be made virtually. This means that the effect of the funding payment settlement is visible after a single transaction, permitting all perpetual contract users to continue as though the payments had settled, without having to update the individual state of each of their positions in the contract. Virtualizing payments is further complicated because funding payments have a cumulative effect on a position held through multiple funding events.

Perpl debuts a novel solution to efficiently settle funding payments for all positions in a perpetual contract virtually. It is based on adapting the staking algorithm and virtual orders idea to eliminate the need for explicit periodic funding payment settlement.

#### 

[](https://docs.perpl.xyz/exchange/funding#a-virtualized-implicit-funding-event-payment-settlement-solution)

A Virtualized Implicit Funding Event Payment Settlement Solution

To derive a virtualized implicit funding payment settlement solution, consider the following equation for funding payment:

Fpayment\[j\]\=Pi\[j\]⋅Frate\[j\]⋅LF\_{payment}\[j\] = P\_i\[j\] · F\_{rate}\[j\] · L Fpayment​\[j\]\=Pi​\[j\]⋅Frate​\[j\]⋅L

_Frate\[j\] = Funding rate for funding event at block number j. P__i_ _\=_ Funding rate price, which is the spot index price at the time of the funding event. _L = Position lot size._

The position lot size L, and side (long or short), remain constant throughout each funding event during which a position is held (a smart contract constraint forces the realization of funding payments when the position lot size or side is changed).

This means that for all positions, cumulative funding payment information across multiple funding events can be determined using superposition. Instead of storing funding rate and index price for each funding event and looking up each funding event a position has been held through, a funding product sum can be stored to reduce read operations.

The funding product is the product of the funding rate and index price for a particular funding event– Importantly, the funding product is independent of information specific to an individual position:

Fproduct\[j\]\=Pi\[j\]⋅Frate\[j\]F\_{product}\[j\] = P\_i\[j\] · F\_{rate}\[j\]Fproduct​\[j\]\=Pi​\[j\]⋅Frate​\[j\]

_F__product__\[j\] = Funding product for funding event at block number j. P__i_ _\=_ Funding rate price, which is the spot index price at the time of the funding event. _F__rate__\[j\] = Funding rate for funding event at block number j. j = funding event block number._

Substituting equation Fproduct into equation Fpayment yields the following equation for the funding payment:

Fpayment\[j\]\=(Fproduct\[j\])⋅LF\_{payment}\[j\] = (F\_{product}\[j\]) · LFpayment​\[j\]\=(Fproduct​\[j\])⋅L

_F__product__\[j\] = Funding product for funding event at block number j. L = Position lot size._

The funding product sum is the sum of all previous funding products. The funding product sum is causal and thus is defined as zero prior to the creation of the perpetual contract.

Fsum\[j\]\={0,j≤i∑j\=iNFproduct\[j\],j\>iF\_{sum}\[j\] = \\begin{cases} 0, & j \\leq i \\\\ \\sum\_{j=i}^{N} F\_{product}\[j\], & j > i \\end{cases} Fsum​\[j\]\={0,∑j\=iN​Fproduct​\[j\],​j≤ij\>i​

_F__product__\[j\] = Funding product for funding event at block number j. j = funding event block number. i = Perpetual contract creation block number._

A funding product of a particular block can be determined by subtracting any two adjacent funding sums, as shown in the equation below:

Fproduct\[j\]\=Fsum\[j\]−Fsum\[j−k\]F\_{product}\[j\] = F\_{sum}\[j\] − F\_{sum}\[j − k\]Fproduct​\[j\]\=Fsum​\[j\]−Fsum​\[j−k\]

_F__sum__\[j\] = Funding product sum for funding event. F__sum__\[j − k\] = Funding product sum for previous funding event. j = funding event block number. k = The number of blocks in a funding interval._

Substituting equation Fproduct into equation Fpayment, the funding payment for a position that has been held through a single funding event at block j, can be computed:

Fpayment\[j\]\=(Fsum\[j\]−Fsum\[j−k\])⋅LF\_{payment}\[j\] = (F\_{sum}\[j\] − F\_{sum}\[j − k\]) · LFpayment​\[j\]\=(Fsum​\[j\]−Fsum​\[j−k\])⋅L

_F__sum__\[j\] = Funding product sum for funding event. F__sum__\[j − k\] = Funding product sum for previous funding event. j = funding event block number. k = The number of blocks in a funding interval. L = Position lot size._

Observing that equation _F__payment_ only depends on the lot size and side (long or short) of a position, it is possible to extend the solution to compute funding payments cumulatively owed for a position held through multiple events. For example, consider a position held through 3 funding events, up to and including a funding event at block j. Its cumulative funding payment could be computed as follows:

Fpayment\[j\]\=(Fsum\[j\]−Fsum\[j−3k\])⋅LF\_{payment}\[j\] = (F\_{sum}\[j\] − F\_{sum}\[j − 3k\]) · LFpayment​\[j\]\=(Fsum​\[j\]−Fsum​\[j−3k\])⋅L

_F__sum__\[j\] = Funding product sum for funding event. F__sum__\[j − 3k\] = Funding product sum for the three funding events prior. j = funding event block number. k = The number of blocks in a funding interval. L = Position lot size._

Importantly, notice that the cumulative funding payment owed can be determined in only two read operations. An important gas efficiency. Furthermore, the value of the funding payment need not be written to the chain until the entire position settles, bypassing the problem of immediate explicit settlement.

Thus, the generalized solution to compute any position’s cumulative funding payment, which can also be expressed as its premium PNL, θpnl, is:

θpnl\=Fpayment\[j\]\=(Fsum\[j\]−Fsum\[m\])⋅Lθ\_{pnl} = F\_{payment}\[j\] = (F\_{sum}\[j\] − F\_{sum}\[m\]) · Lθpnl​\=Fpayment​\[j\]\=(Fsum​\[j\]−Fsum​\[m\])⋅L

_F__sum__\[j\] = Funding product sum for funding event. F__sum__\[m\] = Funding product sum for funding event prior to position creation. j = funding event block number. m = The funding event block number for the funding event prior to position creation. L = Position lot size._

[PreviousInsurance & ADL](https://docs.perpl.xyz/exchange/liquidation/insurance-and-adl)
[NextPrice Indices](https://docs.perpl.xyz/exchange/price-indices)

Last updated 4 days ago

---