Rebalance
There's 2 types of rebalance
:
Natural Rebalance: Occurs at regular, predefined intervals. This type of
rebalance
is scheduled and happens automatically according to the set time periods.Early Rebalance: Triggered by severe market downturn. Specifically, this occurs when RiskON is close to going to zero as a result of breaching the threshold pre-defined in the RiskON/RiskOFF Product Specs.
NAV Calculation and Rebalancing
The Net Token Value (NTV) calculation code is crucial in managing rebalances
. It monitors the market conditions and determines when a rebalance
is necessary, whether it’s a scheduled Natural Rebalance or an Early Rebalance due to market distress (such as the bankruptcy of a Risk On/Off asset).
The main actors in the rebalance operation are as follows:
NTV calculation codes The NTV (Net Token Value) calculation system is an architectural masterpiece, integrating various services such as AWS SQS, AWS Lambda, Aurora Databases, and a Python engine. This system is responsible for determining when a
rebalance
operation should occur based on its calculations. Upon deciding arebalance
is necessary, it performs the following actions:Creates a new record in the database to document the rebalance event.
Triggers OpenZeppelin Defender’s webhook to initiate the
rebalance
process.
OpenZeppelin Defender
OpenZeppelin Defender is a serverless JavaScript application hosted on AWS Lambda. It is activated by its webhook, which is triggered by the NAV calculation system. In our protocol, Defender performs the following critical tasks:
Executes the
rebalance
method on the Orchestrator Contract, initiating therebalance
operation and retrieving transaction details.Calls the updateRebalanceStatus endpoint of our API to update the status of that particular
rebalance
in our database.
API The API serves two primary use cases:
General Users: Provides endpoints accessible by general users, frontend applications, and
flashloan
bots.Defender: After the
rebalance
transaction is confirmed on the Orchestrator Contract, Defender calls the updateRebalanceStatus endpoint to update the relevant records in the database.
Token Factory Smart Contract The executeRebalance method in the Token Factory Smart Contract is invoked with the necessary parameters (encodedValues, signature). In this setup, only the Orchestrator Contract is authorized to call this method.
Orchestrator Contract The Orchestrator Contract serves two main purposes: 1. Rebalance Operation: It triggers the
rebalance
by calling the executeRebalance method of the Token Factory with the required parameters. 2. Post-Rebalance Operations: The contract also manages operations that need to be performed after therebalance
. These operations are modular and can be added or removed as needed. An example is the Balancer Resync Operation, which adjusts the weights of RiskON/OFF assets in Balancer pools following a rebalance.
Rebalance Operation Flow
NTV Calculation Code Initiates the Process:
The NTV calculation code updates the database with all necessary data for the upcoming
rebalance
.It then triggers Defender’s webhook, passing the parameters required for the next
rebalance
.
Defender Executes Rebalance:
Upon receiving the webhook trigger, Defender calls the
rebalance
method on the Orchestrator Contract.
Orchestrator Contract Orchestrates the Rebalance:
The Orchestrator Contract invokes the executeRebalance method on the TokenFactory Contract.
Additionally, any other rebalance-related methods, such as resyncWeights on the Balancer, will be executed as part of the post-rebalance operations.
Parameter Validation:
Within the executeRebalance method, the parameters are thoroughly checked for validity, especially the
SequenceNumber
.If the
SequenceNumber
is valid and matches the expected value, therebalance
operation is carried out successfully.
Rebalance Math
At the outset, we divide the underlying cryptocurrency, XYZ, into two equal-value parts: RiskON and RiskOFF. As the market fluctuates, the prices of the RiskON and RiskOFF tokens diverge. However, by design, the sum of the Risk-on and Risk-off token prices always equals the price of the underlying asset. For instance, if just before rebalancing, the Risk-on token is priced higher than the Risk-off token, Risk-on investors hold more than half of the underlying value, while Risk-off investors hold less.
At the moment of rebalancing, the prices of Risk-on and Risk-off tokens are reset to equal values. To ensure the investors' total value remains the same before and after rebalancing, we adjust the number of Risk-on and Risk-off tokens each investor holds. For example, if the Risk-on price is higher than the Risk-off price before rebalancing, Risk-on investors will need to acquire some Risk-off tokens after the rebalance, as part of the Risk-on value will be redistributed into Risk-off value.
Example:
Initially, the XYZ token price is 100, and both Risk-on and Risk-off tokens are priced at 50.
Over time, the XYZ token price increases to 200, and the Risk-on token rises to 120, while the Risk-off token increases to 80 just before the rebalance.
After the rebalance, both the Risk-on and Risk-off token prices are reset to 100.
In this scenario:
A Risk-off investor holding 1 unit of Risk-off tokens, valued at 1 × 80 = 80 before rebalancing, will receive 0.8 units of the new Risk-off token, with a value of 0.8 × 100 = 80. Thus, the value before and after rebalancing remains unchanged for the Risk-off investor.
Similarly, a Risk-on investor holding 1 unit of Risk-on tokens, valued at 1 × 120 = 120 before rebalancing, will receive 1 unit of the new Risk-on token, valued at 1 × 100 = 100, and an additional 0.2 units of the new Risk-off token, valued at 0.2 × 100 = 20. Therefore, the total value before and after rebalancing remains the same at 120.
Mathematically, it's derived as follows:
The Rebalance Math: RiskON/RiskOFF Strategy
User Balance Calculation for RiskON and RiskOFF
Last updated