Bitcoin Reserve Pool

Bitcoin Reserve Pool

Executive Summary

Community proposal regarding how LFG may deploy its Bitcoin reserve to defend the UST peg

  • Proposing a pool that facilitates rapid BTC liquidity to support UST during downwards peg deviations, and relies on traders to replenish the reserves outside of crises.
  • The pool’s mechanics resembles the LUNA <> UST on-chain mechanism, but with two key differences:
    • First, the pool holds a different asset (wrapped BTC), and so likely needs to use a distinct architecture (e.g. a smart contract capable of interfacing with CW20 wrapped assets).
    • Second, the pool should use different parameters for exit and entry liquidity, rather than netting flows.
  • We propose several sets of parameters to facilitate liquidity and defend against oracle attacks.

Reserve Model

The illustration below describes the minimum viable product for the BTC reserve pool. The reserve’s primary goal is to deploy liquidity during a crisis. The reserve’s secondary goals are to remain simple, such that it can be operationalized quickly and that additional features can be added in the future.

  • LFG places its BTC in a reserve pool that retail traders can access at some discount, e.g. retail participants provide 1 UST in exchange for $0.98 in BTC initially.
    • This mechanism provides a strong backstop for UST during a crisis.
    • While tiered across multiple levels, the exit liquidity should be stiff at the initial discount, to facilitate robust outflows of BTC during a crisis.
  • Once the crisis passes, external traders can purchase UST with BTC, e.g. deposit ~$1.00 in BTC in exchange for 1 UST.
    • This drains the pool of accumulated UST after a crisis passes.
    • This trade should be lucrative when UST faces upwards pressure or trades at a premium in a post-crisis state.
  • As context, the size of the reserve pool will be around $2.5 billion in BTC at launch.
  • Critically, this model assumes robust private markets for UST. It assumes the liquidity provided by the BTC reserve will be expressed onto the decentralized and centralized exchanges, like Astroport and Binance respectively, where most of UST’s trading volume occurs.

Reserve Mechanics

The virtual AMM for the LUNA <> UST on-chain swap mechanism would effectively be forked and utilized for the BTC reserve with three critical differences. (Note that the AMM is virtual because liquidity is centered around an oracle price, rather than the amounts of BTC and UST in the reserve.)

  1. First, this mechanism design results in the delivery/holding of a pre-existing asset (wrapped BTC), whereas the LUNA <> UST one mints and burns new assets into and out of existence. This proposal assumes BTC is ported to the Terra ecosystem via a protocol such as Wormhole.

  2. Second, this mechanism should set parameters that reflect its purpose — to distribute liquidity in an emergency — better.

  3. Third, this mechanism should offer different parameterizations depending on whether traders are extracting BTC or UST from the reserve, i.e. asymmetry in the parameterization.

Reserve Parameters: Background

We discuss the reserve parameters for the virtual AMM at a high level. There are three key parameters:

  1. BasePool determines the size of the ‘virtual’ constant product pool and thus parameterizes the slippage that a given trade might incur, where slippage is approximately the trade’s size divided by the BasePool parameter.
    1. For instance, if we set BasePool to be $100MM, a $1M UST redemption would suffer an extra 100bps slippage (subject to the MinSpread parameter).
    2. A larger BasePool allows greater liquidity facilitation, but also risks allowing an attacker behind a stale or manipulated oracle to withdraw more funds at once.
  2. PoolRecoveryPerioddetermines the pace at which the BasePool is replenished toward the initial value. A shorter recovery period thus facilitates better liquidity.
    1. The same tradeoff emerges: shorter recoveries allow greater liquidity facilitation but face elevated risk of attacks.
  3. MinSpread is the smallest slippage that a swap will incur, which is needed to defend against stale oracles. Trades will be done at the greater of the estimated slippage and the MinSpread parameter.
    1. Again, the same tradeoff emerges: a lower spread allows liquidity to flow more easily, but also faces elevated attack risk.

Observations from the LUNA <> UST on-chain swap setting suggest a relatively smaller BasePool and shorter PoolRecoveryPeriod has been found to be the optimal mix. Empirically, this provides liquidity in small and continued bursts, while reducing the risks around an oracle attack.

For reference, the parameter structure looks like the following. For the on-chain UST <> LUNA mechanism, it is denominated in microSDR; but it should be denominated in UST for this mechanism.

