76 posts tagged with "developer"

A USDT0 AMA​

Last week I built a USDT0 demo and walked through how the LayerZero infrastructure works on Stellar (2026-10-01). Most of your questions about USDT0 arrived after that call, so this week I brought reinforcements. I collected around 30 questions from you and from a few ambassador chapters, shortlisted nine, and hoped to get through four. We got through six or seven.

My guest was Fabricius "Fifo" Zatti. If you've been in the ecosystem for more than six months, you probably know him already. He has been around Stellar for about six years. He started at Cheesecake Labs, where he was the top contributor to Stellar Plus, and now works at The Aha Company. He also wrote Colibri, the TypeScript toolkit for Stellar that includes contract build verification. He works with SDF on a program that brings experts from the ecosystem to help partners build on Stellar.

On USDT0, Fifo was one of the Stellar-side technical contacts for the LayerZero Labs and Everdawn Labs teams. He worked on the issuer setup sequence, six versus seven decimals, multisig tooling, build reproducibility and verification, DVN data needs, and partner readiness. To be clear: he is not from LayerZero or Everdawn, and he did not build the LayerZero protocol internals or set USDT0 policy. He said he might not have every answer, and he gave honest ones where his memory was fuzzy.

For scale, as of the call: about 5 million USDT0 circulating on Stellar, across roughly 25,000 accounts.

Before the Questions: Hack Meridian​

Hack Meridian is our flagship hackathon before the Meridian conference. It runs on October 25–26 in Lisbon. If you have no visa restrictions, come show us what you're building, and make your repos public so we can judge them. No idea what to build? Ask Raven. Prizes go up to $30,000 in XLM.

There's more than one way to take part. That day was my third stream: an AMA as a road to Hack Meridian with Web Zero, a Spain-based developer community, and a presentation on Stellar tooling at a workshop organized by Her DAO. The next day there was an event in Berlin on building with AI. Our production partner is Guava Global, part creative studio, part production house, part cultural connector.

Fifo's Seat at the Table​

My first question: this was not a one-seat operation, so what did his seat look like, and did any Stellar idea take longer than necessary to land?

Fifo tries to stay neutral and transparent about how things work and how choices affect the ecosystem. LayerZero is a huge protocol, and USDT0 already runs on many networks with its own standards. Soroban is a new space for them. So his job was to make sure the teams had all the information when they chose a path. For almost every project that comes to Stellar, he spends extra time on three things: how storage works, how authorization works, and the bridge between classic and Soroban. He doesn't see these as friction points. He sees them as places where you can use Stellar to your advantage. Much of his role was to question design choices: does this come from a requirement, or from tooling you're used to on other networks? If the latter, can we find a better way on Stellar?

The stressful part was build reproducibility. Everyone wanted USDT0 out quickly, but also well tested and bulletproof, and reproducibility was a hard requirement. The existing standard, SEP-55 (Contract Build Verification), works through attestations tied to the CI process in a repository. During the engagement the team saw they needed a different angle: reproduce the contract build itself. That's hard with Rust compiled to Wasm, where differences in the environment can change the output hash. A lot of people worked on it, and the result is the new SEP-58 (Contract Build Reproducibility for Verification). Fifo can't wait to see the ecosystem pick it up, probe it, and improve it.

Why a Classic Asset and Not a Pure Soroban Token?​

This came from last week's stream. When USDT0 leaves Stellar, the seventh decimal is lost; when it arrives, the seventh decimal is empty. A pure Soroban token could carry six decimals, like USDT0 on EVM chains. So why did USDT0 land as a classic asset with a SAC?

Fifo called this the hottest question for any asset issuer coming to Stellar. He admits a bias: he comes from "the old testament of Stellar" and loves the classic side, while also saying Soroban filled real gaps. He thinks the USDT0 teams were pragmatic. A pure Soroban token could work. Good examples exist, such as SolvBTC and the Centrifuge assets. But the key question for builders is: how do you expect people to use this asset? His case for classic:

1. Reach. Classic assets have been around longer. Wallets, non-custodial apps and secondary markets support a new classic asset automatically, so the surface area is immense.
2. Nothing to build or audit. If the control flags meet your requirements, you deploy no extra contracts and need no separate audit. Classic assets get audited with the protocol, and every classic asset runs the same battle-tested implementation.
3. Both worlds. Through the SAC you reach DeFi and smart contracts. You also keep the classic side: the native DEX, liquidity pools and path payments, all cheap and scalable.

For USDT0 specifically, it checked every box. The control flags give the needed control, and the SAC manager adds the extra administration rules. Fifo called the SAC manager "something fancy they did there" and recommends studying it. The OFT then plugs into the classic asset to handle minting and burning. On decimals, he thinks the trade-off is small. Coming in, you get more resolution on Stellar. Going out, you round or leave some dust behind.

The Other Side of the Coin​

I played devil's advocate and asked for the downsides. Fifo agreed readily:

• Classic is limited to what the protocol offers. You get the control flags, or you extend the admin with a contract, and that's it.
• No atomic global pause. With classic you pause through trustlines, one by one. You can bundle several in one transaction, but nothing guarantees you pause every holder at once. A Soroban token can do that.
• No per-transfer rules. Need compliance checks during each transfer? SEP-57, T-REX, does that for Soroban tokens. You can't add it to a classic asset; workarounds don't behave the same.
• Trustlines are part of the user flow. Where you already run KYC, the trustline fits in nicely. Where you want users to just hold the token, you have to build it into the workflow, sometimes through the trust function in smart contracts.

Classic assets are a good solution, but not a silver bullet. The unique part is that Stellar has both, and they work together. My summary: the two big advantages of a Soroban token are customizability and onboarding. With smart wallets, users can hold a Soroban token from day one without waiting for a trustline.

Why a Separate SAC Manager?​

In LayerZero's standard OFT, one contract is both the token and the app. On Stellar, the USDT0 OFT mints through a separate SAC manager (the three-actor picture from last week: the asset, the SAC admin, and the OFT). Why not make the OFT the SAC admin directly?

You can. Fifo recalled this being a big topic, and he believes the reason was how the teams wanted to set up the multisig and governance, though he doesn't remember every detail. The general lesson is about how much responsibility you put in one contract. On Stellar you weigh storage and resources, because they scale differently. You also weigh upgradability: separate contracts let you upgrade one piece while others stay fixed. He doesn't think upgradability drove this case. The classic asset also mattered. You can't change how the SAC works; it's an interface you build on top of. So a small admin contract on top was necessary, and with the token logic already handled by classic, it wasn't a big lift.

His advice, which I want to repeat: don't copy other projects, even big ones. Evaluate the design for your own use case. Flexible, composable building blocks exist so you can adapt them to your reality. Many developers now treat USDT0 almost as its own standard for cross-chain apps, so it matters to know which parts are design choices, which are security choices, and which are required.

What Does "Waiting for Confirmations" Mean on Stellar?​

Stellar closes a ledger and it's final, with no reorgs. So what does it mean when a LayerZero app waits for confirmations on Stellar, and how should an app pick that number?

In LayerZero, the full path from a source contract through the endpoint, the DVNs and the destination endpoint to the destination contract is a channel (a pathway). You configure each channel independently. Two key settings are finality, the number of block confirmations to wait for on the source, and verification, which DVNs must verify the message and how many.

Confirmations exist because some chains can reorg. Competing chains get validated, one wins, and transactions on the loser roll back. That's why Bitcoin and Ethereum transfers wait X blocks. If the destination step ran before the source was truly final and the source then reverted, you'd have a big problem. On Stellar the setting still exists, but a transaction is final after one ledger, about five seconds. Fifo's recommendation: configure Stellar channels with a low value. Add a couple more if you want a safety margin, but you don't need to. For the other chains on your channel, assess each one separately.

Why Does Leaving Stellar Take About Half an Hour?​

A viewer said leaving Stellar takes about half an hour, while arriving from Polygon takes under two minutes. What are the delivery states?

It comes down to channel configuration. A message goes through three legs:

