A Short One, For a Good Reason​

This week's meeting was a short one, because it had exactly one job: announcing the 12 winners across 6 tracks from last week's Stellar Builder Summit in São Paulo. I was on the ground with the builders all week, so this was less news roundup, more handing out trophies. My colleague Teague Kaylor from SDF's marketing team — focused on developer marketing, which means most of the developer events and programs you see from us have Teague's fingerprints on them — joined to set the scene before the announcements.

What the Builder Summit Is​

Builder Summits started as a pilot last year at Consensus Toronto: a long-form developer event that brings the community together over an extended stretch to jam on projects, meet new teams, and get properly connected to the ecosystem — instead of the usual 48-hour hackathon sprint. Toronto went well, so this year the plan is to run them in the markets the foundation is launching into. São Paulo was the first.

The final numbers: around 190 developers from around the world, coding for eight days straight, with workshops and sessions through the week and community days over the weekend. The event was produced with NearX — Stellar's partner in Brazil — and our other partner teams on the ground, and the same week São Paulo also hosted Stellar House, a one-day gathering on tokenization, stablecoin rails, and cross-border settlement.

Attached to the summit was a bounty program — Teague described it as a mix of an RFP track and a hackathon — pointed squarely at what we want to see built on the network: privacy, anchors and ramps, local yield, and agentic payments and tooling. More Builder Summits are coming later this year, so watch the @BuildOnStellar handle on X for announcements.

The Winners: 12 Across 6 Tracks​

