> 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/the-spigot.md).

# The Spigot

A groundbreaking innovation for the onchain financial ecosystem.

The Spigot is a smart contract that governs the secure escrow and splitting of onchain cash flows between multiple parties according to an agreed set of terms — and enforces those terms in code.

Its core purpose is **Trustless Recourse**: if the obliged party (a Borrower) fails to meet its obligations, the counterparties' claim over the Borrower's cash flows is enforced programmatically, at the source, without requiring cooperation or court action.

{% hint style="info" %}
For a Secured Line of Credit, the Spigot escrows an agreed share of the Borrower's revenue to secure and automatically repay the facility. Functionally, it is the onchain equivalent of a lockbox / DACA arrangement in traditional structured finance: a perfected, programmatic first claim on payment settlement flows.
{% endhint %}

### How it works

1. The Borrower attaches one or more **Revenue Contracts** — smart contracts it owns that receive payment flows — to the Spigot, transferring their ownership to the Spigot for the duration of the facility.
2. Each Revenue Contract has an agreed **owner split** (0–100%): the escrowed share flows to the Spigot's beneficiaries; the remainder is claimable by the Borrower through the **Operator** role.
3. The Borrower keeps operating its business normally: the Operator can call whitelisted functions on the Revenue Contracts — but never the claim or ownership-transfer functions.
4. Escrowed tokens repay the facility (directly, or after conversion via DEX or consented OTC swap), or are held as **Reserves**.
5. On full repayment, ownership of the Revenue Contracts returns to the Borrower. On default, the facility's share can step up to 100%.

### A multi-beneficiary payment waterfall

The v2 Spigot serves more than one creditor. Alongside the Line of Credit (the **default beneficiary**), the Spigot can be configured with additional **third-party beneficiaries** — for example other lenders to the same Borrower — each with:

* Its own **allocation** of escrowed cash flows
* Its own **credit token**, **pool address**, and repayment function, so the Spigot can repay that creditor onchain directly
* Live onchain **debt tracking** — the Spigot queries each beneficiary's pool for the debt outstanding and can never overpay it

Escrowed revenue that isn't in a beneficiary's credit token is converted — by DEX trade or consented OTC swap — before repayment. When a beneficiary is fully repaid, its residual tokens are reassigned to the default beneficiary, and its allocation is implicitly redistributed. In emergencies, the Admin can impair (void) a beneficiary's recorded debt or recover tokens on a beneficiary's behalf.

This makes the Spigot a general-purpose, onchain **settlement waterfall**: one revenue source, multiple creditors, deterministic priority and accounting.

### Additional properties

* **ETH handling** — any native ETH received is automatically wrapped to WETH so it can be escrowed and distributed like any ERC-20
* **Anyone can trigger claims** through the permitted roles' functions; all balances and splits are publicly auditable in real time
* **Continuity** — a configured Spigot survives the facility it secured and can be reused for the Borrower's next facility


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.creditcoop.xyz/core-concepts/the-spigot.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.