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 anauditor_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 chosenauditor_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.