Methodology

A benchmark is a rule, a clock and a record.

This page is the rulebook for a CrossDesk fixing and for the people who sign it. Anyone referencing a CrossDesk fixing in a contract is referencing this document. A number nobody can audit is not a benchmark.

Fixing methodology version 0.1 — draft, 12 August 2026 · Signer protocol version 1 — 30 August 2026 · Administrator: CrossDesk. Source documents: docs/FIXING_METHODOLOGY.md, docs/SIGNER_PROTOCOL.md in the repository.

Status. The calculation waterfall, minimum quality conditions, restatement quorum, cessation notice and signer evidence are implemented and tested in the Daml packages. The scheduled strike is detected, not automated: striking is a human act. Nothing here should be read as a claim that a fixing is currently in production — no fixing has been published for commercial use and no committee has been convened. §12 and §P7 state the per-section state.

1. Identification

FieldValue
Benchmark familyCDX
Identifier formCDX-<INSTRUMENT>-<FREQ> — e.g. CDX-CBTC-D (daily), CDX-LX1-D
AdministratorCrossDesk
Currency of quotationThe instrument's cash instrument (e.g. USDC)
LedgerCanton. Every fixing is a NavFixing contract, signed on-ledger

An instrument has at most one fixing per identifier per strike. A second strike for the same identifier and date is a restatement (§6), never a second fixing.

2. What the fixing measures

The price at which the instrument is deemed to transact for settlement purposes at the strike time. It is not an estimate of fair value, a prediction, or an indication of where the instrument may trade next. It is the number contracts settle against.

Two numbers are published side by side and must never be confused:

MeaningBinding?
Official fixingProduced by §3. Creation and redemption settle at this numberYes
Indicative valueDerived continuously from live market dataNo. Informational only

The difference between them, in basis points, is published with the fixing. It is the honest measure of how stale the last strike has become.

3. Calculation — the waterfall

Applied in order. The first tier that produces a value is the fixing, and the tier used is published with it.

Tier 1 — Sealed auction uniform price (preferred)

Where an auction session is held for the instrument, the fixing is the uniform clearing price at which the auction uncrosses, determined from the sealed orders themselves. All executions at that strike occur at that single price. Unpriced market-on-close orders are allocated first; priced orders through the print fill in full, in price priority; only the marginal at-the-print level is rationed, earliest-submitted first — at most one order is ever partially filled.

Minimum quality conditions. The auction price is used only if, at uncrossing:

  • at least two orders rest on the book, and
  • they originate from at least two distinct parties, and
  • the crossed quantity is greater than zero.

If any condition fails, the auction is declared uncrossed and the waterfall proceeds to Tier 2. A single participant cannot set a CrossDesk fixing.

Tier 2 — Committee attestation

A K-of-N OperatorCommittee attests the value. Critically, the committee signs a recipe, not a number:

value(t) = base × (1 + rate × daysBetween(asOf, t) / dayCountBasis)

so the ledger derives the value continuously after the strike rather than holding a number that goes stale. base, rate, asOf and the day-count basis are all signed. For a non-accruing instrument, rate = 0 and the recipe degenerates to a constant.

For a basket, the fixing is Σ (unitsPerShareᵢ × fixingᵢ) over the components. A basket fixing therefore requires a current fixing for every component; if one is missing the basket fixing is not published (§5).

Tier 3 — Carry forward

If neither tier is available, the prior fixing's recipe continues to derive a value and the fixing is published flagged as carried forward, with the age of the underlying strike. Three consecutive carried-forward strikes trigger a review under §8.

The production operating waterfall on the Governance page numbers its steps 1–5 (attested · alternate seats · benchmark × last factor · prior fixing flagged · missed). Tier 2 here is that waterfall's tier 1; Tier 3 here is its tier 4.

4. Strike time and schedule

  • Frequency: every business day, unless the instrument's terms state otherwise.
  • Strike time: declared per identifier at launch (e.g. 16:00 Europe/London) and fixed. It may only change under §9.
  • Business days: the calendar declared per identifier. Where a component's own market is closed, Tier 2 or Tier 3 applies to that component.
  • Publication: as soon as the strike completes. There is no embargo.
  • Ledger latency is not a delay in the fixing. The strike time is the moment the auction closes or the committee's quorum is reached, not the moment the transaction commits.

4a. Strike frequency when the asset trades 24/7 — and when its market is shut

