Laminar FAQ

Laminar is a local-first tool for creating Zcash batch payment requests without holding keys or funds.

It fixes the Spreadsheet Gap: payouts are tracked in spreadsheets, but sending them one by one is slow and easy to get wrong.

Treasurers and operators managing payroll, grants, vendor payments, and recurring disbursements.

No. Laminar only builds payment requests. It never holds keys or funds.

The desktop app prepares and validates the batch (Brain). The mobile wallet signs and sends it (Muscle).

A 12-week build to prove the full end-to-end flow works with minimal features.

Core engine, dual-mode CLI, and desktop UI producing QR/UR handoffs and audit receipts.

Any wallet feature: key management, signing, broadcasting, custody, or recovery flows.

Yes. No required servers and no server-side state.

No. There is no telemetry, analytics, or external tracking.

No. It never stores, generates, requests, or transmits key material.

No. Only the wallet can sign.

No. Only the wallet can broadcast.

Laminar acts like a calculator: it prepares payment data but cannot approve or send funds.

Only optional draft batches and address-book metadata. No secret material is needed to use Laminar.

Sensitive local fields are encrypted on disk with AES-256-GCM.

Keys are derived with a memory-hard KDF, with Argon2id as the default target.

All amounts are handled as integer zatoshis. Floating-point math is not used.

Laminar sanitizes input on import to block formula injection and related spreadsheet attacks.

The whole batch is rejected. Partial execution is not allowed.

Yes. The same inputs and settings produce the same payload and receipt bytes.

Laminar validates network, address format, amount limits, memo encoding and size, required columns, and schema shape.

Yes. All three are validated and supported.

Yes. Each recipient can have a UTF-8 memo up to 512 bytes. Invalid or oversized memos are rejected.

Any network mismatch triggers rejection of the entire batch.

Yes. Duplicates can be intentional, so they are allowed but clearly flagged for review.

CSV for human workflows and JSON for programmatic integrations.

Required: address plus amount or amount_zatoshis. Optional: memo and label.

Laminar enforces recipient and payload limits. If a batch is too large, it is split into ordered segments.

Sensitive batch data is cleared as soon as practical, with minimal persistence in memory and on disk.

One CLI that switches between human-friendly and machine-friendly behavior.

Laminar checks whether stdout is a TTY at startup. You can override this with flags.

Safety and clarity: confirmations, readable summaries, and high-signal validation output.

Machine-friendly output: strict JSON, stable schema, and no interactive prompts.

No. In Agent Mode it does not wait on stdin; missing arguments return an immediate structured error.

Yes. Example: --output json.

With structured JSON error objects, stable error codes, and deterministic exit codes.

Through strict schema validation, sanitization, explicit size limits, and fail-closed processing.

A scripted end-to-end Agent Mode run that generates intents and receipts with no manual steps.

Automation needs safe financial building blocks. Laminar provides payout construction without custody.

Through an air gap: static QR or animated UR, plus deeplink or manual copy where supported.

Zodl (formerly Zashi) on iOS and Android.

YWallet is supported as a fallback for static QR and deeplink. If animated UR is unavailable, Laminar splits more often.

Payload size. Smaller payloads use static QR; larger payloads use animated UR.

Typically around 8 to 12 recipients, depending on memo lengths and payload overhead.

Often 50+ recipients per segment, depending on memo size and scan conditions.

Laminar splits the batch into ordered segments until all recipients are included.

Yes. The desktop UI provides pause and play controls for scan stability.

• M1: Iron Core (core engine + dual-mode CLI).
• M2: Interface (desktop UI + end-to-end workflows).
• M3: Release package (v1.0, field manual, integration guide, production proof).

Pass/fail requires clear proof of deterministic output, fail-fast validation, strict non-custodial boundaries, non-blocking dual-mode behavior, wallet compatibility tests, and a final end-to-end Genesis run.