Forem: zk_nd3r

Building a Crosslink feature net explorer in 90 minutes (FastAPI + nginx + certbot)

zk_nd3r — Thu, 16 Apr 2026 00:59:34 +0000

someone asked for a block explorer in a workshop signal group on a tuesday afternoon. ninety minutes later one was live at ctaz.frontiercompute.cash, source MIT at github.com/Frontier-Compute/ctaz-explorer. this is a writeup of what it took and which choices cost time.

the tldr: about five hundred lines of python and jinja, no build step, no javascript framework, no analytics, no cookies, eighteen routes, server-side svg charts, systemd unit, nginx reverse proxy, lets encrypt cert. the hardest part was a port collision.

the chain

zcash crosslink is a hybrid consensus design. proof of work blocks are produced as usual, and a bft finality gadget stamps them finalized after a delay. it is currently running as an incentivized feature net called ctaz, which is short for crosslink testnet. the protocol page is at shieldedlabs.net/crosslink.

the practical consequence for an explorer is that every block has two states that matter, not one. "this block exists on the chain" and "this block has been finalized by the bft layer" are different questions with different answers. so every surface that shows a block needs to answer both.

there was no public explorer for the ctaz feature net at the time of writing. the protocol had a running node, a json rpc, and a workshop full of engineers staring at raw hex.

stack choices

the choices took about four minutes of deliberation, because the constraint was time and also, do not build anything that needs a sidecar service to render a page.

fastapi + jinja2. python is what the operator already had installed and warm. fastapi gives typed request handling and automatic openapi. jinja2 renders strings on the server. a react or svelte client would have required a build step, a bundler, and a deploy pipeline. on a ninety minute clock those are cost centers, not features.

nginx + certbot. cloudflare in front of a site gives tls and a cdn, and also gives cloudflare a view into every request and every ip. nginx with lets encrypt gives tls and nothing else, which is the correct amount of third party for a tool whose purpose is to let people verify things themselves.

systemd unit. a single python process with a virtualenv did not need a container runtime. the systemd unit is sixteen lines, the environment variable for the rpc port lives inline, and systemctl status ctaz-explorer is shorter to type than the docker equivalent.

no database. every page is rendered from a live rpc call. the rpc node is on the same box, so latency is microseconds. premature persistence is how weekend projects become monorepos.

the rpc dance

this part was not ninety minutes of clean flow. the rpc stack needed debugging.

zebra-crosslink, the monolith fork that runs the bft layer, builds from commit d880b65 tagged "speculative build" by sam smith. it compiles, it syncs, it exposes the standard zebra json rpc surface. the default rpc port is 8232.

the default rpc port was already taken. an unrelated docker zebra-mainnet on the same vps had claimed 8232 months earlier. so the ctaz explorer runs its backing zebra-crosslink on 18232 via an env var override.

# /etc/systemd/system/ctaz-explorer.service
[Service]
Environment=ZEBRAD_RPC_URL=http://127.0.0.1:18232
ExecStart=/opt/ctaz-explorer/.venv/bin/uvicorn main:app --host 127.0.0.1 --port 8088

ZEBRAD_RPC_URL = os.environ.get("ZEBRAD_RPC_URL", "http://127.0.0.1:8232")

async def rpc(method: str, params: list | None = None) -> dict:
    async with httpx.AsyncClient(timeout=10.0) as c:
        r = await c.post(
            ZEBRAD_RPC_URL,
            json={"jsonrpc": "2.0", "id": 1, "method": method, "params": params or []},
        )
        return r.json()["result"]

thirty seconds of code, about twenty minutes to figure out why getblockcount was returning the wrong chain.

finality badges

zebra-crosslink exposes a method called get_tfl_block_finality_from_hash. tfl stands for trailing finality layer. given a block hash it returns one of "Finalized", "NotYetFinalized", or an error. that is almost the entire ux model for a hybrid pow plus bft chain in three string values.

async def finality_for(block_hash: str) -> str:
    try:
        r = await rpc("get_tfl_block_finality_from_hash", [block_hash])
        return r or "Unknown"
    except Exception:
        return "Unknown"

three css classes, three colors. gold for finalized, blue for seen but not yet finalized, gray for unknown.

