TIP-040: tBTCv2 Liquidity Mining for Guarded Launch

Summary: Allocate a minimum of 5,359,375 T tokens and a maximum of 8,039,062.5 T tokens for an initial tBTCv2 liquidity mining program to incentivize early minters of tBTCv2 and facilitate the desired engagement levels and user actions specified in the guarded launch schedule.

Background
tBTCv2 minting is expected to go live on January 9, 2023, via a guarded launch with caps (both per-deposit and system-level) that increase over time. This staged launch is designed to test the protocol as it grows, and ensure it is able to handle very high volumes of deposits and redemptions. Each stage entails a maximum deposit per transaction as well as a hurdle (system-wide TVL and number of deposit transactions) that must be met in order to move on to the next stage.

Motivation
tBTCv2’s guarded launch is designed to rigorously test the deposit and redemption funcitonality prior to scaling TVL. This liquidity mining program is designed to facilitate the targeted number of deposit transactions in the early capped stage, NOT to naively grow TVL.

Allocating T token incentives to early depositors will facilitate the deposits and engagement necessary to properly test the protocol’s functionality and move through the stages in a timely manner.

Additionally, targeting eligibility for the liquidity mining program to specific communities and power DeFi users provides an opportunity to strategically grow the Threshold community and tBTC user base.

Proposal

Allowlist of addresses
An allowlist of eligible addresses drawing from the existing Threshold community, relevant power user communities (LobsterDAO and Degenscore), and the Threshold alumni network (Curve and Tally Ho) will be eligible for rewards.

Specifically, the allowlist includes:

While there’s value in keeping the allowlist exclusive initially, it could potentially be expanded to include the following communities, if desired:

  • vlCVX users
  • wBTC/renBTC minters
  • BadgerDAO users
  • Other relevant communities or users

Rewards Schedule
Liquidity mining rewards will proceed in step with the guarded launch schedule previously proposed, along with two proposed changes/clarifications:

  • Since the System Cap and Total Deposits must be fulfilled before moving on to the next stage, “Week” is renamed to “Epoch”. An Epoch will be at least a week, but may last longer if the specified targets are not met.
  • For accounting simplicity, fluctuating USD values are ignored in favor of BTC-denominated accounting.

Examples
In epoch 1, the System Cap is 0.5 BTC and the Deposit Per-Transaction Cap is 0.005 BTC. Once 100 deposits of 0.005 (totaling 0.5BTC) are made into the System, rewards for that epoch will be exhausted. Only deposits equal to the 0.005 BTC per-transaction deposit cap will be rewarded.

In Week 8, the System Cap is 150 BTC and the Deposit Per-Transaction Cap is 0.05 BTC. Once 1,000 deposits of 0.05 BTC (totaling 50 BTC) are made into the System, rewards for that week will be exhausted. Only deposits equal to the 0.05 BTC per-transaction deposit cap will be rewarded.

Rules & Mechanics
To qualify for rewards, participants must hold the minted tBTC until redemptions are enabled (currently expected in Epoch 8, but subject to change). Since earlier epochs are required to hold for a longer period, the implied T per BTC rewards decrease each epoch.

As a reminder, the goal at this stage is to test system functionality (primarily deposits and redemptions), NOT to naively grow TVL. As such, only transactions that comply with the specified “Deposit Per-Transaction Cap” and that don’t exceed the “System Cap” for the specific week will be eligible for rewards.

Participants that sell, transfer, or otherwise dispose of their minted tBTC prior to redemptions going live will be disqualified from receiving rewards, at the sole discretion of the Threshold Council and Threshold Treasury Guild Committee.

T rewards will be paid out at the end of Epoch 8, pending a manual review to ensure no inappropriate gaming of the system has occurred.

At any point during the liquidity mining period, participants can optionally LP their minted tBTC into the Curve pool for at least an 8 week period, in order to earn a 1.5x boost on their T rewards (meaning the maximum possible T tokens paid out by the DAO for this program is 1.5 x 5,359,375 = 8,039,062.5).

To recap, to qualify for rewards users must:

  • Deposit in the correct increment for the current epoch
  • Hold (or LP in Curve) through at least epoch 8, when redemptions go live
  • Optionally LP in Curve for at least 8 weeks to earn a 1.5x rewards boost
  • Not attempt to game or circument the rules or intent of the liquidity mining program

To avoid being overly prescriptive, this initial proposal only describes liquidity mining for the first 8 epochs before redemptions start. This will provide learnings to inform changes and improvements to any potential future extensions of the liquidity mining program.

Open Questions

  • Should there be an additional holding period after redemptions are live for an address to qualify for rewards?
  • Should the reward boost for Curve LPs be something other than 1.5x?
  • Should the allowlist be expanded? If so, with which communities?
  • Are the T rewards calibrated correctly? Are they too high? Too low?
  • Since this LM program incentivizes LP deposits, should the DAO continue to vote its vlCVX gauge weight for the tBTCv2 pool during this liquidity mining period or should it temporarily use that vlCVX for other purposes (e.g. voting for the teth pool)?