If it trades around the clock, is an hourly NAV needed? No.

Strike frequency follows settlement, not trading.

An ETF trades continuously all day and has exactly one official NAV. Its intraday price comes from the market anchored by arbitrage, not from recomputing NAV; what the exchange disseminates every few seconds is the indicative value, binding on nobody. Creation and redemption settle once, at one struck price. Bitcoin never stops trading, and CME settles every future and option on one daily fixing. Frequency is a settlement decision.

Why more strikes are worse, not better

  1. Every strike costs a quorum. Hourly is 24 K-of-N quorums a day. The N are parties with an existing commercial interest (§7), not staff.
  2. More strikes do not make the settling price more accurate. They multiply the number of published prices someone can dispute.
  3. Manipulation surface grows with every fixing. Benchmarks use few, well-defined strikes deliberately.
  4. A contract needs one referenceable moment. A margin agreement names "the 16:00 fixing", not "whichever of twenty-four."

The one genuine case for more frequency is creation and redemption that must settle intraday. A customer with three settlement windows gets three strikes, declared per §4 and fixed.

How the other 23 hours are covered

Between strikesCovered byApplies to
Derivation from the signed recipe§3 Tier 2 — base, rate, day-count are attested, so the ledger derives a value at every instantAccruing assets: T-bills, money market, anything with a yield
Indicative value§2 — continuous, from live market data, binding on nobodyVolatile assets with an open market: cBTC, cETH
Committee attestation§3 Tier 2 again — as the primary source, not a fallbackAssets whose market is closed

The closed-market case

What is the NAV of a tokenised equity fund at 03:00 on a Sunday? If tokenised stocks trade 24/7, their underlying market does not. Overnight, at weekends and on holidays there is no price for the constituents. Not a stale price — no price. No oracle can solve this: a price feed relays a number that exists, and when the underlying market is shut there is nothing to relay. Somebody must attest a value instead of reporting one — a K-of-N committee signing a defensible mark, with the method published in advance and every signature attributable. That is the case this design was built for.

5. Inputs and their treatment

  • Tier 1 inputs are sealed orders on the ledger. They are visible to no other participant while they rest — including the auditor — and no participant sees the book before the uncrossing. This is enforced by the ledger's signatory/observer model, not by an API filter.
  • Tier 2 inputs are the recipe fields signed by the committee.
  • Indicative value inputs are external market data. External data is never an input to an official fixing. It informs the indicative value only.
  • A wrapped asset's mark is two inputs, not one. Where the instrument is a claim on an asset priced elsewhere (cBTC on BTC, cETH on ETH), the fixing carries the benchmark print (referencePrice) and the par ratio the committee attested (wrapperFactor) as separate signed fields, and the struck price is their product. The benchmark is an input nobody argues about; the ratio is the judgement, and it is the one number no external administrator produces. A pair that does not reconcile cannot exist on-ledger.
  • Incomplete inputs: if a required component has no current fixing, the dependent fixing is not published. A gap is published as a gap. A fixing is never estimated to fill one.

6. Errors, corrections and restatement

  • A fixing found to be materially wrong is restated. Materiality threshold: 1 basis point of the published value, or any error that changes a settlement obligation.
  • A restatement is published as a new record referencing the original, with the reason. The original is never deleted or overwritten — the ledger record is immutable by construction.
  • Restatement window: two business days from publication. After that the fixing stands, and a dispute is a matter for the contract that referenced it. This window is policy, not code: business-day arithmetic needs a holiday calendar the package does not carry, and enforcing two calendar days would silently shorten the window across a weekend. Both the original and the restatement carry their own finalizedAt, so a correction made outside the window is auditable after the fact.
  • Anyone may report a suspected error to the administrator. Corrections require the same K-of-N quorum as a fixing — enforced by RestatementProposal. One signer cannot correct the record alone.
  • The corrected fixing must differ from the published one, and must carry a non-empty reason. A restatement with no stated reason is indistinguishable from tampering, and both are refused on-ledger.
  • The superseded fixing is not archived. It stays on the record, provably published, with the correction pointing back at it. Archiving it would require the original attestors' authority, which would let the members who published a wrong number veto its correction.
  • Consumer rule: the current fixing for an (instrument, session) is the one that no other fixing supersedes — equivalently, the newest finalizedAt.
  • Disclosure survives a correction: every party disclosed the original is disclosed the replacement.

