💵Funding

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.

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:

$C_{FundingRate} = \sum_{n=0}^{k}{ \frac{C_{ImpactPriceDifference}(nT)}{P_{Oracle}(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 = \frac{3600}{T}-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 and is congruent with the method described by Binance. However, importantly, the method herein does not model the cost difference in borrowing USD versus spot crypto.

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.

A Virtualized Implicit Funding Event Payment Settlement Solution

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

$F_{payment}[j] = P_i[j] · F_{rate}[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:

$F_{product}[j] = P_i[j] · F_{rate}[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 F_product into equation F_payment yields the following equation for the funding payment:

$F_{payment}[j] = (F_{product}[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.

$F_{sum}[j] = \begin{cases} 0, & j \leq i \\ \sum_{j=i}^{N} F_{product}[j], & j > i \end{cases}$

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:

$F_{product}[j] = F_{sum}[j] − F_{sum}[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 F_product into equation F_payment, the funding payment for a position that has been held through a single funding event at block j, can be computed:

$F_{payment}[j] = (F_{sum}[j] − F_{sum}[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:

$F_{payment}[j] = (F_{sum}[j] − F_{sum}[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} = F_{payment}[j] = (F_{sum}[j] − F_{sum}[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.