Stellar Is Testing a New Middle Ground Between Public Ledgers and Private Payments

Deep Dives

Research / Privacy

The crypto industry has spent years treating transparency and privacy as opposing choices. A recent set of experiments on Stellar is testing a more complicated possibility: public settlement where different pieces of a payment can be hidden, while applications retain configurable compliance controls.

The newest experiment is Stellar Private Payments, or SPP, a shielded-payment system built by Nethermind in collaboration with the Stellar Development Foundation. The developer preview went public on August 24, 2026, and is currently running on testnet rather than Stellar mainnet.

That distinction matters. This is not a production payment network or evidence that private institutional payments have reached widespread adoption.

But it is a useful project to watch because it approaches one of public blockchain infrastructure’s least comfortable problems from a different direction: financial transparency is useful for verification, but often unacceptable for actual business activity.

⚡ Why This Is Interesting

SPP does not simply add a generic “private mode” to Stellar. It separates privacy into different components and makes some compliance policies configurable at the pool level. Combined with Stellar’s separate Confidential Tokens experiment, it suggests an emerging architecture where applications choose what becomes public, what stays private and which conditions users must satisfy to transact.

Public money is not the same as public financial data

Public blockchains make verification unusually easy because transactions are visible on a shared ledger. That property is valuable when proving asset issuance, settlement and state transitions.

It creates a less attractive side effect for businesses.

Payroll, supplier relationships, treasury balances and B2B settlement amounts are normally sensitive. Publishing those relationships permanently can reveal information about customers, counterparties, pricing and financial positions.

This has produced a persistent tension around institutional blockchain adoption. Companies may want shared, programmable settlement infrastructure without wanting their financial graph to become a public dataset.

INTERPRETATION: privacy therefore increasingly looks less like an optional feature for public blockchains and more like infrastructure required for certain real-world financial uses.

The interesting question is what kind of privacy gets built.

Stellar is experimenting with two different privacy lanes

Stellar’s current approach is notable because it does not treat privacy as a single technical property.

Its recent developer previews distinguish between at least two situations.

Experiment What remains public What becomes private Potential use case
Confidential Tokens Sender and recipient identities remain visible Balances and transfer amounts Payroll, treasury and settlement between known counterparties
Stellar Private Payments Deposits and withdrawals at the edges of the pool Transfers inside the pool, including counterparties and amounts B2B payments or other flows where the financial relationship itself is sensitive

FACT: Stellar’s Confidential Tokens developer preview uses a contract wrapper that can hide balances and transfer values while leaving the participating addresses visible.

FACT: Stellar Private Payments takes a different approach. Funds enter a shared shielded pool. Transfers inside that pool use zero-knowledge proofs so the public ledger can verify that a valid transfer occurred without exposing the specific notes being spent, the transfer amount or the recipient.

The boundary is deliberate. Deposits into and withdrawals from the pool remain observable.

That creates a model that can be summarized as public edges, private middle.

For gram.rest, however, the mechanics are less interesting than what the architecture represents: developers are beginning to get a menu of privacy properties instead of choosing between complete public visibility and complete transaction concealment.

Why this is happening now

The timing is tied to infrastructure that has been arriving underneath the applications.

Stellar’s Protocol 25, called X-Ray, introduced cryptographic host functions designed to make zero-knowledge proof verification practical for smart contracts. Protocol 26, Yardstick, added further capabilities used by the current privacy stack.

The result is that privacy experiments can increasingly happen at the application layer while proof verification is handled directly by the network.

That is a meaningful shift. Privacy systems previously risked requiring expensive computation, specialized infrastructure or external verification paths. More capable base-layer cryptography gives developers additional design space without requiring the entire blockchain to become private.

Signal to Watch Privacy may become modular. Instead of competing primarily over whether a blockchain is “private” or “transparent,” applications may increasingly select privacy properties according to the financial activity they are handling.

The compliance experiment is the real differentiator

Private transfers alone are not new in crypto. The harder problem is building privacy that regulated financial applications can actually use.

This is where Stellar Private Payments becomes more interesting as a research direction.

The testnet implementation includes configurable Association Set Providers, or ASPs. A pool can be configured around allow-lists, block-lists or a combination of both. Users then prove that they satisfy the required condition without exposing their complete transaction history.

The broader Association Set idea predates SPP. Research around Privacy Pools has explored how zero-knowledge proofs could allow users to demonstrate that funds belong to acceptable sets — or are excluded from known problematic sets — without revealing every transaction behind them.

Nethermind’s implementation adapts that idea for Stellar, currently using key-level association sets. According to Nethermind, the design is also exploring features such as selective disclosure and viewing mechanisms for authorized oversight.

SIGNAL: this reflects a broader change in privacy research. The design target is increasingly not maximum secrecy at all costs. It is selective visibility: enough confidentiality for legitimate financial activity combined with mechanisms that applications can configure around legal or operational requirements.

Privacy and compliance are still not magically reconciled

