Title: A_maximally_simple_L1_privacy_roadmap
Category: Uncategorized

Author: vbuterin
Date: 2025-04-11T01:29:18.272Z

See also: pcaversaccio’s roadmap: Ethereum Privacy: The Road to Self-Sovereignty - Privacy - Ethereum Research
These are my current thoughts on how we can practically improve the state of privacy experienced by Ethereum’s users in a way that is very light on Ethereum consensus changes. This covers four primary key forms of privacy:

Privacy of onchain payments
Partial anonymization of onchain activity inside applications
Privacy of reads to the chain, ie. RPC calls
Network-level anonymization

This roadmap can be combined with a longer-term roadmap that makes deeper changes to L1, or privacy-preserving application-specific rollups, or other more complex features.
Roadmap

Incorporate privacy tools (eg. Railgun, Privacy Pools) into existing wallets. Wallets should have a notion of a shielded balance, and when you send to someone else, there should be a “send from shielded balance” option, ideally turned on by default. This should all be designed to feel maximally natural from a UX perspective. Users should NOT have to download a separate “privacy wallet”
Move the ecosystem toward “one address per application” by default. This is a major step, and it entails significant convenience sacrifices, but IMO this is a bullet that we should bite, because this is the most practical way to remove public links between all of your activity across different applications. Moving toward such a design also works very naturally with in-application wallets, and the new workflows required to make this work look very similar to what is needed already with cross-chain interoperability (eg. depositing funds to a chain from one of multiple sources)
Make send-to-self privacy-preserving by default - needed to make (2) work
Implement FOCIL and EIP-7701, and make sure to implement a version of FOCIL that is EIP-7701-friendly. Along with EIP 7701’s account abstraction benefits, this allows protocols like PP, Railway, Tornado etc to operate without needing relays / public broadcasters, greatly simplifying the development and maintenance of such protocols. FOCIL greatly improves censorship resistance of all transactions, including privacy-preserving transactions.
Incorporate TEE-based RPC privacy into existing wallets, as a short-term mitigation. Automata has a version of this already; this needs to be verified and hardened as much as possible. This allows users to interact with RPC nodes while getting stronger assurances that their private data is not being collected.
Replace TEEs with private information retrieval (PIR) once the tech becomes ready. PIR offers cryptographic guarantees, and so is much stronger than TEEs, but it is currently not efficient enough for large datasets. Potentially we can consider hybrid approaches, eg. use TEEs to isolate regions of the state of size 2**20, and use PIR inside of those, shifting the constants up over time as PIR becomes more efficient.
Wallets should connect to multiple RPC nodes, optionally through a mixnet, ideally use a different RPC node per dapp. If we also add security armoring to RPC nodes (ie. light client support), it becomes practical for a user to trust a much larger set of RPC servers. This reduces metadata leakage.
Work on proof aggregation protocols to allow multiple privacy-protocol transactions to share a single onchain proof. This greatly reduces the gas costs of privacy protocols.
Work on privacy-preserving keystore wallets (see more detailed explanations in this post). This allows users to upgrade their account verification logic (algorithm or keys) in one transaction, and have this change be immediately reflected in all private notes that they control (across L1 and all L2s!), without publicly linking those notes.

At the end of this, we will have a world where:

A large portion of sends are private, and private sends are default in many cases
Activity inside of each individual application is public, but the link between your activity in application A and your activity in application B is private
Privacy guarantees hold not just against adversaries passively observing the chain, but also adversaries operating RPC nodes

Author: auryn
Date: 2025-04-11T01:59:23.554Z

vbuterin:

shifting the constants up over time as PIR becomes more efficient.


What is the gap between current reality and required latency to make PIR RPCs viable?

Author: privacycaviar
Date: 2025-04-11T02:02:22.695Z

Tornado Cash is still the largest privacy pool on Ethereum, and with OFAC sanctions now lifted, I’m curious why it’s not mentioned here. Is it being excluded mainly due to compliance concerns?

Author: Sofianel5
Date: 2025-04-11T02:17:09.594Z

No reason to have compliance concerns anymore, we won the case.

Author: Designer-F
Date: 2025-04-11T02:18:42.516Z

Tornado Cash is a better choice, no censorship, large privacy pool, and free to use if relayers are not needed

Author: NelsonMcKey
Date: 2025-04-11T03:13:26.164Z

Along with EIP 7701’s account abstraction benefits, this allows protocols like PP, Railway, Tornado etc to operate without needing relays / public broadcasters…

