The Spigot is the primary innovation that Debt DAO has brought to onchain financing ecosystem.
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.
Table of Contents
- Table of Contents
- How Does The Spigot Work?
- Background Research
- Benefits of Spigot
- Key features of the Spigot
- Access Control
- Revenue Splits
- Risks of Spigot
- Potential Bugs & Attack Vectors
How Does The Spigot Work?
Someone that wishes to use the Spigot in some way - to collateralize a loan, sell their revenue generating contract, or standardize their revenue reporting - they must first follow our guide to deploy a Spigot including setting revenue splits between the Spigot’s Owner and Operator. There are some conditions required for Revenue Contracts to be 100% compatible with the Spigot contract but some conditions depend on your use case.
The revenue generating smart contract that is being collateralized is known as the Revenue Contract. After you transfer ownership of your Revenue Contract to your Spigot, the Spigot will periodically receive revenue from the Revenue Contract which it will divide between the Owner (you) and Operator (you or a proxy agent) with the all tokens from all Revenue Contracts combined into one bucket for each person. Then the Owner and Operator can each independently claim the tokens held for them.
As a part of the security features, the Owner can whitelist what functions the Operator is allowed to call the Revenue Contract. 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.
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. (The Borrower is also incentivized to repay so that we dont liquidate their spigot and sell their Revenue Contracts to repay lender debt.)
<< 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
<< TODO elaborate use cases from Benefits lending, reporting, m&a>>
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
- The Spigot is the rightful onchain owner of all Revenue Generating contracts inside it.
- The Spigot Owner can change revenue split, Operator, or whitelisted functions anytime
- The Owner can transfer ownership of the entire Spigot with all its Revenue Contracts to anyone OR relinquish ownership of a single Revenue Contract to their Operator.
- The Spigot Operator is the only one that can access Revenue Contracts.
- The Operator can only call whitelisted functions on Revenue Contracts by Owner.
- Anyone can claim revenue on behalf of owner/operator
- The Spigot captures a fixed percentage of Revenue Tokens from a Revenue Contract under its control and escrows it for the Owner.
- The Spigot Operator receives a % of revenue as payment from Owner for operating its Revenue Contracts
- Revenue Tokens escrowed for the Owner and Operator are available to be withdrawn on demand.
- The Owner (e.g. LineOfCredit contract) can mandate that Spigot assets must be used to make Owner whole.
- The Spigot itself can also be traded, with all Revenue Contracts still inside it, in the event the Owner wants a lump sum cash payout (e.g. to liquidate borrower) instead of consistent revenue streams
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 90% 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. You can find a full list of considerations for a revenue generating contract in our Spigot Evaluation template.
There is of course the always present smart contract risk inherent to the Spigot itself and its logic.
Potential Bugs & Attack Vectors
- 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.
- Function: N/A
- Fixes: - N/A. Do better due dilligence
- 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
- Function: addSpigot()
- Do better due diligence before adding Revenue Contract
- Remove Spigot and then read with proper settings
- Whitelist proper functions for Operator to call. May introduce more risks depending on underlying functionality of Revenue Contract.
- 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
claimFuncthen anyone, not just the Operator, can syphon revenue away from the Spigot and its rightful owner.
- Function: claimRevenue()
- 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.
- Malicious Whitelist - Owner can whitelist a function on a Revenue Contract that gives Operator access to resources that compromises trustlessness of Spigot integration
- Function: updateWhitelistedFunction()
- Fixes: N/A. Do better due diligence before whitelisting functions that counterparty can access.
- 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.
- Function: addSpigot()
- Fixes: N/A. Do better due diligence before adding Revenue Contract