6 Likes

Thanks for this detailed proposal @Mr_T!

I would like to give this more thought but wanted to make sure I have the details / needs clear. From my understanding this is focussing on (stress) testing the deposit flow, and not yet on the redemption flow.

Are the needs for testing redemptions, once enabled, comparable?

2 Likes

Correct, this proposal is for liquidity mining for the first 8 epochs, prior to the redemption flow going live. Separate proposals can be made for later epochs and/or the uncapped TVL scaling phase.

The redemption flow needs to be tested, but I don’t believe the DAO should incentivize redemptions as that’s at cross-purposes to growing TVL. However, if it’s necessary to ensure adequate testing, perhaps a separate proposal can be made to refund gas costs for testers of the redemption flow.

4 Likes

Please note this TIP needs to be updated to reflect the altered cap schedule I will work on doing so, but please don’t move it to Snapshot until that is done @Luna5.

2 Likes

I’ve updated the incentive schedule to reflect the revised cap schedule published by Hagan (An Updated Timeline for the Launch of tBTC v2).

Given the higher per-transaction deposit caps, I think any deposit at or below the cap should be incentivized on a pro rata basis, rather than limiting it to deposits at the exact cap (i.e. if a user deposits 0.05 BTC in Epoch 2, they should get 10,937.5 / 2 = 5468.75 T rewards).

One issue with the revised incentive schedule is that the number of transactions that receive rewards may end up very limited if everyone makes the maximum deposit per epoch (190 transactions total) and there’s a high likelihood it will be captured by a small handful of unique users, which may limit the marketing/awareness benefits of targeting other communities. Maybe this means we need to give some guidance around whitelisted minting incentives post-week 8 to make sure we’re capturing sufficient interest. Other ideas on how to rectify this issue are welcome.

The proposal also gives the Treasury Guild, Integrations Guild, and Threshold Council reasonable discretion in adjusting the reward amounts, determining the whitelist, and other design parameters including those listed as Open Questions in the OP.

3 Likes

I like this proposal a lot. There’s different arguments for and against an allowlist, but for me what weighs heavily is to get it in front of a specific audience and create some exclusivity.

One issue with the revised incentive schedule is that the number of transactions that receive rewards may end up very limited if everyone makes the maximum deposit per epoch (190 transactions total) and there’s a high likelihood it will be captured by a small handful of unique users, which may limit the marketing/awareness benefits of targeting other communities.

This makes sense. I don’t think there’s a perfect solution here. Some thoughts below:

Goals:

  • Meet the System Cap for each Epoch
  • Have as much unique users as possible participate within each Epoch
  • Have as much unique users as possible participate across Epohs

Risk

  • Have a small amount of unique users filling the System Cap each Epoch (multiple addresses for those users), and epoch to epoch

Potential mitigation

  • Have a ‘sign-up phase’. There’s an x week period where whitelist addresses can ‘sign-up’, indicate that they’re interested in participating. update: could ofc also do without the signer phase, just random pick unique addresses from the total whitelist for all of the epochs, and add these to the allowlist for phase 1 of the respective epoch
  • Before the program starts, there’s a lottery. For every Epoch there’s x addresses selected.
  • Each Epoch is divided in two phases
  • Phase 1, 3 days: Only the addresses that were selected from the lottery can participate.
  • Phase 2, remainder of the Epoc: All addresses from the original whitelist can participate

I’m not a big fan of this, as it makes things more complex and may reduce engagement. It’s just 1 idea for the identified issue. There could be better options.

2 Likes

Thought about it a bit more and we briefly discussed it in yesterdays TIG call as well.

My initial assumption so far has been that each unique address could only could only qualify for each epoch once. But realizing this isn’t actually stated, one address could make 20 deposits in the current set-up.

What I would like to understand is what is needed from the system perspective. What is considered an ok / sufficient amounts of deposits to be made to consider the test successful.

In the initial proposal, assuming cap is reached, there would have been a min of 5600 deposits over the 8 epochs. In the updated proposal there’s a minimum of 190 deposits. So the difference is quite big, and would like to have confirmed if 190 is considered sufficient, or that another program would be needed for deposits.

I also realize that I wasn’t involved in the discussions between the initial proposal and the updated proposal, so not fully aware of the reasons behind the update, so maybe this has been considered and shot down already.

But maybe a compromise could still be to split the epochs in 2 phases:
Epoch 1-1: Per-Transaction deposit cap low, e.g. 0.005
Epoch 1-2: Per-Transaction deposit cap, 0.025

The numbers in the proposal are drawn from the cap schedule proposed here (An Updated Timeline for the Launch of tBTC v2), which we assume are coming from the tBTC application developers.

1 Like

I have been following this proposal since its inception, and have had conversations with several critical members of the DAO regarding it. I think it is an excellent step for Threshold and I fully support it.

3 Likes

We could use the Web3 pledge signing set as a gate here. It’s at around 180k addresses now.

If that’s too wide, we could join it against swap users to get something tighter.

3 Likes