2. Design Rationale

GhostShard was not designed as a privacy wrapper around existing EVM accounts. It was designed from the observation that the primary source of information leakage in EVM systems is the persistence of ownership itself.

Most privacy discussions focus on hiding transactions. While transaction privacy is important, transactions are temporary events. Ownership, by contrast, is long-lived state that persists across every interaction performed by a user.

As addresses accumulate assets, interact with applications, and participate in economic activity, they gradually reveal relationships, balances, behavioral patterns, and historical activity. Over time these signals combine to create an increasingly complete picture of the owner.

This observation leads to a different design objective:

Rather than hiding individual transactions, GhostShard attempts to reduce the visibility, persistence, and certainty of ownership.

To achieve this goal, the protocol introduces several architectural concepts that differ significantly from traditional account-based systems:

Disposable ownership through independently controlled shards.
Mesh transactions that coordinate multiple shards within a single execution.
Ownership ambiguity rather than absolute anonymity.
Separation of discovery, ownership, and execution.
Selective disclosure mechanisms that preserve compliance without sacrificing privacy.

The following sections develop these ideas progressively, beginning with the fundamental ownership problem present in all conventional EVM systems and then motivating the design choices that ultimately lead to the GhostShard architecture.

2.1 The Fundamental Privacy Failure of EVM Systems

EVM systems are transparent by design. Every transaction publicly reveals the sender, receiver, transferred asset, amount, execution data, and timestamp. This transparency enables independent verification of network state and is fundamental to the operation of public blockchains.

However, transaction transparency is not the primary privacy failure of EVM systems.

The core insight of GhostShard is that privacy failures on EVM networks are fundamentally ownership failures rather than transaction failures.

A transaction is a discrete event. Ownership is persistent state.

flowchart TD

    T["Transaction"]
        -->|"Exists briefly"| TE["Discrete Event"]

    O["Ownership"]
        -->|"Persists across time"| PS["Persistent State"]

    PS -->|"Reveals"| W["Wealth"]
    PS -->|"Reveals"| R["Relationships"]
    PS -->|"Reveals"| B["Behavior"]
    PS -->|"Reveals"| H["Historical Activity"]

    W -->|"Accumulates into"| ID["Identity Exposure"]
    R -->|"Accumulates into"| ID
    B -->|"Accumulates into"| ID
    H -->|"Accumulates into"| ID

    ID -->|"Creates"| OP["Ownership Visibility Problem"]

While transactions occur momentarily, ownership persists across every block, every interaction, and every asset held by an address. As a result, ownership becomes a long-lived source of information that continuously leaks data about the user.

When an observer identifies an address, they can often determine:

What assets the address owns
How much value it controls
Who it interacts with
How its holdings evolve over time
Which actions represent payments versus internal transfers

This information remains available indefinitely and accumulates throughout the lifetime of the address.

Consequently, the privacy problem extends beyond individual transactions. Even if specific transfers were partially obscured, persistent ownership would continue to reveal relationships, balances, behavioral patterns, and financial history.

GhostShard therefore approaches privacy from a different perspective. Rather than attempting to conceal individual transactions, it seeks to reduce the visibility and persistence of ownership itself.

The remainder of this chapter explores how this observation leads to an ownership-centric privacy model based on disposable ownership, shards, mesh transactions, and ownership ambiguity.

2.2 Why Ownership Topology?

What Information Does Ownership Reveal?

On a transparent ledger, ownership is not a single fact. It is a composite of multiple information leaks, each of which can independently compromise privacy.

Wealth. The aggregate value of assets held by an address reveals a user's financial position. Once an address is associated with an identity, an observer can immediately determine balances, portfolio composition, and changes in wealth over time.

Relationships. Every transaction from address A to address B reveals a relationship. Not merely that value was transferred, but that two parties chose to interact. Over time, the transaction graph becomes a social graph, exposing business partnerships, organizational structures, personal relationships, and networks of influence.

Behavior. Transaction frequency, timing patterns, gas price preferences, and contract interaction habits form a behavioral fingerprint. An observer can infer when a user is active, which protocols they prefer, how sophisticated they are, and whether they are operating manually or through automation. Similar behavioral patterns can be used to cluster otherwise unrelated addresses.

Intent. The assets an address chooses to hold reveal information about its objectives and preferences. Governance tokens signal participation in a protocol. NFTs signal community membership or cultural affiliation. Stablecoin-heavy portfolios may indicate different risk preferences than portfolios dominated by volatile assets. Ownership becomes a behavioral profile.

Network Position. An address's location within the transaction graph reveals structural importance. Its centrality, connectivity, and role within liquidity or payment networks can indicate influence far beyond the value of its holdings. A large holder is not merely wealthy; it may be systemically significant.

Collectively, these information leaks transform ownership into a persistent identity layer. The observer learns not only what assets exist, but who likely controls them, how they are used, and how they relate to the broader network.

flowchart TD

    O["Persistent Ownership"]

    O -->|"Reveals"| W["Wealth"]
    O -->|"Reveals"| R["Relationships"]
    O -->|"Reveals"| B["Behavior"]
    O -->|"Reveals"| I["Intent"]
    O -->|"Reveals"| N["Network Position"]

    W -->|"Contributes to"| P["Identity Exposure"]
    R -->|"Contributes to"| P
    B -->|"Contributes to"| P
    I -->|"Contributes to"| P
    N -->|"Contributes to"| P

    P -->|"Creates"| Q["Ownership Visibility Problem"]

The Fundamental Question

At what layer should privacy operate?

Most existing privacy systems operate at the transaction layer:

Transaction concealment (mixers): Hide the relationship between transaction inputs and outputs.
Transaction encryption (shielded systems): Hide transaction contents entirely.
Transaction obfuscation (stealth addresses): Hide specific transaction participants.

Although these approaches differ technically, they share a common assumption: ownership remains persistent while transactions are hidden.

Privacy is therefore applied to what happens between ownership states rather than to ownership itself.

Why Transaction Concealment Is Insufficient

Even a hypothetical system that makes every transaction perfectly untraceable does not solve the ownership problem.

Consider a user whose transactions remain permanently concealed for five years. Every transfer, swap, payment, and interaction is cryptographically hidden. Yet the assets must still exist somewhere on the ledger. They must still be owned.

If those ownership containers are persistent, they become long-lived observation points. A single identity leak—a KYC withdrawal, public donation, exchange interaction, or operational mistake—can attach a real-world identity to that ownership structure.

Once ownership is identified, an observer can often infer wealth, relationships, behavior, and historical activity regardless of how well individual transactions were concealed.

This reveals a fundamental distinction:

Transaction privacy protects actions.
Ownership privacy protects identity.

Actions occur momentarily. Ownership persists.

A transaction exists for a block. Ownership may exist for years.

For this reason, GhostShard treats ownership visibility—not transaction visibility—as the primary privacy problem.

Why Ownership Topology Is the Correct Abstraction

The key insight is that ownership is not a property of transactions. Ownership is a property of the ledger's topology.

Who owns what is ultimately a question about the structure of the graph rather than any individual edge within it.

GhostShard therefore operates at the ownership layer.

Instead of asking:

How do we hide this transaction?

GhostShard asks:

How do we make ownership itself ambiguous?

The answer is disposable ownership.

Ownership units should not persist indefinitely. They should exist only long enough to participate in an ownership cycle and then be permanently retired.

Without persistent ownership containers:

There is no long-lived address to observe.
There is no stable identity to cluster.
There is no persistent portfolio to analyze.
There is no ownership graph to reconstruct over time.

This is not simply a stronger form of transaction privacy. It is a fundamentally different privacy model.

Transaction privacy attempts to hide the edges of the graph.

Ownership privacy changes the graph itself.

Instead of concealing activity between persistent owners, the protocol minimizes the persistence of ownership.

flowchart LR

    TP["Transaction Privacy"]
        -->|"Attempts to hide"| TE["Transaction Edges"]

    TE -->|"But leaves"| PO["Persistent Ownership"]

    PO -->|"Still enables"| IV["Identity Visibility"]

    OP["Ownership Privacy"]
        -->|"Changes"| OT["Ownership Topology"]

    OT -->|"Enables"| DO["Disposable Ownership"]

    DO -->|"Produces"| OA["Ownership Ambiguity"]

Design Outcome

GhostShard adopts privacy through ownership topology.

Rather than concealing transactions, encrypting transaction data, or requiring dedicated privacy environments, the protocol seeks to make ownership itself ambiguous.

This represents a fundamentally different privacy model. Transaction privacy attempts to hide activity occurring within a visible ownership structure. Ownership privacy alters the structure itself.

The result is a system in which transactions may remain fully observable while ownership relationships become difficult to determine. An observer can inspect the ledger, follow every state transition, and verify every transaction, yet still be unable to reliably answer the most important question:

Who owns what?

2.2b Why Privacy Must Be the Default

The previous section established that privacy should operate at the ownership layer. This section establishes a second requirement:

Privacy must be the default state, not an optional feature.

This is not primarily a usability consideration. It is an architectural requirement.

The privacy guarantees provided by GhostShard depend upon every user in the protocol participating in the same ownership model. If privacy were optional, the anonymity set would fragment, ownership patterns would become distinguishable, and the combinatorial ambiguity provided by mesh transactions would weaken significantly.

For this reason, GhostShard is designed around privacy by default.

What Privacy by Default Means

In GhostShard, privacy is not a mode that users activate.

Every deposit creates one or more shards.

Every spend consumes shards and creates new shards.

Every ownership transition is announced through ERC-5564-compatible announcements containing encrypted metadata.

There is no public mode, private mode, shielded mode, or unshielded mode.

There is only the ownership model.

Privacy is therefore not a feature layered onto the protocol. It is a property of how ownership exists within the protocol.

flowchart LR

    U["User"]
        -->|"Uses Protocol"| S["Shard Creation"]

    S -->|"Creates"| O["Private Ownership State"]

    O -->|"Spent Through"| M["Mesh Transaction"]

    M -->|"Creates"| N["New Shards"]

    N -->|"Maintains"| P["Privacy By Default"]

    P -->|"Applies To"| A["All Users"]

Argument 1: The Privacy Set Must Be Everyone

Privacy systems derive strength from the size of the set in which an individual becomes indistinguishable.

If only a small percentage of users choose privacy, then participation in the privacy system becomes a distinguishing signal. The privacy set becomes self-selecting, identifiable, and potentially suspicious.

An observer no longer asks:

Which user performed this action?

Instead they ask:

Which user among the small set of privacy users performed this action?

As the privacy set shrinks, anonymity weakens.

GhostShard avoids this problem by making privacy universal. Every participant uses the same ownership model, creating the largest possible anonymity set: the entire user base.

flowchart TD

    A["Opt-In Privacy"]

    A -->|"Creates"| B["Small Privacy Set"]

    B -->|"Makes Users"| C["Distinguishable"]

    C -->|"Weakens"| D["Privacy Guarantees"]

    E["Privacy By Default"]

    E -->|"Creates"| F["Universal Privacy Set"]

    F -->|"Makes Users"| G["Indistinguishable"]

    G -->|"Strengthens"| H["Privacy Guarantees"]

Argument 2: The Opt-In Moment Is a Metadata Leak

Traditional privacy systems require users to perform a visible action to enter the privacy set.

Examples include:

Depositing into a mixer
Shielding assets into a privacy pool
Activating a privacy mode
Moving funds into specialized privacy infrastructure

Even if subsequent activity is concealed, the entry action remains permanently visible.

The act of choosing privacy becomes observable metadata.

GhostShard eliminates the entry point entirely.

There is no transaction that signals:

This user is now entering a privacy system.

Users simply interact with the protocol. Every ownership transition follows the same model regardless of intent.

Argument 3: Regulatory Targeting Requires a Target

Systems that separate public activity from private activity create identifiable regulatory surfaces.

When users explicitly enter a privacy environment, regulators can monitor entry events, track participation, sanction infrastructure providers, or classify participation itself as suspicious behavior.

GhostShard does not create a distinct privacy environment.

There is no privacy pool.

There is no shielding transaction.

There is no transition from public ownership into private ownership.

The ownership model itself is the protocol.