See point four.

Author: TimDaub
Date: 2025-04-11T05:35:47.136Z

vbuterin:

Move the ecosystem toward “one address per application” by default. This is a major step, and it entails significant convenience sacrifices, but IMO this is a bullet that we should bite, because this is the most practical way to remove public links between all of your activity across different applications. Moving toward such a design also works very naturally with in-application wallets, and the new workflows required to make this work look very similar to what is needed already with cross-chain interoperability (eg. depositing funds to a chain from one of multiple sources)


What does this mean for ENS usage? My understanding is that most users currently have one intentionally publicly known address that they use to onboard to apps. And then they have other wallets where they store their wealth, trade, etc. Is an „application“ here: wealth store, trading, public theatre, or is an application: Uniswap, Aave?

Author: vbuterin
Date: 2025-04-11T06:43:16.653Z

Two possible answers:

You can have a single address that is your ENS address, but that’s not the address you use for apps by default.
Stealth addresses (so, others can use your ENS data to send things to a fresh address that you control, without others being able to publicly link it)

Author: MacBudkowski
Date: 2025-04-11T07:48:33.131Z

You can have a single address that is your ENS address, but that’s not the address you use for apps by default.


Okay, so if we follow this path, I think we have to think about UX. E.g., we could ask users before connecting to each app if they want to make their actions public.
And also educate them that if they make their actions public, they can build their onchain reputation. So it’s like “sending a DM on Signal” vs. “sending a tweet". One is better for privacy, one is better for building reputation.
If we don’t do it, we will slow down onchain identity by a lot. And this is a thing that differentiates blockchain addresses from e-mails.
If you run web2 social (like Reddit), users send their gmail addresses to create an account. As a company you have to accept all of them because you cannot check if one address is more legit than the other. It makes it pretty easy to astroturf and run bot networks.
If you run onchain social, you can take users’ wallets and check some predefined parameters. E.g., how old is the address, how many txs it did, what are relationship with other potentially problematic addresses and so on. We already been doing that at Kiwi and it’s been very helpful to track these behaviors.
On Farcaster, where every action is public by default (and wouldn’t be impacted since they use their own P2P network), you can even create these forensics graphs like this one. And of course everyone can do them, which is a big plus.
If - on the other hand - everyone was doing 100% private onchain actions, it’d cripple onchain social defensive capabilities.
PS: We already see onchain identity fragmentation because of in-app wallets, as I described here and lately also noted by nonlinear.

Author: kdenhartog
Date: 2025-04-11T08:52:52.959Z

Number 2 is effectively just recreating 3P cookies if we don’t do it. Web2 has already shown this isn’t a good path forward with everyone except Google having disabled them by default:



Kyle Den Hartog



Web3 is Reintroducing Cross-Origin Tracking Accidentally
We should expect that when the user shares their address that will act as implied consent for cross-origin tracking in the same way cookie notices act as a prompt for tracking.





As for number 7, Oblivious HTTPS is another alternative solution so that we don’t face latency tradeoffs. We need RPC services to enable support for it though.

Author: kdenhartog
Date: 2025-04-11T09:03:29.846Z

Option 1 faces the tradeoff that onchain transactions still leak data. This works IfF we also get 1 by default.

Author: Styliann
Date: 2025-04-11T12:14:53.268Z

This is a roadmap for Privacy in the traditional sense - i.e. Anonymity.
How about encrypting balances and amounts, with the ability to selectively reveal them to a third party? Any thoughts on the confidential ERC20 standard?

Author: iAmMichaelConnor
Date: 2025-04-11T12:37:02.685Z

I’m helping design the Aztec privacy rollup, so this is right up my street. We want to make sure we keep pace with Ethereum’s privacy needs. I have some questions / comments.





 vbuterin:

This allows users to upgrade their account verification logic (algorithm or keys) in one transaction, and have this change be immediately reflected in all private notes that they control (across L1 and all L2s!), without publicly linking those notes


A nullifier keypair for a note can’t easily be rotated, because (a) the nullifier for a given note is deterministically* derived from the secret key of the nullifier public key that “owns” the note, and (b) rotation can lead to double-spend bugs.

