Providing liquidity with smart contracts

Hi all,

I would like to share with you an idea for a smart contract and would appreciate your feedback.

Alice has Bitcoins and other cryptos but needs urgently fiat to pay her bills. She could sell some BTC but she will lose money as the price fell from the time she bought.

Instead she uses a service that allows her to borrow NuBits for a month in exchange of collateral Bitcoins or other cryptos. The collaterial BTC are locked in a 2-of-2 multisig address where neither she or the service can access alone. The contact has a specific duration e.g. 1 month and she can return the borrowed NBT before the expire to get her locked funds back.

In case she defaults on her obligation (contract expires), the service can use a pre-signed timelocked “expire” transaction to unlock the funds by itself. The collateral is then auctioned to recover the original borrowed amount and the rest is returned to Alice.

This service would be a custodian that the shareholders will elect. The borrowed funds that are returned could be provably burned as fees or recycled for new contracts.

It would be possible for Alice to sell her contract in case she does not have the NuBits or wants to speculate due to the BTC/NBT price fluctuation.

The amount of collateral is decided by an algorithm if the Nubits provider are the Nu shareholders or the users themselves if they give their own NBT. Other parameters that influence the % of the collateral are the contract duration and the interest rate that the borrower pays.


  • While it is impossible for the service to steal the coins from Alice without her consent, it is possible that the service refuses to co-sign her closing contract and wait for it to expire.
  • If the contract expires, there is no guarantee that the service will be honest and return to her the coins left from the auction.
  • In case the service’s private keys are compromised by Malice, she could spend the contract without returning the borrowed funds.
  • The contract transaction ID changes thus the refund transaction becomes invalid and the service cannot make an auction of the expired contract. Worst case the service could lose Nubits.
  • Alice sends coins to the contract but the service does not send her NuBits

To improve the security of the contract, a special script can be created that requires Alice’s signature plus 2-of-3 service signatures that we call oracles (they should belong to different custodians). Another characteristic that we want is the contract to remain inactive until Alice spends her Nubits.

To solve the situation where Alice sends Bitcoins to the contract but the service fails to send her NuBits, we add an Atomic cross-chain transfer feature to the contract. It works with Alice picking a secret value X and the hash of X is used in both the NuBits and Bitcoin transactions in a way that to spend them the original value X must be revealed. Both the transactions have a timeout so both parties can be refunded if the exchange was unsucessful. So when Alice spends the NuBits transaction, she reveals the value X and only then the service can use this value for the expire transaction to become active.

This is the P2SH redeem script of the Bitcoin contract:

HASH160 <hash of secret X> EQUALVERIFY
<Alice's pubkey> CHECKSIGVERIFY
2 <Oracle's pubkey 1> <Oracle's pubkey 2> <Oracle's pubkey 3> 3 OP_CHECKMULTISIG

To spend this output the following script sig is needed:

0 <Oracle's signature 1> <Oracle's signature 2> <Alice's signature> <secret X> <The above redeem script>

The Nubits transaction should have the following P2SH script:

  HASH160 <hash of secret X> EQUALVERIFY
  2 <Oracle's pubkey 1> <Oracle's pubkey 2> <Oracle's pubkey 3> 3 OP_CHECKMULTISIGVERIFY
<Alice's pubkey> CHECKSIG

For Alice to spend this, she must use this script sig:

<Alice's signature> <secret X> 1 <The above redeem script>

Notice that she has to put the secret X in the transaction for it to work and this is how the service learns about this value and thus making the expire transaction spendable after the lock time passes.

For the service a timeout transaction will be created using this script sig:

<Alice's signature> 0 <Oracle's signature 1> <Oracle's signature 2> 0 <The above redeem script>

The above Nubits refund transaction is not perfectly safe due to transaction malleability. It can be solved by modifying the script to allow the oracles to spend the transaction without Alice or not providing a refund transaction for the Bitcoin deposit (can still be refunded by Alice + 2-of-3 oracles), both modifications require some extra trust. Another solution is to use CHECKLOCKTIMEVERIFY when it becomes available on the Nubits blockchain.

The custom smart contract, although not perfect, minimizes the trust needed and increases security compared to a classical exchange.

The downside of the custom scripts is that they are not standard and needs custom signing software. Alice could have a choice between a standard 2-of-2 multisig or the safer 1 + 2-of-3 + secretX contract.

Some more research needs to be done for a generic smart contract communication protocol. It is also possible to run this service/protocol on top of BitMessage or B&C exchange.

Thanks for reading and let me know if this is something of interest and what can be improved. I covered mostly the technical side and would like to know your opinion on how a service like could affect the NuBits liquidity.


Edit: Added a clarification about the collateral and the fact that this protocol can also run on the B&C exchange