As a result, there is no singular event that identifies a user's decision to seek privacy.

Argument 4: Defaults Determine Behavior

Most users interact with systems exactly as those systems are presented.

Opt-in privacy requires users to:

Understand privacy risks
Navigate additional workflows
Accept additional complexity
Pay additional costs
Make a deliberate decision to become private

Most users will not do this.

This is not irrational behavior. It is normal behavior.

If privacy requires effort, adoption decreases.

If privacy is the default, adoption increases.

Because anonymity depends on participation, privacy systems cannot rely on widespread manual opt-in.

The default must be private.

Argument 5: Indistinguishability Requires Uniformity

GhostShard's mesh transaction model derives privacy from ambiguity.

When an observer sees multiple inputs and multiple outputs, they cannot reliably determine:

Which outputs are payments
Which outputs are change
Which outputs belong to which participant
Which ownership transitions represent internal restructuring

This ambiguity emerges from uniform transaction structure.

If some transactions are private while others remain public, observers gain a baseline for comparison. Public transactions leak information that can be used to reduce uncertainty about private transactions.

The anonymity set begins to fragment.

For mesh transactions to achieve their intended privacy properties, all transactions must participate in the same ownership model.

Privacy therefore cannot be an optional mode.

It must be the default state of the system.

flowchart LR

    A["Uniform Mesh Transactions"]
        -->|"Creates"| B["Combinatorial Ambiguity"]

    B -->|"Produces"| C["Indistinguishability"]

    D["Mixed Public & Private Modes"]
        -->|"Creates"| E["Structural Differences"]

    E -->|"Enable"| F["Transaction Classification"]

    F -->|"Reduces"| C

Design Outcome

GhostShard makes privacy the default state of ownership.

There is no privacy toggle, no shielding phase, no opt-in workflow, and no special transaction type that signals a user's desire for privacy.

Every deposit creates shards.

Every spend consumes shards and creates new shards.

Every ownership transition follows the same model.

This is not merely a user-experience decision. It is a structural requirement for maintaining indistinguishability and preserving the combinatorial ambiguity on which GhostShard's privacy model depends.

2.3 What Is Disposable Ownership?

The previous sections established two conclusions:

Privacy failures on EVM systems are fundamentally ownership failures.
Privacy must be the default state of the system rather than an optional mode.

The next question is therefore:

If ownership visibility is the problem, why not simply hide owners?

The answer is that hiding owners does not eliminate the underlying issue.

The problem is not merely that ownership is visible.

The problem is that ownership is persistent.

Why Persistent Ownership Fails

Persistent ownership continuously accumulates information over time.

Every interaction adds new information to the ownership record:

History Accumulation — Every transaction contributes to a growing historical record. An address with one hundred transactions reveals significantly more information than an address with one transaction.
Balance Accumulation — Assets received over time accumulate into visible balances. The balance itself becomes a source of information regarding wealth and economic activity.
Relationship Accumulation — Every interaction adds edges to a transaction graph. Over time, counterparties, organizations, and social relationships become visible.
Behavioral Accumulation — Transaction timing, spending frequency, preferred protocols, and usage patterns form recognizable behavioral signatures.

A long-lived ownership container becomes increasingly identifiable simply by existing.

Even if individual transactions were hidden, the ownership structure itself would continue accumulating information.

flowchart TD

    P["Persistent Ownership"]

    P -->|"Accumulates"| H["History"]

    P -->|"Accumulates"| B["Balances"]

    P -->|"Accumulates"| R["Relationships"]

    P -->|"Accumulates"| BP["Behavioral Patterns"]

    H -->|"Creates"| I["Identity Exposure"]
    B -->|"Creates"| I
    R -->|"Creates"| I
    BP -->|"Creates"| I

    I -->|"Weakens"| PR["Privacy"]

The Disposable Ownership Insight

The key insight of GhostShard is that ownership does not need to be hidden.

It needs to be disposable.

Instead of attempting to conceal a long-lived ownership structure, the protocol eliminates the persistence of ownership itself.

Each ownership unit exists for a single ownership cycle and is then permanently retired.

Because ownership does not persist:

History does not accumulate.
Balances do not accumulate.
Relationship graphs do not accumulate.
Behavioral signatures do not accumulate.

The ownership container disappears before meaningful information can collect around it.

What Disposable Ownership Means

A disposable ownership unit follows a simple lifecycle:

An ownership unit is created when value is received.
The ownership unit temporarily holds that value.
The ownership unit is consumed during a spend.
The ownership unit is permanently retired.
Future ownership is represented by entirely new ownership units.

No ownership unit participates in multiple spending cycles.

flowchart LR

    C["Create Ownership Unit"]
        -->|"Receives Value"| H["Hold Value"]

    H -->|"Single Spend"| S["Consume Ownership Unit"]

    S -->|"Permanent Retirement"| R["Retired"]

    R -->|"Future Ownership Uses"| N["New Ownership Unit"]

Why Not Persistent Stealth Accounts?

Stealth addresses improve recipient privacy, but they do not eliminate ownership persistence.

A stealth address that remains active for months or years still accumulates:

Transaction history
Asset balances
Counterparty relationships
Behavioral signatures

Although the ownership container becomes pseudonymous, it remains persistent.

Eventually, sufficient information accumulates around the address to support clustering and analysis.

GhostShard addresses a different problem.

Rather than obscuring a persistent ownership container, it minimizes the lifetime of the ownership container itself.

Why Not Note-Based Systems?

Note-based privacy systems hide ownership through encrypted notes and cryptographic commitments.

While powerful, they introduce a separate state-management problem.

Notes must be:

Created
Stored
Tracked
Proven
Destroyed

This creates additional lifecycle complexity and introduces its own metadata management requirements.

GhostShard instead adopts a simpler ownership model:

Receive. Hold. Spend. Retire.

The privacy mechanism emerges from ownership disposal rather than long-lived hidden state.

Design Outcome

GhostShard adopts disposable ownership.

Assets are held by one-time-use ownership units that participate in exactly one ownership cycle before permanent retirement.

Privacy is achieved not by hiding persistent ownership, but by eliminating ownership persistence itself.

The next question naturally follows:

If ownership is disposable, what form should these ownership units take?

The answer is introduced in the next section through the concept of shards.

2.4 How Do We Achieve Disposable Ownership?

The previous section established that ownership should be disposable.

The next question is practical:

If ownership units are disposable, what form should those ownership units take?

Disposable ownership is a privacy model. To implement that model, the protocol requires a concrete ownership representation.

The representation must satisfy a number of constraints imposed by the EVM itself.

Requirements for the Ownership Representation

Any ownership representation used by GhostShard must satisfy the following requirements:

Standard EVM Compatibility

Ownership units must interact with existing smart contracts without requiring protocol-specific integrations. Assets should remain usable throughout the broader EVM ecosystem.

Independent Ownership

Each ownership unit must be independently controllable. Compromise of one ownership unit must not compromise all others.

One-Time Use

Ownership units must support the disposable ownership model. After participating in a spend, they must be permanently retired.

Minimal Creation Cost

Creating ownership units should be inexpensive enough to support large numbers of units without prohibitive gas costs.

Universal Asset Support

The representation must support ETH, ERC-20 tokens, and ERC-721 assets without requiring different ownership models for different asset types.

flowchart TD

    A["Disposable Ownership"]

    A --> B["EVM Compatibility"]
    A --> C["Independent Ownership"]
    A --> D["One-Time Use"]
    A --> E["Low Creation Cost"]
    A --> F["Universal Asset Support"]

Evaluating Alternative Representations

Several possible ownership representations were considered.

Smart Contracts

One option is to represent each ownership unit as an independently deployed smart contract.

While this provides flexibility, it introduces significant drawbacks:

Contract deployment costs are substantial.
Large ownership sets become prohibitively expensive.
Contract bytecode creates protocol-identifiable artifacts.
Additional deployment transactions increase operational complexity.

The ownership representation becomes visible as a protocol-specific object rather than blending into normal EVM activity.

Shielded Notes

Another option is a note-based ownership model similar to shielded systems.

While note systems can provide strong privacy guarantees, they require:

Specialized state management
Note creation and destruction logic
Proof generation infrastructure
Additional discovery mechanisms
Restricted interoperability with existing EVM protocols

The resulting architecture becomes significantly more complex than the ownership model requires.

Why EOA Shards?

GhostShard adopts standard EVM accounts as ownership units.

Each ownership unit is represented by a unique EOA controlled by a unique private key.

This approach satisfies every design requirement:

Zero deployment cost — EOAs require no contract deployment.
Native EVM compatibility — EOAs interact with existing protocols without modification.
Independent ownership — Every shard has independent cryptographic control.
Protocol indistinguishability — Shards appear identical to ordinary EVM accounts.
Universal asset support — ETH, ERC-20, and ERC-721 assets can all be held directly.

Most importantly, EOAs already exist as a fundamental EVM primitive.

Rather than inventing a new ownership container, GhostShard repurposes an existing one.

flowchart LR

    A["Disposable Ownership Requirements"]

    A --> B["Smart Contracts"]
    A --> C["Shielded Notes"]
    A --> D["EOA Shards"]

    B --> E["Deployment Cost"]
    B --> F["Protocol Fingerprint"]

    C --> G["Complex State"]
    C --> H["Proof Infrastructure"]

    D --> I["Zero Deployment"]
    D --> J["Native Compatibility"]
    D --> K["Indistinguishable Accounts"]

    I --> L["Selected Architecture"]
    J --> L
    K --> L

The Shard Lifecycle

A shard progresses through three states during its lifetime.

Active

The shard currently holds assets and is available for selection during transaction construction.

At this stage:

The shard is discoverable by its owner.
Assets remain under the shard's control.
The shard can participate in future mesh transactions.

Pending

The shard has been selected for spending and a transaction has been submitted.

At this stage:

The spend has been initiated.
The transaction has not yet finalized.
The shard is temporarily unavailable for future selection.

Spent

The transaction has finalized successfully.

At this stage:

The shard is permanently retired.
Assets are no longer associated with the shard.
The shard can never be reused.

stateDiagram-v2

    [*] --> Active

    Active --> Pending : Transaction Submitted

    Pending --> Spent : Transaction Confirmed

    Spent --> [*]

    note right of Active
        Discoverable
        Selectable
        Holds Assets
    end note

    note right of Pending
        Awaiting Confirmation
    end note

    note right of Spent
        Permanently Retired
        Cannot Be Reused
    end note

flowchart LR

    A["Receive Assets"]
        --> B["Shard A"]

    B --> C["Spend"]

    C --> D["Shard B"]
    C --> E["Shard C"]

    D --> F["Future Spend"]

    F --> G["Shard D"]
    F --> H["Shard E"]

    E --> I["Future Spend"]

    I --> J["Shard F"]

    J --> K["Growing Shard Set"]

Design Outcome

GhostShard implements disposable ownership through EOA shards.

Each shard represents a one-time-use ownership unit controlled by an independent private key. Shards hold assets, participate in exactly one spending cycle, and are permanently retired after use.

The resulting ownership model achieves disposable ownership using only standard EVM primitives while remaining compatible with existing wallets, assets, and protocols.

However, disposable ownership immediately introduces a new challenge.

If every receipt creates a new shard and every spend retires existing shards while creating replacement shards, ownership naturally fragments over time.

A user who receives many payments may eventually control dozens or even hundreds of independent shards.

While fragmentation improves ownership privacy, it also creates practical challenges for transaction construction, balance management, and asset utilization.

This introduces the next architectural problem:

How can a system preserve disposable ownership without making fragmented ownership unusable?

The next section examines fragmentation as the first major consequence of disposable ownership and the architectural pressures it creates.

2.5 Fragmentation Problem

Shards provide disposable ownership.

However, disposable ownership introduces a new challenge:

Ownership becomes fragmented across many independent units.

Every deposit creates a new shard. Over time, a user accumulates a growing collection of shards, each holding a portion of their total balance.

A user who receives 100 deposits may eventually own 100 separate shards.

This is not a flaw in the architecture. It is a direct consequence of disposable ownership.

The question becomes:

How can a system maintain disposable ownership without allowing fragmentation to grow without bound?

