receipt-ledger: tariff version 3 prices media jobs per operation and bills the work done #550

Merged

dcharlot merged 2 commits from wai/ledger-work-priced into main 2026-10-31 08:50:18 -04:00

Conversation 0 Commits 2 Files changed 13 +1415 -136

dcharlot commented 2026-10-30 12:23:42 -04:00

Owner

Copy link

What and why

WAI's receipt ledger billed media jobs in a way that fails the physics test twice
(waiTransport docs/decisions.md D3, D4):

1. One price per capability. Within wai.video.int_motion an encode (a motion search, then a
   codestream written) and a decode (a reconstruction) spend different energy for the same output
   units. A version-2 job price is (capability, unit, divisor, price), so it overprices one or
   underprices the other, and waiTransport could not bill decodes at its decode price at all.
2. "Billed once per chain" was keyed on the output. A job source contributes its output's
   int_motion decode receipt (kind 15), and §6.9 refused any record already billed. The codecs
   are deterministic, so a re-run of the same request gives the same output receipt and was refused
   record_rebilled, although the work was done again: a new hop, new energy, a new OER/2 receipt.

The version decision: tariff version 3

A job price gains op_len and operation after capability, which a version-2 reader cannot
read under its strict reading, so §4's own versioning rule makes this version 3: WLT1 and
WLI1 with version byte 3, the invoice laid out exactly as version 2's. Version 2 is untouched.
Its tariff's buyer signed version 2's rules, so it reads, verifies and bills exactly as before,
outputs included. Every existing vector keeps its outcome. The one exception is the
invoice_version control, which now uses version 4 because 3 is defined.

The rules (receipt-ledger §4.6, §5.2, §5.3, §6.3, §6.5, §6.9, §7.2, §7.3, §12)

• Per operation (§4.6). A job is priced by its serving capability and its route record's
  operation, in strictly ascending order of (capability, operation, unit). A version-3 tariff
  with no price for a job's (capability, operation) bills it nothing, as an unpriced capability
  bills nothing today.
• Work, not identity (§6.9). Under version 3 a chain bills a job's work once: its route
  record (16) and its hops' OER/2 receipts (14). The output receipt (15) is cited, and carried in
  the citation digest, but is not once-only. So:
  • a re-run whose route record and hop receipt are new is billed;
  • a replayed hop receipt or route record is refused (record_rebilled across the chain,
    record_duplicate within an invoice);
  • two lines of one invoice may cite one output receipt only under different hop receipts.
• Re-runs of one job id (§5.3). Version 2 refused two route records of one router for one job
  in one invoice (record_overlap). Version 3 does not: they are two runs, each billed from its
  own hop, and no hop twice. Without this, "the same request run again" would be refused or billed
  depending only on where the seller cut the invoice periods. The rule never held across invoices
  and was defeated by a new job id, so it guarded nothing the once-only hop receipt does not.
• Packages (§6.9) keep their rule in every version: a package is billed as a delivered product,
  once per receipt, which is a separate rule.
• Recompute caveat (§6.5), stated in the text. In a version-3 job line where two jobs delivered
  one output receipt, that receipt is cited once and its subpixels are counted for each job. The
  line's cited records name each job and that output once. How many of the jobs delivered it is
  stated by the jobs' sources (each pairs its job with its outputs), not by the cited records
  alone.
• Fixed in passing. A job price whose capability (or operation) is not UTF-8 is
  tariff_invalid, as §4.3 reads it. The reference said malformed, unlike the text and the
  Python. No vector held one.

Both implementations, the corpus and CI

• wai-rs receipt_ledger: VERSION_3, prices_jobs, JobPrice::operation,
  JobFacts::operation, billed_once(version, kind), and check_across(version, …). The breaking
  API changes are named in the CHANGELOG.
• receipt_ledger_verify.py: reads version 3 and applies its rules. It adds five mutated copies
  (the decode priced as the encode, the decode line named an encode, the shared output's subpixels
  billed once, the re-run without its previous invoice, the re-run swapped for a hop replay). It
  also drops two more of its own checks (operation, output-once), and the corpus must catch
  each.
• wai/wai-ledger: applies the chain rule of the tariff's version. A new test issues the
  version-3 chain byte for byte, bills the re-run and refuses the replayed hop.
• Corpus: nine vectors, listed below. The version-3 jobs are routed by the route corpus's router
  under its seeds through a pub(crate) helper. routes/vectors.json is unchanged.