7. Oversight and governance

  • The OperatorCommittee is the oversight function. N signers are named on-ledger; K signatures are required. Both are public per identifier.
  • The N are parties with an existing commercial interest in the instrument — the collateral taker, the issuer, the administrator, the market maker who quotes it. They are not paid to attest. Attestation is a by-product of a position they already hold. A panel of disinterested referees would never be assembled or funded.
  • Every signature is attributable and permanent. Who signed which fixing is on the ledger forever.
  • What each signer asserts is defined, not left to judgement. The signer protocol below sets out, per role, the named conditions a member verifies before confirming. No member is asked for an opinion about the price. A signer declines by naming a condition that failed, not by disagreeing.
  • The composition must be opposed. The issuer favours par, the lender favours prudence, the venue favours the observed print. No single interest holds K.
  • The administrator does not trade the instruments it prices. This is a hard constraint on CrossDesk's own business model, not a preference.

8. Cessation

If a fixing is to be discontinued, the administrator publishes a cessation notice no less than 60 calendar days before the final strike, naming the final strike date and, where one exists, a recommended successor. Contracts referencing the fixing need that window to amend. Three consecutive carried-forward strikes trigger a review of whether the fixing should cease. The sixty days are enforced on-ledger (CessationNotice); an extension may only move the date later.

9. Changes to this methodology

  • Material changes — the waterfall, the strike time, the minimum quality conditions, the materiality threshold, K or N — require 30 days' notice before taking effect.
  • Non-material changes (clarifications, typographical corrections) take effect on publication.
  • Every version of this document is retained. A fixing is always interpreted under the version in force at its strike.

10. Publication and access

Each published fixing carries: identifier · strike date and time · value · tier used · signers · drift versus indicative value in basis points · and, if carried forward, the age of the underlying strike.

Read access is via the CrossDesk API (/api/benchmarks, /api/series/{id}). Referencing a CrossDesk fixing in a contract requires a licence from the administrator; reading a published fixing does not.

11. What this document does not do

It does not make CrossDesk a regulated benchmark administrator. Benchmark administration is a licensed activity in the EU and UK; CrossDesk is not authorised or registered in those jurisdictions and this methodology is not a claim otherwise. Where an EU- or UK-supervised entity wishes to reference a CrossDesk fixing in a regulated product, the recognition or endorsement route must be resolved first. See Regulatory.

12. Implementation state, stated plainly

SectionStatusNote
§3 Tier 1 auction, uniform price, rationingimplemented, tested
§3 Tier 1 minimum quality conditionsimplemented, testedEnforced in the uncrossing as module constants an operator cannot lower
§3 Tier 2 committee attestation of a recipeimplemented, tested
§3 Tier 2 basket summationimplemented, tested
§3 Tier 3 carry-forward flaggingimplementedA fixing older than one interval is returned with carriedForward and the age of the strike
§4 Scheduled strike at a fixed timedetection onlyFixingSchedule declares the time and zone and reports PENDING / DUE / OVERDUE / STRUCK. The desk does not auto-strike: a fixing nobody attested is not a cheaper fixing. Business days are approximated as weekdays
§5 Gap rather than estimateimplementednavPerShare returns nothing on a missing mark
§5 Wrapper mark as two signed fieldsimplemented, testedReconciliation enforced on-ledger
§6 Restatementimplemented, testedSame K-of-N as a fixing. The two-business-day window is policy, not code
§7 Per-signer evidence on the published fixingimplemented, testedThe venue's range is enforced; the issuer's and lender's claims are recorded, not machine-checked
§7 Fund behaviour when K is not reachednot specifiedBelongs to the fund's governing documents, not the administrator's
§8 Cessation noticeimplemented, testedSixty calendar days enforced on-ledger
§10 Lookup by identifier and dateimplementedPublished series with the §6 consumer rule applied, an optional as-of, and any cessation notice

Two honest limits remain: striking is a human act (by design — the schedule reports a missed strike rather than inventing a number nobody attested), and no holiday calendar is carried, so the §6 window and §4's business days are approximations that are stated rather than hidden. Two decisions are deliberately not the administrator's: what a fund does when the committee cannot reach quorum, and whether an EU- or UK-supervised entity may reference these fixings at all.


Signer protocol — P1. The one rule