Why Fragmentation Is a Problem

Fragmentation introduces several operational challenges.

1. Gas Cost

Spending from many shards requires processing many inputs.

As shard count increases, transaction construction and execution costs increase approximately linearly with the number of participating shards.

2. Discovery Cost

Each shard must be discovered through announcement scanning, trial decryption, and balance verification.

More shards increase client-side computational requirements.

3. State Growth

The client must maintain metadata for every shard:

Ownership information
Asset balances
Spent status
Synchronization cursors

Without management, shard state grows indefinitely.

Fragmentation Growth

flowchart LR

    D1["Deposit #1"]
        --> S1["Shard A"]

    D2["Deposit #2"]
        --> S2["Shard B"]

    D3["Deposit #3"]
        --> S3["Shard C"]

    D4["Deposit #4"]
        --> S4["Shard D"]

    S1 --> W["Wallet State"]
    S2 --> W
    S3 --> W
    S4 --> W

    W --> F["Growing Fragmentation"]

Each deposit increases ownership fragmentation.

Without intervention, wallet complexity grows continuously over time.

The User Intent Execution Problem

Fragmentation creates a deeper problem than state growth.

Consider a user who wants to send:

2 ETH to Bob

The wallet may need to combine many shards to satisfy the payment amount.

For example:

Shard A = 0.4 ETH
Shard B = 0.5 ETH
Shard C = 0.3 ETH
Shard D = 0.8 ETH

Total = 2.0 ETH

The user's intent is simple:

Send 2 ETH.

The protocol's ownership model is fragmented:

Spend four independent ownership units.

These are not the same thing.

The user's intent is singular.

The ownership representation is distributed.

This creates a coordination problem.

If one shard transfer succeeds while another fails, ownership becomes inconsistent.

Some shards may be consumed.

Others may remain unspent.

The intended transfer never completes.

The user's state becomes corrupted.

Why Partial Execution Is Unacceptable

flowchart LR

    U["User Intent<br/>Send 2.0 ETH"]

    U --> A["Shard A<br/>0.4 ETH"]
    U --> B["Shard B<br/>0.5 ETH"]
    U --> C["Shard C<br/>0.3 ETH"]
    U --> D["Shard D<br/>0.8 ETH"]

    A --> S1["Success"]
    B --> S2["Success"]

    C --> F["Failure"]

    D --> N["Not Executed"]

    S1 --> X["Inconsistent State"]
    S2 --> X
    F --> X
    N --> X

The user requested one transfer.

The system executed only part of it.

This outcome is worse than complete failure.

Funds become stranded across multiple ownership states and the intended transfer never occurs.

Architectural Requirement

All shards participating in a transaction must behave as a single unit.

The protocol therefore requires:

Either every shard transfer succeeds, or none of them succeed.

This is an atomicity requirement.

Not a privacy requirement.

Not a usability requirement.

A correctness requirement.

Solution Part I — Compression

The first solution addresses shard growth.

When constructing a transaction, the wallet selects:

Required payment shards
Additional compression shards

Compression shards are included even when they are not strictly necessary for the payment.

The number of compression shards scales with wallet size with a hard cap of 15 to prevent fingerprinting:

extraShards = random(floor(sqrt(walletSize) * 0.8))

These shards are consumed alongside the payment and merged into fewer outputs.

Over time:

Fragmentation decreases
State growth slows
Average wallet complexity converges

Compression Effect

flowchart LR

    A["Shard A"]
    B["Shard B"]
    C["Shard C"]
    D["Shard D"]
    E["Shard E"]
    F["Shard F"]

    A --> T["Mesh Transaction"]
    B --> T
    C --> T
    D --> T
    E --> T
    F --> T

    T --> G["Change Shard X"]
    T --> H["Change Shard Y"]

    G --> R["Reduced Fragmentation"]
    H --> R

Compression continuously converts many shards into fewer shards.

Fragmentation therefore remains bounded rather than growing indefinitely.

Solution Part II — Atomic Execution

Compression solves wallet growth.

It does not solve intent execution.

The second solution is atomic execution.

All shard transfers participating in a transaction execute within a single state transition.

If any transfer fails:

The transaction reverts.
All shard state changes roll back.
No shard is consumed.

The user either receives complete execution or no execution at all.

flowchart TD

    A["Mesh Transaction"]

    A --> B["Execute Command 1"]
    B --> C["Execute Command 2"]
    C --> D["Execute Command 3"]

    D --> E{"Any Failure?"}

    E -->|No| F["Commit Entire Transaction"]

    E -->|Yes| G["Revert Entire Transaction"]

    F --> H["All Shards Consumed"]

    G --> I["No Shards Consumed"]

Why Atomic Execution Requires EIP-7702

Independent EOAs cannot coordinate execution.

Each shard possesses:

Its own private key
Its own nonce
Its own state

Without coordination, multiple shard spends become independent transactions.

Independent transactions cannot provide atomic guarantees.

GhostShard solves this using EIP-7702 delegation.

All participating shards temporarily delegate execution authority to a shared execution environment:

GhostRouter.

GhostRouter executes every command within a single execution context.

If any command fails:

innerExecuteMesh() reverts
All state changes roll back
Every shard returns to its original state

This transforms many independent ownership units into a single atomic execution unit.

Additional Privacy Benefits

Compression provides privacy benefits beyond state management.

Wallet-Size Obfuscation

Because compression shard selection is randomized and scales non-linearly with wallet size, observers cannot reliably infer the number of shards owned by a user from a single transaction.

Partial Amount Obfuscation

Compression also obscures transaction amounts.

Observers can see the total value entering a mesh transaction, but cannot immediately determine:

Which inputs funded the payment
Which inputs were included solely for compression

Full amount ambiguity emerges only after compression is combined with output scattering (Section 2.7).

Design Outcome

Fragmentation is an unavoidable consequence of disposable ownership.

GhostShard addresses fragmentation through two complementary mechanisms:

Compression, which continuously reduces shard growth and bounds wallet complexity.
Atomic execution, which guarantees that all shards participating in a user intent behave as a single execution unit.

The result is a system that preserves disposable ownership while remaining operationally practical.

Ownership may be fragmented.

User intent is not.

2.6 How Do We Guarantee One-Time Use?

Shards are designed to be used exactly once. After a shard participates in a mesh transaction, it must never be spendable again.

At first glance this appears straightforward. However, EIP-7702 introduces subtle execution semantics that make one-time-use enforcement significantly more complex than simply checking account state.

The protocol therefore evaluates multiple approaches before selecting a final mechanism.

The Requirement

A one-time-use guarantee must satisfy four properties:

Correctness

A successfully spent shard must never become spendable again.

Retry Safety

A failed transaction must not permanently destroy an unspent shard.

Unambiguous State

The protocol must be able to determine with certainty whether a shard has been consumed.

Persistence

Once a shard is consumed, that state must be permanent and irreversible.

flowchart TD

    A["One-Time Use Requirement"]

    A --> B["Correctness"]
    A --> C["Retry Safety"]
    A --> D["Unambiguous State"]
    A --> E["Permanent Persistence"]

Approach 1: Check the Shard Nonce

The most obvious solution is to verify that a shard's nonce is zero.

A shard that has already been used would have a nonce greater than zero and therefore be rejected.

Why It Fails

Under EIP-7702, authorization processing increments the nonce before transaction execution begins.

This increment occurs regardless of whether execution eventually succeeds or reverts.

Consider the following sequence:

Shard nonce is 0.
The shard is included in a mesh transaction.
Another operation inside the mesh transaction fails.
The entire transaction reverts.
The shard nonce is now 1.
The shard was never actually spent.

The shard's assets remain intact, but the nonce now falsely indicates that it has already been consumed.

The shard becomes permanently stranded despite never successfully participating in a transfer.

flowchart LR

    A["Nonce = 0"]
        --> B["Authorization Processed"]

    B --> C["Nonce Incremented"]

    C --> D["Execution Reverts"]

    D --> E["Assets Still Exist"]

    D --> F["Nonce = 1"]

    E --> G["Shard Not Spent"]
    F --> H["Appears Spent"]

    G --> I["Contradiction"]
    H --> I

The nonce therefore measures attempted execution, not successful consumption.

For a system that relies on transaction reversion for atomicity, this distinction is fatal.

Approach 2: Check the Shard Code

A second possibility is to inspect the shard's delegated code.

When EIP-7702 authorization is processed, the shard receives delegated execution code:

0xef0100 || GhostRouter

One might attempt to treat the presence of delegated code as evidence that the shard has already been used.

Why It Fails

Delegation state is persistent.

The delegated code remains on the account even if execution later reverts.

This creates ambiguity:

Authorization is processed.
Delegated code is installed.
Execution reverts.
Delegated code remains.

Later observations cannot distinguish between:

A shard that was successfully consumed.
A shard whose transaction reverted.
A shard that was delegated for some other purpose.

The delegated code only proves that authorization occurred.

It does not prove successful consumption.

flowchart LR

    A["Authorization Processed"]
        --> B["Delegated Code Installed"]

    B --> C["Execution Success"]
    B --> D["Execution Revert"]

    C --> E["Code Remains"]
    D --> E

    E --> F["State Ambiguous"]

    F --> G["Cannot Determine"]

Code-based detection therefore fails the unambiguous-state requirement.

Approach 3: On-Chain Spent Tracking

The final approach introduces explicit protocol state.

GhostRouter maintains:

mapping(address => bool) public isShardSpent;

Before processing a shard:

require(!isShardSpent[shard], "ShardAlreadySpent");

After successful execution:

isShardSpent[shard] = true;

The flag is written only during successful mesh execution.

Why It Works

Unlike nonce and code inspection, spent tracking records the exact event the protocol cares about:

Successful shard consumption.

The mapping is:

Independent of authorization processing.
Independent of nonce changes.
Independent of delegated code state.
Updated only after successful execution.

If execution reverts, the state write reverts as well.

The shard remains spendable.

If execution succeeds, the flag becomes permanently true.

flowchart TD

    A["Mesh Execution"]

    A --> B{"Execution Successful?"}

    B -->|No| C["Transaction Reverts"]

    B -->|Yes| D["Set isShardSpent = true"]

    C --> E["Shard Remains Usable"]

    D --> F["Shard Permanently Retired"]

Tradeoff Analysis

The primary drawback is storage cost.

The first write to a new storage slot incurs approximately:

~20,000 gas

per shard.

However, this cost is paid exactly once during the shard's lifetime.

The protocol intentionally accepts this overhead because it provides the only mechanism that simultaneously satisfies:

Correctness
Retry safety
Unambiguous state
Permanent persistence

Design Outcome

GhostShard guarantees one-time use through explicit on-chain spent tracking.

Neither nonce inspection nor delegated-code inspection can reliably distinguish successful consumption from failed execution under EIP-7702.

Instead, GhostRouter maintains a permanent isShardSpent mapping that is updated only after successful execution.

The result is a deterministic and irreversible one-time-use guarantee:

Unspent shards remain spendable.
Failed transactions remain retryable.
Successfully consumed shards can never be reused.

Disposable ownership therefore becomes cryptographically enforceable rather than merely conventional.

2.7 Transfer Amount as a Privacy Leak

The previous section established that compression manages fragmentation and that atomic execution preserves user intent.

However, even a perfectly coordinated spend still leaks information.

The remaining problem is amount visibility.

The Amount Privacy Problem

Consider a user who controls two shards:

Shard A: 1.5 ETH
Shard B: 1.0 ETH

The user wishes to send 2.0 ETH to a recipient.

The resulting transaction appears as:

Inputs: 1.5 ETH + 1.0 ETH = 2.5 ETH
Payment Output: 2.0 ETH
Change Output: 0.5 ETH

An observer can immediately infer the user's intent.

flowchart LR

    A["Shard A<br/>1.5 ETH"]
    B["Shard B<br/>1.0 ETH"]

    A --> T["Transaction"]
    B --> T

    T --> P["Payment<br/>2.0 ETH"]
    T --> C["Change<br/>0.5 ETH"]

The privacy failure is not ownership.

The privacy failure is arithmetic.

Because the inputs and outputs are deterministic, the payment amount is directly observable.

