From the start, the end goal with Kanpeki has always been to create something that requires no “specific group”, manual management. “ossification”, to put it simply. Creating contracts that, as per the docs, any individual can interact with has been achieved but ossification has so far remained in limbo. While it may have been tolerable in the past under more naïve (and euphoric assumptions), the liability of continuing with that status quo is increasingly — and arguably has always been — problematic. So why?
Oracles
Just about everyone involved with defi today has some familiarity with the concept of “oracles”. Unfortunately, despite endless examples of the very dire consequences of playing fast and loose with this critical component, many individuals — focused on their own short-term gains — continue to do so and/or put forward “helpful suggestions” promoting it as a valid option to devs. To reiterate a point that has been made several times before: Kanpeki is, and will remain, exclusively dependent on Chainlink as a price-feed oracle for anything that can be deposit/borrow-ed on the platform. Rehashing why is not the focus of this article (there exists a litany of googleable articles for those interested in adequately informing themselves). This fact may displease some people and that’s okay — they’re welcome to bear such risks in their own endeavors.
Relying on Chainlink is not all roses though, especially if a project has its own token that isn’t some do-nothing “governance token”. Getting a token into a state where it can get a Chainlink feed is a relatively long and expensive process, in more than just monetary terms. It is for this reason that Kanpeki’s KAE token has remained without one, which may not seem like a problem since KAE isn’t deposit/borrow-able. However, it does need some pricing data to calculate the rewards for borrowing, required staking amounts, and facilitating buy-backs and burns.
An Alternative
After considering all the options, and the fact that pricing data for the aforementioned components needn’t be so frequent, Spookyswap’s (really Uniswap’s) TWAP oracle has been settled on as an acceptable alternative. For Kanpeki’s purposes, this oracle will be configured as such:
- it can be updated by any recently active borrower with an active stake of at least 2x the base amount
- it can be updated only once per 24 hrs
- only the network gas fee is charged to update it
The reasons for some of this is related to buy-backs.
Buy-backs & Burning
This is a feature that has been advertised from the start but has never been used for a variety of reasons, including the lack of an oracle. But as that’s being solved now, it can move forward. The burn contract collects all fees charged on the platform. These fees can be used to buy-back KAE at anytime which is then subsequently burned. The contract is configured as such:
- only addresses that have passed the check to update the KAE oracle can call the burn function
- the oracle must have been updated within the last 24 hrs to be able to carry out a burn
- only one token, for an amount of value not exceeding ~$1,000, can be burned at a time
- should this limit be exceeded, there must be at least 24 hrs before the next burn
It is advisable to use the most aggressive gas price possible when executing this function.
Closing the Gates
Another, more ambitious, blocking factor to ossification was the ability to permissionlessly add any token to the platform. This feature however has always been predicated on actions by 3rd-parties. While it is possible these 3rd-parties eventually deliver what Kanpeki once needed at some time in the future, such uncertainty and waiting games are no longer of interest for aforementioned reasons. An alternative would be to build out the infrastructure to support this but that would require a significant time-investment, and such endeavors have so far proved, for lack of a better term, wasteful. With these in mind, and coming to terms with the fact that such a feature and supporting an arbitrary number of tokens is a nice-to-have, not a need-to-have, the solution is simple: permanently encode the set of tokens that can be deposit/borrow-ed. The requirements settled on for these tokens are:
- it must have a Chainlink feed
- it must have FTM liquidity on Spookyswap
- it must not be be based on unproven and/or experimental assumptions
Six tokens were identified: ALPACA, BIFI, BNB, BOO, CRV, and SUSHI. These will all be added to Kanpeki and, in addition to the 7 tokens already supported, represent the final set of tokens that will be usable on it.
What’s Next?
To begin the process, and ensure the smooth execution of this ossification, borrowing will be paused starting tomorrow. This will, barring some unlikely event, be the very last time it will be paused or can be paused. As with the last pause, everything else will continue as normal. That will be all for now.
