Bitcoin Reserve Pool

Follow-Up Post: Community Feedback

Thanks to the Terra community for their comments and questions on our proposal. We’ve addressed them below, grouped in a few broad themes:

  1. BTC and LUNA : A few individuals (lejimmy, Paulo_Marf, zhew2013, Crypto_Inquisitor) made comments about the conceptual interaction and implicit competition between the BTC/UST and LUNA/UST mint and burn mechanisms. In general, we think of the BTC/UST swap as the insurance mechanism (for extraordinary times) and the LUNA/UST swap as the routine mechanism (for ordinary times). As part of that, BTC should not be withdrawn from the reserve on a day-to-day basis — and we believe a minimum exit flow spread of at least 200 basis points ensures that, based on UST’s historical price volatility. Thus, most of the time, the LUNA/UST mechanism is the only economically-viable source for individuals exiting their UST positions. The BTC reserve is only deployed during rare and sustained UST peg deviations. Moreover, if the BTC reserve is ever utilized (and UST is deposited into the pool in exchange for BTC), then it should be replenished as soon as the peg is restored — so that it is immediately ready for the next peg deviation. This is why we propose very tight spreads for the entry flow. But as soon as that UST is drained from the pool, there is no further entry flow facilitated and the LUNA/UST mechanism returns to its prime position as the source of new UST minting (York_Zhong also noticed this point). We could, of course, propose smaller exit flow spreads or larger entry flow spreads, but that would make the distinction between the BTC/UST and LUNA/UST mechanisms much smaller — the BTC/UST reserve might end up facilitating entry or exit liquidity during ordinary times alongside the LUNA/UST reserve, rather than only coming into play during extraordinary times. Similarly, we could use the BTC reserve to support the price of LUNA directly rather than UST as Crypto_Inquisitor suggested), but that would again call the reserve into action during ordinary times — unless it was explicitly gated by the price of UST, which introduces a new oracle dependency.
  2. Entry flow parameters : A few individuals had comments about the entry flow parameters. First, to pouiwert’s comment on raising the minimum spread, we believe a low minimum spread allows fast replenishment of the reserve pool back into BTC. But remember that — in general — one will not be able to mint UST from the reserve pool, because in general the reserve pool has no UST. The reserve pool only accumulates UST after a sustained depegging episode. So the low minimum spread is designed to quickly return the reserve pool to its original state, and then have it step back while the regular UST/LUNA mechanism takes over. Second, to Aloiz’s comment on tying the entry flow parameters to the reserve value-to-market cap ratio, this makes sense conceptually, but we worry about the enhanced operational complexity and increased attack surface, as this increases code complexity and embeds new dependencies on oracles. Moreover, we think the right principle is always to immediately replenish the reserve pool after it has been utilized, and then return to business-as-usual.
  3. Exit flow parameters : On this point, a deep note of appreciation for Pedro_explore’s analysis on the optimal set of parameters. We follow the logic and it is very thorough! The main point we’d like to add is that the parameters recommended by that post are among the more conservative in the dispersal of liquidity. The analysis presented is of course compelling in that even these conservative parameters would have performed well in UST’s last peg deviation, but circumstances can change. (For instance, ekryski notes that Anchor was still growing strong last time; that may not be true next time.) Thus, we would want to err on the side of being more generous with the liquidity where possible. In the short run, the differences in parameterization may not be too relevant due to the hard constraint of redemption caps to defend against oracle attacks (see next point); but as the reserve scales and redemption caps get relaxed, this tradeoff will become important.
  4. Oracle attacks : Fig and Bitn8 make comments on oracle attacks, and they make sense. We see oracle attacks as coming from three directions. First, the on-chain BTC price can lag the true price on other exchanges by a few blocks; and second, the true price on other exchanges could be manipulated by large block trades. However, we believe a 200 basis point spread deters a fast attacker from the former; and that the combination of a 200 basis point spread and slippage in the reserve pool deters a well-capitalized attacker from the latter. The third vector is a literal oracle malfunction. To Bitn8’s comment, we do intend to rely on multiple oracles — but we can never rule out a synchronized failure. Thus, we agree with all that hard redemption caps will be necessary, certainly at the start and possibly for the foreseeable future. Separately, to tobikuhlmann’s question, the exact oracles are something the community will need to decide on as it aligns on the exact implementation — although we are Jump Crypto believe that Pyth would be a good candidate.
  5. Technical BTC implementation : Westie and tobikuhlmann asked about the technical implementation of wrapped BTC. We at Jump Crypto believe in Wormhole’s abilities here, given its technical capabilities and decentralized ethos, in bringing wrapped BTC to the Terra chain. Of course, the vast majority of the underlying wrapped BTC itself comes from only a handful of entities (e.g. BitGo) and those protocols may be too centralized for some. But there is little that can be done on that point in the short-run, until some new standard for wrapped BTC emerges. Similarly, there may be some “basis risk” (i.e. price divergence) that opens up between true BTC on the Bitcoin chain, wrapped BTC on other chains, and the wrapped BTC on the Terra chain. Again, this is also an open and ongoing concern for now with no easy resolution — although we would advocate minimizing it by opting for simple and mature implementations where possible.
