Disclosure is deliberate.
People should understand what a use case needs and choose what to share, with whom, and for how long.
ORUVEXAPRIVACY, WITH PROOFA MORE DELIBERATE WAY TO PARTICIPATE ONCHAIN
Your activity can be public.
Your life doesn’t have to be.
We’re exploring tools that give people more control over what they reveal when they participate onchain. Privacy should be understandable, usable, and verifiable.
CHOICE / VERIFICATION / CLARITY
01 / THE CONTEXT
Public by design.
Personal by consequence.
Open ledgers make transactions independently verifiable. But repeated activity can also reveal relationships, habits, and patterns that users never intended to publish as a profile.
A SIMPLE LINKABILITY PATH
01
One public actionA transaction appears under a pseudonymous address.
02
Repeated activityTiming, counterparties, and usage patterns accumulate.
03
Connected contextPublic and offchain signals may make the address easier to interpret.
The goal is not to make systems unverifiable. The goal is to make unnecessary personal exposure a deliberate choice wherever the technology allows.
02 / THE PRINCIPLES
Prove what matters.
Protect what doesn’t.
Three commitments guide the concept from research to product decisions.
Claims should be checkable.
Prefer open mechanisms and verifiable evidence over trust-me language or opaque assurances.
Limits belong in the open.
Explain trust assumptions, tradeoffs, metadata exposure, and failure modes in plain language.
03 / THE APPROACH
Privacy is a system property.
A thoughtful privacy experience must consider more than what is written onchain. Interfaces, RPC providers, timing, device data, and user habits can all shape what observers learn.
ONCHAIN DATANETWORK METADATAUSER EXPERIENCESELECTIVE DISCLOSURE
A
Understand the dataMap what is public, inferred, or held by intermediaries.
B
Minimize exposureAsk what information a task actually requires.
C
Prove the necessaryWhere feasible, verify a claim without disclosing its full underlying data.
D
Explain the remainderTell users what protections do not cover.
Conceptual approach only. These statements describe design goals, not shipped product features or guarantees.
04 / TRUST & LIMITS
Trust begins with specific questions.
Who are we protecting against?
Any real product must define observers, data sources, and the conditions it is designed to address.
What could become harder?
Privacy features can affect usability, cost, performance, and composability. These tradeoffs need honest explanation.
What stays exposed?
No privacy claim should imply that all metadata, endpoints, devices, or counterparties are protected unless proven.
05 / BUILDING IN PUBLIC
Research first. Claims follow evidence.
PHASE 01
Listen & map
Document user needs, risks, and the privacy landscape.
PHASE 02
Model & prototype
Test concepts and make assumptions visible.
PHASE 03
Review & validate
Invite technical review before describing capabilities as real.
PHASE 04
Ship transparently
Publish documentation, limitations, and change history alongside releases.
This is a proposed process, not a delivery schedule. Dates and milestones will be added only when confirmed.
06 / RESEARCH NOTES
Start with primary sources.
ORUVEXA’s concept is informed by public work across Ethereum. These links are context, not endorsements or partnerships.
Ethereum privacy roadmap
OPEN SOURCE ↗Research directions spanning private reads, private writes, and private proving.
Privacy on Ethereum
OPEN SOURCE ↗Background on user choice, selective disclosure, and privacy infrastructure.
EIP-5564: Stealth Addresses
OPEN SOURCE ↗A standard proposal exploring stealth address mechanisms.
Privacy Cluster leadership announcement
OPEN SOURCE ↗Ethereum Foundation context on coordination around privacy work.
07 / FAQ
Questions we should answer clearly.
Is ORUVEXA a live product?
No. This site is a brand and product concept preview. It does not claim that a working product is available.
Does privacy mean hiding everything?
No. The design direction is about deliberate disclosure and minimizing unnecessary exposure while preserving verifiability where possible.
What does ORUVEXA protect today?
Nothing is being represented as protected today. Specific capabilities must be documented and verified before launch claims are made.
Is ORUVEXA affiliated with Ethereum Foundation or the projects linked here?
No affiliation or endorsement is implied. The research links are public references only.
Will there be a token?
This concept page makes no token announcement and does not describe an investment opportunity.
08 / IDENTITY SYSTEM
One visual language, across every surface.
Open aperture. Quiet grid. Signal mint. Built to make the idea legible without borrowing another project’s identity.
ORUVEXA is a working name. Name, domain, trademark, and social handle availability have not been checked.
09 / INTERACTIVE PRIVACY LAB
See how context can accumulate.
This illustrative model shows how multiple public signals may increase the chance of linking activity. It is an educational visualization, not a real identity tool, chain analysis, or security assessment.
Before a transaction: queries to infrastructure providers can reveal which addresses or contracts you are interested in, along with timing and network metadata. Research explores ways to reduce what a provider can infer.
ILLUSTRATIVE SIGNAL MIX
ILLUSTRATIVE CORRELATION SURFACE
40%
The percentage is a made-up visual score to explain accumulation, not a measured probability.
10 / FIELD NOTES & INDUSTRY DISPATCHES
Privacy is moving from niche feature to protocol conversation.
A curated reading list of public research and ecosystem updates. These are third-party industry sources, not ORUVEXA announcements or endorsements.
Ethereum’s privacy roadmap
The roadmap groups work around private reads, private writes, and private proving—covering user queries, transaction exposure, and selective disclosure.
READ PRIMARY SOURCE ↗Protocol priorities: privacy as a research arc
The Foundation describes privacy as one of several multi-fork research arcs, with a long-term goal of stronger protocol-level guarantees.
READ PRIMARY SOURCE ↗EIP-8182 proposes private ETH and token transfers
This peer-reviewed proposal explores a protocol-managed shielded pool. A proposal is not a deployed protocol feature; status can change through review.
READ THE EIP ↗Privacy UX and infrastructure constraints
A Devconnect security discussion highlights user experience, RPC tracking, private data recovery, and infrastructure as open challenges.
READ PRIMARY SOURCE ↗Privacy works best as a crowd
Ethereum.org explains why broad adoption matters: a privacy tool used by only a small group can make those users easier to distinguish.
READ THE EXPLAINER ↗Stealth addresses: reduce address linkability
EIP-5564 specifies a stealth-address scheme intended to reduce public linkage between a recipient’s identity and incoming payments.
READ THE SPEC ↗Items are selected for relevance, not endorsement. Dates and proposal status should be rechecked before reposting.
11 / LAUNCH ROOM
ORUVEXA / EARLY CONCEPT
We’re building the conversation before we make promises.
Follow the research, challenge the assumptions, and help shape what clear privacy UX should explain.
01 / THIS WEEK
Publish the principles and the first research notes.
Publish the principles and the first research notes.
02 / NEXT
Share an annotated product concept and invite critique.
Share an annotated product concept and invite critique.
03 / LATER
Only announce implementation milestones when they are real and reviewable.
Only announce implementation milestones when they are real and reviewable.
Social account and community links are placeholders until official channels are created and verified.
12 / COMMUNITY SIGNAL
Help us ask better questions.
What would you want to verify without making your full activity history public?
Choose a topic to see the concept response.
This local demo stores no vote and sends no data.
CHOICE BY DESIGN✳OPEN RESEARCH✳VERIFIABLE CLAIMS✳HONEST LIMITS✳CHOICE BY DESIGN✳OPEN RESEARCH✳
A NOTE ON THE NAME
A oruvexa is not a wall.
It is a boundary you can choose.
ORUVEXA is a working identity for a project exploring practical privacy and selective disclosure. The name is a metaphor for control and context—not a claim that activity disappears or becomes untraceable.
A strong privacy product should make the boundary visible: what is shared, what is withheld, who can learn from it, and what evidence supports the claim.
THE WORLD WE WANT TO BUILD FOR
Participation should not require a permanent dossier.
Ship in public without exposing every user.
A team wants a transparent application and auditable rules. Users still deserve a way to avoid making every interaction a durable public profile. The challenge is to distinguish system transparency from personal exposure.
Prove eligibility without publishing identity.
A community may need to limit participation to people who meet a requirement. The product question is whether the requirement can be verified while sharing less underlying information.
Use a network without becoming its product.
Users should be able to understand the data trails created by wallets, applications, RPC providers, and public ledgers—and have better choices where the technology permits.
Inspect assumptions, not just outcomes.
Researchers and auditors need enough technical detail to examine mechanisms, threat models, and tradeoffs. Privacy should not mean that the system itself is beyond scrutiny.
THE MANIFESTO
The internet taught us to share by default. Public ledgers made those choices permanent and composable.
We believe people should participate without surrendering every detail. We believe systems can be transparent while individuals retain room to choose.
We believe a claim should be verifiable, a boundary should be understandable, and a limitation should be stated plainly.
We do not promise invisibility. We work toward better choices.
Privacy is the space to act without being fully exposed.
ORUVEXA / PRINCIPLES FOR AN OPEN NETWORK
A FIELD GUIDE TO PRIVACY LANGUAGE
Words matter. So do their boundaries.
Privacy discussions often use terms as if they mean the same thing. They do not. This short glossary is here to make product claims more precise.
Pseudonymity
IDENTIFIER ≠ REAL NAMEAn address may not contain a legal name, but repeated activity can still be correlated or linked with outside information.
Confidentiality
CONTENT CONTROLSome information is hidden from some observers. A credible description states who can and cannot see it.
Metadata
CONTEXT AROUND DATATiming, network requests, device signals, and interaction patterns may reveal information even when transaction contents are protected.
Selective disclosure
REVEAL A SUBSETShare only a specific claim or field with a chosen party, while keeping unrelated information undisclosed.
Zero-knowledge proof
PROVE WITHOUT REVEALING INPUTA cryptographic proof can establish that a statement is true without revealing the full data used to establish it.
Threat model
WHO / WHAT / WHENA description of the adversaries, information, and conditions a system is designed to protect against.
DESIGN RULES WE WILL HOLD OURSELVES TO
Privacy claims must survive careful reading.
RULE / 01
Say what the system does.
Describe the actual mechanism and the data it handles. Avoid vague phrases such as “military grade” or “fully private” when a specific explanation is possible.
RULE / 02
Separate shipped work from aspiration.
Every capability should carry a status: research, prototype, testnet, production, deprecated. Roadmaps are intentions, not guarantees.
RULE / 03
Make independent review possible.
Publish documentation and review artifacts when available. Do not use “audited” as a general quality label; identify scope, version, reviewer, and findings.
RULE / 04
Respect the user’s attention.
Explain consequential choices in the interface, at the moment they matter. Avoid burying trust assumptions in legal language alone.
RESEARCH JOURNAL / EDITORIAL SERIES
Questions before answers.
NOTE 001
What does “private” mean in a public system?
Start by listing observers. A chain explorer, a wallet provider, a node operator, a counterparty, and a block builder may each see different slices of context. One label cannot describe them all.
NOTE 002
Can transparency and confidentiality coexist?
They can address different objects. A system’s rules and proofs can be open to inspection while user-specific information is minimized or selectively disclosed.
NOTE 003
Why does privacy need good UX?
If protective behavior is difficult, costly, or confusing, users may opt out. Clear defaults and understandable recovery paths are part of a privacy design.
NOTE 004
What does adoption change?
Some privacy systems become more useful as more people participate. Adoption can improve the anonymity set, but it does not automatically remove metadata or implementation risks.
NOTE 005
How should a project talk about compliance?
Describe specific technical options and jurisdictional context carefully. Avoid broad guarantees about legality or compliance; those depend on facts and applicable rules.
THE VISUAL LANGUAGE
Quiet surfaces. Clear signals.
The interface uses dark mineral tones to hold focus, a fine grid to nod to public infrastructure, and a mint aperture as the signal for user choice. The open circle is intentionally incomplete: a boundary with an opening, not a locked box.
Motion should be slow and purposeful. Reveal information through masks and focus states; avoid glitch effects that make privacy feel like deception or evasion.
Palette: Void #080B10 / Paper #F3F5F7 / Slate #8994A3 / Signal Mint #83F0C8
PUBLICATION DESK / SAMPLE ANNOUNCEMENTS
Launch communication, ready to adapt.
Meet ORUVEXA.
We’re exploring how people can participate onchain with more control over what they reveal. We’ll publish our principles, research notes, and assumptions as the work develops. Early concept. No product claims yet.
Start with the questions.
Who can observe this interaction? What can they infer? What information does the task require? We think privacy design starts with specific questions—and honest answers.
Help us challenge the assumptions.
What should a wallet explain before you sign? What does a useful privacy control look like? We’re collecting questions before we make promises.