Stable asset token - incentivized floating peg

[dagurval]

I’ve been playing with the idea of creating a token representing an asset (like USD or GOLD) based on having BCH as collateral. Currently I have only the concept and a contract that compiles, but is sure not to work (it’s currently too large for BCH consensus rules). EDIT: It now fits within consensus rules.

Looking for “concept acks” if the idea is sound.

Contract is hosted here: Dagur Valberg Johannsson / BCH pawnshop contract · GitLab

I’ll post the README below:

Pawnshop contract

Status: Feasibility study

An oracle based contract that lets you borrow tokens representing oracle asset against BCH collateral.

The borrowed tokens would have a “incentivized floating peg” – there are built-in market incentives for the borrowed token to be close to the asset borrowed against.

The contract requires over-collateralization for borrowed asset. When a loan does not fulfill the collateral requirements (due to BCH price going down), then the loan becomes “anyone-can-repay” – anyone willing to repay the tokens can claim the collateral.

Incentives

If the price of the borrowed token is too low, existing borrowers are incentivized to purchase token from the market to repay their loan for below-marked-value.

If the price of the borrowed token is too high, new borrowers are incentivized to take loan to profit from overvalued token.

Note that these incentives may not be sufficient. It is likely that in a bull market that speculators would be willing to borrow “below market value” to gear their investments. In a bear market, borrowers may want to unlock their BCH, competing with others seeking “refuge” in the coin.

Contract

The main contract stores an oracle sequence number in a NFT commitment. The main contract (pawnshop.cash) has two functions:

• updateSequence – this updates the sequence of the oracle message.
  Someone™ has to call this regulary in order for stop malicious borrowers from
  minting tokens based on old price.

• borrow – This lets borrowers lock BCH into a loan contract (loan.cash) and in
  return mint asset token.

The loan contract stores the borrowed amount of asset token in a NFT commitment.
The loan contract has two functions:

• addCollateral – This lets the borrower add more BCH collateral.

• repayLoan – Repay the borrowed tokens and unlock the BCH.
  If there is enough collateral, only the loan holder can repay.
  If there is not enough collateral, anyone can repay.

[dagurval]

I’ve been made aware that this is basically the same thing as https://www.liquity.org/

[tula_s]

1. copying liquity has been discussed before and i believe it is something worth exploring.
2. note that there are more mechanisms in liquity than what you described (stability pool)
3. the need for manual updateSequence seems odd. how does anyhedge check for malicious old price at settlement?

what is different to proposed tokenized anyhedge based stablecoin:

1. anyhedge does not support adding collateral.
2. the long part of the contract (the loan) is expected to be also tradeable, as NFTs.

what is the same:

1. the repayLoan is a special case of “mutual” anyhedge redemption where you own both long and short parts.
2. in case of depeg (<=100% collateral) the stable holder can do one sided redemption without cooperation from the owner of the loan (anyone can repay in your terms, liquidation in anyhedge terms)

[dagurval]

note that there are more mechanisms in liquity than what you described (stability pool)

We could do a staking mechanism for pooling up tokens for collateral sniping too – that’s a different contract

the need for manual updateSequence seems odd. how does anyhedge check for malicious old price at settlement?

It checks timestamp in the message. We could do that (it doesn’t really matter which value we use as long as number goes up – we’re checking if it’s a newer oracle message).

[tula_s]

another difference to liquity is that you dont have the redeem mechanism.
anyhedge also does not have that (that would be the hedger getting unilaterally out of the contract at any time)

this might make your stablecoins slightly less valuable, because it is harder to melt them into the underlying bch. Making the long part (trove ownership) tradeable as NFT could partly compensate for that.

EDIT: in bull market that would make the stablecoin a lot less valuable. im pretty sure you are gonna need to do at least one of those things (redemptions or loan NFTs). The difference between these two is basically that in liquity redemptions the fee is hardcoded, while in the other approach the fee is market based.

[tula_s]

EDIT2: to help this move faster - this is the imo last and most important difference to (tokenized) anyhedge - the depeg threshold (the amount of bch that backs each stable token) is variable over consecutive mints.

overall, i would say split the NFT from the loan utxo and you are good to go.

[MathieuG]

@dagurval

Currently I have only the concept and a contract that compiles,[…] EDIT: It now fits within consensus rules.

Very Cool!

Indeed your concept is similar to the Ethereum Liquity V1 protocol (recently announced V2), which also gives interest-free loans but this version is more stripped-down.
I don’t think the comparisons to tokenized AnyHedge hold up.

If I could rephrase what you made: people lock up BCH in a contract which in turn gives them collateralized tokens. If the collateral value falls below 110% others can liquidate your contract by returning the token amount which earns them up-to a 10% premium, so this results in a 9.09% loss for the person being liquidated.

The advantage of a Liquity-like system is that it does not work with on-chain auctions like Maker-DAO, which take time to resolve and might liquidate at much lower price. This means Liquity-like systems with “instantaneous liquidation” can have a lower minimum-collateral-ratio and hence is more capital efficient.

An unaddressed issue here is what if there is more than a 10% price crash between oracle messages? If the token keeps trading at the intended peg, then this loan would be under-collateralized and it would not be profitable for anybody to return the tokens.

@dagurval

note that there are more mechanisms in liquity than what you described (stability pool)

