CP-000 Request for funding thUSD smart contract development


This proposal is for the Threshold Network DAO to fund the smart contract development of a decentralized stable coin with decentralized collateral.

Agoristen proposed a Liquity fork with the following high level changes:

  • No governance token.
  • Fees accruing as Protocol Controlled Value for the Threshold Network DAO.
  • Accepts TBTC as collateral.
  • Interest rate.
  • An initial loan against the protocols future fees will be minted for use by the Protocol Controlled Value in the stability pool, see the docs below for more details.
  • Some upgradable components.

The goal is that like the initial version of uniswap the usage will be driven by utility not tokenomics.

A task force was established to work on how Threshold USD should work, you can read more details here

So What?

Allowing TBTC holders to borrow stables against their bitcoin should increase the TVL in TBTC as bitcoin holders can participate in defi without having to swap to WBTC first.

Who Cares?

T holders will benefit from

  • The TBTC TVL is an important metric for integrating with larger defi protocols.
  • Fee’s from the loans would go to the Threshold Network treasury.

Why Us?

You can read about my experience as a developer on LinkedIn (I have a nice collection of recommendations), my friend Shawn worked on Wallet & Apple Pay, Apple Card and Apple Cash and currently works for a bank.

Project Risks

Risk: Overcoming Impermanent Loss (IL)

To function correctly requires being able to acquire thUSD to close under collateralized TBTC positions. A TBTC to thUSD pool would be subject to IL, since there will be no token to subsidize the IL.


The Threshold Network DAO would establish

  • POL in a pegged BTC pool with TBTC.
  • POL in a stable pool with thUSD.

Risk: Insufficient Depth

Without a yield, pools are unlikely to achieve sufficient depth to be useful. Accumulating sufficient POL to provide the depth is a longer term strategy. This requires a short term incentive.


The Threshold Network Treasury has a strategy to diversify into assets that include gauge weight so the DAO can create a yield for LPs in pools related to Threshold Network without needing an ongoing T subsidy. The DAO is building a CVX and CRV position through its T - ETH POL, A similar strategy that was used to bootstrap this liquidity could be applied.

Risk: Getting value for the DAO

Software development is notorious for scope creep, running over time and over budget.


Representatives of the Threshold DAO would

  • Review logged hours against high level tasks in clockify.me
  • Guild members would have to approve the hours on a fortnightly basis.
  • As the original champion for the project Agoristen would be the product owner and prioritize and approve work.
  • The mechanics in this agreement would be reviewed and need to be reapproved as part of the Q2 budget.

Risk: Scope creep

There are a number of non-trivial changes to the Liquity protocol, which opens the door to deep research and modeling.


The scope of this work would be limited to smart contract development, testing and deployment.

  • Economic modeling and risk assessment would be outsourced by the DAO separately with a strong preference to the teams that Liquity worked with.

Risk: MVP Development Risks

There needs to be a balance between shipping code in a timely manner and shipping safe code. The more complicated additions are in how the Protocol Controlled Value works.


  • Having portions of the code be upgradeable with a time delay.
  • External DAO funded code audits.

Risk: Rugging funds

Having upgradeable components puts the funds at risk of being stolen through a malicious upgrade.


  • Upgrades approved by the DAO.
  • Upgrades having a time delay before being able to be applied.
  • The Threshold Council can veto malicious upgrades if sufficient votes were able to be obtained.


This proposal is for two smart contract developers.

  • Rate $1,100 USD per day (8 hours) per developer paid in T tokens.
    • T token price taken as the global average price as recorded on coingecko for the day that the work was completed.
  • Hours reviewed and approved fortnightly.
  • Tokens transferred monthly.
  • Contributor Mining Pilot with the option to lock the T tokens for a multiplier
    • 6 months for 1.2x
    • 12 months for 1.5x
    • 24 months for 2x


Q: How long will it take to build?
A: Difficult to estimate, this is why an Agile software development approach will be used.

Q: Would you consider doing it cheaper?
A: No.

Q: What are these multipliers about?
A: The goal is to align contributors’ long term success with the project’s long term success.

Q: When can you start?
A: When a vote passes and a review team is selected and approved.

Q: How many days a week can you commit?
A: 4

Q: If the scope grows larger than anticipated, what is the worst case max spend the DAO is committing to before the DAO would vote to approve again?
A: 4 days x 6 weeks x $1100 USD x 2 (2 year lock up multiplier) x 2 people = $105,600 USD

Q: What about the front end?
A: A* is going to put together a design doc with an overview, technical details and scope for a funding proposal.

Q: Does this proposal include the cost of auditing?
A: No. Cost TBD.

Q: Have you built a simulation for the economic model changes?
A: No. External risk assessment to be done by Gauntlet or similar, cost TBD.

Q: How much experience with smart contracts do you have?
A: We haven’t deployed anything to Ethereum mainnet, I have written some Hyperledger Fabric smart contracts. Anything considered learning wouldn’t be included in the logged time.


