Dynamic Liquidity/Dividends
Healthy Liquidity, Healthy Pools.

Dynamic Transaction Protocol (Dynamic Tax Protocol v3)

The Dynamic Transaction Protocol is a unique iteration of the Dynamic Tax Protocol that significantly upgrades liquidity management and provides additional funding to the dividend pools and ad-hoc burn.

Basic Functionality

Traditional reward projects used to split the transaction fees into liquidity and dividend pools with a fixed and share distribution. If the share that goes into liquidity is too high, ultimately BNB will be wasted as sitting on the liquidity pool without for no reason. On the other hand, with a high share of dividend, the liquidity might be too low, ultimately affecting the ability to exchange and trade the given token.
Dynamic Transaction Protocol (DTP-3)
iBNB Introduced a Dynamic Transaction Protocol in order to address the issue aforementioned. The distribution between liquidity and dividend pool is continuously adjusted in order to maximise rewards while ensuring healthy liquidity.
As volume is the driving factor in how quickly the BNB dividend pool fills, it can reach hyper-inflated levels during periods of increased volume, giving investors a false perception of the dividends when the market stabilises. During low trading volumes, the rate at which BNB is collected also drops back down until eventually the volume picks up again.
The rate at which the pool depletes is further accelerated by the number of holders. As the number of people who own the token increase, so does the average proportion of people collecting dividends.
If the trading volume does not recover, then at some point the fast rate at which the dividend pool is drained will cause investors to sell their iBNB tokens (as it becomes less profitable to keep your money invested for the sake of collecting the diminishing dividends). This will create a negative imbalance between the current available liquidity in BNB and the amount of BNB in the pool.
The Dynamic Transaction Protocol (DTP) was created with this issue in mind and with the purpose of adjusting the compulsory 10% transaction fee (split between the liquidity pool and BNB dividend pool) based on the health of the liquidity pool.

Healthy State

A fully healthy state is achieved when the amount of BNB in the liquidity pool sits at 10% or more of the total market cap. The DTP then splits the 10% transaction fee between the dividend pool and the liquidity pool at a rate of:
10% BNB Dividend pool
0% Liquidity pool
As there is sufficient liquidity in the pool, the reward pool becomes the priority. This is done to ensure fast accumulation of the BNB dividend pool, which in turn will keep the market in a healthy state due to the increased value of the asset (more BNB can be claimed per $IBNB purchased)

Rejuvenation State

In the event that the token enters a downtrend for an extended period of time and the liquidity is less than 10% of the market cap, a rejuvenation state is triggered and the DTP automatically prioritise the replenishment liquidity back into the pool, while still retaining a portion of a fee going to the BNB dividend pool.
While it is important to have liquidity in the pool, special mechanics are set in place to help slow down the rate at which liquidity is drained. This acts as a safety net for the liquidity pool and will allow it to refill at a faster rate than during a healthy state. The lower the liquidity, the higher the share of fees that flows back to liquidity is.
In a rejuvenation state, the % of transaction fees going to the liquidity pool is determined by the difference in % between the liquidity and market cap.

Additional Funding to the Dividend Pool

With the team's experience and expertise in the areas of cryptocurrencies and blockchain development, we have been able to create a much more efficient system by pushing the boundaries of what's possible with improving DTP and changing it to the next level iteration called DTP-3. In addition to the lower-bound LP-MC ratio that supports the assurance of a healthy state liquidity, we additionally setup an upper-bound LP-MC ratio that manages the abundance of liquidity in the liquidity pool. Whether or not the DTP system supplies the liquidity pool due to trading, there may also be additional liquidity provided to the liquidity pool (as we previously noted with the iBNB Liquidity Pool). As we have seen in many cryptocurrencies and tokens, it is often the case that there is more liquidity than necessary. To provide additional support to the dividend pools, we developed a system that manages excess in BNB liquidity and directly sends it to the dividend pool. As such, and initially fixed, any BNB that exceeds 15% of iBNB's market capitalisation will automatically be sent to the dividend pool.

Ad-hoc Burn.

Liquidity is provided in both BNB and iBNB tokens, which must match each other. Therefore, in accordance with the BNBs sent to the dividend pools by DTP-3, excess iBNB tokens are sent straight to a dead wallet and burned for a long-term burn effect.