Secured Line of Credit
💧

Secured Line of Credit

<< Short intro to LoC for SEO >>

Programmatic credit account

do everything you already love, but with more capital.

Composable Leverage Protocol

<< Link to Cryptonative Credit >>

https://docs.debtdao.finance/products/introduction/secured-line-of-credit

https://docs.debtdao.finance/products/secured-line-of-credit

Table of Contents

Why not pools?

Most lending protocols use pools to create liquid markets for Borrowers and Lenders. While this is great for generalized asset based lending, it isn't suited to credit-based lending where Lenders want to have decision making power over who/what they're taking risks on and Borrowers have highly individual collateral requirements e.g. revenue streams in their Spigot. Pools disadvantage Borrowers because they all have the same terms and conditions despite differences in collateral, business model, debt structure, etc.

The lack of personalization also stifles market competition between Lenders and incentives for Borrowers to improve fundamental business metrics. We want Lenders to offer the possibility for Borrowers to construct a deal that best fits their needs. This requires you to be able to price the risk of these custom deals according to your own methodologies. This leads to a variety of options and the ability to match with others based on individual preferences. Rather than pool-to-pool, we strongly believe that a p2p lending model is best for large cryptonative entities with onchain revenue stream (e.g. DAO treasuries, onchain investment funds, DeFi protocols)

Components of A Line of Credit

Definitions

  1. Borrower - the owner of SecuredLine contract
  2. Lender(s) - People depositing assets to provide credit to the Line’s Borrower
  3. Spigot - Contract that holds Borrower’s collateralized revenue streams
  4. Escrow - Contract that holds Borrower’s token based collateral
  5. Interest Rate - Fixed rate interest contract
  6. Oracle - Chainlink Feed Registry contract to value all tokens being lent, borrowed, and collateralized.
  7. Arbiter - Trusted 3rd party that mediates between Lenders and Borrowers. Mainly acts to protect Lenders from malicious Borrowers.

Spigot + Line of Credit

Spigot page

Spigoted line functionality

reserves

You can track all the revenue traded through a Line from its Spigot for tokens owed to Lenders and, separately, every time debt is repaid with tokens bought from revenue. We also emit events with the exact changes in Line’s reserves from the two previous actions.

programmatically released when revenue is repaid so borrower is trustless as well. Automatically get all their revenue back as soon as they repay all their debt

Escrowed + Line of Credit

Escrow contract

tokens enabled by arbiter

4626 support if underlying asset has a Chainlink price feed

No forced liquidations

can withdraw collateral up to minimum collateral ratio for Borrower’s current outstanding debt

Interest Rate Contract

Currently DebtDAO only supports one way of charging interest - Fixed rate APR (denominated in bps) with a two fee tiers for drawn and undrawn credit (a.k.a dRate and fRate respectively). We use fixed interest rates for stability and predictability for Borrowers and Lenders and two fee tiers to reflect the different risk levels to Lenders based on utilization. If desired, it’s entirely possible to write your own InterestRate contract and replace it in the LineOfCredit contract. For example creating a LIBOR rate based on ETH staking yield and making interest rates float +500 bps above staking APR.

Benefits of Secured Lines of Credit

