2026-09-17

September 17, 2026 · Kaan Kacar, Developer Advocate

​

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.