Direct-Path Proof-Size Feasibility Memo v1 (TKT-P3-52)¶

Status: decision checkpoint (direct-path rescue lane)
Scope: fixed confidential-transfer statement only

1) Question This Memo Answers¶

After freezing the minimum irreducible private relation, is wallet-direct BCH confidential transfer still plausibly reachable without reopening the protocol boundary?

2) Files Inspected¶

spec/direct-path-minimum-private-relation-v1.md
spec/confidential-transition-boundary-v1.md
spec/verifier-abi-host-kernel-v1.md
spec/budgets-phase3.md
spec/verifier-family-feasibility-v1.md
docs/benchmarks/verifier-family-derisk-p3-43a.md
docs/benchmarks/verifier-stage-a-host-v1.md
packages/zk-boundary/src/proof_blob_v1.ts
packages/zk-backend-mock/src/mock_backend_v1.ts
packages/zk-backend-mock/src/real_backend_v1.ts
packages/zk-backend-mock/src/stark_rq_backend_v1.ts

3) Frozen Baseline Used (Minimized Private Relation)¶

This memo uses the frozen host/prover split from spec/direct-path-minimum-private-relation-v1.md.

Prover-side irreducible private facts:

note ownership
note inclusion
nullifier correctness
receiver note creation
sender change note creation
committed-value conservation
transition consistency against public anchors (stateIn32, stateOut32, outputFingerprint32)

Host-side forever facts (not part of the private relation):

PIv1/PBv1 canonical parsing and envelope checks
transcript/transport binding rules
OFm2/v2 recomputation from real outputs
tokenized continuation shell checks
malformed carrier/section reject logic

4) Threshold Ladder (Do Not Conflate)¶

4.0 Threshold Table (required handoff view)¶

Layer	Meaning	Current best repo-grounded value	Target/limit interpretation
Current repo direct-path envelope	Smallest currently measured wallet-like path in this repo (host + PB transport snapshot, not relation-bearing final prover)	unlock bytes: `1026`; PB bytes: `952`; proof bytes: `64` (`spec/budgets-phase3.md`, legacy host path row)	Indicates practical working discipline is around `~1 KB` class today
BCH direct-path outer ceiling	Hard per-input unlock envelope for direct wallet carriage	`10,000` unlock bytes/input	Absolute outer direct-path limit, not preferred design target
Staged/aggregated scale zone	Multi-transaction or service-assisted fallback space	`>10 KB` per-input direct requirements, up to broader transaction-scale regimes	Signals direct path is no longer the right architecture for that artifact size

4.1 Protocol Structural Floor (syntactic only)¶

From packages/zk-boundary/src/proof_blob_v1.ts:

PBv1 header: 16 bytes
one section entry: 40 bytes
required PROOF section exists; parser does not enforce positive minimum proof length

Structural lower bound for syntactic PBv1 acceptance:

56 bytes (16 + 40 + 0)

This is only parser/host structural acceptance, not cryptographic verification sufficiency.

4.2 Backend-Specific Minimum (implementation-dependent)¶

Current implemented backends:

backend 0 (mock_backend_v1): 64-byte proof
backend 1 (real_backend_v1, provisional bridge): 128-byte proof
backend 2 (stark_rq_backend_v1, placeholder scaffold): 128-byte proof

These are implementation minima in placeholder/provisional backends, not evidence of relation-bearing direct-path feasibility.

4.3 Practical Direct-Path Target (product viability)¶

Direct-path thresholds for this lane:

Ideal wallet-direct target: ~1 KB-class proof-carrier/unlock path
Acceptable outer direct-path ceiling: up to 10,000 unlock bytes per input (BCH direct-path hard envelope)
Clearly-too-large region for direct path: anything that requires operating above 10 KB per input, or that routinely pushes into transaction-scale (>10 KB to 100 KB+) proof carriage assumptions

