TIP-077 Fund request to Threshold Pool: every holders can stake T

TIP-077 Fund request to Threshold Pool application: every holders can stake T

TIP Number and Title: TIP-077

Vote Type: Token Holder Governor Bravo

DAO Elected Representative Sponsor: Luna5, Ashley

Introduction

The proposal addresses challenges faced by limited T token activities due to staking limitations. To overcome this, the proposal suggests developing a proxy contract within the T network that can calculate staking contributions from multiple individuals under one account. It includes fair measurement and distribution logic within the contract, request audits to ensure integrity, and develop a staking dashboard UI for easy delegation would enhance accessibility, ultimately fostering a more vibrant ecosystem.

Pain Points

  • Small shareholders holding less than 40,000 T tokens cannot participate in staking
  • Token utilization faces hurdles because one account cannot receive staking from multiple individuals.
  • Participating in staking becomes challenging for those without development knowledge as stakers must personally operate nodes.

Solution

The staking system ideas from DPoS projects are adopted.

  • A proxy contract capable of calculating staking contributions from multiple individuals under one account will be developed and open to public for anyone to use.
  • The contract includes a logic to measure and distribute rewards on a monthly basis, with binaries or scripts to execute this process.
  • Request audits to ensure the proper development of the above logic.
  • A Staking dashboard UI will be developed to allow T holders to easily monitor the uptime of nodes operating on this contract and delegate their stakes accordingly.

Contract Operation

Basic introduction

  • The contract is already developed and is currently being operated on the contract 0xC1d2fddF9AbE7b3B56d97729139D1f46bD0DA530. It only needs some enhancements and audits.
  • A node operator needs 40,000 T tokens staking for node operation.
  • Basically, a user’s monthly reward is calculated by the formula above

Detail description

Limitation of the current T staking contract

  • In case of staking, it is applied immediately by holder request.
  • In case of unstaking, unstaking delay(unauthorization delay) counts from the unstaking request, and neither additional staking nor unstaking is possible.

Staking and distribution logic of T pool contract

  • User staking/unstaking requests are aggregated and executed once monthly.
  • If staking amount > unstaking amount:
    • Stake the difference between staking and unstaking amounts.
    • The remainder changes as claimable for unstakers.
  • If staking amount < unstaking amount:
    • Executes unstaking for the remainders
    • Staking requests initiated after the unstaking delay cannot apply to the pool. Instead, distribute the staking reward to new stakers in place of the unstakers.
    • Unstaking requests cannot proceed if the current pool is in an unstaking state.
  • A snapshot of current staking/unstaking statuses is taken at 00:00 UTC on the last day of each month.
  • The default reward distribution ratio is Staker : Operator : DAO = 89% : 10% : 1%. The DAO portion remains fixed, while node commission is adjustable by node operators.
  • Additional features include:
    • A node operator can register or remove Threshold applications. It affects the unauthorization delay of each node
    • Unauthorization delay is calculated automatically upon Threshold application addition or removal.

Development items

Contract

  • Add T DAO reward portion
  • Implement additional settlements within the period
    • Assumed the merkle distribution executed once per month.
    • However, occasional instances of merkle distribution may occur due to discrepancies in distribution amounts or bonus allocations.
    • Implement to enable additional allocations within the period in spite of once settlement has been performed.
  • Implement monthly snapshot scheduler
  • Request an audit

Product: Node dashboard

  • Display of statistics:
    • Uptime
    • Apps integrated within Threshold.
    • Unauthorization delay (Unstaking delay)
    • Total staking amount of the operator.
    • Self-staking ratio of the operator
    • Staking/unstaking amounts requested for the next period.
  • Staking/Reward Statistics
    • Estimated reward based on the previous month’s reward
    • User’s staking ratio compared to total staking
    • Staking interface
    • Claim interface
  • Wallet integration options

Roadmap

Design

  • D+1 weeks: Design research
  • D+2 ~ D+3 weeks: Brief design, fix displaying contents
  • D+4 weeks: Finalize layout.

Frontend

  • D+1 ~ D+4 weeks: Component development
  • D+5 ~ D+7 weeks: Logic and layout development
  • D+8 weeks: QA

Contract

  • D+1 week: Development of enhancements
  • D+2 weeks: Initial Audit
  • D+3 to D+5 weeks: Feedback and confirmation audit, deployment of upgrades.

Budget

Total USD 40K

  • It includes the audit and a part of the development cost
  • We’ll make the rest of the development cost from the commission

Future plan

  • List more operators and make users can choose their staking nodes
  • Make the staked share as a liquid staking token (would be ERC721)
  • Make the contract as factory form and any operator can get their proxy account by factory contract execution
    • Easy to get the operator list easier way in the dashboard side
    • Easy to get the proxy account of the operator side
3 Likes

This is AMAZING: thank you @delightlabs_io for the research and development - in particular I am grateful that you have developed this for any operator wanting to run a pool and with an ethos aligned with the Threshold DAO.