1. The source transaction. On Stellar that's about five seconds, plus however many confirmations the channel waits for. USDT0 has its own channel with its own configuration.
2. The DVNs. If the channel requires three DVNs, it takes as long as those DVNs need to pick up, verify and confirm the message on the destination.
3. Execution on the destination. The message runs on the destination chain, and that chain's confirmation time applies.

Open LayerZero Scan and find your message. It breaks down each step: time on the source, time waiting for DVNs, which DVNs took part, and the final leg. You can see where the time goes and whether it's just configuration.

I asked whether the number of signers inside a DVN slows delivery. LayerZero's own DVN, for example, is on Stellar mainnet and has multiple signers. Fifo's answer: it can, but likely not significantly; it depends on each DVN's implementation. If something is slow, look first at the on-chain configuration for that channel: the finality set for the sending and receiving networks is usually the biggest bottleneck. The DVN set also varies by channel: two of three, one of two, four of five. That affects processing time too. Neither of us remembered the signer counts on mainnet offhand; you can look them up from a message on LayerZero Scan. One more point from me: signer count also matters for security, so think about which DVNs you choose.

Closing​

Thank you, Fifo, for answering six or seven of my questions. I have 20 more, and I'm saving them for Hack Meridian. If you want to watch me ask them live, come to Lisbon on October 25–26. See you next week at the Stellar Developers Meeting.

Happy Stellartober​

October is the month of Hack Meridian and the Meridian conference, which is exactly why I refused to spend the call talking about either of them (mostly — see the intermission below). This week was about USDT0 on Stellar: Tether's USDT delivered to Stellar over LayerZero's OFT standard. Think of it as a prologue to a USDT0 AMA — if everything goes well, next week I'll have people who were actually involved in issuing USDT0 and wiring Stellar into LayerZero on the stream, and my job this week was to make sure you ask them the right questions.

The agenda: slides (necessary, for once), a short intermission about Hack Meridian, then a live tour of nine demos in one website, including launching an omnichain token on Stellar and driving a vault on Stellar from MetaMask. Everything I showed lives in one public repo, and every address I mentioned is verified on-chain.

What USDT0 Is​

USDT0 is Tether's USDT moved over LayerZero's Omnichain Fungible Token (OFT) standard. The canonical USDT stays locked in an adapter contract on Ethereum; every other chain holds USDT0 minted against that locked supply. USDT itself is Tether's asset; USDT0 is built and operated by Everdawn Labs (I said "I should fact check this" on the call — I did, and it's correct). It's live on 23 networks, and as of September 2 Stellar is one of them.

One ground rule: USDT0 is on Stellar mainnet only. Anything called USDT0 on testnet is somebody's mock. The LayerZero endpoint, however, is live on testnet, so your own test tokens work there — which is exactly what the demos use.

Where we stood as of the call — not a sales pitch, just a sense of the potential:

• 23,717 accounts hold a USDT0 trustline, up from about 13,500 roughly 17 days earlier — growth of about three quarters in two and a half weeks.
• About 2.58 million USDT0 sits on Stellar, almost all of it held inside 23 contracts.
• Seven DVN operators are registered on Stellar mainnet; USDT0 requires three of them.
• USDT0 is the biggest LayerZero tenant on Stellar but not the only one: of the last 50 messages leaving Stellar when I built the slide, 38 were USDT0. The rest came from other apps — PayPal's and Ethena's among them.

Each Leg Has Its Own Mechanism​

An OFT keeps one total supply across chains by pairing a debit on the source with a credit on the destination, but the mechanism differs per leg. On Stellar it's mint/burn: sending burns your USDT0 through the Stellar Asset Contract; receiving has a contract called the SAC manager mint to you, so supply on Stellar always equals what was bridged in. On Ethereum the OFT is an adapter: sending locks canonical USDT (approve first), receiving unlocks it, nothing is ever minted. That invariant is the whole security story — USDT0 minted everywhere else equals USDT locked in the Ethereum adapter — so never promise "burn and mint on both ends"; always check the leg.

Remember CCTP? Same story with decimals, as we saw in Elliot's CCTP call: Stellar has seven, USDT on Ethereum has six. OFT solves this with a shared precision, six for USDT0, and amounts travel on the wire as a 64-bit integer in those six decimals. Send 12345678 stroops and the wire amount is 1234567; the trailing eight stroops are dust, removed before the message is built, and they stay in your account. The practical rule: always call quote_oft first — it returns the exact amount that will arrive, and skipping it fails your simulation.

A LayerZero message is not a transaction that travels. It's five steps: send, verify, commit, execute, mint. The source OFT calls the endpoint and a packet is emitted with a nonce, endpoint IDs, sender, receiver and payload. Each required DVN — decentralized verifier network — independently attests the packet on the destination chain. Once the required set has attested, the verification is committed on the receive library (anyone can call this). An executor calls lz_receive on the destination OFT — anyone can be the executor. And on Stellar, the OFT asks the SAC manager to mint to the recipient. The DVN set is dynamic and may grow or shrink; for now, know that DVNs exist and why.

Three Contracts and a Classic Asset​

On EVM chains one contract is both the token and the LayerZero app. On Stellar it's several pieces — the most confusing part for me when I first learned LayerZero:

1. The classic asset, USDT0. Its issuer account is locked, and the flags allow freezing and clawback, like Tether does on every chain.
2. The Stellar Asset Contract. The SEP-41 view of the asset — balance, transfer, burn, the usual suspects. Its admin is not a key; it is a contract.
3. The SAC manager. The admin contract. It holds the admin role and mints only for holders of the minter role. The OFT holds that role, and the SAC manager itself is owned by a multisig.
4. The OFT contract. The actual LayerZero app: quote_oft, quote_send, send, lz_receive. It stores the peers and the enforced options, and it points at the SAC and the endpoint.

The classic asset, SAC, and OFT addresses are on the USDT0 page in our docs — point your AI at it. The SAC manager is the SAC's admin, so you can read its address from the SAC itself. Everything about USDT0 is readable without a key or a signature: Horizon gives you the classic side, Stellar RPC gives you the contract side through simulation, and LayerZero's deployment registry is the source of truth for every LayerZero address. One lesson from the chain data: the Stellar testnet endpoint was redeployed in August, so always fetch the registry at runtime instead of hardcoding. The Stellar CLI works too — a contract invoke with any account as source is a simulation, no signing involved.

Sending USDT0 From Stellar​

Sending is five steps and looks like a normal Soroban invocation: build the send parameters; call quote_oft for the exact amount that arrives and use it as the minimum; call quote_send for the fee, paid in XLM; call send — the OFT burns your USDT0 through the SAC and the endpoint emits a PacketSent with a GUID; then track that GUID on LayerZero Scan until it says delivered.

Some details cost real money if you get them wrong: the recipient is raw bytes, either a G or a C address; a G recipient needs a trustline before the message lands; and the seventh decimal never leaves your account, which is why you call quote_oft. Tracking uses the LayerZero Scan API, no key needed — by transaction hash, by GUID, or the latest messages for Stellar. One testnet quirk: Scan indexes Stellar messages by GUID first, so the transaction link can lag a few minutes. Delivery is permissionless: once the required DVNs have attested, anyone can finish the message. Remember CCTP? It sort of works like that.

The first question I get from Stellar developers is how this differs from CCTP, so I put together an honest side-by-side (slides coming to X). The short version: not identical, but if you dabble in CCTP, USDT0 over OFT will not be a problem for you.

Intermission: Hack Meridian​

My intermission guest was Feems from Guava, the production studio helping produce Hack Meridian, who you met on last week's stream. The facts: Hack Meridian is a two-day hackathon on October 25–26 in Lisbon, with two tracks — Genesis, for people with great ideas who want to build (with Raven, the Stellar MCP, at hand), and Scale, for existing teams already on Stellar looking to grow. Expect workshops, mentors, office hours and prizes, then a day to chill before the Meridian conference on October 28–29.

Leading up to it, partners are running a plethora of events across Europe — Barcelona on October 3, Paris on October 6, an online AMA with me on October 8, plus Berlin, Paris and Porto, with more announced each week. Go to one to get a taste of Hack Meridian. My proposal, only half joking: she should do this intermission every week until the hackathon. Thank you for staying up late for it.

The Demos: Fork This Repo​

