GhostShard: Ownership Fragmentation as a Privacy Primitive for the Post-Pectra EVM
I would appreciate feedback and critique on a privacy architecture I have been exploring called GhostShard.
Paper:
Implementation:
https://github.com/giantgun/ghost-shard-protocol
Disclaimer: The implementation is an unaudited research prototype.
Motivation
Most privacy systems on Ethereum focus on reducing visibility.
Examples include:
-
Shielded state systems
-
Private transaction protocols
-
Confidential balances
-
Encrypted execution
-
Mixer-based approaches
While these systems differ substantially, they often share a common objective: conceal information from observers.
GhostShard explores a different hypothesis:
Privacy loss may be better understood as successful ownership reconstruction rather than simple information exposure.
An observer rarely acts on raw blockchain data directly.
Instead, they observe signals and attempt to reconstruct hidden structures:
Transactions
→ Ownership
→ Identity
→ Relationships
→ Behavioral Patterns
From this perspective, privacy loss occurs when reconstruction succeeds.
This raises a question:
Can privacy be improved by disrupting ownership reconstruction itself rather than primarily hiding information?
Observation
Bitcoin derives much of its practical privacy from ownership fragmentation.
Assets are distributed across many independent outputs rather than accumulated under a persistent account.
Ethereum’s account model naturally produces the opposite effect.
Over time, assets, governance participation, social identity, application interactions, and transaction history accumulate under a persistent address.
This persistent attribution surface enables increasingly accurate ownership reconstruction.
Many higher-order inferences emerge from that persistence.
GhostShard
GhostShard investigates whether recent EVM developments make ownership fragmentation practical within the account model.
The architecture combines:
-
ERC-5564 stealth addresses for private ownership reception
-
EIP-7702 delegated execution for programmable EOA behavior
-
Disposable ownership fragments (“shards”)
-
Many-to-many transaction construction
-
Selective disclosure mechanisms
Rather than maintaining ownership within a persistent account, ownership is decomposed into disposable stealth accounts.
Each spend consumes ownership fragments and creates new fragments.
Over time, ownership continuity becomes increasingly difficult to establish.
The protocol does not attempt to hide that assets exist.
It does not attempt to hide that transfers occur.
Instead, it attempts to make ownership reconstruction fail.
Research Question
The central research question is:
Is ownership fragmentation itself a meaningful privacy primitive?
More specifically:
-
Can privacy emerge from ownership topology rather than hidden state?
-
Can ownership reconstruction be disrupted without requiring shielded balances?
-
Can privacy be achieved while preserving standard EVM assets and composability?
-
Can selective disclosure coexist with ownership fragmentation?
Privacy as Ambiguity Generation
One perspective that emerged during development is that privacy systems may be understood not only by what information they hide, but by what questions they prevent observers from answering.
Rather than creating a single anonymity set, GhostShard attempts to introduce ambiguity across multiple layers of ownership reconstruction.
| Ambiguity Layer | Observer’s Question |
|---|---|
| Partition Ambiguity | Which outputs are recipient payments and which are sender change? |
| Ownership Ambiguity | Which recipient-owned shards belong to the same recipient? |
| Amount Ambiguity | Which shards collectively represent a logical payment amount? |
| Temporal Ambiguity | Which transactions and future spends belong to the same participant? |
The objective is not necessarily to make information invisible.
Instead, the objective is to make reconstruction increasingly uncertain by forcing observers to navigate multiple independent ambiguity layers simultaneously.
A useful way to think about the architecture is that each ambiguity layer compounds the uncertainty introduced by the others.
An observer may identify a transaction.
They may identify a collection of outputs.
They may estimate transferred value.
However, establishing a complete ownership narrative requires successfully resolving partition, ownership, amount, and temporal ambiguity simultaneously.
The central hypothesis is that privacy emerges not from any single concealment mechanism, but from the cumulative effect of unresolved ambiguity across multiple dimensions of ownership reconstruction.
I would be particularly interested in feedback on whether ambiguity generation is a useful framework for evaluating privacy systems and whether these ambiguity layers meaningfully resist modern graph-analysis techniques.
UX Hypothesis
A second hypothesis is that privacy adoption may ultimately be constrained more by user behavior than by cryptography.
Many privacy systems require users to consciously perform privacy-preserving actions:
-
Enter a privacy pool
-
Bridge into a privacy domain
-
Maintain anonymity discipline
-
Avoid mistakes when exiting
In practice, privacy becomes something users must continuously remember to do.
GhostShard explores the opposite direction:
Can privacy emerge from ordinary usage patterns rather than explicit privacy actions?
If ownership fragmentation is built into the ownership model itself, privacy may become a default consequence of participation rather than a specialized activity.
Open Questions
I would greatly appreciate feedback on any of the following:
-
Is ownership fragmentation a meaningful privacy primitive independent of shielded-state approaches?
-
Are there existing systems that explore similar ownership-topology models?
-
What are the strongest graph-analysis attacks against this architecture?
-
How should privacy be measured in systems focused on reconstruction resistance?
-
Does ownership fragmentation meaningfully disrupt higher-order inference (identity, relationship, behavioral reconstruction)?
-
What are the most important security assumptions introduced by EIP-7702-based designs?
-
Are there protocol-level improvements that could make this design space more viable?
I welcome criticism, attack analyses, and alternative perspectives.