No signer is ever asked for an opinion about the price. Each signer asserts a fact only it can see.

A committee whose members are each asked "do you agree this is the right price?" is a committee that rubber-stamps — not from bad faith, from economics. Signers are not paid; an unpaid member asked for a daily act of judgement will, within a fortnight, click yes. A signature that means nothing is worse than no signature, because it looks like governance. So the question put to each member is narrowed until it is nearly free to answer:

Asking for judgementAsking for a fact
Cost to the signerHigh — requires forming a viewNear zero — a query against their own systems
Can it be automated?NoYes, and it should be (P4)
What refusal means"I disagree" — unactionable"Attestor quorum was 5 of 10" — actionable
Failure modeRubber-stampingThe check fails and the fixing stops

Two properties follow: signing is cheap, which is what makes an unpaid committee operable at all; and refusal is specific, which tells the administrator, the fund and every other signer exactly what broke.

This is not a claim that the committee resembles a regulated oversight function. Under the IOSCO principles and the UK/EU Benchmarks Regulation, an administrator's oversight committee is composed to be independent of parties with positions. This design does the opposite deliberately: it seats parties because they have exposure. P6 states that challenge at full strength.

P2. The seats, and what each one asserts

The three roles want different answers: the issuer wants the wrapper marked at par; the lender wants it marked conservatively, because it is the one under-collateralised if the mark is too high; the venue wants it marked where the asset actually traded. A committee of three issuers is not a committee.

Issuer — redemption integrity

The party that issues the wrapped asset. It uniquely knows whether the wrapper can actually be redeemed right now.

ConditionNamePass when
Attestor quorumattestor-quorumAt least the issuer's own threshold of attestors are online and signing
Reserves currentreserves-currentThe most recent proof-of-reserve attestation is less than 24h old
Reserves sufficientreserves-cover-supplyAttested reserves ≥ circulating supply of the wrapped token
Redemption queue clearredemption-queue-clearNo redemption request is unfilled beyond its stated window

If all four pass, the issuer may attest wrapperFactor = 1.0. If any fails, the issuer does not sign at par: it declines, or the proposer restrikes with a factor below par and a rationale naming the failed condition. The par factor is the only field in the system no benchmark administrator anywhere produces, and the issuer is the only party with the facts to justify it.

Lender — the mark is safe to lend against

A platform holding the asset as collateral. It uniquely knows whether it will actually carry this number on its own book. This is the strongest signature in the protocol: the only one where the signer asserts something against its own money.

ConditionNamePass when
Independent mark agreesindependent-mark-within-toleranceThe proposed mark is within the lender's declared tolerance (recommended 25 bp) of its own valuation
Liquidations consistentliquidations-consistentNo liquidation the lender ran in the session cleared materially away from the proposed mark
Book acceptancebook-acceptanceThe lender will mark its own collateral at this level for the period the fixing governs

A lender that signs book-acceptance and then marks its own book somewhere else has made a false statement, on-ledger, with its own signature on it.

Venue — the mark sits where the asset traded

A venue where the wrapped asset actually trades. It uniquely holds the transaction data — the only seat with observed prints for the wrapper, since the underlying benchmark does not price it.

ConditionNamePass when
Traded rangetraded-rangeThe proposed mark lies within the high/low the venue's own book traded in the window
Spreadspread-within-toleranceBest bid/ask spread at the strike is inside the declared tolerance
Sufficient volumesufficient-volumeTraded volume in the window meets the declared minimum, else the venue has no basis to attest

A venue supplying observedLow and observedHigh is enforced on-ledger: the confirmation refuses an attestation whose range does not contain the price, an inverted range, or a half-specified one. A venue cannot sign a price its own book never printed. This is the sharpest guard in the system and the most informative refusal available.

Operator (CrossDesk) — proposes, and should not sign

CrossDesk computes the proposal — the benchmark print, the units per share off the ledger, the accrual inputs, the resulting NAV — and publishes all inputs with it. The administrator does not trade the instruments it prices; signing is the adjacent conflict. Where a pilot has only three available seats, CrossDesk signing is tolerable at the very start and must be exited as soon as a fourth party exists — recorded with role = "operator" so the exception is visible on every fixing it touched.

P3. The mechanism

benchmark print                  ← public input; CrossDesk does not build it
        ↓  (transported on-ledger — a technical claim, not a seat)
