DEV Community: zk_nd3r

The Agent Custody Problem

zk_nd3r — Wed, 08 Apr 2026 01:27:38 +0000

AI agents are handling real money. Trading bots. Treasury managers. Procurement agents. Settlement systems. They need wallets.

Three products launched in the last 30 days. Trust Wallet Agent Kit covers 25+ chains. Coinbase AgentKit introduced the x402 protocol for agent payments. Human.tech shipped Agentic WaaP at WalletCon. All of them have the same problem.

The agent holds a hot key. Or the platform holds it for them. Either way, one compromise drains everything.

This is the agent custody problem: how do you give an agent the ability to transact without giving it the ability to steal?

Why it matters now

250,000 agents transact on-chain daily. 550+ agent projects. $4.3B combined market cap. The x402 payment standard, co-founded by Coinbase and Cloudflare, has processed $10M+ on Solana alone. This is not a research problem. This is a production problem.

Every one of these agents holds keys. Every one of those keys is a single point of failure.

The three requirements

1. Non-drainable wallets. The signing key must never exist as a whole. Not at creation. Not at signing. Not at recovery. This is a cryptographic guarantee, not a trust assumption. Split-key architectures where the agent holds one share and a second party holds another. No single compromise drains the wallet.

2. Enforceable spend policy. Rate limits in API middleware are not policy. A compromised agent ignores client-side checks. Policy must live on-chain, in a smart contract that the agent cannot bypass. Maximum daily spend. Approved addresses. Position size limits. Enforced by consensus, not by the agent's own code.

3. Verifiable history. Every action the agent takes must be provable after the fact. But "provable" does not mean "public." A trading agent that publishes every position to a public ledger gets front-run. A treasury agent that exposes every payment gets targeted. You need attestation that proves what happened without revealing the details.

Why existing solutions fail

Coinbase AgentKit. Custodial. Coinbase holds the key, or the agent holds a hot key with an emergency admin freeze. Better than nothing. Still a single point of compromise at the custody layer. No split-key signing.

Trust Wallet TWAK. 25+ chains. 220M user base. Standard wallet model. The agent gets full key access. User-defined permissions exist, but they are client-side. A compromised agent has the key.

Human.tech WaaP. Two-party computation between user device and secure enclave. Permission tokens for spending caps. Closest to real agent custody. But every transaction is visible on-chain. A trading agent using WaaP broadcasts its entire strategy to the world.

Lit Protocol. Threshold MPC with a network of nodes. N-of-M signing. Weaker trust model than 2PC because you trust a threshold of nodes rather than a cryptographic split. No attestation layer. No privacy chain. 7,000 agent wallets created. No way to prove what those agents did without exposing it.

Fireblocks. Institutional MPC. Closed source. $699/month minimum. Solves custody for hedge funds, not for autonomous agents that need programmable policy and verifiable history.

Every one of these products solves part of the problem. None solves all three requirements together.

What agent custody actually requires

2PC-MPC signing. The key is generated in two shares. One share stays with the agent operator. One share stays with the custody network. At signing time, both parties compute their part. The full key never exists, not in memory, not in transit, not in any backup. This is not threshold signing where enough colluding nodes reconstruct the key. This is a two-party protocol where reconstruction is cryptographically impossible.

On-chain policy. Sui Move contracts that enforce spend limits, approved counterparties, and position constraints. The agent submits a transaction request. The policy contract checks it. If it violates the rules, the transaction never gets signed. No API middleware. No client-side checks. On-chain, deterministic, auditable.

Privacy attestation. Zcash shielded memos. Every agent action gets attested to a Merkle tree anchored on Zcash mainnet. The attestation proves the action happened. The shielded memo hides the details. An auditor can verify the proof. A competitor cannot see the position. BLAKE2b verification via EIP-152 on Ethereum at 712 gas per hash. The same proof root, checkable on multiple chains.

Cross-chain verification. One proof system. Multiple verification surfaces. The same attestation root registered on Ethereum, Arbitrum, Base, Hyperliquid, NEAR, and Sui. An agent custody system that only works on one chain is not an agent custody system. Agents operate across chains. Their custody must follow.

Born shielded

We built this. Born shielded, traded shielded, settled shielded.