(a) A nullifier is usually something like hash(hash(note), nullifier_secret_key_1). If you rotate your nullifier keypair, the nullifier for this note still relies on the old nullifier keypair.
(b) You could detach the “owner” of the note from the nullifier keypair, by storing the nullifier public key against the “owner” in a keystore registry. The owner could then rotate their nullifier public key  in the registry. But there’s then a risk that the “owner” can spend the note twice: once by deriving a nullifier from the first nullifier secret key; and a second time by rotating their nullifier public key and deriving second nullifier from the second nullifier secret key.
* There’s a way to solve this, but it’s constraint-heavy, and requires proving: when the rotation took place; when the note was created; and that the ‘old’ nullifier hasn’t already been used.






 vbuterin:

Move the ecosystem toward “one address per application” by default


Aren’t there examples of complex defi flows (which compose many smart contract function calls together) which would require the user’s address to be the same across all the different smart contracts?
Even a simple lending contract stores information against a borrower’s address, but also calls separate token contracts to decrement/increment balances of that same borrower’s address.
Consider more crazy complex flows like: take a flash loan; use the borrowed asset to provide liquidity elsewhere; use the LP tokens and stake them somewhere else; use those staked LP tokens as collateral on another protocol to mint a stablecoin; swap the stablecoin for another asset; repay the flash loan.
… For that crazy flow, isn’t it beneficial for the user’s address to be the same across all those smart contracts?
Would it be more fitting to encourage one address per “defi session” (whatever that might be)?
We’re debating this topic at Aztec, currently.





 vbuterin:

Users should NOT have to download a separate “privacy wallet”


Would it be acceptable if these wallets have to generate and track a new set of secrets, as most privacy tools use snark-friendly secrets that are different from a user’s Ethereum private key?





 vbuterin:

this allows protocols like PP, Railway, Tornado etc to operate without needing relays / public broadcasters


How does this work? How do the gas fees get paid?

Author: jimjim.eth
Date: 2025-04-11T12:41:41.569Z

vbuterin:

“one address per application”


Why cant we just atomically unshield and unshield like how railgun does it with their 0x integration? It would be far more private! It would also be the same UX flow for more endgame privacy like in aztec.

Author: mpeyfuss
Date: 2025-04-11T13:28:26.411Z

This is interesting. Two questions come to mind, from an app developer perspective.
First, having per-app wallets seems to go against the thinking that I can use my wallet across all different applications. Funding those new wallets brings user friction as well. We’ve seen that any additional steps already represent a drop off in user engagement.
Second, what impact would this have on regulation of ETH? I know governments don’t want financial activity hidden from them. Does this pose a threat to users and apps building on Ethereum?
I’m not an expert in privacy so really just asking questions. Cheers!

Author: teddy
Date: 2025-04-11T14:00:30.133Z

On RPC Privacy specifically:
Why choose to move in the direction of TEE->PIR->mixnet instead of focusing on making every wallet be able to run the relevant parts of a node (aka light client?) I feel like going for the former means aiming for an Ethereum ecosystem with privacy guarantees resembling tradfi, while moving in the direction of light clients could yield actually better privacy long-term.

Author: h4x3rotab
Date: 2025-04-11T17:41:12.778Z

I can see a lot of space to explore when using TEE. For example:

Self hosted light client in TEE. We get a solution that doesn’t rely on any single point of failure, but still can outsource the tedious maintenance tasks to some other providers. We can plug it into almost all the wallets or dapp frontend from the day one. There are people exploring running Helios in TEE [2] to achieve this.
Mixnet in TEE. There are also some exploration to run a Tor node in TEE [1]. Since the light client also relies on an upstream RPC provider, it would be a nice addon to redirect all the traffic through a mixnet like Tor to hide the IP address and traffic features.

Links:

/github.com/Dstack-TEE/dstack-examples/tree/main/tor-hidden-service
/github.com/Dstack-TEE/dstack-examples/tree/main/lightclient

(The forum dislike me to post link directly)

Author: SCBuergel
Date: 2025-04-11T21:51:47.165Z

This list is good but IMO too narrowly RPC-focused when thinking about data-harvesting third party services. That is ok for a typical Ethereum wallet of 2018, but (sadly!) not anymore. Unfortunately, a contemporary Ethereum wallet pings a prospering jungle of centralized servers and services for:

gas prices
price feeds
tx simulation
scam checkers
gas-less transactions
cross-chain balances
multisigs with off-chain signature services
a range of indexer data, typically for token balances
token icons (here’s a fun demo showing why this is much more evil than you think!)

All of them reveal some level of personal data. Minimally that is “IP 1.2.3.4 is doing something with Ethereum right now” but usually it is much more and much more personal. So I’d say that we need a general purpose anonymous transport layer, beyond just anonymizing simple RPC calls.