The observer knows:

Total value consumed
Total value returned
Exact payment amount
Exact change amount

Ownership may be fragmented, but intent remains visible.

Why Compression Alone Is Insufficient

Section 2.5 introduced compression shards.

Compression increases ambiguity by adding additional inputs that are not strictly required for the payment.

However, compression alone does not fully solve the amount problem.

Even if ten shards are consumed, an observer can still determine the payment amount whenever the payment output remains distinguishable from change outputs.

Compression obscures the input side.

Amount privacy also requires ambiguity on the output side.

The Core Insight

Privacy requires amount ambiguity.

An observer should be unable to answer three questions:

Which outputs represent payment?
Which outputs represent change?
What amount was actually transferred?

As long as those questions remain unanswered, user intent remains private.

This requires payment and change to become structurally indistinguishable.

Mesh Transactions

GhostShard achieves amount ambiguity through mesh transactions.

A mesh transaction:

Consumes many shards.
Produces many shards.
Splits value into randomized outputs.
Announces all outputs identically.

The result is that value no longer leaves the transaction as a single payment output and a single change output.

Instead, value exits as a collection of indistinguishable ownership units.

flowchart LR

    I1["Input Shard<br/>0.7 ETH"]
    I2["Input Shard<br/>0.5 ETH"]
    I3["Input Shard<br/>0.6 ETH"]
    I4["Input Shard<br/>0.7 ETH"]
    I5["Input Shard<br/>0.4 ETH"]

    I1 --> M["Mesh Transaction"]
    I2 --> M
    I3 --> M
    I4 --> M
    I5 --> M

    M --> O1["Output<br/>0.9 ETH"]
    M --> O3["Output<br/>0.8 ETH"]
    M --> O4["Output<br/>0.7 ETH"]
    M --> O2["Output<br/>0.5 ETH"]

The observer sees four outputs totaling 2.9 ETH.

However, the observer cannot determine:

Which outputs belong to the recipient.
Which outputs belong to the sender.
Whether there is one recipient or many.
Which subset represents the payment.
Which subset represents change.

Multiple interpretations become simultaneously valid.

flowchart TD

    A["Observed Outputs<br/>0.8 • 0.7 • 0.9 • 0.5"]

    A --> B["Interpretation 1<br/>Payment = 2.0 ETH"]
    A --> C["Interpretation 2<br/>Payment = 1.5 ETH"]
    A --> D["Interpretation 3<br/>Payment = 2.4 ETH"]
    A --> E["Interpretation 4<br/>Multiple Recipients"]

    B --> X["Observer Cannot Determine Intent"]
    C --> X
    D --> X
    E --> X

The ambiguity is combinatorial.

As the number of outputs increases, the number of valid interpretations grows rapidly.

The observer sees every output but cannot reliably reconstruct intent.

Why Atomic Execution Matters

The mesh structure alone is insufficient.

If transfers and announcements occur separately, observers can correlate outputs through:

Block timing
Transaction ordering
Gas patterns
Event sequencing

GhostShard therefore executes the entire mesh atomically.

Inputs are consumed, outputs are created, and announcements are published within a single state transition.

No intermediate state exists for an observer to analyze.

The transaction appears as one indivisible ownership transformation.

2.7.1 Recipient and Change Ambiguity

Mesh transactions provide more than amount privacy.

They also create recipient ambiguity.

Every output produced by a mesh transaction shares the same structure:

Fresh shard address
No transaction history
ERC-5564 announcement
Encrypted metadata
Randomized value

From the observer's perspective, every output appears identical.

flowchart TD

    M["Mesh Transaction"]

    M --> O1["Output 1"]
    M --> O2["Output 2"]
    M --> O3["Output 3"]
    M --> O4["Output 4"]

    O1 --> Q["?"]
    O2 --> Q
    O3 --> Q
    O4 --> Q

    Q --> R["Recipient or Change?"]

This creates a stronger privacy property than amount ambiguity alone.

The sender's change and the recipient's payment become structurally equivalent.

An observer cannot determine:

Which outputs belong to the sender.
Which outputs belong to the recipient.
How many recipients exist.
Whether value was split among multiple parties.

The recipient can identify their outputs through trial decryption using their viewing key.

Everyone else sees only a set of indistinguishable ownership units.

Design Outcome

GhostShard adopts mesh transactions as the fundamental spending primitive.

A mesh transaction consumes N shards, creates M shards, and publishes M announcements atomically.

Payment and change are both scattered across randomized outputs.

Because every output is structurally identical, observers cannot reliably determine:

Payment amount
Change amount
Recipient count
Recipient ownership
Sender ownership

The ledger remains fully transparent.

The ownership relationships embedded within it do not.

2.8 Dust Protection

Mesh transactions scatter outputs across multiple shards. This improves amount privacy but introduces a new problem:

dust shards.

Because output amounts are randomized, some outputs may receive values so small that spending them later costs more than the value they contain.

A shard may remain perfectly private and technically spendable while being economically irrational to use.

Example

Consider a mesh transaction that creates four outputs:

Output	Amount
Shard A	0.8 ETH
Shard B	0.7 ETH
Shard C	0.0001 ETH
Shard D	0.9 ETH

The third output may require more gas to spend than the value it contains.

The shard is valid.

The shard is private.

The shard is recoverable.

But spending it would destroy economic value.

This is a dust shard.

Why Dust Matters

Dust is not primarily a privacy problem.

All outputs remain structurally identical:

Fresh shard addresses
Fresh announcements
Encrypted metadata
Randomized output values

An observer cannot determine which outputs are dust.

The problem is operational.

Over time, dust shards accumulate inside the user's shard store:

More shards to discover
More balances to track
More coin-selection candidates
More synchronization work

Without protection, the wallet gradually fills with economically unusable ownership units.

Why Dust Cannot Be Eliminated Completely

The root cause is output randomization.

Mesh transactions deliberately avoid deterministic output amounts because deterministic outputs leak payment information.

For example:

2.9 ETH
   ↓
0.8 + 0.7 + 0.9 + 0.5

Some randomized distributions will inevitably create very small outputs.

Removing randomness would weaken amount ambiguity and reintroduce payment inference attacks.

Dust prevention must therefore coexist with randomized splitting rather than replace it.

flowchart TD

    A["Amount Ambiguity"]

    A --> B["Randomized Output Splits"]

    B --> C["Small Outputs Sometimes Occur"]

    C --> D["Dust Shards"]

    D --> E["Economic Problem"]

The Fundamental Difficulty

Preventing dust requires answering a deceptively difficult question:

Is this output worth spending later?

For native assets this is relatively straightforward.

Both the output value and the spending cost are denominated in ETH.

For ERC-20 assets the problem becomes significantly harder.

The output value is denominated in the token.

The spending cost is denominated in ETH.

Determining whether an output is dust therefore requires some method of comparing:

Token Value
      vs
Future Spending Cost

This immediately becomes a pricing problem.

The protocol must determine how much of a token is equivalent to the cost of spending that token.

Without a pricing mechanism, there is no reliable way to determine whether a token output is economically recoverable.

flowchart LR

    A["ERC-20 Output"]

    A --> B["Token Value"]

    C["Future Spend"]

    C --> D["ETH Gas Cost"]

    B --> E["Need Exchange Rate"]

    D --> E

    E --> F["Dust Decision"]

Alternative Designs Considered

DEX-Based Pricing

One possibility is querying DEX liquidity directly.

The SDK could estimate:

How much token T is equivalent to the ETH required to spend token T?

While theoretically accurate, this approach introduces several problems:

Dependence on external liquidity
Susceptibility to price manipulation
Cross-chain implementation complexity
Increased SDK responsibilities
Inconsistent behavior during volatile markets

Dust prevention becomes dependent on market infrastructure rather than protocol infrastructure.

Oracle-Based Pricing

Another possibility is relying on price oracles.

This simplifies valuation but introduces new trust assumptions:

Oracle availability
Oracle correctness
Oracle freshness
Additional infrastructure dependencies

GhostShard avoids introducing separate oracle dependencies solely for dust estimation.

Why Paymaster Quotes Are the Correct Abstraction

The paymaster already performs economic evaluation.

To sponsor gas using arbitrary assets, the paymaster must determine the relationship between:

ETH-denominated gas costs
Asset-denominated payments

The pricing infrastructure therefore already exists.

Rather than introducing separate DEX integrations or oracle dependencies, GhostShard reuses the same economic authority responsible for gas sponsorship.

The SDK can request a quote from the paymaster:

How much of asset T is required to cover a transfer costing X gas?

The response directly provides the minimum economically meaningful amount for that asset under current conditions.

This makes the paymaster the natural source of truth for dust estimation.

flowchart LR

    A["Transfer Cost"]

    A --> B["Paymaster Quote"]

    C["Asset T"]

    C --> B

    B --> D["Dust Threshold"]

    D --> E["Output Generation"]

GhostShard v0 Approach

GhostShard v0 uses a fixed minimum output threshold.

Outputs below the threshold are not created.

Instead, the value is absorbed into other outputs during the split process.

The fixed threshold prevents obviously uneconomical shards from being generated while avoiding pricing dependencies in the initial implementation.

flowchart TD

    A["Randomized Output Generation"]

    A --> B{"Output Below Threshold?"}

    B -->|Yes| C["Merge Into Other Outputs"]

    B -->|No| D["Create Shard"]

    C --> E["No Dust Created"]

    D --> E

Limitations of the v0 Approach

A fixed threshold is intentionally conservative.

However:

Different assets have different transfer costs.
Different chains have different gas markets.
Different market conditions affect economic recoverability.

As a result, a threshold that is appropriate for one asset may be inappropriate for another.

The fixed threshold should therefore be viewed as an implementation compromise rather than the final architecture.

Future Direction: Paymaster-Based Dust Estimation

Future GhostShard versions replace the fixed threshold with paymaster-derived dust thresholds.

For assets not yet known to the SDK:

The SDK requests a paymaster quote.
The paymaster determines the asset cost of spending that asset.
The SDK derives a minimum economically recoverable output.
Future mesh transactions enforce that threshold.

This allows dust protection to adapt automatically to:

Asset type
Chain conditions
Transfer complexity
Market pricing

while preserving the privacy guarantees of randomized output generation.

Privacy Considerations

A fixed threshold introduces a recognizable output pattern.

If every transaction enforces the same minimum output value, that value becomes part of a visible fingerprint.

Paymaster-derived thresholds reduce this fingerprint.

Different assets naturally produce different minimum outputs, causing output distributions to more closely resemble ordinary asset transfers.

Design Outcome

Randomized output splitting inevitably creates the possibility of dust.

GhostShard v0 mitigates this through a fixed minimum threshold.

Future versions derive asset-specific thresholds directly from paymaster quotes, reusing the same economic infrastructure already required for gas sponsorship.

This eliminates separate pricing dependencies while ensuring that created shards remain economically recoverable under current market conditions.

2.9 How Do We Coordinate Shards Without ETH?

The previous sections established two important properties of the GhostShard architecture:

Ownership is distributed across many disposable shards.
A user's intent may require spending multiple shards atomically.

This creates a practical challenge.

Shards are created at unpredictable addresses and typically hold no ETH. Yet they must still execute code, authorize transfers, and participate in mesh transactions.

The user cannot simply pre-fund shards with ETH:

Pre-funding creates additional observable transactions.
Pre-funding introduces identity-linkage opportunities.
Shard addresses are derived through ECDH and are not known in advance.

The protocol therefore requires a mechanism for coordinating many independent shards without requiring those shards to maintain ETH balances.

flowchart TD

    A["Disposable Shards"]

    A --> B["Hold Assets"]

    B --> C["No ETH Balance"]

    C --> D["Cannot Pay Gas"]

    D --> E["Need Sponsored Execution"]

    E --> F["Need Coordination Layer"]

The Self-Sovereign Ideal

The ideal architecture is fully self-sovereign.

A shard holding assets should be capable of participating in transaction execution without relying on a custody layer, pooled funds, or protocol-controlled asset management.

Using EIP-7702, a shard can temporarily gain smart-contract functionality while retaining its identity as a standard EOA.

In principle, one shard could coordinate the entire transaction:

Gathering shard authorizations
Constructing the mesh transaction
Managing transfer execution
Returning change
Coordinating payment delivery

The user's funds effectively manage themselves.

What Self-Sovereignty Means

Self-sovereignty in GhostShard means that ownership never leaves the user's control.

No protocol contract holds user funds.

No liquidity pool aggregates ownership.

No custodian can freeze, seize, or redirect assets.

All assets remain controlled by user-owned shards throughout the transaction lifecycle.

The supporting infrastructure operates under minimal trust assumptions:

Relayer — may broadcast or refuse to broadcast.
Paymaster — may sponsor or refuse to sponsor.

Neither component can:

Modify transfers
Forge ownership
Create valid shard signatures
Redirect funds
Spend assets without authorization

The architecture therefore preserves user custody even when sponsored execution is required.

The ERC-4337 Path

At first glance, ERC-4337 appears to solve this problem.

ERC-4337 provides:

Gas sponsorship through paymasters
Transaction inclusion through bundlers
Account abstraction infrastructure
Broad ecosystem compatibility

A shard could use EIP-7702 delegation, behave as a smart account, and submit a UserOperation through the existing ERC-4337 ecosystem.

This would provide sponsored execution while remaining compatible with existing tooling.

The Limitation

The difficulty arises from the structure of the current ERC-4337 EntryPoint.

Each UserOperation is centered around a single account.

The EntryPoint validation flow accepts a single sender:

validateUserOp(...)
validatePaymasterUserOp(...)

Both validation paths assume one account per operation.

There is no mechanism for carrying multiple EOA authorizations inside a single UserOperation.

Importantly, this is not a limitation of account abstraction itself.

It is a limitation of the current ERC-4337 EntryPoint design.

A future EntryPoint could support multi-account authorization models.

The current infrastructure does not.

Consequence: One UserOp per Shard

If a transaction requires N shards, the user must submit N independent UserOperations.

flowchart LR

    U["User Intent<br/>Spend 10 Shards"]

    U --> U1["UserOp 1"]
    U --> U2["UserOp 2"]
    U --> U3["UserOp 3"]
    U --> U4["UserOp 4"]
    U --> UN["UserOp N"]

    U1 --> EP["ERC-4337 EntryPoint"]
    U2 --> EP
    U3 --> EP
    U4 --> EP
    UN --> EP
     EP --> P["Partial Execution Risk"]

This immediately introduces two problems.

Gas Overhead

Every UserOperation pays EntryPoint overhead.

For large shard sets, overhead grows approximately linearly with shard count.

A transaction involving ten shards incurs the overhead of ten independent UserOperations before any transfer logic executes.

The coordination layer becomes increasingly expensive as shard count increases.

Loss of Atomicity

More importantly, atomicity is lost.

The user's intent is no longer represented by a single state transition.

Instead, it is fragmented across multiple independent operations.

Consider a transaction involving three shards:

flowchart LR

    A["User Intent<br/>Send Payment"]

    A --> B["UserOp 1"]
    A --> C["UserOp 2"]
    A --> D["UserOp 3"]

    B --> E["Success"]
    C --> E

    D --> F["Failure"]

    E --> G["Partial Execution"]

    F --> G

    G --> H["Intent Broken"]

If UserOperation 3 fails:

UserOperations 1 and 2 may already have executed.
Assets may already have moved.
Remaining operations never execute.
The user's intended transfer is only partially completed.

This recreates the same user-intent execution problem identified in Section 2.5.

The architecture requires all participating shards to succeed together or fail together.

The current ERC-4337 model cannot provide this property.

Native Multi-Authorization with EIP-7702

EIP-7702 provides a different execution model.

A single type-4 transaction can carry multiple shard authorizations simultaneously.

Rather than creating N UserOperations, the transaction carries N authorizations directly.

All shards delegate into a shared execution context.

Execution occurs once.

Validation occurs once.

Atomicity is preserved.

flowchart LR

    S1["Shard 1"]
    S2["Shard 2"]
    S3["Shard 3"]
    SN["Shard N"]

    S1 --> T["Single Type-4 Transaction"]
    S2 --> T
    S3 --> T
    SN --> T

    T --> R["Relayer Broadcast"]

    R --> A["Sponsored Gas"]

    A --> P["GhostRouter"]

    P --> B["Atomic Execution"]

The GhostShard Coordination Model

GhostShard adopts a custom coordination layer built around EIP-7702's native multi-authorization capability.

The architecture combines:

Multi-shard authorization through EIP-7702
Sponsored execution through a paymaster
Transaction broadcasting through a relayer
Atomic execution through GhostRouter

Rather than coordinating many independent UserOperations, all shard authorizations are executed inside a single transaction.

If any transfer fails:

Execution reverts.
State rolls back.
No shard is partially consumed.
No ownership becomes stranded.

The user's intent succeeds completely or not at all.

Design Outcome

The fragmentation problem established that a user's intent may span many disposable shards and therefore requires atomic execution.

This section explains how that atomicity is achieved despite shards holding no ETH and existing as independent EOAs.

GhostShard combines EIP-7702 multi-authorization, sponsored execution, and a custom relayer architecture to allow many disposable ownership units to behave as a single coherent actor.

The result is self-sovereign fund management with minimal trust assumptions, low coordination overhead, and full atomic execution across all participating shards.

2.10 How Do We Verify and Execute Gas Sponsorship?

Shards are intentionally created without ETH.

This improves ownership privacy because users never need to fund newly created shard addresses directly. However, it introduces an immediate execution problem:

How can a shard execute transactions if it cannot pay gas?

GhostShard solves this through sponsored execution.

A paymaster agrees to cover transaction costs, a relayer broadcasts the transaction, and GhostRouter enforces settlement rules that guarantee both parties are treated fairly.

The challenge is not simply paying gas.

The challenge is ensuring that:

The paymaster cannot be overcharged.
The relayer cannot be underpaid.
The user cannot forge sponsorship approval.
The router can verify sponsorship entirely on-chain.

This section describes how GhostShard achieves those guarantees.

Participants

Gas sponsorship involves three actors:

User

Constructs the mesh transaction and obtains a sponsorship quote.

The user never pays ETH directly from participating shards.

Paymaster

Computes gas limits, approves sponsorship, and provides the economic backing for execution.

The paymaster maintains an ETH deposit inside GhostRouter.

Relayer

Broadcasts the transaction to the network and receives reimbursement after execution.

The relayer temporarily fronts gas costs and is compensated through post-execution reconciliation.

flowchart LR

    U["User"]
    P["Paymaster"]
    R["Relayer"]
    G["GhostRouter"]

    U -->|"Request Quote"| P

    P -->|"Signed Sponsorship"| U

    U -->|"Mesh Transaction"| R

    R -->|"Broadcast"| G

    G -->|"Gas Reimbursement"| R

    G -->|"Deposit Settlement"| P

Sponsorship Approval

Before execution, the paymaster performs gas estimation using the Double Simulation process described in Chapter 9.

From this simulation the paymaster derives:

Verification gas limit
Execution gas limit
Pre-verification gas
Expiration timestamp

The paymaster then signs a commitment covering the entire transaction context.

The commitment binds sponsorship approval to a specific transaction and prevents modification after signing.

paymasterHash = keccak256(
    abi.encode(
        block.chainid,
        address(this),
        keccak256(abi.encode(commands)),
        keccak256(abi.encode(announcements)),
        validUntil,
        keccak256(abi.encode(limits))
    )
);

The signed payload commits to:

The chain
The GhostRouter instance
The transfer commands
The announcement set
The expiration window
The approved gas limits

Any modification changes the hash and invalidates the signature.

flowchart TD

    A["Commands"]
    B["Announcements"]
    C["Gas Limits"]
    D["Expiry"]
    E["Chain Context"]

    A --> H["paymasterHash"]
    B --> H
    C --> H
    D --> H
    E --> H

    H --> S["Paymaster Signature"]

On-Chain Verification

When executeMesh() is called, GhostRouter reconstructs the sponsorship hash from the submitted transaction parameters.

The router then:

Rebuilds the hash.
Applies the EIP-191 message prefix.
Recovers the signer.
Verifies the signer matches the configured paymaster.
Verifies the sponsorship has not expired.

Conceptually:

ethHash = toEthSignedMessageHash(paymasterHash);

signer = ECDSA.recover(
    ethHash,
    paymasterSignature
);

require(signer = paymaster);
require(block.timestamp <= validUntil);

If either check fails, execution terminates before any asset movement occurs.

This ensures sponsorship cannot be forged, replayed outside its validity window, or modified after approval.

Prefund Reservation

Before executing any mesh commands, GhostRouter reserves the maximum approved gas budget.

The reservation is computed as:

prefund =
    (
        verificationGasLimit +
        callGasLimit +
        preVerificationGas
    ) * tx.gasprice;

The router verifies that the paymaster has sufficient deposited funds.

require(
    paymasterDeposits[paymaster] >= prefund
);

The prefund amount is then temporarily deducted.

paymasterDeposits[paymaster] -= prefund;

This guarantees that reimbursement funds already exist before execution begins.

flowchart LR

    P["Paymaster Deposit"]

    P -->|"Reserve Prefund"| R["Execution Budget"]

    R -->|"Execute Mesh"| E["Mesh Execution"]

    E -->|"Reconcile"| F["Final Settlement"]

Gas Reconciliation

After execution completes, GhostRouter calculates actual gas consumption.

Conceptually:

totalGasUsed =
    startGas -
    gasleft() +
    POST_EXECUTION_OVERHEAD +
    preVerificationGas;

The final charge is capped by the previously approved prefund amount.

totalGasCost =
    min(
        totalGasUsed * tx.gasprice,
        prefund
    );

Any unused portion is returned to the paymaster.

paymasterDeposits[paymaster]
    += (prefund - totalGasCost);

The relayer receives reimbursement for actual execution cost.

msg.sender.call{
    value: totalGasCost
}("");

This creates a bounded-loss system:

The paymaster cannot lose more than the approved prefund.
The relayer cannot receive less than the measured execution cost.
The user cannot manipulate reimbursement calculations.

flowchart TD

    A["Prefund Reserved"]

    A --> B["Execute Transaction"]

    B --> C["Measure Actual Gas"]

    C --> D["Compute Cost"]

    D --> E["Refund Surplus To Paymaster"]

    D --> F["Pay Relayer"]

Relayer Self-Protection

The relayer does not blindly trust the paymaster's quote.

Before broadcasting, the relayer independently performs Double Simulation.

The simulated gas requirements are compared against the paymaster's signed limits.

If the quote appears underfunded, the relayer rejects the transaction.

This protects relayers from consistently broadcasting transactions that reimburse less than actual execution cost.

As a result:

Paymasters verify transaction cost.
Relayers verify paymaster estimates.
GhostRouter verifies both.

No participant is required to trust the others blindly.

Incentive Alignment

The sponsorship system is designed so that every participant acts in its own economic interest while preserving correct execution.

Participant	Goal	Protection
User	Execute without ETH	Sponsored execution
Paymaster	Avoid overpayment	Signed limits + prefund cap
Relayer	Avoid losses	Independent simulation + reimbursement
Router	Enforce correctness	On-chain verification

The system therefore achieves gas sponsorship through verification rather than trust.

Design Outcome

GhostShard enables ETH-less shard execution through a sponsorship model built around signed approvals, prefunded deposits, and post-execution reconciliation.

The paymaster authorizes a bounded execution budget. GhostRouter verifies that authorization on-chain, reserves the approved funds, executes the mesh transaction, and reconciles actual gas usage after completion. Relayers independently verify quotes before broadcasting, ensuring they are not exposed to systematic losses.

The result is a trust-minimized sponsorship architecture in which shards can execute transactions without holding ETH while preserving economic safety for users, paymasters, and relayers.

2.11 How Do We Enable ERC-20 Gas Sponsorship?

GhostShard v0 implements ETH-based gas sponsorship only.

Paymasters maintain ETH deposits inside GhostRouter, sponsorship approvals are signed off-chain, and execution costs are settled through ETH-based gas reconciliation.

This design keeps the initial architecture simple while validating the core sponsorship model.