• CI: the existing ledger step of wai-conformance.yml runs the new vectors and test, and its
  comment says so. wai-ledger.yml's comment names the new service test. wfsteps.py: 0 problems.

Vectors (live-conformance/ledger/vectors.json)

The corpus goes from 60 vectors to 69. Of the 60, 59 keep their bytes and outcomes. The one
exception is invoice_version, which moves from version 3 to 4. The 30 sources are unchanged,
and 4 are added.

vector	outcome
jobs_priced_per_operation	accept. int_motion encode at 500,000 per job and 20,000 per 10⁶ subpixels, decode at 250,000 and 10,000, and the av1 failover at its encode price.
a_rerun_billed	accept. The next invoice of the chain bills job-0001 run again: a new route record and hop receipt, and the output receipt the first invoice already lists.
one_output_under_two_hops	accept. job-0001 and its re-run in one invoice: the output is cited once ([14,14,15,16,16]) and its subpixels are billed twice.
an_operation_the_tariff_does_not_price	accept. A tariff that prices only the encode: the decode bills nothing, and its hop's energy is still stated.
a_hop_receipt_replayed	refuse record_rebilled at ["source",0]: a new route record replaying job-0001's billed hop receipt.
one_hop_under_two_lines	refuse record_duplicate at ["source",1]: a job whose av1 fallback hop claims the int_motion encode job's hop receipt.
job_prices_unordered_by_operation	refuse tariff_invalid at ["tariff"]
version_2_invoice_under_a_version_3_tariff	refuse tariff_mismatch at ["invoice"]
version_2_bills_an_output_once	refuse record_rebilled at ["source",0]: the same re-run under a version-2 chain.

All the version-2 vectors are untouched, among them output_claimed_by_two_jobs (record_duplicate)
and job_routed_twice (record_overlap).

Tests (all green)

Framework host (192.168.4.47, rb, CARGO_BUILD_JOBS=8, features opportunity_report):

• --lib receipt_ledger:: route_record:: revenue_share::: 21 passed. The new unit tests cover the
  version-3 tariff reading back with every altered byte refused, ordering by operation, the
  operation's form at 128 and 129 bytes, non-UTF-8, billed_once, and a version-3 invoice.
• --test receipt_ledger: 5 passed, including the new
  version_3_prices_each_operation_and_bills_the_work (488 s in debug).
• --test route_record: 6. --test revenue_share: 7. --test opportunity_report: 6. Their
  corpora regenerate byte for byte.
• wai_receipt_ledger_vectors verify: the corpus regenerates byte for byte, and every vector gets
  its stated outcome.
• cargo check --features route_record alone: the ledger helpers are gated off cleanly.
• wai/wai-ledger: cargo test --locked, 4 passed (the new
  a_rerun_is_billed_and_a_replayed_hop_is_not among them), and cargo clippy --locked --all-targets -- -D warnings is clean.
• clippy over wai-rs with those features: no finding in any file this change touches.

Studio (100.100.141.123, Python 3.15.2 with cryptography):

• receipt_ledger_verify.py: 69/69 vectors, every reason of §10, 82 mutated copies fail, 25
  dropped checks caught.
• revenue_share_verify.py, opportunity_report_verify.py and route_record_verify.py all pass.

The Framework's Python has no cryptography, so its OER/2 verifier refuses every hop receipt
there, including the unchanged route corpus's. The Studio run is the Python result.

Repo text checks (check-spec-refs, check-wai-section-refs, vanity metrics, comparative prose,
tests-in-CI) pass. wfsteps.py HEAD origin/main reports 0 problems.

Falsifications (each rule broken in the source, the corpus fails, then restored)

Rust ran on the Framework (wai_receipt_ledger_vectors verify, profile falsify). Python ran on
the Studio (receipt_ledger_verify.check). Each mutation was checked to have applied exactly once,
was restored with git checkout, and the restored tree passes again.

