Overview
A “protocol” is an immutable set of rules that define how to interact with crypto assets and onchain data. A protocol usually contains multiple smart contracts which operate together to provide the full service.
A “revenue-generating contract” is a specific contract in a protocol that receives value from people interacting with the protocol and distributes it to people providing services. This value could be taken from fees paid by users or new tokens emitted as incentives.
While the Spigot is designed to be no-code plug and play with any revenue contract, there are so many different smart contract designs and patterns that not all revenue contracts are trustless or easily integrated with the Spigot.
For example, Curve is a protocol for providing, incentivizing, and trading against liquidity. Each liquidity pool is a revenue generating contract for LPs but they can technically lose money, in ETH terms and in terms of notional tokens they put in which makes them hard to integrate so they are “bad” for revenue contracts. Gauges are “good” revenue contracts since they are more programmatic in receiving and claiming income to LPs without the mess of virtual prices and mixing assets, its one token in (which yes is a bundle but its much easier to account for within the contract) and one token out. The $CRV staking contract is also a “good” revenue-generating contract for veCRV holders that claim 3CRV although it’s not possible due to their whitelist on smart contract staking. Note: A DAO is neither a protocol nor a revenue-generating contract, its a group of people yelling at the sky hoping it will rain diamonds.
1. Identify Your Type of Revenue Contract
While most contracts are compatible with the Spigot, not all revenue streams are created equal, some are more secure, composable, and trustless than others. Different protocols have different logic and architecture around governance and the flow of assets internally which affect how you setup your Spigot and lenders evaluate your cash flows. We’ll break down the different types of revenue The 3 main criteria for an onchain revenue
#1 - Programmatic, Trustless Smart Contracts
- Fees taken from users programmatically by contract
- Fees earned are controlled by contract (doesnt necessarily have to be stored inside the contract)
- No governance or only one governance address
- Complete control of smart contract can be transferred to the Spigot
- Smart contracts are immutable and non-upgradable
- Only the Spigot can change any aspect of revenue from who claims revenue to amount of fees paid by users
- Complete assurance that any and all ongoing revenue will flow to Spigot
#2 - Trusted Smart Contracts
- Fees taken from users programmatically by contract
- Fees earned are controlled by contract
- One or more governance addresses controlling contract
- May have multiple hierarchical roles.
- Ability to claim revenue but not complete control can be given to Spigot.
- Someone can change/remove the Spigots share of revenue or ability to claim.
- Some to complete assurances that any and all ongoing revenue will flow to Spigot depending on the contract and control structure.
#3 - Invoicing or Receivables
- No smart contract generating fees, direct token transfers from clients to multisig/EOA
- You could transfer a Superfluid stream NFT or similar to your Spigot but streams can be canceled or never fully paid so at best its a Trusted Smart Contract setup.
- No assurances that all ongoing revenue will flow to Spigot.
