---
# System prepended metadata

title: Uncollateralized Debt on Blockchains

---

# Uncollateralized Debt on Blockchains
<!--
This is debt to purchase some asset 

The purchase of the asset has to be atomic 

"governance tokens" over the *purchased aset*

you need to have rights based on ownership of gov tokens so the creditor can regain part or all of their loan if defaulted

You can use on-chain views to check parameters like payment schedule that might give rights for liquidation. On-chain views let you look at contract's storage in a way that does not require emitting a transaction.
-->
## Introduction

Intro/description here 


## "Real-world" Contract Being Emulated
The first iteration should allow for very simple contracts, which include:
- The asset to be purchased, `Asset X` (implicit in this is the loan amount),
- Interest rate, 
- The number of `X Token`s to be minted that tokenise the NFT,
- Loan termination date,
- Repayment schedule
- Required collateral (specified in absolute terms, not percentage)

This can get more advanced over time and with iterations.

## Smart Contract Structure 

There are three main contracts:

1. Initializing contract where people set terms for their contract/Main controller contract that controlls the system
1. A custodial FA2 contract that holds the asset (an NFT), issues the tokens, and holds the collateral.
    - If Alice defaults, `X Token` holders shall be entitled to the tokenized asset as well as a portion of the collateral put up thus far by Alice in order to ensure that the token holders (lenders) receive value greater than their initial capital, the interest paid thus far and a default premium (taken from Alice's initial payment to enter the Initiliazing contract).
    - Alice pays into this contract; `X Token` holders can redeem their tokens for a portion of what she’s paid, effectively transferring more fractional ownership to Alice in return for their tokens;
    - The amount she has to have repaid goes up over time; kept internally 
    - Either lender or borrower can “initialise” a contract
    - Once the deadline is met then they can liquidate her and have partial ownership over this NFT. Someone collects them all etc. The market decides what to do with that.
    - Once Alice has repaid her loan in full, she has full control of the NFT but the FA2 contract stays around until tokens have all been redeemed. At which time, all `X Token`s are burned and the NFT is released.
1. An accompanying AMM optimised for these (similar to Lev's actually $LINK$)
    - these can be thought of as fixed-interest loans
    - or as futures (with some risk)

We will call these three contracts:
1. `init`
2. `fa2`
3. `amm`

## `init`
`double _valueOfAssetX`
`DateTime _expiry`
`double _fixedAPY`
`double _borrowerDeposit`
Possibly:
`Array<DateTime, double> _repaymentSchedule`

## `fa2`
`Oracle _assetXPriceOracle`
`double _totalCurrentRepayment`
`Calculator _outstandingDebt`

## `amm`
`Oracle _assetXPriceOracle`


## Work Flow 

This is the workflow for Alice borrowing funds from Bob to pay for an NFT.

1. Alice triggers an entrypoint in the `init` contract with the terms of the agreement. This spawns `fa2`, which represents a potential agreement for which there exists a market.
2. Bob sees the spawned contract and decides to engage. He triggers an entrypoing in `fa2` and purchases the NFT through `fa2`; his sending of the funds and the purchase of the NFT happen atomically, as well as Alice's `deposit`. The smart contract owns the NFT and Alice's `Deposit`.
3. Alice has a balance to repay and she has to finish repaying it before the deadline. `fa2` has a view that allows people to easily verify that she "owns" the NFT she bought with borrowed money.
4. Bob gets issued the number of tokens in the agreed-upon contract. If there are `n` tokens, each token represents `1/n` of the balance to be repaid. These tokens can be redeemed any time there is money in the
5. Alice can repay at any time***; this contributes to the balance to be repaid, which goes up over time (representing interest) {RA: I don't think this works. If she can pay at any time, she can wait until one day before maturity, having accumulated her loan repayment and can review whether it is in her interest to pay back. It might be optimal to lose her collateral and purchase the NFT on the open market. See Problems at end. I think a payment schedule to mitigate against slippage might be required. It also provides confidence that there is a (somehat) liquid market for `Token X`}
6. If Alice repays the entire balance, then she can redeem the NFT and fully owns it.
7. If the deadline comes and Alice hasn't repaid her loan in full then ownership of the NFT transfers to token-holders. Token holders can still redeem their tokens for any remaining balance in the contract; they are also eligible to claim the deposit. 
    - Any single party that owns a number of tokens representing the outstanding loan balance can redeem the NFT and has full ownership. {RA - this seems unfair to Alice.. e.g. She has repaid 90% of her loan and then someone recognises she made a smart investment and `Asset X` is worth more than the loan value so redeems the NFT (returning Alice her full balance)?}

## Secondary Market
This model opens up the possibility of a secondary market representing futures contracts or fixed-yield assets. Token-holders can sell and trade their tokens. Price will (presumably) depend on the deadline, repayment schedule, and their assessment of the likelihood of repayment, though crucially not the value of the underlying, as that (from `fa2`'s perspective) is fixed.

Traders will likely wait to redeem their tokens until Alice has either defaulted or waited the maximal amount of time to pay off her debt (and thus accrued the most interest). If they redeem their tokens for XTZ too early they may not benefit from accrued interest; however, if they wait too late they may be caught in a bidding war over the NFT or may find it difficult to sell off their tokens.

This will trigger lots of interesting market behaviour that is worth exploring more in depth.

## Self-Arbitrage 
A potential attack would be for Alice to buy up `Token X` on a secondary market and then default on her own loan. However, if you do the calculation, this doesn't make sense for Alice and any potential profits get cancelled out. 

TODO: Do calculations here and justify this.
Pseudo calc:
In `fe2` we have n `X Tokens` and the contract is worth `nY` capital, making each `X Token` worth `Y` capital.

If Alice is able to purchase tokens on the free market for less than `Y` then this is clearly better than her debt, however this would require someone to purchase `X Token`s within `fa2` at `Y` and then sell them for < `Y`, which is arb (though could happen). Arbitrageurs would thus guarantee the free market value is >= `Y`.

Thus, Alice is only able to purchase tokens on the free market for more than `Y`. In this case, she is essentially paying more for `X Token`s than she has to, as `fa2` allows her to pay just `Y` per token. This makes no economic sense for Alice.

## Adversarial Behaviour 

If Alice misbehaves (defaults) then token-holders get control of her NFT. Further, her `Deposit` shall be paid out to token holders as recompense for their lost yield.

How can Bob misbehave? The inital transactionis atomic, meaning that the purchase of the NFT and the funds to purchase it are swapped in one single transaction. Also, Alice doesn't need Bob's permission to access the NFT if she's paid off her debt. Bob also has no power over the NFT until Alice defaults.

Any other situations? Can we prove there are no more?

## Generalizing 

To be useful, other contracts have to recognize that Alice owns this NFT while it's bought under collateral. Any rights given to an NFT-owner should be extended to her and would be easy to access through the contract's view that shows ownership.

This can also be extended to more "real-world" contracts. It would be nice to make it possible for people to configure and add their own "real-world" contracts, whether if that's through an off-chain voting mechanism liek with a DAO, or through some on-chain entrypont to the `init` contract that allows people to add contracts.
- For example, one possible way to generalize this would be to allow people to specify conditions for default. These would be boolean values that would be constitute a value in the contract storage `HAS_DEFAULTED`.

## Gloassary

See contracts section for variable names.
- `Asset X`/`The NFT` the asset to be purchased with the debt.
- `X Token` the fractional ownership tokens of `Asset X` that Alice purchases over the course of the contract.
- `Custodial ownership` the party that owns a given asset from the perspective of who has paid for it. The Custodial ownership of X Tokens shall slowly shift from Bob (or his secondary market participants) to Alice as she makes repayments. Custodial ownership is a useful concept for calculating who is owed what in the event of default or contract termination (with the simple case being Alice owns every `X Token` that was created).
- `Recognised ownership` from an outsiders perspective, who owns asset X. This would be both Alice and Bob until termination of the contract.
- `Deposit` the cash amount Alice offers as a down payment for the contract - the over collateralisation. In event of default, Bob would redeem 100% of the NFT + additional capital from the `Deposit` as recompense.

## Problems

1. What if the value of the NFT drops below the value of the total of all Alice's payments? e.g. On 1st of month, the `fe2` is entered with `Asset X` value $100 and `Deposit` of $20. The folowing day, `Asset X` drops to $75. Now Alice should default, losing her $20 but being in a position where she can purchase `Asset X` for $75, for a net cost of $95 < $100. `Asset X` must either meet some requirements about uniqueness or volatility. Either that, or a price oracle must be built into `fe2` that liquidates Alice as soon as $NFT < 0.9*$`fe2`, so that Bob is guaranteed to receive at least what he loaned + Alice's over collateral recompense payment.