#	rule broken	vectors that fail
R1	the version-3 price match ignores the operation	jobs_priced_per_operation, a_rerun_billed, one_output_under_two_hops, an_operation_the_tariff_does_not_price (citation and invoice mismatches)
R2	an output receipt is billed once in version 3 too	a_rerun_billed (→ record_rebilled), one_output_under_two_hops (→ record_duplicate)
R3	version 2 is given version 3's output rule	version_2_bills_an_output_once (→ accept), output_claimed_by_two_jobs
R4	a hop receipt is not once-only in version 3	a_hop_receipt_replayed (→ accept), one_hop_under_two_lines (→ accept)
R5	two records of one job overlap in version 3	one_output_under_two_hops (→ record_overlap)
R6	job prices are ordered by (capability, unit), the operation left out	every version-3 vector (→ tariff_invalid)
P1–P4	the same four rules in receipt_ledger_verify.py (operation, output once, hop once, overlap)	the same vectors as R1, R2, R4, R5

receipt_ledger_verify.py's own sweep also drops each of its 25 checks (operation and
output-once among them), and the corpus catches every one.

wai breaking

Run on the Framework against 4902e6679, the current main and this branch's base. It reports 4
breaking changes, all acknowledged in the CHANGELOG, and exits 0:
record:corpus:wai/live-conformance/ledger/vectors.json,
api:rust:wai::receipt_ledger::JobPrice::operation,
api:rust:wai::receipt_ledger::JobFacts::operation and
api:rust:wai::receipt_ledger::check_across. It lists VERSION_3, billed_once and
prices_jobs as compatible additions.

Found and not changed (also fail the physics test)

These are raised, not changed:

1. Package jobs. A routed package.build job stays a package source (§4.5), billed once per
   package receipt. That receipt states no time, so a deterministic re-package with a model-based
   (or unmetered) figure gives the same receipt_hash and is refused, although the work was done
   again. A measured re-package gets a new hash only because its joules differ, so whether a
   re-package bills depends on meter noise. That is the same output-keyed failure. The fix in kind
   would bill a package job as a job source (route record and hop receipt once, the package receipt
   as evidence). The package receipt also carries work_units, which no tariff prices.
2. Stored bytes are billed once, with no time. package prices stored bytes per 10⁹, once per
   receipt. Storage cost accrues per byte-time, so one charge per receipt does not track it.
3. The router's price book has no operation (route-record §3.2, §4.2). Its estimates, its
   max_price and spend_ceiling limits, and its price ranking cost an encode and a decode alike,
   so a router can choose by a price the ledger will not bill.
4. Failed hops' energy is in no row. Scope 5 states only the billed hop's figure. A failed hop
   (or one past the deadline) spent real energy that the invoice's energy statement leaves out.
   Billing it nothing is right; stating no energy for it undercounts what the jobs cost.
5. Room units are time, not bytes. Subscriber seconds per layer class approximate bitrate, but
   waiTransport D7's argument (delivery cost scales with bytes) applies.
6. The recompute caveat above (§6.5). Binding a hop's OER/2 subject.output to its output (the
   codestream hash the decode receipt states) would let the cited records alone pair each job with
   its output. That needs a route-record or OER binding rule.

🤖 Generated with Claude Code

