2026-05-21

Another Two-Part Meeting

This week splits in half again. The first half belongs to our guest — a builder out of Kolkata who joined the community last October and started shipping ZK tooling almost immediately. He's here to present Root14 — a privacy toolkit for Stellar built on the zero-knowledge primitives that landed in recent protocol upgrades. The second half is mine: a fast tour through roughly ten open-source, mostly-free AI tools, continuing the orchestrator theme from last week. If cryptography isn't your thing, skip to the tools. If you've had enough of me talking about agents, the first half is the one for you.

A quick reframing before he starts, because it's load-bearing for everything he says: Root14 is not a private payments app. It's not a mixer and it's not a shielded pool. It's the cryptographic infrastructure that sits underneath all of those things. The analogy he uses is OpenSSL versus a single HTTPS website — Root14 isn't the website, it's the part every website ends up importing.

The Substrate: Why the Economics Only Work on Stellar

He grounds the whole talk in CAP-0059, which shipped the native BLS12-381 host functions to Soroban: G1/G2 addition, scalar multiplication, multi-scalar multiplication, pairing checks, and full scalar-field arithmetic. That's the complete substrate you need to do production-grade Groth16 verification natively, available to any contract.

His pitch for why Stellar comes down to cost. A pairing check that would take tens of millions of Wasm instructions on another chain runs as a single host call here. No other smart-contract chain has this combination at this cost point today — which is exactly what pulled him to the network and got him researching ZK on it in the first place.

What's in the Toolkit

Root14 is a layered toolkit, and he walked through it piece by piece:

• Root14 Core — a single contract that does two things. You call register and get back a content-addressed circuit identifier (the SHA-256 of the verification key, so the binding is unforgeable). After that, any contract on the network calls verify with a circuit ID, a proof, and the public inputs, and gets back a boolean. That's the entire interface. The contract holds no business logic, no value, no decisions — just registered verification keys and pairing checks. It's live on testnet today. The load-bearing insight: every existing privacy project on Stellar embeds its own verifier inside its own contract and pays for its own audit on essentially the same pairing code. A shared registry makes that duplication disappear.
• Circuit Library — a set of vetted primitive circuits with published constraint counts and content-addressed identifiers: range proofs (credit thresholds, age bounds), set membership (KYC allow-lists), set non-membership (sanctions screening), and knowledge-of-preimage (ownership groups). Register a primitive once and every dapp on the network can use it.
• SDK and CLI — a single cargo add gets you proof generation and serialization in Rust; the CLI is a human-friendly shell over the same SDK, with templates for generating contracts.
• MCP server — the part he's most excited about. It lets Claude or any MCP-compatible model register a circuit, generate a proof, and trigger a verify call through natural language. As far as he can tell, it's the first ZK-on-Stellar MCP integration anywhere. A registry indexer streams on-chain events so developers can discover which circuits exist and how to compose them.

The zkTLS Bridge

The piece closest to his heart is Root14's zkTLS. It bridges web2 and web3 trust: a user generates a zero-knowledge proof that they received a specific response from a specific web2 server without revealing the rest of the session. Prove you have over $1,000 in a bank account without showing the statement. Prove a KYC status with a particular issuer without exposing the underlying credential. Prove a tweet exists at a URL without leaking the OAuth token. There's a prototype today and production integration is on the roadmap; combined with the verifier registry, it's a clean way to pull real-world data into Soroban contracts without trusting a centralized oracle.

Private Payments, Honestly

He was candid about the one piece that isn't usable right now. His original SCF submission leaned on private payments, and the mainnet privacy-pool deployments lagged on the AML/KYT-sensitive side — building privacy-preserving payments without thinking hard about compliance is how you get into legal trouble. So that part is currently down while he reworks it to be KYC/AML-aware. The developer-facing shape is still the goal, though: you don't write pairing code, you don't run a trusted-setup ceremony, you don't touch arkworks — you write your application contract, bind it to the relevant circuit identifiers in the registry, and call verify when you need a proof checked.

Production Readiness

This isn't framed as a research prototype. Verification keys registered on mainnet will be immutable and content-addressed — no upgrade method, no admin power to silently re-point an identifier. Canonical registration transactions go through an SDF-approved multisig. The phase-2 trusted-setup ceremony will be multi-party with public transcripts and end-to-end-verified attestations from every contributor, and everything is open source under the Root14 name.

The Q&A: AI, Groth16 vs. PLONK, and the Business Question

We tend to roast our guests with hard questions so they've already sweated out the answers before they reach an SCF panel, and the audience delivered:

• How much AI, and what's the setup? He works ZK problems out with pen and paper first, then drives Claude Code layer by layer — architecture, then circuits, then verifier — prototyping, testing, and bouncing the output off other agents before moving on. He also leaned on the llms.txt file from the docs to make the model Stellar-aware out of the gate. His honest caveat matches mine: AI tends to cut corners on ZK, so it's an accelerant, not an autopilot.
• Long-term sustainability? A shared verifier registry doesn't make much money on its own — maybe a small fee on registrations or calls. The real business is zkTLS as a B2B product: managing ZK infrastructure for Stellar-native teams and selling into developer/user onboarding flows.
• Why Groth16 over PLONK, and who runs the ceremony? Groth16 won on cost and proof size for a hackathon timeline; PLONK needs more pairings and polynomial-commitment work, roughly double the budget for the same proof. He reuses an existing phase-1 powers-of-tau output (the Ethereum or Aztec ignition ceremonies, both public and audited with 100+ contributors) and only runs phase 2 per-circuit. Nothing about Root14 is religiously locked to Groth16.