6 Likes

Would a Nebula Protocol cluster of several forms of wrapped BTC reduce the bridging centralization risk?

Thank you for addressing issues. Still I don’t get where the real BTC is going to sit. In LFG multisig wallet? If so where is the descentralization? Is only wBTC through wormhole isn’t this a little bit risky?

Nice work. Wormhole raises huge flags for me… it needs to be SUPER audited and all learning from other wormhole hacks must be implemented. Somewhere out there as we discuss this… in fact, probably someone reading this right now… is scheming (like the little worm that they are) how to drain this reserve… build carefully, build safely!

Could there be an alternative to holding it all via a wormhole bridge ?

Would love to know this as well, what’s the incentive for people to not arb it with Luna?

Technically couldn’t people just swap UST → Luna → BTC to bypass the $.98 price?

1 Like

You might’ve missed it, someone answered here. In short, it gives the swapper(s) alternatives in times of volatility.

Thanks so much, I did miss that. Looking forward for the system to be up.

Any update about BTC Reserve? When it will be lunched?

rip ser

2 Likes

It’s just this way to save LUNA, but it’s also hard to get people to trust again

How many BTC in the Terra Foundation right now? It can’t be ends like this…

I think this plan makes a ton of sense, thanks to all those involved for the leg work putting it together.

Two questions:

  1. How soon can this be implemented? I know Astroport was working on something like this (or maybe precisely this). Is this weeks/months away, or farther?

  2. How do users exit Terra if they want to? i.e. convert wrapped Bitcoin into native Bitcoin or some other asset.

BTC/UST is not the only way. We need decentralized stablecoins and by using bonded foreign stablecoins then it meets the practical criteria of being backed by decentralized money without centralized exchanges. If the greatest plan @JumpTrading has is to continue forward with simply the $0.98 BTC backing then you will see additional depegging pressure during additional Fed interest rate hikes. In all your proposals you must realize by now that cash must be collateralized with multiple assets and currencies. It is not possible to escape George Soros pressure and single points of failures. Please consider to raise LUNA stability insurance funds and increase actual bonded stablecoin collateralization for USTs. This is the only way to make the system have value. Everything thing else is waiting for a bigger fish to toy with your BTC reserves then damage Terra again, except there is no next time. The next time everyone will flee from this platform for good. We must build extreme robustness and know your $0.98 BTC is incapable of going up against large whales. Assets ideally should never back USTs. Only stablecoins back USTs. Assets and stables can back LUNAs.

When UST market price is very low now, about 0.08 USD, why doesnt LFG take this opportunity to buy back UST and burn? This will gradually bring back UST to peg, and gradually revive LUNA and the echo system?

They bailed out the whales. The company has zero money left. This was our biggest fear. Do Kwon even proposing to reset the allocations was just him panicking that he had nothing left to give. There is something left to give. He needs to give his time into repairing the platform and first remove the broken minting algorithm that simply does not work. Do Kwon still has a narrow window out of this and he can still tap into the goodwill, but it is almost guaranteed that by him closing off and hiding 100% of the goodwill and patients will turn into anger and rage. Do the right thing. Fix the platform and focus on increasing value. This is the way out of the mess. Keep everyone in the loop of the high levels of what is being done and what major challenges are left. Use this opportunity to fight to survive.

Current LFG funds

How the BTCs were spent

1 Like