Author: peersky
Date: 2025-04-13T05:49:58.031Z

Instead of submitting as “pinnaple-green-swordwish” many “normal” users want to have notifications in form “Tim submitted his proposal” (for those who has been granted notion about account connection to the sender identity) but keep the submission private.
Especially in case of on-chain governance this allows better level of UX and reducing halo.
This  requires reveal only commit and have 3rd party to host pool of proposals that later is batch revealed, ongoing UX goals for Rankify.it / Peeramid.network  looks like this:
Bot: @Bob sent a proposal. // public commitment & signed by Bob and trusted server holding nullifier
Bot: @Alice sent a proposal. 
Bot: @Georg hurry up!
Bot: @Georg sent a proposal.
Bot: New proposals: A;B;C; // Server reveals & nullifies pool of proposals 
// Voting phase begins <..>
// Tally, posts proofs of data integrity
Bot: Winning proposal was C, it was sent by @Bob


Current plans is to have marketplace for such private pools, enabling users to pick whatever trust guarantees they want (chose between Lit, ICP, TEE, Self hosted MPC etc).
@vbuterin Im having hard time to classify that though, does that fit in your categorization under privacy pools  or aggregation?

Author: ying484
Date: 2025-04-13T18:45:06.899Z

I need someone familiar to teach me all this.

Author: undefined
Date: 2025-04-14T01:02:08.869Z

These next-level ambitions are all promising and important to explore. However, I think more people need to start paying attention to the basics when it comes to privacy.
Have you tried passing your wallet/browser through mitmproxy or burpsuite and checked out just how much information is broadcasted to various endpoints in the cloud? If you use a browser extension wallet, you may be surprised to see traffic that is not visible in Chrome/Firefox developer tools Network tab.
Now see how much you are actually able to prevent leaking by using the wallet settings. Disable any analytics, use your own RPC node, disable optional third-party features, and try again. Compare reality to the privacy policy of the wallet.
The state of privacy in mainstream wallets have gone increasingly worrying over time and I don’t see much talk about that. The features discussed in this thread don’t mean much if balance- and history requests in practice use proprietary unconfigurable vendor servers. Addressing that is not an unsolved technical issue but one where wallet vendors have faced little scrutiny and pushback from the community.
Some deviations and options:

Konkret Wallet is one budding initiative showing a different approach to the browser wallets.
Trezor actually provides the option to do self-hosted and private account-indexing via BlockBook (but on the other hand their connector module is idiomatiacally loading from the cloud…)
TrueBlocks is a great way for expert users with the resources to self-host indexing

All are pretty obscure if not neglected. I think we need to start practice what we preach and addressing the here and now while we consider future possibilities.

Author: undefined
Date: 2025-04-14T01:23:37.288Z

Continuing on the above:
The comment focuses a bit on browser wallets but the points and exercise are equally valid for household hardware and mobile wallets. You may be surprised just how difficult or even unviable it is to use certain hardware wallets privately and/or in an airgapped scenario today.
A bit tangential to the main topic of privacy but related to the larger security story: Just how long-term reliable is a hardware wallet if the vendor-provided app suites for end users won’t function without connections to public cloud servers? How robust its integrations if the vendor SDK and examples integrate with their server endpoints for basic functionality? Are we satisfied with the supply-chain security situation of various modules pulling runtime code from github, npm, and elsewhere? And back to privacy again: How many of these endpoints are TLS-terminated at either Cloudflare, Akamai, or one of the big 4 clouds? How confident are you in the integrity of those with the developing situation in US gov? I think those who understand the implications of such questions should do some research on their own in 2025 before recommending particular vendors to end-users.
Not naming names here because the issue is systemic enough and I really hope this triggers some readers to take a fresh look at the environment we are in.

Author: codebyMoh
Date: 2025-04-14T09:46:08.494Z

We can have ENS as main identity address making sure user can create variation of that address as sub identity same like we have wallet derivation path from seedphrase.
One user might want to remember one Seed but want to use multiple addresses for niche usecases/apps which we should support as decentralised identity so user can navigate addresses to right identity to use. @vbuterin

Author: ml_sudo
Date: 2025-04-14T11:09:32.650Z