However, many users may hold only ERC-20 assets and no ETH.

Supporting gas payments directly from ERC-20 balances is therefore a natural extension of the protocol.

The challenge is that gas is ultimately paid in ETH, while the user wishes to pay using a different asset.

This introduces an additional pricing and settlement layer that does not exist in the ETH sponsorship model.

The Pricing Problem

ETH sponsorship is straightforward because both costs and settlement occur in the same asset.

ERC-20 sponsorship is different.

The protocol must answer a fundamental question:

How many units of token T are equivalent to the ETH required to execute this transaction?

This requires an exchange rate between ETH and the selected ERC-20 token.

GhostShard's proposed approach is a paymaster-signed quote.

The paymaster provides a signed statement specifying:

The token being accepted
The ETH-to-token conversion rate
The quote expiration timestamp

Conceptually:

1 ETH = X TOKEN T
Valid Until = Timestamp

The quote is signed by the paymaster and included as part of the transaction context.

This allows the router to convert ETH-denominated gas costs into token-denominated settlement amounts.

flowchart LR

    A["Gas Cost (ETH)"]

    B["Paymaster Quote"]

    A --> C["ETH → Token Conversion"]

    B --> C

    C --> D["ERC-20 Settlement"]

Quote Verification

Execution follows the same trust-minimized model used for ETH sponsorship.

The router reconstructs the quote payload, verifies the paymaster signature, and validates the expiration window.

Only quotes signed by an approved paymaster are accepted.

This ensures that users cannot fabricate exchange rates and relayers cannot modify settlement terms.

The paymaster remains fully responsible for determining the quoted conversion rate.

ERC-20 Prefunding

Once a quote is verified, the router can calculate the maximum ERC-20 amount required to cover execution.

Conceptually:

Maximum Token Cost
    =
Maximum ETH Cost
    ×
Quoted Exchange Rate

The corresponding token amount is reserved before execution begins.

This reservation serves the same purpose as ETH prefunding in the v0 architecture:

Relayers receive guaranteed reimbursement.
Users cannot spend the same funds twice.
Paymasters can bound their economic exposure.

The Remaining Funds Problem

Unlike ETH sponsorship, ERC-20 sponsorship introduces a new challenge.

The exact execution cost is unknown before execution begins.

As a result, the prefunded token amount must exceed the expected cost.

After reconciliation, excess tokens remain.

Those excess tokens must be returned to the user.

The question is:

Where should they go?

This turns out to be surprisingly difficult.

Option 1: Dedicated Gas Shards

One approach is to create a dedicated shard specifically for gas refunds.

Unused tokens would be transferred to this shard after reconciliation.

flowchart LR

    A["ERC-20 Prefund"]

    A --> B["Execution"]

    B --> C["Unused Tokens"]

    C --> D["Gas Refund Shard"]

This approach preserves ownership of the excess funds but introduces several drawbacks:

Additional shard management complexity
Extra state growth
Additional discovery overhead
Potential linkage opportunities if refund shards are reused incorrectly

The refund mechanism itself becomes part of the ownership graph.

Option 2: Sweep Back to a Spent Shard

Another possibility is returning excess funds to one of the shards consumed during execution.

The user already possesses the shard's private key and can theoretically recover the funds later.

flowchart LR

    A["ERC-20 Prefund"]

    A --> B["Execution"]

    B --> C["Unused Tokens"]

    C --> D["Previously Spent Shard"]

This approach avoids creating additional ownership structures.

However, it introduces different tradeoffs:

Recovery becomes an off-protocol operation.
Small residual balances may be uneconomical to recover.
Accurate gas estimation becomes more important.
Excessive overestimation can strand value.

The economic cost of estimation error is shifted toward the user.

Why This Remains Open Research

Both approaches solve part of the problem.

Neither solves it completely.

Dedicated refund shards preserve protocol-native recovery but increase complexity.

Spent-shard recovery simplifies protocol state but increases reliance on estimation accuracy.

Additional designs are possible, including:

Dynamic refund shards
Refund pools
Deferred settlement models
Hybrid approaches

Each introduces different privacy, complexity, and economic tradeoffs.

The optimal design remains an open research question.

Current Status

GhostShard v0 deliberately avoids this complexity.

The current implementation supports:

Paymaster verification
ETH sponsorship
Deposit prefunding
Gas reconciliation
Relayer reimbursement

ERC-20 gas sponsorship is not part of the v0 protocol.

The architecture described in this section represents a future extension rather than a deployed component.

Design Outcome

GhostShard v0 implements gas sponsorship exclusively through ETH-backed paymaster deposits.

ERC-20 sponsorship introduces additional pricing and settlement challenges because transaction costs are denominated in ETH while user balances are denominated in arbitrary tokens.

The protocol's proposed approach uses paymaster-signed exchange-rate quotes and token-based prefunding. However, the problem of returning excess funds without introducing complexity, economic inefficiency, or privacy leakage remains unresolved.

ERC-20 gas sponsorship therefore remains future work and is intentionally excluded from the v0 implementation.

2.12 Announcement and Discovery

The previous sections established how ownership is created, fragmented, compressed, transferred, and coordinated.

A mesh transaction consumes existing shards and creates new shards.

This naturally raises two questions:

How are receiving shards determined?

How do recipients discover which shards belong to them?

These questions are fundamental.

GhostShard's ownership model requires permissionless ownership transfer.

A sender must be able to create ownership units for a recipient:

Without prior coordination
Without requiring the recipient to be online
Without revealing the recipient's ownership publicly

At the same time, recipients must be able to discover newly received shards without exposing their ownership graph to observers.

The protocol therefore requires a discovery mechanism that satisfies three properties:

Anyone can send ownership units to a recipient.
Only the intended recipient can identify those ownership units.
Discovery does not reveal ownership to external observers.

Meta-Addresses

Before a sender can create receiving shards, it must have a way to reference the recipient without learning or reusing the recipient's actual ownership addresses.

GhostShard solves this using ERC-5564 meta-addresses.

A meta-address is a public receiving identifier that allows anyone to derive receiving shards for a recipient without learning the recipient's ownership graph.

Importantly, a meta-address is not an ownership address.

It never directly holds assets.

Instead, it acts as a reusable destination from which fresh receiving shards can be derived.

flowchart LR

    A["Recipient"]

    A --> B["Meta-Address"]

    C["Sender"]

    C --> B

    B --> D["Fresh Receiving Shard"]

    D --> E["Ownership Transfer"]

A recipient may publish a meta-address through:

Direct communication
Application-level contact sharing
QR codes
An ERC-ERC6538 registry

The mechanism used to derive receiving shards from a meta-address is discussed in Chapter 4.

For the purposes of this chapter, the important observation is architectural:

Meta-addresses allow recipients to expose a stable receiving identifier without exposing ownership addresses.

Receiving Shards

GhostShard uses ERC-5564 as its ownership announcement and discovery mechanism.

When constructing a mesh transaction, the sender uses the recipient's meta-address to derive one or more receiving shards.

The recipient does not need to pre-generate receiving addresses, remain online, or participate in the transaction.

Ownership can therefore be transferred permissionlessly.

flowchart LR

    A["Sender"]

    B["Recipient Meta-Address"]

    A --> B

    B --> C["Create Receiving Shards"]

    C --> D["Mesh Transaction"]

    D --> E["Recipient Offline or Online"]

The mechanism used to derive receiving shards is defined by ERC-5564 and discussed in detail in Chapter 4.

For the purposes of this chapter, the important observation is architectural:

Receiving ownership can be created without prior interaction between sender and recipient.

Announcements

Creating a shard alone is insufficient.

The recipient must also learn that the shard exists.

GhostShard therefore publishes ERC-5564 announcements alongside mesh transaction outputs.

Announcements serve as ownership discovery signals.

They allow recipients to identify newly received ownership units without revealing ownership publicly.

Observers can see that announcements exist.

They cannot determine:

Who the intended recipient is.
Which shard belongs to which recipient.
Whether a particular recipient owns any output at all.

flowchart LR

    A["Mesh Transaction"]

    A --> B["Create Output Shards"]

    A --> C["Publish ERC-5564 Announcements"]

    B --> D["Public Blockchain"]

    C --> D

The exact announcement format, encryption scheme, and key derivation process are discussed later in Chapter 4.

Discovery

Recipients discover ownership by scanning announcements and applying the ERC-5564 discovery process.

Successful discovery reveals ownership information to the intended recipient.

Unsuccessful discovery reveals nothing.

From an external observer's perspective, all announcements appear identical.

The observer can see that discovery is possible.

They cannot determine who successfully discovered ownership.

flowchart LR

    A["Announcements"]

    A --> B["Recipient Scan"]

    B --> C["ERC-5564 Discovery"]

    C --> D["Owned Shards"]

    D --> E["Local Shard Store"]

The cryptographic mechanisms that make this possible are examined in Chapter 4.

This chapter focuses only on the architectural role of discovery within the ownership lifecycle.

Architectural Significance

Announcements complete the disposable ownership model.

Without meta-addresses, senders would have no way to derive receiving ownership.

Without announcements, ownership could be transferred but not discovered.

Without discovery, ownership would exist but be unusable.

Together, meta-addresses and announcements provide the missing link between ownership creation and ownership utilization.

flowchart LR

    A["Meta-Address"]

    A --> B["Create Receiving Shard"]

    B --> C["Publish Announcement"]

    C --> D["Recipient Discovery"]

    D --> E["Shard Available"]

    E --> F["Future Mesh Spend"]

    F --> G["Shard Retired"]

The important observation is architectural:

Ownership can be transferred permissionlessly while remaining discoverable only by the intended recipient.

A shard can now be created, transferred, discovered, spent, and retired without exposing persistent ownership relationships on-chain.

This completes the ownership lifecycle.

The cryptographic foundations that make announcement and discovery possible are deferred to Chapter 4.

The next question naturally follows:

If ownership remains private by default, how can users selectively prove ownership when required?

The answer leads directly to the selective disclosure model.

2.13 Selective Disclosure and Compliance

Privacy and compliance are often presented as opposing goals.

GhostShard rejects this assumption.

The objective of privacy is not to make information impossible to reveal.

The objective is to ensure that information is revealed only when the owner chooses to reveal it.

This distinction is critical for institutional adoption.

Organizations must regularly demonstrate compliance with tax authorities, auditors, regulators, counterparties, and internal governance processes.

A privacy system that prevents disclosure entirely is unusable for institutional finance.

A privacy system that exposes everything by default is incompatible with financial confidentiality.

GhostShard therefore adopts a model of selective disclosure:

Reveal exactly what is required, and nothing more.

The Compliance Problem

Institutions frequently need to prove that specific transfers occurred.

Examples include:

Vendor payments
Payroll distributions
Treasury operations
Tax reporting
Regulatory investigations
Financial audits

In a transparent blockchain system, proving a transfer is trivial because the transaction is publicly visible.

In a privacy-preserving system, the transaction is intentionally hidden.

This creates a new requirement:

How can a user prove a transaction without exposing their entire financial history?

GhostShard addresses this through layered disclosure mechanisms.

Disclosure Granularity

Not all compliance requirements require the same level of visibility.

Different situations require different disclosure scopes.

flowchart TD

    A["Selective Disclosure"]

    A --> B["Single Transfer"]

    A --> C["Bounded Transaction Set"]

    A --> D["Full History"]

    B --> E["Vendor Payment"]
    C --> F["Audit Sample"]
    D --> G["Regulatory Investigation"]

The goal is always to disclose the smallest amount of information necessary.

Level 1: Transaction-Level Disclosure

The default disclosure mechanism in GhostShard v0 is transaction-level disclosure.

A user can prove a specific transfer without revealing unrelated activity.

The proof reveals only the information associated with the transfer being examined.

For example:

Asset type
Amount
Timestamp
Recipient relationship
Relevant announcement data

All unrelated shards remain private.

All unrelated balances remain private.

All future activity remains private.

flowchart LR

    A["Wallet History"]

    A --> B["Transfer A"]
    A --> C["Transfer B"]
    A --> D["Transfer C"]
    A --> E["Transfer D"]

    C --> F["Disclosed"]

    B --> G["Private"]
    D --> G
    E --> G

