Skip to main content

Frozen v1 hash vectors

generation/runtime-overrides/eod-risk-bundles/tests/fixtures/golden-v1/ is a portable synthetic package containing two fixed examples, their original CSV inputs, manifests, exact hash preimages and expected.json. It was frozen before adding bundle v2. The exchange case has non-ASCII and non-BMP characters in its synthetic epoch to expose JSON escaping differences across languages.

Run the standalone verifier (Python standard library; no TraderX imports):

python3 specs/YU18-risk-integration/generation/runtime-overrides/eod-risk-bundles/verify_golden.py

Do not run with Python optimization enabled: the verifier refuses -O. CI also compares the production manifest/workload implementation with the fixed expected values and verifies that changing a CSV makes the independent checker fail. No expected value is regenerated by verification.

The files and hash scopes are:

  • positionsSha256/contractsSha256: original CSV bytes, including comments, formatting and newline.
  • bundleId: canonical manifest object excluding bundleId; exact bytes are bundle-preimage.json.
  • manifestFileSha256: full manifest file including bundleId. This is not the bundleId.
  • workloads.local: canonical {bundleId,profile} using adapter transport-mock-v1.
  • workloads.http: same shape using adapter http-transport-mock-draft-1. The full fixed profiles and exact byte scopes are in the two workload-preimage.json files.

The canonical encoding is JSON with keys sorted, two-space indentation, separators comma followed by newline/indent and colon followed by one space, ASCII escapes (including UTF-16 surrogate pairs for non-BMP string characters), finite values, UTF-8, and one trailing LF. Arrays retain order. Booleans use JSON lowercase. Cut sequence/version values remain strings, never float conversions. The manifest has no floating-point numeric fields; CSV decimals remain inside hashed byte files. Object keys in this contract are ASCII. A compact JSON encoder produces a different identity.

Alex can implement his encoder, compare generated bytes to these preimages, and then compare hashes. Existing fixture hashes must not be changed to accommodate a new encoder. Real pricing profiles are not defined by these mock profiles and need their own agreed versioned vectors.

See the v3 compatibility follow-up for scoped checkout attributes, CRLF diagnostics, the additive terms-v2 accrual basis and the invalid missing-accrual fixture. Existing examples and v1 hashes remain unchanged.