Cardano Updates

Co-authored-by: sg-doc-holiday[bot] <219201796+sg-doc-holiday[bot]@users.noreply.github.com>

Relax bounds number of participants

Signed-off-by: Chris Gianelloni <[email protected]>

[EC Api] - Weekly development report as of 2026-05-29

Signed-off-by: jeluard <[email protected]>

After running through all six chunking notes alongside the current
codebase, found one materially wrong number and a number of stale
tooling pointers / missing cross-links:

- parallel-chunking-results.md: regenerated the chunk_compare table
  at M=500k. The previous M=50k table had n=8 at 3.465s (~10% above
  the M=500k truth of 3.157s) because seed=42 happened to land on a
  high outlier for that row. Updated table, baseline, and takeaway
  values; added a footnote explaining why M=500k is now the default.

- TOC.md and parallel-chunking-low-p.md: the "~10× n=32 conditional
  reduction" claim came from the M=50k initial table (~10 conditional
  samples). The M=500k validation revises this to ~5× (8.9s → 1.69s).
  TOC now says ~5×; low-p note adds an inline correction pointer.

- parallel-chunking.md (foundations): replaced manual q^(1/n)
  recipe and stale "10000+ MC runs" advice with concrete pointers
  to tools/chunk_compare.py, tools/plot_chunking.py, and
  tools/chunking_stability.py. Expanded caveats to three (added
  low-p marginal-degeneracy).

- parallel-chunking-mc-confidence.md: the "Or reframe the metric"
  paragraph was a suggestion when written; it's now implemented as
  --conditional. Rewrote to point at the implementation and the
  low-p note.

- parallel-chunking-cdf-staircase.md, parallel-chunking-n2-puzzle.md,
  parallel-chunking-results.md: added the missing cross-links to
  the later companion notes that were written after them.

Co-Authored with Claude.

Compares the on-chain builtin union path (unsafeDataAsValue + unionValue +
mkValue) against a hand-rolled sorted-merge over the raw BuiltinData
representation, so V3 guidance on union cost rests on concrete numbers
rather than estimates.

The new module Spec.Data.Value.UnionBudget adds 8 goldenBundle entries:
union_S1,3,8,100 in builtin and raw variants. Both bundle paths take two
BuiltinData-encoded Values, the same value on both sides, mirroring the
conservation-of-value pattern from production validators, produce the
merged BuiltinData, and report the CEK budget. The bundle does not chain
a lookupCoin or valueOf on the result so the measured cost is the union
itself, not a union-then-lookup composite.

The hand-rolled unionValuePositiveRaw is a Plinth translation of
Philip's pvalueUnionFast (Plutarch, slack thread 1776810760.659419).
Sorted-merge with a three-way branch on key comparison; assumes both
inputs sorted by lexicographic key and inner-pair values strictly
positive. Sorted-merge is O(L + R) per level; lookup-and-merge through
AssocMap.union would be O(L x R).

unionValuePositiveRaw is module-internal and not exported from
plutus-ledger-api. The positive-quantity precondition is documented at
the call site, not encoded in the type system. The unionValueNonZero
variant from the slack discussion is left for a follow-up commit; the
production case Philip cares about is tx outputs, which are strictly
positive.

Result matrix, raw vs builtin CPU ratio: S1 5.20x, S3 5.65x, S8 5.83x,
S100 4.47x. Byte-identical output between builtin and raw at every
shape; the raw column closes most of the gap that the typed unionWith
from plutus#7799 opens. Goldens regenerated under both GHC 9.6 and GHC
9.12 (per ghc-version-support cabal stanza). 24 goldens times 2 GHC
versions equals 48 files.

For IntersectMBO/plutus-private#2243.