Root14 is in SCF #43 — the docs site is mid-rebuild, so keep an eye out and vote it up when public voting opens.

The Orchestrator Theme, Continued

The pivot to the second half: last week I made the case that the job is shifting from facilitator (you write the code, you stay close to the work) to orchestrator (you manage a fleet of agents). This week's theme is narrower and a little more pointed. Stop writing "make no mistakes" to your model. If you can't steer the build, it's usually because you don't understand what's being built — and if you wouldn't be able to build it without AI, that's the most dangerous place to be. The tools below are all attempts to keep you hands-on enough to understand the thing you're shipping.

Hands-On Frameworks: BMAD and Superpowers

The BMAD Method is the one I most wanted to show. It installs locally and free with npx bmad-method install — it's just a set of skills, hooks, and workflows, scoped to your project rather than installed globally. The point is spec-driven development with an Agile shape: it slows you down on purpose and walks you through brainstorming, market and domain research, technical research, and then planning out a PRD and stories. Each phase has a named agent — Mary is the business analyst you brainstorm with — and /bmad-help is your "what do I do next" button at any point. I kicked off a "Hey Mary, I want to build something with agentic payments on Stellar but I don't know what" session live to show the brainstorming loop.

Superpowers is an alternative skills framework that does more or less the same job minus the explicit Agile emphasis. Try both and keep whichever fits how you think. The shared point of both: a more hands-on approach so you actually understand what's being built.

Letting Agents Use a Browser: kernel.sh and browser-use

Claude Code and Codex can fetch a page's data but can't really drive a browser — and they can't touch Chrome extensions, which is painful if you're testing a Stellar wallet extension. kernel.sh fixes that: it spins up cloud browsers and lets your agent build automated workflows (it calls them "apps") through a free MCP server. My demo had Claude Code's kernel MCP walk stellar.expert for mainnet stats, click into the Soroban tab, hop to CoinGecko for the XLM/USD price, and capture it all to JSON. It's open-source infra with a free tier; the paid plan exists, but the free MCP is enough to expand your sense of what's possible.

browser-use is the tool your model reaches for first when you ask for browser automation — which is exactly why I show it. First-recommended isn't the same as best. It wants its own API keys (Google's and Anthropic's), and I'd rather point an agent at tools that ride the CLI I'm already paying for. Useful to know it exists, but kernel was the smoother experience for me.

Free Compute: freebuff

freebuff is the free tier of CodeBuff — it gives you a few hours a day of DeepSeek V4 Flash for free, with ads. The agent ("Buffy") does the usual implementation, codebase navigation, testing, and multi-agent orchestration (it'll spawn a stack of sub-agents), and it drives a browser using browser-use under the hood, so you get the browser-automation demo and the free-compute demo in one. DeepSeek V4 Flash is light but genuinely good for exploratory work when you don't want to burn frontier-model budget. CodeBuff's paid tier is around $100/month; if you're going to consider that, spend your free hours first.

Memory: claude-mem, mnemon, and Raindrop Workshop

The unsolved problem under all of this is memory — how does the agent remember where it left off? Three takes:

• claude-mem is the most widely used, and it's my favorite plug-in for this. It runs locally, works with Claude Code and Codex, and at the end of each session it scans the whole thing — what you discussed, what the agent did, where it went wrong, how it reached its conclusions — and writes session summaries plus, my favorite part, discoveries. Open the folder again and the agent already knows where it left off. No more hand-written handoff markdown. The trade-off is that it stores a lot, including things you didn't need.
• mnemon is the same idea but LLM-supervised: it lets your model decide what to remember and when to recall it, which keeps the store much tighter. It's newer and smaller than claude-mem, has an MCP server, and persists across sessions. Import claude-mem's history into mnemon's graph and you can see what the former would look like with structure; run mnemon on its own and you get a clean "mind palace."
• Raindrop Workshop is the outsider. It's a local debugger that doesn't store everything and isn't LLM-supervised — it stores workflows, the step-by-step way to do a recurring thing. Ask the agent to do that thing again and it fetches the tree and follows it. It's cost-efficient precisely because it only remembers how, not what.

Where This Is Going

We covered a lot at a shallow depth on purpose. I want your help picking which of these deserves a full, hour-long deep dive in an upcoming session — tell me on Discord. The throughline of the whole second half: software is getting fast and cheap, and cheap software is also dangerous software. A more hands-on approach is the cheapest insurance you can buy. Stop writing "make no mistakes," start writing /bmad-help, and understand the thing you're building.

One housekeeping note worth repeating: CCTP is live on Stellar now, so cross-chain interop apps are something you can start building today.