L1 lending/borrowing of native assets and L1 (price) oracles

[lukastanisic99]

Following the discussion on the trustless exchange of native assets ( #42 ), we can introduce a similar approach to L1 Lending/Borrowing and L1 oracles. All using non turing complete smart contracts and as some would say ‘hardcoded logic’.

L1 Lending/Borrowing
We can extend the UTXO model to make it possible for lenders and borrowers to match in a trustless way.
Both lenders and borrower can initialize the process by creating a specific type of UTXO.

A lender can create a lending UTXO that contains the assets that will be lent out.
In the UTXO the lender would define the terms of lending such as:

• the collateral (native asset) that is accepted for the loan,
• the APY – interest rate,
• the interest rate model (e.g. simple interest or compound interests),
• the max duration of the loan,
• the oracles that are used to determine the underlying price of the assets used in the lending/borrowing process,
• the collateral factor,
• the liquidation incentive.

On top of that the lender can also define who can unlock (consume) the UTXO (a specific borrower or any borrower who accepts the conditions).
For the sake of simplicity, we’ll stick to one example even though this UTXO model can have a lot of modifications the same way the trustless exchange of assets has a lot of modifications (see post above).

Once the lending UTXO is created everyone can see it.
A borrower consuming the lending UTXO is essentially agreeing to all its terms (as defined above).
Now the lender and borrower are matched and the UTXO is available for consumption in a few ways.
At any point in time the borrower may repay a portion or the entire loan + interest and by doing so will unlock a portion or the entire collateral.
The UTXO can be consumed by anyone in the process of liquidation – when the borrowers collateral drops bellow the collateral factor measured by the oracles price. The liquidator in that case liquidates a portion or the entire collateral of the borrower by repaying the loan on his behalf and seizing his collateral (liquidation incentive included).
If a borrower doesn’t repay the loan in time as set by the max duration, a liquidator may liquidate him at any point in time after the expiration.
The lender can consume the UTXO to extend the loan duration.

This described a process where the lender created the terms for lending/borrowing, but the same is possible from the perspective of the borrower. A borrower can offer his terms and all lender can see it and can accept it by consuming the UTXO and afterwards same dynamics apply.

How does this compare to the ‘pool’ based model used in Ethereum?

For starters there is no systemic risk – the risk is only between the lender and the borrower. Other participants are not affected.
There is no need for governance to decide which assets can be lent out, used as collateral, the interest rate model, which oracles are used etc...
Everything can be decided between 2 parties and if they choose to accept illiquid assets and untrustworthy oracles the risk is on them, not on the protocol.
This would be implemented on L1 and as such would inherit the full security of L1 and feeless transactions. On top of the already feeless transactions there are no system ‘fees’ as in Compound for instance. There are no liquidity providers, no explicit governance structure, no treasury that takes a % fee. Everything that’s paid by the borrower goes directly to the lender.
This allows for an efficient market to be formed outside the protocol as lenders and borrowers would state their offers and match.

While this approach can be implemented on any chain that uses the UTXO model, it makes more sense to be implemented on IOTA considering the feeless base layer. If a UTXO doesn’t get matched the owner can just consume it and cancel it – feeless. On other chains a fee would have to be paid. We can argue that the fee here would be paid with mana and that’s true, but mana is regenerated.

Pros:

• Fully trustless directly on L1
• Feeless – no transaction fees + no system fees
• Risk only between the specific lender and borrower
• Fully customizable – lenders and borrowers can create their own terms and don’t have to pick from predefined terms created by governance

Cons:

• Race condition – if multiple borrowers/lenders wanted to consume the same UTXO – only one would go through as determined by OTV (On Tangle Voting). This is mitigated by creating new UTXOs. This is an inherent problem to the UTXO model, specifically to a UTXO that can be consumed by multiple parties.

L1 Oracles
While the idea of an oracle is simple, it’s widely needed for many use-cases. Oracles can be implemented in many ways. This post will cover one potential implementation of an oracle that I believe has good characteristics to be used as price oracle on L1 with the UTXO model. Having oracles on L1 could potentially solve most of the oracle problems on L2.

We’ll implement this oracle as a state machine similar to how ISCP works (new UTXO type).
The oracle will be defined by an oracleID and stateIndex.
The oracleID is unique to the oracle (e.g. IOTA/USD oracle) and the stateIndex gets incremented each time the state gets updated.

We won’t discuss who has the right to update the state – that’s to the creator to define. Both single signatures (1 entity) or distributed key generation and Ed25519 schnorr signatures (multi signatures) – as planned for ISCP.

The point of this oracle is to be reused and referenced in multiple places.
The price of IOTA/USD will most likely be used in all DeFi projects building on IOTA and it’s important to have a single source of truth. Updating the price/state would be done in a similar way as in ISCP. You’d consume the old state and produce a new state (UTXO) that has the updated price. This would be a ‘write’ operation, while referencing the data would be a ‘read’ operation.
Multiple entities can read the data at the same time without consuming the UTXO.
Now this becomes a similar problem to the readers/writers problem in concurrent systems, where you could have multiple readers at the same time or a single writer. While the Tangle doesn’t have total order and we won’t use mutual exclusion to protect the shared resource (oracle UTXO) we’ll count on OTV to resolve the race condition and to determine the cutoff between reads and writes.

An example of how this would work in the above scenario regarding Lending/Borrowing and it would work more or less the same for all other use-cases.

We have a liquidator who’s observing the Tangle trying to find UTXOs that can be liquidated.
The liquidator looks at each UTXO to see which oracles do they reference.
The liquidator checks the current price reported by that oracle by doing a read operation on the latest state (this is subjective to the node he uses). Using that price, the liquidator calculates whether the Lending/Borrowing UTXO can be liquidated. If the calculation confirms that a liquidation is possible, the liquidator begins the process of liquidation by consuming the Lending/Borrowing UTXO, providing the payment + interest on the borrowers behalf and references the price he used for doing the calculation by specifying the oracleID and stateIndex of the state that he used in his calculations.
He produces a new UTXO that he believes will resemble the new state of the Lending/Borrowing UTXO after liquidation and posts the transaction to the Tangle.
Now nodes have to vote on the outcome of the transaction. Each node would independently form its opinion in the same way as usual.
The only difference here is the node would see the oracleID+stateIndex referenced by the liquidator and would check locally is that the lates stateIndex for that oracleID? If it is and if all other checks pass the node would vote affirmative on the new UTXO.
If the node is aware of new state with a higher stateIndex for the same oracle the node would dislike the newly created UTXO.
This is done independently by all nodes and they come to consensus by voting.

The state of the oracle can be updated at any point in time and due to the asynchronous nature of the Tangle each node sees transactions in different order. The race condition of what came first, the reference to the old state or the state update is solved by voting – without the need to modify OTV or any other dependencies.

The performance and number of race conditions are highly dependent on the write operation (state updates) on the oracle UTXO.
If updates happen to frequently there would be more race conditions and conflicts, if the state updates take longer then there would be fewer on average (only in those last few seconds).
Considering how Chainlink works today – they post state updates 1-3 times per hour or when 0.5% of the price changes in either direction. Under these real-world circumstances, the oracle would perform really well. Wasp nodes can agree which oracleIDs are of interest to them and on each oracle state update the wasp nodes can come to consensus on the stateIndex and transfer the data to their L2 chains.