TIP-040: tBTCv2 Liquidity Mining for Guarded Launch

[Mr_T]

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:

• T stakers
• Liquid T holders with a balance >= 100,000 T
• lobsterdao NFT holders (https://www.lobsterdao.io/)
• DegenScore Beacon soulbound token holders (https://degenscore.com/)
• tBTCv1 minters
• veCRV holders
• Tally users (as per some TBD metric)

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)?

[Naxsun]

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?

[Mr_T]

@Naxsun

From my understanding this is focussing on (stress) testing the deposit flow, and not yet on the redemption flow.

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.

@Naxsun

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

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.

[Mr_T]

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.

[Mr_T]

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.

[Naxsun]

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.

[Naxsun]

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

[Mr_T]

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.

[ZeroInFo56]

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.

[mhluongo]

@Mr_T

Tally users (as per some TBD metric)

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.

[Mr_T]

The shutdown of renBTC means there is currently no permissionless BTC bridge with meaningful utilization in DeFi. Due to this, it’s likely tBTC can capture significant market share organically, without incentives.

Coupled with optimistic minting enabling an uncapped, rather than a guarded launch, we no longer believe the previously described incentivized minting program is appropriate.

However, the strategy of targeting specific communities of DeFi power users/influencers/thought leaders that are not currently engaged with the Threshold community is still valuable. Additionally, there’s value in increasing the number of tBTC nodes at launch.

We propose a modification to the liquidity mining program to incentivize running tBTC nodes, targeted towards the following communities:

• LobsterDAO NFT holders (1,891 unique addresses)
• DegenScore Beacon NFT holders (2,210 unique addresses)
• Ren Dark Node Operators (DNO) (1,957 registered nodes) **

Eligible users would be able to earn a minimum stake in T (40,000 tokens) by operating a tBTC node and meeting uptime+liveness requirements for at least 3 months.

Open Questions

• What other (if any) communities should be included in this program?
• Should only currently registered Ren DNOs be eligible? Or historical ones as well?
• Is 3 months an appropriate minimum? Or should it be longer?
• Should the base reward be higher than 40,000 T?
• Should there be a way for eligible participants to earn more than the minimum stake? If so, under what mechanism?
• Should eligible users who LP a minimum amount of tBTC in a qualified pool (e.g. Curve) also be incentivized? Should this be in addition to running a node? Or should it be possible for eligible users to earn an LP reward without also running a node?

---

** Please note that Ren has a staking cap, which requires stakers to distribute their tokens across multiple nodes after a certain threshold. This means the number of unique stakers is some lower amount than the 1,957 registered nodes.

[Eastban]

Thanks for this idea ! I really like it. We’ve been discussing it today in the IG call and want to come up with a plan.

[jakelynch]

Thanks for adapting the proposal proactively.

The one addition I would add is that we should cap the amount that gets paid out.
40k T across 6k nodes would be ~25% of the DAO’s treasury.

Since this is a meaningful objective, I’d recommend we target the optimal amount (maybe @beaushinkle can share here).

[beaushinkle]

@jakelynch

The one addition I would add is that we should cap the amount that gets paid out.
40k T across 6k nodes would be ~25% of the DAO’s treasury.

Since this is a meaningful objective, I’d recommend we target the optimal amount (maybe @beaushinkle can share here).

Sorry this took me a bit to get to!

Here’s what I have: Staking Calcs - Google Sheets [1]

Say we give folks 40k T (which costs $640 at the time of writing) and they Stake. After a year of staking, they get their stable-yield of 15%, which is $96, or $8/mo. Current estimates (reflected in the picture) are that running a full node on Threshold will cost somewhere between $200 to $300 a month if you do it efficiently. So by giving someone the min-stake, and then asking them to pay for a node, they lose about $292 a month.

Rewards scale with investment but the cost of running the node is constant. We break even at $24k in T (the price of T does not matter; but this is 1.5M T at the current price).

Considering the cost of running a node, an operator hits 10% APR when they’ve put in $72k worth of T (4.5M T at current prices) [2].

There’s a couple of things we can do about this in broad strokes.

• We can juice up rewards [3]
• We can subsidize costs

For instance, at 20% yield instead of 15%, the break-even stake goes from 24k to 18k. The 10% APR stake goes from $72k to $36k.

If running a node costs $100/mo instead of $300 (a $200/mo subsidy), then the breakeven-stake goes from $24k to $8k. The 10% APR stake goes from $72k to $24k.

If we do both, then the breakeven-stake goes from $24k to $6k. The 10% APR stake goes from $72k to $12k.

---

[1]: I started this from a sheet Will linked me that was owned by Derek. Thanks!

[2]: This is strictly considering stable-yield rewards since what happens to the TBTC fees is up to the treasury. My suggestion: use the fees to become a liquidity provider in TBTC:ETH since that helps provide deep liquidity and enables a route for TBTC → ETH → USDC (or whatever stable), but has less impermanent loss (since BTC is correlated with ETH). The TBTC:USDC pair is important for folks looking to use TBTC to lever up on BTC.

[3]: I noticed yesterday that we don’t seem to be using the constant from the original stable yield proposal. The proposed calculation for issuance was issuance = target_yield * supply * max(staking_rate, constant). If constant = 0.5, then at our current stake amount of ~3B, and supply of 10B, we would issue 0.15 * 10B * 0.5 = .75B, which against 3B staked is 25% APR. Let’s encourage some more staking!

[FarthingDreadful]

Hi Beau,
Curious what your infra looks like at $300. I’m coming way under at the moment when running both services. Not sure what S3 costs for backup will look like with utilization. Right now they’re obviously minimal.

[beaushinkle]

Waiting to hear back from Piotr (he knows more about what we specifically need than I do), but here’s some ideas:

• I’m looking at the ec2 prices for a1.2xlarge, which run at ~$150/mo for on-demand or $1051 for a year paid up front ($88/mo).
• Need storage (each signer needs to store every message they’ve signed for months in order to refute fake fraud challenges); my guess here is around $20/mo
• The free infura/alchemy plans won’t cut it, so looking at somewhere between $30 and $50 for that
• Need to run a second, baby-sized node in order to monitor/report on the main node. Probably $15/mo

Adding that all up we get to low: $153, high: $235

There are almost certainly ways to cut costs here or find cheaper providers; but that’s roughly what I’m looking at! I’ll get back when I have better system requirements/more info from Piotr

[nico186]

Thank you Beau, this is very informative and raises an important consideration.

I wanted to mention I was involved in Kyber Network in 2021, as a staker; they had similar issues with staking costing more than the rewards compensated. Their conflict was the sudden rise in Gas, and Kyber is a totally different product as well. However, there might be some lessons learned (from Kyber) that we can glean for our own decision making process.

Of note, Kyber had developed a pretty seamless dashboard making it easy for individuals to onboard and self start. But it was immediately evident people were “paying” to stake, and interest subsequently trailed off.

I think your suggestion of subsidizing stakers is a solution to this undesired outcome because individual stakers could be more likely to stay with our project longer (imo) if they feel supported - both financially, and socially, by the project.

[beaushinkle]

Okay! Piotr got back to me with clarifications.

The documentation is up to date; so we need at least a c5.large, which is 2 vCPU / 2 GB RAM / 1 GiB Persistent Storage.

Additionally, this is just for v2; the same node should not be running the random beacon or PRE.

Some other considerations:

• The larger percentage of the stake you have, the more work your computer does (since you’ll be handling multiple seats on multiple wallets).
• Monitoring should be deployed separately.
• There also needs to be a connection to electrum/bitcoin, especially if TIP-035 doesn’t pass. Right now, blockstream is providing a public electrum endpoint, but we don’t want all of the nodes pointing to the same endpoint or that becomes a point of failure.

[FarthingDreadful]

Thanks Beau. That’s what I’m currently running. I’d recommend running a cron to backup the keep dir to an s3 bucket. I have mine set to a 5 minute backup interval with a 3-day lifecycle. Those values are somewhat arbitrary so I’m interested in opinions on this. I’m also using route53 to run health checks and SNS for alarms. Im curious if there’s any particular metrics that should also be monitored.

[arj]

Just a note on the constant – it was originally envisioned to fulfill three purposes:
(1) Provide an insurance against disorderly exoduses, by rapidly increasing effective APY if the staking rate dropped below a pre-specified, DAO-chosen ‘dangerous’ percentage.
(2) Focus the stable yield mechanism on addressing staking rate scenarios that harm small stakers in the short-term – i.e. elevated staking rates → depressed yields → larger segment of the staker population falling below the break-even stake size. As you detail, this remains an issue due to fixed USD infra costs >> T subsidies converted to USD.
(3) Make the switch from the prevailing ‘dependent variable’ yield model to stable yields psychologically less jarring/unnerving.

I decided to ditch the constant for the first minting proposal, because sticking to a constant 15% yield from genesis avoided over-rewarding early adopters (read: insiders) and unnecessarily ladening sell/depreciation pressure onto the T token (bear market thinking). Moreover, none of the three above arguments were compelling enough; (1) an exodus seemed very unlikely given the foundation of community/client-team commitment to servicing the network, (2) small stakers are still harmed if the protocol over-mints, and (3) the general approval of the stable yield concept meant that this compromise wasn’t necessary to get it over the line.

I not fundamentally against reintroducing variable yields, moderated by a constant, thereby increasing rewards – up until staking rates increase to an ‘acceptable’ level. However, I would question whether this will actually increase the number of genuinely independent stakers, or just be gobbled up by existing large stakers. The staking rate may simply increase because incumbents increase their capacity. Hence I would suggest any changes to reward rates be complemented by:
(i) A concerted marketing & education campaign to convince prospective stakers that the long-term cost-benefit makes sense. Making it easier to spin up a node is one major cost reduction, and the capital efficiency of being exposed to DeFi and Web3 with the same collateral is a unique, huge, underemphasized diversification benefit over longer investment horizons.
(ii) Unearth and detail overhead-reducing (even temporary corner-cutting) strategies for the currently shallow-pocketed.
(iii) Reiterate the business case for betting on medium-term fee-based income – e.g. taking market share from centralized/declining alternatives.