The format: for each track, second place first, then the winner. One housekeeping note before the list. I read these names off the results live and dropped the repo links into the YouTube stream chat as I went (sorry, Twitter viewers — we still haven't figured out posting links there). The canonical list, with correct spellings and repo links, is going out via @BuildOnStellar and our summit partners, so trust that over my pronunciation. Where the auto-captions and I couldn't agree on a name, I'm describing the project rather than guessing.

Privacy: Confidential Tokens & Private Payment Wallets​

Second place went to a Confidential Token SDK — a TypeScript client for OpenZeppelin's confidential tokens, with a verifiable replay archive. If you read the July 2 note on the confidential-token developer preview, this is exactly the tooling layer that preview was begging for. I talked with this builder in São Paulo, and their read on our confidentiality layers was genuinely insightful — the placement is well earned.

The winner: a privacy wallet — a passkey-based smart wallet with confidential transfers and a shielded pool whose idle liquidity earns yield. Keep this builder in mind; they show up again below.

Enterprise Compliance & RWA​

Second place: Green Road by Trustless Work — a confidential milestone escrow that releases a private allowance without revealing the amount. We all know and love Trustless Work and their escrow infrastructure, and this is a natural extension of it into the confidential era.

The winner: QuietBook — confidential book-building for tokenized RWAs. Sealed bids, a provable winner, atomic settlement. Need I say more? I don't think so. It came from a Turkish builder the community knows as Captain — we all met Captain in São Paulo, and the stream chat's verdict ("Captain is the goat") stands.

Anchors & Ramps: Regional Kits​

Second place, Trustless Work again: a LatAm ramp kit — a drop-in SDK and React component kit that adds fiat ramps to any LatAm app. Two placements in a single summit is a statement.

The winner: a Brazil regional kit — a PIX on- and off-ramp for Brazil with live quotes from competing anchors. It's an aggregator; we all need it, we all love it. The team behind it we've known since our hackathon in Mexico — long-term builders in this ecosystem, still shipping.

Anchors & Ramps: Emerging-Market Yield​

Second place went to a project that parks idle receivables in Brazilian treasuries while measuring the currency risk. The captions and I jointly butchered the team's name on stream — apologies again; the official winners list will do it justice.

The winner, from a Brazilian DeFi team: BRL that earns Brazilian treasury yield right up to the second a PIX payment fires. Which, as I said on the call, is pretty cool.

Agentic Payments​

Second place: a discovery layer that lets AI agents find what to pay for on Stellar. Every agent-payment stack eventually hits the "pay for what, exactly?" question, so yes — we all need this one too.

The winner: StellarPay — one middleware for every machine payment protocol on Stellar. x402, MPP Charge, MPP Channel — all of it behind a single interface. And yes: same builder as the privacy wallet above. Two tracks, two first places, one summit.

CLI Plugins & Dev Tooling​

Second place: a CLI plugin that lets an AI agent safely call a Soroban contract, gated by an on-chain policy. If you've ever wired an agent up to a Soroban contract, believe you me, you might just need this.

The winner: Stellar Memory — a persistent memory layer that links a Soroban repo to what's actually live on-chain. I love a memory layer as much as the next guy, and I'm glad the track went to a project that closes the gap between your codebase and the deployed reality.

Closing​

Close to 200 builders, building for almost a week straight — thank you for showing up. Thanks as well to the judging bench (I was on it, alongside colleagues from SDF and friends from across the ecosystem) and to NearX and the partner teams who produced the event with us. My last words on the call stand: I hope to see every one of these projects evolve into something bigger, and I hope you get to brag one day about how your journey started at a Builder Summit in São Paulo. More of these are coming later this year. See you next week.

Live from Stellar House​

This week we streamed from Brazil, where the team is camped out for Stellar House — if you're around, come on down. The stream itself was a full-hour Q&A about confidential tokens, now live on Stellar testnet: private balances and transfer amounts for SEP-41 tokens, with sender and recipient addresses kept public for compliance. I collected 25+ genuinely hard questions from builders during the summit that just wrapped, the live chat piled on more, and my plan was to ask the easy ones and let you do the damage.

The guests: Alessandro Voto (goes by Alex), senior product manager of privacy at SDF — in crypto since 2014, and the conduit between institutions asking for private payments and the people implementing them. Design questions went there. Technical ones went to Jay Geng, a stellar-core engineer at SDF for four-plus years who worked on Soroban and the host functions that brought ZK primitives to Stellar (Poseidon, BN254, BLS12-381), presented an early iteration of confidential tokens at Meridian in Rio last year, and shaped several of this product's early design decisions.

We started with 100+ viewers across three platforms and ended past 250.

Private Does Not Mean Illegal​

A surprising number of the questions boiled down to "is this legal?" Alex pushed back on the premise: nobody scrutinizes what you spent on groceries yesterday, and payment privacy in traditional finance isn't a convenience — it's a mandate. For enterprises it's a dealbreaker; they will not make payments their competitors can watch. Blockchains made payments public as a side effect of protecting transaction integrity, never as an end goal.

The SDF position pairs privacy with compliance readiness: the tools ship with freezing, clawback, and Stellar Asset Contract passthroughs, deliberately open-ended because disclosure requirements differ by jurisdiction — you figure out what "legal" means where you operate, and the boundaries enforce it. That same morning, José Fernández da Ponte, SDF's president, had framed the network as public by default, private by design — about the neatest recap available.

Chat asked the obvious follow-up: why the application layer rather than the chain itself? Same reasoning. SDF won't force a privacy regime on anyone happy with the public network's auditability, and application-level privacy lets technologies evolve — some use cases may eventually demand post-quantum designs — without touching the L1. What the core team did ship is the cryptographic host functions that make verifying these proofs on-chain cheap.

Why Hide Amounts but Not the Addresses?​

The single most asked question — more than five builders raised it with me at the summit alone.

Alex's product answer: confidential tokens are one tool in a toolkit. If you need counterparty privacy, Nethermind's Stellar Private Payments is a privacy-pool toolkit that shields amounts and addresses. Confidential tokens deliberately keep counterparties public because that's what the target users asked for: institutions making regular, publicly known payments — foundations paying grantees, charities, banks settling with each other — where an on-chain record of who got paid is an audit feature, but the amount is the sensitive part. A settlement amount can leak an acquisition intent; a large grant to someone vulnerable can paint a target on them. It's the missing middle setting on Venmo: I want you to know I paid this person, just not how much. (And to chat's "who is this for?" — primarily institutions today.)

Jay's engineering answer: full anonymity is a fundamentally different design. Privacy pools are UTXO-shaped, elaborately grafted onto Stellar's account model, and the proving cost is much higher — you're proving note formation, Merkle-tree inclusion, and unspent nullifiers on every transaction. The confidential token is the more elegant construction: it wraps any existing SEP-41 token — without knowing in advance which asset it will shield — and only encrypts the numbers.

Auditors, Viewing Keys, and the Escrow Question​

The auditor is, in my experience, the single most confusing part for developers, so I asked chat's version directly: how does an auditor see anything without the holder cooperating? Jay's answer: it falls naturally out of the encryption design. Amounts are encrypted under the sender's and recipient's keys — and, in addition, under the auditor's key. Whoever holds that viewing key can decrypt the same information, no cooperation required. Policies — who can audit, rotation, key lifetime — don't have to live in the contract logic; it just cares that the key exists. It's decoupled and modular — the key can even belong to a third party that doesn't exist on-chain.

Alex layered the intent on top: there's selective disclosure, which is user-initiated ("I can prove this payment happened to whoever I choose"), and there's compelled revelation through the auditor key. The intention is not that someone sits watching the pool — the auditor key should sit unused inside an MPC or TEE custody setup (think Utila or Fireblocks, not a Freighter wallet) and only answer scoped requests when a regulator compels one. A single auditor address does not mean a single person; put real key management on it. Alex would be shocked if you didn't.

Then the fun one. Alberto of Trustless Work (the escrow project) showed me a confidential-marketplace experiment that day — an escrow contract between Alice and Bob — and asked whether one auditor holding four keys across four "auditor channels" was the simplest compliant setup. The panel's honest answer: the question doesn't quite map onto the design — "channel" is an overloaded word Jay wanted more context on, and the escrow case probably wants selective disclosure rather than extra auditors. One correction from me while writing this up: Alex's on-call recollection was one global auditor key per confidential token contract, but the shipped implementation binds an auditor_id per account at registration, out of a shared auditor registry that can hold many keys and serve many tokens — design your compliance around that, not around a single global key. To be continued on Discord once the project ships.

The broader point is worth keeping: today's confidential tokens do basic payments with very little composability inside the wrapper — a confidential wrapper doesn't give you atomicity between a payment and a delivery. People are already hacking extensions (like triggering a contract on successful payment), and Alex explicitly wants to see an escrow system built this way. Just don't expect the primitive to hand it to you.

C-Addresses, Passkeys, and Key Derivation​

Can you use confidential tokens from a smart wallet — passkeys, C-addresses? Yes; Alex has already seen a passkey demo inside a confidential-token-capable wallet. Jay's explanation of why it works: authentication and token holding are decoupled. The smart wallet is an authentication mechanism; the account holder is just a regular token holder underneath. Encryption keys are derived from your account's secret — secret key, then spending key, then viewing key, and so on.

Registration was the follow-up: to participate you register with a specific token contract — the key derivation commits to that contract, involves a proof, and stores your public spending and viewing keys along with your chosen auditor_id. (The auditor's own keys live in a separate registry contract — you pick an auditor at registration, you don't provide its key.) Per Jay, both sender and recipient need to be registered; you can't fire tokens at an address that has never generated its keys. Alex noted the registration step is the deliberate price of a design ask — log in with your existing address and derive everything from it, instead of manually managing separate view and spending keys like the original implementation did.

Then the warning of the week, from Alex: your key derivation must be deterministic and must match the OpenZeppelin SDK's canonical derivation. Alex vibe-coded a wallet that derived keys differently than the demo does — it could deposit funds but never spend or withdraw them. That's an accidental honeypot, built in good faith, by AI. It's funny until it's a lot of money. The system deliberately pushes work client-side for privacy, so the cryptography there actually matters; OpenZeppelin is writing an SDK spec to make expectations explicit. Until then, follow the SDK and don't let a hallucination invent your derivation path.

Wallet Hygiene: Retention Windows and Replay​

Jay's practical corollary for wallet builders: receiving requires no action from the receiver — incoming amounts accumulate homomorphically into your receivable balance as encrypted events, and your wallet learns what you hold by replaying those events, decrypting, and storing the openings. Stellar RPC's default retention is seven days, and that number is load-bearing: your commitment stays on-chain forever, but if your wallet loses its local state and the events have aged out of everything you can reach, you can see that your funds exist without being able to reconstruct the opening that spends them. OpenZeppelin's spec is blunt about this — recovery from seed requires a durable event archive, and they publish an indexer specification for exactly that — so wire up infrastructure with the retention you actually need and refresh periodically. Spending is self-healing — every spend forces you to open your balance and generate a proof — so it's the long gaps after your last spend you have to sweep for.

Timing Leaks, Scale, and the Road to Mainnet​

A sharp one from chat: deposits and withdrawals into the wrapper are public, so can't you correlate them? Yes — Alex didn't dodge it; in a small pool with few participants, timing analysis gets easier. These systems benefit from scale: more parties, purposes, and denominations all make correlation harder — an argument for shared deployments serving many customers under the same jurisdictional requirements, not one pool per app.

On observability: the OpenZeppelin demo ships an auditor interface showing all transactions and amounts (deliberately open there; keep it behind custody in real life), but scoped audit requests, monitoring, and selective-disclosure tooling — say, sharing your confidential history with a service so you can do your taxes — are wide-open design space. Nobody is building that platform for you. Hint.

And the shortest question got the most concrete answer: is it coming to mainnet? The contracts are live on testnet now — Alex has vibe-coded basic wallets and a private payroll app against them in about twenty minutes. Audits were days from starting at the time of the call; after remediation comes a stable release. The proving stack is Noir, verified on-chain by an UltraHonk verifier that originated with a community member and is maintained by Nethermind. Alex's main ask: OpenZeppelin is a tooling provider, not an operator. Pick a jurisdiction and a use case and go be the operator — sanction lists, allow/deny lists, compliance hooks — and show everyone what best practice looks like.

Bonus Round: Confidential Agentic Payments​

Someone asked about AI agents, so Jay closed with a design sketch. Stellar already has x402 and machine-payment implementations, and confidential tokens can absolutely make agentic payments private — but not by naive plugging-in. Agent payments are fast, tiny, and many-to-many; you can't settle every one on-chain with five-second finality plus client-side proving. The plausible shape is channel-based: accumulate payments off-chain, then settle batches across multiple agents at once, with a registry of who settled what and a dispute period. Jay called it "some engineering to be done" and left it to the ecosystem. I'll repeat what I said live: builders will ship exactly this at the next hackathon, and it will probably win.

Closing​

Alex's parting note was the right one: this isn't an incremental ease-of-use feature. It's the chance to stop choosing between traditional finance (private but closed) and blockchains (open but exposed) — ideally ending as a plain checkbox in your wallet that says make this transaction private, done compliantly, from mainnet day one. Drop further questions in the developer chat on the Stellar Developers Discord — there's enough unanswered material for a sequel if demand holds. Thanks to Alex and Jay, and I'll see every single one of you next week.

Two Developer Advocates, One Call​

The twist this week: I wasn't the only developer advocate on the stream. Most of SDF was heads-down preparing for Stellar House in Brazil the following week — and if you were in Brazil, you were probably at the Stellar Builder Summit at that very moment. If not, I shouted you out for no reason.

The topic was cross-chain interoperability with CCTP — Circle's Cross-Chain Transfer Protocol — and USDC on Stellar. My guest was Elliot (@elliotfriend just about everywhere — if you can't find him on a platform, type "elliotfriend" into the search bar and be done with it), a senior developer advocate at SDF and genuinely one of the people I've learned the most from since joining. He's been in and around the Stellar ecosystem for six-plus years, having wandered into the Stellar Quest Discord out of curiosity about how the machine actually worked — not to trade altcoins — and never looked back. He built the CCTP demo himself, so I got out of the way and let him drive.

CCTP in One Paragraph​

Some framing before the demo. USDC has been native on Stellar since 2021, so this isn't a story about finally getting the token here — it's about how it gets here. Until recently, moving USDC from Ethereum or Base onto Stellar meant a centralized exchange or a third-party bridge: a human does it out of band while your application sits there waiting for a balance to appear. CCTP turns that into a contract call. Circle is the issuer of USDC, so nothing needs to be locked anywhere: you burn USDC on the source chain, Circle signs an attestation that the burn happened, and you mint the same amount on the destination chain. Same canonical USDC on both sides, and the whole thing is something your code can start and finish on its own. CCTP went live on Stellar this past May.

Elliot's history lesson made the "why" concrete. Cross-chain bridging has traditionally been done two ways: lock-and-mint (lock tokens in a vault on chain A, mint a wrapped representation on chain B — wrapped BTC being the classic) or liquidity pools (deposit real USDC on chain A, withdraw real USDC on chain B). Both approaches end with a giant pile of USDC sitting somewhere, and giant piles attract bad actors. CCTP's version has no pile: the tokens are gone on the source chain, and real, canonical USDC — not a wrapped token, not a pool that can get drained — is minted on the destination.

The Demo: Stellar to Arc​

Elliot's demo app is live at cctp27.vercel.app — named after Stellar's CCTP destination domain, 27 — and the whole thing is open source. He ran it against Arc testnet (Circle's chain, domain 26) because Arc is usually quick, but it works the same with any CCTP-enabled chain; he's wired up the EVM chains and Solana.

First transfer: 5 USDC, Stellar to Arc. The deposit-for-burn invocation on the Stellar side takes a handful of arguments worth knowing:

• Amount — Stellar USDC has seven decimals of precision, so 5 USDC is 50 million stroops. Every other CCTP chain uses six. Why? Per Elliot: "I don't know why, but it is."
• Destination domain — 26 for Arc, 27 for Stellar.
• Mint recipient — the destination address, passed as 32 bytes.
• Burn token — the USDC SAC address.
• Destination caller — leave it all zeros and anybody can call the mint function on the destination chain, making the mint permissionless; set it if you want only the recipient to be able to.
• Max fee and finality threshold — these matter for fast transfers on slower chains. Out of Stellar, standard (threshold 2000) is the only supported mode, because Stellar already reaches finality in seconds. Fast transfers exist for chains like Ethereum and its L2s — and Elliot's favorite, Starknet, which can take four to eight hours to reach finality before you can mint.

Out of the box this is a two-transaction flow on Stellar — an allowance approval on the USDC SAC, then the deposit-for-burn — which bugged Elliot enough that he wrote a wrapper contract that does both in one atomic transaction. He demoed it with a 3.14 USDC transfer, "because I'm a dork." Either way, the rest is the same: wait for Circle's attestation ("Circle's permission slip that the burn actually happened"), confirm the mint in MetaMask, watch the balances update.

The Gotchas: Getting USDC Into Stellar​

Before going the other direction, Elliot flagged the part that will "totally torch your funds if you're not careful." On EVM chains a mint recipient is a 20-byte address; CCTP gives you a 32-byte field. For transfers into Stellar, you cannot just drop your G address (or M, or C address) in there. Circle requires the mint recipient — and the destination caller — to be the CCTP forwarder contract, as the raw 32 bytes underlying its C address (the Stellar SDK will decode those for you).

Your actual destination goes into the hook data, which has a strict layout: 24 zeroed "magic bytes," a version field (currently zero), a length field, and then your G address as a hex-encoded UTF-8 string — the string key itself, not the decoded public key bytes. Get that layout wrong and your funds go somewhere you didn't intend.

The live Arc-to-Stellar run promptly hit Arc testnet's aggressive RPC rate limits, which gave Elliot the chance to show off my favorite feature: resume from burn hash. Paste the transaction hash of an earlier burn, the app fetches Circle's attestation, Freighter pops up, and you approve the mint_and_forward call on the forwarder contract. Five USDC landed back in his Stellar wallet.

Solana, ATAs, and Every Chain's Opinion​

This project was Elliot's first real development against Ethereum and his first Solana transaction ever ("so I'm pretty much an expert on Solana"). Two observations from that tour. First, every ecosystem has its own flavor of contract bindings — the Stellar CLI generates TypeScript or Rust bindings, EVM has ABIs, Solana has IDLs — and they all save you from hand-assembling binary data on the front end. Second, every chain has its own opinion about the 32-byte recipient: EVM addresses are right-aligned and zero-padded; Solana addresses fill all 32 bytes; Stellar wants the forwarder plus hook data.

The Solana catch: your tokens don't live at your wallet address. Every token you hold has an associated token account (ATA) — imagine if each of your Stellar trustlines had its own distinct address you sent payments to — and CCTP transfers to Solana must target the ATA, not the wallet. With that handled, a 12 USDC fast transfer from Solana devnet to Stellar went through cleanly: burn confirmed in Phantom, attestation arrived in seconds, Freighter approved the mint_and_forward carrying the message and attestation from Circle's Iris API.

The closer was Circle's forwarding service. Normally you sign — and pay gas — on both sides of a transfer. Going outbound from Stellar (inbound isn't supported yet), you can have Circle submit the destination transaction and cover the gas: it's a relayer, same idea as OpenZeppelin's relayer service or Launchtube, triggered by putting "CCTP forward" magic bytes in the hook data. Elliot sent 11 USDC from Stellar to Solana and the tokens simply appeared — no popup, no destination gas, minus whatever fees Circle took along the way. Getting this working on Stellar testnet took a week or two of politely bugging Circle support (Stellar as a source chain wasn't being indexed correctly at first), so pour one out for whoever fielded those tickets.

What's Next for the Demo​

Elliot's roadmap: try M-addresses and smart accounts (everything so far has been plain G addresses), add more chains beyond "EVM is pretty much the same from one to the next," extend the wrapper contract to ensure the destination G address has a trustline before invoking the mint on Stellar-bound transfers, and use the forwarding service to create the recipient's ATA on Solana-bound ones — ATAs aren't opt-in like trustlines, they just have to be paid for.

Closing​

Everything — the app, the contracts, even the slide deck (an HTML page Claude put together) — lives in the stellar-cctp-demo repository. Take it, build it, break it, steal it; whatever floats your boat, per the author. A viewer on Twitch asked for the presentation materials, and Elliot's sharing them once refined. Close to 200 of you watched live across YouTube, X, and Twitch. Elliot's parting words: "let your heart guide you." Next week we talk confidential tokens with more SDF folks — see you there.

Stellar Quest Is Back​

Before the guests, some news from the developer ecosystem — starting with a sentence I haven't been able to say for a while: Stellar Quest is live again. If you've been around long enough, you know Stellar Quest was once the most widely shared link between builders in this ecosystem. It's been broken for some time, mostly because third-party services it depended on sunset their operations (including the one that powered the interactive code lessons). That's fixed now — it's live, it's working, and you can use it to get a genuinely hands-on feel for building on Stellar.

Is a click-through learning platform the best use of a developer's time in the post-AI age? That's for you — and for our ambassadors — to decide. What I can say is this: building with AI is insanely easy, and the only thing separating you from AI slop is actually knowing the ecosystem you're building in. You don't have to write the code by hand anymore, but you do have to know what an account is, what a trustline is, what a SEP-41 token is. Stellar Quest is one way to earn that knowledge. Expect a refined version in the coming weeks, shaped by whatever our ambassadors ask for.

On the AI side of the same coin: skills.stellar.org keeps growing. It's our skills website, but it's also your skills website — there's a community section with 17 community skills built by non-SDF people (one of my favorites: a Scout-style skill for researching the ecosystem and SCF before you build), next to 7 official skills, with three more official ones visible in the open-source repo if you go looking. Adding your own is a pull request away — there's an example skill-card entry in the repo showing exactly how to submit. Building on Stellar with AI gets easier every day; Stellar Quest is there when you want to slow down and actually learn.

Guest: Hypertron — Private Payments and Operations for Businesses​

This week's guest was Hypertron (hypertron.space), a programmable operating layer for B2B payments and operations on Stellar — think payments, treasury, and compliance workflows for a business, with privacy as an opt-in layer on top. Sweta and Soumik, the two co-founders, joined from India at 11:47 p.m. their time (self-declared night owls, so it's fine).

Some backstory: the two met in college, ran an agency and freelanced together, and fell into web3 in late 2023 through hackathons — ETHIndia was the first big one. Since then Sweta has worked at a Solana-based company, on early NFT projects on Base, and currently also does security work at Hacken; Soumik has worked for a prediction market on Solana and a payments company. This one was personal for me too: I first met them at a Rise In hackathon in Bangalore about two years ago, on my second day ever in India. I mostly remember the biryanis.

Why Stellar? Their answer was better than the usual one. Stellar targets institutional clients and has always been a public blockchain by design — which they think is the right default. Traditional finance is private by default with auditability on request; public blockchains are transparent by default. Hypertron's whole thesis is to add privacy on top of the public chain, without giving up the verifiability that makes a public chain valuable in the first place. The problem is concrete: once a business runs payroll and vendor payments in stablecoins, anyone — a client, a competitor, a very motivated employee — can trace its treasury. Wallets get poisoned, payments get tracked. That's the gap they're filling.

The Application Layer​

Soumik demoed the product side. There's a sandbox on hypertron.space so you can poke around before connecting anything, and sign-in is gated behind an invite code they shared live on the stream. You connect with a Stellar wallet (Freighter in the demo) and land in a workspace — and you can manage several, one per business. Creating one is a guided onboarding: pick the business type (protocol, DAO, agency, freelancer), and the modules adapt — an agency doing dev work doesn't need heavy compliance tooling, a DAO very much does. You choose the operations you want (payments, treasury, risk reports, compliance), invite teammates, wire in integrations like Slack for transaction notifications or Gmail/Notion/Google Drive for the paperwork around employees and invoices, and set your geography so the risk and compliance reports (delivered daily to Telegram or WhatsApp) actually match your market.

The payments demo was the simple, satisfying kind: create a payment of 10 XLM with a description, get a payment link, open it from a second wallet, pay — settled near-instantly, tracked in the dashboard. XLM and USDC are supported today, with more assets planned. For real integrations there's a developer portal with API keys, docs, and an SDK, plus an MCP in the works so you can wire Hypertron into your app from an AI tool in minutes. To make it tangible, Soumik built a demo app that day: a Pokémon NFT marketplace with Hypertron checkout. Buy an NFT, get redirected to the payment link, pay, and a webhook bounces you back to the marketplace with the NFT already in your account. The stablecoin payment stack and APIs are live now, with the full v1 targeted about two weeks out.

On monetization: honest answer, still being figured out — likely pay-per-use across the smaller features rather than a cut of payments alone. One of those features is bridging: a business already operating on Ethereum, Solana, or Avalanche can move its treasury over to Stellar specifically to use the privacy payments. That's a fun acquisition channel if it works.

The Privacy Stack​

Sweta took the second half, and this is where it gets interesting for protocol nerds. Their framing: privacy isn't a rule, it's a spectrum, and it doesn't start with a circuit — it starts with the question what needs to be hidden. They've built a private-payments evaluation framework around six leakage dimensions: sender, receiver, amount, timing, linkability, and metadata. Confidential tokens, for contrast, hide the amount but leave sender and receiver public. Hypertron's target is linkability — nobody should be able to learn who pays whom — while keeping compliance deliberately open through viewing keys, so an auditor with the right key can still see what regulators need to see. Their privacy matrix today: sender, receiver, amount, and linkability covered; timing still partial (that's a batching-and-delay problem); compliance intentionally left open. In the app it'll surface as an opt-in privacy button on otherwise normal transparent payments.

