Stellar Quest Is Back​

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

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

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

Guest: Hypertron — Private Payments and Operations for Businesses​

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

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

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

The Application Layer​

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

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

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

The Privacy Stack​

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

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

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

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

The Fine Print​

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

Closing​

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

This week's protocol discussion had two parts. First we wrapped up the CAP-84 debate from last week. Then Dmytro Kozhevin (Dima) presented CAP-86. Discord gave a few people audio trouble at the start, so if you could not hear Dima live, the recording above is the place to catch up.

CAP-84 Follow-Up: Why Muxed Contract Addresses​

Jake Urban, the author of CAP-84, joined to explain the product case. His core point: every valid reason to mux a G account also applies to contract accounts.

• Omnibus accounts: Most exchanges take deposits and withdrawals on G accounts with memos or muxed addresses. If an exchange or custodian moves to smart accounts, it loses both options, because a contract invocation cannot carry a memo.
• Per-payment IDs: On and off ramps attach an off-chain ID to a payment to reconcile it with the on-chain transfer. A muxed contract address can carry that ID in the address itself.

George restated his concern from last week. He does not have a strong objection, but he wanted the group to check if a Soroban-level pattern, such as a standard omnibus contract that emits the ID in events, could reach the same goal without a protocol change. He noted that the impact is smaller than he first thought, because integrators that read the CAP-67 unified events do not need the new strkey.

Jake's reply:

• A contract-level pattern would give each address type a different interface, which is a footgun for developers and would slow contract account adoption.
• Today you send a muxed deposit by calling the token contract directly. With a custom pattern, you would call the contract account, which then calls the token. That is a worse developer experience.
• Muxed G addresses already exist, so leaving contracts out feels like going halfway.

George agreed that fragmentation is a real concern and was fine with the decision once the alternative was considered. Dima added that a single address string is much safer than an address plus a separate ID. Users lose funds when they forget the memo, which is why muxed accounts exist in the first place.

A builder in the audience gave a real example. Their team won an SDF RFP for a smart account onboarding protocol. Today, on and off ramps cannot deposit directly to a C address, so they run a relayer: deposits go to a pooled G address with a memo ID, and the relayer forwards the funds to the user's contract account. Muxed contract addresses would remove that whole layer. With that, the group considered George's question about demand mostly answered.

CAP-86: Sparse Map Reads and Writes​

CAP-86 fixes a problem that Soroban has had since launch: you cannot change a #[contracttype] struct without breaking every reader of that struct.

The SDK uses fast host functions to convert structs to and from maps. These functions require every requested field to exist, and every field in the map to be consumed. If you add, remove or rename a field, the reader traps. The contract cannot catch the error and try another layout. People have hit this in practice: they upgraded a contract, added a field to the struct that holds the admin, and could no longer read that struct, so they could not upgrade again.

The CAP adds two host functions, sparse_map_new_from_linear_memory and sparse_map_unpack_to_linear_memory:

• Sparse reads: The reader names the fields it wants. The map can have more fields than requested. A missing field comes back as Void, which the SDK can map to Option::None. If you need a field, make it non-optional and the read fails as expected when the field is missing.
• Sparse writes: A None field is not written to the map at all. This saves storage and makes event payloads with many optional fields smaller. Dima mentioned SEP-41 events with an attached map as one use.

This enables migrations that were not possible before. You can add an optional field and fill a default when it is None, remove fields you no longer need, and extend structs passed between contracts without new functions. Dima compared it to protobuf v3, where every field is optional and the reader decides what is required.

Caveats:

• If two contracts disagree on a field name, an optional field could silently read as None. This needs a miscommunication and an optional field, so Dima considers it a small risk compared to the one it removes.
• Old readers break if a writer starts omitting None fields, because they expect every field. The SDK will decide when to use sparse writes.
• The CAP adds new functions and does not change existing ones, so no deployed contract changes behavior. To use the new semantics, you must update the SDK and rebuild your contract.

Performance is the same as the current functions, or slightly faster when you skip fields.

Please add your comments to the CAP-84 and CAP-86 discussion threads.

The Week I Mostly Shut Up​

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

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

What Raven Actually Is​

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

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

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

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

The Sources: Lumen Loop and Stellar Light​

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

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

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

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

Truth Is a Garden​

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

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

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

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

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

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

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

Other questions from chat, rapid-fire:

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

Tangents Worth Keeping​

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

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

Closing​

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

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

This week was a protocol discussion. Dmytro Kozhevin (Dima) from the core team presented two CAPs: CAP-85 and CAP-84. He started with CAP-85, because CAP-84 had already drawn some concerns and was likely to take longer.

CAP-85: Externally Managed Contract Executables​

CAP-85 came out of ecosystem requests. Every Soroban contract can already update its own Wasm, but only one contract at a time. If you run a fleet of contract instances that must share the same code, for example a set of token contracts, you need a custom batching contract today. That only works if the whole update fits into one transaction's resource limits.

The CAP adds a third executable type next to Wasm and the Stellar Asset Contract: an executable reference.

