> ## Documentation Index
> Fetch the complete documentation index at: https://tetrafi.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Where It Applies

> One clearing layer, many kinds of debt - and why every new lane raises everyone's ratio.

<Note>
  **Coming soon.** The clearing layer is in design. The lanes below describe where it applies - some ship with the primitive, some are designed, some are future work; each is labeled.
</Note>

## One Graph, Many Kinds of Debt

The clearing engine is deliberately domain-blind: it nets obligations - who pays whom, how much, by when - without caring what created them. A trade, an invoice, a redemption, a corridor flow: once a debt is signed onto the graph, it clears the same way. That is what lets one clearing layer serve very different books, and it is what makes the network compound: **every lane feeds the same graph, so each new kind of flow raises everyone's netting ratio.**

## The Lanes

<CardGroup cols={2}>
  <Card title="Stablecoin Flows" icon="coins">
    **Ships with the primitive.** Cross-chain stablecoin obligations are the first lane - the flows the network settles today, cleared with compliance built in: sanctions and jurisdiction gates at every run entry, per-issuer risk awareness, and regulated-record capture a supervisor can independently verify.
  </Card>

  <Card title="Tokenized Assets" icon="building-columns">
    **Designed.** Delivery-versus-payment pairs - the asset leg and the cash leg - net together with atomicity preserved: both legs settle in one unit or neither does. Tokenized treasuries, money-market funds, and repo flows settle gross today; a shared netting layer is the missing compression under them.
  </Card>

  <Card title="Payment Networks" icon="tower-broadcast">
    **Designed.** Retail-scale micro-flows aggregate into netting-eligible institutional obligations, clear against the network, then split back out per provider with full reconciliation - so corridor flows benefit from institutional-grade netting without every provider integrating settlement infrastructure. See [payment networks](/use-cases/payment-networks).
  </Card>

  <Card title="Trade Finance" icon="file-invoice">
    **Future.** Dated obligations - 30, 60, 90 days out - clear together by settlement date, and each debt can anchor the hash of its originating document, so the same invoice can never back two live obligations.
  </Card>

  <Card title="Energy & Circular Debt" icon="bolt">
    **Future.** A owes B, B owes C, C owes A is endemic in energy markets - and a closed loop of debt is exactly what the engine extinguishes with zero money moved. Circular-debt resolution is set-off in its purest form.
  </Card>

  <Card title="Risk Intelligence" icon="chart-line">
    **Designed.** A by-product only this layer can produce: counterparty scores, concentration and stress views, and intraday liquidity figures computed where the graph lives - each participant reads its own, and nobody reads anyone else's.
  </Card>
</CardGroup>

## Why the Lanes Compound

Netting finds value in opposing flow, and opposing flow lives across books, not inside them. A market maker's corridor rebalancing, an issuer's mints against redemptions, a payment network's north-south flows, a desk's T+1 obligations - each alone nets modestly; on one shared graph, each becomes the counterflow that clears the others. The ratio is a network property: more members, more lanes, more offsets, and the engine finds them all in one solve.

That compounding is upside, not a precondition. A book nets against itself the day it joins, on the settlement rails it already runs - the shared graph only makes the residual smaller. [Who adopts it, and on what](/use-cases/netting-adopters).

## Keep Going

<CardGroup cols={2}>
  <Card title="How It Works" icon="gears" href="/netting/how-it-works">
    The clearing run step by step, funding, and where the residual goes.
  </Card>

  <Card title="Privacy & Control" icon="lock" href="/netting/privacy-and-control">
    Who sees what, who you end up facing, and the lines the protocol never crosses.
  </Card>
</CardGroup>