Video you can put in a receipt.
Every frame, the same bytes everywhere.
The learned-video family (DCVC) propagates a float reference feature frame to frame, so a
~1e-5 drift compounds down the clip — reproducible only on the same build, never receiptable.
wai.video.int_motion is the opposite: each frame is reconstructed by integer
block motion compensation from the previous frame plus an integer-quantized residual, the
whole decode the same pure-i64 Rust native sinks run, compiled to wasm32 — no float,
no ML runtime. So every frame is byte-identical on every machine, and the page
re-checks each one's hash against the native reference. That is frame-state-equivalence:
a per-frame portable hash, a whole clip you can put in a receipt.
Why this is the moat
The clip plays in your browser, and as it plays the page hashes each decoded frame and
checks it against the hash the native reference produced — all
— match, byte-for-byte. A learned float codec can't make that
promise: its frames drift between machines, so you can't pin them. This decode is integer all
the way down (motion compensation is array indexing, the residual is integer-quantized), so
the per-frame hash is portable. The keyframe can also be the learned int_hyper
codec (wai.video.int_hyper) — a learned keyframe + integer inter-frames, still
byte-exact. And it scales to real footage: real captured video moves a non-integer
number of pixels per frame, so the motion compensation predicts at the half-pixel grid
by integer bilinear interpolation ((a+b+1)>>1) — which shrinks the bitstream
(here ~32% under whole-pel) without a single float, so every frame still hashes the same
everywhere. Reference engine + conformance corpus in the open-standards repo, Apache-2.0.