The architecture, in one breath: proofs are generated locally (the provers never leave your device), a relayer sponsors fees and submits, commitments land as leaves in an on-chain Merkle tree, and nullifiers handle spend-tracking. Four contracts ship the whole thing — commitments, nullifier, verifier, and a transfer contract that orchestrates shielding, sending, and unshielding with a single integration point for the merchant app.

What I liked most is that they're packaging it twice. For protocol builders there are composable Rust crates — Merkle trees, nullifiers, proof verification, disclosure mechanisms — so you can assemble your own privacy design instead of rebuilding from scratch: relayers plus a ZK pool if you care about sender privacy, confidential tokens for payroll, a mixture with auditing for treasury settlements, pooling-batching-delay for anonymous donations. For application builders there's an npm package with a compiled WASM prover, so you generate proofs without ever touching the cryptography. Everything leans on the primitives the protocol now ships natively — the BLS12-381 pairings that landed in Protocol 22 and the Poseidon hashing from January's X-Ray (Protocol 25) upgrade — rather than porting verifier and hashing libraries in. That's also their differentiation pitch against Nethermind's SPP shielded pool: shielded pools go back to Zcash in 2016, and Hypertron's angle is composing the on-protocol primitives instead of shipping a ported stack. When I asked why BLS12-381 over BN254 (the more common choice for shielded pools), the answer was refreshingly honest: not entirely sure yet, the goal is fast verifiable circuits. Pools are per-asset — XLM first, more later.

The CLI demo walked the real flow: query the last indexed Merkle root, compute a Poseidon commitment from secret inputs, run the deposit — commitment on-chain, proof generated and submitted, transaction shielded. Then the private-transfer proof failed on an indexing error, live, in front of 200+ people. As regular viewers know the rule by now: you're not a real builder if your demo works every time.

The Fine Print​

My PSA from the stream, repeated here for the record: Hypertron is a project in development, running on testnet. These things should happen — that's the point of showing them — but it's not a live business yet, so don't route your company's treasury anywhere just yet. The open-sourced v2 of the contracts was days away at recording, and viewers were already asking about integration pricing live on the stream, which is honestly the best kind of validation a pre-launch project can get. Follow them at x.com/hypertron_HQ.

Closing​

X-Ray has been live for about six months now, and privacy on Stellar still fascinates me — we've gone from protocol primitives to confidential tokens to shielded pools, and now to teams like Hypertron trying to be the B2B application layer on top of all of it. A private payments product for businesses is a whole different level of hard, and I'd love to see more projects emerge in this lane. We crossed 250 live viewers by the end — thank you for that. Next week I'm planning a session on the cross-chain interop options available to Stellar builders, plus another guest. See you then.

