A Doozy of a Week​

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

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

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

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

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

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

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

The Problem​

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

Three Primitives​

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

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

What's Next for XCCY​

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

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

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

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

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

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

Live Demo​

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

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

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

Back After a Week​

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

Sodax: Cross-Network Liquidity as Developer Tooling​

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

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

From ICON to Sodax​

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

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

The Spoke-Chain Model​

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

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

Three Lines to a Cross-Network Swap​

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

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

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

Earn, and a Bit of Alpha​

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

Built for Agents​

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

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

The Fee Model​

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

Why Mainnet Only​

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

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

Next Week​

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

Another Two-Part Meeting​

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

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

The Substrate: Why the Economics Only Work on Stellar​

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

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

What's in the Toolkit​

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

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

The zkTLS Bridge​

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

Private Payments, Honestly​

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

Production Readiness​

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

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

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

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

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

The Orchestrator Theme, Continued​

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

Hands-On Frameworks: BMAD and Superpowers​

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

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

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

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

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

Free Compute: freebuff​

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

Memory: claude-mem, mnemon, and Raindrop Workshop​

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

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

Where This Is Going​

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

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

A Packed Two-Part Meeting​

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

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

The Problem: Group State Without Metadata​

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

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

Three Iterations: Groth16 → PLONK → Post-Quantum​

Renat walked through the iteration history:

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

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

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

Cost, Limits, and the Open Payer Problem​

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

The limits worth knowing:

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

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

What Renat Is Looking For​

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

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

The Orchestrator Shift​

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

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

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

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

Cline Kanban​

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

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

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

Paperclip: A Control Plane for AI Labor​

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

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

Two practical notes:

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

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

BMAD Method (Saved for Next Week)​

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

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

Where This Is Going​

Two takeaways:

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

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

Machine Payments Protocol: A Deep Dive​

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

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

Charge Mode vs. Channel Mode​

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

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

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

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

The Receipt Flow​

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

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

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

Demo Walkthrough​

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

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

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

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

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

The Wallet Setup​

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

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

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

The Exact Moment an Operation Becomes MPP​

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

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

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

SDKs and Reference Implementations​

Two pointers for going deeper:

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

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

Where MPP Fits​

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

Concrete examples worth thinking about:

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

Messari State of Stellar Q1 2026​

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.

MoneyGram and SDF Extend Partnership​

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 Hits $50M TVL​

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.

Stellar Agents Hackathon: 260+ Projects​

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.

Stellar 8004 — On-Chain Identity and Reputation for AI Agents​

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:

• Identity registry contract — agents register with on-chain metadata and wallet binding
• Reputation registry contract — users leave feedback with average scoring
• Validation registry contract — third-party organizations can endorse agents through on-chain attestations

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.

MPP Router (Rozo)​

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.

Stellar Security Audit Agent​

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:

1. Bytecode verification — fetches the deployed WASM bytecode from Stellar and compares it against the source code. This step matters because one of the most common attack vectors is deploying different code than what was audited.
2. AI-powered vulnerability analysis — runs a full checklist equivalent to the OWASP top categories for smart contracts: access control flaws, integer overflows, reentrancy, storage exploits, initialization attacks, denial-of-service vectors.
3. On-chain audit record — audit results are written immutably into a smart contract on Stellar, creating a public, verifiable audit record that anyone can query.

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.

Stellar Mobile Agent Builder​

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.

Talos — Autonomous Agent Corporation Framework​

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 Mexico City​

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.

Stellar AI Guide MX​

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 "Yardstick" Hits Testnet​

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.

CAP-0081 — Discussion

CAP-0082 — Discussion

Ecosystem Snapshot: $2B in Tokenized Real-World Assets​

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.

DeFi Ecosystem Update​

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:

• DEJA (Centrifuge) — a AAA-rated CLO strategy
• DEJTRY — the Janus Henderson short-term US Treasury strategy
• CETES and USTRY (EtherFuse) — tokenized Mexican and US Treasury exposure
• soBTC/USDC pair — you can now use Bitcoin as collateral to borrow on Stellar

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.

x402 and MPP: Agentic Payments Are Live on Stellar Mainnet​

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 Problem They Solve​

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​

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 (Machine Payments Protocol)​

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.

The Full Picture​

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.

Resources for Building​

If you want to start building with these protocols, the best starting points are:

• developers.stellar.org → Build → Agentic Payments — x402 and MPP docs are here
• Stellar Dev Skill — a plugin for AI coding assistants (Claude Code, OpenCode, Codex) that gives your AI assistant deep current knowledge of the full Stellar stack including x402 and MPP
• developers.stellar.org/tools/ai — the building with AI page, including links to the llms.txt file for feeding Stellar context directly into LLM prompts, and Stella, the AI assistant trained on Stellar docs

Guest Demo: Noether — First Perpetual DEX on Stellar​

The 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.

Why a Perp 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.

What They Showed​

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:

• Order book on the left, showing pending limit orders with long orders on one side and short orders on the other, and the current market price in the middle.
• Price chart in the center, pulling real-time price data from Binance via a price proxy.
• Three trading pairs available at launch, with more pairs planned for the following month.

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.

On AI in Development​

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."

Protocol Discussion​

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:

CAP-0081 - Discussion

CAP-0082 - Discussion

Protocol Discussion​

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:

CAP-0080 - Discussion

CAP-0073 - Discussion

OpenZeppelin Q4 Releases​

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.

Protocol Discussion​

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:

CAP-0077 - Discussion

CAP-0078 - Discussion

CAP-0079 - Discussion

In this meeting we do a walkthrough of OpenZeppelin’s Q3 library releases for Smart Account, Vault and RWA.

Links to docs:

• Smart Account: https://docs.openzeppelin.com/stellar-contracts/accounts/smart-account
• Vault: https://docs.openzeppelin.com/stellar-contracts/tokens/vault/vault
• RWA: https://docs.openzeppelin.com/stellar-contracts/tokens/rwa/rwa

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