Skip to content

1. Introduction

1.1 Motivation

Every transaction executed on a public Ethereum Virtual Machine (EVM) network permanently records the core parameters of a state transition: the sender, receiver, execution data, transferred amount, token contract, and timestamp. This transparency is a fundamental property of public blockchain systems and enables independent verification of network state. However, within the EVM's account-based model, transparency comes at the cost of persistent ownership visibility.

Unlike UTXO-based systems, where ownership can be distributed across many independent outputs, an EVM Externally Owned Account (EOA) functions simultaneously as a user's execution origin, asset container, and public identity. Over time, this creates a persistent financial profile that can be observed, analyzed, and correlated across the entire history of the chain.

The current state of EVM privacy introduces several significant challenges:

Deterministic Transfer Transparency

Every transfer of native assets or ERC-20 tokens is publicly observable. Standardized events such as:

Transfer(address indexed from, address indexed to, uint256 value)

allow observers to reconstruct the exact flow of assets across the network. Any participant operating a standard RPC node can index and analyze these transfers in real time.

Address Clustering and Identity Correlation

Chain analysis systems employ clustering heuristics to associate multiple addresses with a single entity. Common signals include:

  • Shared funding sources
  • Exchange withdrawal patterns
  • Co-spend behavior
  • Temporal transaction correlation
  • Repeated interaction patterns

Over time, these techniques allow observers to build increasingly accurate ownership maps linking seemingly independent addresses.

NFT Ownership Exposure

The ERC-721 and ERC-1155 standards expose ownership through public view functions such as ownerOf() and balanceOf(). As a result, any observer can enumerate the complete non-fungible asset portfolio of a target address.

Because NFTs often represent unique assets, memberships, identities, achievements, or event attendance records, they can become powerful correlation anchors that connect on-chain activity to real-world personas.

Wealth Inference and Economic Targeting

Public state visibility enables observers to estimate a user's financial position by aggregating balances across native assets, tokens, staking positions, and yield-bearing protocols.

This transparency creates opportunities for:

  • Targeted phishing campaigns
  • Social engineering attacks
  • Competitive intelligence gathering
  • MEV exploitation
  • Real-world coercion and extortion

Transaction Graph Analysis

The transaction graph reveals far more than balances. Counterparty relationships, business operations, interaction frequency, and behavioral patterns can all be inferred from historical activity.

By analyzing contract interactions, trading patterns, lending activity, bridge usage, and transaction timing, adversaries can construct behavioral profiles capable of identifying users and predicting future actions.

The Ownership Visibility Problem

The consequence of these properties is not merely transaction transparency but persistent ownership transparency.

An observer can often determine:

  • What assets a user owns
  • How much they own
  • Who they interact with
  • How they use their assets
  • How their holdings evolve over time

As a result, privacy failures on the EVM are fundamentally ownership failures rather than transaction failures.

GhostShard begins from the observation that meaningful privacy cannot be achieved solely by obscuring individual transactions. Instead, privacy should emerge from the structure of ownership itself. The remainder of this paper explores an ownership-centric privacy model designed to preserve self-custody, maintain EVM compatibility, and provide practical privacy for both fungible and non-fungible assets.

1.2 Limitations of Existing Approaches

Existing EVM privacy systems generally fall into three categories:

  • Mixers (e.g. Tornado Cash)
  • Shielded pools (e.g. Railgun)
  • Stealth address systems (e.g. ERC-5564)

Each improves privacy, but they do so by operating primarily at the transaction layer.

Mixers and shielded pools attempt to hide relationships between deposits, transfers, and withdrawals through shared anonymity sets or zero-knowledge proofs.

Stealth address systems improve recipient privacy through one-time receiving addresses.

However, none directly address the underlying visibility of ownership within the EVM.

Persistent ownership remains observable.

Addresses accumulate:

  • Transaction history
  • Balance history
  • Relationship history
  • Behavioral history

As a result, privacy is typically achieved through specialized workflows rather than existing as the default ownership state.

Users must actively enter a privacy environment by:

  • Depositing into a mixer
  • Shielding assets into a privacy pool
  • Managing notes, commitments, or proofs
  • Funding stealth addresses for future spending
  • Consolidating fragmented balances
  • Exiting back into public ownership when assets are ultimately used

These workflows often introduce additional complexity, delays, operational overhead, and composability constraints.

They also create usability challenges.

Users may be required to:

  • Learn privacy-specific concepts and tooling
  • Manage additional wallets, notes, or keys
  • Understand anonymity set assumptions
  • Wait for privacy-preserving withdrawal windows
  • Coordinate gas funding for private accounts
  • Navigate workflows that differ from standard EVM usage

Consequently, privacy becomes an explicit action the user performs rather than a property of ownership itself.

Even when transaction relationships are obscured, ownership remains a long-lived observable object.

GhostShard begins from a different premise.

Rather than hiding relationships between known owners, GhostShard makes ownership itself disposable.

Ownership is fragmented into temporary units called shards.

Shards receive, hold, spend, and retire.

No ownership unit accumulates history indefinitely.

Privacy therefore emerges from ownership topology rather than transaction concealment.

The goal is not merely to improve privacy, but to make private ownership compatible with existing EVM assets, existing wallet models, and familiar user workflows.

The remainder of this paper develops this approach and describes how disposable ownership can be implemented on the post-Pectra EVM using ERC-5564, EIP-7702, sponsored execution, and atomic mesh transactions.

1.3 Design Goals

GhostShard is designed around eight core principles:

1. Privacy as a property of ownership. Privacy should emerge from ownership structure rather than transaction concealment. Assets should be private by default, not through explicit privacy actions. Users should not enter or exit privacy systems; ownership itself should be ambiguous.

2. Self-custodial privacy. Users retain full control of their assets. No trusted operators, custodial pools, delegated ownership, or trusted intermediaries are required.

3. Privacy beyond fungible assets. Privacy must extend to any ownership unit—including ERC-20 tokens, ERC-721 NFTs, and native assets—without requiring separate privacy systems for different asset classes.

4. Privacy as the default state. Privacy should not depend on user expertise, specialized operational knowledge, or explicit privacy workflows. Users should obtain privacy through normal ownership and transfer activity.

5. Compatibility with existing EVM infrastructure. The protocol should operate on existing EVM chains using existing wallets, existing assets, and existing developer tooling. No new chain, virtual machine, consensus mechanism, or execution environment should be required.

6. Composable privacy primitives. GhostShard is infrastructure rather than an application. Its contracts, SDK, services, relayers, and paymasters should be independently usable and composable with existing DeFi protocols and applications.

7. Economically sustainable privacy. Privacy should emerge from ordinary asset movement rather than requiring a separate privacy economy. Costs should remain comparable to normal transfers, with no percentage-based privacy fees, staking requirements, lockup periods, or participation incentives.

8. Compliant privacy without total anonymity. Privacy should support selective disclosure. Users must be able to prove specific ownership relationships or transactions to auditors, regulators, counterparties, or other authorized parties without exposing their complete financial history. Privacy does not imply opacity; it implies controlled cryptographic disclosure on the user's terms.

The Design Rationale chapter (Chapter 2) traces how these goals constrain and ultimately shape the architecture—from ownership topology to disposable ownership, shards, mesh transactions, recipient/change ambiguity, sponsored execution, and protocol infrastructure.