We could do a staking mechanism for pooling up tokens for collateral sniping too – that’s a different contract

Liquity also has some extra stabilization mechanism built-in:

How can the protocol offer interest-free borrowing?

The protocol charges one-time borrowing and redemption fees that algorithmically adjust based on the last redemption time. For example: If more redemptions are happening (which means LUSD is likely trading at less than 1 USD), the borrowing fee would continue to increase, discouraging borrowing.

[tula_s]

@MathieuG

don’t think the comparisons to tokenized AnyHedge hold up.

which one?

	supports (can support, should support)
	borrow / self mint	addCollateral	repayLoan / self redemption	liquidation	tradeable long	redeem	infinite maturity	constant depeg threshold across troves
anyhedge (tokenized)	yes	no (yes, yes)	no (yes, yes)	yes	yes	no (yes, ?)	no (yes, yes)	yes
pawnshop	yes	yes	yes	yes	no (yes, yes)	no (yes, ?)	yes	no (yes, no?)
liquity	yes	yes	yes	yes	yes	yes	yes	no (yes, no?)

[dagurval]

@tula_s

overall, i would say split the NFT from the loan utxo and you are good to go.

Can’t split it into a free NFT, we need to restrict it in a way that let others repay the loan on low collateral. We could have the BCH collateral in the main loan contract instead of locked in with the NFT, but I don’t see a benefit in doing so. What we can do is add a function to change ownership of the loan, this would make it transferrable (and tradeable in specialized contracts)

@MathieuG

If I could rephrase what you made […]

Thanks for describing it in a much better way

@MathieuG

An unaddressed issue here is what if there is more than a 10% price crash between oracle messages? If the token keeps trading at the intended peg, then this loan would be under-collateralized and it would not be profitable for anybody to return the tokens.

It would be logical for the market to depeg the coin enough to make it profitable to pay off the bad depth – then recover?. But what the market actually would do, I don’t know enough to speculate on.

@MathieuG

The protocol charges one-time borrowing and redemption fees that algorithmically adjust based on the last redemption time.

We could perhaps do something similar. There is room in the commitment of the loan contract to store a weight – it could increase on redemptions and decrease with every “updateSequence” call (increasing sequence being a proxy for time passing)

[tula_s]

@dagurval

Can’t split it into a free NFT, we need to restrict it in a way that let others repay the loan on low collateral.

you have to add a redeem/melt mechanism as i explained above. one way to do that is to enable shorts to buy a long NFT and repay to get the underlying bch. you have two options how to do that - make the NFT free floating (in which case you need specialized sw to check if the nft has any value) or make it covenant bound (in which case you need specialized sw to trade it).

relevant quote from tokenized anyhedge discussion:

3. to further limit scams, the keys to vaults should be single use (burn the key after unlocking the sats)
4. in case of depeg the shorts need to be able to liquidate without cooperation from the long nft holder (because that is near worthless). so we either need the NFTs in covenants or we are at odds with point 3 above

maybe of note is that in case of constant depeg threshold across troves (which i assumed was necessary to make people understand and trust the fungibility of the tokens and the scheme as a whole) having free floating nft tokens with no value is not such a big problem because it is always either all are valid or all are invalid.

[tula_s]

@dagurval

We could perhaps do something similar. There is room in the commitment of the loan contract to store a weight – it could increase on redemptions and decrease with every “updateSequence” call (increasing sequence being a proxy for time passing)

things that come to mind:

1. fully market based vs algorithmic corrections for supply/demand
2. simple vs controller algorithm (RAI – one of the coolest experiments in crypto | Dankrad Feist)
3. minimum viable product vs copying something existing as close as possible vs creating the best possible thing
4. global controlling variables in utxo model are either simple single-thread or require joint execution.
5. tracking an asset as close as possible or reflecting the natural demand for the asset in our particular community as close as possible (example - lets say in some country the demand for dollars is higher, 1 usd on their exchange will trade higher than 1 usd equivalent. Should the local government try to lower the price back to the peg, by some kind of fees?)

[MathieuG]

Thanks for pointing out the importance of the redeem mechanism in Liquity @tula_s.

Various implicit and explicit mechanisms ensure that LUSD will closely follow the price of USD. We call mechanisms that are based on direct arbitrage opportunities “hard peg mechanisms” and call less direct processes “soft peg mechanisms”.

from the Liquity blogpost: “On Price Stability of Liquity”, with a handy graph:

[MathieuG]

Worth posting here that @dagurval is working out his initial concept posted here as ‘Moria Money’, a stablecoin said to launch on BCH this year still.

The project already has a public whitepaper, which can be found on the project’s website: moria.money

Here’s the abstract:

Moria Protocol: A Decentralized Stablecoin and Loan System on Bitcoin Cash

The Moria Protocol is a decentralized, censorship-resistant borrowing
protocol on the Bitcoin Cash (BCH) network, allowing users to borrow
stablecoins backed by BCH collateral. Designed to be capital-efficient and
secure, Moria enables users to access loans while maintaining minimal
collateral requirements. The protocol leverages the Bitcoin Cash UTXO
model and is tailored to operate within its consensus limitations. This
whitepaper provides an in-depth analysis of Moria’s system architecture,
loan processes, collateral management, and potential future developments