The Zcash ecosystem is transitioning from a more centralized funding era to a multi-treasury ecosystem (Multiple Dev Funds, Independent Grants, DAOs). While this decentralization is healthy, it creates a specific operational bottleneck: Credible Administration under Privacy.
The challenge isn’t sending the funds, it’s evidencing the allocation without turning the shielded pool into a glass box. Without a consistent, neutral way to evidence payments, administrative friction increases and trust erodes.
The Proposal: Laminar (Tactical Spike)
Laminar is a local-first, stateless operational console designed to help treasuries prepare and evidence payments, without ever taking custody.
It functions as a transaction preparation and evidencing layer:
Ingest: Takes CSV/JSON payout data.
Construct: Validates recipients and builds multi-recipient intents. Note: Laminar can be run fully offline for intent construction.
Export: Outputs ZIP-321 Payment Request URIs (QR/Link) for signing by any external wallet that supports the standard.
Evidence: Generates machine-verifiable Receipt Bundles for internal accounting and audit workflows. Each Receipt Bundle includes a hash-linked intent manifest and a deterministic JSON schema that can be verified by a simple laminar verify command. The JSON schema will be published and versioned so third parties can verify bundles without running Laminar. This command checks bundle integrity and linkage; it does not reveal shielded recipients or amounts without explicit disclosure. Receipt Bundles are designed to be shareable with third parties for integrity/traceability without revealing shielded details unless the disclosure mode is explicitly invoked. Default mode is privacy-preserving integrity, not disclosure.
Laminar assumes the signing wallet is the broadcast boundary; Laminar never contacts the network unless explicitly invoked for non-sensitive verification (e.g., confirming that a provided txid exists / was mined, without attempting to infer recipients or amounts).
Core Philosophy: “Pure Software”
To ensure jurisdiction-portable operation and global availability, Laminar is architected as standalone software, not a service:
Stateless: Laminar stores no keys and maintains no remote state (no backend); it produces portable artifacts (URIs + Receipt Bundles) and can run fully offline for intent construction.
Air-Gapped: Constructs ZIP-321 payment requests for QR/link handoff to an offline signing environment (separate machine or offline wallet instance).
Crucial Distinction: What Laminar is NOT
To prevent category errors, we must define the boundaries:
NOT a Wallet: Laminar holds no keys. It cannot sign. It cannot spend.
NOT a Custodian: It never holds funds. It is strictly a local calculation tool.
NOT Surveillance: It does not analyze the chain, correlate addresses, cluster identities, or infer transaction graphs.
NOT “Grant Policing”: It is a tool for treasurers to prove their own integrity, not a weapon to attack others.
Technical Definition: Evidence of Execution (Receipt Bundles)
We are avoiding the ambiguity of “universal proofs” in favor of pragmatic Receipt Bundles. In the Tactical Spike, the Receipt Bundle is defined as a flexible artifact supporting three modes:
Mode A (Integrity): Canonical intent manifest (hashed) + transaction reference (txid or wallet-provided confirmation identifier). This links “The Plan” to “The Execution” within the bundle.
Mode B (Selective Disclosure): Support for selective disclosure artifacts where explicit, documented consent is given by the relevant parties (treasury + auditor/recipient as applicable).
Mode C (Future Standard): Architecture ready for emerging disclosure standards (e.g., ZIP-311 Draft) as wallet support matures.
Execution: The $50k Tactical Spike
We are proposing a focused engineering sprint to build the “Engine” before the “Interface.”
Scope:
The Validator (Rust): A library utilizing Zcash reference crates (e.g., librustzcash) to validate Unified Addresses (ZIP-316) and structure transaction intent.
The CLI Builder: A command-line pipeline that converts payroll.csv → ZIP-321 URI.
The Receipt Bundler: A module that generates a hash-linked PDF/JSON report containing the intent manifest and transaction references.
Non-Goals for the Spike:
GUI (Graphical User Interface)
Transaction Broadcasting (handled by the external wallet)
Direct Wallet Integration (handled via ZIP-321 handoff)
Chain Analytics
Request for Comment
I am finalizing the ZCG proposal for this spike. I invite feedback on the following:
Q1 (Treasurers & Grant Recipients):
Do you currently have a need for stronger evidence/receipts for your shielded treasury payouts?
Artifacts: What is your minimum acceptable artifact (PDF, JSON, signed receipt, disclosure payload)?
Requirements: Specifically, what do you need to prove: recipient list, amounts, timing, internal approvals, or just bundle integrity?
Context: What is your typical payout volume (recipients per batch) and frequency?
Q2 (Power Users): Is a csv → ZIP-321 CLI sufficient for an MVP, or does the ecosystem require a full GUI from Day 1 to be useful?
A quick update on Laminar’s progress since posting this RFC last week.
We have been refining the architecture for the local-first operational console, specifically looking at how we optimize high-volume private transaction throughput.
Next Step: We are finalizing the grant proposal for ZCG. We are targeting a $50k tactical spike to build the initial Proof of Concept.
Before we formally submit the grant, I’d like to get the community’s eyes on the scope. For the developers and ZCG members here: Do you see any immediate red flags regarding the integration with existing light client infrastructure, or any friction points in the proposed UX for high-volume merchants? > Any technical friction we can identify now will only make the PoC stronger.
That is a fair question, dismad. To solve the “Spreadsheet Gap,” we have to handle the messy reality of human-entered data while maintaining the absolute precision required by librustzcash.
The goal is to move from Intent (a row in a spreadsheet) to Fact (a validated transaction output). Here is how we are handling the ingestion:
1. Simple Input Examples
We are prioritizing a “flexible ingestion, strict enforcement” model.
CSV Example (payroll_january.csv)
address,amount,memo
u1z...abc,10.5,Core Engineering Grant
u1y...xyz,2.25,Design Sprint - Q1
Normalization in Laminar happens in three distinct stages before it ever touches the construction engine:
Header Mapping: We utilize fuzzy matching to normalize common organizational headers. Whether your CSV says to, destination, addr, or recipient, it maps to a single internal address field.
Arithmetic Hardening: To avoid floating-point errors (the bane of financial software), all amount strings are immediately converted to integer zatoshis. The internal calculation follows: Batch Total = Σ (amount_i × 10^8).
Address Verification: We don’t just check for strings; we run every address through a local instance of zcash_address to verify the checksum and network type (Mainnet vs. Testnet). If a single row fails, the entire batch is locked to prevent partial execution.
Memo Constraints: We validate that memos fit within the 512-byte shielded limit. If an entry is too long, the UI forces a truncation or a rewrite rather than allowing a failed transaction construction later.
3. The Validated “Fact” Object
Once sanitized, the input is transformed into a strictly typed internal schema that serves as the blueprint for the ZIP-321 Construction Engine.
This ensures that by the time the user sees the “Confirm” button, the data is already consensus-compatible.
Thanks for your clarity! I think your idea would be useful now that I better see what you are trying to do. If you decide to demo a MVP and would love to play with it!
You’re spot on, playing with a live binary is when the utility really becomes undeniable. Here is how we’re planning to roll that out:
Milestone 1 (The Iron Core): We’ll be focused on the CLI logic first to ensure the plumbing (Rust/librustzcash) is bulletproof.
Milestone 2 (The Alpha Demo): This is where the desktop interface comes alive. We’ll be releasing an Alpha version specifically for community testing.
I’ll definitely keep you in the loop as we get closer to that Milestone 2 release. Having experienced eyes like yours stress-testing the ingestion logic and the “Calculator Defense” architecture is exactly what we need to turn this from a “useful idea” into an industrial standard.
While the RFC has been quiet, the forge has been active.
We believe that high-assurance infrastructure cannot be debated in the abstract. It must be proven in the compiler. To validate our architecture before submitting the final Phase 1 Grant Proposal, we have deployed the Laminar Tracer Bullet (v0.0.1-alpha) to the public repository.
This is not a mockup. This is a vertical slice of the engineering stack, designed to prove our most critical invariants before we commit to the full build.
What has been proven:
The “Zatoshi Standard” (INV-04): We have enforced strict u64 integer arithmetic at the parser level. Floating point math is chemically prohibited in the codebase.
Fail-Fast Safety (INV-10): Atomic batch validation. If one row in a 1,000-recipient CSV is malformed, the entire batch rejects. No partial states.
Dual-Mode Architecture (INV-06): The single laminar-cli binary successfully detects its environment (TTY vs Pipe) and adapts its output automatically—serving Human Treasurers (spinners/tables) and AI Agents (strict JSON) simultaneously.
Request for Review: We invite the engineering community to review laminar-core/src/parser.rs.
If you find a way to inject floating-point drift into our Zatoshi implementation, report it.
Next Steps: We are finalizing the ZCG Grant Proposal for the “Tactical Spike” (Phase 1) submission this week.