Optim Finance
  • INTRODUCTION
    • Introduction
    • Roadmap
  • OADA
    • Overview
    • OADA 🟣 and sOADA 🟢
    • Flow of Funds
    • User Guides
      • Passive yield with sOADA
      • Epoch Stake Auction
    • AMOs
      • Splash DEX AMO
      • Stake Auction AMO
      • Staking AMO
    • UNHCR Donation Module
      • Automated Yield Donation Protocol
      • NFT Impact Certificate
      • Integration with the OADA Ecosystem
      • Humanitarian Partnership
      • Future Extensions
    • Governance
    • Resources
  • OTOKEN Framework
    • Introduction
      • Key Benefits
      • Who is it for?
      • Inspirations & Applications
    • Framework
      • Key Concepts
      • Use Cases
      • OTOKENs
    • Core Concepts
      • OTOKEN and sOTOKEN
      • Algorithmic Market Operations (AMOs)
      • Balancing Stability, Yield, and Adaptability
    • System Architecture
      • OTOKEN Policy
      • Staking AMO
      • Collateral Management AMO
    • Extensions & Other Modules
      • DEX AMO (Liquidity & Peg Stability)
      • Stake Auction AMO
      • Borrowing & Lending AMOs
      • Other AMOs & Opportunities
    • Multiple OTOKEN Deployments
      • Ecosystem Synergy
      • Not Just Synthetic Assets
    • Vision
      • Key Pillars of the OToken Framework
      • Future Directions & Opportunities
      • An Invitation to Innovate
    • Bug Bounty Program
  • LIQUIDITY BONDS
    • Overview
    • Bond App FAQ
    • Use Cases
      • ISPO Bonds
      • SPO Bonds
    • Bond Architecture
      • Validators
      • High Level Workflow
      • Scripts Technical
      • Transaction Flow
      • Pooled Loans
    • Guides for SPOs
      • Bond Creation
      • Bond Sales
      • SPO Bond Issue Summary
      • Bond Verification
    • Liquidity Bonds Audit
  • OUSD
    • OUSD Reserves
      • Reserve Criteria
        • Stability and Reputation
        • Compliance
        • Smart Contract Security
    • Ongoing Reserves Management
      • Reserve Asset Valuation Calculation
      • Dynamic Reserve Asset Adjustment Metrics
        • Dynamic Reserves Adjustment
    • Yield, Staking, and Flow of Funds
      • Yield Modules
        • OUSD DEX AMO
        • Future Modules (v2)
      • Staking AMO
      • sOUSD Redemption Mechanism
    • Peg Protection
      • Market Depth and Liquidity
    • Governance and Risk Framework
      • Risk Capital Requirements
      • First-Loss Capital Structure
      • Asset Allocation Framework
        • Static Governance Parameters
        • Dynamic Allocation System
    • Financial Engineering Audit
  • Leviathan
    • System Architecture
      • Background
      • Concurrency Limitations
      • Complexity in Transaction and Contract Management
    • Core Concepts
      • Deterministic Transaction
        • Guaranteed Transaction
      • Instant Finality
        • Liveness and Safety
        • Probabilistic Finality vs Instant Finality
      • Account Abstraction
        • Concept of Account Abstraction
        • Technical Implementation
        • Security and Operational Implications
      • Intent Based Transactions
        • The Infrastructure and Process of IBTs
        • Declarative Constraints in IBTs
      • Layer 2
        • Types of Layer 2 Solutions
      • Sequencers
        • Core Functions of Sequencers
        • Role in Layer 2 Rollups
        • Challenges
    • System Components
      • Understanding the System Components
      • Optim-Account (Intents to enable tx chain)
        • User Interaction and Intent Submission
        • Intent Structuring and Authentication
        • Smart Contract Functionalities and Operational Parameters
        • The Necessity of an Account-Based Framework
        • Account Abstraction and Its Role in Leviathan
      • Leviathan Sequencer System (tx chain building)
        • The Role of the Leviathan Sequencer System in Conjunction with The Optim Account
        • Sequencing and Ordering of Transactions
        • The Role of Time in the System
        • The Pragmatic Leviathan: Dealing with Potential Changes
      • The Role of OADA in the Leviathan System
        • Operational Simplification of Staking Mechanisms via OADA Integration
        • Facilitating Time Dilation and Composability
    • Processes
      • Entering Leviathan
      • Transaction Execution
      • Leaving Leviathan
    • High Level Overview
      • System Design
        • Account Abstraction Functionality
        • Guaranteed Transactions
        • Instant Finality
        • Unbreakable Transaction Chaining
        • Layer 2 Execution Environment
        • Future Sequencer Network
      • System Context
        • Limitations of current transactions chaining paradigm
        • Limitations of current inter dApp composability issues
        • Explanation of basic design and non-custodial asset inputs
        • Intent Based Transactions
        • Account Base vs eUTxO model app architecture
      • Theoretical Applications
  • GOVERNANCE
    • Governance Overview
      • Proposal Temp Check
      • Governance Proposal
        • On/Off Chain Mechanics
      • ODAO
    • Tokenomics
      • Categories
      • Vesting
    • Optim DAO Wallets
    • Protocol Profits
  • GUIDES
    • Transaction Chaining
      • Background
      • Overview
      • Pool Transaction Chaining
    • OPTIMiz Conversion
  • ODAO Stack
    • Introduction
    • Design Principles
    • Why Optim DAO Stack?
      • Current Limitations
      • ODAO Solutions
    • Key Features
      • Snapshot Voting
      • Treasury Management
      • Proposal Execution
    • System Architecture
      • Modular Framework
      • On-Chain Logic
      • Off-Chain Operations
      • User Interfaces
    • Core Modules
      • Snapshot Voting Module
      • Treasury Management Module
      • Proposal Execution Module
    • Future Roadmap
      • Potential Future Enhancements
      • Long Term Vision
  • OADA UI
    • Setup
      • Installation
      • Development Workflow
      • Troubleshooting
      • Development Tips
      • Open Source Contributions
      • FAQ
    • Key Functionalities
      • Wallet Integration
      • Dashboard
      • Transaction Management
        • UTxO Management
        • Transaction Creation and Conversion
        • Transaction Monitoring
      • Real-time Updates
        • Portfolio Value Tracking
        • Transaction Status Monitoring
    • OADA Smart Contract API
      • Minting OADA
      • Staking OADA
      • Unstaking sOADA
      • Epoch Stake Auction
        • Bid Calculation Functions
        • Auction Actions
        • Bid Form Component
        • Auction Dashboard
    • Tutorials
      • Environment Setup and Installation
      • Understanding the Project Structure
      • Basic Configuration and Customization
      • Working with Components
      • State Management and Data Flow
      • Wallet Integration and State Management
      • Smart Contract Integration
      • Advanced UI Customization
      • Testing and Quality Assurance
