Open Treasury Yield Basis: Specification v1.1

Status: published and in force. The reference implementation serves it live. Version: 1.1.0 Published at: https://402rates.com/basis-spec-v1 Reference implementation: 402rates.com, capability compass.rwa.yields over x402 Date: 2026-09-01

Corrections are recorded in §11. Every correction to an observation or a published figure is listed there. Figures quoted from issuers are reproduced as they were published on the date given and are not restated afterwards.

---

0. Why this document exists

Every issuer of a tokenized treasury publishes a yield on its own basis. The figures carry names like 7-day yield, 30-day yield, APY and distribution yield, and they are not the same quantity. Aggregators restate them side by side under one column heading, which produces a table of mismatched units rather than a comparison.

Two findings from our own census of 22 instruments (99_log/rwa-census.md, 2026-07-29) motivate this specification:

1. **The most transparent issuer in the field publishes a figure that cannot be

reproduced from its own published data. Superstate exposes a keyless API with 939 daily NAV points and a written definition. Its thirty_day field is 3.5506 %. Reconstructed strictly on its own stated definition from its own published fields, we land at 3.6067 % - 5.6 basis points off, and no variation of the day count closes the gap. On a NAV-ratio basis, the same field is 30.8 basis points** away, because it is not a NAV-ratio measure at all. It is a different quantity wearing a familiar name.

1. Half the market cannot express a yield in its price. For BUIDL, BENJI,

VBILL and WTGXX the NAV is pinned at 1.00 by construction and the yield arrives as additional tokens. No price series can measure it.

So the gap in this market is not a missing dataset. It is a missing definition. This document is that definition. It is written to be implemented by a stranger, and the numbers we publish are evidence that it works - not the other way round.

---

1. The measure

1.1 In words

The Open Treasury Yield Basis is the realised change in an instrument's own value per share over a fixed thirty-day window, annualised on actual calendar days and a 365-day year, computed from the instrument's own state and net of fees by construction because the value per share is already net.

1.2 In arithmetic

For an instrument with value per share V observed at two points:

d  = calendar days between the two observations, using each observation's
     SOURCE-DATED day, never the day we happened to read it

y  = (V_end / V_start - 1) * 365 / d

V is the instrument's value per share for its accrual family, per §2.

1.3 The three choices, and what they were chosen over

Each was tested against real series before being fixed here. The alternatives are named so a reader can disagree with evidence rather than taste.

Window: 30 calendar days. Seven days is too short for these instruments: Superstate's own one_day field for its crypto-carry fund read 10.92 % against a thirty_day of 2.74 % on the same date. A treasury NAV moves in the fourth decimal place, so a short window amplifies rounding and a single missed update into a headline number. Thirty days is also the window most issuers quote, which makes the comparison in §6 meaningful rather than incidental.

Annualisation: simple, × 365 / d. Not continuous.

Two reasons, and neither of them is a comparison against another issuer's figure.

First: continuous compounding asserts something the data does not contain. The compounding form is e^(r·365/d) − 1 - Ondo's own published formula for OUSG, verbatim: "30-Day Yield = e^((End NAV - Start NAV) / (30/365)) - 1". It takes the linearly annualised return and treats it as a nominal rate compounded continuously for the rest of the year. Nothing in a thirty-day NAV observation supports that reinvestment. It is a forward assumption dressed as a measurement, and it always produces the larger number. Simple annualisation asserts only what was observed, scaled linearly to a year, and says so in the field name.

