What changed, and why it matters
This commit simply raises the maximum number of Zcash transactions that can be processed in one batch from 35 to 40 on a specific firmware variant. It updates a constant, the matching documentation, and a unit test. There is no indication in the commit that this fixes a security vulnerability.
No security action required. Treat as a normal functional/configuration change. If reviewing for operational risk, verify that the device has sufficient memory to handle 40 PCZTs within the unchanged 512 KiB total limit under worst-case PCZT sizes.
Security signals we found
No security-relevant keywords in commit title or message.
No bounds-checking, input-validation, or cryptographic code changes beyond updating the threshold value and its test.
No references to CVEs, vulnerabilities, researchers, or security advisories in the commit or supplied materials.
The total byte cap (512 KiB) is unchanged; only the allowed item count increases.
Evidence from the diff
The change increases ZCASH_BATCH_MAX_PCZTS from 35 to 40 in rust/rust_c/src/zcash/mod.rs, gated behind the ‘cypherpunk’ feature. The docs/protocols/ur_registrys/zcash.md file and a unit test that checks the upper-bound enforcement are updated accordingly. The 512 KiB total batch size limit remains unchanged, so the effective per-PCZT average budget is slightly reduced. No memory allocation, parsing, or cryptographic logic is modified.
Changed components
rust/rust_c/src/zcash/mod.rs (cypherpunk feature)docs/protocols/ur_registrys/zcash.mdInspect captured patch +3 / −3
diff --git a/docs/protocols/ur_registrys/zcash.md b/docs/protocols/ur_registrys/zcash.md
index 0812fea..eb2e821 100644
--- a/docs/protocols/ur_registrys/zcash.md
+++ b/docs/protocols/ur_registrys/zcash.md
@@ -63,7 +63,7 @@ carries the PCZT-owned response in its own opaque `data` field. It also reports
the signing firmware version once for the entire response.
Batch version 1 is supported by cypherpunk firmware and currently accepts up to
-35 PCZTs. The encoded batch data and request id together, and the canonical PCZT
+40 PCZTs. The encoded batch data and request id together, and the canonical PCZT
payloads after decoding, must each fit within 512 KiB. The operation is atomic.
If any PCZT is invalid or cannot be signed, Keystone returns an error instead of
a partial result. PCZT entries with identical canonical encodings are rejected.
diff --git a/rust/rust_c/src/zcash/mod.rs b/rust/rust_c/src/zcash/mod.rs
index 0e8ccc2..a1948b5 100644
--- a/rust/rust_c/src/zcash/mod.rs
+++ b/rust/rust_c/src/zcash/mod.rs
@@ -40,7 +40,7 @@ use zeroize::Zeroize;
// Cap both per-PCZT overhead and variable-size payload data to leave headroom
// in shared device memory while processing a batch.
#[cfg(feature = "cypherpunk")]
-const ZCASH_BATCH_MAX_PCZTS: usize = 35;
+const ZCASH_BATCH_MAX_PCZTS: usize = 40;
#[cfg(feature = "cypherpunk")]
const ZCASH_BATCH_MAX_TOTAL_BYTES: usize = 512 * 1024;
#[cfg(feature = "cypherpunk")]
@@ -1061,7 +1061,7 @@ mod tests {
overlong_small_count.push(0);
validate_zcash_batch_request_count(&overlong_small_count).unwrap();
- // The body declares 36 PCZTs but omits them. Reaching the count error
+ // The body declares 41 PCZTs but omits them. Reaching the count error
// proves the limit is enforced before the full request is parsed.
request[ZCASH_BATCH_REQUEST_HEADER_LEN] += 1;
let registry = ZcashSignBatch::new(vec![0xaa], request);
Why this scored 18/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.