# Funding Tick

Funding payments are part of the perpetual-application business logic. In short - funding is a mechanism to credit or debit the users' positions, according to a predefined logic, in order to incentivize certain strategies.

 Since StarkEx already supports periodic modification of the users' balances, this support can be easily extended for different purposes, such as debt management or periodic rewards.

## Step 1: The application sends a Funding Tick to StarkEx

The funding tick has the following parameters:

• The new `system_time`

• A new `global_index` for every `assetId` in the system

## Step 2: StarkEx verifies the validity of a Funding Tick

StarkEx checks the following conditions:

• The new `system_time` is greater than the previous `system_time`.

• For every `assetId`, the following condition holds:

$|\text{prev_global_index} - \text{global_index}| \leq \text{config.max_funding_rate} \ \cdot\\ (\text{system_time}-\text{prev_funding_time}) \cdot \text{current_price[assetId]}$

Where `config.max_funding_rate` is an on-chain configuration parameter, for more details see here. `current_price` is set according to the last Oracle Price Tick, for more details see here.

 In the above formula you can see that the time since the previous funding tick directly affects the change allowed by the funding tick. In order to limit the permitted change, StarkEx verifies the following at the beginning of every transaction:`system_time - prev_funding_time <=` `funding_valdity_period`

## Step 3: Funding Tick Effect

After the funding tick is accepted, an array called `global_indices` is updated with a new value per `assetId`.

Every transaction execution that touches a position (Deposit, Withdrawal, Trade, Transfer, Forced Withdrawal and Forced Trade) applies a funding operation on this position. For this, each position stores a value called `position_cached_indices` per `assetId` , which represents the last funding tick that affected it. The execution of a transaction consists of two steps:

1. For every `assetId`reduce the funding debit from the balance and update the position indices, as described below:

$\text{position_balances[collateral]} -= \text{position_balances[assetId]} \cdot \\ (\text{global_indices[assetId]} - \text{position_cached_indices[assetId]})$
$\text{position_cached_indices[assetId]}= \text{global_indices[assetId]}$
2. Apply the transaction specific logic.

These two steps are atomic: If a transaction is invalid then neither step is executed.

## Step 4: Funding Tick - Batch Validity Checks

If the Funding Tick is valid, it is included in a batch to be submitted on-chain along with a validity proof. See here for full details on state update on-chain.

As part of the batch validity checks, the StarkEx contract checks that the last funding timestamp in the batch was within the last week.
This limits the time between two funding ticks and thus limits the funding debits.