The Week I Mostly Shut Up​

Probably my favorite Stellar Developers meeting so far, and — unusually for me — I spent most of it not talking. The occasion: introducing Stellar Raven, the unified Stellar-ecosystem MCP gateway. My pitch in one line: the first, last, and only thing you need to build on Stellar — Stellar docs and ecosystem context in one connection. You might think "oh, it's just an MCP." You would be mistaken, and I brought four guests to explain why.

Quick introductions. Bri has been on the ecosystem team at the foundation for about four and a half years and does a lot of the storytelling around what Tyler builds — a job description that now includes Raven. Boxy built Stellar Light and focuses on data indexing: making ecosystem data smart and high-quality enough that Raven keeps getting smarter from it. Ralph wears many hats in the ecosystem but joined as the builder of Lumen Loop (lumenloop.com), a discovery platform for everything happening on Stellar. And Tyler — still a developer advocate director, and together with Bri quietly spinning off a new team inside the foundation to work on exactly this kind of thing. Don't tell anybody.

What Raven Actually Is​

Tyler's framing: the problem Raven solves is context. It's an MCP (Model Context Protocol) server that aims to ensure agents know the truth about Stellar when you ask a question or build something.

The corpus of Stellar truth is scattered, and some of that is structural. We're open source with a very open culture, so a lot of what's true about Stellar lives outside the foundation's control. We run a hackathon on one SDK version, ship a new release two months later, and now SEO is actively working against us: LLMs index a pile of once-true, now-outdated information. Everyone builds off a Blend or Soroswap repo at a hackathon; those repos are static (you can't update deployed contracts), so freshly generated content keeps encoding stale best practices. Recency is a bad signal when the new content was generated off the old standards; scoring what's actually true is genuinely tricky.

Tyler had solved this for himself with a personal deep-research workflow, but "install these ten skills and four MCP servers" is not a shippable product. Raven is that build workflow surfaced as a single service — the fifth version he's tried to build over almost a year, and it only got serious once Lumen Loop and Stellar Light/Scout existed as APIs he could route to. Under the hood, Raven pulls together Lumen Loop, Stellar Light, the Stellar docs, all the Stellar skills, and the Algolia indexes behind the docs and the site, plus general research tools like Parallel and Perplexity in the research pipeline.

The broader thesis: anyone seriously evaluating chains is comparing Stellar against several ecosystems, each with its own sprawl of bespoke skills and MCPs. Nobody maintains all that. If we want people to give Stellar a fair chance with their LLMs, there has to be one tool. That's the niche.

The Sources: Lumen Loop and Stellar Light​

Ralph and Boxy overlap on purpose — two independent sources of ecosystem truth mean you can cross-check what works.

Lumen Loop is content-first and agentically driven: backend agents discover content, attach metadata, generate summaries and embeddings, look up SCF information, occasionally disagree with it and self-correct, and publish the result to an open ecosystem database on GitHub that others (like Boxy) build on. Ralph's favorite party trick lives at labs.lumenloop.com: a constellation view of the entire ecosystem — every piece of content and how it relates to everything else. We've never been able to see that before, and it's just one source behind Raven.

Stellar Light started as a discoverability problem and grew once agents entered the picture. Boxy's current frontier is repo indexing: ingesting thousands of repositories from Electric Capital and other sources and actually trying to understand the code depth inside each one, so questions get answered from real code rather than vibes. It's hard, and token-hungry — Boxy has been hitting model limits doing it.

The shared hope: less time on the boring things. SCF reviews, hackathon judging, hunting for the right link — all of that is exactly the shape of work Raven quickens.

Truth Is a Garden​

The part I found most interesting is how Raven improves itself, because the core issue with LLMs is that they don't know when they're wrong. Give an agent disparate sources and superseded information and it will grab something, hold it confidently, and careen off a cliff in a burning cloud of tokens. MCPs don't fix that. Skills don't fix that. Continuous re-research of truth fixes that — Tyler's metaphor: truth is a garden, not granite. Things go live, die, migrate; somebody has to keep re-indexing and re-scoring. Concretely:

• Golden QA. The team mined Stack Exchange, Discord, and old Stella logs for almost 500 common Stellar questions, then ran long, expensive research against each — Lumen Loop, Stellar Light, the docs, the site, web research — to produce golden answers.
• Evals. Ask Raven the same questions, have a model grade Raven's answer against the golden one, and — the fun part — assign blame. Is a miss a Lumen Loop problem? A Stellar Light problem? Are the docs missing something, or contradicted by a repo?
• The loop. Misses land in an improvements directory and become issues on the right repository, where Ralph's and Boxy's agents pick them up. Telemetry (the whole thing runs on Cloudflare) captures what tools got called and what came back, so agent flows can compare what Raven found against what it should have. Bri pointed out this already works in the other direction too: several issues open on the docs repo right now exist because Raven couldn't answer something correctly from the docs — Raven is making the docs better, not just consuming them.

Two real examples of misses: asked about asset issuers in Latin America, Raven almost never surfaced Etherfuse — apparently they don't describe themselves as an asset issuer anywhere, even though everyone expects to find them under that word. And "where can I swap assets on Stellar" almost never returned Sushi, new on Stellar and competing with a crowd of existing swap services. Both became golden questions; both improved. When you hit something like this, open an issue on the Stellar Raven repo — that's the mechanism.

Tyler's longer-term vision is forward-deployed agents: Raven plus opt-in memory and profiles, so an agent embedded with a partner learns you're always asking about, say, Argentine anchors, and gets more specific over time. You could stand up an agent today, hand it the Raven MCP and your Sentry logs, put it on a loop, and have it PR fee optimizations against your own repo. The pieces exist; they just need packaging.

Q&A: Live Data, Cheap Models, and Where to Run It​

A viewer asked how much you can learn about real-life anchor operations — which turned into the best design discussion of the call: should Raven serve live data? Tyler's answer is no, mostly. Raven is a model context protocol, not a data API. It shouldn't call the RPC for you; it should tell your agent where the RPC docs are, who provides endpoints, and let your model write the code. Same for the recent explosion of data sources: Mercury (just came back, and very cool), stellarindexer.com, Alchemy's new Stellar API, Dune, the data-lake tooling like Galexie. Your agent doesn't know what it doesn't know — but once Raven points it at the right sources, your agent is the best tool for the job. Tyler's analogy, which I intend to steal: "I'm going to borrow your body to use my brain." We're giving the agent the tools, not building it the house.

The same logic answers the hosted demo question. There's a playground on the Raven site, and you should treat it as exactly that: heavily rate-limited, a really cheap reasoning model, capped search/execute turns — Tyler is understandably not exposing hundreds of dollars of frontier-model compute to the open internet. Use it to see which tools get called and get a feel for the answers (we asked it "who is Justin Rice" live, and for a throttled setup it did honestly fine), but the real product is Raven installed in your own IDE or agent, where a frontier model gets far more out of the same context. That's also why there's a sign-in: a standard OAuth MCP login, needed for rate limiting today and the opt-in memory features later.

Other questions from chat, rapid-fire:

• Test suites and security? Raven would be phenomenal at it as the repo indexing matures — find repos that already cover fuzz testing and common error patterns, then plug that into whatever monitors your backend. The follow-on idea everyone liked: index audit reports. Lumen Loop surfaces audits but only as links; the trick is accurate summaries so Raven knows when an audit is relevant, then hands your agent the full source. Same pattern as Raven's planned ephemeral artifacts for oversized responses — just the right context at just the right time.
• Does Raven speak Spanish? Whatever your terminal speaks. The proxied APIs are mostly English semantic search, but your agent translates on both ends.
• Can we make a sassy Raven? Wrap it in your own agent and give it whatever personality you want — one of the crew confessed theirs answers as Princess Donut from Dungeon Crawler Carl. Mine calls me Mr. Kaan. I want professional distance from my agent.
• Is this a Stella replacement? Different animal. Tyler was blunt: Stella was a great experiment and he's glad it died — it made Discord unsearchable, a huge share of prompts were vandalism attempts or non-Stellar questions, and an agent-as-a-service collects PII you then have to worry about. Raven inverts the model: a service that your agent calls, with tool-use-shaped telemetry instead of raw prompts. My addition: Stella existed because models couldn't read our docs properly back then. Frontier models read docs fine now — the scarce thing is dynamic, current ecosystem context, and that's precisely what Raven addresses.

Tangents Worth Keeping​

