Skip to content

Wrapped Verifier-Artifact Feasibility v1 (TKT-P3-54)

Status: design memo (direct-path rescue lane)
Scope: fixed confidential-transfer statement, verifier-facing cryptographic wrapping only

1) Question

If the specialized fixed-statement prover lands in the sub-10 KB but not-yet-small-enough region, can cryptographic wrapping of the verifier-facing artifact materially improve direct-path wallet viability without changing frozen protocol boundaries?

2) Files Inspected

  • spec/direct-path-minimum-private-relation-v1.md
  • spec/direct-path-proof-size-feasibility-v1.md
  • spec/specialized-fixed-statement-prover-design-v1.md
  • spec/confidential-transition-boundary-v1.md
  • spec/verifier-abi-host-kernel-v1.md
  • spec/budgets-phase3.md
  • packages/zk-boundary/src/proof_blob_v1.ts

3) Frozen Boundary Constraints (Applied Here)

Unchanged by this memo:

  • fixed confidential-transfer statement
  • host/prover split
  • PIv1 and PBv1 semantics
  • transcript/transport binding discipline
  • OFm2/v2 and tokenized continuation invariants
  • wallet behavior and no-public-receiver-marker rule
  • verifier ABI rule: public inputs + proof artifact only

This memo evaluates only cryptographic proof-of-proof style wrapping in the verifier-facing artifact lane.

4) Threshold Ladder (Do Not Conflate)

  • ideal wallet-direct target: ~1 KB-class proof-carrier / unlock path
  • outer BCH direct-path ceiling: 10,000 unlock bytes per input
  • staged/aggregated region: approaches that materially depend on >10 KB direct carriage assumptions

Additional frozen PBv1 pressure point:

  • PROOF section hard cap in current codec: 4096 bytes (MAX_PROOF_BYTES in packages/zk-boundary/src/proof_blob_v1.ts)

So any wrapped direct-path strategy must not only stay under 10 KB unlock bytes, but also fit PBv1 proof-section policy unless a future versioned boundary update is explicitly approved.

5) Boundary-Compatible Wrapped-Compression Strategy Classes

5.1 Same-statement recursive wrapper (inner specialized proof -> outer concise proof)

Compatible form:

  • keep public inputs unchanged (shardId32, stateIn32, stateOut32, outputFingerprint32)
  • inner proof remains prover-side object
  • outer proof attests inner-proof validity + public-anchor consistency
  • only outer proof bytes are verifier-facing payload

Compatibility: Yes, if verifier consumes only existing public inputs + proof artifact and no extra witness-derived channels.

5.2 Succinct validity wrapper over committed inner-proof digest

Compatible form:

  • prover commits to inner proof/transcript object
  • wrapper proves that committed object verifies fixed statement under frozen anchors
  • chain sees concise wrapper artifact and commitment tie-in

Compatibility: Yes, if commitment plumbing is internal to proof artifact and does not widen PIv1/ABI fields.

5.3 Multi-layer wrapper stacks (two or more nested wraps)

Compatible form:

  • technically possible while preserving ABI
  • each layer increases prover complexity and trust in tooling correctness

Compatibility: Conditionally, but only if final artifact shrinks enough to justify complexity and still fits PBv1/direct-path budgets.

6) What Is Already Implausible for This Ticket

The following do not qualify as useful direct-path wrapping here:

  1. Plain transport compression (gzip/packing/chunking) without cryptographic proof-size reduction.
  2. Any approach requiring new verifier-visible fields beyond frozen public inputs.
  3. Any approach using hidden witness side channels (witness hash aliases, sidecar digests widening ABI).
  4. Any approach that only helps when split across staged/multi-transaction carriage.
  5. Any wrapper where final verifier-facing artifact still exceeds PBv1 proof cap or effectively pushes direct path into staged territory.

7) What Artifact Improvement Range Would Actually Matter

To be worth pursuing in the direct-path lane, wrapped output should satisfy both relative and absolute gains:

High-value range (strongly worth it)

  • final verifier-facing proof artifact at or below ~1–2 KB
  • and at least ~50% reduction versus non-wrapped specialized baseline

This range materially improves wallet-direct ergonomics and leaves safety margin under direct-path ceilings.

Conditional range (maybe worth it)

  • final artifact around ~2–4 KB
  • with clear verifier-cost stability and deterministic build/testing

This may still be viable direct path, but is less aligned with the ~1 KB-class discipline.

Low-value / disqualifying range

  • final artifact remains >4 KB, or reduction is too small to change practical wallet-direct posture
  • or wrapper introduces major verifier/op/script burden that erodes byte gains

In this range, wrapping is unlikely to rescue direct-path usability enough to justify complexity.

8) Disqualifiers for Wrapping as Direct-Path Rescue

Wrapping should be deprioritized for direct path if any of these hold:

  1. Cannot fit within PBv1 proof cap (4096) and practical unlock budget simultaneously.
  2. Requires widened verifier ABI or additional public input fields.
  3. Requires verifier-side access to hidden witness-derived material.
  4. Produces marginal byte reduction but significantly increases verifier arithmetic/hash burden.
  5. Becomes operationally dependent on staged carriage assumptions to be usable.

9) Honest Judgment

Judgment: conditionally useful.

Why:

  • Wrapping is boundary-compatible in principle and can plausibly help if specialized baseline lands above ideal target.
  • It is not automatically useful; value depends on whether final wrapped artifact lands in the ~1–2 KB to ~2–4 KB ranges with acceptable verifier overhead.
  • Without concrete wrapped measurements on the specialized fixed-statement baseline, treating wrapping as guaranteed rescue would be premature.

10) Recommendation for Direct-Path Lane

Proceed as follows:

  1. Build/measure specialized fixed-statement baseline artifact first.
  2. Gate wrapping decision on measured gap to ~1 KB-class target and PBv1 cap headroom.
  3. Only pursue wrapper implementation if projected wrapped artifact enters high-value or at least conditional-value range without ABI drift.

This keeps direct path primary and avoids prematurely moving into staged fallback assumptions.

11) Acceptance Mapping (TKT-P3-54)

  • Distinguishes transport compression vs cryptographic wrapping: Yes
  • Preserves verifier semantics and frozen boundary: Yes
  • Final recommendation explicit: Yes (conditionally useful)
  • No protocol-boundary widening proposed: Yes