I’m all for it. I think this is an essential Lego-block for Bitcoin defi and this would add tremendous value to BTC whales looking to leverage their holdings in a non-custodial manner. More so, this would add value to the threshold ecosystem. One question and some more info:

Question: Would you consider working with more developers to expedite the process?

More info: If desirable, I can help coordinate a security review (as an industry, I think we’re all trying to move away from ‘audit’ language) through Spearbit DAO. Depending on the complexity, this will cost around $50-100k and will take approximately 2-4 weeks to complete from engagement. Alternatively, we can explore a ‘security consulting’ strategy, which is more of an ongoing process.

Disclosure: I am a member of Spearbit DAO and have a stake in the organization.


I’m definitely for it.

  • Having more use cases for tBTC is essential for its growth and adoption.
  • Having a decentralized stablecoin collateralized with tBTC -decentralized bitcoin-peg on Ethereum- is needed.
  • Huge plus for Threshold Network is it means another really interesting income source for its Treasury.

Just to expand data to make a well informed decision:
thUSD project would have this four expense buckets ?

  • SC development (this proposal)
  • FE development
  • Security Audits
  • Economic Assesment

Are there more ?
When should we have rough estimates on this 4 ?


Question: Would you consider working with more developers to expedite the process?

On the initial development of the smart contracts, no.

In the same way that 9 women cant make a baby in 1 month, more developers doesn’t always mean faster development. The process of forming, storming, norming and performing in a new team takes time and can be hard to do when everyone is remote.

On QA, security review, economic modelling, yes.

I would defer to @maclane and @mhluongo on selecting external parties to do a security review.


Are there more ?

There are also the deployment costs.

When should we have rough estimates on this 4 ?

For the FE development A* had indicated a fixed price around $36k USD, however having a fixed price requires a design doc to scope exactly what is included, how feature requests and revisions would be handled to manage the risks of scope creep and expectations being met.

For the Security Audits and Economic Assessment costs I think it will depend on how different the fork ends up being and if the original assessors are available.

1 Like

This could be a very good additional project to provide utility to tBTC from the get go. I support this proposal.

As a suggestion for when this project is delivered (i.e. in a couple of months), in addition of the Curve Pool for thUSD, we should aim to have thUSD as Collateral in Lending Protocols (e.g. AAVE, Compound) to allow for additional disposition and easy retrieval by users if they have to pay off debt due to Collateral Ratio coming down. This would help further with keeping the peg of thUSD to other StableCoins.

1 Like

Can you elaborate on what’s the smart contract development experience of the proposed team? This is a far from simple project, even considering the Liquity repo is open-source.


I like this idea. I wonder whether it’s the kind of thing that someone (or more) on one/both teams could provide input/guidance on, per David’s point/question.

1 Like

Can you elaborate on what’s the smart contract development experience of the proposed team

I built a prototype for a supply chain startup using Hyperledger Fabric, you can read the user story here. The TLDR is that food fraud is an issue in China for 5 star restaurants that want to source lobsters from Australia. Most parties in the supply chain only know the next person in the chain not the whole chain.

You can view an animated gif of the interactions between the real world and the blockchain oracles throughout the supply chain.

The prototype was built on Hyperledger Fabric as a permissioned chain and it supports having multiple private chains in the same ecosystem. The smart contracts were relatively straight forward, mostly just validating and recording data from trusted oracles in the supply chain about the; Tag, User, Fisher, Location, Lobster, Lobster Weight, Event, Packing Case, Packing Link.

The long term goal was for any participant in the supply chain to be able to provide a Verifiable Credential that allowed the owner to prove things like “I have dealt with 8 customers with similar needs to you for greater than 1 year each and 7 are still customers”, without providing the data.

The biggest coding challenge was designing the architecture to accomodate the order of transactions being executed being unknown and not being able to modify the same data structure twice in the same block of transactions. This became problematic when high volumes of transactions were being put through and multiple steps in the supply chain happened together (e.g. weighing and boxing).

Most of the technical challenges where in bootstrapping the nodes in a supply chain.

Each node has a local Membership Service Provider (MSP) and each node has a self signed certificate. The MSP is just a list of certificates that the node knows it can trust, since they are all self signed it requires an initial key ceremony to get things up and running (which was missing from the docs at the time, all the managed service providers only allowed nodes that where within the same service provider).

In the Hyperledger Fabric architecture you have orderers to build the blocks of transactions, they have a leader with followers for redundancy. The orderer nodes are kept in sync using a Kafka cluster and ZooKeeper. ZooKeeper is used for querying which Kafka broker is leader. Each of the supply chains is on a seperate partition in Kafka. This all made for a lot of docker containers to develop against locally.

This is a far from simple project, even considering the Liquity repo is open-source.

I agree there will be complexity which is why our preference is based on time spent rather than a fixed price.

I proposed logging time and summary tasks with a review by DAO members to ensure that the DAO isn’t paying for learning.

If you or other team members have bandwidth we would welcome feedback / code review.


I would like to suggest 3 members from the community to represent the DAO in reviewing progress on a fortnightly basis, perhaps one from each team and the community. Any volunteers?

1 Like

Snapshot vote