Powered by GitBook
On this page
  • Pool Token
  • Open Pool Validator
  • Closed Pool Validator
  • Transaction Flow
  1. LIQUIDITY BONDS
  2. Bond Architecture

Pooled Loans

PreviousTransaction FlowNextGuides for SPOs

Last updated 10 months ago

This system is a second order dapp to liquidity bonds, being a self-contained application that interfaces with it. The purpose of it is to pool funds such that they may execute against a bond, which normally requires 1M+ ADA. Specifically, the design is a little awkward when dealing with continual-funding fundraising initiatives. It works best when a borrower wants to take one loan and one loan only.

The pool creator must ensure that the correct amount of pool tokens are deposited to the pooling validator (and the correct number of bonds made). This is easily checked frontend-wise, and even on-chain-wise as the number N = pool tokens in utxo + (ada in utxo / 100) is known in advance and whether or not this invariant is broken.

Pool Token

Minting policy for the primary tokens of the product. Minted upon entering Open state and burned when the last bond token gets claimed.

Open Pool Validator

Pool validator allowing a loan to be filled by multiple lenders. The datum specifies the compatibility requirements for the Bond Writing Validator to be matched. Once all pool tokens have been bought, this position can be paired with a borrower's BWV UTxO to mint the bond tokens and send them to a corresponding Closed Pool state.

Closed Pool Validator

Pool validator receiving initial bond tokens. Holders of pool tokens can redeem them for bond tokens once the bond has been written, and redeem those in turn once the position enters the Closed state.

Transaction Flow

  1. Creating Pool: Lender creates a Pool by buying one or more pool tokens.

  2. Pool tokens sold: Pool tokens are sold until the Borrow offer has been fully funded.

  3. Matching against a BWV: The pool is matched against an outstanding Bond Writer Validator as if the pool was a single entity.

  4. Exchange PT -> BT: Lenders will exchange Pool Tokens for a corresponding amount of Bond Tokens.

  5. Pool Closed: Once all Bond Tokens have been claimed, the pool is terminated.