ProposeWrappedFixing             ← benchmarkPrice × parFactor = the struck price
        ↓
ConfirmWithChecks × K            ← each member names the conditions it verified
        ↓
FinalizeFixing → NavFixing       ← signatory set IS the attestor set
        ↓
Create / redeem settles atomically against it

Why the oracle is not a seat. An oracle asserts "this is faithfully the benchmark print" — a transport claim. It has no money riding on the answer, so its vote carries no information, and it dilutes the opposed-interests property. It also cannot answer the question the committee exists for: when nobody quotes the wrapper, an oracle has nothing to relay. An oracle's commercial relationship to CrossDesk is redistribution, not attestation.

What lands on the ledger. Each SignerCheck carries the member, its role, the protocol version it applied, the named conditions it verified, and (venue only) the observed range. The finished NavFixing carries the list. The fixing answers why, not only who.

P4. Automating a seat

Every check in P2 is a query against the signer's own systems. None requires a human to form a view. A signer should run a checker that confirms automatically when all its conditions pass and halts and escalates when one does not. An unpaid committee that requires daily human attention will decay into rubber-stamping within weeks; a seat that is automated is a seat that is still honest in month six.

A checker must never auto-confirm on a failed condition, and must never widen its own tolerances to make a check pass. Both are silent conversions of this protocol back into a rubber stamp. A checker that halts notifies the administrator with the failed condition named; the administrator either restrikes with a corrected input, or the fixing does not happen.

P5. When K is not reached

No NavFixing exists. No auction prints, and the fund's NAV per share returns nothing rather than a guess — a gap is published as a gap. What the fund does then — suspend creations and redemptions for the session, or invoke a declared fair-value procedure — belongs to the fund's own governing documents, not to the administrator, and it must be specified before any fund relies on this.

P6. The strongest objection, stated fairly

"You have seated people with positions and called it oversight. That is LIBOR."

It is the best argument against this design. LIBOR's panel banks submitted rates on instruments they held positions in, and some moved submissions to suit those positions. Three differences, structural rather than rhetorical:

  1. The panel is composed to disagree. LIBOR's submitters shared a direction of interest. Here the issuer wants par, the lender wants conservative, the venue wants observed — and no single interest holds K.
  2. Submissions are verifiable rather than asserted. A LIBOR submission was an unfalsifiable estimate of where a bank could borrow. Every check in P2 is a fact with a record behind it, and the venue's is checked by the ledger itself.
  3. Every signature is permanent and attributable. LIBOR ran on phone calls and unlogged discretion. Here who signed which fixing, under which protocol version, having verified which conditions, is on the ledger forever.

What honesty requires conceding: this is a mitigated conflict, not an absent one. A regulated administrator would seat independent members and manage conflicts by exclusion. This design cannot — a panel of disinterested referees would never be assembled or funded for an asset this size — so it manages conflict by opposition and evidence instead. An EU- or UK-supervised entity referencing a CrossDesk fixing must resolve §11 first; this section does not substitute for that.

P7. Implementation state, stated plainly

SectionStatusNote
P2 role definitions and named conditionsimplemented, tested at the edgeThe API refuses a condition that does not belong to the declared seat, an unknown role, an empty or repeated checklist, a venue without a range, and a non-venue with one
P2 the conditions a signer is shownimplementedGET /api/signer-protocol serves the same list the validator uses; the desk renders its checkboxes from it
P2 venue range enforcementimplemented, testedRefuses a price outside the range, an inverted range, or a half-specified one
P2 one attestation per member, signed by that memberimplemented, tested
P3 wrapper mark as an explicit fieldimplemented, tested
P3 evidence survives finalisation onto the fixingimplemented, tested
P4 reference checker implementationsnot builtEach signer writes its own against its own systems
P5 fund behaviour when K is not reachednot specifiedBelongs to the fund's governing documents
P2 operator-exit rulepolicy onlyrole = "operator" makes it visible; nothing enforces the exit

In three layers: the ledger enforces the venue's traded range and the arithmetic of the wrapper mark. The API enforces that a claimed condition belongs to the seat claiming it. Nothing enforces that the issuer's attestor quorum really was met, or that the lender will really mark its book at that level — those rest on the signer's own systems and on the fact that a false attestation is permanent, attributable, and made against their own money. That residual trust is deliberate, and it is disclosed to anyone taking a seat rather than glossed.