KIP 008 - Implement a Protocol Savings Pool (Trill)

Governance Kolibri Improvement Proposals
#1

Keeping in line with the hummingbird theme of the project, I want to propose Trill, an idea to fund and support a savings pool for the protocol. Trill is the jingling sound [male] hummingbirds make via their feathers and use it as a defensive/mating tactic.

Kolibri currently has a relatively conservative mechanism to fund a reserve for the protocol’s stability as well as Kolibri’s future development work. A percentage of liquidations currently supports a portion of the stability and the development funds.

KIP - 006 proposed the elevation of the Liquidity Pool as the primary liquidator for the protocol. This was to enhance the protocol further and promote the use of the platform. The Liquidity Pool serves as a backstop to the protocol, however, its incentives and structure need an upgrade.

The idea behind Trill is simple:

  1. It increases fees charged to liquidations to properly fund aspects of Kolibri which ensure long-term success.
  2. It enhances the Liquidity Pool’s ability to clear HUGE trades (ideally, through the protocol itself). Market liquidity and depth are two concerning aspects within the Tezos ecosystem currently, and potential liquidations of huge ovens may shock platforms like QuipuSwap. At the time of this writing, an oven liquidation of >$500k would potentially undermine the integrity of the XTZ-kUSD pool on Quipi.

Trill, as a savings pool, can fund two reserves:

  1. Pure kUSD pool (as it does now).
  2. An XTZ-kUSD pool just to help clear huge trades (think of this as adding depth and liquidity to not only Kolibri, but also the Tezos ecosystem).

Trill can be used for:

  1. Rewarding liquidators appropriately (this is needed to incentivize the use of the Liquidity Pool as well as the platform).
  2. Funding Kolibri’s own XTZ-kUSD savings pool to help clear large trades. This pool can also potentially assist with future expansion of the platform, perhaps for lending as a product/service.
  3. Rewards for submitting successful governance proposals (this is needed for the proper functioning and an ever-engaged DAO community).
  4. Rewards for voting, for obvious reasons.

There are potential concerns around #3 and #4 above, perhaps in the form of mal-voting and trying to game the platform. Would be great for members of the community to chime in.

For the purposes of this proposal, any numbers I use here are examples of what’s possible. The idea is that all the percentages mentioned below will be DAO-driver parameters.

There are three workflows to funding Trill:

  1. Current stability fee will be modified so it gets spread into two pots - 50% kUSD, 50% XTZ. 50% XTZ can be purchased (from a DEX like Quipu) at the same time the stability fee is assessed on ovens.
  1. When an oven is liquidated from the Liquidity Pool:
    a. 80% of liquidation value is rewarded to Liquidity Pool funders on a pro-rata (weighted) basis.
    b. 10% of liquidation value is rewarded to the liquidator.
    c. 3.5% of liquidation value is used to purchase XTZ from Quipu (or wherever else). I am not sure whether the contract can simply “take” 3.5% of an oven’s XTZ during liquidation - if so, it may reduce a roundtrip to Quipu. This feature is quite useful in that, over time, the protocol is not trading against itself - it participates (at least 3.5% on a rolling basis) in the other side of the trade, relieving some of the price slippage pressure.
    d. 1.5% of liquidation value is set aside to reward voters/governance participants. I call this the proposal savings pool.
    e. 1.5% of liquidation value is set aside for rewarding submitters of successful governance proposals. I call this the voting savings pool.
  1. When an oven is liquidated from a private wallet:
    a. 90% of liquidation value is rewarded to the liquidator.
    b. 3.5% of liquidation value is used to purchase XTZ from Quipu (or wherever else). I am not sure whether the contract can simply “take” 3.5% of an oven’s XTZ during liquidation - if so, it may reduce a roundtrip to Quipu. This feature is quite useful in that, over time, the protocol is not trading against itself - it participates (at least 3.5% on a rolling basis) in the other side of the trade, relieving some of the price slippage pressure.
    c. 1.5% of liquidation value is set aside in the proposal savings pool to reward voters/governance participants.
    d. 1.5% of liquidation value is set aside in the voting savings pool for rewarding submitters of successful governance proposals.

As part of Trill, I am also proposing that every successful governance submission is awarded 10% of the balance of the proposal savings pool. 10% of the voting savings pool is also awarded to each voter on a pro-rata basis, regardless of the outcome of the proposal and/or how the participants voted (yay/nay). Those who abstain from voting, aren’t awarded anything.

