Pool Transaction Chaining
Optim’s Liquidity Bonds will use Pool Transaction Chaining in order to enable several smaller actors to pool their liquidity to fulfill one bond request. Pool Transaction Chaining efficiently allows for the submission and sequential ordering of all interactions with a pool’s smart contract without having to wait for each transaction to be included in a block on chain.
An Optim Liquidity Bond is essentially a smart contract that allows for the lending and borrowing of staking rights to ADA. ADA is deposited into a smart contract, a borrower can attach their staking key to the ADA in the contract, and terms such as interest payments and duration are enforced. If terms are broken, the ADA is released from the contract. A lender receives Bond Tokens representing their lending position which are redeemable for underlying ADA + interest at the end of a Bonds duration.
Here is how Pool Transaction Chaining works in the case of an SPO Bond:
User Journey, the steps for pool creation is the following set of actions:
Context
A borrower (SPO) needs an $ADA Liquidity Bond (likely to delegate to themselves). Thus, the SPO puts up a bond borrow offer.
A lender sees the bond offer and wants to lend but their balance is not enough to satisfy the entire bond offer amount by themselves.
The bond tokens can be redeemed for the underlying $ADA plus accrued interest according to the terms of the bond offer at maturity.
The lender can create a lending pool consisting of pool tokens. Other lenders can buy pool tokens from this pool until there are no more pool tokens to buy (the bond has been fully funded).
The pool now contains enough $ADA to satisfy the bond offer.
The pool is matched against the bond offer.
Lenders can now exchange their pool equity tokens for the bond tokens.
On-chain, those steps for Pool Transaction Chaining translate to the following set of actions:
When a lender creates a lending pool consisting of pool tokens, they are essentially minting pool tokens and sending them to UTXO → OpenPool
When a lender buys pool tokens, then UTXO → OpenPool with pool tokens is replaced by UTXO → OpenPool with less pool tokens and more $ADA.
When the lending pool consisting of pool tokens is filled, it is matched against the bond offer. This means, UTXO → OpenPool is spent and its $ADA goes to another UTXO at a different validator. Bond tokens are minted and sent to the UTXO → ClosedPool
When the lender exchanges pool tokens for bond tokens UTXO → ClosedPool with bond tokens is replaced by UTXO → ClosedPool with less bond tokens and more pool tokens.
Mempool: [tx1: (01 -> 22) ; tx2: (02 -> 03) ; tx3 (03 -> 04)]
The pools are identified by the token name of the pool token, and this also exists in the datum. Therefore there should only be 1 UTXO for each pool across both OpenPool and ClosedPool script addresses.
This means that there are pool transactions that (transaction) chaining is useful for:
Buying/Withdrawing pool tokens in a not yet filled (open) pool.
Matching a filled pool against a borrow offer.
Exchanging pool tokens for bond tokens in a filled and matched (closed) pool.
As explained above, transaction Chaining provides a solution for contention that is not centralized in any way. It aggressively orders the transactions before they make it on-chain. Having innovative, decentralized solutions that push transaction speed and leverage Cardano’s unique architecture is necessary to facilitate the ecosystem’s growth and ensure long-term viability.
Last updated
