The problem ZK-Inherit solves

The problem it solves

ZK-InherIt is a private, verifiable crypto inheritance system. It lets people decide who gets their crypto (ETH, USDC, NFTs) if they become inactive, without revealing beneficiaries or amounts on-chain and without relying on a lawyer or custodian to execute the will.

What people can use it for

• Set a private digital will Allocate assets to up to 8 beneficiaries. Only a commitment hash and Merkle root go on-chain; who gets what stays hidden until execution.
• Prove validity without leaking data A Noir ZK circuit proves that allocations sum to declared totals and match the committed will, so the chain can trust execution without seeing beneficiary details.
• Automate execution on inactivity A heartbeat contract tracks check-ins (e.g. yearly). If the user stops checking in, a configurable grace period starts; trusted veto members can pause. After the grace window (and if not vetoed), the will can be executed and assets distributed privately.
• Use existing legal documents Upload a signed PDF will; a Rust backend extracts beneficiary data so users can bridge traditional wills into the same private, on-chain flow.
• Comply with identity and age rules Integration with Self Protocol ensures only verified humans (e.g. passport/Aadhaar) can register wills and enforces age checks (e.g. 18+) without storing personal data on-chain.

How it makes things easier or safer

In short: people use ZK-InherIt to pass crypto to chosen beneficiaries privately, on a schedule driven by inactivity, with verifiable correctness and optional PDF/identity integration.

Challenges I ran into

1. Heavy ZK dependencies slowing the frontend

What happened: The Next.js frontend took several minutes to compile and often felt stuck. First load was very slow because of large crypto/ZK libraries (circomlibjs, @noir-lang/noir_js, @aztec/bb.js, Poseidon, etc.). Webpack was analyzing and bundling all of them on every cold start.

How I got over it: I optimized the Next.js webpack config: added chunk splitting so heavy crypto libs are in a separate bundle, ignored noisy "Critical dependency" warnings from circomlibjs/ffjavascript, and enabled SWC minification. I also cleared the .next cache and ensured Node 18/20 (not Node 24) was used. First compile stayed heavy but became manageable; subsequent dev runs and page loads were much faster.

2. Node 24 breaking Next.js with ERR_INVALID_PACKAGE_CONFIG

What happened: Running npm run dev failed with Invalid package config ... next/dist/compiled/commander/package.json and Node.js v24.4.1. Next.js 14 isn’t validated on Node 24, and Node 24’s stricter package.json handling caused the bundled commander inside Next to fail.

How I got over it: Switched the project to Node 20 (or 18) via nvm, added an .nvmrc with 20 so the right version is used automatically, and reinstalled dependencies. The frontend then started without that error.

3. Stale Service Worker (Workbox) blocking the app from loading

What happened: The app at http://localhost:3000 kept loading indefinitely. The browser console showed no-response errors for /_next/static/chunks/main-app.js and other Next chunks. A previously registered PWA/Workbox Service Worker (from another project or an old build) was intercepting requests and failing to fetch the new chunks, so the page never rendered.

How I got over it: In Chrome DevTools → Application → Service Workers, I unregistered the service worker for localhost and enabled “Bypass for network”. Then under Storage I did Clear site data and performed an Empty Cache and Hard Reload. After that, Next’s chunks loaded normally and the app worked.

4. Rust backend failing to build: serde_core build script timeout

What happened: Running cargo run in the backend failed with:
failed to run custom build command for serde_core v1.0.228 and
Os { code: 60, kind: TimedOut, message: "Operation timed out" }.
The build script of the newer serde/serde_core was hitting a timeout (likely a network or system call), so the backend never compiled.

How I got over it: I pinned serde and serde_json in Cargo.toml to slightly older versions that don’t trigger that build script behavior:
serde = "=1.0.210" and serde_json = "1.0.114".
Then I ran cargo clean and cargo build. The backend compiled successfully and runs on port 3002.

5. Designing the Noir circuit so allocations are both private and verifiable

What happened: I needed the circuit to prove that beneficiary allocations sum to the declared totals and match a Merkle tree, without revealing individual addresses or amounts. Getting the public vs private inputs right and building a Poseidon-based Merkle tree that matches the frontend (and fits in the circuit) was tricky; wrong ordering or padding broke verification.

How I got over it: I clearly separated public inputs (will_commitment, merkle_root, total_eth, total_usdc, total_nft_count) from private inputs (salt, will_data, beneficiary arrays). I implemented the same Poseidon hash (hash_2, hash_4, hash_5) and Merkle structure in both the Noir circuit and the frontend’s Poseidon lib so the computed commitment and root matched. I added a test in the circuit (test_valid_will) with fixed values to lock in the expected hashes and avoid regressions.