The Spigot

This Spigot is a smart contract that enables Borrowers to collateralize their onchain revenue streams giving Lenders trustless assurances that they MUST be repaid from all collateralized income. This is the first time that revenue-based financing has been enabled for cryptonatice borrowers and the Spigot is the primary innovation that Debt DAO has brought to onchain financing ecosystem.

Table of Contents

• Table of Contents
• How Does The Spigot Work?
• Why Do I Need The Spigot?
• Benefits of Spigot
• Key features of the Spigot
• Ownership
• Access Control
• Revenue Splits
• Recourse
• Risks of Spigot
• Potential Bugs & Attack Vectors

How Does The Spigot Work?

The Spigot is designed to control revenue streams that are programmatically generated by smart contracts such as Yearn vault deposit fees, Index Coop streaming fees, or Nouns DAO sales. The revenue generating smart contract that is being collateralized is known as the Revenue Contract. The owner of a Revenue Contract must transfer either complete ownership or just the ability to claim revenue over to the Spigot. This means the Spigot smart contract is now the owner of the protocol with some level of admin access. The Spigot uses its access rights to claim revenue from the Revenue Contract and divide it between the Spigot’s Owner and Operator.

The Owner can configure which Revenue Contracts can be added to the Spigot and approves functions for the Operator to call on these contracts. Usually the owner of a Spigot is a Debt DAO Line of Credit which controls how much revenue to split for debt repayment, gives ownership of Revenue Contracts back to borrowers as soon as debt is repaid, and other programmatic operations related to the debt obligation.

The Operator is responsible for managing the protocols held within the Spigot and receives a % of the revenue for their efforts. The whitelist allows the Operator to carry on business as usual on their Revenue Contracts but limiting the possibility to divert revenue streams or some other exploit. The Owner and Operator can be the same address or completely unrelated parties.

The Spigot will work with any revenue stream - like invoices for offchain services provided - just with different trust assumptions depending on how its configured. It is truly on “trustless” when securing fully onchain revenue streams generated by immutable smart contracts.

We have a list of conditions required for Revenue Contracts to be 100% compatible which helps demonstrate how the Spigot works with any revenue contract

Why Do I Need The Spigot?

When we set out to build Debt DAO, our sole focus was to help the larger, established DAOs that we worked at who felt the crippling need for debt financing when they normally would have easy access if they were normal legal entities with a bank account. Our goal has always been to service 100% onchain and 100% anonymous entities.

This commitment to Cryptonative Credit forced us to kept running into a hard question - How do you provide undercollateralized lending to people you dont know and dont trust without losing your money? There were already solutions on the market using legal contracts and reputation but that obviously goes against our cryptoanarchist principles. Eventually we realized the one advantage that onchain entities have is that they are onchain where all their financials and governance are completely programmable. If we could programmatically control revenue streams, could we collateralize future cash flows by guaranteeing payment to lenders? And so the idea of the Spigot was born.

After extensive research into various revenue generating protocols, their smart contract design patterns, and speccing requirements from borrowers and lenders on what they needed to execute a trustless revenue-based lending agreement, we then designed and built our Spigot smart contract.

It became clear there was a distinction and balance between ownership and control when trying to use trustless revenue-based collateral. Why? We want to ensure everyone receives the agreed upon revenue split, but the new owner of the revenue stream might not know how to generate revenue. So the owner must pay someone to operate the Revenue Contract for them and give them a cut of the revenue. In the case of Debt DAO, our Line of Credit is the Owner and the borrower is the Operator. The Line contract, on behalf of its Lenders, is incentivizing the Borrower to keep running their business and ensuring the Line’s collateralized revenue stream stays healthy by giving them an operator cut of the collateralized revenue stream. The Borrower is also incentivized by the obvious fact they get their Spigot liquidated and lose their revenue streams if they do default.

This novel mechanism for collateralizing revenue became the bases for trustless AND anonymous lending in the Debt DAO marketplace.

<< Graphic of how Spigot works >>

Benefits of Spigot

• Ability to collateralize revenue streams to receive lower interest rates on loans
• Add layer of security on top of your protocol to separate onchain roles for managing finances and managing product
• Can hire operators for your onchain business while giving them minimal control over your protocol
• Ability to sell off a revenue generating contract if you no longer want to own it
• Standardize your projects financial reporting across products and tokens using Spigot’s RevenueClaimed events

The first usage of the Spigot is in the Secured Line of Credit. One Spigot is deployed once per Line and can attach to multiple Borrower revenue contracts.

More Spigot use cases will be introduced. We consider it a product in its own right.

Key features of the Spigot

Risks of Spigot

There are different risks associated with the Spigot depending on if you are an Operator giving up your Revenue Contract or the Owner hoping for trustless payments. Operators care more about direct technical integration compatibility so that their Revenue Contract doesn’t get locked in the Spigot and Owners care more about the underlying Revenue Contract logic to ensure Operators cant rug revenue after giving control to their Spigot.

The Spigot is designed to be automatically compatible with 80% of protocols with 0 custom code required. The main exceptions are 1. Your protocol is completely immutable with no governance to transfer ownership to your Spigot (not a bad problem to have) 2. your protocol’s transfer owner function isn’t compatible with our Spigot. If you wish to use the Spigot - to collateralize a loan, sell their revenue generating contract, or standardize their revenue reporting - you must first check some conditions required for Revenue Contracts to be 100% compatible. Some conditions may depend on your use case!

There is of course the always present smart contract risk inherent to the Spigot itself and its logic.

Potential Bugs & Attack Vectors

1. Revenue Diversion - A common attack vector is to divert revenue from Revenue Contracts in a Spigot that were not designed to used as revenue-based collateral. In this case, the Spigot never truly owns the Revenue Contract and should not be used.
1. Function: N/A
2. Fixes: - N/A. Do better due dilligence
2. Misconfigured Spigot - If the settings for a particular Revenue Contract use the wrong claim revenue or transfer ownership function than a Revenue Contract may become bricked depending without removing the Revenue Contract (with Spigot.removeSpigot())
1. Function: addSpigot()
2. Fixes:
1. Do better due diligence before adding Revenue Contract
2. Remove Spigot and then read with proper settings
3. Whitelist proper functions for Operator to call. May introduce more risks depending on underlying functionality of Revenue Contract.
3. Malicious Claim Revenue - Anyone can claim revenue on behalf of the Owner and Operator. Our Spigot assumes best coding practices that the only side effect of claiming revenue will be balance changes. If there is extra functionality implemented in the Revenue Contract’s claimFunc then anyone, not just the Operator, can syphon revenue away from the Spigot and its rightful owner.
1. Function: claimRevenue()
2. Fixes: N/A. Do better due diligence before adding Revenue Contract. Spigot cannot properly secure Revenue Contract’s revenue and Revenue Contract MUST NOT be added. Owner MAY whitelist the claimRevenue function so only the Operator can call but they MUST trust Operator and hope Operator doesn’t exploit it themselves.
4. Malicious Whitelist - Owner can whitelist a function on a Revenue Contract that gives Operator access to resources that compromises trustlessness of Spigot integration
1. Function: updateWhitelistedFunction()
2. Fixes: N/A. Do better due diligence before whitelisting functions that counterparty can access.
5. Upgradable Revenue Contract - If a Revenue Contract is allowed to change the logic that runs when calling it (UpgradeableProxy or updatable contract addresses in state) then that Revenue Contract MUST NOT be added. This prevents code from being changed at anytime to revoke revenue stream from spigot, remove Spigot controls entirely, or any number of attack vectors.
1. Function: addSpigot()
2. Fixes: N/A. Do better due diligence before adding Revenue Contract