Secured Line of Credit

Debt DAO’s Secured Lines allow borrowers and lenders to create credit, fully progrmmatically and crypyonatively, for the first time ever. We allow powerful customizations to structure any type of deal you might want to finance from collateralizing revenue to cover payroll or depositing assets for a leveraged-buyout.

Do everything you already do, just with more money 🌞

In the dark forest of DeFi, you need a lifeline to survive 🌚

Table of Contents

• Table of Contents
• Why not pools?
• Components of A Line of Credit
• Definitions
• Spigot + Line of Credit
• Escrowed + Line of Credit
• Interest Rates
• Benefits of Secured Lines of Credit
• For Borrowers
• For Lenders
• Borrowing & Lending
• Lifecycle of a Line
• Deployment & Configuration
• Liquidations
• Example User Flows Graphics
• Arbiter Role
• Arbiter Risks to Consider
• Oracle
• 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. DeFi protocols, DAO treasuries, onchain investment funds).

Our Line of Credit contracts for borrowers are p2p and 1-to-many letting lenders syndicate loans and create tranching by increasing their interest rates the further back in the repayment queue they are.

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
8. Reserves - Surplus revenue claimed from a Spigot stored in a Line to repay debt later

Spigot + Line of Credit

While the Line of Credit contract handles the financial lending data, the Spigot ocntract collateralizes the borrowers cash flows. We then combine them together into a “Spigoted Line” where the Line contract is the owner of the Spigot and the borrower is the operator. The Spigot handles the money earned by borrowers and then lets the Line of Credit pull those funds whenever the borrower wants to repay debt.

Borrowers are ensured that as soon as they repay all their debt, their Spigot is released back to them and they become the beneficiary of 100% of revenue again. This programmatic, trustless assurance gives Borrower’s more confidence to funnel more revenue through their Spigot, allowing them to earn better interest rates on their credit.

This integration also allows anyone to track all the revenue traded through a Line from its Spigot, how much of a Borrower’s debt was repaid from revenue vs from their wallet, and anytime debt is repaid directly from revenue streams or from revenue reserves.

Escrowed + Line of Credit

The Escrow contract is the simplest contract as it simply handles depositing and withdrawing tokens, calculating their total value, and if they are above the required collateral ratio. All tokens deposited as collateral must first be enabled by the Arbiter of the Line. 4626 tokens can be enabled if the underlying asset has a Chainlink price feed. It is up to the Lenders to do DD on any collateral tokens and determine if it is an asset they want backing the debt before they agree for the Arbiter to enable it.

Notably the Escrow contract itself doesnt mandate that it is liquidatable when you call liquidate(), it delegates responsibility to the Line that owns it. This master-slave architecture allows more flexibility when incorporating multiple collateral types and liquidation conditions to create a cohesive, single credit account without silos between modules.

Debt DAO is a B2B platform designed for DAOs as the main borrower type. DAOs also mean long times to do anything. Instead of immediately liquidating borrowers as soon as they become undercollateralized or miss a deadline. Borrowers have time to top up collateral, pass a vote to repay from their treasury, or wait for their revenue streams to fully repay before liquidations actually begin. More on liquidations below.

Interest Rates

Currently DebtDAO only supports one way of charging interest - fixed rate APR (denominated in bps) with 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. 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 or AAVE/COMP market rate and charge +500 bps.

Benefits of Secured Lines of Credit

For Borrowers

• Leverage recurring revenue streams for cheaper interest rates
• choose between asset and revenue-based collateral with customized parameters
• How long you want the entire facility to last
• 0-100% of revenue split with lenders
• 0-400,000% collateral ratio
• interest rate model
• Cross-margin account so you can collateralize multiple assets and borrow multiple assets.
• Can syndicate between many Lenders or have them 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

Borrowing & Lending

🚨  🚧  🚨 Under Construction 🚨  🚧 🚨 

Lifecycle of a Line

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 contracts for their 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 vote to spigot their revenue.

Liquidations

The Arbiter decides 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 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

Example User Flows Graphics

Arbiter Role

The Arbiter’s role is multifaceted and is currently the only ‘trusted’ party within the Debt DAO marketplace. While a trusted 3rd party, we have tried to minimize their access and control as much as possible to only where its needed.

Actions they take:

• Adding revenue contracts + settings to Spigot for Borrower to collateralize
• Updating whitelisted functions on Spigot that Borrower can call to manage their product
• Enabling token collateral to Borrower’s Escrow contract after agreed upon by Borrower and Lender’s
• Liquidating tokens from a Borrower’s Escrow contract
• Trading revenue earned by Borrower in their Spigot into assets owed to lenders
• Liquidating idle revenue in Borrower’s reserves
• 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

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.

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.

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.

It is also important to note that Oracles also define which tokens are allowed as collateral and lending. You can use different oracles for collateral vs lending tokens but by default we set them to the same. This means if you can use a specialized NFT oracle for collateral and the standard Chainlink oracle for lending ERC20s in the same line of credit.

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 relying on Chainlink oracles many of these risks are mitigated but there is always oracle risk. Chainlink 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 or not at all.

If an oracle feed disappears that is currently being used in a debt dao contract, borrowing and healthchecks (thus liquidations) will be prevented. Lenders will still always be able to withdraw all available capital and borrowers can still repay from revenue or their wallets. If the price feed never comes back, the borrowers tokens deposited as collateral would be locked, even for liquidations, until the borrower fully repays their debt. This could be easily solved with a flashloan to repay debt and then use the recovered collateral to repay it.

So even if our oracle system completely fails, assets in any Debt DAO contracts should still recoverable and used to repay lenders.