> For the complete documentation index, see [llms.txt](https://docs.creditcoop.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.creditcoop.xyz/core-concepts/secured-line-of-credit/secured-line-of-credit/revenue-based-lending-operations.md).
# Revenue-Based Lending Operations
A Line of Credit secured by cash flows gains additional repayment and security mechanics via the Spigot.
{% hint style="info" %}
A Spigot is deployed with every Secured Line of Credit. Tokens from Borrower Revenue Contracts are escrowed by the Spigot and split between the Borrower and the Line according to the agreed owner split per contract.
{% endhint %}
### Revenue collection and repayment
Claiming revenue into the Spigot
The Operator or Servicer pulls tokens from a Revenue Contract into the Spigot (push payments direct to the Spigot are also supported). Each claim is split automatically: the agreed owner split is escrowed for the Line (and any other beneficiaries), and the remainder is reserved for the Borrower to claim via the Operator.
Using escrowed revenue to repay Credit Positions
Revenue escrowed for the Line can be applied straight to repayment, following the facility's repayment queue. If the revenue token differs from the Credit Token owed, it is first swapped — via a decentralized exchange aggregator, or via a consented OTC swap — before being applied.
Storing revenue as Reserves
Instead of repaying immediately, claimed revenue can be held in the Spigot as Reserves — a standing buffer that secures the facility and can repay positions on demand. This gives the Borrower flexibility on repayment timing and on when token conversion happens.
Swapping revenue tokens
Two conversion paths exist for revenue that isn't in the repayment asset:
* **DEX swap** — executed by the Admin through the facility's configured swap target, with a minimum-buy-amount safeguard
* **OTC swap** — executed against a specific counterparty by mutual consent, with whitelisted stablecoins trading one-to-one and other assets priced by oracle within an agreed maximum price impact
A swap fee and/or servicing fee, where configured, is taken from proceeds to the protocol treasury.
### Managing the Spigot over the life of the loan
Adding Revenue Contracts
Additional Revenue Contracts can be attached to the Spigot over time (by Admin or Servicer) to add security or replace an existing revenue source. Each contract carries its own owner split, claim function, and transfer-ownership function.
Updating whitelisted functions
The Admin can update which functions the Operator may call on Revenue Contracts, so the Borrower can keep operating its product while the Spigot is attached. Claim and ownership-transfer functions can never be whitelisted for the Operator.
Updating the revenue split
The owner split on a Revenue Contract (0–100%) can change in two ways: (1) by the Borrower when the facility has no open positions (with any open proposals cleared and the nonce incremented), or (2) by the Admin when the Line is LIQUIDATABLE — the programmatic step-up that gives Lenders full recourse on default.
Release, reuse, and removal
* **Removal of a single Revenue Contract:** once the facility is REPAID (or in specified credit-event states), ownership of a Revenue Contract is transferred back to the Operator and the contract is removed from the Spigot.
* **Sweeping residual funds:** once the facility is REPAID and no beneficiary debt is outstanding, remaining owner/operator token balances in the Spigot can be swept back to the Borrower.
* **Reuse:** because a REPAID facility can be reactivated by a new Credit Position, an already-configured Spigot and its Revenue Contracts can secure a new borrowing cycle without redeployment — cheaper, faster, and less error-prone.
Third-party beneficiaries
The Spigot is not limited to serving the Line. It can escrow and distribute revenue to additional third-party beneficiaries (e.g. other creditors of the Borrower) alongside the Line, each with its own allocation and repayment configuration — a full onchain payment waterfall. See [The Spigot](/core-concepts/the-spigot.md) for details.
Default and liquidation
If the facility becomes LIQUIDATABLE, the Admin can step the owner split up to 100%, and escrowed revenue plus Reserves are applied to repay Lenders. See [Credit Events](/core-concepts/secured-line-of-credit/secured-line-of-credit/loan-impairment-and-lender-recourse.md).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.creditcoop.xyz/core-concepts/secured-line-of-credit/secured-line-of-credit/revenue-based-lending-operations.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.