Trust

Methodology

Effective 2026-08-01

Every crypto number this product issues traces to a versioned formula and a verified input — and everything that cannot is refused with a named reason. This page lists the formulas, the verification rules and the refusal codes as they exist in the code today.

The formula registry, as shipped

Formulas are versioned, immutable identifiers. A result always carries the version that produced it, so a receipt can be recomputed years later against the exact arithmetic it used:

  • risk.linear.v2 — planned all-in loss, exposure and estimated margin for a linear contract, fees and slippage included.
  • perp.linear.usdt.v1 — the contract profiles: BTCUSDT, ETHUSDT and SOLUSDT linear USDT perpetuals with stated lot steps and the USDT≈USD settlement assumption.
  • liq.isolated.linear.v1 — isolated liquidation from a maintenance-margin tier table, solved per tier and accepted only when the solution lands inside its own bracket.
  • funding.scenario.v1 — the holding-cost scenario from a confirmed or sourced funding rate; gated, not yet served by any route.
  • buffer.thresholds.v1 — the liquidation-buffer classification; it never says “safe”, only REVIEW or UNLABELLED.

The engine's golden vectors are hand-computed and pinned in the test suite; a change that moves any of them fails the build.

Verification, and its expiry

A tier table becomes usable only through a recorded verification: the venue's own documentation as source, a usage-rights note, and a date. Freshness then runs on the governance ladder: fresh for seven days; from day eight to fourteen the number still computes but wears a visible “verification due” badge; past fourteen days it is stale, and a stale verification refuses exactly like a missing one — because venues change maintenance tiers without notice.

As of the date above, no tier table has been verified yet. The Liquidation Shield therefore refuses every request, and says so. That is the design working, not a gap in it: the refusal names what has not been checked, where a guess would silently pretend it had been.

The refusal codes

  • TABLE_UNVERIFIED — no recorded verification for this contract's tier table.
  • TABLE_STALE — the verification is older than 14 days.
  • NO_TIER_TABLE — the contract is outside coverage.
  • CROSS_MARGIN_NOT_COMPUTABLE — cross liquidation depends on whole-account state this product does not hold.
  • NO_CONSISTENT_TIER — no verified tier is consistent with the position's notional.
  • NON_POSITIVE_INPUT / BAD_DIRECTION — the inputs cannot be calculated.

What this product never does

No signals, no predictions, no trade quality scores. Green means a rule passes, red means it does not, and a liquidation figure is an estimate of a venue's rule — never a forecast of price. Where the arithmetic depends on something unverified, the product refuses rather than approximates.

See it hold

The same facts, machine-readable: /api/v1/crypto/registry — contracts with lifecycle status, formulas with pinned evidence, tier tables with verification state, and the governance policy. The Liquidation Shield shows the refusal architecture live. The proof demo walks a governed decision end to end, and Limitations states the boundaries in plain language.