Skip to main content

Full Collateralization

Collateral is deposited atomically at offer creation — no two-step “list then fund” flow. Deferred claims are bounded by the backing counter for each series.
Claims are minted only when collateral already exists in escrow — never speculatively. The protocol enforces this at the contract level; there is no administrative override.

What “Fully Collateralized” Means in Practice

No Fractional Reserve

For any series, claimToken.totalSupply() == series.backing, and the venue holds at least that much of the asset. Claims can never exceed backing.

No Synthetic Exposure

Canopy does not create artificial asset representations. Every claim maps 1:1 to real escrowed tokens.

No Leverage

You cannot open a position larger than the collateral already deposited. Over-commitment is structurally impossible.

1:1 Backing

The relationship between claims and collateral is exact and immutable. For every unit of claim token in circulation, one corresponding unit of the underlying asset sits locked in escrow. When a claim is redeemed, the protocol decreases the series’ backing counter by the exact amount redeemed and releases that collateral directly to the holder. The claim tokens are burned in the same transaction. No operation in the protocol can break this invariant.

Independent Series

Each series maintains its own isolated backing counter. A TECH series with one unlock time and a separate TECH series with a different unlock time each hold their own escrow accounting; one series can never draw on another’s backing. This isolation means a problem in one series — however unlikely — cannot cascade and drain collateral from unrelated positions you hold.

Isolated Backing

Escrow backing is tracked per series. No series can borrow from or share collateral with another.

Independent Accounting

Fill tracking, claim issuance, and redemption are all scoped to a single series at a time.

Fee-on-Transfer Token Support

Many tokens in the ERC-20 ecosystem deduct a transfer fee when tokens move between addresses. If a naive protocol simply trusts the nominal transfer amount, it can record more collateral than it actually received — a subtle but critical solvency gap. Canopy closes this gap by measuring escrow using actual received balances, not the amount the sender specified. When you deposit 1,000 tokens of a 1% fee-on-transfer asset, the venue observes that 990 tokens arrived and records 990 as the escrowed amount in assetRemaining. Offers and claims are sized against the real balance, keeping the 1:1 backing guarantee intact.

Buyer Protections at Fill Time

Because transferred amounts may differ from nominal amounts, Canopy gives buyers three configurable protections when submitting a fill via fillWithLimits:
You specify the ceiling on the total quote tokens debited from your wallet, including the base cost, protocol fee, and any transfer taxes. If the total debit exceeds this ceiling, the transaction reverts automatically.
You can assert a floor on how much the seller actually receives net of any fees. This prevents scenarios where fees eat so deeply into the transfer that the economic terms of the trade materially change.
You specify the minimum quantity of the asset you must receive for the fill to succeed. If fees reduce the delivered amount below this threshold, the transaction reverts — protecting you from receiving less than you agreed to.
Tokens with unsupported behaviors — including rebasing tokens, double-entry tokens, and tokens with exotic transfer hooks — will cause transactions to revert safely with UnsupportedTransferBehavior() rather than executing at incorrect values. This is intentional: the protocol prefers a clean revert over any settlement that could compromise solvency.

Protocol Solvency and Quote Token Flow

Canopy does not custody quote tokens. When a buyer fills an offer, the quote payment flows directly from the buyer’s wallet to the seller, and the fee flows from the buyer to the fee recipient — the venue is never an intermediary holding quote balances. Only the asset being sold is held in escrow. This design limits the protocol’s custody surface to exactly what it needs to enforce delivery, and nothing more.

Quote Tokens: Never Custodied

Quote payments (e.g., USDC) move directly from buyer to seller and fee recipient at fill time. The venue touches them only to route the transfer.

Asset Tokens: Escrowed Until Settlement

The asset being sold (e.g., a project token) is held by the venue from offer creation through fill, cancellation, or redemption.