The key never existed whole. The policy lives on Sui. The attestation lives on Zcash. The verification lives on seven chains. FROST threshold signing for multi-party attestation. EIP-152 verification on Ethereum mainnet. 54 npm exports. 2 Rust crates. Mainnet proven.

The agent custody problem is not a feature request. It is a category. The products that solve it will handle the money that agents move. The products that do not will be the ones that get drained.

npm install @frontiercompute/zcash-ika

zk-nd3r builds agent custody infrastructure at frontiercompute.cash (https://github.com/Frontier-Compute).

Verifying Zcash Proofs on Ethereum with EIP-152

zk_nd3r — Tue, 07 Apr 2026 21:39:46 +0000

Ethereum has a precompile that almost nobody knows about. It lives at address 0x09, it computes the BLAKE2b compression function, and it was put there specifically so you can verify Zcash on Ethereum. This is the story of how we use it.

What EIP-152 Is

EIP-152 landed in the Istanbul hard fork (December 2019). It exposes the BLAKE2b F compression function as a precompiled contract at address 0x09. Cost: 1 gas per round. A standard BLAKE2b call runs 12 rounds, so 12 gas total.

BLAKE2b is the hash function underpinning Zcash's Sapling and NU5 Merkle trees. Without this precompile, computing BLAKE2b in Solidity costs around 200,000 gas. With it: 712 gas for a full hash. That is a 280x reduction.

The EIP was proposed by Tjaden Hess and others from the Ethereum Foundation and was motivated by one thing: enabling Zcash light client verification on Ethereum without absurd gas costs.

Why It Matters

Cross chain proof verification needs hash functions. Zcash uses BLAKE2b with personalization strings for domain separation. Each tree level, each protocol context uses a different personalization. For example, ZcashPedersenHash for note commitment trees and ZTxIdHeadersHash for transaction IDs.

If you cannot compute these hashes cheaply on chain, you cannot verify Zcash state on Ethereum. Period. The precompile makes it possible.

The 213 Byte Input Format

The precompile expects exactly 213 bytes, packed tight:

rounds (4 bytes): number of rounds, 12 for BLAKE2b
h (64 bytes): state vector, 8 x uint64 little endian
m (128 bytes): message block
t[0] (8 bytes): offset counter low, uint64 little endian
t[1] (8 bytes): offset counter high, uint64 little endian
f (1 byte): final block flag, 0 or 1

Total: 213 bytes in, 64 bytes out.

The Precompile Call

Here is how ZAP1Verifier.sol calls it:

function blake2b(
    uint32 rounds,
    bytes memory h,
    bytes memory m,
    uint64 t0,
    uint64 t1,
    bool isFinal
) internal view returns (bytes memory) {
    bytes memory input = abi.encodePacked(
        bytes4(rounds),
        h,
        m,
        bytes8(t0),
        bytes8(t1),
        isFinal ? bytes1(0x01) : bytes1(0x00)
    );

    (bool ok, bytes memory out) = address(0x09).staticcall(input);
    require(ok, "BLAKE2b precompile failed");
    return out;
}

staticcall to 0x09. No ABI encoding. No function selector. Raw bytes in, raw bytes out. The precompile handles the rest.

Personalization Strings

Zcash domain separation works by XOR ing a 16 byte personalization string into the initial state vector (bytes 32 to 47 of h). Each protocol context gets its own string. When verifying a Sapling note commitment Merkle path, you set the personalization to the appropriate Zcash constant before each compression call.

This is not optional. Wrong personalization means wrong hash means failed verification. The precompile does not enforce personalization; your contract must set h correctly before calling 0x09.

Gas Reality

A Merkle proof for a Zcash Sapling tree is 32 levels deep. Each level needs one BLAKE2b compression. With the precompile, that is roughly 32 x 712 = ~22,800 gas for the hashing. In pure Solidity: 32 x 200,000 = 6.4M gas. One would blow past block gas limits.

The precompile does not just save money. It makes the verification possible at all.

Live on Mainnet

ZAP1Verifier is deployed on ETH mainnet at 0x12db453A7181E369cc5C64A332e3808e807057C1. It verifies Zcash Sapling Merkle proofs using the EIP-152 precompile. The same contract is live on Arbitrum, Base, Hyperliquid, and Sepolia.

Source: github.com/Frontier-Compute/zap1-verify-sol

The Bottom Line

The precompile has been on Ethereum since 2019. Almost nobody uses it. We do.