.badge-final    { background: #d4a017; color: #000; }
.badge-pending  { background: #2b6cb0; color: #fff; }
.badge-unknown  { background: #4a5568; color: #fff; }

{% if block.finality == "Finalized" %}
  <span class="badge badge-final">finalized</span>
{% elif block.finality == "NotYetFinalized" %}
  <span class="badge badge-pending">not yet finalized</span>
{% else %}
  <span class="badge badge-unknown">unknown</span>
{% endif %}

the badge shows up inline on the homepage block list, on the block detail page, and on every tx page since a tx inherits its block's finality. an honest detail: at the time of writing the finality gap on the ctaz feature net is about eighteen hundred blocks. the explorer displays that accurately. a chain does not need to be perfect for its explorer to be honest about where it is.

pool deltas

every zcash block returned by getblock verbose includes a valuePools array. one entry per shielded pool, with a valueDelta that tells you how much zec moved in or out of that pool in that block. the pools are transparent, sprout, sapling, orchard, and on crosslink there is also a lockbox pool.

no explorer on ctaz was showing per block pool flow. that was a gap worth filling, and the data was already there in the rpc response. so the explorer computes a two hundred block rolling window and renders one svg sparkline per pool, cumulatively, with no javascript involved.

def sparkline_svg(values: list[float], width: int = 280, height: int = 40) -> str:
    if not values:
        return ""
    lo, hi = min(values), max(values)
    span = (hi - lo) or 1.0
    pts = []
    for i, v in enumerate(values):
        x = (i / max(len(values) - 1, 1)) * width
        y = height - ((v - lo) / span) * height
        pts.append(f"{x:.1f},{y:.1f}")
    return (
        f'<svg viewBox="0 0 {width} {height}" xmlns="http://www.w3.org/2000/svg">'
        f'<polyline fill="none" stroke="currentColor" stroke-width="1.5" '
        f'points="{" ".join(pts)}"/></svg>'
    )

the polyline string goes straight into the jinja template with the |safe filter. browser renders svg natively. no chart library, no hydration, no skeleton loader. the page ships in one request.

/pool/orchard, /pool/transparent, /pool/sapling, /pool/sprout, /pool/lockbox. each has a matching /api/pool/{id} that returns the raw series as json for anyone who wants to pipe it into their own tooling.

attestation registries

three small json files in the repo hold a registry for each of three protocols that sit on top of zcash: zap1 anchors, shieldedvault custody events, and zeven event streams. the explorer loads them at request time and matches them against the txid being viewed. if there is a match, a typed card renders on the tx page explaining which registry matched and what claim is being made.

REGISTRIES = {
    "anchors": Path("data/anchors.json"),
    "vaults":  Path("data/vaults.json"),
    "events":  Path("data/events.json"),
}

def registry_matches(txid: str) -> list[dict]:
    hits = []
    for name, path in REGISTRIES.items():
        if not path.exists():
            continue
        entries = json.loads(path.read_text())
        for e in entries:
            if e.get("txid") == txid:
                hits.append({"registry": name, **e})
    return hits

on the ctaz feature net these registries are currently empty, because no anchors or custody events have been published to this chain yet. the /anchors, /vaults, and /events pages say so honestly, with a one line explanation of what will land there when the feature net gets real traffic. fake demo content would have been faster to render and would have been a lie. empty state with a sentence of context costs nothing and keeps the explorer trustworthy.

/verify

one page, one input field, one purpose. paste a txid. get back a json object containing the block, the finality status, the pool deltas affected, and any registry matches. one request, one answer.

@app.get("/api/verify/{txid}")
async def api_verify(txid: str):
    tx = await rpc("getrawtransaction", [txid, 1])
    block = await rpc("getblock", [tx["blockhash"], 2])
    return {
        "txid": txid,
        "block_height": block["height"],
        "block_hash": block["hash"],
        "finality": await finality_for(block["hash"]),
        "value_pools": block.get("valuePools", []),
        "registry_matches": registry_matches(txid),
    }

no auth, no api key, no rate limit, curl friendly. the whole point of the tool is that every claim the explorer makes elsewhere is independently verifiable by anyone running their own crosslink node, and /verify is just the shortcut.

curl https://ctaz.frontiercompute.cash/api/verify/<txid> | jq

/why

a link at the top of the homepage labeled "why this exists" goes to a page explaining the design choices above in more detail, with every claim anchored to a file and line in the repo. a block explorer explaining why it renders its own pages is recursively silly, but it answers the most common question a first time visitor has.

what does not work

the finality gap is large. the explorer shows it accurately but does not speed it up.
the 200 block sparkline window is a constant in source, not configurable per request.
no websocket push for new blocks, the homepage refreshes on page load only.
no search across addresses yet, only direct address page lookup by string match.
on rpc failure the page returns a 503 json blob, not a friendly error page with a retry hint.

none of those are hard. they are just not ninety minutes of work.

closing

this is not a product. there is no signup, no cta, no dashboard, no email capture. source is mit at github.com/Frontier-Compute/ctaz-explorer. if something looks wrong, open an issue. if something looks right, just use it.

the full route list, for reference:

/                   home, five panel dashboard
/block/{x}          block detail with finality badge and pool deltas
/tx/{x}             tx detail with attestation cards if any match
/address/{x}        address page
/finalizers         bft finalizer set
/stake              stake distribution
/params             protocol params
/verify             one shot proof tool
/why                design notes
/pool/{id}          per pool cumulative sparkline page (5 pools)
/anchors            zap1 anchor registry
/vaults             shieldedvault registry
/events             zeven event stream
/api/*              json versions of all of the above

eighteen routes, about five hundred lines of python and jinja, one afternoon. the ninety minutes is real but the ninety minutes is also the result of every choice above being the cheap one. react would have been a day. a database would have been a day. cloudflare in front would have been an hour of dns plus a permanent third party. none of those buy anything a feature net explorer needs on day one.

if the next person wants to fork it and point it at a different chain, the rpc url is an env var and the templates are plain jinja. that is the whole porting guide.

5 properties of agent custody

zk_nd3r — Thu, 09 Apr 2026 03:28:52 +0000

your AI agent can write code, book flights, manage a calendar. now hand it a wallet.

suddenly we are back to "trust me bro" with a hot key.

agent frameworks are everywhere. agent custody is nowhere. the gap between what agents can do and what agents can safely hold is the most dangerous problem in AI infrastructure right now.

here are five properties every agent wallet needs. if your agent is missing any of them, you do not have custody. you have a liability.

1. non-drainable

no single key compromise should drain the wallet.

most agent wallets today give the agent a private key. or they custody it on a server. either way, one compromise and the funds are gone.

the fix is threshold signing. split the key into shares. require 2 of 3 (or 3 of 5, or any t of n) to produce a valid signature. the agent holds one share. a policy service holds another. a recovery key sits in cold storage.

FROST is one way to do this. 2PC-MPC is another. the mechanism matters less than the property: no single point of failure drains funds.

2. policy-bound

spend limits, allowlists, and time locks must be enforced on chain. not in client code.

if your spending policy runs on the same server as your agent, the agent can modify the policy. or the server can be compromised and the policy disabled.

on-chain policy means the rules exist in a smart contract. the agent can request a transaction but the chain enforces the limits. the agent cannot override what the chain does not permit.

Sui Move is one approach. EVM modifiers are another. the key property: policy enforcement is independent of the agent runtime.

3. attested

every action the agent takes should produce a verifiable proof.

when your agent moves money, there should be a cryptographic commitment that says: this agent, at this time, took this action, with this result. anchored to a public ledger. independently verifiable.

this is not logging. logs are controlled by the operator. attestation is committed to a chain that the operator cannot alter after the fact.

ZAP1 is one implementation. any Merkle tree anchored to an immutable ledger achieves the property. the key: proof exists outside the system being proven.

4. remembering

the agent should carry context across sessions.

an agent that forgets what it did last session is an agent that repeats mistakes. custody requires memory. what positions are open. what policies were active. what decisions led to the current state.

this is not just a database. it is a knowledge graph that the agent can query semantically. "what happened last time volatility spiked" should return an answer, not a blank stare.

5. killable

a human or risk system must be able to halt the agent instantly. no override. no delay.

if your agent has a kill switch that the agent can disable, you do not have a kill switch. the halt mechanism must be external to the agent runtime and immediate.

file-based kill switches work. hardware dead man switches work. the property is: when the human says stop, the agent stops. before the next transaction. not after.

the test

for any agent wallet, ask five questions:

can a single key compromise drain the funds?
can the agent override its own spending policy?
can the operator alter the action history after the fact?
does the agent know what it did last session?
can the agent prevent a human from shutting it down?

if any answer is "yes", you do not have agent custody. you have a hot wallet with a prayer.

reference implementation

we build open-source agent custody infrastructure on Zcash. FROST threshold signing, on-chain policy enforcement, Merkle-anchored attestation, semantic memory, hardware kill switches. privacy by default.

all of it is open source, MIT licensed, and verifiable.

npm: npmjs.com/package/@frontiercompute/zcash-ika
github: github.com/Frontier-Compute
spec: github.com/zcash/zips/pull/1243
awesome-agent-wallets: github.com/Zk-nd3r/awesome-agent-wallets

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.