type Params struct {
	PoolRecoveryPeriod int64   `json:"pool_recovery_period" yaml:"pool_recovery_period"`
	BasePool           sdk.Dec `json:"base_pool" yaml:"base_pool"`
	MinSpread          sdk.Dec `json:"min_spread" yaml:"min_spread"`


Reserve Parameters: Asymmetry

The reserve fund is designed to provide deep liquidity at a discount when the UST peg is under pressure, and not to provide liquidity for the ordinary expansion and contraction of UST as the LUNA <> UST on-chain mechanism does. The reserve fund should also replenish itself with BTC after a crisis, but it does not need to do so with the same urgency.

As such, we recommend asymmetric parameters for the virtual AMM, which effectively splits the two sides of the pool (UST → BTC and BTC → UST) into independent pricing functions.

  • This means that the internal state variable “TerraDelta” gets split into TerraDelta_EntryFlow and TerraDelta_ExitFlow, and are tracked and decayed separately.
  • This splitting offers a further defense against oracle attacks. In the status quo, a single “TerraDelta” nets inflows and outflows, and an attacker can buy and sell to keep spreads narrow. By not offsetting inflows and outflows, the reserve prevents an attack from buying and selling without facing wide spreads.

See the illustration below as an example of potential parameters.

type Params struct {
	PoolRecoveryPeriod_EntryFlow int64   `json:"pool_recovery_period_entryflow" yaml:"pool_recovery_period_entryflow"`
	PoolRecoveryPeriod_ExitFlow  int64   `json:"pool_recovery_period_exitflow"  yaml:"pool_recovery_period_exitflow"`
  BasePool_EntryFlow           ust.Dec `json:"base_pool_entryflow" yaml:"base_pool_entryflow"`
	BasePool_ExitFlow            ust.Dec `json:"base_pool_exitflow"  yaml:"base_pool_exitflow"`

	MinSpread_EntryFlow          ust.Dec `json:"min_spread_entryflow" yaml:"min_spread_entryflow"`
	MinSpread_ExitFlow           ust.Dec `json:"min_spread_exitflow"  yaml:"min_spread_exitflow"`



//Hypothetical arrangement of initial parameters (entry flow, BTC for UST) 
PoolRecoveryPeriod_EntryFlow // 10 minutes
BasePool_EntryFlow           // $500 million
MinSpread_EntryFlow          // 10 bps

//Hypothetical arrangement of initial parameters (exit flow, UST for BTC) 
PoolRecoveryPeriod_ExitFlow  // 1 minute
BasePool_ExitFlow            // $500 million
MinSpread_ExitFlow           // 200 bps                         

Reserve Parameters: Empirical Assessment

In this section, we offer guidance on what the actual parameter settings should be.

Exit Flow Parameters: this should be based on a desired activation level for the fund (e.g. $0.98) and the desired speed of deploying all capital. The table below shows how much liquidity is available instantly and per hour at a variety of slippage rates. All of these parameters are within reasonable ranges to defend against oracle attacks, as discussed in the appendix.

Parameters (Exit Flow) Instant Liquidity Per-Hour Liquidity
Base Pool Recovery Period (minutes) Minimum Spread (bps) 200 bps 300 bps 400 bps 200 bps 300 bps 400 bps
$100MM 1 200 $2MM $3MM $4MM $60MM $90MM $120MM
$100MM 1 300 $0 $3MM $4MM $0 $90MM $120MM
$500MM 1 200 $10MM $15MM $20MM $300MM $450MM $600MM
$500MM 1 300 $0 $15MM $20MM $0 $450MM $600MM
$500MM 5 200 $10MM $15MM $20MM $60MM $90MM $120MM
$500MM 5 300 $0 $15MM $20MM $0 $90MM $120MM
$1,000MM 0.5 200 $20MM $30MM $40MM $1,200MM $1,800MM $2,400MM
$1,000MM 0.5 300 $0 $30MM $40MM $0 $1,800MM $2,400MM
$500MM 0.1 200 $10MM $15MM $20MM $3,000MM $4,500MM $6,000MM
$500MM 0.1 300 $0 $15MM $20MM $0 $4,500MM $6,000MM

In this table, we examine minimum spreads (i.e. activation levels) of 200 - 300 basis points, i.e. UST being redeemed for $0.97 - $0.98 in BTC. This is based on an empirical calibration, to prevent the fund for being utilized for ordinary movements in the price of UST in favor of extraordinary movements only. In particular, using hourly data in the past ninety days (as of 3/21/22), the 0.1% percentile of UST’s price was just above $0.98. Moreover, using daily data since UST’s inception, the 1% percentile of UST’s price was just above $0.98, with almost all exceptions coming from the large and sustained deviation in May 2021. Thus, 200 basis points seems like an appropriate threshold to be utilized in emergencies but not otherwise.

Entry Flow Parameters: this should be based on the desire to replenish BTC in the reserve after a crisis has passed and the UST peg has been restored. However, it may be desirable to provide liquidity at shallower depths, and replenish the reserve over a longer period of time. This is because the reserve should have a substantially smaller MinSpread parameter, making it more vulnerable to oracle attacks — and so a longer PoolRecoveryPeriod is appropriate.

Parameters (Entry Flow) Instant Liquidity Per-Day Liquidity
Base Pool Recovery Period (minutes) Minimum Spread (bps) 5 bps 10 bps 50 bps 5 bps 10 bps 50 bps
$100MM 1 5 $50K $100K $500K $36MM $72MM $360MM
$100MM 1 10 $0 $100K $500K $0 $72MM $360MM
$500MM 1 5 $250K $500K $2.5MM $180MM $360MM $1,800MM
$500MM 1 10 $0 $500K $2.5MM $0 $360MM $1,800MM
$500MM 5 5 $250K $500K $2.5MM $36MM $72MM $360MM
$500MM 5 10 $0 $500K $2.5MM $0 $72MM $360MM
$1,000MM 5 5 $500K $1MM $5MM $72MM $144MM $720MM
$1,000MM 5 10 $0 $1MM $5MM $0 $144MM $720MM
$500MM 10 5 $250K $500K $2.5MM $18MM $36MM $180MM
$500MM 10 10 $0 $500K $2.5MM $0 $36MM $180MM

Oracle Attacks

The section contains the analysis needed to set attack-resistant parameters. It covers two types of oracle attacks: stale oracles, and manipulated oracles.

First, consider stale oracles. We present the plot of the 99.5 percentile of BTCUSD price movements (from the last six months), in absolute value, as a function of timescale. Stale oracle prices of up to five (5) Terra blocks expose the reserve to ~25 bps of price movement in the tails. As such, the MinSpread parameter needs to be large compared to this, in order to protect trading against stale oracle prices being used to drain the pool over time.

Second, consider manipulated oracles. Here, we need to ensure that the BTC liquidity available from the reserve is small compared to that available in the centralized exchanges for BTCUSD. This protects against an attacker manipulating the real BTC price and then trading against this manipulated price. Below is a consolidated liquidity plot for all the major centralized exchanges, showing the slippage in bps that a market order of various USD notional sizes would suffer. Reassuringly, the BTCUSD market is very liquid — and so, as long as the reserve pool suffers more than ~20bps in slippage on a $10MM trade, there is negligible risk of an oracle being manipulated.

However, regardless of proposed mechanisms above to counter issues relating to oracles, we recommend the implementation of daily BTC redemption caps. This outflow restriction protects the reserve in the worst scenario, such that not all BTC could be drained in one or a series of days due an oracle bug. We suggest somewhere between 10-30% of the total reserve size as an initial redemption cap and are seeking community input for guidance.

We look forward to engaging with the community on this proposal.


First off, holy shit, this is one of the most rigorous proposals I’ve seen almost anywhere. Maybe only some of the ones in Maker forums and Vitalik’s posts compare… :clap:

Obviously this is super important and has been one of my main questions around how the BTC reserve will be utilized. Great to see a very thoughtful start.

This will make a sustained de-pegging beyond $0.98 very difficult to achieve if the primary mechanism for UST redemptions is on-chain and not through a CEX. :slightly_smiling_face:

I 100% support this. A cap on redemption over a given period should also help curb bank runs during a catastrophic event. This is what banks have historically done in TradFi - buffered withdrawals. I think a cautious 10% is probably a good starting point. Could also increase with a governance vote later.

Need to think on the other pieces. Overall this is pretty huge. :grinning:


There have been talks about how what percentage LUNA will be minted vs. how much BTC can be redeemed to defend the peg during an emergency.

Clearly these mechanisms are not directly intertwined in this proposal but perhaps the exact percentage can be extrapolated by the parameters set for BTC<>UST vs. LUNA<>UST.

In any case, supportive of this proposal, LFG!


Would it make sense to tie the entry flow parameters to the reserve value / market cap of UST? In other words, incentivize replenishing the reserve more when the reserve value / market cap of UST is low, and disincentivize it as it approaches 1?


Very nice analysis!

I think basing the BTC reserve model on the current on-chain market makes sense.

On the MinSpread_EntryFlow parameter, I think 5-10 bps could be too low. Currently on-chain LUNA <> UST MinSpread is 50 bps, so that would make minting UST via BTC the cheaper option most of the time. As per your parameter tables, people could mint $180MM to $1.8B UST daily using BTC paying less than 50bps, which could massively reduce LUNA burns during expansionist periods.

I think having MinSpread_EntryFlow slightly higher than LUNA <> UST MinSpread (e.g.: 55-80 bps) would be the best way to keep the current alignment of incentives, where LUNA accrues the value of the growth of the ecosystem.

Another alternative would be to keep MinSpread_EntryFlow at 5-10 bps, but make BasePool_EntryFlow much smaller, allowing for a smaller but steady inflow of BTC to the reserves, while keeping the majority of the UST expansion via LUNA burns.


Great proposal! I have a couple questions. First, why would anyone choose to swap 1 UST for $.98 worth of BTC when they can swap 1 UST for $1 of LUNA? Would known arbitragers simply choose that option because the order books are likely more liquid? Might be misinterpreting something, so please let me know. Second, you mention the BTC will be wrapped, what will this look like and is this truly a decentralized manner of redemption? Otherwise all other things look great, fully in support.


Risk Harbor research team here :wave:

Excellent work to the Jump team and everyone else who worked to make this proposal a reality. Multidimensional parameter selection problems are difficult in general, moreso when the design space is large as was the case here. But the team clearly thought extremely carefully about this one and brought us one of the best presented proposals in the history of Terra governance.

With that said, we wanted to highlight a few technical aspects of the proposal:

On “Critically, this model assumes robust private markets for UST”:

We agree with the cautious approach here from the proposers but at this point, robust private markets for UST are more of a fact than an assumption. UST has deep liquidity on Terra, Cosmos (Osmosis), Ethereum Mainnet, and on CEX’s. Of course, in times of stress on the system, this liquidity can dry up but considering how invested many of the market makers are in the Terra Ecosystem, that seems unlikely.

On the oracle security assumptions and provisions

We think Jump has taken exactly the right approach. When this much is on the line we have to plan for failure and take appropriate precautions to protect the system even if oracles are compromised briefly. The asymmetric reserve parameters here are a nice touch. It’s an example of an optimization that only comes when you think methodically about a problem by carefully laying out objectives and security assumptions.

Overall this is an exceptionally well thought out proposal that adds even more security to the UST peg. UST depeg was already extremely unlikely but the addition of this stability pool has rendered it nearly impossible for the foreseeable future.


To your first question, if enough UST is swapped for Luna in a short enough time frame the cost to swap UST increases (i.e. you get less Luna per every UST swapped). If there’s a large enough outflow of UST, at some point it’ll be more profitable to swap UST for $.98 worth of BTC.


Good job on the proposal, looks pretty good.
Some more technical stuff might be hard to understand but I’m wondering if you can elaborate how this proposal would affect Luna Burns when minting UST.

The idea on $1 UST for $0.98 BTC is great. I’ve been thinking about that as well.

For the ~$1UST for $1BTC part. Would that remove some value capture of Luna? Once the depeg danger is over, people still might get UST by swapping BTC. Some of new UST demand might be consumed by this reserve instead of burning Luna.

Could you guys please enlighten me? Thanks!

Excellent idea!

this is not milestone of Terra. this is MileStone of Crypto World!

Yes! just do it!

Very good.

Only one question: wen Degenbox with UST, wrapped BTC token, and 100x leverage ? (a la $MIM) Already have the USDT / UST Curve pool so…

Why not have several oracles - Band, Pyth, and chainlink with a mean shorting function?


Bolstering confidence in UST’s peg and stability is the priority. If UST holders do not panic and wait until the oracle pool spread diminishes to redeem their depegged UST → Luna → [other asset] then, as shown here, Terra/Luna will be able to absorb the drawdown and keep Luna from going to $0.

However, if confidence that patience will pay-out dwindles, the peg goes into question and panic ensues. What determines this:
Time depegged + Price of Luna.

The May panic was triggered not because of the Luna price fell, but rather because Terra’s Burn/Mint Module was frozen due to Oracle TXs being crowded out of Blocks (this has since been fixed). Interestingly, before this Module froze, panic did not occur, and once the Module started back up panic subsided. Back then UST had much fewer use cases and reputation compared to today.

Interestingly, when the Module turned back on, Luna had lost 75% of it’s price, and STILL, the peg recovered. After the peg recovered, we saw little change in Luna price. TAKEAWAY: Protecting the peg protects Luna’s price and should be prioritized. Furthermore, a tight UST peg also bolsters confidence and encourages patience for redeemers.

The only question is: In an objective UST drawdown, how quickly should we conclude the drawdown?

Luna Mint/Burn Module can handle $290M/day at a 2% swap tolerance. I propose we set the Forex Reserve parameters to absorb any excess Burn/Mint demand based on our “Time to conclude drawdown” target.

In May the peg recovered after 8 days. So we can be confident market participants are willing to accept 8 days of uncertainty/depeg. Now that Terra is much stronger and trusted, I would say we can set the drawdown parameter to 7 days (or higher) without issue. (As pointed out there were many other issues in May such as Anchor non-competitive liquidation premiums)

We should prepare the reserve for something severe, this is a panic drawdown after all. Being able to survive a proper $10B drawdown without issues would quite any Anchor FUD and bolster Terra for any drawdown of its biggest Dapp ($11B UST in Anchor):

This drawdown would take 34 days. To be able to absorb this in 7 days the mint/pool mechanism has a deficit of $1.1B per day. For the Forex Reserve to Absorb this, it corresponds to the following Parameters: Base Pool $100M - Recovery 1 min - Min Spread 2%.

With $8B BTC in the Forex Reserve, UST could absolutely absorb $10B in an immediate agnostic contraction of UST Mcap. This would take 7 days and keep the peg around $0.98 / UST, which we know are acceptable parameters for users.

Effect on Luna: By only absorbing $2B worth of UST contraction Luna will have less mint. Furthermore, by absorbing minting fees on the way down Luna becomes a more attractive asset to hold during sell-offs. If we expect Luna to drop to a specific price this will be the result: (this assumes Luna price stays constant for the entire burn, therefore this is the WORST case scenario in terms of new Luna minted):


  • Suggested Params: Base Pool $100M - Recovery 1 min - Min Spread 2%.
  • Terra can absorb $10B in UST contraction in 7 days while at the same time keeping the Peg within a 2% tolerance. (requires $8B in BTC).
  • Quick peg return encourages patient market participants andavoids panic, this encourages users to hold UST during the market turbulence and reduces UST drawdown.
  • Luna price will be severely impacted, however by offloading sell pressure to Forex Reserve: Luna remains a valuable asset to hold during drawdown.
  • Size of the Reserve does not have to grow as UST Mcap grows. I should match the biggest single points of failure of UST use such as the biggest Dapp.
  • Terra’s Trust and Ensured Survival will be cemented.

Great analysis. One thing to note, that previously the reason the peg recovered so well is because there was still heavy subsidy of Anchor which is what has been driving insane UST demand. If the yield % is more comparable to the yield you can get with other assets then I don’t think the UST demand will be so strong, especially at larger volumes. Lots of our assumptions here depend on a strong UST demand and utility. That will have a bigger impact on the peg defence than collateral imho (although collateral and this mechanism certainly helps absorb shocks).

Killer - love seeing firms such as Jump getting their hands dirty.

Value add - and helps foster both decentralization and UST adoption. At its core, this proposal looks to create a greater use case for BTC and further stabilize UST.

I hope to outline some points brought up above:

While this may be true, the severity depends on what perspective you are coming from. As a LUNA holder, this may be a bit scary - but for BTC it is good news.

I worry about the integrations of oracles as it is the most frequent attack vector.

You approach this risk as negligible. In the last two quarters, has slippage price has never gone above 20%? Chart looks truncated on the y-axis at 18.62%.

I will mirror @ekryski’s comment and applaud this feature below:

It further prevents severe exploits, which seems like a great idea.

Lots of great input from the community and excited for further collaboration between investors and users.

1 Like

To clarify, the UST in the reserve pool is limited (accumulated during UST crisis phase) and thus wen it is depleted, this pool does not support further purchasing of UST using BTC.

Is this understanding correct?

Thanks for such a detailed proposal.

Would it be worthwhile backing Luna itself, vs the UST peg? The objective is to incorporate exogenous reserve assets into the seniorage model— so presumably this could be done by backing Luna in some way, rather than UST.

It seems like this might simplify the mechanics of the backing.

e.g. an approach as simple as a protocol-owned $5b LUNA-wBTC AstroPort 50/50 pool would create sustained buying pressure on Luna as the pool auto-balanced during a Luna price fall. Additionally, LP trading fees at all times could be fed directly back into the pool, further deepening it.

Has something like this approach been considered?

Super nice proposal @JumpTrading! Would love to see this moving forward.

While reading, two questions came up for me:

  1. Oracles: Where do they come from and who operates them?
  2. Wrapped BTC: Do you have any recommendations on which wrapped BTC to use and associated wrapping and bridging risks? Thinking about whether wrapped Assets might run into trouble in times of market turmoil, failing to represent their underlying asset’s price correctly. Or introducing centralization and therefore a single point of failure into the system