Can’t wait for some of these ideas to be implemented. I worry that many users will find it overwhelming and give up. Some users may think they have more privacy than they have, if they use a combination of features but don’t have the right mental models for how they overlap.
We need to build shared mental models on privacy that builders and users can reference, for clarity and efficiency. Otherwise I suspect we’ll see misunderstandings and duplication that may be very expensive in terms of time and mistakes.

Author: sheldrake
Date: 2025-04-14T16:12:06.161Z

Good observation @TimDaub. Our work on Addresso throws a different light on things.
When @vbuterin writes that we need to move to “one address per application”, I’d argue that it will definitely need at least one per application.
Rather than entailing “significant convenience sacrifices”, it should in fact be more intuitive, just as convenient, and, critically, more human. Which for the avoidance of any doubt I also consider to be ‘more Ethereum’! 
We have been given a most beautiful gift … an open source way for anyone to create abundant keypairs with associated UUIDs (wallet addresses) at zero cost without permission almost instantly.
We have been ignoring this abundance for no other reason I can see than received “wisdom”, and yet the abundance is ripe with abstraction potential.
Such abstraction helps us pursue humanity-centered rather than computing-centered design goals, but I won’t attempt to relitigate my essay here! (“Human identity: the number one challenge in computer science”)
If you’re looking for something a little more bite-sized, I can offer the following table.
There’s no doubt that Name Services have their applications, I’d just argue that human identity isn’t one of them if we’re not to render web3 the mother of all bureaucratic machines.




QUALITY
WEB3 NAMING SERVICES e.g. ENS
ADDRESSO




Inspiration
DNS — a naming system for computers, services, and other resources on the Internet or similar networks.
Human life.


Who does the naming?
The entity that controls the address the name resolves to.
We do. The beholders. Everyone making sense of their world.


Relativity
Non-relative.
As desired, e.g. “Mom”, “The school”.


Contexts
Non-contextual.
As desired, e.g. “Bob at work”, “Fred the electrician”.


Descriptive
Not usually because descriptions are relative and/or contextual.
As desired, e.g. “Tall Sarah”, “Kraken my original CEX”.


Abstraction
Partial. The human-readable name is an abstraction of an address.
Fully. Abstracts a person from a singular non-contextual name and therefore from singular addresses.


Plurality
Works against plurality. Acclaimed for setting things up as if we’ll have very few wallets: “Keep your identity consistent across all services and platforms effortlessly. Say goodbye to juggling multiple usernames.”
Ready for a near-future where each of us has hundreds of wallet addresses as contexts vary and as privacy demands. The variety is essential but will be abstracted away.


Privacy
The Cypherpunk’s Manifesto notes “Privacy is the power to selectively reveal oneself to the world.” It’s very hard to do that when you present one (or one dominant) name to the world.
Privacy is enhanced with relativity, contextual variation, subjective description, abstraction, and plurality.

Author: kdenhartog
Date: 2025-04-17T05:52:43.706Z

sheldrake:

We have been given a most beautiful gift … an open source way for anyone to create abundant keypairs with associated UUIDs (wallet addresses) at zero cost without permission almost instantly.
We have been ignoring this abundance for no other reason I can see than received “wisdom”, and yet the abundance is ripe with abstraction potential.


One practical reason we’ve not been able to scale this as a privacy solution is we’re largely limited by asset allocation today. In other words, if all my assets are associated with one key today I can’t suddenly control them with another key easily (EoA issue due to needing to transfer) or cheaply (smart account issue due to gas costs + funds still get correlated AFAIK). I don’t believe this is an unsolvable problem though, just one that we’ve not developed a scalable solution for so the friction defaults the user behavior to reusing the same account for simplicity and cost savings.

Author: sheldrake
Date: 2025-04-17T09:17:05.849Z

Thanks @kdenhartog. Yes, that corresponds precisely to how we’d sum it up 
We’ve concluded that any form of resolution will necessarily require local-first, peer-replicating software. So that’s what we’ve been building. And that’s the design challenge we’d love to work with everyone here to crack.

Author: kladkogex
Date: 2025-04-20T13:44:42.264Z

sheldrake:

We have been given a most beautiful gift … an open source way for anyone to create abundant keypairs with associated UUIDs (wallet addresses) at zero cost without permission almost instantly.


There is a way to create many temporary Ethereum accounts using identity-based signatures (IBS).
The basic idea is that a user publishes a master IBS public key, and then anyone who wants to send assets or messages to that user can generate a unique, temporary address derived from an identity string — such as "user@example.com#session42" — and send assets there.
The user, who holds the corresponding master secret key, can then derive the private key for any of these temporary addresse and spend from them.
The hardest problem to solve here is gas, since to send from a temporary address you would need to first get enough gas into it.

