Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.tessera.finance/llms.txt

Use this file to discover all available pages before exploring further.

The protocol’s invariants are the contractual claims about what cannot happen, regardless of input or sequencing. They are the guarantees an issuer, lender, solver, or auditor can rely on.

​
The invariants

#InvariantEnforcement
I1No settled auction transferred collateral to a non-compliant recipient.Bid-time compliance check + transfer-hook re-check at safeTransfer.
I3Bid is atomic. When bid() results in settlement, all 5 settlement steps complete in one tx. When bid() results in BidRejected, no state changes occur.Single transaction, all-or-nothing revert semantics.
I4Settled auctions are terminal — Settled status never reverts.State machine forbids transitions out of Settled.
I6Only allowlisted lenders can call requestLiquidation.LiquidationRouter checks REGISTRY.allowedLenders[msg.sender].
I7Auctions are only created from fresh oracle data (within the asset class’s stalenessWindow).Router checks block.timestamp - oracle.lastUpdated(token) ≤ stalenessWindow.
I8Floor price always satisfies minFloor ≤ floor ≤ maxFloor and floor < startPrice.Auction creation reverts on FloorOutOfBounds / FloorAboveStart.
I11Every BidRejected event corresponds to a non-compliant recipient at that block.Adapter call result is the only path that emits BidRejected.
I12Every successful AuctionSettled was preceded in the same tx by exactly one ComplianceChecked(passed=true) for the same (auctionId, solver).Settlement path is reachable only via passed=true.

​
Why each matters

The headline guarantee. The whole point of building Tessera on identity-aware infrastructure is that the protocol cannot be used to circumvent the issuer’s compliance regime. Two-line defense (bid-time check + transfer-hook re-check) ensures this holds even under adversarial sequencing.
Lenders need to know that a “successful” bid means money moved AND collateral moved AND the auction is closed. Solvers need to know that a “failed” bid means none of those happened. Atomicity is the contract.
Once an auction is Settled, it stays settled. No replays, no rollbacks, no surprise mutations. Solvers can update their internal state immediately on settlement without needing to wait for finality games.
Without this, anyone could initiate a liquidation against any registered token. Lender allowlisting is the protocol’s perimeter — only counterparties who have agreed to operate under Tessera’s parameters can use the auction infrastructure.
Stale oracle data leads to absurd start prices and broken auctions. Per-asset-class staleness lets the protocol accommodate quarterly NAV assets without giving up the freshness gate for daily NAV assets.
Prevents both griefing (lender sets floor at 0.001%) and unrealistic optimism (lender sets floor above start). Lender freedom on floor sits within protocol-enforced rails.
Without this, BidRejected events could be emitted speculatively or by error paths. With it, every rejection is a real on-chain claim that this address was non-compliant at this block. Critical for the audit trail.
Every successful settlement is preceded by an explicit pass on the compliance check, in the same transaction, for the same solver. There is no path to settlement that bypasses compliance.

​
What we don’t claim

Equally important: things that are not invariants, and that we don’t pretend to guarantee.
  • Auction always clears. If no solver bids before deadline, the auction expires. The lender falls back to the issuer’s forceTransfer. Tessera does not promise a successful clearing.
  • Clearing price is fair. The protocol does not compute fair value. Solver competition produces clearing prices, and the price reflects what solvers are willing to pay given the asset’s distressed state.
  • Recovery for the lender. The protocol does not guarantee any particular recovery percentage. The lender’s expected recovery is a function of the floor they set, the asset class, the solver pool, and the underlying value at the time.
  • Solver always wins what they bid for. Race conditions resolve via normal Ethereum tx ordering. A solver who bids and loses the race pays no gas beyond the failed transaction.

​
Test coverage

Invariants are verified in an invariant test suite running against forked mainnet at pinned blocks with the real Aqua bytecode. The fuzz suite is the long-running form of correctness verification. Static analysis and human audit complement it.