# Funding

Perpetual Futures instrument can receive funding charges whereby the long positions are paying funding to the short positions according to a given funding rate and funding reference price. The frequency and parameters of the funding charge are determined by the engine administrator and is triggered by calling the control gateway API endpoint for each funding round.

2 accounts have traded 100 Linear Futures contracts with each other. The administrator applies an hourly funding charge of 0.001% with a reference price of 100,000.0 In this case the long account pays 100 * 100,000 * 0.00001 = 100$ to the short account.

The API supports 2 modes of Funding charges. The choice between Simple Rate and Cost per Contract modes is done at instrument setup and cannot be changed.

The administrator can set a reference price and a rate to apply to this price. The calculation of the funding charge for a position is then position * price * rate. To prevent rounding errors from accumulating, the engine keeps track of the total funding rate since instrument inception.

P_k : the reference price on funding round k

R_k : the funding rate on funding round k

Total funding rate from inception:

F(n) = \sum_{k=1}^n R_k P_k

At round n+1, the funding charge applied to a position C is :

F_T = F(n+1) * C - F(n) * C

C = 100 (contracts)
P_1 = 123.512
R_1 = 0.1
P_2 = 132.543
R_2 = 0.1

With naive funding calculation:

F(1) = 1235
F(2) = 1325

With rounding error prevention mechanism:

F(1) = 1235 

F(2) = (P_1 * R_1 + P_2 * R_2) * C - P_1 * R_1 * C \\\\
F(2) = (123.512 * 0.1 + 132.543 * 0.1) * 100 - 1235 \\\\
F(2) = 25.6055 * 100 - 1235 \\\\
F(2) = 2561 - 1235 \\\\
F(2) = 1326 \\\\

Alternatively the administrator can specify a cost per number of contract of the instrument. In this case the rate is the number of contracts x to apply the charge to (usually 1.0) and the reference price is the number of minor unit of currency to pay per x contract.

The engine applies a similar strategy as with the simple rate to avoid accumulating rounding errors.

Funding is taken from the following sources, depending on availability of funds.

Funding charge is paid first from the account's balance.

If an account doesn't have sufficient balance to pay the full funding charge, which should imply that the account has significant unrealized gains that prevent it from being liquidated, the engine would cut some of the unrealized profits to pay the remainder of the funding charge.

For example if an account has to pay a funding charge of 1100$ but only has 1000$, provided that it doesn't get liquidated, the engine will pay 1000$ from the account's balance and 100 from unrealized pnl.

This is achieved by adjusting the position entry price to a slightly less favorable price to cut off the required amount of unrealized gains. There will be two executions of equal and opposite size marked as "FundingByUnrealizedPnl". The difference in cost is the unrealized pnl used to pay the funding charge.

If this operation puts the account above its maximum leverage, it will be liquidated right away.

C = 100 (contracts)
E = 124.65 (entry price)
P = 128.79 (current price)
B = 1000\$ (balance)
P_1 = 132.512 (reference price)
R_1 = 0.1 (funding rate)

F(1) = 1325

Account pays 1000$ from balance. 325 remain to be paid.

UnrealizedPnl = 414 \\\\
NewUnrealizedPnl = (414 - 325) = 89 \\\\
NewEntryPrice = 128.79 - (89 / 100) = 127.9 \\\\

The position entry price is adjusted to 127.9 so that it only generates 89 in profit. The loss of 325 in profit constitutes funding payment

In the unlikely event that in order to collect unrealized pnl on the funded instrument, the engine would need to move the position entry price above the max price of the instrument, the price will be capped at the max price and the remaining funding will be paid by a similar methodology on other instruments on which it has a position.

If none of the above method suffice to pay the full funding charge, the remaining amount is taken from the insurance fund via a BalanceReset transaction, and the normal liquidation workflow ensues. Note that this scenario is very theoretical as it would imply an account has a long position bought at the maximum price of the instrument (the account should have been liquidated a long time ago!)