Author: Antonio
Date: 2025-04-20T18:08:19.325Z

Why do envious people delete my comments?!
We will already launch a full-fledged web4 social network Allmint (without backend, with smart contract engin) and such ETH privacy technology will be very useful for ours users! Thanks

Author: Muxailo
Date: 2025-04-22T10:44:25.599Z

Now that RISC-V is trending again — not just as an architecture, but as a philosophy of open, verifiable systems — I can’t help but mention Cartesi.
This is not just another rollup — Cartesi allows you to run full Linux applications in a RISC-V machine, living off-chain, while still maintaining on-chain verification. In other words, Cartesi brings the power of traditional computing stacks to the blockchain world.
Why is this important?

RISC-V + Linux = a familiar environment for devs.
Off-chain verifiable computations = scaling without security trade-offs.
Access to the entire open-source Linux ecosystem = unlimited possibilities for Web3 apps.

Want to build Web3 services with actual computing power like Web2? Look no further than Cartesi.

Author: Muxailo
Date: 2025-04-23T08:45:58.046Z

Heh, the post does sound enthusiastic. I just genuinely believe it’s one of the more underappreciated projects in the space.
What caught my attention is the way Cartesi bridges the gap between traditional software development and blockchain. Running full Linux environments inside a verifiable off-chain context isn’t something you see every day. It opens up dev possibilities that aren’t feasible with traditional smart contracts alone.
Most rollups focus purely on scalability — Cartesi adds actual computing flexibility on top of that. So when I saw RISC-V trending again, I thought it was worth spotlighting a project that’s been quietly pushing innovation in that direction for years.

Author: wschwab
Date: 2025-05-08T11:37:22.586Z

There’s a bit of an elephant in the room wrt tx privacy imho. I’ll start with an example from web2.
Recommendation engines work by looking at a user’s data - if the user’s YouTube usage was private (from YT), YT wouldn’t be able to recommend content, which many users apparently see as a good thing. Tons of internet denizens applaud what Big Tech does with their data, mainly due to only perceiving the good bits. (If they can be called that, and let’s face it, it is useful sometimes.)
While the airdrop meta seems to have largely faded, it often built on a similar principle. Let’s take Optimism Airdrop 1 as an example. I am picking it because it illustrates my point well, but also because iirc many in the community found its criteria praiseworthy. Looking at the list, DAO voting, multisig signing, and Gitcoin contributions are all listed. Would those be from the same address if we were following good privacy hygiene? There was a bonus for ‘overlap’, meaning a single address that met multiple criteria received an allocation greater than the sum of its parts, which would mean that having separate addresses for the voting, signing, and contributions would not have received as much in aggregate. Even worse, many airdrops took to at least attempting to scout out sybils/airdrop farmers, meaning that one user using fresh addresses for each DAO and multisig might not even reap the benefits of having multiple eligible addresses.
We often want aggregation and signal. The idea of onchain identity to some degree views this as axiomatic. There are almost certainly ways that people can retain a ‘main’ account, and use proofs where necessary to prove their ownership of others privately, but my gut feeling is that this would change the UX in a number of applications, and if made user-friendly, would almost certainly need to be handled by wallets in order to be more intuitive. This itself would still open the door to something similar to the current data consent modals in web2 - imagine “the following dApp would like to view your activity in the following addresses”. How many of us will blindly click through most of the time anyway?
The other issue is just how much metadata txs have. Even if the tx doesn’t originate from the same address, it seems inevitable that there will always be some level of data leakage that in aggregate can be correlated to identify the hidden hand signing the transactions. If they don’t, I wonder if that inherently means sacrificing some of the UX we have today.
I’m hoping for good rebuttals. I want to believe that there can be actual privacy, not just theater, without sacrificing UX.

Author: kladkogex
Date: 2025-05-09T12:03:29.795Z

wschwab:

I’m hoping for good rebuttals. I want to believe that there can be actual privacy, not just theater, without sacrificing UX.


Hey - let me know what you think about the BITE protocol we are working on



SKALE Network Forum – 2 May 25




BITE : Solving Blockchain Privacy in Four Phases




dApp Developers




Hey @kladkogex  Great to see our discussion come to life.  Some thoughts from my side:    I think both Phase III and Phase IV bring really unique options that allow the world to move away from “crypto” and more to “decentralized compute” or maybe...