2026-08-27

August 27, 2026 · Kaan Kacar, Developer Advocate

​

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.