Key features of the Spigot

A Spigot's purpose is to provide Trustless Recourse for Secured Agreements

A Spigot's purpose is to provide Trustless Recourse for secured agreements. Its key features:

Escrow at the source

The Spigot takes ownership of the Borrower's Revenue Contracts for the life of the agreement. Cash flows are split and escrowed the moment they are claimed — repayment security does not depend on the Borrower initiating transfers.

Configurable splits, programmatic step-up

Each Revenue Contract has an agreed owner split between 0% and 100%. In a credit event, the split on a defaulted facility can be stepped up to 100% by the Admin — the recourse is in the code, not in a covenant document.

Business as usual for the Borrower

Through the Operator role, the Borrower keeps running its product: any function the parties whitelist can still be called on the Revenue Contracts — except claim and ownership-transfer functions, which are permanently blocked for the Operator.

Multi-beneficiary distribution

One Spigot can serve several creditors simultaneously, each with its own allocation, credit token, and onchain repayment path, with live debt tracking that prevents overpayment. See The Spigot.

Token conversion built in

Escrowed revenue in the "wrong" token is converted before repayment: via DEX aggregator with slippage protection, or via OTC swap under mutual consent with oracle pricing, stablecoin whitelisting, and price-impact limits.

Reserves

Claimed revenue can be held in the Spigot as Reserves — a standing repayment buffer and additional security for the facility.

Clean release and reuse

On full repayment, Revenue Contract ownership transfers back to the Borrower's Operator, and residual balances are swept back to the Borrower. A configured Spigot can be reused to secure the next facility without redeployment.