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: a tour of three 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, Open Router, 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.net.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.

Not yet on mainnet, but 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

In this meeting we are talking to Dobprotocol to learn more about how they use Stellar to build a unique platform, turning machines into investable assets.

Website: https://www.dobprotocol.com

Protocol Discussion​

In this call the recent state archival issue, introduced by Whisk (Protocol 23), is discussed. Questions from community builders are also answered.

OpenZeppelin UI Builder demo​

We are meeting with the OpenZeppelin team again to catch up on the latest developer tooling work they are doing.

This time Steve will demo UI Builder, an easy way to spin up a front-end for any contract call in seconds. UI Builder allows you to select a function and then it auto-generates a React UI with wallet connect and multi-network support, and exports a complete app.

OpenZeppelin UI Builder

Protocol Discussion​

In this Core Advancement Proposal discussion CAP-0075 (Host functions for enabling Poseidon and Poseidon2 hash functions) is presented.

This CAP proposes adding host functions for cryptographic primitives enabling Poseidon family of hash functions, which are widely-adopted hash choices in efficient zero-knowledge proof systems. Supporting these as host functions in Soroban can facilitate adoption of ZK applications and interoperability with other ecosystems.

Link to CAP-0075