For Borrowers

  • Leverage recurring revenue (a.k.a assets you don't even have yet) for cheaper interest rates
  • choose between asset and revenue-based collateral with customized parameters (0-100% of revenue and 0-400,000% collateral ratio)
  • Lenders compete to give you the lowest interest rates
  • Don't have to sell equity, governance tokens, or dilute existing token holders
  • Only pay for what you need, when you need it. No lock-in to long term loans or bonds.
  • More flexible, sustainable and efficient financing for growth initiatives
  • No forced liquidations, as long as you repay principle + interest before maturity you'll be able to withdraw your collateral.

For Lenders

  • Collateralized onchain revenue thanks to the Spigot offers a new level of security for lenders
  • Automatic and trustless loan repayment
  • Compete against other Lenders via interest rates to offer the best risk-adjusted rates to the market
  • Withdraw your funds at any time if not currently in use by a Borrower
  • Monitor your Borrower’s financial health using financial reporting built into the Spigot
  • Syndication allows for sizing risk exposure without losing out on dealflow

Lifecycle of a Line

<<insert mermaid graphic>>

  1. Decide with your lenders the % revenue split and collateral ratio you all are comfortable with for your target interest rate
  2. Deploy your SecuredLine, Spigot, and Escrow contracts from our factory with the agreed terms
  3. Arbiter adds collateral settings on Spigot and Escrow
  4. Borrower transfers ownership of their Revenue Contracts to their newly deployed Spigot
  5. Borrower adds collateral to their Escrow contract
  6. Borrower initializes their SecuredLine to show they are ready to accept offers
  7. Lender proposes their agreed terms on the Borrower’s SecuredLine
  8. Borrower accepts Lender’s offer
  9. Borrower borrows from Lender’s line of credit
  10. Borrower earns revenue through their Revenue Contracts and stores it in their Spigot
  11. Arbiter trades Borrower’s revenue to Lender’s owed token and stores in SecuredLine
  12. Borrower or Lender can repay Borrower’s debt with tokens bought by Arbiter in SecuredLine
  13. Borrower closes line of credit and returns all money + interest to Lender
  14. Borrower gets back ownership of their Spigot from their SecuredLine and remove all collateral from Escrow contract

Deployment & Configuration

Our contracts also have the capabilities to deploy a line for someone else so DAO ops, teams can deploy and configure contracts for a DAO and start attracting lenders before the DAO has to go through official governance to accept a position. This avoids the hell of DAO bureaucratic inertia. Teams can also write custom scripts to deploy and configure their Line and transfer ownership of revenue streams or treasury assets in a single vote/transaction. Here is a GovernorBravo example of IDLE Finance’s proposal to deploy a Debt DAO line of credit and transfer revenue streams from their FeeCollector contract after token holders

<<mad user journey shit. probs link out to own Notion page>>

Borrowing & Lending

<<mad user journey shit. probs link out to own Notion page>>

Liquidations

<<EMPHASIZE NO SUDDEN LIQUIDATIONS AND LARGE DEALSIZE HENCE ARBITER OTC STRUCTURE>>

It is up to the Arbiter how they want to process liquidations and which of the Borrower’s assets they sell off and in which order to repay Lenders’ debts. The comments below are a best approximation of what an Arbiter would do. You should vet Arbiters’ processes, past performance, and reputation before deploying a Line with them because they unfortunately are a trusted counterparty and is an immutable variable. The liquidation process ends when Arbiter has repaid enough debt to make Line healthy again. In the event Borrower is completely past their repayment deadline, the Arbiter will attempt to repay all outstanding debt with Borrower’s remaining collateral.

If revenue collateral

  1. Arbiter claims revenue for Spigot and adds them to Line’s unusedTokens
  2. Arbiter uses all available unusedTokens in credit tokens Line to repay any outstanding debt
  3. Arbiter sweeps all available unusedTokens in revenue tokens from the Line to themselves to trade for credit tokens

If token collateral

  1. Arbiter liquidates Borrowers collateral via the Line contract sending tokens to themselves
  2. Arbiter trades tokens for credit tokens
  3. Arbiter repays Borrowers debt with liquidated collateral

Productizing Credit

Example User Flows Graphics

🧶
Common User Flow Sequence Diagrams

Arbiter Role

The Arbiter’s role is multifaceted and is currently the only ‘trusted’ party within the Debt DAO marketplace. They are responsible for:

  • Adding revenue contracts + settings to Spigot for Borrower to collateralize
  • Trading revenue earned by Borrower in their Spigot into assets owed to lenders
  • Enabling token collateral to Borrower’s Escrow contract after agreed upon by Borrower and Lender’s
  • Liquidating tokens from a Borrower’s Escrow contract
  • Liquidating idle revenue in Borrower’s Line if necessary
  • Selling Borrower’s Spigot to a new owner if they are unable to cover debt before deadline
  • Repaying Lenders from liquidation proceeds
  • Declaring a Line of Credit insolvent
  • updating whitelisted functions on Spigot that Borrower can call to manage their product

At a high level, a lot of responsibility currently lies with the arbiter. This means the arbiter must be properly incentivized in order for the marketplace to function correctly. In the case where Debt DAO is the arbiter, we have a vested interest in the marketplace operating as efficiently as possible. However, it is possible to customize the arbiter role and in this case, it is possible to incentivize arbiter actions with profit (via code logic) or offchain agreements between parties.

https://docs.debtdao.finance/developers/arbiter/liquidate-and-declareinsolvent

Arbiter Risks to Consider

The main risks of the arbiter include managing the health of the Line of Credit and how revenue via the spigot is handled. A bad arbiter might not monitor the health of a line and allow a liquidatable line to exist in a healthy state or might not liquidate or sweep assets in a timely manner meaning the lender could miss out on significant recourse for a bad loan.

If the arbiter is not a savvy trader, they could trade volatile revenue tokens for credit tokens during inopportune times.

Additional risks include:

  • misconfiguring the setting for a revenue contract when adding it to a Spigot
  • whitelisting (or not whitelisting) functions that disrupt the borrower’s ability to operate their business
  • Enabling collateral that is not a good asset (illiquid, fraudulent, too volatile) and leads to unhealthy lines of credit unnaturally.

Oracle

First things first, you do not have exposure to oracle risk in any way on purely revenue based Lines. If you as a lender or borrower do not want to be exposed to oracle risk, simply set collateral ratio to 0% so the Oracle has no effect on the system. We do still use the oracle to calculate total outstanding debt in USD for transparency and easier integrations but this does not affect Line health or liquidations if no collateral is required.

Second, we exclusively rely on Chainlink oracles for all currently deployed versions of the Debt DAO marketplace. It is possible for anyone to deploy their own Debt DAO marketplace with a different oracle system other than Chainlink but these will not show up on debtdao.finance.

All prices denominated in USD to 8 decimals in order to normalize across all the different assets lent out by each lender and all tokens put up as collateral by borrower.

Oracle Risks to Consider

Oracles can be manipulated. By allowing only Chainlink oracles on Debt DAO deployed infrastructure, we mitigate many of these risks, but risk exists with any oracle. Chainlink still relies on offchain decision making when submitting validated prices onchain. With Oracles in general, collateral that is priced with a compromised oracle can be deemed liquidatable prematurely.

Risks:

  • decimals?
  • TWAP pricing
TwitterGitHub

Dev Docs

Product Docs

Borrower FAQ

Lender FAQ