## What and why WAI's receipt ledger billed media jobs in a way that fails the physics test twice (waiTransport `docs/decisions.md` D3, D4): 1. **One price per capability.** Within `wai.video.int_motion` an encode (a motion search, then a codestream written) and a decode (a reconstruction) spend different energy for the same output units. A version-2 job price is `(capability, unit, divisor, price)`, so it overprices one or underprices the other, and waiTransport could not bill decodes at its decode price at all. 2. **"Billed once per chain" was keyed on the output.** A job source contributes its output's `int_motion` decode receipt (kind 15), and §6.9 refused any record already billed. The codecs are deterministic, so a re-run of the same request gives the same output receipt and was refused `record_rebilled`, although the work was done again: a new hop, new energy, a new OER/2 receipt. ## The version decision: tariff version 3 A job price gains `op_len` and `operation` after `capability`, which a version-2 reader cannot read under its strict reading, so §4's own versioning rule makes this **version 3**: `WLT1` and `WLI1` with version byte 3, the invoice laid out exactly as version 2's. Version 2 is untouched. Its tariff's buyer signed version 2's rules, so it reads, verifies and bills exactly as before, outputs included. Every existing vector keeps its outcome. The one exception is the `invoice_version` control, which now uses version 4 because 3 is defined. ## The rules (receipt-ledger §4.6, §5.2, §5.3, §6.3, §6.5, §6.9, §7.2, §7.3, §12) - **Per operation (§4.6).** A job is priced by its serving capability **and** its route record's `operation`, in strictly ascending order of (capability, operation, unit). A version-3 tariff with no price for a job's (capability, operation) bills it nothing, as an unpriced capability bills nothing today. - **Work, not identity (§6.9).** Under version 3 a chain bills a job's work once: its route record (16) and its hops' OER/2 receipts (14). The output receipt (15) is cited, and carried in the citation digest, but is not once-only. So: - a re-run whose route record and hop receipt are new is billed; - a replayed hop receipt or route record is refused (`record_rebilled` across the chain, `record_duplicate` within an invoice); - two lines of one invoice may cite one output receipt only under different hop receipts. - **Re-runs of one job id (§5.3).** Version 2 refused two route records of one router for one job in one invoice (`record_overlap`). Version 3 does not: they are two runs, each billed from its own hop, and no hop twice. Without this, "the same request run again" would be refused or billed depending only on where the seller cut the invoice periods. The rule never held across invoices and was defeated by a new job id, so it guarded nothing the once-only hop receipt does not. - **Packages (§6.9)** keep their rule in every version: a package is billed as a delivered product, once per receipt, which is a separate rule. - **Recompute caveat (§6.5), stated in the text.** In a version-3 job line where two jobs delivered one output receipt, that receipt is cited once and its subpixels are counted for each job. The line's cited records name each job and that output once. How many of the jobs delivered it is stated by the jobs' sources (each pairs its job with its outputs), not by the cited records alone. - **Fixed in passing.** A job price whose capability (or operation) is not UTF-8 is `tariff_invalid`, as §4.3 reads it. The reference said `malformed`, unlike the text and the Python. No vector held one. ## Both implementations, the corpus and CI - `wai-rs` `receipt_ledger`: `VERSION_3`, `prices_jobs`, `JobPrice::operation`, `JobFacts::operation`, `billed_once(version, kind)`, and `check_across(version, …)`. The breaking API changes are named in the CHANGELOG. - `receipt_ledger_verify.py`: reads version 3 and applies its rules. It adds five mutated copies (the decode priced as the encode, the decode line named an encode, the shared output's subpixels billed once, the re-run without its previous invoice, the re-run swapped for a hop replay). It also drops two more of its own checks (`operation`, `output-once`), and the corpus must catch each. - `wai/wai-ledger`: applies the chain rule of the tariff's version. A new test issues the version-3 chain byte for byte, bills the re-run and refuses the replayed hop. - Corpus: nine vectors, listed below. The version-3 jobs are routed by the route corpus's router under its seeds through a `pub(crate)` helper. `routes/vectors.json` is unchanged. - CI: the existing ledger step of `wai-conformance.yml` runs the new vectors and test, and its comment says so. `wai-ledger.yml`'s comment names the new service test. `wfsteps.py`: 0 problems. ## Vectors (`live-conformance/ledger/vectors.json`) The corpus goes from 60 vectors to 69. Of the 60, 59 keep their bytes and outcomes. The one exception is `invoice_version`, which moves from version 3 to 4. The 30 sources are unchanged, and 4 are added. | vector | outcome | |---|---| | `jobs_priced_per_operation` | accept. `int_motion` encode at 500,000 per job and 20,000 per 10⁶ subpixels, decode at 250,000 and 10,000, and the av1 failover at its encode price. | | `a_rerun_billed` | accept. The next invoice of the chain bills job-0001 run again: a new route record and hop receipt, and the output receipt the first invoice already lists. | | `one_output_under_two_hops` | accept. job-0001 and its re-run in one invoice: the output is cited once (`[14,14,15,16,16]`) and its subpixels are billed twice. | | `an_operation_the_tariff_does_not_price` | accept. A tariff that prices only the encode: the decode bills nothing, and its hop's energy is still stated. | | `a_hop_receipt_replayed` | refuse `record_rebilled` at `["source",0]`: a new route record replaying job-0001's billed hop receipt. | | `one_hop_under_two_lines` | refuse `record_duplicate` at `["source",1]`: a job whose av1 fallback hop claims the `int_motion` encode job's hop receipt. | | `job_prices_unordered_by_operation` | refuse `tariff_invalid` at `["tariff"]` | | `version_2_invoice_under_a_version_3_tariff` | refuse `tariff_mismatch` at `["invoice"]` | | `version_2_bills_an_output_once` | refuse `record_rebilled` at `["source",0]`: the same re-run under a version-2 chain. | All the version-2 vectors are untouched, among them `output_claimed_by_two_jobs` (`record_duplicate`) and `job_routed_twice` (`record_overlap`). ## Tests (all green) **Framework host (`192.168.4.47`, `rb`, `CARGO_BUILD_JOBS=8`, features `opportunity_report`):** - `--lib receipt_ledger:: route_record:: revenue_share::`: 21 passed. The new unit tests cover the version-3 tariff reading back with every altered byte refused, ordering by operation, the operation's form at 128 and 129 bytes, non-UTF-8, `billed_once`, and a version-3 invoice. - `--test receipt_ledger`: 5 passed, including the new `version_3_prices_each_operation_and_bills_the_work` (488 s in debug). - `--test route_record`: 6. `--test revenue_share`: 7. `--test opportunity_report`: 6. Their corpora regenerate byte for byte. - `wai_receipt_ledger_vectors verify`: the corpus regenerates byte for byte, and every vector gets its stated outcome. - `cargo check --features route_record` alone: the ledger helpers are gated off cleanly. - `wai/wai-ledger`: `cargo test --locked`, 4 passed (the new `a_rerun_is_billed_and_a_replayed_hop_is_not` among them), and `cargo clippy --locked --all-targets -- -D warnings` is clean. - clippy over `wai-rs` with those features: no finding in any file this change touches. **Studio (`100.100.141.123`, Python 3.15.2 with `cryptography`):** - `receipt_ledger_verify.py`: 69/69 vectors, every reason of §10, 82 mutated copies fail, 25 dropped checks caught. - `revenue_share_verify.py`, `opportunity_report_verify.py` and `route_record_verify.py` all pass. The Framework's Python has no `cryptography`, so its OER/2 verifier refuses every hop receipt there, including the unchanged route corpus's. The Studio run is the Python result. Repo text checks (`check-spec-refs`, `check-wai-section-refs`, vanity metrics, comparative prose, tests-in-CI) pass. `wfsteps.py HEAD origin/main` reports 0 problems. ## Falsifications (each rule broken in the source, the corpus fails, then restored) Rust ran on the Framework (`wai_receipt_ledger_vectors verify`, profile `falsify`). Python ran on the Studio (`receipt_ledger_verify.check`). Each mutation was checked to have applied exactly once, was restored with `git checkout`, and the restored tree passes again. | # | rule broken | vectors that fail | |---|---|---| | R1 | the version-3 price match ignores the operation | `jobs_priced_per_operation`, `a_rerun_billed`, `one_output_under_two_hops`, `an_operation_the_tariff_does_not_price` (citation and invoice mismatches) | | R2 | an output receipt is billed once in version 3 too | `a_rerun_billed` (→ `record_rebilled`), `one_output_under_two_hops` (→ `record_duplicate`) | | R3 | version 2 is given version 3's output rule | `version_2_bills_an_output_once` (→ accept), `output_claimed_by_two_jobs` | | R4 | a hop receipt is not once-only in version 3 | `a_hop_receipt_replayed` (→ accept), `one_hop_under_two_lines` (→ accept) | | R5 | two records of one job overlap in version 3 | `one_output_under_two_hops` (→ `record_overlap`) | | R6 | job prices are ordered by (capability, unit), the operation left out | every version-3 vector (→ `tariff_invalid`) | | P1–P4 | the same four rules in `receipt_ledger_verify.py` (operation, output once, hop once, overlap) | the same vectors as R1, R2, R4, R5 | `receipt_ledger_verify.py`'s own sweep also drops each of its 25 checks (`operation` and `output-once` among them), and the corpus catches every one. ## `wai breaking` Run on the Framework against 4902e6679, the current main and this branch's base. It reports 4 breaking changes, all acknowledged in the CHANGELOG, and exits 0: `record:corpus:wai/live-conformance/ledger/vectors.json`, `api:rust:wai::receipt_ledger::JobPrice::operation`, `api:rust:wai::receipt_ledger::JobFacts::operation` and `api:rust:wai::receipt_ledger::check_across`. It lists `VERSION_3`, `billed_once` and `prices_jobs` as compatible additions. ## Found and not changed (also fail the physics test) These are raised, not changed: 1. **Package jobs.** A routed `package.build` job stays a package source (§4.5), billed once per package receipt. That receipt states no time, so a deterministic re-package with a model-based (or unmetered) figure gives the same `receipt_hash` and is refused, although the work was done again. A measured re-package gets a new hash only because its joules differ, so whether a re-package bills depends on meter noise. That is the same output-keyed failure. The fix in kind would bill a package job as a job source (route record and hop receipt once, the package receipt as evidence). The package receipt also carries `work_units`, which no tariff prices. 2. **Stored bytes are billed once, with no time.** `package` prices stored bytes per 10⁹, once per receipt. Storage cost accrues per byte-time, so one charge per receipt does not track it. 3. **The router's price book has no operation** (route-record §3.2, §4.2). Its estimates, its `max_price` and `spend_ceiling` limits, and its price ranking cost an encode and a decode alike, so a router can choose by a price the ledger will not bill. 4. **Failed hops' energy is in no row.** Scope 5 states only the billed hop's figure. A failed hop (or one past the deadline) spent real energy that the invoice's energy statement leaves out. Billing it nothing is right; stating no energy for it undercounts what the jobs cost. 5. **Room units are time, not bytes.** Subscriber seconds per layer class approximate bitrate, but waiTransport D7's argument (delivery cost scales with bytes) applies. 6. **The recompute caveat above (§6.5).** Binding a hop's OER/2 `subject.output` to its output (the codestream hash the decode receipt states) would let the cited records alone pair each job with its output. That needs a route-record or OER binding rule. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-10-30 12:23:42 -04:00

