Revenue-Based Lending Operations

A Line of Credit secured by cash flows gains additional repayment and security mechanics via the Spigot.

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.

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