Again, all the numbers above are “made-up” and the community can adjust depending on needs. For example, the 3.5% in 2-c/3-b above can be set really high (say 15-20%) if the Liquidity Pool is clearing >$500k trades on a regular basis.

I am imagining there’s some lead-up time to get Trill fully funded. What Trill ultimately gets us is ANOTHER, self-sustaining XTZ-kUSD pool of depth and liquidity besides a DEX like Quipu to help clear large liquidations. In times of duress (say Quipu is knocked offline), this backstop can really jump to action on its own.

Finally, I don’t know if there are plans for a Kolibri lending product. But if there are, I am making the educated leap that our own savings pool of XTZ-kUSD assets will be invaluable.

Credits to @chas @fitblip @Basil.

1 Like
#2

Lots to unpack here, thanks for the thoughtful proposal.

If I’m understanding correctly, I think there’s two main ideas:

  1. De-risk trading the Liquidity Pool
  2. Reward Governance Participants

I think the simplest method towards de-risking the Liquidity Pool is simply implementing a scheme like Liquity that does not require trading on a DEX.

If that seems like an acceptable goal, then I think there’s no need for the protocol to hold XTZ and that would simplify a lot of this proposal. I do think I’m a bit fuzzy on how the XTZ bit is supposed to work, so feel free to help me understand if I’m not grokking it correctly.

WRT to the funding workflows:

  1. Current stability fee will be modified so it gets spread into two pots - 50% kUSD, 50% XTZ. 50% XTZ can be purchased (from a DEX like Quipu) at the same time the stability fee is assessed on ovens.

Conveniently, the contracts in the Governance timelock have an entrypoint to update the splits between interest. It would be trivial to add another fund here (and that fund could trade for XTZ). One caveat is that we have to be cognoscente that there is a gas limit, and inter-contract calls in Tezos remain expensive (although hopefully this gets better in Hangzhou) .

As above, I’m not completely sure what the value of holding XTZ is.

  1. When an oven is liquidated from the Liquidity Pool:
    a. 80% of liquidation value is rewarded to Liquidity Pool funders on a pro-rata (weighted) basis.
    b. 10% of liquidation value is rewarded to the liquidator.
    c. 3.5% of liquidation value is used to purchase XTZ from Quipu (or wherever else). I am not sure whether the contract can simply “take” 3.5% of an oven’s XTZ during liquidation - if so, it may reduce a roundtrip to Quipu. This feature is quite useful in that, over time, the protocol is not trading against itself - it participates (at least 3.5% on a rolling basis) in the other side of the trade, relieving some of the price slippage pressure.
    d. 1.5% of liquidation value is set aside to reward voters/governance participants. I call this the proposal savings pool.
    e. 1.5% of liquidation value is set aside for rewarding submitters of successful governance proposals. I call this the voting savings pool.

When a liquidation occurs, liquidators (including the pool) pay a liquidation fee (currently set at 8%, adjustable via governance). Thus to liquidate a 100 kUSD loan, you will pay 108 kUSD (100 * 1.08).

WRT to (b), I think that @fitblip has a signal request out for adjusting the rewards rate.

I’m a bit confused at why we’d want to fund these pools only from liquidation and not from interest rates.

  1. When an oven is liquidated from a private wallet:
    a. 90% of liquidation value is rewarded to the liquidator.
    b. 3.5% of liquidation value is used to purchase XTZ from Quipu (or wherever else). I am not sure whether the contract can simply “take” 3.5% of an oven’s XTZ during liquidation - if so, it may reduce a roundtrip to Quipu. This feature is quite useful in that, over time, the protocol is not trading against itself - it participates (at least 3.5% on a rolling basis) in the other side of the trade, relieving some of the price slippage pressure.
    c. 1.5% of liquidation value is set aside in the proposal savings pool to reward voters/governance participants.
    d. 1.5% of liquidation value is set aside in the voting savings pool for rewarding submitters of successful governance proposals.

Same basic comments as above. I think it would be really useful to have this logic be standardized, otherwise it’s a mess and tricky to implement. Ideally we treat all liquidations the same, rather than trying to special case them and adding complexity to contracts.