This represents the preferred disclosure model for most business use cases.

Level 2: Bounded Historical Disclosure

Some compliance scenarios require proving multiple related transactions.

Examples include:

Quarterly audits
Treasury reviews
Counterparty reconciliation
Internal investigations

In these situations, a user may wish to disclose a specific subset of historical activity without exposing the remainder of their transaction history.

The disclosed set remains bounded and explicitly selected.

Only the chosen transactions become visible.

The rest of the ownership graph remains private.

Future activity remains private.

This capability is a future enhancement and is expected to rely on cryptographic proofs that demonstrate ownership relationships without exposing viewing credentials.

Level 3: Full Historical Disclosure

As a last resort, a user may voluntarily disclose complete wallet history.

This level of disclosure may be appropriate for:

Regulatory investigations
Comprehensive audits
Tax authority reviews
Legal proceedings

Under full disclosure, an authorized reviewer gains visibility into all discoverable ownership associated with the disclosed wallet.

flowchart LR

    A["Wallet History"]

    A --> B["Transaction 1"]
    A --> C["Transaction 2"]
    A --> D["Transaction 3"]
    A --> E["Transaction N"]

    B --> F["Auditor"]
    C --> F
    D --> F
    E --> F

Because this disclosure scope is broad and difficult to revoke, it should be treated as an exceptional rather than routine action.

Deterministic Institutional Proofs

Large institutions face a practical challenge when generating transaction proofs.

A payment may need to be verified months or years after it occurred.

Managing large volumes of transaction-specific proof material can become operationally expensive.

GhostShard therefore supports deterministic proof generation from existing business identifiers.

Examples include:

Invoice identifiers
Purchase order numbers
Settlement references
UUIDs
Internal payment references

Rather than maintaining separate proof-management infrastructure, institutions can derive proof material from identifiers that already exist within their operational workflows.

flowchart LR

    A["Invoice ID / UUID"]

    A --> B["Deterministic Derivation"]

    B --> C["Generate Proof"]

    C --> D["Auditor Verification"]

This reduces operational complexity while preserving the ability to generate localized compliance proofs.

The cryptographic details of deterministic proof generation are discussed in Chapter 4.

For the purposes of this chapter, the important observation is architectural:

Existing business identifiers can act as anchors for future compliance proofs.

Privacy–Compliance Coexistence

GhostShard does not attempt to eliminate disclosure.

Instead, it transfers control of disclosure from the public blockchain to the asset owner.

The owner decides:

What is disclosed.
To whom it is disclosed.
At what level of granularity disclosure occurs.

Privacy and compliance therefore become complementary rather than contradictory.

Privacy protects information by default.

Compliance reveals information by exception.

Design Outcome

GhostShard adopts a selective disclosure model rather than a transparency model.

Transactions remain private by default, but users retain the ability to disclose information at multiple levels of granularity:

Disclosure Level	Scope	Typical Use Case
Transaction-Level	Single transfer	Vendor payment verification
Bounded History	Selected transaction set	Audit samples, reconciliation
Full History	Complete wallet history	Regulatory review, legal disclosure

The result is a system that preserves privacy during normal operation while remaining compatible with institutional auditing, reporting, and compliance requirements.

2.14 How Do We Privatize NFTs?

NFTs are fundamentally harder to privatize than fungible assets.

Fungible assets can be divided, pooled, merged, compressed, and redistributed across many ownership units.

NFTs cannot.

An NFT exists as a single indivisible token controlled by a single address at any point in time.

This creates a challenge for most privacy systems.

Privacy mechanisms designed for fungible assets typically rely on denomination pools, note systems, or balance aggregation. None of these approaches naturally apply to unique assets.

The question therefore becomes:

How can ownership of a unique asset be privatized without modifying the NFT itself?

Why Existing Approaches Struggle

Many privacy systems are built around fungibility.

Mixers

Mixers rely on identical denominations.

Users deposit assets into a common pool and later withdraw equivalent assets.

This works because one ETH is interchangeable with another ETH.

NFTs are unique.

A CryptoPunk cannot be exchanged for another CryptoPunk without changing the asset itself.

As a result, mixer-based privacy does not naturally extend to NFTs.

Privacy Pools

Privacy pools represent ownership as fungible notes.

Each note corresponds to some claim on pooled assets.

NFTs do not fit this model because ownership cannot be represented as interchangeable shares.

The NFT must either:

Remain outside the pool
Be wrapped into another asset type

Both approaches introduce additional complexity and trust assumptions.

Zero-Knowledge Ownership Systems

Some privacy systems use zero-knowledge proofs to hide NFT ownership.

These systems can provide strong privacy guarantees but often require:

Specialized circuits
Asset-specific logic
Complex proving systems
Additional protocol infrastructure

While powerful, they significantly increase implementation complexity.

The GhostShard Observation

GhostShard does not attempt to privatize the NFT itself.

Instead, GhostShard privatizes the ownership unit that controls the NFT.

The NFT remains unchanged.

The ERC-721 contract remains unchanged.

The transfer mechanics remain unchanged.

Only ownership attribution changes.

The NFT is held by a shard.

That shard is unlinkable to the owner.

Therefore ownership of the NFT becomes unlinkable.

flowchart LR

    A["NFT #123"] --> B["Shard Address"]

    B --> C["Ownership Hidden"]

    C --> D["Owner Unknown"]

This is the same mechanism that privatizes:

ETH
ERC-20 tokens
ERC-721 NFTs

GhostShard introduces no NFT-specific privacy infrastructure.

The shard model already provides the required ownership ambiguity.

Receiving NFTs

NFT transfers follow the same recipient derivation process used for fungible assets.

The sender:

Uses the recipient's ERC-5564 meta-address.
Derives a shared secret.
Derives a receiving shard.
Transfers the NFT to that shard.

flowchart LR

    A["Recipient Meta-Address"]

    A --> B["ECDH Shared Secret"]

    B --> C["Receiving Shard"]

    C --> D["Transfer NFT"]

The recipient does not need to be online.

No interaction is required.

No receiving address must be pre-generated.

NFT Announcements

After transferring the NFT, the sender publishes an ERC-5564 announcement.

The announcement allows the recipient to discover ownership of the newly created shard.

For NFT transfers:

assetType = ERC721
identifier = tokenId

The token identifier is encoded within the announcement payload.

Only the intended recipient can decrypt and interpret this information.

Observers see the announcement but cannot determine:

The recipient
The shard owner
The decrypted metadata

flowchart LR

    A["NFT Transfer"]

    A --> B["ERC-5564 Announcement"]

    B --> C["Recipient Discovery"]

    C --> D["NFT Shard Recovered"]

Discovery

Discovery is identical to the discovery process described in the previous section.

The recipient scans announcements and performs trial decryption.

If the announcement belongs to them:

The shared secret is recovered.
The shard address is reconstructed.
The NFT ownership is added to the shard store.

No NFT-specific discovery logic is required.

The discovery pipeline is entirely asset-agnostic.

flowchart LR

    A["Announcements"]

    A --> B["Trial Decryption"]

    B --> C{"Valid?"}

    C -->|No| D["Ignore"]

    C -->|Yes| E["Recover NFT Shard"]

    E --> F["Add To Wallet"]

Spending NFTs

NFT transfers are executed through the same mesh transaction mechanism used for fungible assets.

A mesh transaction may contain:

Native transfers
ERC-20 transfers
ERC-721 transfers

within the same atomic execution context.

The NFT transfer is represented as a command executed inside the router's execution sandbox.

If any command fails:

The NFT transfer reverts.
All fungible transfers revert.
All announcements revert.

The entire user intent succeeds or fails as a single unit.

flowchart TD

    A["Mesh Transaction"]

    A --> B["ERC20 Transfer"]

    A --> C["NFT Transfer"]

    A --> D["Announcements"]

    B --> E["Atomic Execution"]
    C --> E
    D --> E

    E --> F["All Succeed"]

    E --> G["Or All Revert"]

What NFT Privacy Protects

GhostShard provides ownership privacy.

GhostShard does not provide asset invisibility.

This distinction is important.

The ERC-721 contract remains public.

Anyone can still observe:

ownerOf(tokenId)
Transfer(from, to, tokenId) events
The token identifier itself

An observer can see that a specific NFT moved between two addresses.

What they cannot determine is:

Who controls the sending shard
Who controls the receiving shard
Whether multiple shards belong to the same user

The NFT remains visible.

The owner becomes ambiguous.

flowchart LR

    A["Observer"]

    A --> B["Sees NFT #123"]

    B --> C["Sees Address A -> Address B"]

    C --> D["Cannot Link Either Address To User"]

Limitations

NFT privacy inherits the limitations of public NFT ledgers.

For highly recognizable assets, the token itself may reveal information.

Examples include:

High-value collectibles
Rare art NFTs
Named institutional assets

An observer may know what was transferred.

GhostShard only prevents them from knowing who controls it.

This is fundamentally different from fungible assets, where both ownership and value can be obscured through output scattering.

Design Outcome

GhostShard does not require special NFT privacy infrastructure.

NFTs are privatized through the same ownership ambiguity that privatizes fungible assets.

An NFT held by a shard is private because the shard itself is unlinkable to its owner.

No wrapping, pooling, note systems, or NFT-specific circuits are required.

The privacy guarantee is ownership ambiguity rather than transaction invisibility.

Observers can see that a particular token moved between two shard addresses, but they cannot determine who controls either address or whether multiple NFT shards belong to the same entity.

2.15 Metadata Length Standardization

Section 2.13 introduced selective disclosure, where transaction metadata (senderInfo) is encrypted within ERC-5564 announcements and can later be revealed to auditors, regulators, or counterparties on a transaction-by-transaction basis.

This capability introduces a subtle privacy challenge.

While the contents of senderInfo are encrypted, the length of the encrypted payload remains publicly visible on-chain.

If announcement metadata is allowed to vary in size, observers may be able to extract information without decrypting a single byte.

The Metadata Fingerprinting Problem

Mesh transactions rely on structural uniformity.

Every output should appear indistinguishable from every other output.

Observers should not be able to determine:

Which outputs belong to recipients.
Which outputs are change.
Which outputs belong to the same participant.
Which outputs represent the same type of activity.

However, variable-length encrypted metadata introduces an unintended fingerprint.

Consider two announcements:

Announcement	Encrypted Metadata Size
A	128 bytes
B	340 bytes

Even though both payloads are encrypted, the difference in size is observable.

Over time, observers can begin clustering announcements according to metadata length.

This creates a new source of information leakage.

Sources of Length-Based Fingerprinting

Sender Fingerprinting

Different institutions often use different metadata formats.

One sender may include only the minimum required information.

Another may include invoice references, payment identifiers, or internal accounting data.

As a result, announcements originating from the same institution may repeatedly produce similar ciphertext lengths.

Observers can gradually construct sender profiles based solely on metadata size.

flowchart LR

    A["Institution A"] --> B["128 Byte Metadata"]

    C["Institution B"] --> D["340 Byte Metadata"]

    B --> E["Observable Pattern"]

    D --> E

Recipient Fingerprinting

Metadata may also vary according to recipient-specific information.

If certain counterparties consistently receive announcements of similar sizes, observers may be able to group outputs belonging to the same recipient even without identifying them directly.

The metadata remains encrypted.

The structure itself becomes the signal.

Content Fingerprinting

Different transaction types naturally produce different metadata footprints.

Examples include:

Simple transfers
Invoice-linked payments
NFT transfers
Multi-asset settlements
Payments containing memos

Without standardization, these activities can become distinguishable through ciphertext size alone.

flowchart LR

    A["Simple Transfer"]

    B["NFT Transfer"]

    C["Multi-Asset Transfer"]

    D["Invoice Payment"]

    A --> E["Different Metadata Lengths"]
    B --> E
    C --> E
    D --> E

    E --> F["Content Classification"]

Why This Matters

The privacy of mesh transactions relies heavily on combinatorial ambiguity.

With multiple outputs, an observer should face many plausible interpretations of ownership.

The observer should not know which outputs belong to recipients and which belong to change.

If output structures begin to differ, clustering becomes possible.

