Lesson 03 · 5 min

Resets: the Heartbeat

Every quarter the floating leg fixes, and a Reset lands in resetHistory. State accretes; nothing is overwritten.

The morning the rate lands

2026-07-17, the start of the swap's second calculation period. SOFR prints at 3.62%, and the swap's floating leg finally learns what it pays this quarter. Here is the question this lesson answers: where does that number go? Not into the trade. The trade says how to fix (rateOption: USD-SOFR, reset at each period start) and never changes. The number itself lands in resetHistory, as a Reset record on the state. The spec stays put; the log grows.

USD-SOFR observed: 0.0362beforetrade: the swapresetHistory:[0] 0.0341 · Apr 17resetresetDate: 2026-07-17aftertrade: unchangedresetHistory:[0] 0.0341 · Apr 17[1] 0.0362 · Jul 17 the new entryQualify_Reset: one after state, same trade, resetHistory one longer
Key ideas
  • A Reset is a record, not an edit

    Reset carries the resetValue (a Price, required), the resetDate, and the observations that justify it, at least one. A fixing without evidence does not validate.

  • Observations are the evidence

    An Observation pairs an observedValue with an observationIdentifier: what was read, from which source, for which date. Resets point at observations, so every number in the logbook traces to a print.

  • The instruction names the leg

    ResetInstruction is small: which payout is fixing, on which resetDate. The machinery for computing the value was already on the trade; the event just records the outcome.

  • History accretes on the state

    Before the event, resetHistory has n entries. After, n + 1, and the trade inside is byte for byte the same. That is not a convention; it is literally what the qualifier checks.

The after state, on the wire

{} tradeState, after the July reset, trimmed
{  "trade": "… the swap, unchanged …",  "state": {    "positionState": "Formed"  },  "resetHistory": [    {      "resetValue": "… 0.0341, the April fixing …",      "resetDate": "2026-04-17"    },    {      "resetValue": {        "value": 0.0362,        "priceType": "InterestRate",        "unit": {          "currency": "USD"        },        "perUnitOf": {          "currency": "USD"        }      },      "resetDate": "2026-07-17",      "observations": [        "… the SOFR print behind the fixing …"      ]    }  ]}
Reset also has an averagingMethodology slot for legs that average instead of fixing once: the averaging commodity leg writes its monthly average into the same structure.

History lives on the state

Why is resetHistory on TradeState rather than on the payout? Because the payout is the specification: it describes how fixings work for the life of the deal. The state is the log: what actually happened so far. Keeping them apart is what lets the trade stay immutable while its history grows. Qualify_Reset enforces exactly this shape, checking three things: the event produced one after state, the trade in it equals the trade before, and resetHistory is exactly one entry longer. An event that edited anything else would simply fail to be a Reset.

Try itOpen Create_Reset in the Playground. It is the function that builds the after state: run it and watch a Reset get appended to a real TradeState.
◆ Checkpoint

01Where does a floating rate fixing live?

1 / 3