The Spigot

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.

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 >>

<< 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.

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.