2026-08-06

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.