[Proposal] Adjusting interest parameter

Terraform labs

TLDR

  • We propose updating the target_deposit_rate and threshold_deposit_rate in the Overseer Contract to account for the change in average block time since the launch of Anchor Protocol and to enable the protocol to maintain a tighter peg around 20%.

Anchor money market’s interest calculations are based on blocks. Prior to Anchor launch, it was assumed that the block time would stay consistent, but that has not been the case. The Anchor money market expected 6.4274 seconds per block on the Terra network; in reality, recent block time (120hr) has been 6.772016867318786 seconds on average due to:

  1. An increase in the validator set & number of validators.
  2. Increased network congestion.

The Terra network has recently increased its max validator set from 100 to 130. Additionally, since the launch of Anchor, the number of validators has increased from 81 to 108. Due to the increase in the validator set and number of validators, block time has increased, as validator’s signatures are required during block creation. Also, the total transaction amount on the Terra network has increased, affecting block time.

As our current threshold_deposit_rate and target_deposit_rate calculations are based on past block time assumptions, we propose adjusting the threshold_deposit_rate and target_deposit_rate in consideration of recent block times.

We propose using 6.772016867318786 seconds for block time, so the block per year calculation would be 4,656,810 blocks.

Furthermore, we also suggest adjusting the annual_threshold_deposit_rate and annual_target_deposit_rate to 19.5% & 20.5%, respectively, to maintain a tighter peg around 20%. Due to the interest subsidy calculation, our current interest rate shows a slightly lower interest compared to our current annual_threshold_deposit_rate, which is 18%. Adjusting annual_threshold_deposit_rate and annual_target_deposit_rate to 19.5% & 20.5% would enable us to maintain a peg closer to 20%.

So the updated threshold_deposit_rate and target_deposit_rate would be:

blocks_per_year = 4,656,810
annual_threshold_deposit_rate = 19.5%
annual_target_deposit_rate = 20.5%

Current threshold_deposit_rate = 0.000000036686454933
Proposed threshold_deposit_rate = annual_threshold_deposit_rate / blocks_per_year = 0.000000041874158490

Current target_deposit_rate = 0.000000040762727703
Proposed target_deposit_rate = annual_target_deposit_rate / blocks_per_year = 0.000000044021551233

The on-chain proposal will follow.

Next Steps
As this proposal only provides a temporary solution, we plan to change the time-related calculation base from blocks to seconds in the longer term.

6 Likes

Please bear with me, I am relatively new. :grinning_face_with_smiling_eyes: If the Earn APY data at reactor.starport.services is correct, then it looks like we haven’t ever dipped below ~17.64% with the threshold currently set to 18%. That was the worst case that I see, but the typical deviation doesn’t seem to be more than 1.32%. If the goal is to stay as close to 20% as possible, are there any reasons we couldn’t have a much tighter range, and set the threshold_deposit_rate to 19.8%, placing the target_deposit_rate at 20.2% or even leaving it at 20%? If the 1.32% deviation tracks with a new threshold of 19.8%, then it would give us an estimated low value of about 19.54% (which at least rounds up to 20 nicely). However, I guess this would make it possible for the interest buffer distribution to trigger more often, but would that be an issue? Would we have to also decrease the max_borrow_factor to prevent quicker depletions in that scenario, or would that not really be relevant as the maximum is not ever used anyway? If I am completely off-base in this thinking, please let me know. Thank you!

  1. I think having 19.5 ~ 20.5 % range don’t have significant diff compare to 19.8 ~ 20.2 %
  2. max_borrow_factor is to prevent bank run situation of Anchor protocol - don’t think this has relationship with current topic.

Anyway thank you for the opinion!

1 Like

Thank you for the explanation. I now understand why lately Deposit APY is below 18%.

I agree that a tighter peg to a target rate is aligned with the notion of “Fixed APY”.
But isn’t TFL also contemplating a proposal to lower the target rate?
In order to avoid a scenario where the Deposit APY goes up (due to tighter peg) but soon goes further down (due to lowered target rate), I suggest the two proposals be merged to avoid any confusion. I’d hate to explain to newbies why Anchor’s “fixed” APY fluctuated like a rollercoaster from 20% to 17.9% to 19.5% to 15% in such a short timespan.

Minor note: ±0.2% is indeed “tighter” than ±0.5%. How do you determine that the ±0.5% range is sufficiently tight enough?

Due to the increase in the validator set and number of validators, block time has increased, as validator’s signatures are required during block creation. Also, the total transaction amount on the Terra network has increased, affecting block time.

Hi, long-term question: should we expect the Terra network throughput to continue getting worse as the number of validators/nodes grows?

Hi, I’m pretty new to Terra, Anchor, and crypto in general, so I appreciate your patience and bearing with my rather naive concern/question.

Would tightening the spread between threshold and target cause tapping into reserves more frequently? If so, is this not a concern? I guess, asymptotically, I ask the question why not just have the threshold be set to the target and be done with it. I’m sure there’s clear motivation to have the spread but aside from reducing the risk of tapping into reserve too frequently, I can’t think of anything else. Thanks and sorry if the question was stupid.

1 Like

This is what I was wondering myself, but I read something wrong and mentioned the wrong variable in my previous message. I was thinking that the ±0.2% may keep the number close enough to target while also allowing for some time between distributions. There is likely a maximum amount of reserves allowable per distribution, but I am not sure what that variable is called, or what it is currently set to. Knowing that would likely shed some light as to why the spread should/shouldn’t be tighter. Hopefully someone can point that out for us. :smiley:

1 Like

Maybe. Every blockchain has a tradeoff between throughput and decentralization. However, with our planned updates on using block timestamps for interest calculation instead of blocks itself, this wouldn’t be much of a problem.

2 Likes

I agree. Hopefully the Terra OG’s or Anchor devs can give us some insights.

I’m pretty excited to be part of these discussions btw. I’m pretty confident a pleb like myself will never be allowed to sit in on any of these governance discussions in tradfi world.

1 Like

Sorry if I’m misunderstanding, but are there 2 proposals lumped together in one?

  1. Using 6.772016867318786 seconds for block time
  2. Make the target band tighter by adjusting annual_deposit_rate and annual_target_deposit_rate to 19.5% & 20.5% respectively

Is 2 dependent on 1 or are they completely independent? It sounds to me that 1 helps with efficiency as it is related to the increased number of validators.

While 2 also seeks to make the protocol work as intended, the lower interest rate we’re experiencing now is an unexpected benefit, given the lack of borrowers and the risk of running down the reserve.

I echo @redkiho 's suggestion to consider this together with the proposal to ensure a more sustainable interest rate. Trying to solve for a tighter peg should not be viewed in isolation - the protocol’s stability and longevity should always be considered first.

2 Likes