There is an important reason not to overstate the breakthrough.

Adding allow-lists, block-lists or association-set providers does not eliminate the policy trade-offs around private money. It relocates some of them.

Who decides which identities are blocked? Which provider defines an acceptable association set? What happens when several jurisdictions disagree? Can administrators abuse freezing powers? Does a compliance provider become an important point of control?

The cryptography can prove that a rule was followed without revealing unnecessary data. It cannot decide whether the rule itself is fair, accurate or desirable.

That distinction is essential.

Risk / Overhype Check

SPP is not production-ready. Stellar explicitly describes the current release as a developer preview. It is running on testnet, development is ongoing and the contracts should not be treated as finished financial infrastructure.

Privacy depends on participation. Shielded pools become more useful when more unrelated activity shares the same privacy set. Thin usage can make transaction timing and amounts easier to correlate even when the cryptography itself works as designed.

Compliance introduces governance. Configurable access controls solve one institutional problem while creating another: somebody may have meaningful influence over who can participate.

Better technology does not guarantee adoption. Wallet UX, proof-generation performance, integration complexity, legal treatment and institutional risk policies may matter as much as the underlying cryptography.

Why this matters beyond Stellar

The most interesting part of this experiment is not whether Stellar becomes the dominant privacy network.

It is the design direction.

Public blockchain finance has historically exposed information that conventional financial systems routinely keep confidential. Meanwhile, fully shielded systems can create difficult compliance and integration questions for regulated businesses.

A modular model creates more possibilities.

A company might want counterparties to remain visible but hide invoice values. Another application might need the financial relationship itself hidden from outside observers. An institution could require users to satisfy an eligibility policy while still avoiding publication of every transaction they make.

Those are different privacy requirements. Treating them as different products rather than one universal privacy setting is arguably closer to how financial systems actually operate.

Interpretation The longer-term competition in blockchain privacy may be less about which system hides the most information and more about which system lets applications reveal exactly what is necessary — and nothing more.

Who should pay attention

Payments and stablecoin teams should watch whether privacy becomes a practical feature that can be added to existing assets rather than requiring a separate privacy-native currency.

Financial institutions should watch the distinction between transaction confidentiality and anonymity. Hiding commercially sensitive values while retaining known counterparties may be considerably easier to integrate than fully anonymous settlement.

Wallet developers have a different challenge. Cryptographic privacy becomes valuable only if users can manage keys, proofs and private balances without introducing unacceptable friction.

Privacy researchers should watch how association sets evolve. SPP’s current key-based model differs from deposit-based approaches explored in the original Privacy Pools research, and Stellar says further mechanisms are still being designed.

Other blockchain ecosystems should watch the product architecture itself: base-layer cryptographic primitives combined with multiple application-level privacy systems may prove more flexible than trying to impose one privacy model across an entire network.

The signals that would make this much more important

A developer preview deserves attention, not conclusions.

Several developments would strengthen the thesis that configurable privacy is moving toward practical financial infrastructure.

🔭 Where to Look Next
  • Mainnet deployment: whether Stellar Private Payments or Confidential Tokens graduate from testnet experiments after security review.
  • Real assets: whether major stablecoins or tokenized financial instruments actually use these privacy layers in production.
  • Privacy-set size: whether shielded pools attract enough independent activity to provide useful privacy in practice.
  • Compliance architecture: how Association Set Providers evolve and whether multiple independent providers can coexist.
  • Selective disclosure: whether users and institutions gain workable methods to reveal specific transactions without exposing their broader financial history.
  • User experience: whether wallets can make private transfers feel comparable to ordinary payments rather than specialized cryptographic workflows.
  • Cross-ecosystem adoption: whether similar configurable privacy patterns appear across other payment and tokenization networks.

A different way to think about onchain privacy

Crypto’s privacy debate is often framed as a binary choice: transparent ledgers on one side, anonymous transactions on the other.

The experiments now appearing on Stellar suggest that this framing may be too narrow.

One payment system can hide balances. Another can hide transaction amounts. Another can conceal counterparties inside a shared pool. Access policies can potentially be proven without publishing the user’s full financial history.

None of those experiments solves the policy, governance or usability problems surrounding financial privacy.

But together they point toward a more granular model of blockchain infrastructure.

That is what makes Stellar Private Payments worth exploring now. It is not simply another zero-knowledge application. It is an attempt to turn privacy from an ideological setting into a configurable property of financial software.

Key Takeaway

Stellar’s current privacy experiments are interesting because they reject the assumption that public blockchains must choose between total transparency and total concealment. If configurable privacy proves secure, usable and operationally acceptable, the more important question may become not whether a transaction is private, but precisely which parts of it need to be visible — and to whom.

Research status: September 14, 2026. Stellar Private Payments and Confidential Tokens are developer previews and should not be interpreted as production-ready infrastructure. This material is for editorial and informational purposes and is not investment advice.

Rate article
Add a comment