receipt-ledger: tariff version 3 prices media jobs per operation and bills the work ... 8642b13940

A job price of version 2 is (capability, unit, divisor, price), so one
capability's encode (a motion search, then a codestream written) and decode
(a reconstruction) shared a price although they spend different energy for
the same output units. And a chain billed every record once, the output's
int_motion decode receipt among them: the codecs are deterministic, so a
re-run of a request (a new hop, new energy, a new OER/2 receipt) delivered
the same output receipt and was refused record_rebilled.

Version 3 (WLT1 and WLI1 with version byte 3) adds op_len and operation to
each job price, which a version-2 reader cannot read, and prices a job by its
serving capability and its route record's operation, in strictly ascending
order of (capability, operation, unit); an unpriced (capability, operation)
bills nothing. Under it a chain bills a job's work once (its route record and
its hops' OER/2 receipts); the output receipt is cited and carried in the
citation digest but is not once-only, so a re-run is billed and a replayed hop
receipt or route record is still refused (record_rebilled, record_duplicate).
Two route records of one job are two runs, no longer record_overlap. Version 2
reads, verifies and bills exactly as before; packages keep their rule. A job
price whose capability or operation is not text is tariff_invalid, as §4.3
reads it (the reference said malformed).

wai-rs, receipt_ledger_verify.py and the ledger service follow. The corpus adds
nine vectors (encode and decode at their own prices, a re-run billed, one
output under two hops, an unpriced operation, a replayed hop, one hop under
two lines, prices out of order by operation, a version-2 invoice under a
version-3 tariff, the re-run refused under version 2); its version-3 jobs are
routed under the route corpus's seeds, whose file is unchanged. The control
invoice_version now gives version 4.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot referenced this pull request 2026-10-31 02:52:54 -04:00

