Major Hurdle #1 — Running Shielded Wallets in the Browser

I originally tried to build a fully self-custodial Zcash wallet directly in the web environment using zcash-devtools.
But:

• The tools rely heavily on Rust and native bindings

• I didn’t know Rust before the hackathon

• Compiling and using them inside a browser environment was extremely difficult

• This consumed a huge portion of my hackathon time

  How I solved it

I pivoted to using Zingo CLI, which has a much simpler interface and allowed me to spin up shielded wallets quickly.

The tradeoff was significant:

• I had to switch from self-custodial (user holds keys)
  to
  custodial (backend manages keys)

---

Major Hurdle #2 — Building a Modular Security Policy Engine

Aidra’s core innovation is its 13-module programmable security system, but:

• policies had different data structures

• some policies needed historical context

• some required real-time locks and atomic reservations

• concurrency issues led to race conditions

• I had to prevent double-spending even under rapid requests

  How I solved it

I redesigned the system as a plug-and-play policy pipeline with:

• atomic DB transactions
• “pending” state reservations
• modular JSON schemas
• consistent execution order
• a unified evaluation framework

Some policies are still slightly buggy at the edges, but the core enforcement logic works reliably and is extendable.

---

Major Hurdle #3 — Learning the Zcash Ecosystem on the Fly

Zcash’s tooling, terminology, and shielded workflows were initially unfamiliar:

• lightwalletd

• unified addresses

• shielded vs transparent flows

  How I solved it

I spent a chunk of time reading docs, testing commands, and experimenting with real wallets.
This slowed early progress but ultimately helped me build a correct and safe integration.

Major Hurdle #4 — Couldn't Implement WebAuthn-Protected Policy Updates

Another feature I planned but couldn’t implement in time was WebAuthn-secured policy updates.

Originally, my vision was:

• Users authenticate with WebAuthn to log in and
• The same WebAuthn credential would be required to change any security policy
  (limits, whitelists, guardian config, etc.)

This matters because without that second layer:

• Anyone with access to the device (friend, sibling, coworker)
• Could modify a user’s policy settings
• Which could weaken their security posture
• Even if they cannot directly sign outbound transfers

Why it didn’t make the final build

The limitation wasn’t technical difficulty, it was purely time.

Implementing:

• WebAuthn ceremony prompts for policy changes
• backend verification flows
• signed mutation logs
• re-authentication middleware

…would have required more time than I had left in the hackathon.

I chose to ship a stable core system rather than rush a critical security feature.

---

How I plan to fix it post-hackathon

The post-hackathon version will include:

• WebAuthn-signed policy updates
• Separate “admin” passkey for policy management
• Tamper-proof policy mutation logs
• Optional guardian approval for policy changes

This will harden the system so that policy changes are as secure as outbound transfers.