<< 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 >>
Table of Contents
- Table of Contents
- Why not pools?
- Components of A Line of Credit
- Spigot + Line of Credit
- Escrowed + Line of Credit
- Interest Rate Contract
- Benefits of Secured Lines of Credit
- For Borrowers
- For Lenders
- Lifecycle of a Line
- Deployment & Configuration
- Borrowing & Lending
- Productizing Credit
- Example User Flows Graphics
- Arbiter Role
- Arbiter Risks to Consider
- Oracle Risks to Consider
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
- Borrower - the owner of SecuredLine contract
- Lender(s) - People depositing assets to provide credit to the Line’s Borrower
- Spigot - Contract that holds Borrower’s collateralized revenue streams
- Escrow - Contract that holds Borrower’s token based collateral
- Interest Rate - Fixed rate interest contract
- Oracle - Chainlink Feed Registry contract to value all tokens being lent, borrowed, and collateralized.
- Arbiter - Trusted 3rd party that mediates between Lenders and Borrowers. Mainly acts to protect Lenders from malicious Borrowers.
Spigot + Line of Credit
Spigoted line functionality
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
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
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
- 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.
- 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>>
- Decide with your lenders the % revenue split and collateral ratio you all are comfortable with for your target interest rate
- Deploy your
Escrowcontracts from our factory with the agreed terms
- Arbiter adds collateral settings on
- Borrower transfers ownership of their Revenue Contracts to their newly deployed Spigot
- Borrower adds collateral to their Escrow contract
- Borrower initializes their
SecuredLineto show they are ready to accept offers
- Lender proposes their agreed terms on the Borrower’s
- Borrower accepts Lender’s offer
- Borrower borrows from Lender’s line of credit
- Borrower earns revenue through their Revenue Contracts and stores it in their
- Arbiter trades Borrower’s revenue to Lender’s owed token and stores in
- Borrower or Lender can repay Borrower’s debt with tokens bought by Arbiter in
- Borrower closes line of credit and returns all money + interest to Lender
- Borrower gets back ownership of their
SecuredLineand remove all collateral from
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>>
<<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
- Arbiter claims revenue for Spigot and adds them to Line’s
- Arbiter uses all available
unusedTokensin credit tokens Line to repay any outstanding debt
- Arbiter sweeps all available
unusedTokensin revenue tokens from the Line to themselves to trade for credit tokens
If token collateral
- Arbiter liquidates Borrowers collateral via the Line contract sending tokens to themselves
- Arbiter trades tokens for credit tokens
- Arbiter repays Borrowers debt with liquidated collateral
Lines of Credit and Use Cases
Why use Lines of Credit on-chain instead of regular term loans?
Example User Flows Graphics
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.
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.
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.
- TWAP pricing