route-record: version 2 prices per operation, ranks by measured failure, binds a hop receipt to its output #552

dcharlot referenced this pull request from a commit 2026-10-31 04:00:36 -04:00

wai-conformance: the cargo-class corpora and the independent verifiers build without debuginfo

dcharlot referenced this pull request 2026-10-31 04:00:38 -04:00

wai-conformance: two arm64-heavy jobs build without debuginfo (the VM's disk filled mid-link) #553

dcharlot added 1 commit 2026-10-31 06:10:50 -04:00

Merge origin/main (#553: two arm64-heavy conformance jobs build without debuginfo) into wai/ledger-work-priced ... 4dc270aeb2

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot merged commit 7a78426b78 into main 2026-10-31 08:50:18 -04:00

dcharlot referenced this pull request from a commit 2026-10-31 08:50:20 -04:00

Merge pull request 'receipt-ledger: tariff version 3 prices media jobs per operation and bills the work done' (#550) from wai/ledger-work-priced into main

dcharlot referenced this pull request 2026-10-31 09:54:00 -04:00

wai-quantum: exact gradients, deterministic optimisers, VQE, QAOA and algorithm builders, each answer checked or bounded, on every surface #555

dcharlot referenced this pull request 2026-10-31 11:33:03 -04:00

wai-quantum: jobs placed on certified GPU members or split over several, byte for byte the CPU's; Clifford+T as sums of stabilizer states #557

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!550

No description provided.