So putting this all together, I think there are 3 proposals here:

  1. Trade some of our treasury for XTZ in the stability fund
  2. Create a a proposal savings pool
  3. Create a voter savings pool

I’m unclear at how (1) really helps us. My specific concerns are:
a) It feels likely that we’ll have shallower liquidity than quipuswap, and I’d rather us encourage LPing on DEXes by increasing trading volumes than trying to hand roll a solution.
b) It’s unclear to me that trading for XTZ against trades for kUSD is going to produce intended results; haven’t thought about it too much.
c) I don’t understand how holding XTZ in the stability fund helps us. We can’t use it to liquidate or anything. Otherwise, we could turn the stability fund into a DEX (which largely gets us back to the same place)
d) Feels like if this is actually a concern we can just remove the DEX component of the liquidity pool by creating a V2
e) Feels like this is adding a lot of complexity into the protocol by special casing things and trying to do more automatic trades.

WRT 2:
I’m actually pretty cool with us rewarding proposers. Of note, this is basically possible today, because a proposer could put in a lambda that:
a) Makes a change
b) Sends the proposer some kUSD from the development fund or some kDAO from the community fund as an invoice

Our tools could make this easier to do.

If we wanted to make this automatic, I think that’s fine too. However, I also think some changes are worth more than others - changing the stability fee or debt ceiling successfully are useful adjustments, but creating entire new protocol features are probably worth more. Manual invoicing might be more effective here.

There’s some risk management involved to make sure we have money on hand to do this (ex. if we pay out a fixed rate for each proposal, and many proposals are executed we may actually run out of money in the proposal fund and become insolvent). If this is an automatic process, it’s likely that contract calls could fail and nothing could get executed until we became solvent again. Note that KIP-009 can make this more predictable.

WRT 3:
I’m not sure paying people to vote is great idea (and I’d prefer that people research and participate if they want). We already have high participation rates (>70%) so I’m not sure that this incentivizes much.

Same comments about making sure the protocol doesn’t go insolvent as above.

#3

Sorry for the late response.

  1. Trade some of our treasury for XTZ in the stability fund
  2. Create a a proposal savings pool
  3. Create a voter savings pool
  1. I do see your side and buy into your thesis around complexity vs. usability. Without getting into a complicated explanation/justification, my main motivation for holding XTZ was that it may help with platform growth. I see it as a product innovation (where very few protocols have gone before) - that you reward protocol participants not only in kUSD, but also the underlying asset in the form of XTZ. And at the time of liquidation, there’s a unique opportunity for the protocol to just “grab” some XTZ from the oven, if you will. In my head, this is a draw to the platform, but I also see your point about complexity, especially the bit around hand rolling our own solution aka reinventing the wheel. Interested to hear your thoughts if we simply look at holding XTZ for the sole purpose of rewarding participants (either now and/or later as more features are added, say lending).
  1. Would definitely want this implemented - am happy to explore the lambda route if automation is cumbersome.
  2. For the record, I kind of felt that proposing to incentivize voting is a polarized issue. In line with #1, the motivation here is to draw more usage to the platform. BUT also incentivizing long-term holding of kDAO. I do believe in the philosophy of voting your free voice, but I also know that more voices will be raised if incentives and outcomes are aligned. OK with putting a pin in this, but is food for thought.

Look forward to new thoughts related to #1 and #3. Seems like we have consensus on #2 (:+1:).

#4

Looking forward to the Savings Pool, adding more usage of kUSD and more liquidity locked in the ecosystem. I think that lending and borrowing will take us to the next level as a community. We have the borrowing, and hopefully lending soon.

#5

@keefertaylor a recent, “soon to-be liquidated” large oven made me come back to this KIP again. The current situation of this oven (around Dec 12, 2021) is a perfect example of why the protocol may want to [partially] hold XTZ instead of raising liquidity via a flash sale:

  1. There isn’t enough depth on Quipu - now I do understand that this may eventually change as the tez ecosystem improves, but I don’t think it’s going to be any time soon.
  2. The trade could (will) exacerbate the peg situation even further.
  3. The flash sale could (would) result in a discounted sale, affecting “value” for QLkUSD holders.

I actually thought of another feature to supplement this idea - in addition to the protocol hoarding some XTZ from a liquidation, we can also give the liquidator the option to accept XTZ for the [current 10%] liquidation reward. This will further help with depth/peg issues.

Thoughts?