Any collateral scheme needs a system to determine appropriate collateralization. You skipped the risk where the collateral rapidly devalues and defaulting becomes economically beneficial over fulfilling the contract. We would need a system to rate the risk in loaning with a particular currency and require the certain level of collateralization (150%? 300%?). Please be aware that the issue of collateralization is a deep one, and that it is the basic bread and butter of bitAssets.

My first thought while reading this was : Is this a proposal for a decentralised exchange or a trust-less lending service?

The title suggest this would be a way to provide liquidity. In which sense? The example you made, on the other hand, makes me think that this kind of contract could use NuBit’s unique ability to control supply for making an otherwise-impossible landing platform.

What is your angle on this?

How do you imagine the auction ?

I also second @Nagalim’s concern over the collateral

Good point, I forgot to write about this risk:

The amount of collateral is a (dynamic) system parameter where it depends on the length of the contract, the how stable the collateral coin is and the interest rate that Alice wishes to pay.

Some examples:

  • a 125% Bitcoin collateral could be used for a 7 days contract with 3% interest rate
  • a 200% Bitcoin collateral could be used for a 7 days contract with 2% interest rate
  • a 300% Bitcoin collateral could be used for a 7 days contract with 1% interest rate
  • a 200% Litecoin collateral could be used for a 1 month contract with 2% interest rate
  • a 300% Dogecoin collateral could be used for a 1 month contract with 1% interest rate

So the more interest rate you pay, the less collateral you need to put. The longer the contract length the more collateral you need.

One solution for this information problem is to allow other users to provide the Nubits and decide by their own how much collateral they are comfortable with, the contract length and the amount of interest rate they want.

So an nbt holder willingly puts up or fulfills an order to loan against a collateral. What do the loaners get if the loan is satisfied according to contract? What does Nu get from the deal, I.e. what stops someone from just executing this contract using B&C signers?

Neither. In an exchange 2 parties want to trade something for something else, in a lending service a borrower does not provide collateral in the short term. Maybe a hedging service?

From the crypto to NBT it is easy to see that it is liquid. From NBT to crypto, when Alice wants to close her contract she can provide the NBT herself and get back her collateral or sell her contract to Bob that has Nubits (Bob pays the borrowed NBT and gets part of the collateral).

A nice characteristic of Nubits is the flexible supply, so Alice would never have to pay a premium to acquire the Nubits back VS to a zero sum system where the USD tokens are fixed and you have to pay a premium to cover your liabilities or face the consequence of automatic liquidation.

It will use a similar smart contract mechanism with a secret X hash locking. Each bidder will choose a secret X value and create a transaction that sends coins to the service. The service cannot spend these transactions because it needs to know each secret X.

When the bidding period is over the service selects the highest bidder and sends him the coins with a secret X hash lock. When the bidder spends their bought part of the collateral they reveal secret X so the service and Alice can get their Nubits and the rest of the collateral respectively.

There is a transaction timeout period in case the bidder disappears (in that case the bidder will face a penalty of having their coins locked for a period like 3 months).

They should get an interest rate. I imagine short term contracts with 300% Bitcoin collateral to have near 0% rate because there is virtually zero risk.

Another trick to spread the risk is to allow monthly payments where the contract transaction is spent to a new contract.

This protocol is so flexible that I don’t see a reason it cannot be integrated to the B&C exchange. I am most interested in the economical soundness and the incentive structure of this contract.

If you’re giving interest then you still need to assess risk. How is this done? Delegates? Voted on the blockchain? Alogrothmically and written into protocol? Central server?

This is an open question.

When the funds are provided by the Nu shareholders the service operators are vulnerable to moral hazard because in a way they are making an investment decision. It could be a hybrid system with shareholder votes + algorithmic analysis of the market.

When the funds are provided by the users themselves, they decide their own risk exposure.

Some contracts will default and the collateral sold will not be enough to fully cover the original amount. Yet the risk is significantly lower than if a loan didn’t have any collateral.

There are cases that even <100% collateral in p2p loans is possible:

  • You know the person
  • You make a legal contract in your local jurisdiction
  • Bitcoin crashed and you expect it’s value to rise
  • The interest rate is high enough to balance the risk

Obviously you cannot take <100% collateral in algorithmic risk assessments with the funds of the shareholders.

1 Like

Are you going to formulate a motion to help realize this?

I am experimenting with various smart contracts and this specific is a thought experiment on how you could create a collateralized USD debt contract based on Nubits.

However I am not sure that this is a good or a useful contract:

  • Are people really willing to give $1.5 in cash to borrow $1 in cash?
  • Is it safe? A speculator borrows 100K NBT and dumps them very fast in the market. This disrupts the peg, creates panic and cheap NBT, that are re-bought to release the locked collateral, making a sizable profit on the way.

@mhps feel free to create a motion to gauge the interest of the shareholders.

Don’t know. Depending on the risk of losing the $0.5 difference. Is it possible to let market decide it (not a suggestion) ?

So far this is too technical for most shareholders. It’s better to describe like this and start discussion among non-technical community members first