Comments:

  • I’m curious if you have any thoughts to how you see governance of a given proxy contract? Is this deployed by the operator? If so, are there any malicious things that the operator could do as the deployer of the contract?
  • It is unfortunate that application auth is up to the operator but I understand the complexities and don’t think it’s a dealbreaker. Worst case is Operator is not on top of auth/top-ups and stakers can move to a different operator
  • Sorry if I missed it, but what does compounding look like from the staker’s perspective? Is it up to the Operator? (compounding = claim rewards + top-up + authorize apps)

Regarding the 40K USD for this work, I am 100% in favor and think it is worth every penny to unlock staking for smaller holders and boostrap a DPoS ecosystem of operators and stakers.

2 Likes

(post deleted by author)

Hi shoegazer69 :slight_smile:

Thank you for your interest and my replies are below:

  • I’m curious if you have any thoughts to how you see governance of a given proxy contract? Is this deployed by the operator? If so, are there any malicious things that the operator could do as the deployer of the contract?
    → Thank you for your feedback! I’ll put it on the item
  • It is unfortunate that application auth is up to the operator but I understand the complexities and don’t think it’s a dealbreaker. Worst case is Operator is not on top of auth/top-ups and stakers can move to a different operator
    → We considered the policy between that the operators should follow all apps but unauthorization delay should be the max one, and operator can make the optimal choice. And we choose to believe operators. Instead, the dashboard would show which app they authorized.
  • Sorry if I missed it, but what does compounding look like from the staker’s perspective? Is it up to the Operator? (compounding = claim rewards + top-up + authorize apps)
    → Nope. You just claim the reward and restake it. Would no effect on the first and second month, but from the third month the effective staking would rise every month.

is this a commission on every node/delegation using the platform? or just from nodes that delightlabs will run?

Each node operator takes the commission

The contract has a setting for operator commission. Any operator can deploy their contract, setting the commission. I believe what @delightlabs_io is saying is that their commission will cover their costs for R&D of the contract. Since they will most likely be the first to support T staking through this contract, their costs should hopefully be covered through the commission they collect. I foresee them being the only operator to support T staking through this method for a while.

2 Likes

Thanks for taking the initiative write the contract and propose this, @delightlabs_io! We’ve long wanted to bring token holders with smaller amounts into staking, and it was good speaking with you recently.

I’m not familiar with your business model, but a few questions:

  • Might it work (if others agree) for the DAO reward % to be a bit higher, allowing us to recoup the cost in a shorter amount of time (something that would likely be a goal of a future grant program)?
  • IIRC, the original idea was to propose Threshold DAO funding the audit, with development provided by Delight. Did the scope expand? (I’m not opposed to funding development; thinking about the recycling of funds noted above.)

Thanks

2 Likes

Hey @delightlabs_io, thank you for this proposal. I think this will be a great enabler for node operators and T hodlrs alike.

My questions relate to the Dashboard.

  • Will Delight labs host and control the dashboard, or will ownership be passed to the DAO?
  • If I understand correctly, Delight will launch as the only delegate on the dashboard to begin with, to recoup initial costs. How long do you expect this exclusivity period to last?
  • What is the rough total cost Delight is seeking to recoup from commission?

In the interests of decentralization, I’d prefer to see multiple delegate options live from Day 1, and the DAO cover Delight’s cost directly. At the very least, it would be great to define the exclusivity term, at the end of which new delegates will be added to the dashboard.

2 Likes

I’d also like to hear more about the process for increasing the pool of potential delegates. And I’m going to put myself forward as one of the initial options :slight_smile:

2 Likes
  • Might it work (if others agree) for the DAO reward % to be a bit higher, allowing us to recoup the cost in a shorter amount of time (something that would likely be a goal of a future grant program)?
    → If 10%, it would be a little bit high, but we or community could talk about the better initial number :slight_smile:

  • IIRC, the original idea was to propose Threshold DAO funding the audit, with development provided by Delight. Did the scope expand? (I’m not opposed to funding development; thinking about the recycling of funds noted above.)
    → Not opposed to recycling funding. In this case, happy to onboard more operators for enough funding

  • Will Delight labs host and control the dashboard, or will ownership be passed to the DAO?
    → It’s not stated in the proposal and good question. It could be some options. If DAO has its own infra in AWS, GCP, or Azure, we can construct CD and the dashboard automatically updates by code change (change could be from others - I belive that the repo of dashboard will be opened to the public)
    The main purpose of “control” would be operator listing. In the section Furue plan, you may see Make the contract as factory. It means that the operator list is not managed by dashboard, but real-time listing by register method execution of the factory contract - more decentalized way.

  • If I understand correctly, Delight will launch as the only delegate on the dashboard to begin with, to recoup initial costs. How long do you expect this exclusivity period to last?
    → If community has intererst on it, we think we can only stand in a couple of month our alone.
    Exclusivity doesn’t mean more income if there’s no community interest, I think

  • What is the rough total cost Delight is seeking to recoup from commission?
    → Expect to cover the salary of T pool product developers in early stage (would be around USD 40K)

Welcome to our bootstraping operators, in advance :slight_smile:

2 Likes