• The contract does not store its own Wasm hash. It points to a contract data entry owned by another contract, which the CAP calls the owner contract. You can think of it as a manager contract.
• Lookup gets one more step: find the reference, read the Wasm hash from the owner contract's entry, then load the code.
• When the owner contract updates the hash, every contract that points to it updates atomically. No need to iterate over the fleet.
• One manager contract can own many references, so a whole protocol with several different implementations can be updated in one transaction.
• Existing contracts can switch to an executable reference with an update, and they can switch back to a plain Wasm executable later. Nothing is one-way.

Safety: the executable tag​

A plain contract data entry could be deleted, or set to a value that is not a valid Wasm hash. A bug in a manager contract could then make the whole fleet unusable until someone fixes the entry. To remove that class of errors, the CAP adds a new object type, ExecutableTagObject, which wraps a string and must be used as the key of a reference entry. Because the protocol can now recognize reference entries, it:

• does not allow anyone to delete them, and
• only allows updates to the hash of a Wasm that is already uploaded on chain.

The only remaining way to break the fleet is to point it at valid Wasm that does the wrong thing, which the protocol cannot detect.

TTL extension and state archival​

The existing functions that extend the TTL of contract code will extend both the code and the reference entry when a contract uses a reference. The intent of these functions is to keep everything the contract needs to run alive, so extending only one of the two entries would be surprising.

The reference entry is persistent storage, so state archival works as usual. If it gets archived, simulation generates a restore, someone pays the restore fee, and the contract keeps working.

Questions from chat​

• Smart wallets and modules: A smart wallet could use a manager contract to update all of its modules atomically. Dima called this a good example of a use that the CAP did not originally target.
• Authorization context: Custom accounts receive a context that describes contract creation, so the CAP extends that structure with the new executable type. A policy could allow or block contracts created from a reference. This is a small backwards-compatibility point: an account that parses the context needs a newer SDK to read the new type. It only matters if the account itself creates such contracts.
• Alternatives: The team compared other designs and chose the one that is the most flexible and ergonomic for Soroban.

CAP-84: Muxed Contract Addresses​

CAP-67 brought muxed addresses to Soroban, but only for classic G accounts. A muxed address bakes an off-chain identifier into the address. A custodian such as an exchange can serve thousands of users from a handful of on-chain accounts, and the identifier appears in the token events.

CAP-84 extends the same idea to contracts. A muxed contract address is the 32-byte contract ID plus a 64-bit ID, and it gets its own strkey. The existing muxed address object and host functions cover the new type, so:

• SEP-41 does not need to change, and
• contracts that already accept muxed addresses pick up the new type automatically.

Is there demand?​

George raised the main concern in the discussion thread. The XDR change is small, but a new strkey type is a large ecosystem change. Every SDK, and every wallet or backend that handles addresses, has to support it. George asked for concrete use cases from builders, and asked whether Soroban's programmability could solve the problem without a protocol change. He gave claimable balances as an example of a feature that shipped before the need was clear.

Dima's answers:

• Jake Urban wrote the CAP and works with builders of custodial contract wallets. These builders want to integrate SEP-24 on and off ramps, but they cannot use memos or muxed destinations with contract accounts today.
• Memos are not safe in Soroban. Authorization is detached from the transaction on purpose, so you cannot reliably tie a memo to a given event.
• The other option discussed during CAP-67 was a new transfer function with a separate destination ID. That brings back the two-part address problem of memos, and every contract would need to change to support it.
• An account per user is expensive and hard to operate, especially for contract accounts. A custom wrapper token would bypass most of the ecosystem.
• Integrators that already parse the CAP-67 unified events get the muxed ID from the events without needing to handle the new strkey.

Dima's view: the CAP is not guaranteed to be merged, but if the protocol supports muxed contract addresses, this is the cleanest way to do it. George agreed that the implementation details matter and asked for a concrete picture of how a custodial contract account would work with SEP-24 without the CAP. The discussion moved to the thread and continued the next week.

Please add your comments to the CAP-85 and CAP-84 discussion threads.

A Week About Privacy​

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

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

Guest: Zarf — Private Token Distribution by Email​

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

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

The Problem​

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

How It Works​

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

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

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

The Architecture​

A few implementation details worth capturing:

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

The Demo​

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

Confidential Tokens: The Other Half of Privacy​

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

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

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

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

Closing​

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

Another Doozy of a Week​

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

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

Guest: Gaian — Stablecoin Rails for Southeast Asia​

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

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

How the Flow Works​

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

Authentication​

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

The Order Lifecycle​

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

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

The Demo​

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

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

The Real World ZK Hackathon​

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

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

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

Closing​

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

A Doozy of a Week​

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

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

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

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

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

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

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

The Problem​

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

Three Primitives​

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

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

What's Next for XCCY​

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

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

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

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

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

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

Live Demo​

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

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

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

Back After a Week​

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

Sodax: Cross-Network Liquidity as Developer Tooling​

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

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

From ICON to Sodax​

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

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

The Spoke-Chain Model​

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

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