(A third form exists and is used by neither: (1+r)^(365/d) − 1, the effective annual rate under reinvestment once per window. It sits about 2 bp below Ondo's form on these instruments. It is named here only so a reader who computes it does not think one of us is wrong.)

Second: it is the convention the issuers themselves name. Franklin Templeton, verbatim: "assumes that the same income is generated each week over a 365-day period" - a linear scaling, not a compounding one. Ondo publishes its yield formulas against a 365-day year. Where an issuer states a convention at all, it is this one, so a reader converting between our figure and theirs has one fewer transformation to get wrong.

The table below is corroboration, not justification. It cannot be justification: Spiko publishes no definition for monthlyYield - this specification says so in §6.1 - so agreement with it is evidence that our convention is the one the market reaches for, not proof that it is correct. Both annualisations are stated in every response so a reader can convert either way.

Instrument	our simple	our continuous	Spiko monthlyYield	simple error	continuous error
Spiko EUTBL	2.1515 %	2.1748 %	2.1700 %	−1.8 bp	+4.8 bp
Spiko USTBL	3.4332 %	3.4928 %	3.4400 %	−0.7 bp	+5.3 bp
Spiko UKTBL	3.5542 %	3.6181 %	3.6000 %	−4.6 bp	+1.8 bp

Mean absolute deviation: simple 2.4 bp, continuous 4.0 bp.

Day count: actual / 365. Actual days, because the window is anchored on observations and observations fall where the source puts them, not on an idealised calendar. 365 rather than 360 because it is the convention the issuers themselves state - Franklin: "assumes that the same income is generated each week over a 365-day period"; Ondo publishes its formulas with 365. Using 360 would inflate every figure by 1.4 % relative for no reason a reader could check.

1.4 One deployment produces the number; the others are evidence

An instrument deployed on eight chains has up to eight readable values for the same NAV, and they do not agree. Spiko's Ethereum oracle was 568 days behind its Polygon oracle, which was 14 days behind its API, all for the same fund on the same day.

Therefore, and this is a MUST:

• Each instrument names exactly one primary source in the catalogue

(primary_source_id). The Basis is computed from that source and no other.

• Every other readable deployment is recorded by the recorder and appears in

the response as an observation, with its own age and its own endpoint.

• **Divergence between deployments is a published finding, never a computation

input.** It is not averaged, not reconciled, not used to correct the primary. It is stated, with both values and both ages, in deployment_divergence.

An instrument that cannot name a primary source names none, records why, and is quoted by construction. This is not a loophole in the MUST above, it is what the MUST is for: a catalogue that named a source incapable of producing the number - a total supply, an unverified holder, a stale oracle - would satisfy the letter of the rule and defeat its purpose. In v1.0.0 all three Family B instruments name none, because a passive holder per §2.2 does not exist yet.

This resolves the tension between §1 - one number per instrument - and §5.2 - freshness per source and per chain - without adding a mechanism. There is one number because there is one named source; the other chains are how a caller sees that the number is not the only thing the chain says.

A change of primary_source_id changes published figures and therefore forces a new specification version under §9.

1.5 What is not in the measure

Not included, and named so nobody assumes otherwise: expected forward yield, gross yield before fees, any smoothing or averaging across windows, any adjustment for subscription or redemption fees, currency conversion, and any tax treatment. The Basis is a backward-looking realised figure on the instrument's own currency.

---

2. The two accrual families, and why they cannot be mixed

An instrument's yield reaches its holder in one of two ways. The arithmetic in §1.2 applies to both, but V is a different observable, and a figure from one family is not comparable to a figure from the other as a measurement - only as a published number.

2.1 Family A - price accrual

The value per share rises; the holder's token count is constant. V = NAV per share, or the oracle's price per share.

Verified members: OUSG, USDY, USTB, USYC, TBILL (OpenEden), mTBILL, EUTBL, USTBL, UKTBL.

The observable is public and holder-independent: anyone reading the same oracle or API on the same day gets the same V. This is the family in which the Basis is fully measured.

2.2 Family B - supply accrual

The NAV is pinned at 1.00 by construction; the yield arrives as newly minted tokens. V = the balance of a designated passive holder, not a price.

Verified members: BUIDL, BENJI, VBILL. (WTGXX belongs here but has no machine-readable source at all.)

totalSupply is not a permitted observable for this family. Supply grows through subscriptions as well as distributions, so a yield derived from it would count new money as income. This is the single most tempting error available in this market and it is prohibited here.

A designated holder qualifies as passive over a window only if:

• it recorded no Transfer in or out over the window other than distributions

received, and

• that absence was verified against the transfer log, not assumed from the

balance moving smoothly, and

• the verification itself is published as an input under §5.

A holder that subscribed or redeemed inside the window is not a yield series. If passivity cannot be verified, the instrument is quoted and not measured - there is no intermediate state.

As of 2026-07-30 no Family B instrument qualifies. Candidate holders are recorded daily (five for BUIDL, three for BENJI, four for VBILL) but passivity is a property of a series that begins on that date, and verifying it requires transfer history that public nodes refuse without archive access. Every Family B figure published before that is resolved is quoted.

2.3 Why the families are reported together but never ranked together

Excluding Family B would put roughly half the market's capitalisation into known_not_covered, which is a weaker and less useful answer. Ranking a quoted figure against a measured one would be worse: it would present an issuer's self-reported number as if we had checked it. Both families appear in every response; only measured figures rank. See §4.

---

3. Scope

3.1 In scope

A tokenized share in, or note over, US, EU or UK treasury bills or government money-market instruments, where all of the following hold:

• the issuer publishes at least one contract address in a primary source, or we

have read the address on chain ourselves;

• the accrual mechanism is established from the issuer's own documentation;
• eligibility is quoted from the issuer's own words, or recorded as unknown.

3.2 Out of scope, deliberately

• Stablecoins with treasury reserves (USDL, USDtb, AUSD, M^0, RLUSD). A claim

on a reserve is a different legal form, a different risk and a different question. They may get their own basis; they do not get this one.

• Crypto-carry and basis-trade funds (Superstate USCC, Midas mBASIS,

mEDGE, mRe7YIELD, Spiko SAFO and SPKCC). USCC's own one_day of 10.92 % against a thirty_day of 2.74 % is the reason: this is not a treasury return distribution and averaging it into one is misleading.

• Private credit (Coinbase CUSHY at SOFR + 400–700 bp).
• Tokenized equities.

3.3 What disqualifies an instrument from a figure

An in-scope instrument still produces no Basis figure when any of these holds. Each becomes an entry in known_not_covered with the reason and with what would be needed to close it:

• no machine-readable observable at all (WTGXX, Backed bIB01/bIBTA/bC3M);
• an observable that exists but cannot be read without credentials we do not

have (JTRSY: the Chronicle consumer reverts unauthenticated);

• fewer than the minimum observations in the window (§5.3);
• for Family B, no verified passive holder.

---

4. measured and quoted

Every published figure carries yield_basis.

measured requires all of:

1. every observable in the window came from the instrument's own state - an

oracle, a contract read, or the issuer's own NAV series;

1. both window endpoints are source-dated (§5.1);
2. the window satisfies §5.3;
3. for Family B, a verified passive holder per §2.2;
4. every input is published in the response so the figure can be recomputed.

quoted means the issuer stated a figure and we did not compute it. A quoted figure is published with the issuer's own definition verbatim, its own window, its own as-of date, and a note where we could not reproduce it.

The ranking rule: a quoted figure never competes with a measured one. Ranking, any "highest" statement and any spread are computed over measured rows only. Quoted rows are present, labelled, and unranked.

This shares a principle with the cost side of the reference implementation - a figure with a weaker basis never sets a ranking - but it is deliberately not the same rule, and an earlier draft of this section claimed it was. On the cost side an incomplete figure is a lower_bound: it still competes, because a floor constrains where the true value can be. A quoted yield constrains nothing. Its window, its convention and its reproducibility are all outside our control, and one of them was measured to be irreproducible from the issuer's own published inputs (§6.2). So a lower bound is ranked with a caveat; a quoted figure is not ranked at all.

Ranking is also within one currency and one family. A EUR treasury yield and a USD treasury yield differ mostly by the currency's own risk-free rate, and the Basis performs no currency conversion (§1.5). Comparing them would produce a league table of central bank policy rates wearing an instrument's name. Rows are therefore grouped by (family, currency) before anything is called highest, and §2.3 already forbids ranking the two families against each other.

There is no third value. "Partly verified" is not a basis.

---

5. Observations, freshness, and the window

5.1 Source-dated, never read-dated

An observation belongs to the day its source assigns it, not to the day we read it. Where a source carries no date of its own, the observation belongs to the day we read it and is marked as such; such an observation may never be used to date a point in the past.

This rule exists because of a measured failure. Phase 1's first comparison of our figure against Superstate's was 9 % off, purely because the newest NAV point was matched against an as_of_date two days older. After correction the gap was 0.42 bp. A yield that looks slightly wrong is more dangerous than one that looks absurd, because nobody checks it.

5.2 Freshness, per source and per chain

Every source declares a maximum age. An instrument whose newest usable observation exceeds it produces no measured figure - unprovably fresh data would be wrong, and wrong data is refused rather than sold.

What that means for a request depends on what the request asked for, and the distinction is deliberate:

• A stale instrument inside a multi-instrument answer is named, carries

yield_basis: "unavailable" with the age that disqualified it, and falls back to its quoted figure where one exists. The remaining instruments were computed correctly, so the answer is partial and true, is delivered, and is charged for. Turning one issuer's outage into a failed request would mean withholding eleven correct figures and raising our error rate until discovery indexes filter us out.

• **A request that resolves to exactly one instrument, and that instrument is

stale**, produced nothing. It is refused as STALE_SOURCE, with no settlement.

Both branches come from the same rule - never publish a number we cannot prove, never charge for something we did not deliver. An earlier draft of this section stated only the second branch; that phrasing was written for a single-instrument request and would have made one stale oracle take down the whole capability.

Source kind	max age	derivation
daily NAV oracle or API	5 calendar days	the longest closure these funds face, see below
oracle without its own timestamp	1 day	the only age it has is our read time
issuer yield figure	35 days	it is quoted, not measured, and carries its own as-of

Where the five days comes from. These funds price on business days. The longest run of consecutive non-business days in the markets they trade in is four - Good Friday, Saturday, Sunday, Easter Monday - which puts five calendar days between the Thursday pricing and the following Tuesday one. Four days would therefore disqualify a legitimately priced fund once a year. Measured against our own recorded series, over the last 90 days: USTB, EUTBL, USTBL, USYC and mTBILL never exceeded a 4-day gap; UKTBL had exactly one 5-day gap. Both the derivation and the measurement point at five.

Freshness is evaluated per source and per chain, never per instrument. The same instrument reads differently on different chains, and the difference can be enormous: Spiko's Ethereum oracle last updated on 2025-01-07 and was 568 days stale when read on 2026-07-29, while its Polygon oracle lagged 14 days and its API was same-day. A chain read is not a current read.

Consequence, stated in the specification rather than buried in code: a source that is structurally stale is not a source. Spiko's on-chain oracles are excluded by name, with the reason recorded, rather than being read and then discarded at runtime.

5.3 Window admission

A window produces a measured figure only when all of the following hold.

(a) The actual span is 28 to 32 calendar days. A nominal thirty with tolerance for weekends and holidays at either end. Outside that range the instrument is not comparable for this window and says so; it does not get a shorter window fitted to its history, because a window chosen to fit the available data is a window chosen to produce a number.

(b) No gap between consecutive distinct observations exceeds the source's declared maximum age - five calendar days for a daily NAV source, per §5.2.

This is the rule that replaces an arbitrary minimum count, and it is the same rule as §5.2 applied inside the window rather than at its edge. The reasoning: if a source may be at most five days stale to be usable at all, then a stretch of more than five days inside the window is a stretch during which the instrument was, by our own standard, not fresh. Without this condition a source that stopped updating mid-window would still produce a confident figure from two endpoints straddling the silence.

(c) A derived consequence, not a separate rule: at least seven distinct observations. It follows from (a) and (b) - covering 28 days with no gap above five requires at least ⌈28 / 5⌉ = 6 intervals, hence 7 observations including both endpoints. It is stated explicitly only so an implementer can assert it directly.

The floor sits far below normal operation, which is the point: it bites when a source genuinely stops, not when a market closes. Measured on our own series, 32-day windows ending 2026-07-30 contained:

Instrument	distinct observations	largest gap
USTB	22	4 d
EUTBL	23	3 d
USTBL	21	4 d
UKTBL	22	3 d
USYC	22	4 d
mTBILL	20	4 d

(d) Carried-forward duplicates count once. Superstate's series repeats the same tuple across weekends: of 30 consecutive rows ending 2026-07-27, only 21 carried a new value. Counting the repeats would overstate the evidence behind the figure by 43 %, and it is what made the Phase 1 census read a 21-day window where a 30-day one was expected.

(e) Both endpoints are the highest revision recorded for their day (§7).

5.4 Which window, when several qualify

A 28-to-32-day tolerance means a daily series offers up to five admissible windows on any given day, and they do not produce the same number. Two implementations that both follow §5.3 could therefore publish two different figures and both be right. That is unacceptable in a specification whose purpose is comparability, so the choice is fixed here:

1. The end point is the newest distinct observation that satisfies §5.2. Not

the newest observation - a carried-forward repeat is not a new observation (§5.3 d), and dating the window's end to the repeat would stretch d without adding evidence.

1. **The start point is the observation that produces the admissible window

whose span is closest to 30 days.** Admissible means every condition of §5.3 holds for that window, gap rule included - a window that violates §5.3 is not a candidate, it is not a fallback either.

1. On a tie, the longer span wins - 28 and 32 days both being one day from a

theoretical 30 cannot happen, but 29 and 31 can. The longer window rests on more observations, and preferring more evidence is the only tiebreak that does not need a second justification.

The rule is stated as an algorithm rather than a principle because determinism is the whole point: given the same recorded observations, every implementation of this specification must publish the same figure, down to the last digit.

---

6. The issuer's figure, published beside ours

Where an issuer publishes a machine-readable figure, the response carries it next to ours with its own definition and as-of date. Where the two disagree, the disagreement is stated, not smoothed.

This is the most valuable field in the response, and it is why this specification exists.

6.1 Worked example - a figure that reconciles

Spiko EUTBL, window 2026-06-29 → 2026-07-29, 30 days.

V_start = 1.05408500   (source-dated 2026-06-29, public-api.spiko.io)
V_end   = 1.05594900   (source-dated 2026-07-29, public-api.spiko.io)

y = (1.05594900 / 1.05408500 - 1) * 365 / 30 = 0.021515  ->  2.1515 %

issuer: monthlyYield = 0.0217  ->  2.1700 %      difference: -1.8 bp

Spiko publishes no definition for monthlyYield; docs.spiko.io disallows automated access, so the convention could not be read from a primary source. Our reconstruction lands within 1.8 bp across EUTBL, 0.7 bp across USTBL and 4.6 bp across UKTBL, which is evidence - not proof - that the field is a simple annualisation of the NAV ratio over about thirty days. Recorded as such.

6.2 Worked example - a figure that does not reconcile, and why

Superstate USTB. The issuer's definition, verbatim:

"30 Day Yield is reflective of the accrued net income from USTB's underlying holdings over the past thirty days divided by the average outstanding shares for that same period, divided by the last calculated NAV of USTB, and then annualized. This 30 Day Yield calculation is inclusive of fees and expenses."

Their published figure: 3.5506 % (as_of_date 2026-07-28).

computation	result	difference
Open Treasury Yield Basis, 30-day NAV ratio, 2026-06-30 → 2026-07-30	3.2427 %	−30.8 bp
their definition, reconstructed from their own published fields, weekend carry-forwards deduplicated, × 360/30	3.6067 %	+5.6 bp
the same, × 365/30	3.6568 %	+10.6 bp
the same, weekend carry-forwards counted as observations	4.7123 %	+116.2 bp

Two conclusions, and both belong in the response:

1. Their figure is a different quantity, not a different convention. It is

income over average shares over NAV. The Basis is a change in NAV per share. The 30.8 bp gap is what the two measures are, not an error in either.

1. Even reconstructed on their own definition, it does not close. 5.6 bp at

best, from the issuer with the best data in the field. The residual is consistent with the undocumented treatment of the weekend carry-forward rows, and it cannot be resolved from public inputs.

The Phase 1 census reported that the closest fit to their figure came from a 21-day window, which looked like a contradiction of the field's own name. It was not: a 30-row window ending 2026-07-27 contains exactly 21 distinct value days. The two observations are the same fact from opposite sides. Recorded here as a correction to the census's phrasing.

USTB is therefore published as measured on the Basis, with Superstate's figure alongside as quoted, with the definition, and with the difference stated.

---

7. Inputs are part of the answer

Every figure ships the inputs that produced it. This is not a courtesy: a basis nobody can recompute is just another issuer figure with a different logo on it.

The response carries, per figure:

• both endpoint observations: value, source-dated day, source id, source method,

the block number and block timestamp where the read was on chain, the endpoint that answered, and access: "public" | "archive";

• the window in actual days and the count of distinct observations in it;
• the annualisation and day count as literals, not as a reference;
• basis per §8;
• for Family B, the designated holder and the evidence of its passivity.

Recorded observations are append-only. A correction is a new revision with a stated reason and the superseded row remains readable. A series that can be silently rewritten proves nothing to anyone who cited it last month.

Values are carried as integers with their own decimals, and converted to decimal strings without floating point. Two reasons, both measured: BENJI has 18 decimals and a balance of 47 940 547.349210462890046092, which a double cannot hold; and EUTBL has 5 decimals, not 6 - assuming the common value would misstate every EUTBL figure by a factor of ten.

---

8. The basis block

Every response carries the specification, not just the number, so an agent that stores our figure can state later - without us - which definition produced it.

"basis": {
  "name": "Open Treasury Yield Basis",
  "abbreviation": "OTYB",
  "version": "1.1.0",
  "spec_url": "https://402rates.com/basis-spec-v1",
  "window_days": 30,
  "window_tolerance_days": [28, 32],
  "annualisation": "simple",
  "day_count": "actual/365",
  "family": "price_accrual",
  "observable": "nav_per_share"
}

---

9. Versioning

A cited basis that can change silently is worth nothing. Therefore:

May change inside version 1.x - additive only: new instruments, new chains, new sources for an existing instrument, additional response fields, prose clarifications that do not alter a computed value, and corrections to recorded observations that follow §7.

Forces version 2.0 - anything that can change a published figure: the window, the tolerance, the annualisation, the day count, the minimum observation count, the window selection rule of §5.4, any change of an instrument's primary_source_id (§1.4), the definition of an admissible observable for either family, the passivity requirement, and the ranking rule between measured and quoted.

Every published figure carries the version that produced it. Superseded versions stay published at their own URL. A figure computed under 1.0.0 remains recomputable under 1.0.0 forever, whatever the current version is.

Version history

1.1.0 - 2026-09-01. The published name changed from Open Treasury Basis (OTB) to Open Treasury Yield Basis (OTYB). The calculation did not change: observable, input selection, 30-day window, 28–32-day tolerance, minimum observation count, deterministic window selection, simple annualisation, actual/365 day count, source rules and ranking are identical to 1.0.0. The response envelope remains schema version 0.5.0, and the public URL remains /basis-spec-v1/.

1.0.0 - 2026-07-30. First published version, under the former name.

---

10. Reference implementation

402rates.com, capability compass.rwa.yields, over x402. The implementation is not the specification: anyone may implement this document, and a second implementation that disagrees with ours on the same inputs is a defect in one of the two, to be resolved in public.

The public conformance vectors are the JSON document at /basis-spec-v1/test-vectors.json. Each vector carries its complete input, the expected result and a SHA-256 digest of the exact input object. An independent implementation that produces every expected result from those inputs is OTYB-1.1.0 conformant. Passing the vectors establishes arithmetic conformance only; source selection, evidence quality and passive-holder verification remain the implementer's responsibility under §§1, 2 and 5.

Open at the time of writing, and stated rather than hidden:

• No Family B instrument has a verified passive holder yet. All Family B figures

are quoted until the recorded series and transfer history allow verification.

• OUSG, USDY and OpenEden TBILL have a readable current price and no readable

history. Their own recorded series begins 2026-07-30; until 28 days of it exist they are quoted.

• Archive access is not configured. Without it, Family B promotion and older

history for OUSG and Spiko stay out of reach. The configuration hooks exist (ARCHIVE_RPC_<CHAIN>) and every read already reports access: "public" | "archive".

• **Open, and deliberately unresolved in v1.0.0: how a distribution is told

apart from a subscription in a Family B transfer log.** §2.2 requires that a designated holder received nothing but distributions over the window, and the distinguishing signal - a distribution lands on many holders in one block, a subscription on one - has not been specified or tested here. It does not block anything: Family B is quoted in v1.0.0 regardless, and the recorder is already accumulating the balance series that any future test will need. It is named here so nobody implements a guess and calls it verified.

---

11. Corrections

Every correction to an observation or a published figure is recorded here.

• 2026-09-04: spiko.api.nav.eutbl dated six Saturday observations one

day ahead. Under Spiko's Known NAV method, Sunday's NAV is fixed on the previous day; USTBL and UKTBL use same-day Unknown NAV. The affected period was 2026-08-01 through 2026-09-04. The published EUTBL yield was about 2.3 bp too high, 2.109785 % instead of 2.087049 %. It was corrected with a failure revision; no observation was deleted.