[Grant Application] Veridex: Passkey Shielded Wallets & AI Agent Payments

Community Grants
1

Hi Zcash Community,

I’m Manny from the Veridex Protocol team. We specialize in cross-chain identity and payment infrastructure, specifically focusing on WebAuthn (Passkeys) and AI Agent authorization.

We have officially submitted our grant proposal to the Zcash Community Grants (ZCG) program and wanted to share our high-level architecture here to get your feedback and ensure we are aligning perfectly with the community’s technical vision.

**Link to GitHub Issue:** application-issue

### What We Are Building for Zcash

We currently have two production-ready open-source SDKs (`@veridex/sdk` and `@veridex/agentic-payments`) deployed across multiple chains. We are requesting a $45,000 grant to make Zcash a first-class citizen in this stack.

Our grant is split into two primary phases:

**Phase 1: Seedless, Passkey-Authenticated Shielded Wallets**

Seed phrases remain the biggest barrier to mainstream adoption. We will implement Zcash support into `@veridex/sdk`, allowing users to generate and manage shielded Zcash wallets purely through biometric Passkeys (FaceID/TouchID/Windows Hello).

**Phase 2: Privacy-Preserving AI Agent Payments**

We believe Zcash is the perfect currency for the emerging autonomous AI economy. We will integrate Zcash into `@veridex/agentic-payments`. This will allow a human user to authenticate with their Passkey and securely generate a constrained “session key” for their AI agent. The human can set strict parameters (e.g., “Spend max 1 ZEC per day”). The AI agent then uses this session key to autonomously negotiate API paywalls (e.g., HTTP 402) and execute shielded ZEC payments for data and compute without needing human intervention.

### Our Team & Security Focus

Our team consists of 3 core engineers, including Wasiu Ajao, a deep systems and cryptography engineer from Obscura Protocol, handling our Rust/WASM bindings. We have explicitly budgeted $10,000 out of our total $45,000 request for an independent third-party cryptographic audit of our WebAuthn-to-Zcash key derivation models, as we know security is paramount.

### We Would Love Your Feedback

As a community-driven initiative, we’d love your thoughts:

1. Translating WebAuthn (P-256) signatures to authorize Zcash shielded transactions: Are there specific libraries or cryptographic paths the community prefers we utilize under the hood? (We are currently surveying `librustzcash`).

2. Does the AI Agent economy use case resonate with the current Zcash priorities?

Looking forward to your feedback and excited about the prospect of bringing this to the Zcash ecosystem.

Best,

The Veridex Team

Zcash Community Grants Meeting Minutes 1/3/26
2

Manny, welcome to the Zcash ecosystem. It is great to see more builders focusing on the machine economy and agentic payments.

Regarding your first question on translating WebAuthn (P-256) to Zcash: this is the exact cryptographic friction that historically traps consumer-wallet architectures. Because Zcash relies on RedJubjub/Pallas, you cannot directly map a P-256 hardware enclave signature to a shielded spend. You will likely be forced to custody the Zcash spending keys in a software-layer wrapper that is merely unlocked by the Passkey, rather than natively signed by it.

This introduces a critical architectural divergence: Liability.

By generating autonomous ‘session keys’ for AI agents to execute transactions, the @veridex/agentic-payments SDK becomes a custodial hot-wallet surface. For consumer retail, this friction might be acceptable. But for enterprise treasuries and sovereign DAOs, software that holds spending keys triggers immediate VASP/MSB regulatory classification and catastrophic honeypot risk.

At Darklight Labs, we are currently solving this exact AI Agent intent-generation problem with Laminar, but we enforce a strict zero-liability ‘Calculator’ architecture. Laminar operates completely air-gapped and headless, calculating the deterministic intent for the agent, but handing off the actual cryptographic signing to dedicated infrastructure (like MPC networks or isolated mobile hardware).

I highly recommend isolating your agentic intent-generation from your key-custody layers to avoid absorbing the regulatory liability of autonomous execution. Happy to share some of our architecture if it helps your team navigate the P-256 boundary.

3

@Darklight_Z

Thank you for the warm welcome and the incredibly insightful feedback! This is exactly the kind of technical discussion we were hoping to have.

You hit the nail on the head regarding the P-256 to RedJubjub/Pallas friction. The gap between hardware enclave signatures and native Zcash shielded spends is the primary technical hurdle we are navigating. Also, you make a crucial point about liability: we completely agree that having `@veridex/agentic-payments` act as a custodial hot-wallet would introduce massive regulatory headaches and unacceptable VASP/MSB risks, especially for enterprise and DAO workflows.

Your approach with Laminar, enforcing a strict zero-liability “Calculator” architecture where intent generation is isolated from key-signing, is extremely compelling. It perfectly aligns with where we want to take our SDK. We want the agent to operate headlessly to negotiate and determine the spending intent (e.g., verifying an HTTP 402 requirement), but securely hand off the cryptographic signing of the shielded transaction to an isolated vault, the user’s secure hardware/enclave.

Would love to read more about how Darklight Labs is approaching this if you’re willing to share more resources

4

Manny, it is excellent to see a team prioritize regulatory physics over development speed. Recognizing the MSB/VASP trap early saves years of legal friction, especially when dealing with enterprise architectures.

To answer your question on how we approach this: we solve the P-256 to RedJubjub/Pallas friction by completely decoupling the agent’s brain from the cryptographic muscle.

If your @veridex/agentic-payments SDK is negotiating an HTTP 402 paywall, it shouldn’t touch Zcash cryptography at all. It should merely output a deterministic JSON intent detailing the required payment parameters.

This is exactly what the Laminar Phase 1 (Dual-Mode) architecture is built to handle. laminar-core features a headless, JSON-native Agent Mode. The optimal integration path for your team would look like this:

  1. Your Agent SDK negotiates the API paywall.

  2. Your Agent SDK pipes a JSON payload into the air-gapped laminar-core engine.

  3. Laminar performs the strict u64 integer validation, constructs the deterministic ZIP-321 payload, and aggregates the intent.

  4. Laminar hands the intent off to the user’s isolated vault (e.g., a hardware wallet or an enterprise MPC network) for the actual cryptographic signature.

By utilizing Laminar as the intent-construction boundary, your SDK remains perfectly non-custodial and sidesteps the elliptic curve mismatch entirely.

We will be publishing the Phase 1 API specifications and the dual-mode CLI documentation to the forum shortly. Once the core Rust crate is open-sourced, I would be happy to explore how the Veridex SDK can plug into the Laminar boundary.

5

Big +1 on killing seed phrases. UX is still crypto’s biggest bottleneck, and this is the right direction.

My main concern is the WebAuthn (P-256) → shielded key path. That translation layer is where things can get sketchy fast, so I’d really want to see minimal custom crypto glue and heavy reliance on audited primitives.

Also on the AI session keys, the spending limits need to be enforced cryptographically, not just at the app layer; otherwise, it’s a soft boundary.

The concept is strong, though. If the key management model is tight, this could be seriously compelling for Zcash.

6

Thank you for submitting your proposal. Following a thorough review by the ZCG the committee has decided not to move forward with this proposal.

We sincerely appreciate the time and effort you invested in your application and encourage you to stay involved and continue contributing to the Zcash community. Further details will be available in the meeting minutes to be posted later this week.