Everything lives at kaankacar/stellar-layerzero-demos. Please fork it and do a bunch of weird stuff with it — every time I play with LayerZero, another use case opens up. Highlights of the tour:

• Explainer — an interactive version of the slides, with the DVNs live on testnet and the "Stellar twist" of multiple contracts. I'm an academic boy, so there are multiple-choice quizzes too.
• Inspector — mainnet, read-only, refreshed every 30 seconds: USDT0 supply and holders, plus the wired peers — the 21 networks your app on Stellar can connect to: Arbitrum, Berachain, Tempo, Optimism, Monad and more. I don't know half of these chains, but each one is a user base you might want to reach. (HyperCore shows up in LayerZero's testnet API but has no registry ID, so it's unusable for now.) A simulate view shows how many DVNs a route requires: three.
• Bridge tracker — paste a transaction hash and follow it, or browse the latest USDT0 messages touching Stellar; the last four were from Polygon and Ethereum, each attested by three DVNs. Timing varies: my first Ethereum testnet transfer took 20 minutes because of Ethereum's block times; Arbitrum takes about two seconds.
• Quotes and a playground — mock only, because real USDT0 is mainnet only.

Launching an Omnichain Token, Live​

The launchpad generates an issuer keypair in your browser and keeps it in local storage — testing only, not how you'd launch a real token, but it walks the exact steps. I'd already launched a KAAN token (please don't buy it if anyone offers it to you; I'm not selling, and I don't even have any). For the live run I named the asset after the last person in chat — ELLIOT — in lock/unlock mode (the alternative is mint/burn, like USDT0), one million supply.

The Stellar side, one Freighter popup per step at a thousandth of an XLM each: fund a throwaway issuer via Friendbot, deploy the SAC, deploy the SAC manager (USDT0 has one, why shouldn't ELLIOT), open a trustline (always — OFT or not, a SAC means a trustline), mint a million ELLIOT, hand the SAC admin to the SAC manager, deploy the OFT, and lock the issuer — simulating USDT0's trust model with clawback and master weight.

Then the part that makes it omnichain: deploy the OFT on Arbitrum Sepolia via MetaMask, enforce options, and wire the two OFTs as peers — three wallet-signed transactions. Result: ELLIOT live on two chains, one OFT owned through Freighter and one through MetaMask, on a pathway using the active testnet DVN. Recipients need an ELLIOT trustline; open one and I'll send you some. Want more chains? Repeat the last three steps per chain: deploy the OFT, enforce options, wire the peers.

A Vault on Stellar, Driven From MetaMask​

The last demo: a vault on Stellar testnet that you operate with MetaMask on Arbitrum Sepolia. To be clear, I am not saying MetaMask has integrated Stellar. I'm saying that, right now, MetaMask on an EVM L2 can interact with a contract that lives on Stellar. I minted some mock USDT0 on Arbitrum, hit deposit via LayerZero, signed the MetaMask popup, and watched the tracker: one DVN verification required.

Then the demo stalled — I hate it when my demos don't work — so I nudged it with my Freighter: committed the verification and called the endpoint's lz_receive myself. "You were the executor." Exactly the logic from Elliot's CCTP demo: instead of waiting for execution, you finish the message. A moment later the vault on Stellar held 500 more mock USDT0, deposited from MetaMask.

Now imagine the rest. Five years ago people talked about omnichain tokens with no good use cases; the industry is in a more established place now. Omnichain DEXes, omnichain lending and borrowing, omnichain wallets — anything. Every user of Ethereum, Arbitrum, Berachain or Monad is now a potential user of your financial application on Stellar. Fork the repo, ask Raven what else is possible, and build it.

Closing​

Around 250 people were still watching when I closed, and I hate ending a stream with a quarter of a thousand viewers on. I'll be at Hack Meridian helping every one of you — if you're around, ask me about LayerZero. Thanks for watching, enjoy the outro music, and I'll see you next week — hopefully with something as interesting as this week's topic.

Road to Hack Meridian, Episode One​

This week kicked off a live stream series that runs all the way to Meridian, our flagship conference, and Hack Meridian, the hackathon that happens right before it. The idea is simple: we want builders walking into Hack Meridian with as many resources as possible, and the first resource you should look at when building on Stellar is Raven. "If you're building on Stellar, just ask Raven" isn't an official slogan, but it's the one we keep repeating. I look at a lot of protocols to see how they help their developers, and — biased as I am — Raven is probably the best thing happening to a Web3 builder right now.

Thankfully I wasn't alone at 11 p.m. staring at my comment section. My guest was Feems from Guava Global, the studio managing the Hack Meridian efforts. Feems leads hackathon program design and the hacker experience: live streams, workshops, coordination with the activation hosts across Europe, and co-hosting these Thursday streams with me from here on.

Hack Meridian, the Facts​

Guava describes itself as a strategy and production studio that delivers events, activations, and experiences that bring ideas, brands, and communities to life. Hack Meridian is their big one this year:

• Lisbon, October 25–26, at ONE16 — an old railway station, which is a very cool venue.
• Two tracks. Genesis is for developers and founders bringing a new idea to Stellar. Scale is for existing projects looking to scale onto Stellar or integrate with it. The specific themes within those two categories drop soon.
• On-site support, workshops, mentors, prizes, and a room full of developers from across Europe.
• Find Your Way, the campaign this stream is part of: more than 10 partners throwing 20+ IRL activations across Europe — Madrid, Barcelona, Paris, London, Porto, and more — for builders, founders, and newbies alike. The calendar lives on hackmeridian.com, and Guava Global's X account retweets everything.

Raven at a Glance​

Feems' framing beat mine (mine was "a time capsule of your future self talking down to you, informing you every step of the way"). When you build in an ecosystem, the biggest question is has this been built already? — and answering it normally means scouring tons of documentation. Raven collapses that into one place: hundreds of developer docs plus everything happening in the Stellar ecosystem, so you can ideate faster, check relevancy — the biggest problem at the scale stage — and keep up with how fast the development side moves. Think of it as your builder sidekick.

Setup is one line. Go to raven.stellar.org, copy the command for your AI tool of choice — Codex, Claude, whatever — run it, authenticate, done. I demoed it from a clean Claude Code terminal running Opus 5.5: open the MCP list, see that stellar-raven needs authentication, click authenticate, agree to the terms in the browser window, and you're connected in under a minute.

One piece of builder feedback worth adding. Technical questions are getting rarer — not because builders have no technical problems, but because the ecosystem has more than enough tooling to do practically anything on Stellar. The question has evolved from "how do I do this on Stellar" to "how do I find the material that lets my AI build X on Stellar," and that is precisely the gap Raven closes. Fewer technical questions also means more ideation questions: at the last Meridian, for every technical question we got ten about ideas, and whether that idea had already been validated in a recent SCF round.

The Demo: From "a ZK Track" to a Shortlist​

Feems walked through the questions every builder asks. Ideation: what could I build? (The part that takes longest; the heartbreaking failure mode is spending months on something nobody wants.) Validation: does anyone want this, does it fit the ecosystem, does it line up with funding? For Scale projects: market research and a real consumer base — which, not coincidentally, is what judges look at too. A future stream will cover judging properly.

So I played a Hack Meridian participant. My prompt, roughly: I'm at Hack Meridian and want to build something around privacy, maybe ZK — let's pretend there's a ZK track. Use Raven to see what privacy solutions are live on Stellar, and check previous SCF rounds for funded privacy projects. Also, you're being live streamed, so show how and why you're using Raven at every step. (I regretted that last sentence immediately. Don't tell your agent it's on TV.) Someone in chat pointed out I'm also a judge; I am, and a hard one to please — I try not to be impressed by projects.

While it ran I plugged a sibling project: Stellar Build, a more private, hands-on set of skills and personas for the AI of your choice that doesn't touch dynamic data. Stellar Build helps you decide what to build; Raven tells you what has already happened — and Stellar Build uses Raven under the hood, because Raven is the best.

Raven came back with the privacy projects live on Stellar today, each with its SCF cohort and the amount awarded: a reusable-KYC project, Moonlight (compliant confidential transactions), and Zarf — the Turkish team doing private token distribution with ZK, who you met in the July 2 note. It also laid out what the protocol itself supports right now, the technical border of what you can build — a border that gets wider every day. And because Raven indexes the Electric Capital developer report, not just SCF, it surfaced projects like KALIEN, Tyler's ZK-proven Asteroids game. Cohorts 23, 37, 40, and 42 flew past, each with the track applied to and the funding received.

Here's the point. I started "knowing" three things: I'm at the hackathon, there's a ZK track, I want to build on it. I got back ideas proven to have a place in the ecosystem — not to copy, but to build something bigger, smaller, nicher, or better on top of. Step two: pick one and go nicher. I grabbed one of the listed projects and asked whether a more niche version existed — think threshold encryption, confidential transfers, sealed-bid auctions. Raven's answer: a few, none funded or listed as projects, so maybe I'd walked down a wrong road — or a new one. The closest match was Stelvin, a sealed-bid batch DEX that uses drand time-lock encryption rather than ZK, built by a Turkish builder I know who won our Istanbul hackathon in June 2025. It also surfaced Sub Rosa, a sealed commit-and-reveal protocol that, if I remember correctly, has received InstaRewards and is heading into the upcoming SCF round. The name-dropping isn't the point; the speed is. You go from "privacy, I guess" to "here is the shape of the final product" in minutes, as long as you know the next question to ask: what can be nicher, what can be bigger.

And my standing advice to builders: you chose Stellar and you chose this hackathon — so at the very least, choose to build something that brings you joy.

Protocol 28, and a Correction​

Feems asked how a newcomer finds technical documentation through Raven. The answer explains what Raven is: an MCP, and MCPs fetch dynamic data. Every call pulls not only the Stellar skills, every SCF submission, and every project in the Electric Capital report, but the developer documentation itself — Raven's Stellar docs family is a full-text search over developers.stellar.org. So I asked it what changed with Protocol 28.

Raven said Protocol 28 has three CAPs and "is not live yet." I let that slide on stream, so for the record: the three CAPs are right — CAP-83 (validators can vote to drop the transaction set from the current ledger), CAP-85 (externally managed contract executables), and CAP-86 (host functions for sparse Symbol-keyed map creation and unpacking) — but "not live yet" was stale. Per the software-versions page in these very docs, Protocol 28 hit testnet on August 27 and mainnet on September 16, a week before this stream. The tooling part was correct: stellar-core and Stellar CLI v28 are out, open source, on GitHub. Go update.

Scale Track: Find Your Nearest Neighbor​

We'd just wrapped a hackathon in Istanbul with the same Genesis/Scale split, so Feems asked how Scale projects should use Raven. For a Scale builder the question is "what's my next step," and you answer it by being inspired by something. What my teammates and I did with the Istanbul Scale track was help each team ask Raven: is there a project similar to mine, what are the differentiators between theirs and mine, and how do I make mine better? That's where scaling starts, and where differentiating yourself from the rest of the ecosystem starts.

How We Actually Use It​

Me: every time a builder asks me anything about Stellar, I ask Raven first — partly to answer, partly to check it still works. I use it to research older content, and almost daily to find out whether a tool is being built somewhere in the world. Say I want a Go CLI for Stellar: maybe someone is already building it, or building something that gets me there faster. The research side is the side I use most.

Feems: understanding past hackathons and the projects that came out of them, to build better personas for these streams and the hackathon itself. It aggregates all things Stellar, which is exactly what a program designer needs.

What's Next​

Feems closed with the activation calendar — events next week in Madrid, Barcelona, Lisbon, Berlin, and Paris from hosts including CryptoDays and Layer X, with the slide refreshed every week.

Next Thursday the topic is LayerZero OFT and USDT0: how USDT0 works on Stellar and how the underlying OFT infrastructure works. We ran an informal survey of builders, and cross-chain applications and privacy were the runaway answers. We have NEAR Intents, we have CCTP, we have a bunch of things — but LayerZero is one of the newest integrations and deserves a proper walkthrough. The week after will probably be privacy again: we've covered SPP and confidential tokens a lot, but one more, more mathematically detailed session — maybe with one more guest — wouldn't hurt.

Closing​

More than 150 people watched this at midnight my time, and Feems joined at 4 a.m. in theirs — one finds a way. I also owe you a promise: I will spend thirty minutes of my night learning how to zoom in on my terminal, so nobody has to squint next time. I just got my visa, so fingers crossed I'll be in Lisbon, side by side with Feems, helping you build more interesting things. Follow Guava Global on X and keep an eye on hackmeridian.com. See you next week.

An AMA for the Newest Kid in Town​

This week was a straight-up AMA about Stellar Private Payments (SPP), Nethermind's privacy-pool implementation for Stellar. We played around with Nethermind's demo on a stream a couple of months back, and the August 6 confidential-tokens Q&A kept pointing at SPP as the tool you reach for when you need counterparty privacy rather than hidden amounts. So this time we went to the source. A few days before the stream we asked on X and in the developer Discord for your questions; my job was to read them to Antonio Larriba from Nethermind, who joined from Europe at 8 p.m. his time and took the whole hour in stride.

Quick introduction, since the Electric Capital developer numbers for Stellar keep climbing and a lot of you are new here: Antonio is a computer scientist with a PhD in cryptography — electronic voting and anonymous identification, specifically — and has been a cryptography engineer at Nethermind for a bit over three years. He has led the Stellar Private Payments work for the whole project. He also blamed Cryptonomicon, read as a teenager, for the privacy obsession. There is clearly a story there; I did not ask, since it is private.

The questions came mostly from builders in LATAM and the MENA region, and they were largely conceptual: people understand how SPP differs from confidential tokens, they wanted to know how the design actually holds up.

What "Compliance" Means Inside a Pool​

The first question came from a developer in Turkey who had read both the Nethermind blog post and ours and kept snagging on one sentence they share: privacy and compliance are not opposing requirements. Fine — but what does compliance mean concretely? What can a regulator, an issuer, or an auditor actually do with an SPP pool?

Antonio's framing: a fully private pool is easy to build, and history shows what happens next — honest users end up sharing a pool with hacked funds, and everyone's money is tainted by association. Compliance in SPP is the set of rules that keeps bad actors out without making the privacy useless, and it is part of the protocol, not an add-on:

• Every interaction is a zero-knowledge proof that you own funds in the pool, that they are really part of the pool, and that they have not been spent.
• On top of that, you prove membership in a whitelist and non-membership in a blocklist. These lists are called association sets, and the parties maintaining them are Association Set Providers (ASPs).
• The rules are configurable per pool. An ASP could implement a blocklist mirroring a government sanctions list, or a whitelist that is ZK-friendly and never asks for personal information. Or a pool operator can run a pool with no whitelist and no blocklist at all — fully private, no admin superpowers, "for the good and the bad," as Antonio put it.

The part I found most important: if a whitelist is KYC-based, you give up some privacy exactly once, at onboarding. After that, everything happens inside the proofs. The ASP can accept or block your notes, but it cannot see which notes you own or how you spend them. A chat question later asked whether mentioning KYT (know-your-transaction) means the model is not trustless — the answer is the same: nothing is enforced per transaction today, the whitelist and blocklist operate at the public-key level, and whether a pool uses any of it is the operator's call. Everything is open source, so you can read how the lists are enforced rather than take anyone's word for it.

Where SPP Sits in the Privacy-Pool Family​

I asked Antonio where SPP lands in the wider privacy landscape, and he was refreshingly unbothered about being first: SPP is a privacy pool, in the lineage of private notes spent inside circuits. Tornado Cash is the famous one, Railgun uses similar techniques, and a handful of newer teams are working on compliance-aware pools too. The shared goal is severing the public link between an origin account and a destination account. What makes SPP interesting is the feature set layered on top of that, which is where we spent the middle of the call.

The Feature List, For the Hackathon Crowd​

Antonio led with the packaging, because there is a hackathon on and I personally know more than five teams building on SPP right now:

• A TypeScript SDK on npm and a Rust SDK on crates.io, both named stellar-private-payments. They are new, so feedback and bug reports are genuinely wanted.
• Deposit and withdraw to break the origin-destination link. The privacy you get is statistical and scales with the anonymity set — the number of people using the pool.
• Internal transfers: you can pay other people, trade, or move funds between your own accounts without leaving the pool, so none of that activity leaks.
• Selective disclosure: generate a proof that you own, say, ten notes with a given balance, without revealing your secrets or any personal information. Useful when you need to show an honest origin of funds without opening everything up.
• An optional global view key. Some pools are being deployed where users encrypt certain secrets to a pool administrator, who can decrypt them off-chain when legally required and audit the trace. It is view-only — your funds can only ever be spent by you — and whether a pool enables it is, again, configurable. Institutions want this, and institutions are where the volume (and therefore the anonymity set) will come from.
• A CLI, which Antonio rightly pointed out is the natural interface if you want to hand an agent a set of tools and let it operate the pool for you.

On the roadmap, with the usual "no details yet": lighter-weight tracing via KYT at deposit time — screen funds once on the way in, then leave the user fully private instead of relying on a powerful view key — and ragequit, so that if a pool bans you unfairly you can get your funds back, at the cost of the privacy you would otherwise have had.

Multi-Asset and Multi-Policy Pools​

My own question, which I prefaced with "this might be stupid": does trading inside the pool mean multi-asset pools are possible? Antonio said they could ship one relatively soon, but most multi-asset designs sacrifice privacy. Fifty people using token A and fifty using token B in one pool does not give you an anonymity set of 100; it gives you two sets of 50 dressed up as one. Better UX, no extra privacy. The team has ideas for a design where every asset shares the same large anonymity set — best of both worlds — but it needs changes to the pool and is not on this year's roadmap.

My follow-up, a thought of a thought: not multi-asset but multi-policy — one configurable, interoperable pool usable by different contracts and assets. That one is technically possible today. The trade-off is that an arithmetic circuit pays for every operation whether you use it or not, so more policies in one pool means longer proving times. If you are at the hackathon this weekend: just do it.

Anonymity-Set Economics: Who Deposits First?​

The question I was most curious about. Many of SPP's guarantees are only as strong as the number of people in the pool, and pools are per asset today. How does a mainnet pool bootstrap an anonymity set, and what is the smallest set Antonio would call useful?

On bootstrapping: "believers and privacy enthusiasts," with a laugh, but then a real answer. SPP supports splitting and mixing notes inside the pool, so there are no fixed denominations like the mixers of old — one deposit can become twenty withdrawals. That means you can deposit 0.1 of a token to test the waters instead of committing a round 1,000. Antonio's bet is that enough people want privacy badly enough to take the small leap of faith first, and that institutional volume follows.

On the minimum: it depends on your threat model — an average user and a journalist whose life depends on it are different cases — and the anonymity set is not the only thing that matters. Metadata hygiene matters just as much: deposit from account A and withdraw to account A and you have bought yourself nothing. Use unrelated accounts, ideally with a third account paying the transaction fee. With proper hygiene and enough time in the pool, his bare-minimum number was 12, which he noted is roughly the ring size he recalled from Monero's ring signatures. I appreciated getting an actual number.

My tangent for the builders in the audience: protocols with AMMs or treasuries could upgrade their contracts to be SPP-compatible and move a chunk of liquidity into a pool, giving it a base of depositors from day one. Nobody told me this was impossible.

Housekeeping: Demo Errors and Where to Ask​

Several of you hit timeouts and simulation failures using the demo with Freighter on testnet. Antonio's explanation: SPP is under active development, breaking changes land multiple times a week, and each one can mean recompiled circuits, new binaries, and redeployed contracts. If your browser is holding old circuits or old state in local storage, proofs get generated against stale data and simulation fails. The fix: open developer tools, clear local storage for the demo page, delete the page's cookies, and reload. For the record, "simulation failed" is my least favorite error on Stellar too.

Where to get help: if you are sure it is a bug in the code and not in your setup, open an issue on the GitHub repo (responses can be slow while they build). For questions, there is a Telegram group for people developing on SPP — Antonio shared the link, I posted it in the chat, and I warned him that every privacy builder on Stellar is about to join. His X profile went into the comments too, so your timelines can gain a few more privacy freaks.

Closing​

About 200 of you were watching live. Round two ran roughly an hour later: a protocol discussion on CAP-87, the proposal adding host functions for ML-DSA post-quantum signature verification, on a Google Meet with the core developers. Builders in Istanbul: the Stellar Pro Hackathon at Grand Pera is this weekend, and I expect several of you to show Antonio your projects and ask him a bunch of questions about SPP. Busy weekend for him. Thank you, Antonio — hopefully I will see you at Meridian. See you next week.

Dress Code: Confidential​

I showed up in a black jacket this week, like a serious businessman here to discuss confidential tokens and privacy. Not because I own no other jackets. The agenda: instead of me talking for an hour, we were going to play a game built by SDF's new Frontier Lab team, with a stack of colleagues and ecosystem friends on the call. One piece of housekeeping first, because it was too big to skip: USDT0 is live on Stellar. The infrastructure that carries Tether's USDT to every network launched on Stellar the day before the stream — a real milestone for a chain built for payments and cross-border finance. But this meeting was about confidentiality, and about how we've only scratched the surface of confidential tokens so far. The August 6 Q&A covered the design philosophy; this week was the hands-on version.

The cast: Bri, senior developer advocate on the Frontier Lab team, who built the game. Playing: Tyler, Elliot, Raph from Lumen Loop, Boxy from Stellar Light, and Patrick, introduced by Bri as "some random guy I picked up off the street." Several people arrived in costume. Patrick's suit jacket, Halloween accessories, and riding shades were, in his words, an attempt to be confidential and undercover. He later admitted the jacket was only on because it was wrinkled and he needed it Saturday. Sweating the wrinkles out, live.

Who Ate Gerald?​

Gerald was a villager. Emphasis on was. One morning the village wakes up, Gerald has been eaten, and that's how everyone learns there's a werebear living among them. Who Ate Gerald? is an eight-player social deduction game in the Werewolf/Mafia family: everyone gets a secret role, one player is the werebear, and the village has to banish the werebear before it eats everyone.

Bri built it because she wanted a more fun way than a blog post to demonstrate the confidential token transfer flow, and to learn it herself by building with it. The caveat, stated up front: confidential tokens are still a developer preview, on testnet only, not ready for production. OpenZeppelin built the Soroban contract suite and the Noir circuits that make confidential SEP-41 tokens possible; Nethermind built the UltraHonk verifier that checks the proofs on-chain. The privacy section of the developer docs has the details, and I was pasting that link into chat all stream.

A day in the village:

• Shop. Log in with Freighter set to testnet, pick a character, and visit two of the four shops: blacksmith, general store, butcher, chapel. Items protect you, expose other players, or just cause chaos. The chapel sells Gerald's fingers; when the eight fingers run out, his two thumbs appear, then toes. Poor Gerald.
• Ask Maude. Every purchase is a real confidential token transfer. The whole village can see which shop you interacted with, but nobody can see what you bought or how much you spent — except the auditor. In the game that's Maude McLedger, the village fortune teller, who holds the auditor key and can read the amounts. Each player gets one private question per day: "what did Trixie buy at the blacksmith?" or "did anyone buy something from the chapel?"
• Accuse and vote. Maude's answers become clues, bluffs, and misdirection. Maybe Raph bought a barrel of beer because it protects you from the werebear at night. Or maybe he bought it precisely so you'd think he isn't the werebear. The most-voted player is banished; an innocent villager loses their vote but keeps talking. Then night falls, the werebear eats someone, and the morning starts over with fewer villagers.

You receive 25 XLM of pocket money per day, so blowing it all on day one means no fancy items later. Bri also quietly raised the discussion timer from two minutes to ten, in case things got heated. They did.

Where the Value Actually Lives​

Before the demo, Bri gave the clearest explanation of confidential tokens I've heard so far, built on two mental models. The first: where the value sits.

1. Regular XLM in your wallet. Public, boring, visible on any explorer. Bri's testnet account was sitting on almost 18,000 test XLM.
2. The shared pool. The confidential token contract is a wrapper around a regular asset — XLM in the game, but any SEP-41 asset works. Every deposit puts XLM into one big pool held by the contract, and it stays there until someone withdraws. The pool's total is completely public: around 34,000 XLM on stellar.expert during the call. What is not public is how that total is split: 500 of it is Bri's, 100 is Boxy's, 10 belongs to the butcher, and you can't tell any of that from the chain.
3. Confidential claims. Nobody inside the system carries their own pile of XLM; they carry claims on the pool. For every registered participant the contract keeps an entry with their public keys, a pending balance (OpenZeppelin's docs call it the receiving balance), a spendable balance, and which auditor they chose. When the game says Bri has 500 XLM, she really has a confidential claim on 500 XLM in the pool, and the number itself is hidden inside a Pedersen commitment: anyone can see the commitment on-chain, nobody can read the balance out of it. (Bri: "I actually don't really know what that is very much, so that's all I'm going to say about it." Honest, and correct.)

Hiding the number creates the obvious problem: what stops you from spending money you don't have? Zero-knowledge proofs. A proof says "the hidden math checks out — I had enough, I didn't create money from nowhere, and all the balances still add up" without revealing any numbers. Commitments hide the numbers; proofs make sure nobody cheats.

The Six Steps of a Confidential Payment​

The second mental model is the lifecycle, which the game displays as a checklist that lights up as you play:

1. Register — each address registers once per wrapper contract. Bri's was already green because she has played the game, in her words, thirty million times.
2. Deposit — public XLM goes into the pool.
3. Merge — the sender moves their pending balance into their spendable balance.
4. Transfer — the sender confidentially moves part of their spendable balance into the receiver's pending balance.
5. Merge — the receiver moves the incoming claim from pending to spendable.
6. Withdraw — the receiver exchanges part of their claim for regular XLM back in their wallet.

The first four are the sender's job, the last two the receiver's. Register, transfer, and withdraw are the steps that carry ZK proofs. And the detail that explains the whole game: deposit and withdraw are the only two points where real XLM and confidential claims trade places. Everything in between is claims changing hands inside the pool. Buy a soup bone from the butcher and the contract's public XLM balance does not move; you just privately changed who owns some of what's already in there. Boundaries public, middle private. You could watch it live in the game's on-chain activity feed: every daily "25 XLM" showed up as a public deposit plus a merge, and every purchase as a transfer with the amount marked confidential. Open one on stellar.expert and there is simply nothing to see.

Maude, the Auditor​

The auditor is the part developers trip over most, so: Maude holds a secret key whose public half sits in an on-chain auditor registry. When you register with the confidential token contract, you pick which registry entry audits you; this game's contract offers one option, so Maude audits everyone. In a real application that slot is a regulator, a compliance team, or an independent auditor — someone who legitimately needs the amounts without making them public. This matches what we worked out in the August 6 note: the auditor is chosen per account at registration, out of a registry that can hold many keys.

She is also strict. Ask something too broad or too specific and she declines. Raph burned his first question asking who the werebear was. When I tried to social-engineer her, she told me, more or less, to shine a mirror on myself. Chat's verdict: "this is what regulation has come to — psychics checking our transactions."

How the Game Went​

Bri ran a watcher screen rather than playing, so she could narrate without leaking her own role. The roster: Trixie Diamond the lamp lighter, Lawrence McDig Jones the gravedigger, a drunk named Not The Werebear, a midwife named Definitely Not Kaan, Boxy the rat catcher (very creative), Badger McPatrick the beekeeper, Chuck Roast the poacher, and a baker whose name I won't attempt to spell. Patrick turned out to be playing two characters, which raised the odds considerably.

Day one: everyone shopped (Elliot was broke within minutes), Maude answered what she felt like answering, and the village banished Lawrence McDig Jones — an innocent villager. Sorry, Lawrence. Trixie Diamond was taken in the night, except, as Boxy clarified while nobody believed him, that was a soup bone: an item that redirects an attack onto someone else. Day two: the soup bone was suddenly the most popular item in town, and the village voted out Badger McPatrick, who was indeed the werebear. Two rounds. "This was scripted," Bri insisted. Last time we played I was the werebear, kept buying the same protective item every round, Maude told everyone about my tooth sharpener, and that game lasted five minutes.

The strategy debrief was genuinely useful for understanding the design: protective items early look innocent; the tooth sharpener bypasses everyone's protections and is a near-certain werebear tell; pizza party means nobody gets banished that day, priced at 43 XLM so you can't spam it; the horseshoe nail persists all game and breaks banishment ties in your favor. And yes, you can soup-bone the werebear by accident and end the game on the spot. There is a custom animation for that. There is also one for the werebear winning, in a tutu, with champagne.

Bri kept the repo private until the stream ended so none of us could work out how to cheat with our agents. It's public now: play at gerald.stellar.buzz (Freighter on testnet), read the code at github.com/stellar-experimental/who-ate-gerald, and treat it as a real reference application for confidential token transfers. Bri also floated that she and Teague might build a "Stellar arcade." Official announcement pending, allegedly.

Closing​

Around 300 of you watched a developer meeting conducted largely in costume, and I'm obsessed. Thank you to Bri for building the game, to everyone who played, and to the viewers who put up with us. There is a serious side to confidential tokens — go read the docs — but experimenting should be fun, and this was. Next on the privacy track: Stellar Private Payments with Nethermind. See you next week.

Housekeeping: Protocol 28 and Another Privacy Preview​

Two links before the agenda. First: if you haven't upgraded yet, do it now. Testnet is on Adapter (Protocol 28) as of this week — the testnet vote landed the same day as this call — and mainnet follows in a few weeks. Check the upgrade guide for what changed: faster consensus (CAP-83), externally managed contract executables (CAP-85), and sparse-map host functions for data migrations (CAP-86).

Second: Stellar Private Payments is officially in developer preview. Deposit into a shared pool, transact inside it, withdraw — without publicly linking who paid whom. Fitting, because this week was a privacy call too.

This Week's Guest: Moonlight​

Moonlight Protocol (moonlightprotocol.io) is a privacy layer built on Stellar by The Aha Company. Their one-liner: it transforms each account into a constellation of unlinkable UTXOs, shielding balances and payments from public traceability. I'll admit a bias — this might be my favorite privacy solution on Stellar — and it's probably the single most requested topic from you all, so I was excited to have Chad and Gorka on. We waited for the room to fill (50+ at the start, close to 200 by the end) and handed Chad the stage.

Introductions came late, because I assumed everyone already knows Chad. For the record: Chad Ostrowski is founder and now CTO of The Aha Company, which arrived about a year before Stellar had smart contracts and built a lot of the core developer tooling — Scaffold Stellar and Stellar Registry among them — plus stablecoin work for large global banks and a tokenized money market fund. A new passkey wallet is in the works too; more on that at Meridian. Gorka, a self-described digital nomad, has been the lead engineer on Moonlight for the past six months — the person actually in the guts of the protocol, and the one who made the UIs, stacks, and layers compose into something you can click.

Chad's Tour: Compliant Privacy Without ZK​

Chad's framing: Moonlight is the privacy layer that makes public blockchains usable for regulated finance. It came directly from needs their banking partners kept raising. Banks want public blockchains — faster settlement, lower costs, new revenue models — but public is a deal breaker. Without privacy they can't legally or competitively make the switch, so today they're forced to choose between privacy and compliance. He showed a chart of privacy solutions getting blocked as regulation tightened: in blockchain, more regulation has meant less privacy, and MiCA makes it harder still. The problem is structural — pay with your public key and the cashier sees your balance and your full history — and regulatory needs differ per region. Privacy isn't dead. We need compliant privacy.

One thing Chad made explicit when a viewer asked: there is no zero-knowledge cryptography in Moonlight today. Turns out you don't need it to build a privacy solution. ZK could add superpowers later (larger bundle sizes, for one), but there's no immediate plan or need. If you've been following the confidential tokens and ZK conversations on this stream, note the contrast: this is a different design axis entirely.

The four building blocks:

UTXOs (Pronounced "Ucho")​

Instead of accounts and balances, Moonlight uses the unspent transaction output model you know from Bitcoin and Cardano. Each payment consumes multiple UTXO inputs and creates multiple outputs, breaking the value trail. Entropy is tunable: fewer UTXOs for cheaper transactions, more for more privacy. Providers can bundle one-to-many or many-to-many transfers — Alice, Bob, Calvin, and David all tell their bank "send this," the bank combines everything into one on-chain bundle and can mix in decoy UTXOs on top. Tailored bundling strategies also unlock new service models: mixers, paymasters, aggregators. Also, Gorka taught Chad to pronounce it "ucho," a viewer asked whether that's a bad word somewhere, Gorka swore it's just a T and an X bundled together, and I'm adopting it.

Standardized Derivation​

One master secret. Every Moonlight address derives from the same seed, which simplifies backups, keeps self-custody intact, and lets you migrate between wallets or providers with no loss of access and an unbroken privacy posture. No derivation data touches the chain, so observers can't cluster addresses back to the master key. And while Stellar is the system of record, the incoming keypair could come from Ethereum, Cardano, Solana, or elsewhere.

Privacy Providers and Councils​

The key concept. Every user onboards with a privacy provider — think bank, though it could be another financial institution or a wallet. The insight: users already trust these institutions with their private data, so Moonlight harnesses that model instead of fighting it. Providers run off-chain infrastructure (a Moonlight API service, KYC/AML) and on-chain infrastructure (an operation-executor wallet registered with a council contract). From the outside the UTXO graph is unintelligible; the provider has enough to see its own users and answer regulator audit requests. Providers also do the bundling.

Providers self-govern through councils, grouped by regulatory region. Chad's running example: two large US banks deploy a council contract; a third asks to join, and the members use their multisig to add its verified address. Users keep sovereignty — onboard with two providers in the same council and you can route one transaction through each, with your wallet living separately from both. Cross-border payments need a provider that operates, and answers to regulators, in both regions.

Privacy Channels​

One smart contract per channel, one channel per asset. The council decides which assets to support and deploys a channel for each — USDC seems likely, a tokenized money market fund maybe, XLM who knows. Channels can carry extensions to bridge liquidity between channels and regions or connect directly to other on-chain applications.

The Testnet Dashboard​

It's live on testnet. Chad pulled up the network dashboard (linked from moonlightprotocol.io): 24 councils, including a seeded "US Banks" example with three providers, each with its public key and wallet-connect URL — the two things the browser wallet asks for at setup. We clicked into a bundled send from a seeded "EU bank" provider and looked at what an outsider sees: gobbledygook. A lot of uchos. The provider's own dashboard would join those outputs to its KYC records; logged out, you get nothing. One gotcha from chat: the council testnet UI currently talks to Freighter directly, not through Stellar Wallets Kit.

I said on the call that the council concept makes enormous sense to me — entities choosing which channels and assets to offer, per region, is how compliance actually works — and a few months after mainnet I'd love to see a long list of providers plugging institutions into this layer.

Gorka's Demo: Alice, Bob, and 42 XLM​

Two wallets side by side. Demo one, the low-level flow: Bob is the only one who can derive UTXOs from his secret key, so he generates a payment request — a very long string — and sends it to Alice. Alice has no channel balance yet, so she deposits 100 XLM into the privacy channel, then fulfills Bob's request using only the information in his message. Bob refreshes: balance updated. Bob then withdraws back to his public account to show the round trip. A viewer asked whether the council validates these transactions — no, they're regular Stellar transactions; the council only deploys channels and governs who may interact with them.

Demo two is why this can actually ship to humans. Passing long strings around is "somewhat not the best user experience," as Gorka put it. Since providers hold KYC data on their users, they can abstract that away: Alice logs into a provider UI and sends 42 XLM to "Bob" by name. The provider holds the amount for Bob until he claims it; his self-derived UTXOs stay out of the provider's reach the whole time, and if he's uneasy about anything held on his behalf he can sweep it into his own UTXOs immediately. Sovereignty preserved, friction removed.

Fifo Drops In​

Fifo — Brazil-based, roughly six years in the Stellar ecosystem starting at Cheesecake Labs, about a year and a half at Aha — had been live-commenting the whole stream, so we pulled him on stage (video slightly squashed). Moonlight started as his garage project a couple of years ago; the original contracts were his alone before Chad and Gorka came in to find the problems and evolve the protocol. The origin story matches Chad's: banking institutions saying "blockchain is great, but how do I onboard users without exposing my whole operation?" It's still a moving target — every new business conversation surfaces another use case. Fifo also works with SDF on a program helping new partners past the common friction points of building on Stellar, so you may have met him already.

Q&A and How to Try It​

A viewer asked for a flow diagram from sender to pool. There is one — it lives in the documentation produced during the recent Runtime Verification audit of the core contracts, whose public report is up. I offered Gorka a two-hour session walking through every diagram; the silence told me to schedule that another time. Spam us on Discord if you want it to happen.

Elliot from our DevRel team had already spun up a council and a provider of his own and asked how to deposit. The order: deploy the council (the administering group), deploy a channel for one asset (think private pool), then deposit the first liquidity into it. You'll need the browser wallet — build it from source and load it in dev mode in Chrome or Brave — or, being Elliot, call the contract directly. Everything is open source under github.com/Moonlight-Protocol: the browser wallet, the provider stack, and the UIs from the demo. The team's explicit request is to go break it: create providers and councils, send private transactions, file what you find. There's no bug bounty yet, just a very big thank-you — and please, no AI-generated low-severity reports; we've had that problem before.

Closing​

Thanks to Chad, Gorka, and last-minute Fifo. Follow @theahaco on X — with 3,500 monthly active developers in this ecosystem, not knowing The Aha Company is on you — and go find bugs in Moonlight. See you next week.

Why Wallets, Why Now​

This week was a coding session rather than a project spotlight: six wallet infrastructures, one demo app, and a running list of gotchas for each. The topic came straight out of the Builder Summit in Brazil, where I spent a week with the local builders and our partners at NearX. Watching what people shipped reminded me of a pattern I had been noticing in Turkey and had assumed was a local quirk. It is not. Worldwide, when builders ship something on Stellar — at a hackathon or in an SCF application — they reach for the Stellar Wallets Kit almost by reflex, because a modal full of extension wallets feels like building on EVM.

The kit is great and I am not here to talk you out of it. But a site that demands "connect your wallet" the second you land on it is a bit of a red flag, and extension wallets are the default in Web3 only because nobody questioned it. I would love to see more experiments with C-addresses, smart accounts, and passkeys, and above all with social login — connect with Google or an email code and you are in. So I built a small gallery app that wires the same flow (show the wallet anatomy, fund with Friendbot, swap XLM to test USDC through Soroswap's router contracts, sign a payment) through each of six kits, and walked through what each one does under the hood. The code is public: kaankacar/stellar-wallet-gallery. If you want the whole thing as a single skill, tell me — skills.stellar.org was at 29 community skills alongside the official ones as of this call, and I am happy to add another.

One housekeeping item before the code: testnet upgrades to Protocol 28 next week, around this same time on Thursday. The chain keeps running, but do not pin your project config to Protocol 27, and maybe take a 30-minute break instead of testing right through the upgrade window. Better safe than sorry.

Stellar Wallets Kit: The One You Already Use​

Nothing new here, so I kept it short. The kit bundles the extension and hardware wallets — Freighter, Albedo, xBull, LOBSTR, Hana, Rabet, Ledger, Hot Wallet, Bitget, and friends — behind one modal, needs no API keys, and only ever talks to classic G-accounts. The flow is the one you know: the dApp loads the source account's sequence number from Horizon, builds a classic transaction, hands the XDR to the wallet, the wallet asks you to approve, the signed XDR comes back, and the app submits it to Horizon or RPC.

Two gotchas worth saying out loud:

• Set the network explicitly. If you leave out the network: testnet line when you initialize the kit, your Freighter or Hana wallet connects on mainnet by default. Check that line before you test, whether you wrote the code yourself or an agent wrote it for you.
• Use v2, and check that you actually are. For the newer builders: there is a v1 and a v2, and yes, we know the payments example in our own documentation still uses v1. We are fixing that; you should be on v2 today.

The default modules work with zero config. Only Trezor and WalletConnect need app credentials, so either add those or drop the two modules and ship with the defaults.

Blux: Pretty, Customizable, and a Little Rough​

Blux has a special place in my heart — it is a Turkish project, SCF-funded about a year ago, and it is a connect kit that onboards users through extension wallets and email, phone, Google, or passkeys. The dashboard at dashboard.blux.cc is genuinely lovely: accent colors, backgrounds, fonts, borders, your own logo, and you can trim the login options down to just Google or just email if that is all your app wants. I live-demoed my own app ID and secret on stream, so that got rotated right after the call. Learn from me.

Under the hood Blux still creates a classic G-account with an Ed25519 key pair. When you log in with email, SMS, or Google, Blux manages that key. That is the trade-off every social-login product makes, and Matias in chat asked the fair question: what happens if Blux disappears tomorrow and they are the custodian? I did not have an answer, and I would love to have the Blux team on a future call to give one.

The gotchas I hit:

• Social login is off by default. Email, SMS, Google, and passkey have to be enabled explicitly in the config, or you have just installed another wallet kit.
• The login modal has no close button, and the signing overlay locks page scroll, so you cannot dismiss it or move around the app without a refresh.
• Soroban transactions through the overlay resolved maybe half the time in my testing. I have not dug into why.
• Blux is React only, the provider must not be mounted without a real app ID (the ID is validated server-side on every auth call), avoid React strict mode, and the npm README is stale.

The workaround that made the demo work: set showWalletUIs to false and let the swap go through silently. One XLM in, 2.48 test USDC out, no overlay. Matias summarized the whole section better than I did: pretty colors and customization are not a trade-off for bad UX. Agreed, and the colors are still pretty. Blux team, if you are reading this, consider it an audit with love.

Privy: Social Login Done Properly, With One Caveat​

You know Privy from EVM. What fewer people know is that it supports Stellar: embedded wallets powering 120 million-plus accounts, with email and social login out of the box. Stellar is a Tier 2 chain in Privy's model. Tier 1 is raw cryptographic signing (Bitcoin and the other Ed25519 chains), Tier 2 adds wallet abstractions, and Tier 3 is full end-to-end client support (Ethereum, Solana). Tier 2 is exactly what we need: Privy signs, but your app builds the transaction.

The flow is elegant. The login opens Privy's modal, an email code creates a wallet inside Privy's key infrastructure, your app builds the XDR and sends only the raw transaction hash to Privy, Privy signs it and returns a hex signature, the dApp converts it to base64, attaches it, and the Stellar SDK verifies it client-side before accepting it. The key never touches the browser's JavaScript, the app only ever sees the address and the signature, and by the time Horizon or RPC sees the envelope it is a perfectly ordinary classic payment. The key does live in Privy's infra, but it is exportable by the user at any time, which is a working mitigation.

Gotchas:

• If you come from Privy on EVM or Solana you are used to the createOnLogin config. On Stellar (and every other Tier 2 chain) you call createWallet with chainType: "stellar" instead. Get that right and you are good.
• You still need an app ID from dashboard.privy.io or nothing works.
• Second-hand, unverified, filed under gossip: two builders told me Privy gets slow once you are scaling to tens of thousands of users. I have not seen it myself. If you have that problem, congratulations on the problem, and go experiment with the other kits.

Para: MPC, Finally​

Para is the newest of the four I demoed on Stellar, and the reason I love it is one acronym: MPC, multi-party computation. With Blux and Privy your social-login key lives in their infrastructure. With Para the key is born as two shares — one in your session, one on Para's network — and the full key never exists anywhere. Signing is a ceremony: the app sends the transaction to Para's MPC network, the two shares compute a signature together without either side ever seeing the whole key, and the fully signed envelope comes back for the dApp to submit. In a world where every conversation is ZK and fully homomorphic encryption, seeing good old MPC in production is refreshing. It was the first cryptographic idea I understood as a new Web3 developer, so I am biased.

Setup: create a project at developer.getpara.com, copy the beta API key, done. The free plan covers 1,200 monthly active users and 30 REST requests per minute, which is more than enough to evaluate it. From the user's side it looks like Privy — phone or email, no seed phrase, no overlay on the swap — and the createWallet call is the same shape.

Gotchas, in order of severity:

• Same mainnet trap as the wallets kit: if you do not pass the network passphrase into the Para signer hook, it defaults to the public network.
• Para's SDK currently pins stellar-sdk 14.6.1 while my project is on 16. As long as only XDR strings cross the boundary it does not matter, but it could.
• The SDK lazily imports ethers even when you only use Stellar. You never touch EVM, you still download it.
• I could not find an export option for your share of the key. In principle you should be able to take your share and do the computation locally; check developer.getpara.com for the current answer.

Matias made the point that a wallet relying on a backend is a bad wallet, and it is the honest trade-off of this whole meeting. In Web3 you can own everything — the seed phrase, the key, the money — but the onboarding will never feel like signing in with Google. Every kit above picks a different spot on that line. Pick yours knowingly.

One Thing Every Social-Login Kit Shares​

When you connect Freighter, you bring an account that already exists. When Blux, Privy, or Para create a G-account from scratch for a Google or email login, that account is unfunded, even on testnet. Hit Friendbot before you do anything else, or you will drown in errors that look unrelated. Most of you know this; with over 170 viewers on the call and a lot of new Stellar builders in the ecosystem, it was worth saying.

Passkey Kit vs. Smart Account Kit​

I ran out of time for a deep dive, so here is the differential. Both give you C-addresses (smart accounts) instead of G-accounts. Passkey Kit is ours and it is hackable: build any kind of transaction, run your own relayer, customize everything. Smart Account Kit sits on OpenZeppelin's audited smart-account contracts and gives you multi-signer auth, policies, and the rest out of the box, maintained upstream. More control, Passkey Kit; more batteries included, Smart Account Kit. If you want a dedicated workshop on either, ask in the Stellar Developers Discord.

Closing​

Adrian in chat brought up Cavos, another embedded-wallet layer with Stellar support that I had not seen yet. We will give it a proper look in a future meeting. We ended around 200 viewers, I promised to drop the gallery repo in the comments, and I meant it when I said I want more of these strictly-coding sessions — comparing infrastructures side by side instead of only showcasing projects. If there is a comparison you want next, say so. See you next week.

A Short One, For a Good Reason​

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

What the Builder Summit Is​

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

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

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

The Winners: 12 Across 6 Tracks​

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

Privacy: Confidential Tokens & Private Payment Wallets​

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

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

Enterprise Compliance & RWA​

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

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

Anchors & Ramps: Regional Kits​

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

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

Anchors & Ramps: Emerging-Market Yield​

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

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

Agentic Payments​

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

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

CLI Plugins & Dev Tooling​

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

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

Closing​

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

Live from Stellar House​

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

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

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

Private Does Not Mean Illegal​

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

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

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

Why Hide Amounts but Not the Addresses?​

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

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

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

Auditors, Viewing Keys, and the Escrow Question​

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

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

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

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

C-Addresses, Passkeys, and Key Derivation​

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

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

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

Wallet Hygiene: Retention Windows and Replay​

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

Timing Leaks, Scale, and the Road to Mainnet​

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

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

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

Bonus Round: Confidential Agentic Payments​

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

Closing​

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

Two Developer Advocates, One Call​

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

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

CCTP in One Paragraph​

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

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

The Demo: Stellar to Arc​

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

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

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

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

The Gotchas: Getting USDC Into Stellar​

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

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

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

Solana, ATAs, and Every Chain's Opinion​

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

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

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

What's Next for the Demo​

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

Closing​

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

Stellar Quest Is Back​

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

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

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

Guest: Hypertron — Private Payments and Operations for Businesses​

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

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

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

The Application Layer​

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

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

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

The Privacy Stack​

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

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

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

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

The Fine Print​

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

Closing​

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

The Week I Mostly Shut Up​

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

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

What Raven Actually Is​

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

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

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

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

The Sources: Lumen Loop and Stellar Light​

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

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

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

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

Truth Is a Garden​

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

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

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

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

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

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

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

Other questions from chat, rapid-fire:

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

Tangents Worth Keeping​

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

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

Closing​

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

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