How Kassandra works
The impending launch of Kassandras’ vision requires clarifications of some finer points concerning the protocol’s operation. In a series of previous articles, we have explained what Kassandra is and what it hopes to achieve, how the DAO and protocol token is established, and how the first Kassandra product (Avalanche Social Index) will work.
Therefore, in this article we will look at the technical side, that is, the logic of the smart contracts. It is strongly recommended that all those interested in Kassandra and its products read the articles on Medium. The full documentation page is still being developed and will launch soon.
First of all and to recap:
Kassandra is a decentralized autonomous organization that governs a set of tokenized data-driven investment funds, bringing a new class of investment products to the DeFi ecosystem: actively managed investment baskets without compromising the pillars of decentralization. All investment products made available through the Kassandra Protocol are permissionless, non-custodial, and actively managed by a third party.
The investment funds brought by Kassandra come in the form of a liquidity pool with fixed or changing weights (allocation). In the case of our first product, that is, the Avalanche Social Index, the weights will be determined by the Social Score. The liquidity pool will receive the deposits of the investors who in return will receive $aHYPE token. Those investors can earn fees because they are also liquidity providers, and in addition, the pool token (index token) can appreciate value-generating a greater return. The investors can choose to sell the protocol token at any time if they want since the token will be traded on the market.
To sum up: the Avalanche Social Index is an investment fund in the form of a liquidity pool, more precisely a SIP.
Under the hood, a SIP works essentially as an Automated Market Maker (AMM) for multiple assets, but with dynamically adjustable weights, that can be changed using external data. Using this approach removes the need for rebalancing operations by creating small arbitrage opportunities that external users can profit from and ensure that the desired proportions of each asset in the investment basket are maintained.
Now we can follow step by step the logic of our first product and how each smart contract interacts with one another.
The aHYPE strategy v1.0 works like the following.
- The DAO appoints two users:
— An updater is responsible for “awaking” the strategy so it obtains external data and starts updating the strategy
— A watcher, responsible for checking if the strategy is working as expected
- The updater “awakes” the strategy by telling it to start a request for external social score data provided by Heimdall through the API3 oracle service
- If the Heimdall API call worked our smart-strategy obtains the data, partially validates the data, saves it in the contract, and emits an event
- The updater calls
updateWeightsGraduallywhich does the heavy work of converting the social score data received from Heimdall into the weights data the SIP understands
- The strategy then checks how much has the percentage of each asset changed since the last call and if the percentage has increased or decreased more than what the DAO has defined as suspect, the strategy will automatically pause itself without committing the new distribution and will wait for the watcher decide if the new weights are to be accepted or discarded. If otherwise, the changes are below the suspect threshold, the new weights are committed in the SIP immediately.
- Once committed in the SIP the new weights are not taken into effect immediately, instead, they are scheduled to be reached in 24 hours, changing on each block following a linear function. This way prices in the pool won’t change instantly causing heavy rebalancing loss (impermanent loss).
One can see that the contract on the bottom of the diagram, that is, the HEIM POOL, enables the arbitrageurs to interact with the pool. Since our pool functions as a AMM, we depend on arbitrageurs to call the Poke Weights function to actually change the allocations in the pool. The DAO will only inform external agents what are the intended weights at each hour but not actively change them.
This diagram is the heart of the Avalanche Social Index. It has been tested, retested, and successfully audited by Certik. In the DEFI world errors in the smart contracts is the death knell of a Protocol. Therefore, the Kassandra team is very confident that our care and dedication in building the contracts and the expertise of the Certik auditors made possible a solid, secure, and reliable smart contract implementation.
Learn more about Kassandra:
- Website: https://kassandra.finance/
- Twitter: https://twitter.com/dao_kassandra
- Github: https://github.com/KassandraFinance
- Medium: https://kassandrafoundation.medium.com/