Three Lines to a Cross-Network Swap​

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

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

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

Earn, and a Bit of Alpha​

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

Built for Agents​

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

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

The Fee Model​

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

Why Mainnet Only​

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

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

Next Week​

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

Another Two-Part Meeting​

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

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

The Substrate: Why the Economics Only Work on Stellar​

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

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

What's in the Toolkit​

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

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

The zkTLS Bridge​

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

Private Payments, Honestly​

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

Production Readiness​

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

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

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

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

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

The Orchestrator Theme, Continued​

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

Hands-On Frameworks: BMAD and Superpowers​

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

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

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

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

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

Free Compute: freebuff​

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

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

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

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

Where This Is Going​

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

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

A Packed Two-Part Meeting​

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

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

The Problem: Group State Without Metadata​

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

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

Three Iterations: Groth16 → PLONK → Post-Quantum​

Renat walked through the iteration history:

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

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

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

Cost, Limits, and the Open Payer Problem​

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

The limits worth knowing:

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

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

What Renat Is Looking For​

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

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

The Orchestrator Shift​

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

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

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

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

Cline Kanban​

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

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

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

Paperclip: A Control Plane for AI Labor​

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

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

Two practical notes:

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

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

BMAD Method (Saved for Next Week)​

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

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

Where This Is Going​

Two takeaways:

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

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

Machine Payments Protocol: A Deep Dive​

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

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

Charge Mode vs. Channel Mode​

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

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

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

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

The Receipt Flow​

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

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

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

Demo Walkthrough​

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

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

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

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

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

The Wallet Setup​

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

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

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

The Exact Moment an Operation Becomes MPP​

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

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

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

SDKs and Reference Implementations​

Two pointers for going deeper:

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

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

Where MPP Fits​

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

Concrete examples worth thinking about:

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

Protocol Discussion: Modular Custom Accounts and Signature Security in Protocol 27​

This protocol meeting covered two related authorization changes coming in Protocol 27, presented by Dmytro Kozhevin: a recap of CAP-71's authentication delegation for custom accounts, and a newly published security addendum, CAP-71-02, that closes a narrow signature replay gap.

CAP-71 Recap: Authentication Delegation for Custom Accounts​

CAP-71 has been around for a while and hasn't changed — the news is that it is actually being implemented in Protocol 27. It improves what modular custom accounts can do by adding built-in delegation support at the protocol level. A "root" account can delegate logic — for example, the cryptography implementation — to separate "sub-account" contracts. That makes it possible to have an abstract, configurable meta-account shared by multiple users, with the actual signing logic living in different contracts.

This architecture has already been attempted in the wild (OpenZeppelin's contract examples use it), but until now it was painful: delegating the authorization context required several rounds of pre-simulation to propagate the context. CAP-71-01 builds the delegation mechanism directly into the protocol, which should make life significantly easier for anyone developing custom accounts.

CAP-71-02: Closing a Signature Replay Gap​

The reason a separate addendum exists: CAP-71 introduced a new kind of signature payload preimage, and that surfaced a small oversight in the original design. Soroban uses a unified format for signature payloads — a preimage carrying most of the necessary context, hashed with SHA-256 and then signed with an arbitrary cryptographic algorithm. "Most" is the key word: the standard authorization payload does not include the signer's address.

Most of the time this doesn't matter. In a typical token transfer from A to B, the authorizing address is present in the payload anyway. Even when it isn't — like minting with a Stellar Asset Contract, where the admin address is not in the payload — a SAC has only a single admin, so the signature can't be reused.

The one obscure case where it does matter, described in detail in the security notice published just before the meeting, requires a specific combination of factors to line up:

• An admin-style contract where the authorizing signer is implicit — fetched from storage rather than named in the payload
• That admin being rotated to a different public address
• The old and new addresses reusing the same private key

Sharing a private key across public addresses is rare and generally not something you should do, and an analysis showed this combination has never occurred on-chain. But if it ever did happen, the impact would be serious — a signature could be replayed to, for example, mint a token a second time. The gap was discovered through security audits.

The fix introduces a new credential type, SOROBAN_CREDENTIALS_ADDRESS_V2, whose only difference from the current address credentials is that the protocol uses an address-bound signature payload preimage — the signer's address is guaranteed to be part of what gets signed. The structure is otherwise identical, so supporting it downstream is just a matter of switching from one credential type and payload format to the other.

Migration Guidance​

As of Protocol 27, the old address credentials are not being deprecated — the probability of the issue is low enough that there's no urgency for an abrupt, breaking fix. The intention is to migrate to address v2 eventually (possibly Protocol 28 or later): client tooling — the CLI, developer SDKs, and so on — can update to the new credential and payload format at their own pace after the Protocol 27 upgrade, and once the ecosystem has moved, the old format can be deprecated non-disruptively. If you maintain an admin-style contract and are worried in the meantime, you can pass the signer address in the payload explicitly.

Read more about the proposals here:

CAP-71 - Discussion

CAP-71-01 - Discussion

CAP-71-02 - Discussion