Building this stuff is not cheap: Tyler estimated around 20 billion tokens in the last couple of weeks alone. That led into a review of token-saving tools — headroom (compresses JSON and log output), caveman (make prose short, why speak much when few word do trick), and ponytail (don't over-engineer; less code when little code does the trick). Verdict: modern models are too smart to be talked to stupidly. Headroom-style compression made them suspicious they were missing something, so they looped and burned more tokens; caveman's brevity triggered extra reasoning to reconstruct the stripped context. Only ponytail earned its keep, and less for token savings than for code quality. If you're going to install one, install that one.

Best mini case study of the call came from Bri, who is building an application with confidential token transfers and used Raven as a research tool: "Alice owns 1,000 USDC, Bob owns 300; Alice deposits 500 into the confidential token wrapper and privately transfers 200 to Bob — walk me through step by step what happens." Raven's answer taught Bri more about confidential transfers than a week of reading. Researching with Raven is as legitimate a use case as building with it — and it's not a one-and-done oracle. Ask, learn a little, redirect, pair it with your other tools.

Closing​

We peaked around 380 live viewers, blew past the hour as usual, and rolled into the protocol discussion half an hour later. Brazilian builders: we'll be at the Stellar Builder Summit in São Paulo — find me there and ask me about Raven. Otherwise, ask on the Discord or tag Tyler (@kalepail), Lumen Loop, Boxy, or Bri on X. Every question makes Raven better.

Also, I publicly demanded Raven swag. A bandana would be sick. Slogan's already written: just ask the Raven. See you next week.

A Week About Privacy​

This week wasn't about AI — it was about your second-favorite subject: privacy. Per the Electric Capital developer report there are now more than 2,000 developers building on Stellar in a given week, and hopefully you're one of them.

Two reasons privacy was the theme. First, there was exactly one day left to submit to the Real World ZK hackathon on DoraHacks — the best possible time to be building with zero knowledge. Second, an hour before the call we published the developer preview of confidential tokens on Stellar, which pairs naturally with this week's guest. So the plan was: guest first, then a plain-English tour of confidential tokens.

Guest: Zarf — Private Token Distribution by Email​

Our guest was Zarf (zarf.to), a Turkish project that lets you distribute tokens to an email address rather than a wallet address. Recipients claim with a familiar "sign in with Google" button, and their browser quietly proves they own that email using a zero-knowledge proof — so the recipient's wallet is never linked to a person, and nothing on-chain says who received what. This was a special one for me personally: Yaman, one of the founders, is the first person I ever met in web3, at my first hackathon a bit over four years ago.

Yaman introduced Zarf alongside Dennis, who has spent three to four years in the ZK space (previously an exploration engineer at O1 Labs on the Mina protocol, and before that in web2 cyber security). The team builds things that are only possible with zero-knowledge proofs, and got excited about Stellar once the protocol gained native, cheap ZK-proof verification — with the heavy elliptic-curve math implemented as protocol-level precompiles, verifying a proof on Stellar became genuinely inexpensive.

The Problem​

When you send tokens on a blockchain, the recipient's wallet is always exposed. In token distributions and private sales, anyone can watch who claimed what — a strong signal for whales-watching and an easy way to get doxxed. Zarf's origin was a hackathon project at Devconnect in Buenos Aires: a proof-of-attendance tool that let you prove you'd attended an event via an email you received, then mint it as a POAP-style NFT. That grew into the more general idea of using an identity you already have — a Google account — for private, programmable token distributions.

How It Works​

The primitive underneath Zarf is ZK JWT — zero-knowledge proofs over the JSON Web Token that Google signs when you log in. When you sign in with Google, Google digitally signs your JWT; inside the circuit, Zarf verifies that signature against Google's published public keys, confirms the key really belongs to Google, and parses your email — all in zero knowledge. That proof then lets you claim from any wallet you like, and different claims can come from totally unlinked wallets (wallet A for one batch, wallet B for the next), even a single-use stealth address.

Dennis was careful to distinguish ZK JWT from ZK email: ZK email proves the signature of an email's sender, while ZK JWT is specifically for authentication and identity. They prefer ZK JWT because the UX is far better — no forwarding emails or uploading .eml files; you just open the page and log in with Google, and the proof is generated behind the scenes.

The best framing we landed on: Zarf is a privacy-focused version of the Stellar disbursement platform — instead of handing over a CSV of wallet addresses, you hand over emails, and people claim from whatever wallet they want, so nobody can track balances or link an identity to a wallet.

The Architecture​

A few implementation details worth capturing:

• Proof system. Zarf uses Noir rather than Circom. Noir brings faster proof generation and, importantly, no per-circuit trusted setup ceremony (it relies on a universal setup instead).
• Four contracts. A factory, a vesting contract, a verifier contract (invoked on every claim to check the proof), and a JWK registry that holds Google's public keys.
• The Google key-rotation challenge. Google rotates the public keys that sign JWTs roughly every two weeks (not exactly, and not all at once). Zarf runs a Cloudflare worker that fetches the current keys and writes them on-chain so verification stays valid. This is the biggest open problem; the team is exploring more trustless approaches (e.g. zkTLS to prove the certificate URL directly) and even offering a shared Google-certificate registry as a public good for the whole ecosystem.
• The privacy model. To break the email↔wallet link, Zarf parses your email from the JWT, generates a secret pin code, hashes the pin, hashes your email, and places the hashed identity in a Merkle tree. At claim time the circuit verifies the Google-signed JWT, derives your unique identifier, walks the Merkle proof to the root, and compares that root against the distributor's on-chain vesting contract. The pin prevents anyone who merely knows your email from brute-forcing to find you in the tree.

The Demo​

Yaman created a live token distribution on testnet — upload an email list, auto-build the Merkle tree, set a vesting schedule, deploy — then tried to claim. Proof generation and some caching got in the way and the claim didn't land cleanly on the call (it had worked in rehearsal). As I like to say: you're not really a builder if your demo works every time. It's a fine reminder of exactly why beta testers matter — better to get roasted in private than in front of 250 live viewers. Zarf is SCF cohort 42, heading to mainnet after its audit (likely within the week), and looking for beta testers via zarf.to and X (@zarf).

Confidential Tokens: The Other Half of Privacy​

After the guests left, I did a "so what?" walkthrough of the confidential token rails we previewed that day, built by OpenZeppelin — because Zarf and confidential tokens solve two different privacy problems and it's worth seeing the contrast:

• Zarf hides identity. The email↔wallet link is never revealed. But once a claim lands, the recipient's wallet, the amount, and the claim event are all still public on-chain — fine in many cases, problematic in others.
• Confidential tokens hide amounts. Instead of storing a plaintext balance, the token stores each balance as an encrypted commitment. Transfers move encrypted amounts and carry a zero-knowledge proof that the transfer is valid (the sender had enough, the amount is a positive integer, inputs equal outputs) without revealing any of the amounts. Only the holder — and optionally an auditor who holds a decryption key — can read the balance, which is how you'd add a compliance layer.

The mental model is a handful of methods: register, deposit, merge, transfer, withdraw. To participate at all you first register (a one-time zero-knowledge proof generated locally in the browser). You then deposit public tokens into your encrypted balance, merge received amounts so they become spendable, and transfer confidentially. Confidential tokens behave like SEP-41 tokens, so in theory they compose — but they're best at additive accounting (adding and subtracting amounts), and not the right tool for multiplication, price discovery, or deep public composability, where time-sensitive proof generation gets in the way. This is a confidential token, not a dark pool that hides the operation itself.

To make it concrete I vibe-coded a tiny confidential wallet for the meeting — two accounts, Alice and Bob — that walks through registering, depositing public XLM into an encrypted balance, merging, and then transferring confidentially so nobody can see how much moved. It reuses OpenZeppelin's confidential-token contract from the developer preview, so I was cutting corners, but it makes the flow tangible. The GitHub link is in the stream, and the real source of truth is the developer preview itself.

Closing​

With ~20 hours left on the Real World ZK hackathon deadline and a strong turnout of hackers, there was still time to ship something small and submit. Next week's guest is Hyperron. Thanks for watching — see you then.

Another Doozy of a Week​

Before the guests, a quick bit of ecosystem context for why this week felt busy. Per the on-chain data, Stellar's RWA market cap just crossed $3 billion — you can see it for yourself on the Dune dashboards. And the ideal Stellar developer meeting, in my book, is one with as many guests as possible, because the conversation I keep having with projects is that they want a real way into the ecosystem. Contributing is one way; introducing yourself on this call is another. This week we had two guests and, with a bit of luck, a new viewer record.

We also had four days left to submit to the Real World ZK hackathon on DoraHacks — more on that from our second guest below.

Guest: Gaian — Stablecoin Rails for Southeast Asia​

Our first guest was Gaian (gaian.network), a stablecoin payment infrastructure for the APAC region. In one sentence: it's an API that connects crypto wallets to local banking rails using USDC on Stellar, moving value between stablecoins and local currencies like the Vietnamese dong to power merchant payments, on/off ramps, and cross-border transfers that settle straight into real bank accounts. Imagine paying for a coffee in Hanoi straight from your Freighter, Albedo, or Beans wallet — that's the promise. Kelvin walked us through it live from Vietnam (at 1 a.m. his time).

Gaian isn't new — the team has been at it for over a year and pivoted twice; what they demoed is the v2 of the API. They're live across APAC (Vietnam, the Philippines, part of Thailand) plus Brazil and Peru, and in Vietnam and the Philippines they operate as the anchor themselves, working directly with the top banks.

How the Flow Works​

There are several actors but only one payment. A consumer holding USDC talks to a wallet; the wallet talks to the Gaian API; Gaian uses the blockchain as the settlement layer and a partner PSP in the destination country to land fiat in the merchant's bank account. Crucially, the merchant sees no blockchain at all — they just receive fiat.

Authentication​

The v2 API authenticates every request with an HMAC signature. You get an API key and secret from the self-service dashboard, build a canonical message out of the timestamp, method, path, query, and body, HMAC it with your secret, and base64-encode the result. Every request must carry that signature and timestamp.

The Order Lifecycle​

There are two halves — onboarding a user, then placing an order:

1. Onboarding. Create a user (POST /v2/users), associate a wallet address to that user (the address is just a string — the wallet provider controls it), then generate a KYC URL for the user (providers vary by country) and poll their status by ID or wallet address until it's approved.
2. Payment. Ask Gaian for a code by passing the scanned QR string, the fiat amount, and the user's wallet address. Gaian returns a code ID, the fiat amount, the total (including the bank's processing fee), the exchange rate, and the decoded bank details. Then place the order with that code ID — Gaian returns an order ID, a status label, the settlement wallet address, and the token address (USDC today). The wallet signs and broadcasts the USDC transfer to the settlement wallet (not an API call), and finally notifies Gaian with the transaction hash so Gaian can verify it on-chain and mark the order settled (there's no automatic chain listener yet). There's also a prefund flow where a wallet pre-funds stablecoin with Gaian.

The Demo​

Kelvin ran the whole thing live from a Bruno collection and a demo wallet, paying ~21,000 VND (under a dollar, with a small minimum bank fee) to a real Vietnamese bank account. The first code expired mid-explanation — a hazard of a good demo — and re-verifying settled it. The real headline: the self-service dashboard means any viewer can sign up, grab API keys, and integrate Gaian's payment capability into their own wallet without ever talking to sales, up to a ~$4,000 cap before KYB is required.

Gaian went live on Stellar the previous Friday, and for now it's mainnet-only — going fast to production rather than testnet-first. The one thing I asked for repeatedly (and will keep pestering them about) is a self-service sandbox on testnet, so we can amplify Gaian as an anchor to builders across the Philippines and Vietnam.

The Real World ZK Hackathon​

Our second guest was Jeremy (also known as J Romero), the ecosystem partner running the Real World ZK hackathon on DoraHacks. The scope is deliberately wide open: anything that touches zero knowledge on Stellar qualifies — privacy pools, private payments, confidential tokens, verifiable computation, even ZK games.

The news he dropped live: for the first time ever, they extended the deadline by about a week, so it lands just before the US holiday (giving builders more time and keeping judging off the judges' holiday plates). The prize pool is $10,000 in XLM across five places ($5,000 for first down to $750 for fifth), plus a random $100 in XLM for someone who fills out the feedback survey. Requirements are light — an open-source repo and a short demo video.

Everything runs on DoraHacks (search "Stellar"), but the real hub is the dedicated Telegram group (1,000+ people), where ecosystem ZK teams — Nethermind, Boundless, OpenZeppelin, Aztec — hang out to help. A prolific builder who's won three prior Stellar hackathons (including the ZK Gaming one) is helping as a mentor this round. There's also a resources tab on the hackathon page you can point your AI at, and office hours were being scheduled. Jeremy's parting advice: don't let AI name your project (three teams showed up with identical AI-generated names), and build the thing you're passionate about — Stellar has always been about local builders shipping local solutions.

Closing​

I also gave a shout to the Pulso hackathon in São Paulo (on DoraHacks), whose prize includes a fully sponsored trip to the Stellar Summit, with live pitches across Argentina, Brazil, and Colombia. I'd planned to close with a live stellar-build session — using the Justin and Nicole personas to show off the new self-running loop and spin up a ZK project idea — but at 75 minutes and seven cups of coffee deep, I saved it for next week. Next week we also have another guest, so please be there.

A Doozy of a Week​

This week was a doozy — not just one exciting guest, but a pile of news and a stack of tools to use and maybe break. Before the guest, a quick ecosystem roundup. The big one: v16 of the JavaScript SDK is live. If you're building on the JS SDK, upgrade your codebase and read the release notes to see what changed. Ask in the Stellar Developers Discord if anything trips you up.

Two more things worth your time. Our Real World ZK hackathon with onlyhacks is still running — 11 days left to submit, $10,000 in prizes. The brief is simple: build anything that uses zero knowledge and runs on Stellar — privacy pools, private payments, confidential tokens, identity and compliance proofs, provable computation, verifiable data. If it's ZK and it's on Stellar, it counts.

And if your team is closer to launch, SDF and CV Labs have opened the Stellar CV Labs Accelerator — SDF's first EMEA-focused program. It's a 12-week remote-first accelerator with a two-week in-person boot camp in Cape Town, supporting 10 early-stage startups across DeFi, payments, and RWA in the ME region. Selected teams get technical support, tokenomics advisory, go-to-market guidance, mentor 1:1s, ecosystem perks, and up to $150,000 in XLM in initial development funding from SDF. Post-program, top teams are eligible for additional SDF grants and a joint IC review with CVVC's fund — up to another $150k per team for the top two. Applications are open until July 3rd.

For context on why any of this matters: per the Electric Capital developer report, close to 1,800 builders shipped on Stellar this week, and we had nearly 150 builders live on the call when we started (peaking past 470 by the end). There's a synergy here, and I hope you can feel it too.

Guest: XCCY — A Fixed-Rate Engine for DeFi​

This week's guest was XCCY (short for cross-currency swaps) — an on-chain interest rate engine that's integrating to Stellar. The pitch: lock in a fixed yield on stablecoins, borrow at a fixed rate for a known period, and hedge variable interest rates instead of guessing where yields will go. Their current platform already shows around $1M in liquidity and roughly $2M in 24-hour volume.

Dennis (co-founder and CEO; background in math/CS, several DeFi protocols, and HFT trading) and Dmitri (CPO; a TradFi derivatives background) walked us through it. XCCY was accepted into SCF's 41st cohort, is deployed on EVM mainnets today, and started building on Stellar two weeks ago.

The Problem​

There's a huge amount of unhedged floating-rate exposure across DeFi. In TradFi this is solved with an interest rate swap — a derivative that lets you exchange a fixed, predefined rate for a floating rate tied to some source (Fed funds rate, or in DeFi a lending market's borrow/lend rate). XCCY brings that primitive on-chain, leaning into an RWA-looping narrative and fixed rates on Stellar — natural given the depth of RWAs and lending markets like Blend and YieldBlox on the network.

Three Primitives​

Dennis demoed the platform (live, on Stellar testnet, network errors and all) and the math behind it:

1. Oracle Hub — XCCY uses two oracle types. Reflector (5-minute candles) for collateral pricing, and RedStone for some assets like RWAs. For rates they derive APR oracles by applying exponentially weighted moving average smoothing — because lending-market rates only update on trades, so without smoothing the rate can sit unchanged for long stretches.
2. vIMM (virtual IMM) — an AMM-style engine, close to Uniswap v3 with liquidity ticks, but instead of trading token-vs-token it trades a fixed rate against a variable rate tied to an underlying (e.g. a Blend rate). Pools issue fixed tokens (representing a fixed ~1% APR factor) and variable tokens (whose growth tracks the underlying). It's a zero-sum game — the sum of LP and taker tokens is always zero, so when one side loses on a rate change, the counterparty earns it.
3. Collateral Engine — handles LTVs, liquidation bands, and stages. Stable-vs-stable isolated pools can run very high LTV (~99%); portfolio exposure with volatile collateral needs more buffer. Crucially, because an interest rate swap's P&L is driven by accrued value over time rather than instantaneous price spikes, the engine can support high leverage for shorter tenors using dynamic upper/lower "worst-case" bounds — more collateral for longer maturities, less for closer ones. Settlement happens automatically at maturity, much like options.

What's Next for XCCY​

Mainnet is several months out, gated mostly on audits given the complexity, with the Stellar testnet and SDK landing in a few weeks. The API already exists and is being ported to Stellar this month — and they explicitly want to adapt it for AI agents, so a strategy can be wired up with "one prompt or one skill." Cross-chain arbitrage across their existing EVM pools is on the roadmap too. Reach them on the Stellar Discord, Telegram, or X.

It's a fitting guest for where Stellar is: nearly $3 billion in RWAs on the network today, and teams like XCCY are coming precisely because of the institutional and real-world-asset depth.

stellar-build: Your Whole Dev Journey in One Command​

The AI half of the meeting was a walkthrough of stellar-build (stellar.new) — the tool the DevRel team shipped last Friday and used at the Istanbul hackathon. It's a one-command installer that drops 42 skills plus curated data on 700+ projects built on Stellar and 9,000 projects from Electric Capital's developer reports into your setup. Since Friday it's been installed about 101 times.

The idea: answer almost every question a builder would otherwise ask a mentor during a hackathon — is this a good idea, has it been done on Stellar, can it be done on Stellar, who are my competitors — not just "how do I implement X." It's built on the BMAD method, so it's a hands-on, orchestrated journey rather than a one-shot app generator. You're the orchestrator; the AI personas and their data do the legwork while you say yes, no, or maybe.

Those personas are the DevRel team rendered as agents: Justin (analyst), Bri (tech writer), Nicole (PM), Kaan (UX), Tyler (architect), and Elliot (senior dev) — spanning the idea, planning, solutioning, implementation, and launch phases. There's a party mode that brings everyone into the room at once, and a stellar-help router that re-orients you whenever you forget where you are.

Live Demo​

I drove it live for the ZK hackathon. Asked Justin what to build; he pulled my prior context (via the mnemon memory plugin), then loaded the competitive-landscape skill and went treasure hunting through both the curated catalog and the Electric Capital dump. He surfaced real neighbors — Zarf Protocol (an SCF 42 privacy-preserving token distribution with ZK private claims), Sora Drop (an open-source but non-private airdrop tool, ~$48k from SCF 28), and a stealth team porting the same primitive — making the point that the Merkle-claim mechanic is already being commoditized, so the opening is a sharp, specific application rather than yet another ZK toolkit.

From there we routed into a PR FAQ validation (working-backwards stress test) with Justin, then pulled in Tyler to sketch the architecture with full context handed off cleanly — issuer contract, circuit spec, storage layout, interface signatures. Every persona ends its turn with concrete next steps, which matters: even the human versions of these people aren't always in the room.

That's stellar-build — the entire DevRel team as agents on your screen. Grab it for this week's Real World ZK hackathon on DoraHacks, and I'll see you next week.

Back After a Week​

We skipped a week — the DevRel team was in Istanbul for the hackathon we threw during Istanbul Blockchain Week, and the side event at the end gathered more than 400 people. This week we're back, and the guests are Paul and David from Sodax. You may know them from Balanced or Hana Wallet; they're some of the OGs, and they walked us through what Sodax is and why a Stellar builder should care. The plan was to close with a new AI package from our side, but the Sodax half earned its time, so that one slid to next week.

Sodax: Cross-Network Liquidity as Developer Tooling​

Sodax is a cross-network execution and liquidity system — an intent-based one — and the framing David led with is that it's essential developer tooling, not a destination app. If you're building on Stellar and you want to open your front door to users who hold assets on other networks, you normally have to build bridges, source liquidity, and maintain infrastructure. Sodax does that part so you don't: you stay on Stellar, build the way you want, and reach users elsewhere through a single developer SDK.

The liquidity piece is the part that's easy to underrate. It isn't only cross-network connectivity — Sodax has already sourced the liquidity, so the cross-network swaps and DeFi actions actually settle. As a developer you stop worrying about where the depth comes from.

From ICON to Sodax​

Paul gave the origin story, and it's a good one. The Sodax brand is new — early 2025 — but the team isn't. Before Sodax they were ICON (the ICX token), a layer-1 from the ICO era with an interoperability vision that was years ahead of its time. Over time the lesson landed: to do intent-based, liquidity-powered interoperability you don't actually need to run your own blockchain. So they spun the L1 down, put their logic hub on Sonic (a fast, sub-second-finality EVM chain), and built the smart contracts out across Stellar, Solana, Sui, and more — deliberately spanning EVM and non-EVM networks to open routes other systems treat as impossible.

Balanced (once the number-one DEX on ICON) and Hana Wallet (formerly the ICON wallet, now a self-custodial multi-network wallet on mobile and desktop) both come from those same ICON roots and are now powered by Sodax under the hood. Both went through Stellar's SCF program — they pitched at Meridian in London two years ago and Hana again at Meridian Brazil last year.

The Spoke-Chain Model​

In the Sodax model, Stellar is a spoke chain — which means everything in the Sodax docs applies to and for Stellar builders. The count keeps climbing, but they're on roughly 20 networks now, and they recently plugged in native Bitcoin, which they're rightly proud of. Some of the more exotic spokes are Near, Stacks (a Bitcoin L2), and Injective (Cosmos).

The asset model is worth understanding. When you swap into "BTC" on Stellar through Sodax, you get a soda variant — a trading- and liquidity-backed Sodax representation of Bitcoin that lives on Stellar but is plugged into real Bitcoin liquidity on the Bitcoin network. The solver sees native-asset liquidity across all 20 networks at once and reasons across all of it when a trade fires, so there's depth without anyone provisioning pools — and you can withdraw straight back out to a native Bitcoin wallet. If you've used something like Near Intents, the UX will feel familiar.

Three Lines to a Cross-Network Swap​

Paul's honest line was that the demo is hard to make sound impressive because the SDK abstracts so much away. Integration is three steps:

1. Quote — ask for the price of the swap you want.
2. Swap — do it. One line.
3. Status — poll for not started, solved, or failed.

If a swap fails, the recovery system automatically returns funds — even if they'd already left the wallet. There's also a built-in wallet-connection component (wrap it around your frontend, stack the providers, done), which matters when you're juggling 20 networks, and Stellar trustlines are handled inside the SDK. npm install the SDK (or pnpm add it) and that's most of what you need to ship a real cross-network app.

Earn, and a Bit of Alpha​

Beyond swaps, the SDK exposes a cross-network money market — your end users can deposit, borrow, and earn supply interest. David dropped a bit of alpha too: leveraged staking yield is coming, so things like native ETH or native Solana staking would become accessible to your users even if your app lives entirely on Stellar or some other unrelated network.

Built for Agents​

This is the part that fit the room. Sodax shipped a best-in-class builder MCP server (builders.sodax.com) — plug it into Claude or your cursor agent and it levels your agent up into a "prime Sodax developer." You don't need a docs-indexer like Context7; the MCP is the docs. Even before you commit to building with Sodax, you can point the builder MCP at your existing Stellar repo and have it assess, in about ten minutes, where Sodax could open up cross-network opportunity for you. On top of that, they've embedded agent skills directly inside the SDK, so even if you never wire up the MCP, an agent crawling the package runs into the skills and uses the swap/lend/borrow modules correctly — in their words, "so that even Sonnet 4.6 doesn't make mistakes."

I can vouch for that last claim. The morning of the meeting I didn't even use the MCP — I pointed Sonnet 4.6 (not the strongest model) at docs.sodax.com with roughly "surprise me," and about thirty minutes and 20% of a Pro plan later I had a one-shot mainnet demo: assets, addresses, cross-chain swaps, bridge limits, every supported chain. The question stopped being can you vibe-code something on Sodax and became why not.

The Fee Model​

Sodax takes a flat 0.1% on swaps — the same shape as a Uniswap-style backend fee. The interesting part for builders: any partner integrating the SDK can set their own partner fee on top. A wallet like Hana, or your own app, can add (say) 0.5% and keep it. You have full control over what you charge your users, which means an integrator can end up earning more per swap than Sodax itself.

Why Mainnet Only​

A recurring audience question: does it support testnet? Short answer, no — and the reason is structural. The solver sources real liquidity from real markets, and there's no monetary value backing assets on testnet, so the solver simply has nothing to solve. Replicating it would mean standing up and maintaining dozens of testnet liquidity pools, bridges, and staking platforms in parallel. They're open to bringing parts of the stack to testnet and want to hear from developers about which parts would actually help — but for now Sodax is a mainnet product, which is also fine, because you're not deploying your own contracts. It's a plug you put into your app and it works.

Where to go next: docs.sodax.com for the SDK, builders.sodax.com for the MCP, and sodax.com/partners to see how the integration and fee split work. Their whole team hangs out in Discord and answers builder questions directly.

Next Week​

I ran out of time to show the AI package we built, so set a reminder. Next week's is the one I've been most excited about: the tool the SDF DevRel team shipped that drops 42 skills and hooks into your setup, packs in information about every project ever built on Stellar for market research, and wraps the whole thing in an Agile workflow. It needs a full half-hour to do it justice. See you then.

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-59, 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.

A Packed Two-Part Meeting​

This week's meeting splits cleanly in half. The first half belongs to Renat — a builder in our community working out of Estonia — presenting a draft SEP for zero-knowledge group membership state on Soroban. The second half is mine: an introduction to open-source, free, locally-runnable orchestration layers for AI-assisted development. If ZK isn't your thing, stick around for the second half. If running fleets of agents isn't your thing, the first half is the better one for you.

Renat is upfront about the framing: he's a builder, not a mathematician. The work he's presenting isn't a new cryptographic result — it's the integration story of getting Stellar's ZK primitives (shipped in Protocol 22 and Protocol 25) to compose into something useful, and then sharing what works, what doesn't, and what's still unsolved.

The Problem: Group State Without Metadata​

The naive way to put a group on-chain is to store a list of addresses. That works, and it's terrible for privacy — anyone who reads the contract storage knows who is in the group, who is an admin, and what the governance rules are.

The use cases Renat is targeting all want the opposite shape: a messenger that hides which group a user belongs to, DAO credentials that prove "I'm a member" without revealing who I am, governance contracts that enforce rules without leaking the rule structure (is this a democracy, a tyranny, a one-on-one?). The problem is "prove membership and authority without revealing identity," which is the classic zero-knowledge setting.

Three Iterations: Groth16 → PLONK → Post-Quantum​

Renat walked through the iteration history:

Groth16 was the starting point. It worked, but supporting governance rules over a hidden group required contributing randomness via a trusted-setup ceremony. The standard reassurance — "you only need one honest contributor out of fifty" — is mathematically fine, and the Ethereum KZG ceremony had ~141,000 contributors as proof-by-example, but the operational burden of running a credible ceremony at a small-project scale didn't fit.

PLONK was the second iteration, chosen explicitly to dodge the trusted-setup ceremony. This is what's currently live on testnet, and it owes its existence to the Soroban primitives shipped in Protocols 22 and 25. The contract interface is small: update the Merkle tree, verify membership, create group — with the proof transported separately from identity. A postmortem about getting the proof from client to contract is part of the package; that turned out to be the part of the work that bit the hardest.

Post-Quantum (no ceremony at all) is the direction Renat wants to take this next. It's currently blocked on memory consumption inside the Soroban environment — not CPU, which was his initial guess, but memory. The Stellar developers helped him diagnose this. Cost is also a factor at the post-quantum end — somewhere north of 16 cents per update versus less than a cent for the PLONK path.

Cost, Limits, and the Open Payer Problem​

The PLONK version is cheap. State updates cost less than a cent, and the actual messages in the messenger reference implementation are free. That's a usable cost envelope for a real product.

The limits worth knowing:

• PLONK is bounded by K max 2 in the current configuration — meaning "democracy" in the governance taxonomy doesn't scale to large groups yet. Two voters max per vote at the current parameters.
• TTL and contract capacity need to be designed into any SEP draft. They don't disqualify the approach, but they aren't free parameters either.
• The payer/anonymous-user interface is the most interesting open problem: somewhere in the flow, gas needs to come from somewhere, and "the anonymous member pays" leaks information unless handled carefully. This is the surface point of contact between the fee-paying entity and the privacy-preserving member, and there's no good answer in the current draft.

The code is MIT-licensed and reproducible — the runs are public, the reference messenger implementation is published, and Renat is explicit that what's shown is reference-quality, not production-ready.

What Renat Is Looking For​

This part is the actual call to action: Renat is looking for a SEP champion in the developer community. Someone who can read the draft, push it through the ecosystem-proposal process, and validate that the work is useful beyond his own messenger project.

If that sounds like you, his Discord handle is pinned in the meeting comments, and his email and GitHub are reachable from the reference implementation's README. He's open to "this works" feedback, "this doesn't work" feedback, and — the most useful kind — "this works but here's the obstacle you missed." He's planning to attend Meridian 2026 in Lisbon this October, so the champion conversation can also happen in person.

The Orchestrator Shift​

The pivot of the second half: if you've been building on Stellar for any length of time, you're using AI. Pretending otherwise is silly. The interesting question is what kind of AI use you're doing.

There are two roles to recognize. The earlier role — the facilitator — is what most of us got used to between November 2022 and roughly the end of 2024: you write what you think, you write what you want, you guide the model through the build, and you stay close to the work. Cursor Composer, Sonnet 4, GPT-o3 — all of these reward facilitation.

The newer role — the orchestrator — is what Opus 4.7, Composer 2, the Claude Agents SDK, and the autonomous-agent stacks (Hermes, Open Claw, custom-built agents) are designed for. You're no longer the one writing prompts to a single model; you're managing a fleet, and your job is to keep that fleet aimed at a useful outcome. That's a different skill, and the tools for that role are still finding their shape.

The three tools in the second half of this meeting are all attempts at giving the orchestrator a control plane.

Cline Kanban​

Cline Kanban — free, open-source, runs locally — is the lightest of the three. It's a Kanban board for agent work, built on top of Cline (the open-source coding agent that ships an SDK, a CLI, and a VS Code extension of its own). You drop into a project directory, run kanban, and a local web UI comes up. The board can attach to any of the major agents — Cline itself, Claude Code, Codex, Factory Droid, Kiro, Hermes — and you use it to define tasks, set dependencies between them, and drag work through To Do → In Progress → Review → Done.

The demo: a fresh directory called x402-contest-demo, a one-line ask to "create an exploratory x402 demo on Stellar," and the Kanban agent decomposed it into five linked tasks. From that point on, the orchestrator's job is to review each completed task, decide whether to merge to main, and unblock the next one in the chain. The board offers auto-commit, open-PR, and "leave on branch" flows; while you're getting a feel for an agent's output quality, "ask for approval at each step" is the right default.

The shape of this tool: best when the underlying work is coding and you want a lightweight layer on top of one or more agents to keep tasks orderly and dependencies explicit.

Paperclip: A Control Plane for AI Labor​

Paperclip takes the orchestrator framing one step further. Where Cline Kanban treats your project as a repo, Paperclip treats it as a company. You onboard with npx paperclip-ai onboard --yes, name the company, give it a mission, hire your first agent (the CEO by default), and from there you're the board.

The demo company was "Paper Excel" — Dunder Mifflin in spirit — with the goal "to be the best paper company in the world with the best-looking UI." The CEO went to work hiring the first team: CTO, CMO, UX designer, research lead, intern. Each role has its own starter prompt, its own heartbeat interval, and its own assigned skill set. The dashboard tracks issues, an organizational chart, an inbox for the board (i.e., you) to receive agent emails, and routines for recurring work. The agent backends are pluggable: Claude Code, Codex, OpenRouter, Gemini CLI, Hermes Agent, Open Claw.

Two practical notes:

• It is not a magic productivity multiplier. It's a coordination layer for running multiple agents — most of the agents in the demo were slacking on their first day, and roughly half the issues failed on first run with API errors. This is alpha-quality at the experience level, even where the underlying agent capabilities are strong.
• It will burn through tokens fast. Bring-your-own-API-key with per-agent spending caps is the right way to experiment. The demo ran on a Claude Code subscription and was probably $50–100 of usage in 30 minutes. For exploratory work, point it at a free model on OpenRouter — output quality is worse, but cost is bounded.

The shape of this tool: best when the work is broader than coding — a research-and-marketing-and-content-and-product company-shaped problem — and you want to see what "running a small AI org" actually feels like before staffing one in real life.

BMAD Method (Saved for Next Week)​

The third tool is the BMAD method — this week's favorite, and the one I most wanted to demo. The meeting ran long (the first half earned its time), and BMAD is worth a real walkthrough rather than five rushed minutes. Tune in next week for that one.

The one-sentence pitch: BMAD is for builders who want an Agile development flow with their agents, and for builders who want a thoughtful brainstorming partner that's read more about the problem space than they have. If either of those describes your current bottleneck, the deferred demo will be the one to catch.

Where This Is Going​

Two takeaways:

The move from facilitator to orchestrator isn't a tooling upgrade — it's a skill change. The tools shown today are the early shape of what that change looks like: local-first, agent-agnostic, opinionated about how you compose work. They're not finished. They will get better.

And: if you have time before next week, read Renat's draft and the reference implementation. A SEP that lets Soroban hold private group state cheaply is exactly the kind of primitive that quietly unlocks an entire category of applications later. The champion role is open.

Machine Payments Protocol: A Deep Dive​

This week's meeting is a hands-on walkthrough of the Machine Payments Protocol (MPP) on Stellar — what it is, when to reach for it, and the specific moment in your code where an operation becomes an MPP operation. The goal is to answer one question by the end: "So what? Why should I care about MPP?"

MPP is the second of the two agentic-payment primitives covered in recent meetings. The first, x402, is the more familiar of the two — it's effectively a programmable paywall built on top of the long-standing HTTP 402 Payment Required status. A human or an agent hits a route, gets a 402, pays, and is allowed through. MPP is the less obvious sibling, and the value proposition only becomes clear once you understand its two modes.

Charge Mode vs. Channel Mode​

MPP has two payment modes, and the distinction is the entire point of the protocol.

Charge mode is pay-per-request. A route returns a payment challenge, the caller pays for that single request, and the receipt unlocks the response. If you've worked with x402, charge mode will feel almost identical — it is the right choice when requests are infrequent or the underlying data isn't changing rapidly. One call, one transaction, one receipt.

Channel mode is where MPP earns its keep. Imagine you're charging for access to a premium LLM that emits 50 tokens per second, and the underlying cost model is per-token rather than per-request. Pay-per-request breaks down immediately: you'd need the user to send a transaction every 1/50th of a second, which is impossible. Channel mode solves this by letting the user open a funded channel up front, spend against it at high frequency, and then settle in a single on-chain transaction when the channel closes. The channel can be closed manually (a button, an explicit "end session") or by a timeout — a timeout is usually the better default, because a user closing their laptop doesn't close the channel for them.

The mental model: charge mode is a turnstile; channel mode is a bar tab. Both are useful, and a single tool can expose both — pick the mode that matches the cost shape of the underlying operation.

The Receipt Flow​

The channel-mode handshake is worth internalizing because it's where most of the "wait, how does this work?" questions come from:

1. The client calls the MCP tool. The server returns 402 Payment Required with a channel challenge.
2. The client opens a channel against the server. The client's wallet receives a receipt for that channel.
3. The client retries the call, this time presenting the receipt. The server returns 200 and serves the response.
4. Subsequent high-frequency calls reuse the open channel — no new transaction per call.
5. When the channel closes (button, timeout, or explicit end-session), a single settlement transaction lands on-chain.

Charge mode collapses steps 2–5 into a single pay-and-go interaction — you pay, you get the receipt, you make the call, done.

Demo Walkthrough​

The full demo is on GitHub and the code is meant to be read alongside this video — it is intentionally not production-ready. The demo is an MCP server with four tools:

• get_network_status — free, returns testnet liveness.
• lookup_account — free, fetches live XLM balance for an account.
• analyze_account_risk — paid, demonstrates charge mode.
• explain_latest_transactions — paid, demonstrates channel mode.

The free tools work the way you'd expect — 200 OK, no payment required. They're effectively the free trial of the MCP.

Calling analyze_account_risk without paying returns 402 Payment Required with a charge-mode challenge: "100 base units to use this tool." Paying via the Run Selected Tool button produces a receipt, the call retries, and the server returns 200 with the result. Mode shown in the receipt: charge. One request, one transaction.

Calling explain_latest_transactions after activating a channel session uses channel mode. The first call against an inactive channel returns 402; opening the channel and retrying returns 200, and subsequent calls against the same open channel don't require new transactions. The demo includes an explicit Close Channel button for clarity — in production you'd almost certainly use a timeout instead, so a user walking away doesn't leave a channel hanging open.

The Wallet Setup​

The demo uses four wallet roles, and the setup is worth calling out:

• Buyer wallet — the end user paying for tool access.
• Seller wallet — the MCP operator receiving payment.
• Fee payer wallet — sponsors gas fees via OpenZeppelin's relayer. Not required for MPP to work, but heavily recommended for UX. In 2026 there's very little excuse to make users hold the native asset just to interact with your tool, and fee sponsorship is the cleanest way to remove that friction.
• Channel commitment key — a separate wallet that holds the cumulative channel commitments. This is included to illustrate that the actors in an MPP setup can be decomposed — there are paths beyond "I get paid for my service" toward monetizing the commitment-holding role itself. The demo configuration here is illustrative, not best practice.

The wallets live in-client (the same model used in the AK Gaming hackathon's game studio), so there's no browser extension or passkey prompt in this demo. That's a deliberate choice for clarity, not a recommendation — for anything heading toward production, look at OpenZeppelin's policy-based smart accounts (OZ Policy). With OZ Policy you can express rules like "any transaction over $10 requires my signature," which is most of what you actually want from a smart agent wallet.

The Exact Moment an Operation Becomes MPP​

The pivot of the video: where in the code does a regular HTTP handler turn into an MPP-gated handler?

In the charge-mode handler, the route checks for a valid payment receipt. If the receipt is present and valid, the handler proceeds to the underlying business logic and returns the response. If it isn't, the handler returns a 402 with the charge challenge attached. That gating block — the small "molecule" sitting between the request and the response — is the entire MPP surface area for charge mode. Flipping the same handler from charge mode to channel mode is essentially a one-line change in the configuration of that gating block.

If you've worked with x402, charge mode is going to feel like familiar territory. The thing to internalize is that channel mode is not x402 with extra steps — it's a different settlement model for a different cost shape, and it's the reason MPP exists as its own primitive.

SDKs and Reference Implementations​

Two pointers for going deeper:

• The MPP documentation on developers.stellar.org, including the list of supported MPP intents.
• The recommended SDK for creating MPP patterns on Stellar — the easiest path to a working integration.

For a better-looking, more-complete reference implementation than the demo shown in this stream, look up @ElliotFriend on X — Elliot's MPP demo (including MPP Stellar Buzz, a per-channel chatbot) is a strong example of channel mode used correctly: open a channel when the conversation starts, settle once when it ends, no per-token transaction overhead in between.

Where MPP Fits​

The use cases that map cleanly onto MPP all share one property: high-frequency paid calls. That keyword is the easiest filter. If your access pattern is bursty or per-token or per-tick, channel mode. If it's an occasional one-off charge for a piece of data, charge mode. If it's neither, you may not need MPP at all.

Concrete examples worth thinking about:

• Paid data feeds and oracles — charge per query, or open a channel for high-frequency consumers.
• Premium developer tools and analytics APIs — the obvious one. Per-call billing for tools that today rely on API keys and out-of-band invoicing.
• AI-enabled explorers — paste a wallet or contract address into a chatbot and have it narrate the on-chain activity. Open question on the table during the meeting — a strong opportunity for builders.
• AI auditing tools — auditing a Soroban contract for vulnerabilities, with the caveat that no AI auditor should be the only thing standing between a project and mainnet.
• Agent service marketplaces — agents paying agents per-call, with MPP as the settlement layer.
• Usage-based infrastructure — anything where the cost shape is "metered, often, small."