The 100 KB transaction-scale envelope is fallback architecture territory (staged/chunked/aggregated), not wallet-direct success criteria.

5) Smallest Proving Task Actually Needed Now¶

Because host-side shell and transcript checks are frozen out of the private relation, the proving task is:

prove only the seven irreducible confidential relation facts listed above
bind those facts to frozen public anchors already validated by host (stateIn32, stateOut32, outputFingerprint32)
keep verifier semantics public-input-only + proof-artifact-only

This is materially narrower than proving full transaction-shell validity inside the prover.

6) Candidate Direct-Path Rescue Directions Evaluated¶

Direction A: Specialized fixed-statement prover (relation-specific)¶

Description:

implement a statement-specific prover/verifier pair only for the frozen fixed statement
encode only irreducible private relation constraints
keep host shell checks outside prover

Direct-path fit judgment:

Plausible and best first path for direct-path rescue
directly aligns with minimized private relation and fixed public anchor boundary

Direction B: Recursive/wrapped verifier-artifact compression (for same fixed statement)¶

Description:

keep same statement/boundary
use proof-of-proof wrapping to reduce verifier-facing artifact

Direct-path fit judgment:

Conditionally plausible
should be evaluated after specialized fixed-statement design baseline exists
cannot substitute for defining the core fixed-statement prover relation

Direction C: Generic zkVM-style or large transparent proofs as direct wallet artifact¶

Description:

rely on broad-purpose proving paths where proof artifacts are typically large

Direct-path fit judgment:

Already implausible for direct path under wallet-first thresholds
may still be useful as architecture/prototyping input, but not as direct-wallet artifact strategy

7) What Is Already Implausible for Direct Path¶

The following are not credible as direct-path success definitions:

treating parser-level structural minimums as cryptographic feasibility
treating placeholder backend proof sizes (64/128 bytes) as evidence of real relation-bearing viability
treating transaction-scale payload room as if it were direct-path wallet viability
treating staged/chunked carriage as equivalent to direct wallet-carried proof success

8) Unknowns Blocking Final Go/No-Go¶

Proof-size scaling for a real relation-bearing fixed-statement prover under the seven irreducible facts.
Constraint encoding cost for note inclusion and committed-value arithmetic under deterministic fixture discipline.
Artifact overhead after binding to frozen transcript/PBv1 carrier requirements.
Verification-side arithmetic/hash burden for a real (not placeholder) proof family path.
Whether a wrapped path can reduce artifact size enough to matter without widening ABI or violating frozen boundaries.

9) Compatibility Reconciliation Check¶

This feasibility framing remains compatible with:

transcript/proof-carrier discipline (PIv1/PBv1 unchanged)
transport binding rules (unchanged host responsibility)
canonical fixture/corpus reuse (no parallel fixture authority)
no disguised witness channels
outputFingerprint32 as public relation anchor only
visible BCH sats not representing confidential transfer amount semantics

10) Recommendation¶

Recommendation: Continue direct-path rescue with the next exact ticket:

TKT-P3-53 (#143) — design the specialized fixed-statement prover path optimized for small verifier-facing artifact size.

Reason:

the minimized private relation leaves a credible direct-path design space that has not yet been honestly measured by a real relation-bearing specialized prover path.
stopping now would be premature because current backend artifact sizes are placeholder/provisional and not relation-bearing evidence.

Escalation rule after TKT-P3-53:

if specialized design cannot produce a credible path toward ~1 KB-class artifact discipline (or at least defensible progress within the <=10 KB direct-path ceiling), prioritize fallback work via staged architecture tickets.

11) Acceptance Mapping (TKT-P3-52)¶

Memo grounded in frozen statement: Yes (Section 3 baseline).
BCH thresholds explicit and non-conflated: Yes (Section 4 ladder).
Candidate directions evaluated against same fixed boundary: Yes (Section 6).
Final recommendation explicit: Yes (Section 10).