8. Privacy Analysis
Question: What information is hidden, from whom, and under what assumptions?
This chapter analyzes the privacy properties of GhostShard v0 and the information available to different classes of observers.
GhostShard does not attempt to achieve perfect anonymity or conceal the existence of transactions. Instead, it seeks to make ownership relationships, payment relationships, and wallet reconstruction computationally difficult by restructuring how ownership is represented and transferred on-chain.
The analysis is organized around the privacy properties that emerge from GhostShard's central design thesis:
Privacy is a property of ownership topology rather than transaction concealment.
Accordingly, this chapter focuses on what observers can infer from publicly visible protocol activity, what information remains hidden, and the assumptions under which those privacy guarantees hold.
8.1 Ownership Unlinkability
Question: Can an observer reliably determine who owns a shard?
Ownership unlinkability is the foundational privacy property of GhostShard.
If ownership can be reliably mapped to identities, then transaction graphs, transfer histories, and wallet reconstruction become possible regardless of any other privacy mechanisms. Consequently, the primary objective of the ownership model is to prevent observers from establishing durable links between on-chain ownership objects and real-world identities.
GhostShard achieves this through the combination of stealth address derivation, disposable ownership, shard retirement, and the elimination of persistent ownership containers.
flowchart LR
A[Meta Address]
--> B[Viewing Key]
--> C[Spending Key]
D[Ephemeral Key]
B --> E[ECDH Shared Secret]
D --> E
C --> F[Shard Derivation]
E --> F
F --> G[One-Time Shard]
8.1.1 Stealth Address Derivation
Every shard is represented by a stealth address derived from:
- The recipient's viewing public key.
- The recipient's spending public key.
- A fresh ephemeral key pair generated by the sender.
The derivation procedure is described formally in Chapter 5.
The resulting shard address is uniquely derived for a specific recipient and transaction while remaining cryptographically unlinkable to the recipient's public meta-address.
An observer can see:
- The shard address.
- The sender's ephemeral public key.
- The associated transaction data.
However, without access to the recipient's private viewing key, the observer cannot determine which recipient produced the corresponding shared secret used during shard derivation.
Consequently, ownership cannot be inferred directly from on-chain address data.
This property establishes the first layer of ownership privacy: observers can identify that a shard exists, but cannot reliably determine who owns it.
8.1.2 Disposable Ownership
Every shard is intended for exactly one spend.
Once a shard participates in a valid transfer, its corresponding entry in the isShardSpent mapping is permanently set to true.
A spent shard can never be reused.
This eliminates ownership accumulation, a common weakness in traditional account-based systems.
In conventional wallet architectures, a single address may receive funds repeatedly over long periods of time. If an observer successfully links that address to an identity, all historical and future activity associated with the address becomes attributable to the same owner.
GhostShard prevents this form of longitudinal analysis.
Each shard appears exactly once as an ownership object and disappears after use, preventing observers from building persistent ownership histories around individual addresses.
8.1.3 Shard Retirement
After a shard is spent, it becomes economically inactive.
Although EIP-7702 delegation remains attached to the address unless explicitly cleared, the shard itself is permanently retired from the ownership graph.
A retired shard:
- Cannot be spent again.
- Cannot re-enter circulation.
- Cannot participate in future ownership transitions.
Consequently, even if ownership attribution were somehow achieved after a shard has been consumed, the information provides little value because the associated assets have already moved into newly derived shards.
Ownership knowledge does not propagate forward through the system.
8.1.4 Absence of Persistent Ownership Containers
GhostShard intentionally avoids persistent ownership containers.
The protocol does not maintain:
- Wallet accounts.
- Ownership registries.
- User balances.
- Address-based asset inventories.
The user's meta-address functions only as an off-chain discovery primitive and does not participate directly in transaction execution.
Ownership exists solely as a collection of independently derived shards.
The only persistent secret is the user's root seed, which never appears on-chain.
Because ownership is fragmented across disposable stealth addresses rather than aggregated into persistent containers, observers lack a stable object around which ownership attribution can accumulate.
This property forms the architectural foundation of GhostShard's privacy model.
Privacy is achieved not by concealing ownership containers, but by eliminating them entirely.
8.1.5 Observer Knowledge
Given an arbitrary shard address observed on-chain, an external observer cannot reliably determine:
- Which meta-address owns the shard.
- Which real-world identity controls the shard.
- Whether two shards belong to the same owner.
- The complete set of shards controlled by a particular user.
- The historical ownership chain leading to the shard.
The observer can determine only that the shard exists and participated in protocol activity.
Ownership attribution requires information that never appears on-chain, namely the recipient's private viewing key and the secrets derived from it.
Under the assumption that secp256k1 and ECDH remain secure, ownership remains cryptographically unlinkable to external observers.
8.2 Sender Privacy
Question: Can an observer determine who initiated a private transfer?
Sender privacy concerns whether protocol activity can be attributed to a specific user.
In conventional account-based systems, the account that authorizes a transfer is also the account that appears on-chain as the transaction sender. This creates a direct and persistent link between ownership and transaction activity.
GhostShard separates these roles.
Users authorize mesh transactions through shard signatures and delegated execution rights, while transaction inclusion is performed by a relayer. Consequently, the entity that appears on-chain as the transaction sender is not the entity that authorized the transfer.
flowchart LR
A[User Authorization]
--> B[Signed Mesh Bundle]
--> C[Relayer Submission]
--> D[GhostRouter Execution]
As a result, transaction execution and transaction authorization become distinct observable events.
8.2.1 Separation of Authorization and Submission
In the v0 architecture, users never submit mesh transactions directly to the blockchain.
Instead, users construct and authorize a mesh bundle locally. The completed bundle is then forwarded to a relayer, which broadcasts the transaction and invokes the router.
As a consequence:
- The relayer appears on-chain as the transaction sender.
- The user's meta-address never appears as
msg.sender. - The user's identity is not exposed through transaction submission.
An observer can identify the relayer that submitted the transaction but cannot directly identify the user that authorized it.
8.2.2 Observer Knowledge
For a given mesh transaction, an external observer can determine:
- That a transaction occurred.
- Which relayer submitted it.
- Which shards participated in execution.
- Which output shards were created.
However, the observer cannot reliably determine:
- Which user authorized the transaction.
- Which real-world identity controlled the participating shards.
- Which meta-address originated the transfer.
The execution record therefore reveals protocol activity without revealing the identity responsible for authorizing that activity.
8.2.3 Architectural Note: Future Execution Models
The sender privacy properties described in this section are specific to the v0 execution architecture.
In v0, transaction submission is performed by a relayer because shard addresses do not maintain native-token balances and therefore cannot independently fund execution. As a result, the relayer appears on-chain as the transaction sender.
Future versions of GhostShard may explore execution models in which a shard itself acts as the transaction-originating account.
Such architectures could become possible if:
- Shards are capable of holding native assets sufficient to fund execution.
- Future account-abstraction systems support sponsored execution without requiring relayer-originated transactions.
- New execution frameworks allow ownership objects to initiate transactions directly while preserving privacy and sponsorship guarantees.
Under these models, a shard could potentially appear as the transaction sender while remaining unlinkable to a persistent user identity.
These approaches remain future work and are not part of the current protocol design.
Importantly, this would change the execution architecture rather than the ownership model. Ownership privacy in GhostShard derives from disposable stealth-address ownership and the properties described in Section 8.1, not from the identity of the transaction submitter.
8.2.4 Limitations
Sender privacy is not absolute.
Infrastructure Visibility
Paymasters and relayers may possess information unavailable to external observers.
A sponsoring paymaster may associate a user identity with a transaction request, while a relayer may observe network-level metadata associated with submission.
These observations arise from infrastructure participation rather than from information revealed on-chain.
Ownership Correlation Within a Transaction
All input shards participating in a mesh transaction are authorized together.
Consequently, observers can infer that the consumed shards belonged to the same authorization domain at execution time, even though they cannot determine the identity controlling that domain.
Infrastructure Collusion
A colluding paymaster and relayer may combine identity information and network metadata to perform stronger attribution analysis than either party could independently.
Mitigating this risk requires organizational separation, independent operators, or future trust-minimized infrastructure designs.
8.3 Recipient Privacy
Question: Can observers determine the recipient of a payment?
Recipient privacy concerns whether an observer can identify the intended receiver of a transfer.
In conventional account-based systems, recipient addresses appear directly within transactions and often accumulate long-lived histories that can be linked to real-world identities.
GhostShard replaces persistent recipient addresses with disposable stealth addresses derived uniquely for each output. Consequently, recipients do not appear directly on-chain during transaction execution.
flowchart LR
A[Recipient Meta Address]
--> B[Viewing Key]
--> C[Spending Key]
D[Ephemeral Public Key]
B --> E[Shared Secret]
D --> E
C --> F[Stealth Address]
E --> F
F --> G[ERC-5564 Announcement]
8.3.1 Announcement and Discovery
Every output shard created during mesh execution is accompanied by an ERC-5564 announcement.
The announcement contains:
- The newly derived stealth address.
- The sender's ephemeral public key.
- Encrypted metadata required for recipient discovery.
Announcements are publicly visible and are emitted as part of normal protocol operation.
However, visibility of an announcement does not imply visibility of its recipient.
An observer can determine that a shard was created, but cannot determine who owns that shard. Recipient discovery requires information available only to the intended recipient.
As a result, announcements reveal ownership creation without revealing ownership attribution.
8.3.2 Recipient Attribution Resistance
Recipient privacy derives from the stealth-address construction described in Chapter 5.
Each output is associated with a uniquely derived stealth address that can be recognized only by parties possessing the appropriate viewing key.
Because fresh randomness is used for every output:
- Payments sent to the same recipient produce unrelated on-chain addresses.
- Multiple outputs cannot be reliably linked to the same recipient.
- Recipient identities cannot be inferred from observed stealth addresses.
An observer therefore lacks a reliable method for mapping observed outputs to recipient identities.
8.3.3 Encrypted Announcement Metadata
The metadata associated with each announcement is encrypted before publication.
As described in Chapter 5, only parties capable of reconstructing the corresponding shared secret can decrypt the announcement contents.
To external observers, announcement metadata appears as authenticated ciphertext.
Consequently, observers cannot determine:
- Asset-specific transfer information.
- Recipient-specific transfer information.
- The contents of the announcement payload.
The announcement reveals that ownership was created, but not the context associated with that ownership.
8.3.4 Absence of Public Recipient Resolution
GhostShard does not maintain a public ownership registry.
Meta-addresses do not participate directly in transaction execution and are not required to be publicly associated with identities.
As a result, observers lack any authoritative mechanism for resolving stealth addresses back to recipient identities.
Even if a stealth address is observed, there is no public mapping that allows an observer to determine who controls it.
8.3.5 Observer Knowledge
Given an arbitrary ERC-5564 announcement, an external observer can determine:
- That a new shard was created.
- The stealth address associated with that shard.
- The ephemeral public key used during derivation.
- That encrypted metadata exists.
However, the observer cannot reliably determine:
- Which recipient owns the shard.
- Which meta-address the shard belongs to.
- Whether multiple announcements belong to the same recipient.
- The contents of the encrypted metadata.
Recipient attribution therefore remains computationally infeasible under the assumptions described in Chapter 5.
8.4 Recipient–Change Ambiguity
Question: Given a mesh transaction's outputs, can an observer determine which outputs represent payments and which represent change?
Recipient–change ambiguity is one of GhostShard's primary privacy properties.
Even when all outputs of a mesh transaction are publicly visible, an observer cannot reliably determine which outputs belong to transaction recipients and which outputs return value to the sender. Because recipient outputs and change outputs are created using the same cryptographic construction and announced through the same protocol mechanisms, they appear indistinguishable on-chain.
8.4.1 Output Partition Ambiguity
Consider a mesh transaction that creates (M) output shards.
From an observer's perspective, the outputs must be divided into two categories:
- Recipient outputs.
- Sender change outputs.
Without additional information, every non-empty partition of the output set is a plausible interpretation.
The number of valid partitions is:
where the subtraction of two excludes the trivial cases in which all outputs are interpreted as recipient outputs or all outputs are interpreted as change outputs.
The ambiguity grows exponentially with the number of outputs.
| Outputs ((M)) | Valid Partitions |
|---|---|
| 2 | 2 |
| 4 | 14 |
| 6 | 62 |
| 8 | 254 |
| 10 | 1022 |
Even modest output counts therefore generate a large number of plausible ownership interpretations.
8.4.2 Multi-Recipient Ambiguity
Future versions of GhostShard may support batching payments to multiple recipient meta-addresses within a single mesh transaction.
In that setting, ambiguity extends beyond identifying recipient outputs versus change outputs.
Suppose an observer somehow knew which outputs belonged collectively to recipients. The observer would still be unable to determine how those outputs should be grouped into recipient ownership domains.
Given \((R)\) recipient-owned outputs, the number of possible ownership partitions is given by the Bell number:
The first few Bell numbers are:
| Recipient Outputs (\((R)\)) | Bell Number (\((B_R)\)) |
|---|---|
| 1 | 1 |
| 2 | 2 |
| 3 | 5 |
| 4 | 15 |
| 5 | 52 |
| 6 | 203 |
| 7 | 877 |
| 8 | 4,140 |
For example, three recipient-owned outputs \(({A,B,C})\) can correspond to:
Thus:
Even if recipient-owned outputs could somehow be isolated, the ownership structure of those outputs remains ambiguous.
8.4.3 Amount Ambiguity
Even if an observer could correctly identify which outputs belong collectively to recipients and which belong collectively to change, a further inference problem remains:
Which outputs collectively represent the logical payment amount?
GhostShard does not represent payments as single outputs.
Instead, value may be fragmented across multiple recipient-owned shards and multiple change shards. Consequently, observers cannot assume that any individual output corresponds directly to the transferred amount.
For a transaction producing a recipient-owned output set:
the observer must determine which subset of outputs represents the actual payment amount and which subsets represent ownership fragmentation.
This introduces an additional combinatorial search problem.
Given \((n)\) recipient-owned outputs, the number of possible non-empty output combinations is:
Each combination represents a plausible interpretation of the logical payment value.
For example, consider four recipient-owned outputs:
An observer must consider:
and every other non-empty subset as a potential payment composition.
Consequently, identifying recipient-owned outputs does not automatically reveal the transferred amount.
Amount reconstruction therefore becomes a separate inference problem layered on top of recipient–change ambiguity and ownership ambiguity.
This ambiguity is particularly important because many blockchain-analysis techniques rely on value matching and arithmetic conservation to trace ownership relationships across transactions.
GhostShard intentionally weakens such analysis by allowing ownership value to be fragmented across multiple independent shards.
As a result, observers must determine:
- Which outputs belong to recipients.
- Which recipient outputs belong to the same owner.
- Which subsets of those outputs collectively represent a logical payment amount.
Each stage compounds the uncertainty of the previous stage.
8.4.3 Structural Indistinguishability
The combinatorial ambiguity described above is meaningful only because recipient outputs and change outputs are structurally indistinguishable.
GhostShard achieves this through several mechanisms.
Uniform Announcement Format
Every output is announced through the same ERC-5564 announcement structure.
No field identifies whether an output represents a payment or change.
flowchart LR
A[Recipient Output]
--> C[ERC-5564 Announcement]
B[Change Output]
--> C
Uniform Cryptographic Construction
Recipient outputs and change outputs are derived using the same stealth-address construction described in Chapter 5 and Section 8.1.
Both use:
- ECDH-derived shared secrets.
- Identical address derivation procedures.
- Identical announcement formats.
Consequently, output addresses reveal no ownership role.
Encrypted Metadata
Announcement metadata is encrypted before publication.
Observers cannot inspect ownership information, recipient information, or transfer details contained within announcements.
Output Randomization
Output ordering carries no semantic meaning.
Observers cannot infer ownership roles from transaction layout or output position.
8.5 Wallet Reconstruction Resistance
Question: Can an observer reconstruct a user's ownership graph over time?
Wallet reconstruction resistance is not an independent privacy mechanism. It emerges from the interaction of ownership unlinkability, sender privacy, recipient privacy, and recipient–change ambiguity.
However, GhostShard introduces an additional property:
Ownership attribution does not accumulate over time.
In conventional account-based systems, ownership information compounds. Every new transaction adds information to an existing ownership graph. Addresses persist, balances accumulate, and historical observations remain useful indefinitely.
GhostShard behaves differently.
Each shard is a disposable ownership object that is consumed exactly once. When a shard is spent, the previous ownership state is destroyed and replaced by newly derived shards.
As a result, ownership observations do not naturally carry forward through time.
8.5.1 Temporal Fragmentation
Consider an observer attempting to track a user across multiple transactions.
At time \((t_0)\) the observer may identify a set of candidate shards.
At time \((t_1)\) those shards are consumed and replaced by new output shards.
To continue tracking ownership, the observer must determine:
- Which outputs belong to recipients.
- Which outputs belong to change.
- Which ownership transitions occurred.
- Which newly created shards remain under the original owner's control.
Because these questions cannot be answered deterministically, ownership attribution becomes increasingly uncertain after each transaction.
flowchart LR
A[Ownership State t0]
--> B[Mesh Transaction]
--> C[Ownership State t1]
--> D[Mesh Transaction]
--> E[Ownership State t2]
A -. Attribution Hypothesis .-> C
C -. Attribution Hypothesis .-> E
Each transition introduces additional uncertainty.
8.5.2 Non-Accumulating Ownership Information
Traditional blockchain analytics relies on the assumption that ownership information compounds over time.
GhostShard breaks this assumption.
Even if an observer develops a plausible ownership hypothesis for one transaction, subsequent transactions continuously fragment that hypothesis through:
- Disposable ownership.
- Stealth-address derivation.
- Recipient–change ambiguity.
- Independent output construction.
Ownership attribution therefore does not become progressively easier as transaction history grows.
Instead, uncertainty compounds alongside protocol activity.
8.5.3 Observer Knowledge
An observer may construct ownership hypotheses.
However, the observer cannot reliably determine:
- The complete set of shards controlled by a user.
- The historical ownership path connecting multiple shards.
- The future ownership state resulting from a transaction.
- The total balance controlled by a specific ownership domain.
Consequently, wallet reconstruction remains an inference problem rather than a graph-analysis problem.
Under the assumptions described in Chapter 5, ownership relationships become increasingly difficult to reconstruct as ownership transitions accumulate over time.
8.6 NFT Privacy
Question: Can an observer determine which NFTs a user owns or track NFT ownership over time?
NFT privacy presents unique challenges because NFTs are indivisible, uniquely identifiable assets with publicly visible ownership records on transparent blockchains.
In conventional ERC-721 systems, ownership is permanently exposed through the ownerOf(tokenId) mapping. Anyone can query the current owner of a token and reconstruct ownership history through transfer events.
GhostShard changes the ownership layer rather than the NFT itself.
NFTs remain standard ERC-721 assets, but ownership is held by disposable stealth-address shards rather than publicly identifiable accounts.
8.6.1 NFT Ownership Privacy
When an NFT is deposited into GhostShard, ownership is transferred to a shard address.
From the perspective of the ERC-721 contract:
- The NFT is owned by the shard.
- The shard appears as an ordinary address.
- No relationship exists between the shard and the owner's meta-address.
Because shard addresses are derived through the stealth-address construction described in Chapter 5 and Section 8.1, observers cannot determine which user controls the NFT.
flowchart LR
A[User]
--> B[Meta Address]
--> C[Stealth Shard]
--> D[ERC-721 Ownership]
D --> E[NFT]
An observer can identify the address currently holding the NFT but cannot determine the identity behind that address.
8.6.2 NFT Transfer Privacy
NFT transfers inside GhostShard occur through mesh execution.
When an NFT moves between ownership domains:
- The input shard is consumed.
- A new output shard is created.
- Ownership is transferred to the new shard.
- The new shard is announced through ERC-5564.
Observers can see that ownership moved from one shard address to another.
However, they cannot determine:
- Who owned the original shard.
- Who owns the new shard.
- Whether the transfer was a payment, a self-transfer, or a change operation.
- Whether the transfer occurred between different users.
Ownership transitions remain visible, but ownership attribution remains hidden.
8.6.3 Portfolio Reconstruction Resistance
NFT portfolio analysis normally relies on ownership clustering.
If multiple NFTs belong to addresses that can be linked to the same owner, observers can reconstruct a user's complete collection.
GhostShard disrupts this process.
Each NFT may reside in an independent shard:
- Different NFTs may be held by different stealth addresses.
- Shards possess no observable ownership relationship.
- Ownership does not accumulate into a persistent account.
Consequently, observers cannot reliably determine:
- How many NFTs a user owns.
- Which NFTs belong to the same owner.
- The complete NFT holdings associated with a particular user.
Portfolio reconstruction therefore reduces to the broader wallet-reconstruction problem discussed in Section 8.5.
8.6.4 Asset-Type Confidentiality
GhostShard encrypts announcement metadata before publication.
As discussed in Chapter 5 and Section 8.3, asset-specific information is contained within encrypted announcement metadata that can only be decrypted by the intended recipient.
As a result, observers cannot determine:
- The asset type associated with an output.
- The token contract involved.
- NFT-specific metadata.
- Token identifiers associated with newly created shards.
To an external observer, output announcements appear as uniformly structured encrypted objects.
This means that NFT outputs are indistinguishable from other asset outputs at the announcement layer.
8.6.5 Observer Knowledge
An observer can determine:
- That an NFT exists.
- The shard address currently holding the NFT.
- That ownership moved between shard addresses.
- The public transfer history recorded by the underlying ERC-721 contract.
However, the observer cannot reliably determine:
- Which user owns the NFT.
- Which meta-address controls the holding shard.
- Whether multiple NFTs belong to the same owner.
- The complete NFT portfolio of a user.
- The ownership relationships between NFT-holding shards.
Under the assumptions described in Chapter 5, NFT ownership remains hidden behind the same stealth-address and ownership-fragmentation mechanisms that protect fungible assets.## 8.7 Metadata Confidentiality
Question: What information is revealed through announcements, and what remains confidential?
GhostShard uses ERC-5564 announcements as the recipient-discovery mechanism. Because announcements are publicly visible, privacy depends on carefully controlling which information must remain observable and which information can be concealed.
The objective is not to hide the existence of a transfer, but to minimize the amount of information that can be learned from the announcement itself.
8.7.1 Announcement Structure
Every output shard is accompanied by an ERC-5564 announcement containing:
| Field | Visibility |
|---|---|
schemeId |
Public |
stealthAddress |
Public |
ephemeralPubKey |
Public |
metadata |
Partially encrypted |
The public fields are required for recipient discovery and protocol interoperability.
The metadata field contains both publicly visible and encrypted components.
8.7.2 Public Information
An observer can determine:
- That an announcement was emitted.
- The stealth address associated with the new shard.
- The ephemeral public key used during stealth-address derivation.
- The transaction in which the announcement was created.
- The timing of the announcement.
These values are necessary for recipients to discover newly created shards and therefore cannot be fully concealed.
Importantly, visibility of these fields does not reveal ownership.
As discussed in Sections 8.1 and 8.3, a stealth address remains unlinkable to a recipient identity without the corresponding viewing key.
8.7.3 Encrypted Information
Certain announcement data is encrypted using keys derived from the shared secret established during stealth-address derivation.
Only parties capable of reconstructing that shared secret can decrypt the protected contents.
Examples include:
- Optional sender-identifying information.
- Recipient-specific transfer metadata.
- Future protocol extensions requiring selective disclosure.
To external observers, this information appears as authenticated ciphertext.
Consequently, the existence of metadata is visible, but its contents remain confidential.
8.7.4 Metadata Length Considerations
Metadata length can itself become a side channel.
If different announcement types produce ciphertexts of different sizes, observers may infer information about the underlying transfer even without decrypting the contents.
Future versions of GhostShard may standardize encrypted metadata lengths through padding mechanisms.
Such an approach would prevent observers from distinguishing announcements based on payload size and would reduce metadata-based fingerprinting opportunities.
This remains future work and is not required for the core privacy guarantees described in this paper.
8.7.5 Privacy Implications
Metadata confidentiality complements the privacy properties discussed throughout this chapter.
Announcements reveal that ownership objects were created, but do not reveal:
- Who owns them.
- Who created them.
- How outputs should be interpreted.
- The ownership relationships between announcements.
As a result, announcements function primarily as discovery signals rather than ownership disclosures.
The blockchain records that new shards exist, while the information required to interpret those shards remains accessible only to the intended recipients.## 8.8 Privacy Set Growth
Question: How do GhostShard's privacy guarantees evolve as protocol adoption increases?
Unlike privacy systems that rely on optional privacy pools or specialized transaction types, GhostShard embeds privacy directly into its ownership model.
As protocol participation grows, the set of plausible ownership interpretations available to an observer grows as well. Additional users, shards, and transactions increase uncertainty rather than reducing it.
8.8.1 Privacy by Architectural Default
GhostShard does not distinguish between "private users" and "normal users."
Every deposit creates shards.
Every transfer creates stealth-address outputs.
Every recipient discovers ownership through the same announcement mechanism.
As a result, all users participate in the same privacy system automatically.
There is no separate privacy pool, shielded mode, or alternate transaction format.
The protocol therefore avoids the anonymity fragmentation that often occurs when privacy features are optional.
flowchart LR
A[User A]
--> D[GhostShard Ownership Model]
B[User B]
--> D
C[User C]
--> D
D --> E[Shared Privacy Set]
8.8.2 Ownership Population Growth
Ownership unlinkability depends on the number of plausible owners that could control a shard.
Let
denote the number of protocol participants.
For an observed shard, an external observer must consider all users as potential owners.
Consequently, the ownership anonymity set grows approximately with protocol adoption:
As additional users join the system, ownership attribution becomes increasingly uncertain.
8.8.3 Shard Population Growth
Each new deposit creates additional ownership objects.
Let
denote the number of active shards visible within the system.
Every additional shard introduces new ownership possibilities and increases the difficulty of ownership clustering.
Because shards are independently derived and disposable, increases in shard count do not create stronger ownership signals.
Instead, they expand the space of possible ownership assignments.
8.8.4 Transaction Growth
Every mesh transaction introduces additional ownership transitions and output interpretations.
As transaction volume increases:
- More stealth addresses are created.
- More announcements are emitted.
- More ownership paths become possible.
- More recipient-versus-change interpretations emerge.
Consequently, the number of plausible transaction interpretations grows significantly faster than transaction count itself.
Observers are therefore required to evaluate an increasingly large set of candidate ownership histories.
8.8.5 Growth Dynamics
| Growth Factor | Privacy Effect |
|---|---|
| More users | Larger ownership anonymity set |
| More shards | Greater ownership ambiguity |
| More transactions | More ownership interpretations |
| More announcements | More candidate recipients |
| Uniform participation | No identifiable privacy subgroup |
GhostShard's privacy model strengthens as adoption increases.
Additional protocol activity expands the space of plausible ownership interpretations available to an observer, making attribution, clustering, and ownership reconstruction progressively more difficult over time.
8.9 Trust Assumptions and Privacy Boundaries
As of the time of this paper, no privacy system provides absolute protection against every possible adversary.
The privacy properties described throughout this chapter are subject to explicit trust assumptions, infrastructure assumptions, and cryptographic assumptions. This section defines the primary privacy boundaries of GhostShard v0 and identifies the information that may still be available to certain participants.
8.9.1 Paymaster Visibility
In the current architecture, a sponsoring paymaster performs user verification before issuing sponsorship approval.
As part of this process, the paymaster may learn:
- The user's identity according to its verification model.
- The sponsored transaction bundle.
- Transaction timing.
- Asset transfer details.
Consequently, a malicious or compromised paymaster may associate user identities with protocol activity.
This visibility is a consequence of the sponsorship model rather than a weakness in the privacy architecture itself.
GhostShard hides users from public observers, not necessarily from infrastructure providers that participate directly in transaction authorization.
Potential Mitigations
- Self-funded execution.
- Multiple competing paymasters.
- Future threshold-signing architectures.
- Future privacy-preserving sponsorship mechanisms.
8.9.2 Network-Level Metadata Leakage
Transaction bundles are submitted to relayers before appearing on-chain.
A relayer may therefore observe:
- Submission timing.
- Network metadata.
- IP-address information.
- Request patterns.
Even when transaction contents remain private, network-level observations may provide additional attribution signals.
This class of attack exists independently of GhostShard and affects most blockchain systems that rely on network communication.
Potential Mitigations
- VPNs.
- Tor.
- Private relay infrastructure.
- Future peer-to-peer submission networks.
8.9.3 Value Correlation Attacks
An observer possessing external knowledge about expected transfer values may attempt to reduce ambiguity by analyzing observable asset movements.
For example, if an observer knows:
- The approximate value being transferred.
- The assets entering a transaction.
- The assets leaving a transaction.
then some recipient–change interpretations may become less plausible than others.
GhostShard does not eliminate this possibility entirely.
However, ownership fragmentation, output partition ambiguity, and randomized output construction significantly reduce the effectiveness of simple value-tracing techniques.
Potential Mitigations
- Larger ownership fragmentation.
- Multi-shard spending.
- Larger output sets.
- Shared infrastructure usage.
8.9.4 Temporal Correlation
Timing information remains publicly observable.
An observer may attempt to correlate:
- Receipt of an output shard.
- Subsequent spending activity.
- Related external events.
For example, rapidly spending a newly received shard may provide additional information to a determined observer.
Temporal observations do not directly reveal ownership, but they may reduce uncertainty when combined with external knowledge.
Potential Mitigations
- Delayed spending.
- Ownership fragmentation.
- Independent transaction timing.
- Increased network usage and participant diversity.
8.9.5 Shard Visibility
Input shards participating in execution are visible on-chain.
Observers can determine:
- Which shards were consumed.
- Which shards were created.
- Which shards participated in a transaction.
If an external party independently links a shard to an identity through off-chain information, that shard's participation in a transaction becomes observable.
This limitation is inherent to ownership-transition systems that publish transaction activity on a public ledger.
GhostShard mitigates the impact through disposable ownership:
- Shards are spent once.
- Shards are permanently retired after use.
- Ownership information does not naturally propagate forward.
Consequently, even successful attribution of a historical shard provides limited visibility into future ownership.
8.9.6 Counterparty Knowledge Accumulation
Repeated counterparties may possess information unavailable to ordinary blockchain observers.
Over time, a recurring recipient can accumulate knowledge about:
- Historical payments they received.
- Expected payment schedules.
- Typical transfer amounts.
- Business relationships.
- External contextual information.
This information may allow a counterparty to make stronger ownership inferences than a passive observer relying solely on public blockchain data.
For example, a supplier receiving regular payments from the same organization may gradually develop a more accurate model of that organization's transaction behavior than an external analyst.
Such observations may improve:
- Temporal correlation.
- Amount correlation.
- Ownership inference.
However, these observations arise from direct participation in economic activity rather than from weaknesses in GhostShard's privacy architecture.
Importantly, counterparties still do not automatically obtain:
- Viewing-key access.
- Ownership discovery capabilities.
- Wallet reconstruction capabilities.
- Visibility into unrelated counterparties.
- Visibility into unrelated transactions.
Their knowledge remains limited to information acquired through repeated interaction.
This behavior closely resembles privacy in physical cash systems.
Individuals who repeatedly transact with one another naturally accumulate contextual knowledge that external observers do not possess.
GhostShard preserves this property while preventing those observations from expanding into protocol-wide ownership visibility.
8.9.7 Infrastructure Collusion
A paymaster and relayer operating together may possess substantially more information than either party individually.
Such an entity could potentially combine:
- User identity information.
- Transaction details.
- Network metadata.
- Timing information.
GhostShard does not currently prevent this form of infrastructure-level correlation.
Mitigating collusion requires either:
- Independent infrastructure operators.
- Competitive infrastructure markets.
- Future cryptographic protocols that minimize infrastructure trust.
8.9.8 Cryptographic Assumptions
The privacy guarantees of GhostShard ultimately depend on the security of the cryptographic primitives described in Chapter 5.
In particular:
- Stealth-address privacy relies on the hardness of elliptic-curve discrete logarithms over secp256k1.
- Shared-secret derivation relies on the security of ECDH.
- Metadata confidentiality relies on HKDF-SHA256 and AES-256-GCM.
If these assumptions fail, ownership privacy may be compromised.
The encrypted metadata component is expected to remain secure against known practical attacks for the foreseeable future.
However, large-scale fault-tolerant quantum computers would threaten secp256k1-based constructions and could potentially weaken ownership unlinkability.
Post-quantum migration remains future work.
8.10 Privacy Summary: Ownership Unlinkability
The primary privacy objective of GhostShard is ownership unlinkability: preventing observers from reliably determining which on-chain assets, outputs, and transactions belong to the same ownership domain.
Unlike privacy systems that attempt to conceal transaction existence, GhostShard operates under the assumption that observers possess complete visibility of blockchain state. Transactions, announcements, execution traces, and ownership transitions remain publicly observable.
The protocol instead focuses on preventing reliable reconstruction of ownership relationships from that information.
Ownership unlinkability emerges from the composition of several independent ambiguity layers, each obstructing a different stage of the ownership-reconstruction process.
An observer attempting to reconstruct ownership relationships must simultaneously answer the following questions:
| 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? |
Partition ambiguity prevents reliable classification of outputs into recipient and change domains.
Ownership ambiguity prevents recipient clustering by obscuring how recipient-owned shards should be grouped into ownership sets.
Amount ambiguity prevents observers from using value-based heuristics to reconstruct ownership relationships between shards.
Temporal ambiguity prevents reliable linkage of ownership activity across time, weakening transaction graph analysis and longitudinal tracking.
Importantly, these ambiguity layers are not independent. They reinforce one another.
Solving any single inference problem does not reveal ownership relationships unless the remaining inference problems are also solved.
For example:
- Identifying a recipient-owned shard set does not reveal how many recipients participated.
- Reconstructing a logical payment amount does not reveal which recipient owns that amount.
- Linking transactions across time does not reveal how outputs should be partitioned into ownership domains.
Consequently, ownership reconstruction becomes a multi-dimensional inference problem rather than a direct observation problem.
GhostShard therefore derives privacy not from hiding transactions themselves, but from preventing reliable reconstruction of ownership relationships between transaction outputs, recipients, and future ownership transitions.
The resulting privacy guarantee is ownership unlinkability: the inability of an observer to confidently determine which assets, outputs, or transactions belong to the same participant despite complete access to on-chain information.
Under the cryptographic assumptions described in Chapter 5, ownership attribution remains an inference problem with multiple unresolved dimensions rather than a deterministic consequence of blockchain transparency.