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.
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 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.
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.
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.
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.
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.
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.
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.
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.
]]>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.
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.
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.
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.
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.
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.
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.
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.
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.
]]>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.
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.
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:
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.
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.
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.
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.
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.
]]>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.
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.
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.
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.
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.
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.
]]>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.
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.
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.
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:
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.
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:
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.
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.
]]>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.
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.
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.
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.
A few implementation details worth capturing:
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).
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:
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.
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.
]]>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.
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.
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.
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.
There are two halves — onboarding a user, then placing an order:
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.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.
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.
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.
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.
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.
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.
Dennis demoed the platform (live, on Stellar testnet, network errors and all) and the math behind it:
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.
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.
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.
]]>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 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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
]]>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.
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.
Root14 is a layered toolkit, and he walked through it piece by piece:
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.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.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.
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.
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.
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:
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.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 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.
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.
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.
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.
The unsolved problem under all of this is memory — how does the agent remember where it left off? Three takes:
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.
]]>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 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.
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.
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:
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.
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 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 — 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 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:
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.
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.
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.
]]>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.
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 channel-mode handshake is worth internalizing because it's where most of the "wait, how does this work?" questions come from:
402 Payment Required with a channel challenge.200 and serves the response.Charge mode collapses steps 2–5 into a single pay-and-go interaction — you pay, you get the receipt, you make the call, done.
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 demo uses four wallet roles, and the setup is worth calling out:
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 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.
Two pointers for going deeper:
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.
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:
This protocol meeting covered two related authorization changes coming in Protocol 27, presented by Dmytro Kozhevin: a recap of CAP-71's authentication delegation for custom accounts, and a newly published security addendum, CAP-71-02, that closes a narrow signature replay gap.
CAP-71 has been around for a while and hasn't changed — the news is that it is actually being implemented in Protocol 27. It improves what modular custom accounts can do by adding built-in delegation support at the protocol level. A "root" account can delegate logic — for example, the cryptography implementation — to separate "sub-account" contracts. That makes it possible to have an abstract, configurable meta-account shared by multiple users, with the actual signing logic living in different contracts.
This architecture has already been attempted in the wild (OpenZeppelin's contract examples use it), but until now it was painful: delegating the authorization context required several rounds of pre-simulation to propagate the context. CAP-71-01 builds the delegation mechanism directly into the protocol, which should make life significantly easier for anyone developing custom accounts.
The reason a separate addendum exists: CAP-71 introduced a new kind of signature payload preimage, and that surfaced a small oversight in the original design. Soroban uses a unified format for signature payloads — a preimage carrying most of the necessary context, hashed with SHA-256 and then signed with an arbitrary cryptographic algorithm. "Most" is the key word: the standard authorization payload does not include the signer's address.
Most of the time this doesn't matter. In a typical token transfer from A to B, the authorizing address is present in the payload anyway. Even when it isn't — like minting with a Stellar Asset Contract, where the admin address is not in the payload — a SAC has only a single admin, so the signature can't be reused.
The one obscure case where it does matter, described in detail in the security notice published just before the meeting, requires a specific combination of factors to line up:
Sharing a private key across public addresses is rare and generally not something you should do, and an analysis showed this combination has never occurred on-chain. But if it ever did happen, the impact would be serious — a signature could be replayed to, for example, mint a token a second time. The gap was discovered through security audits.
The fix introduces a new credential type, SOROBAN_CREDENTIALS_ADDRESS_V2, whose only difference from the current address credentials is that the protocol uses an address-bound signature payload preimage — the signer's address is guaranteed to be part of what gets signed. The structure is otherwise identical, so supporting it downstream is just a matter of switching from one credential type and payload format to the other.
As of Protocol 27, the old address credentials are not being deprecated — the probability of the issue is low enough that there's no urgency for an abrupt, breaking fix. The intention is to migrate to address v2 eventually (possibly Protocol 28 or later): client tooling — the CLI, developer SDKs, and so on — can update to the new credential and payload format at their own pace after the Protocol 27 upgrade, and once the ecosystem has moved, the old format can be deprecated non-disruptively. If you maintain an admin-style contract and are worried in the meantime, you can pass the signer address in the payload explicitly.
Read more about the proposals here:
]]>Messari published their State of Stellar Q1 2026 report ahead of this meeting, and there are numbers in it that every developer building on Stellar should understand — not as vanity metrics, but as signal for where the ecosystem is actually heading and where the real opportunities are.
RWA market cap — $2 billion at the time of the meeting, up from approximately $1.5 billion at the end of Q1 2026. That is roughly a 33% increase quarter over quarter and a 3x increase year over year from the $500 million mark in Q1 2025. The biggest single-quarter move across any metric in the report.
Average daily smart contract volume — $16 million per day in the last quarter. One year ago it was $2 million per day. For five or six consecutive quarters, Soroban transaction volume has only gone up. This is real usage: contracts being called, operations executed, applications that real users are touching.
Stablecoin market cap — $300 million, up 20% quarter over quarter. Protocols driving this include Aquarius, Blend, and SolarSwap.
The synthesis: Stellar is executing a compounding flywheel that is now clearly visible. Institutional capital flows in via RWAs, higher TVL attracts more DeFi protocols, more DeFi protocols drive more Soroban invocations, more on-chain activity attracts more developers, more developers build more user-facing applications, more users generate more stablecoin and payment volume — and all of that makes Stellar more compelling for the next wave of institutional adoption.
The full report is on messari.io and is worth reading in detail.
Announced on April 22nd at Stellar House in Mexico City: MoneyGram and the Stellar Development Foundation have announced a multi-year extension of their partnership. The framing is important — this is about scaling real-world stablecoin utility globally.
This partnership has been running since 2021. In that time they built the world's largest cash on- and off-ramp for digital assets, launched the MoneyGram Ramps API so developers can plug into the network directly, and created a stablecoin balance feature inside the MoneyGram app that lets customers hold funds in digital dollars and cash out at physical locations.
The next phase focuses on Latin America. The MoneyGram app with stablecoin support first went live in Colombia. With this announcement, it is extending to El Salvador, with more countries across Central and South America planned throughout 2026. The stack powering this is Stellar, Cross-Mint, and Circle's USDC.
The real-world scale here: MoneyGram operates nearly half a million retail locations across 200+ countries. That is not a sandbox — that is live infrastructure for people sending money to families and communities that depend on cash-based services. Stellar Development Foundation CEO Denelle Dixon said: "Stellar was built on the belief that the global financial system should work for everyone." This partnership is what that looks like in practice.
Aquarius, the decentralized liquidity management platform built on Stellar, crossed $50 million in total value locked. Aquarius is Stellar's answer to DeFi liquidity infrastructure — AMMs, liquidity pools, reward systems — and it is designed to be a foundational liquidity layer that other Stellar protocols build on top of. When Aquarius TVL grows, the entire Stellar DeFi ecosystem becomes more liquid and more efficient.
For developers asking where to start: Aquarius has been investing in documentation. Their docs at docs.aqua.network now include real code examples — how to execute swaps through the optimal path, how to claim LP rewards, how to add fee configurations to swaps for building routers into existing applications. If you are building anything on Stellar that involves swapping assets, yield strategies, or liquidity-adjacent features, the Aquarius docs are a solid reference for what production-quality Stellar DeFi integration looks like.
The Stellar Agents hackathon on DoraHacks just wrapped, with around 600 hackers submitting over 260 projects. The hackathon was focused on agentic payments using x402 and MPP — the two protocols covered in the previous developer meeting. What the hackathon showed is what happens when you put those primitives in the hands of 600 builders from around the world.
The following are standout submissions, highlighted not to endorse any specific project but to use them as a window into what is actually possible to build on Stellar right now.
stellar8004.com addresses one of the most important unsolved problems in the emerging AI agent economy: there is no standard way to find agents, verify who built them, or evaluate whether they are reliable. You cannot search for a trustworthy A2A agent for a given task and get a verifiable answer. Every platform has its own walled garden, and there is no portable reputation.
Stellar 8004 takes its name from ERC-8004 on Ethereum (now going multi-chain) and gives every AI agent a blockchain-backed identity, a discoverable endpoint, and a reputation system you can verify on-chain. Think of it as LinkedIn for agents, except the reputation is not self-reported — it is attested on-chain.
The stack is built on three Soroban contracts:
The live explorer at stellar8004.com lets you browse registered agents, check reputation scores, interact with them, and leave feedback. Registered agents can also advertise x402 and MPP payment support in their metadata, so agents can be discovered and paid per query in USDC.
For builders, the team also published a TypeScript SDK at tryon.lab/stellar8004 and a Claude Code skill with slash commands for building on top of the registry with AI assistance.
The conceptually powerful part is the agent-to-agent trust loop. When a DeFi agent wants to call a data analysis agent, it currently has no way to verify that agent is legitimate or reliable. With a registry like this, it can query on-chain, check the score, verify attestations, and decide whether to proceed programmatically.
One note for anyone building in this space: distribution is everything for infrastructure like this. In just one hackathon there were four or five similar projects targeting the same use case. If you are building an agent registry or identity system, check the ecosystem page first and understand the competitive landscape.
mpprouter.dev is a payment network router specifically designed for agent-to-agent micropayments. On Tempo, there are over 400 MPP endpoints. This router makes it possible for users and agents on Stellar to reach and use those endpoints by paying on Stellar.
It's on mainnet. The problem it solves is real and concrete: 400 agents on another network, and this project makes them reachable from Stellar. The way to find good project ideas is to find the pain points of a network — this one found a clear one.
With over $3 billion lost to hacks and exploits in 2025 (the worst year on record), and the industry already down over $600 million in just the first weeks of 2026, autonomous smart contract auditing is becoming genuinely important infrastructure.
Built under the handle Chinese Powered, this is an autonomous AI security auditor for Soroban smart contracts. It works in three steps:
The insight that makes this composable is step three: by writing audit results on-chain, you create an auditing layer that other contracts or agents can query. The project is currently on testnet and needs more work before it is production-ready — particularly around trust establishment and distribution — but the vision it represents is one of the most important unsolved problems in DeFi.
Over 75% of crypto users access services via mobile, and in the markets where Stellar is most relevant — Latin America, Africa, Southeast Asia — mobile-first is not a preference, it is the only option.
Built by Sam Felix, this project flips the assumption that running an AI agent requires cloud infrastructure. Take an old Android phone, run a FastAPI agent runtime on it using Ollama for local inference, and connect it to Stellar via MPP for per-request micropayments. Anyone with a phone can become a node in the AI agent economy.
What is particularly clever is the no-code layer on top: a visual drag-and-drop builder where non-technical users can design agent workflows without writing any code. The exact use case is letting someone in an emerging market use their device to provide or access AI capabilities that would otherwise be inaccessible or expensive. Not yet on mainnet, but the direction is worth noting for anyone building for global audiences.
Highlighted as one of the most polished projects from the CDMX hackathon, Talos is an autonomous agent corporation framework. It lets you create sub-agents and orchestrate them to act as corporate employees: dedicated agents for GTM strategy, marketing campaigns, engineering lead hiring, and so on. The payment layer runs on x402. If you have worked with Paperclip or similar autonomous agent setups before, the mental model will be familiar. One of the most common questions at the CDMX hackathon was how to use AI to steer an entire project or company — Talos is one of the more complete answers that came out of that event.
Stellar House is SDF's format for bringing together builders, partners, and ecosystem members in a physical space — typically two to three days of talks, workshops, and demos. The Mexico City event just wrapped, and all sessions were live-streamed on the SDF YouTube channel (find them under the Playlists section of the channel).
Mexico City was particularly significant for two reasons: the MoneyGram announcement came out of it, and Mexico and Latin America broadly are central to Stellar's mission. The event also featured pitch presentations from several teams that came through the CDMX hackathon — building a pipeline from hackathon to Stellar House is a format that seems to be working.
For developers building on Stellar with AI tooling, a new open-source resource is available at github.com/kaankacar/stellar-ai-guide-mx. Check the building with AI section at developers.stellar.org for the full set of AI resources, including the llms.txt file for feeding Stellar context into LLMs and Stella, the AI assistant trained on Stellar documentation.
Protocol 26, codenamed Yardstick, went live on testnet on April 16, 2026 at 17:00 UTC — literally the day of this meeting. Mainnet validator votes are scheduled for May 6th. If you are running any kind of infrastructure on Stellar — nodes, SDKs, integrations — now is the time to pull the Protocol 26 changes, update your SDKs, and test against testnet before the mainnet vote. The #protocol-next channel in the Stellar developer Discord is where the ecosystem coordinates during upgrades.
Two CAPs shipped with this release:
CAP-81 rewrites the Soroban eviction scan. Instead of scanning the BucketList on disk, eviction now works directly from in-memory Soroban state. The result is faster evictions, fewer disk reads, and more efficient node operations. This is the kind of under-the-hood improvement that compounds as Soroban usage grows — less I/O overhead means the network handles growing state more gracefully at scale.
CAP-82 adds checked arithmetic variants for the existing 256-bit integer host functions. Where the current functions trap on overflow, the new checked variants return Void instead, letting contracts handle arithmetic errors explicitly and gracefully rather than panicking. If you're writing DeFi contracts — lending protocols, swap routers, pricing curves — this matters: checked arithmetic means operations fail explicitly and predictably instead of silently wrapping or trapping.
Stellar has crossed $2 billion in tokenized real-world assets on the network — more than 4x growth in 12 months and 2.5x growth year-to-date as of April. This is not speculative TVL. These are actual financial instruments: tokenized treasuries, bonds, and private credit sitting on-chain today. The institutional names driving this are serious: Franklin Templeton's tokenized treasury fund, Ondo Finance, RedSwan Digital, and Centrifuge. These are not crypto-native experiments — these are traditional finance institutions choosing Stellar as their settlement layer.
What makes this meaningful for developers is that those $2 billion in assets do not just sit there. They are becoming collateral in lending protocols, being deployed in DeFi, and earning yields. That creates real primitives to build on top of.
The Stellar DeFi ecosystem is maturing quickly. Here is the current state:
Blend has crossed $80 million in TVL, making it one of the most significant lending protocol deployments on Stellar.
Stellar Templars Protocol added six new real-world assets to lending markets on Stellar. You can now borrow stablecoins against tokenized institutional assets. The newly added collateral types include:
Institutional-grade RWAs as DeFi collateral is a significant milestone. Sovereign debt meeting DeFi accessibility is a phrase worth sitting with.
Sushi deployed their first concentrated liquidity DEX on Stellar. PYUSD/USDC and XLM/USDC pools are live. Cross-chain functionality is coming soon through Squid Router, which connects Stellar assets to 80+ other blockchains.
EURA — a MiCA-compliant euro stablecoin from All Unity — is live on Stellar. This is a fully backed, regulated euro stablecoin built for institutional use. A regulated euro stablecoin on Stellar is a notable addition for builders targeting European markets or building compliant financial applications.
For a full picture of where Stellar DeFi stands, the SDF published a post titled "What the DeFi is happening on Stellar?" that captures how the ecosystem has been quietly maturing while others debate narratives.
Both x402 and MPP — the two leading agentic payment protocols — are now live on Stellar mainnet. This is a significant milestone for anyone building at the intersection of AI and payments.
The entire payment infrastructure of the internet was designed for humans. An AI agent that needs to call a paid API hits a fundamental wall: there's a form, a billing dashboard, an API key a human configured. The agent hits a paywall and the workflow breaks. x402 and MPP solve this by making machine-to-machine payments as simple as an HTTP request.
x402 is built on the HTTP 402 "Payment Required" status code — a code that has existed since the 1990s but was never meaningfully implemented until now. The flow is simple: an agent requests a resource, the server responds with a price, the agent authorizes stablecoin payment, and the resource is delivered. One HTTP round trip.
On Stellar, this settles in under 5 seconds. Stellar's fees — approximately 0.00001 XLM per transaction — are essential here: if your transaction fee costs more than the payment itself, micropayments do not work. Stellar also has USDC, PYUSD, and USDY as first-class native assets — not bridged, not wrapped.
x402 is co-governed by Coinbase (who launched it), Cloudflare, Google, and Visa. Google has integrated it into their agentic payments protocol. Cloudflare built it into their pay-per-crawl tooling. The SDF also brought OpenZeppelin into the picture — they secure over $130 billion in on-chain assets — to power the x402 facilitator and provide audited smart account contracts with programmable spending limits and guardrails.
MPP was co-developed by Stripe and Tempo and launched last month, and it is live on Stellar. Where x402 handles one payment per request, MPP introduces sessions: an agent pre-authorizes a spending limit up front, then streams micro-payments within that session, settling in bulk at the end. If your agent is querying a data feed thousands of times an hour, MPP sessions are the right model — you avoid the overhead of a per-request authorization for every single call.
On Stellar, MPP settles via Soroban SAC transfers. Agents never need to hold gas tokens because the SDK handles server-sponsored fees.
MPP launched with over 100 integrated services including Stripe, Anthropic, OpenAI, Shopify, and Visa. The core spec has been submitted to the IETF for standardization as the official HTTP payment standard.
To connect this back to everything else in this meeting: those DeFi protocols, tokenized assets, and stablecoin rails all become accessible to AI agents through these payment primitives. An agent can borrow against a tokenized treasury, pay for a data feed, execute a swap, and settle cross-chain — all programmatically, without a human in the loop.
If you want to start building with these protocols, the best starting points are:
llms.txt file for feeding Stellar context directly into LLM prompts, and Stella, the AI assistant trained on Stellar docsThe second half of this meeting featured Yahya and Mert, co-founders of Noether from the No Ethers team, recent graduates of the latest Stellar Community Fund funding round. Noether is, to their knowledge, the first perpetual DEX on Stellar.
The opportunity is straightforward: every serious DeFi ecosystem needs a perpetual DEX, and Stellar did not have one. Mert has been building on Stellar since smart contracts launched on the network, has hosted over 10 Stellar workshops in Turkey, and has mentored builders and served as a judge in Stellar hackathons. When Yahya identified the gap, they locked in and built.
Mert walked through a live testnet demo of Noether:
Faucet — A testnet faucet page where users can claim up to 1,000 USDC per day. Before claiming, users need to set up a trustline to the testnet USDC asset — a standard Stellar requirement for holding any non-native asset.
Trade Page — The core trading interface has three components:
Smart Contract Status — The contracts are currently at MVP stage. Mainnet launch is planned approximately two to three months out, following a smart contract audit that will be supported by the Stellar Development Foundation. The team emphasized they will not launch on mainnet before the audit is complete.
When asked what percentage of their codebase was written with AI assistance, Mert estimated around 70% — with an important caveat: the core financial logic in smart contracts was written and verified by hand. Their approach was to use AI for the less critical parts (landing pages, boilerplate, tooling) while personally reviewing and proving the correctness of anything financially sensitive. As Mert put it: "We write the code with AI but we read it."
]]>In this protocol meeting we had two CAPs to discuss and that was CAP-81 and CAP-82.
CAP-81: This CAP introduces a simpler and more efficient eviction scan process. Instead of scanning the BucketList, the new eviction scan just uses in-memory Soroban state. This simplifies the logic while reducing disk reads and speeding up eviction speed.
CAP-82: This CAP adds checked variants of the existing 256-bit integer arithmetic host functions. Unlike the existing functions which trap on overflow, the checked variants return Void on overflow, allowing contracts to handle arithmetic errors gracefully.
Read more about the proposals here:
]]>We have one new CAP to discuss and that is CAP-80. This proposal adds BN254 Multi-Scalar Multiplication and modular arithmetic used in a variety of ZK proof applications. Adding host support for these will greatly improve the performance of these use cases.
We also follow up on a previous CAP - the CAP-73.
Read more about the proposal here:
]]>In this year’s first Stellar Developer Meeting, on Thursday, January 22nd at 8am PT on Twitch, we will catch up with Ozgun and Boyan from the OpenZeppelin team and take a look at the libraries released in Q4 last year.
We had three CAPs prepared for this meeting. CAP-77 will provide a way to make ledger keys inaccessible based on the network configuration upgrade performed with a validator vote. CAP-78 proposes an interface which allows developers to specify TTL extension policies such as 'if an entry TTL is less than 29 days, extend it to have 30 days TTL'. CAP-79 introduces host functions for converting Stellar strkey format strings to/from Address/MuxedAddress objects.
Read more about the proposals here:
]]>In this meeting we do a walkthrough of OpenZeppelin’s Q3 library releases for Smart Account, Vault and RWA.
Links to docs:
]]>In this meeting we are continuing our mini series about the Stellar-based open source tooling OpenZeppelin is developing. In the last session we talked briefly about Relayer and this time we are diving deeper into this tool, and OpenZeppelin Managed Service.
OpenZeppelin Relayer: https://docs.openzeppelin.com/relayer
]]>