Outputs that share similar metadata lengths can be grouped together, reducing uncertainty and shrinking the effective anonymity set.

The encrypted contents remain private.

The observable structure becomes the leak.

flowchart TD

    A["Identical Outputs"]

    A --> B["Large Anonymity Set"]

    C["Variable Metadata Length"]

    C --> D["Output Clustering"]

    D --> E["Reduced Anonymity Set"]

Standardized Metadata Length

To eliminate this fingerprinting vector, GhostShard standardizes the size of encrypted metadata.

Before encryption, every senderInfo payload is padded to a fixed length.

plaintext  = senderInfo || randomPadding

ciphertext = AES-256-GCM(plaintext)

Regardless of the actual content:

Every encrypted metadata blob has the same size.
Every announcement appears structurally identical.
Metadata length no longer reveals information about the sender, recipient, or transaction type.

Shorter payloads are padded before encryption.

Payloads that exceed the maximum supported size must be truncated or referenced through external data mechanisms.

flowchart LR

    A["Short Metadata"]

    B["Medium Metadata"]

    C["Long Metadata"]

    A --> D["Pad To Fixed Length"]
    B --> D
    C --> D

    D --> E["Encrypt"]

    E --> F["Uniform Ciphertext Size"]

Design Properties

Metadata standardization provides several important guarantees:

Sender Independence Different institutions produce indistinguishable announcement sizes.
Recipient Independence Outputs cannot be clustered based on recipient-specific metadata length.
Content Independence Transaction type cannot be inferred from announcement size.
Selective Disclosure Compatibility The internal contents of senderInfo remain unchanged and can still be selectively disclosed when required.
Authenticated Encryption Preservation Padding occurs inside the AES-256-GCM authenticated boundary. Any modification to the ciphertext remains detectable.

Cost of Standardization

Standardization increases calldata usage because additional padding bytes must be transmitted.

This introduces a modest gas overhead.

The exact cost depends on:

The chosen fixed metadata size.
The number of announcements.
The deployment environment (L1 versus L2).

The additional cost is generally small relative to the privacy gained.

More importantly, the overhead scales predictably and does not introduce new trust assumptions or protocol complexity.

Design Outcome

Selective disclosure enables institutions to reveal specific transactions without exposing their broader transaction history.

Metadata length standardization ensures that this capability does not create a new fingerprinting vector.

By enforcing a uniform encrypted metadata size across all announcements, GhostShard preserves the structural indistinguishability of mesh transaction outputs and prevents observers from classifying transactions based solely on ciphertext length.

Privacy therefore depends on cryptographic ownership ambiguity rather than accidental differences in metadata structure.

2.16 Architectural Evolution

GhostShard was not designed in a single step.

The architecture emerged from a sequence of constraints.

Each solution introduced a new problem.

Each new problem forced another architectural decision.

Some decisions were unavoidable consequences of previous choices.

Others emerged independently from broader goals such as compliance, privacy hardening, and asset coverage.

This section maps the architectural evolution of the protocol and shows how the various components fit together.

The Primary Causal Chain

The following sequence forms the architectural spine of GhostShard.

Each step is a direct consequence of the previous one.

Removing any link breaks the system.

flowchart TD

    A["2.1 EVM Ownership Visibility"]

    A --> B["2.2 Privacy Must Protect Ownership"]

    B --> C["2.2b Privacy Must Be Default"]

    C --> D["2.3 Ownership Must Be Disposable"]

    D --> E["2.4 Shards"]

    E --> F["2.5 Fragmentation"]

    F --> G["Compression"]

    F --> H["Atomic Execution"]

    H --> I["Shared Execution"]

    I --> J["EIP-7702"]

    J --> K["Gas Sponsorship"]

    K --> L["Relayers"]

    L --> M["GhostShard v0"]

2.1 → Ownership Visibility

The EVM exposes ownership directly.

Every address accumulates:

Transaction history
Balance history
Relationship history
Behavioral history

Even if transaction details are hidden, ownership remains observable.

This means transaction privacy alone is insufficient.

The ownership layer itself becomes the source of information leakage.

flowchart LR

    A["Address"]

    A --> B["Transaction History"]

    A --> C["Balance History"]

    A --> D["Relationship Graph"]

    A --> E["Behavioral Patterns"]

    B --> F["Ownership Visibility"]
    C --> F
    D --> F
    E --> F

2.2 → Privacy Must Protect Ownership

If ownership is the leak, ownership must become ambiguous.

Privacy cannot merely hide transfers between known owners.

It must prevent observers from confidently determining who owns what.

This shifts privacy from the transaction layer to the ownership layer.

flowchart LR

    A["Transaction Privacy"]

    A --> B["Transfers Hidden"]

    B --> C["Ownership Still Visible"]

    C --> D["Insufficient"]

    D --> E["Ownership Privacy"]

2.2b → Privacy Must Be Default

Opt-in privacy creates a small identifiable anonymity set.

Users who actively choose privacy become distinguishable from those who do not.

A privacy system intended for institutional adoption must avoid this distinction.

Privacy therefore becomes the default behavior of the protocol rather than an optional feature.

flowchart LR

    A["Opt-In Privacy"]

    A --> B["Small Privacy Set"]

    B --> C["Users Become Identifiable"]

    C --> D["Weak Privacy"]

    E["Default Privacy"]

    E --> F["Everyone Uses Same Structure"]

    F --> G["Large Anonymity Set"]

2.3 → Ownership Must Be Disposable

Persistent ownership accumulates information over time.

Even unlinkable transactions become linkable if they continuously originate from the same address.

The solution is temporary ownership.

Ownership units are created, used, and permanently retired.

History never accumulates.

flowchart LR

    A["Persistent Address"]

    A --> B["More History"]

    B --> C["More Linkability"]

    D["Disposable Shard"]

    D --> E["Single Lifecycle"]

    E --> F["Retired Forever"]

2.4 → Disposable Ownership Requires Shards

Disposable ownership requires a concrete representation.

The ownership unit must be:

Independent
Cheap to create
EVM-compatible
Compatible with all asset types
Disposable after use

EOAs satisfy these requirements naturally.

GhostShard therefore represents ownership using disposable EOAs called shards.

flowchart TD

    A["Disposable Ownership"]

    A --> B["Independent"]

    A --> C["Cheap"]

    A --> D["EVM Compatible"]

    A --> E["Asset Agnostic"]

    A --> F["Disposable"]

    B --> G["EOA Shards"]
    C --> G
    D --> G
    E --> G
    F --> G

2.5 → Shards Create Fragmentation

Each incoming transfer creates a new shard.

As activity grows, users accumulate increasingly large shard sets.

A single payment may require spending many shards simultaneously.

Fragmentation therefore becomes inevitable.

flowchart LR

    A["1 Deposit"]

    A --> B["1 Shard"]

    C["100 Deposits"]

    C --> D["100 Shards"]

    D --> E["Fragmentation"]

2.5 → Fragmentation Requires Compression

Without intervention, shard count grows indefinitely.

Compression reduces long-term shard growth by consuming additional shards during ordinary spending operations.

The result is bounded shard-store growth.

flowchart LR

    A["Many Small Shards"]

    A --> B["Compression"]

    B --> C["Fewer Shards"]

    C --> D["Bounded Growth"]

2.5 → Fragmentation Requires Atomic Execution

Fragmentation creates another problem.

A single user intent may involve many shards.

Partial execution would leave funds stranded across partially completed operations.

User intent therefore requires atomicity.

flowchart TD

    A["User Intent"]

    A --> B["Shard A"]
    A --> C["Shard B"]
    A --> D["Shard C"]

    B --> E["Atomic Execution"]
    C --> E
    D --> E

    E --> F["All Succeed"]

    E --> G["Or All Revert"]

2.7 → Atomic Execution Requires Shared Execution

Empty EOAs cannot coordinate themselves.

Multiple shards must temporarily act as a single execution unit.

This requires delegation into a shared execution environment.

flowchart LR

    A["Shard A"]
    B["Shard B"]
    C["Shard C"]

    A --> D["Shared Execution Context"]
    B --> D
    C --> D

    D --> E["Atomic Mesh Transaction"]

2.7 → Shared Execution Requires EIP-7702

ERC-4337 provides account abstraction but currently processes only a single sender per UserOperation.

GhostShard requires multiple shard authorizations within a single execution context.

EIP-7702 provides this capability natively through authorization lists.

This enables true multi-shard atomic execution.

flowchart LR

    A["Multiple Shards"]

    A --> B["Multiple Authorizations"]

    B --> C["EIP-7702 Authorization List"]

    C --> D["Single Atomic Transaction"]

2.9 → EIP-7702 Requires Gas Sponsorship

Shards contain assets but hold no ETH.

Without sponsorship, they cannot pay transaction fees.

The protocol therefore requires a mechanism that allows execution without pre-funding shards.

Paymasters solve this problem.

flowchart LR

    A["Shard"]

    A --> B["No ETH"]

    B --> C["Cannot Pay Gas"]

    C --> D["Paymaster Sponsorship"]

2.10 → Gas Sponsorship Requires Relayers

Someone must broadcast the sponsored transaction.

The relayer performs this role.

Its authority is intentionally narrow.

The relayer can:

Broadcast
Refuse to broadcast

The relayer cannot:

Modify transactions
Forge transactions
Steal assets

The result is minimal trust.

flowchart LR

    A["Signed Mesh Transaction"]

    A --> B["Relayer"]

    B --> C["Ethereum Network"]

    D["Can Broadcast"]

    E["Can Refuse"]

    F["Cannot Modify"]

    G["Cannot Steal"]

    B --- D
    B --- E
    B --- F
    B --- G

Parallel Architectural Branches

Not every component emerged from the primary chain.

Several subsystems arise independently from separate design goals.

These branches complement the architecture rather than extend the causal spine.

Compliance Branch

Driven by:

Privacy without sacrificing auditability.

flowchart TD

    A["Selective Disclosure"]

    A --> B["Per-Transaction Proofs"]

    B --> C["Deterministic Shared Secrets"]

    C --> D["Future ZK Compliance Proofs"]

This branch allows institutions to reveal specific transactions without exposing complete wallet histories.

Privacy Hardening Branch

Driven by:

Maximum practical privacy.

Metadata Privacy

flowchart TD

    A["Metadata Fingerprinting"]

    A --> B["Metadata Standardization"]

    B --> C["Uniform Encrypted Payloads"]

Dust Protection

flowchart TD

    A["Output Randomization"]

    A --> B["Dust Creation"]

    B --> C["Dust Protection"]

    C --> D["Future Adaptive Thresholds"]

These decisions do not create privacy.

They preserve privacy by removing secondary information leaks.

Asset Coverage Branch

Driven by:

Privacy should apply to all ownership types.

flowchart TD

    A["Fungible Assets"]

    A --> B["NFT Ownership"]

    B --> C["Unified Shard Model"]

Rather than building separate privacy infrastructure for NFTs, GhostShard extends the same ownership model to all asset classes.

Architectural Convergence

All branches ultimately converge into GhostShard.

flowchart TD

    A["Ownership Visibility"]

    A --> B["Disposable Ownership"]

    B --> C["Shards"]

    C --> D["Compression"]

    C --> E["Atomic Execution"]

    D --> F["GhostShard v0"]

    E --> G["EIP-7702"]

    G --> H["Gas Sponsorship"]

    H --> F

    I["Compliance Branch"]

    J["Privacy Hardening"]

    K["Asset Coverage"]

    I --> F
    J --> F
    K --> F

What This Reveals

The most important observation is that GhostShard is not a collection of unrelated features.

Compression exists because shards fragment.

Atomic execution exists because compression alone is insufficient.

EIP-7702 exists because atomic multi-shard execution requires shared execution.

Relayers exist because sponsored execution requires transaction propagation.

Each decision is a response to a constraint introduced by the previous decision.

The architecture therefore resembles a dependency graph rather than a feature list.

The primary causal chain forms the protocol's structural backbone.

The compliance, privacy-hardening, and asset-coverage branches extend that backbone toward practical deployment.

Together they form GhostShard v0.

The next chapters distills these architectural decisions into the core design principles that govern the protocol.