# Starknet’s “Private ERC-20”

*What the Terms of Service Actually Say*

By [MODULAR_FORMS_AND_DIGITAL_NORMS](https://paragraph.com/@francos.eth) · 2026-06-16

---

  

I’ve been a Starknet supporter for years.

I run Starknet validators, coauthored the openzeppelin erc6909 cairo contracts, contributed to the cairo compiler and standard library, maintain the zed language extension for cairo and generally view Starknet as one of the most technically ambitious projects in Ethereum.

Which is why I was surprised when I finally sat down and read the Terms of Service for Starknet’s new privacy solution.

Like most people, I usually don’t read Terms of Service. Most users don’t. That’s precisely why I think it’s important to highlight what is written there.

This is not a criticism of the cryptography. Nor is it an accusation of wrongdoing.

It is simply an attempt to answer a basic question:

**What kind of privacy is Starknet actually offering?**

**The Marketing vs. The Legal Documents**

When most crypto users hear terms like:

*   private transfers
    
*   private ERC-20
    
*   privacy layer
    
*   shielded transactions
    

they naturally think of systems such as:

*   Zcash
    
*   Monero
    
*   Tornado Cash
    
*   Railgun
    

Different systems, different tradeoffs, but all generally aim to maximize user privacy and minimize the ability of third parties to inspect transaction histories.

The Starknet Privacy Pool appears to pursue a different goal.

Reading the Terms of Service, the system is explicitly designed around a compliance framework that allows transaction histories to be reconstructed under certain circumstances. In my view this distinction matters.

**The Auditing Entity**

The most important definition in the entire document may be this one:

> “Auditing Entity” is a governance body that holds the private keys required to decrypt Viewing Keys stored in the registry.

The Terms further state:

> “Users must encrypt their private Viewing Key to the Auditing Entity’s public key to enable the compliance framework.”

In other words:

*   every user possesses a viewing key
    
*   every user must provide an encrypted copy to the Auditing Entity
    
*   the Auditing Entity can decrypt that key
    

The Terms also state that:

> “The Auditing Entity may reconstruct audit logs of transaction history, including deposits, withdrawals, amounts, wallet addresses, and timing.”

and may share such information with regulators, law enforcement, auditors, compliance officers, or other authorized parties.

This is a core component of the system’s design.

**Privacy, But Not Anonymity**

The Terms repeatedly emphasize that privacy is limited.

The document states:

> “You acknowledge that the Protocol operates with limited privacy protections and that complete anonymity or confidentiality of transactions cannot be guaranteed.”

The protocol hides sender, receiver, and amount information during normal operation.

However:

*   metadata remains visible
    
*   recipient addresses are exposed during initial channel creation
    
*   complete anonymity is explicitly not guaranteed
    

This is an important distinction.

The system provides privacy from the public blockchain observer, but not necessarily privacy from the designated auditing authority.

**A Comparison With Existing Privacy Solutions**

One reason I found these design choices surprising is that Starknet already has privacy-focused projects exploring different tradeoffs.

For example, Privacy Pools proposes a model where users retain control of their own viewing keys.

If a user later needs to demonstrate the source of funds, satisfy compliance requirements, or provide transaction history to a third party, they can voluntarily reveal that information themselves.

The disclosure capability remains under the user’s control.

The model described in Starknet’s Privacy Pool Terms appears different.

Instead of users exclusively controlling disclosure, the protocol introduces an Auditing Entity that is capable of reconstructing transaction history under certain circumstances.

Reasonable people can disagree about which model is preferable.

But they are fundamentally different trust assumptions.

One places disclosure power primarily with users.

The other places disclosure power within a governance structure.

**The Biggest Unanswered Question**

The document defines the Auditing Entity.

What it does not define is who the Auditing Entity actually is.

As of writing, I have been unable to find public documentation answering questions such as:

*   Who controls the auditing keys?
    
*   Is it a multisig?
    
*   What threshold scheme is used?
    
*   Who appoints members?
    
*   Can members be removed?
    
*   Is StarkWare involved?
    
*   Is the Starknet Foundation involved?
    
*   What constitutes a valid request?
    
*   Is a court order required?
    
*   Under which jurisdiction?
    
*   Are users notified if they are audited?
    
*   Is there transparency reporting?
    
*   Are audit requests published?
    

These questions are not minor implementation details. They are the trust model.

Without answers to them, it is difficult to evaluate the privacy guarantees being offered.

**Why This Matters**

Most crypto privacy discussions focus on cryptography.

But cryptography is only one part of a privacy system.

What else matters?

*   Governance
    
*   Key management
    
*   Legal processes
    
*   Trust assumptions
    

A privacy system where nobody can reveal your transaction history is fundamentally different from a privacy system where a designated entity can reveal it under certain circumstances.

Neither approach is inherently right or wrong.

There are legitimate reasons why some users, institutions, and regulators may prefer auditable privacy over stronger anonymity.

The issue is not that Starknet has built a compliance-oriented privacy system.

The issue is whether users clearly understand the trust assumptions they are accepting.

**My Concern**

My concern is not that the protocol contains an auditing mechanism.

My concern is that many users may hear “private ERC-20” and assume properties that the system does not actually provide.

If the protocol is designed around auditable privacy rather than strong anonymity, then that distinction should be communicated clearly and prominently.

More importantly, users are being asked to trust an Auditing Entity whose identity, governance structure, key management process, jurisdiction, transparency obligations, and oversight mechanisms have not yet been publicly disclosed.

And until those questions are answered, I believe the most important part of the protocol’s privacy model remains undefined.

Privacy is not only about what is hidden.

It is also about who has the power to reveal it.

---

*Originally published on [MODULAR_FORMS_AND_DIGITAL_NORMS](https://paragraph.com/@francos.eth/starknets-private-erc-20)*
