Skip to content

10. Security Analysis

Question: What can go wrong, and why does it not compromise the security of the system?

This chapter analyzes the security properties of GhostShard under realistic adversarial conditions.

The objective is not to argue that attacks are impossible, but to identify the classes of adversaries the protocol may encounter, define their capabilities, and evaluate whether those capabilities can compromise fund safety, authorization integrity, privacy guarantees, or protocol operation.

Security is examined across multiple layers of the system, including cryptographic assumptions, authorization mechanisms, paymaster sponsorship, relayer infrastructure, smart-contract execution, and SDK-level key management.

Core Principle

GhostShard follows a defense-in-depth security model.

No single participant, infrastructure provider, protocol component, or cryptographic primitive should be capable of unilaterally compromising user funds, authorization integrity, or ownership privacy.

Instead, security emerges from multiple independent protection layers:

  • Cryptographic authorization controls asset movement.
  • One-time-use shards limit ownership propagation.
  • Stealth-address construction protects recipient privacy.
  • Sponsorship controls protect paymaster resources.
  • Execution controls protect relayer infrastructure.
  • SDK safeguards protect key material and authorization workflows.

Consequently, the failure or compromise of a single component does not automatically imply compromise of the entire system.

The security analysis that follows evaluates whether this property holds against the adversaries defined in the threat model.

Scope of Analysis

This chapter evaluates the security of GhostShard across the major attack surfaces introduced throughout the protocol.

The analysis focuses on:

  • Threat modeling — defining security objectives, adversary classes, and trust assumptions.
  • Authorization security — preventing unauthorized spending, replay attacks, authorization misuse, and signature abuse.
  • Transaction-ordering attacks — analyzing front-running, bundle manipulation, transaction reordering, and authorization theft attempts.
  • Paymaster security — protecting sponsorship infrastructure from abuse, griefing, economic draining attacks, and unwanted sponsorship liabilities.
  • Relayer security — evaluating censorship risks, resource exhaustion attacks, simulation abuse, and operational trust assumptions.
  • Protocol abuse resistance — examining dust spam, meta-address spam, announcement flooding, and state-growth attacks.
  • Key-management security — analyzing root-seed protection, viewing-key compromise, spending-key compromise, device compromise, and recovery assumptions.
  • Smart-contract security — evaluating authorization validation, state consistency, execution safety, and contract-level attack surfaces.
  • Cryptographic security — reviewing the assumptions underlying ECDH, stealth-address construction, metadata encryption, and future post-quantum considerations.

Each section follows a common structure:

  1. Define the attack or adversarial objective.
  2. Explain why the attack is relevant.
  3. Analyze the protocol's exposure.
  4. Describe the mechanisms that mitigate or contain the threat.
  5. Identify any remaining assumptions or limitations.

Privacy-specific adversaries and ownership-inference attacks were analyzed separately in Chapter 8 and are referenced here only where they intersect with protocol security.

The goal of this chapter is therefore not merely to catalog threats, but to evaluate whether GhostShard maintains its core security properties when confronted with realistic adversarial behavior.

10.1 Threat Model

This section defines the security objectives, adversary classes, and threat assumptions used throughout the remainder of the security analysis.

The purpose of the threat model is to establish who the protocol is attempting to defend against, what capabilities those adversaries possess, and which classes of attacks are considered within scope for GhostShard v0.

Unless otherwise stated, all subsequent security claims are evaluated relative to the adversaries defined in this section.

10.1.1 Security Objectives

GhostShard v0 is designed to achieve the following security objectives.

Fund Safety

Only the legitimate owner of a shard can authorize its spending.

No relayer, paymaster, block builder, smart contract, or other infrastructure participant can unilaterally transfer user assets without possession of the required authorization keys.

Double-Spend Prevention

Each shard can be consumed exactly once.

GhostShard enforces this property through permanent on-chain spend tracking (isShardSpent) together with transient-storage deduplication that prevents duplicate consumption attempts within the same transaction execution context.

Sender Privacy

Observers should not be able to reliably link a user's externally owned account (EOA) to the shards they control or the transfers they initiate.

Recipient Privacy

Recipients should not be identifiable through publicly observable transaction data.

Stealth-address derivation and encrypted announcement metadata are designed to prevent recipient identification by passive observers.

Metadata Confidentiality

Sender-specific metadata should remain confidential to authorized participants.

Metadata confidentiality is provided through AES-256-GCM encryption using keys derived from transaction-specific ECDH shared secrets.

Authorization Integrity

Valid authorizations should be usable only for their intended purpose.

Authorizations are bound to specific actions, contracts, chains, and execution contexts, preventing cross-contract, cross-chain, and cross-transaction replay.

Censorship Resistance

Users should retain the ability to submit transactions even when individual relayers refuse service.

GhostShard therefore permits direct user submission and does not require reliance on any single relaying provider.

Infrastructure Safety

Protocol participants operating relayers or paymasters should be protected from protocol-level resource exhaustion and economic-draining attacks.

The protocol seeks to ensure that valid participation cannot be weaponized to force infrastructure providers into sustained economic loss.

10.1.2 Adversary Classes

GhostShard considers several classes of adversaries with different capabilities and objectives.

Passive Observer

A passive observer has access to all publicly available blockchain information, including:

  • Complete transaction history.
  • ERC-5564 announcements.
  • Authorization lists.
  • Shard creation events.
  • Shard consumption events.
  • Smart-contract state.

A passive observer cannot:

  • Forge signatures.
  • Modify transactions.
  • Access viewing keys.
  • Access spending keys.

This adversary class models blockchain analytics companies, researchers, and public observers attempting to reconstruct ownership relationships from observable data.

Active Protocol Participant

An active protocol participant operates within the GhostShard ecosystem as a relayer, paymaster, RPC provider, or similar infrastructure service.

Such an adversary may observe:

  • Transaction submission timing.
  • Sponsorship requests.
  • Bundle contents.
  • Network metadata.
  • User information collected during onboarding.

The participant may act maliciously within the permissions of its role, including:

  • Logging user activity.
  • Refusing service.
  • Attempting censorship.
  • Performing transaction-ordering attacks.

However, the participant cannot forge valid authorizations or modify signed transaction contents without invalidating the associated signatures.

Counterparty Adversary

A counterparty adversary participates directly in economic activity with the target user.

The adversary may possess:

  • Knowledge of transfers sent.
  • Knowledge of transfers received.
  • Expected payment schedules.
  • Commercial relationships.
  • Off-chain contextual information.

Because of repeated interaction, counterparties may accumulate substantially more information than passive observers.

However, counterparties do not automatically obtain:

  • Viewing-key access.
  • Ownership discovery capabilities.
  • Visibility into unrelated transactions.
  • Visibility into unrelated counterparties.

Infrastructure Adversary

An infrastructure adversary controls network-level services such as:

  • RPC endpoints.
  • Mempool access.
  • Transaction-routing systems.
  • Builder relationships.

Such an adversary may attempt:

  • Timing analysis.
  • Transaction correlation.
  • Network-level attribution.
  • Observation of unconfirmed transaction activity.

GhostShard assumes these adversaries may possess significant observational capabilities but cannot break the underlying cryptographic primitives.

Economic Adversary

An economic adversary seeks financial advantage by exploiting protocol incentives or imposing costs on other participants.

Potential objectives include:

  • Draining paymaster deposits.
  • Bleeding relayer resources.
  • Triggering excessive computation.
  • Creating denial-of-service conditions.
  • Exploiting protocol economics.
  • Griefing users or infrastructure providers.

Unlike purely external attackers, economic adversaries may possess fully valid protocol credentials and may submit valid transactions if doing so creates costs for others.

Cryptographic Adversary

A cryptographic adversary attempts to violate the security assumptions underlying the protocol.

Potential objectives include:

  • Recovering private keys from public information.
  • Forging signatures.
  • Decrypting metadata without authorization.
  • Linking stealth addresses to identities.
  • Breaking authorization schemes.

GhostShard assumes the security of:

  • secp256k1 discrete logarithms.
  • Elliptic-Curve Diffie-Hellman (ECDH).
  • HKDF-SHA256.
  • AES-256-GCM.

The protocol's security guarantees are contingent upon the continued security of these primitives.

10.1.3 Out-of-Scope Threats

The following threats are considered outside the scope of GhostShard v0 protocol-level protections.

Endpoint Compromise

GhostShard does not protect users whose devices are compromised.

Examples include:

  • Malware.
  • Keyloggers.
  • Remote-access trojans.
  • Root-seed theft.
  • Memory extraction attacks.

Social Engineering

The protocol cannot prevent users from voluntarily authorizing malicious actions.

Examples include:

  • Phishing attacks.
  • Fraudulent signing requests.
  • Impersonation attacks.
  • User deception outside protocol controls.

Physical Attacks

GhostShard does not address:

  • Device theft.
  • Coercion.
  • Hardware tampering.
  • Physical extraction of secrets.

Global Network Surveillance

Nation-state or ISP-level surveillance capable of monitoring large portions of internet traffic is considered outside the scope of v0 protections.

Large-Scale Quantum Adversaries

GhostShard v0 does not claim resistance against fault-tolerant quantum computers capable of executing:

  • Shor's algorithm against secp256k1.
  • Large-scale quantum attacks against current public-key cryptography.

Malicious Wallet Interfaces

GhostShard assumes that wallets present signing information honestly.

A wallet intentionally displaying incorrect transaction information to a user is considered outside protocol scope.

Threats in these categories require operational security measures, trusted hardware, user education, future cryptographic upgrades, or wallet-level protections rather than protocol-level modifications.

10.2 Authorization Security

Question: Can an attacker spend assets they do not control?

Under the security assumptions defined in Section 10.1, the answer is no.

GhostShard's authorization architecture is designed such that asset movement requires possession of the private key corresponding to the shard being spent. Neither relayers, paymasters, builders, routers, nor other infrastructure participants can authorize transfers on behalf of a shard owner.

This section analyzes the mechanisms that enforce authorization ownership, prevent replay attacks, constrain authorization scope, and resist signature misuse.

10.2.1 Authorization Ownership

Every transfer command must be authorized by the private key corresponding to the shard being consumed.

Let

\[ H = \operatorname{Keccak256} \left( \operatorname{abi.encode} ( chainId, routerAddress, shardAddress, assetType, token, to, value, announcements ) \right) \]

The transfer authorization is then:

\[ \sigma = \operatorname{EIP191Sign}(H, shardPrivateKey) \]

On-chain verification recovers the signer from the EIP-191 signature and requires it to match the shard being spent:

\[ [ \operatorname{Recover} \Big( \operatorname{EthSignedMessageHash}(H), \sigma \Big)= S ] \]

where:

  • \((H)\) is the transfer-command hash.
  • \((\sigma)\) is the EIP-191 signature.
  • \((S)\) is the shard address being consumed.

Only the holder of the private key corresponding to \((\S)\) can produce a signature that satisfies this equality.

The authorization flow is therefore:

flowchart LR

    K[Shard Private Key]
    --> S[Generate Transfer Authorization]

    S --> SIG[Signature]

    SIG --> V[Contract Verification]

    V --> OK[Authorized]

Only the holder of shardPrivateKey can produce a signature that recovers to cmd.shard.

Neither the relayer, paymaster, router, nor block builder possesses this key.

Consequently, an attacker cannot authorize asset movement without compromising the shard's private key itself.

This property ultimately relies on the unforgeability of ECDSA signatures over secp256k1.

10.2.2 Replay Resistance

GhostShard employs multiple independent replay-prevention mechanisms.

Permanent Replay Prevention

Each shard functions as a one-time-use ownership object.:

After successful execution, the shard is permanently marked as spent:

\[ \texttt{isShardSpent}[s] \leftarrow \texttt{true} \]

where (s) denotes the shard being consumed.

Any subsequent attempt to consume the same shard causes execution to revert:

\[ \texttt{isShardSpent}[s] = \texttt{true} ;\Longrightarrow; \texttt{revert}(\texttt{ShardAlreadySpent}) \]

The shard can therefore be spent at most once.

flowchart LR

    A[Shard]
    --> B[Spend]

    B --> C[Marked Spent]

    C --> D[Reuse Attempt]

    D --> E[Revert]

Authorization Replay Prevention

Replay protection also exists at the EIP-7702 layer.

Each authorization:

  • Ghost Shard v0 Uses nonce 0.
  • Delegates to a specific implementation contract.
  • Is bound to a specific chain.

Consequently, an authorization cannot be:

  • Replayed on another chain.
  • Replayed against another contract.
  • Reused after shard consumption.

Authorization validity therefore terminates with the lifecycle of the shard itself.

10.2.3 Authorization Scope Binding

A valid authorization permits exactly one action.

The signed transfer hash commits to:

  • chainId
  • routerAddress
  • shardAddress
  • assetType
  • token
  • to
  • value
  • announcements

Any modification produces a different hash: $$ [ H' \neq H ] $$

which invalidates the corresponding signature.

As a result, an attacker cannot:

  • Substitute recipients.
  • Modify transfer amounts.
  • Replace assets.
  • Alter announcement sets.
  • Redirect outputs.
  • Execute the authorization against another contract.
flowchart LR

    H[Signed Transfer Hash]

    H --> A[Recipient]
    H --> B[Amount]
    H --> C[Asset]
    H --> D[Announcements]

    X[Modify Any Field]
    --> F[Hash Changes]

    F --> R[Signature Invalid]

The authorization remains cryptographically bound to the exact transfer intended by the signer.

10.2.4 Cross-Transaction Reuse Attacks

An attacker observing a valid transfer command may attempt to reuse it in a separate transaction.

Such attacks fail for three independent reasons.

Shard Consumption

The shard has already been marked spent:

\[ [ isShardSpent[s] = true ] \]

Execution therefore reverts immediately.

Authorization Consumption

The corresponding EIP-7702 delegation is tied to a one-time-use shard lifecycle.

Once the shard is consumed, the authorization has no remaining utility.

Bundle Binding

Paymaster sponsorship commits to the specific bundle being sponsored.

Commands extracted from one bundle cannot be inserted into another without invalidating sponsorship approval.

Consequently, observing a valid transaction does not yield reusable authorization material.

10.2.5 Signature Phishing Resistance

GhostShard deliberately separates authorization responsibilities across multiple cryptographic domains.

Scheme Type Signed By Purpose
EIP-7702 Authorization Type 0x05 Shard Key Delegation
EIP-191 Transfer Command Personal Message Shard Key Asset Transfer
EIP-191 User Bundle Personal Message User EOA Sponsorship Approval

Each scheme uses a distinct encoding format and execution context.

Cross-Scheme Separation

EIP-7702 authorizations:

  • Use transaction type 0x05.
  • Use RLP encoding.
  • Authorize delegation.

EIP-191 signatures:

  • Use the Ethereum signed-message domain.
  • Authorize application-specific actions.

Therefore:

  • An EIP-191 signature cannot be interpreted as an EIP-7702 authorization.
  • An EIP-7702 authorization cannot be interpreted as a transfer command.
  • A transfer command cannot be interpreted as a sponsorship approval.

Cryptographic domain separation prevents cross-scheme replay and signature confusion attacks.

Key Separation

GhostShard further separates authorization authority across distinct key classes.

flowchart LR

    RK[Root Seed]

    RK --> SK[Shard Keys]
    RK --> VK[Viewing Keys]
    RK --> UK[User EOA]

    SK --> TC[Transfer Commands]

    UK --> PB[Paymaster Approval]

Transfer commands are signed by shard keys.

Paymaster approvals are signed by the user's EOA.

Compromise of one authorization context does not automatically compromise another.

Wallet-Level Phishing

GhostShard's cryptographic protections do not eliminate UI-level deception.

A malicious website may attempt to misrepresent transaction details and induce a user to sign a valid authorization.

Users should therefore verify:

  • Router address.
  • Chain identifier.
  • Recipient information.
  • Sponsorship details.

before signing.

Such attacks target wallet interfaces rather than the protocol itself and are discussed further in Section 10.7.

10.2.6 Authorization Visibility

EIP-7702 authorizations are publicly visible within transaction authorization lists.

Observers can therefore determine:

  • Which shards participated in execution.
  • Which shards delegated execution authority.

However, visibility does not imply control.

An observer who sees an authorization still lacks:

  • The shard private key.
  • A valid transfer-command signature.
  • The ability to generate new authorizations.

Authorization visibility therefore creates no direct spending vulnerability.

At most, it reveals participation of a shard in a transaction, a privacy consideration discussed separately in Chapter 8.

10.3 Front-Running and Transaction Ordering

Question: Can transaction ordering compromise the security of GhostShard?

Transaction-ordering attacks are a common source of value extraction in public blockchain systems. In conventional account-based transactions, an adversary may observe a pending transaction, copy its parameters, and submit a competing transaction with a higher fee in an attempt to capture value or alter execution outcomes.

GhostShard's authorization architecture significantly limits the effectiveness of such attacks because transaction execution depends on ownership-bound signatures and one-time-use shards rather than publicly observable transaction intent alone.

This section analyzes front-running, authorization theft, bundle manipulation, mempool observation, and transaction reordering.

10.3.1 Front-Running Resistance

A front-running attack typically follows a simple pattern:

flowchart LR

    U[User Transaction]
    --> M[Mempool]

    A[Attacker]
    --> M

    M --> F[Front-Run Transaction]

    F --> B[Block Inclusion]

The attacker observes a pending transaction, copies its parameters, modifies the fee, and attempts to execute first.

This strategy is ineffective against GhostShard.

A mesh transaction spends specific shards that are controlled by specific private keys.

Even if an attacker observes every transaction parameter, they still cannot:

  • Produce valid shard signatures.
  • Modify transfer destinations.
  • Alter announcement outputs.
  • Substitute recipients.
  • Redirect funds.

The attacker may copy the transaction, but they cannot produce the required authorizations.

Ownership remains the controlling factor rather than transaction ordering.

10.3.2 Authorization Theft Resistance

GhostShard separates delegation authority from spending authority.

An observed EIP-7702 authorization does not grant control over assets.

The authorization only delegates execution authority to the GhostShard implementation contract.

Actual asset movement requires a separate transfer command signed by the shard owner.

The authorization flow is:

flowchart LR

    K[Shard Private Key]
    --> A[EIP-7702 Authorization]

    K --> T[EIP-191 Transfer Command]

    A --> E[Execution]

    T --> E

    E --> S[Shard Spend]

Successful execution requires both components.

An attacker who observes an authorization still lacks:

  • The shard private key.
  • The transfer-command signature.
  • The ability to create valid spending instructions.

Furthermore, because shards are single-use objects, even a copied authorization becomes useless once the shard has been consumed.

Authorization visibility therefore does not translate into authorization theft.

10.3.3 Mempool Observation

Relayers, builders, searchers, and other infrastructure participants may observe pending mesh transactions before inclusion.

Such observers may learn:

  • Bundle contents.
  • Announcement structures.
  • Sponsorship information.
  • Gas parameters.
  • Transaction timing.

However, observation alone does not provide spending capability.

The observer cannot:

  • Forge shard signatures.
  • Modify transfer commands.
  • Redirect assets.
  • Create new valid announcements.
  • Recover viewing keys.

The information exposed through mempool visibility is therefore operational rather than authorization-related.

This distinction is important:

Observing a transaction is not equivalent to controlling a transaction.

GhostShard assumes mempool visibility is possible and remains secure under that assumption.

10.3.4 Bundle Manipulation Resistance

A malicious relayer may attempt to alter a transaction bundle before broadcasting it.

Potential modifications include:

  • Adding commands.
  • Removing commands.
  • Reordering commands.
  • Replacing announcements.
  • Modifying outputs.

GhostShard prevents such manipulation through bundle binding.

The sponsorship approval commits to the exact command set and announcement set.

Conceptually:

\[ B = H(\text{commands}) || H(\text{announcements}) \]

where:

  • (H(\text{commands})) is the hash of the command array.
  • (H(\text{announcements})) is the hash of the announcement array.

The paymaster signature is generated over these values.

Any modification changes the committed bundle hash and invalidates sponsorship approval.

flowchart LR

    O[Original Bundle]
    --> H[Bundle Hash]

    H --> P[Paymaster Signature]

    M[Modified Bundle]
    --> H2[Different Hash]

    H2 --> X[Signature Invalid]

As a result, a relayer cannot successfully alter transaction contents without causing execution to fail.

10.3.5 Transaction Reordering

A block producer may reorder transactions before inclusion.

This capability is unavoidable on public blockchains.

The relevant question is whether reordering creates a security vulnerability.

For GhostShard, the answer is generally no.

Within a mesh transaction:

  • Commands are executed atomically.
  • Authorization validity is independent of ordering.
  • Each shard is consumed at most once.
  • Partial execution is impossible.

The execution model is:

flowchart LR

    A[Command 1]
    --> B[Command 2]

    B --> C[Command N]

    C --> D[Commit]

    X[Failure]
    --> R[Full Revert]

Either:

  • Every command succeeds, or
  • The entire transaction reverts.

There is no intermediate state in which an attacker can insert a competing operation between commands.

Consequently, transaction ordering does not create a path to unauthorized asset movement.

10.3.6 MEV Considerations

Although front-running does not compromise ownership security, infrastructure participants may still attempt to extract value through transaction observation.

Examples include:

  • Transaction censorship.
  • Delayed inclusion.
  • Selective bundle forwarding.
  • Priority manipulation.

These attacks affect transaction execution quality rather than authorization correctness.

Users may reduce exposure through:

  • Private RPC infrastructure.
  • Self-relaying.
  • Multiple relayer options.
  • Alternative sponsorship providers.

Because no single relayer is required for protocol operation, users retain the ability to route transactions through alternative infrastructure when necessary.

10.4 Paymaster Security

Question: Can users abuse, drain, or otherwise compromise sponsorship infrastructure?

This section analyzes the trust assumptions, attack surfaces, and economic security properties of the GhostShard paymaster model.

The primary objective is to ensure that sponsorship infrastructure can participate in transaction execution without gaining authority over user assets, while simultaneously preventing users from imposing unbounded costs on sponsoring entities.

10.4.1 Security Model

The paymaster occupies a unique position within the GhostShard architecture.

It participates in transaction execution by providing gas sponsorship, but it does not participate in asset ownership, authorization generation, or shard control.

flowchart LR

    U[User]
    --> P[Paymaster]

    P --> R[Relayer]

    R --> C[GhostShard Router]

    C --> A[Assets]

    P -. Sponsors Gas .-> C

    P -. No Asset Control .-> A

This separation creates an important security boundary:

  • Sponsorship authority is distinct from spending authority.
  • Sponsorship approval does not grant asset access.
  • Sponsorship approval does not grant transfer authority.
  • Sponsorship compromise cannot directly result in asset theft.

As a result, the paymaster may influence transaction execution but cannot independently move user funds.

10.4.2 Trust Assumptions

GhostShard assumes that a paymaster:

  • Validates sponsorship requests before approval.
  • Simulates execution before accepting economic exposure.
  • Maintains sufficient deposits to cover sponsored transactions.
  • Enforces its own sponsorship policies.

GhostShard does not assume that a paymaster is honest, benevolent, censorship-resistant, or continuously available.

A malicious paymaster may:

  • Refuse sponsorship.
  • Log user activity.
  • Enforce restrictive policies.
  • Attempt to correlate transactions.

However, the paymaster is intentionally excluded from critical security functions.

Fund Safety

Asset transfers remain exclusively controlled by shard owners.

The paymaster cannot:

  • Spend user assets.
  • Create transfer commands.
  • Modify transfer recipients.
  • Redirect outputs.
  • Authorize transfers.

Even a fully compromised paymaster cannot move assets without valid shard signatures.

Authorization Integrity

The paymaster does not possess:

  • Shard private keys.
  • Viewing keys.
  • Transfer-authority credentials.

Consequently, sponsorship authority and spending authority remain cryptographically independent.

flowchart LR

    P[Paymaster]

    P -. No Access .-> SK[Shard Keys]
    P -. No Access .-> VK[Viewing Keys]

    SK --> T[Transfer Authorization]

    P --> S[Gas Sponsorship]

10.4.3 Sponsorship Scope Binding

A sponsorship approval is valid only for a specific transaction bundle.

Conceptually, the paymaster signs:

\[ H( \text{commands}, \text{announcements}, \text{limits}, \text{chain}, \text{router}, \text{expiry} ) \]

The approval therefore commits to:

  • The command set.
  • The announcement set.
  • Gas limits.
  • Chain identifier.
  • Router address.
  • Expiration time.
flowchart LR

    B[Transaction Bundle]
    --> H[Bundle Hash]

    H --> S[Paymaster Signature]

    M[Modified Bundle]
    --> H2[Different Hash]

    H2 --> X[Signature Invalid]

As a result:

  • A sponsorship approval cannot be reused for another transaction.
  • A sponsorship approval cannot be moved to another chain.
  • A sponsorship approval cannot survive expiration.
  • A sponsorship approval cannot be modified after signing.

Bundle-substitution attacks therefore fail automatically.

10.4.4 Economic Abuse and Bleeding Attacks

The primary threat against a paymaster is economic rather than cryptographic.

An attacker may attempt to:

  • Consume sponsorship deposits.
  • Waste simulation resources.
  • Increase operating costs.
  • Trigger denial-of-service conditions.
  • Force the paymaster into unfavorable sponsorship decisions.

GhostShard is designed so that these attacks remain bounded.

Expensive Transaction Requests

An attacker may repeatedly submit large or computationally expensive sponsorship requests.

GhostShard mitigates this through pre-sponsorship validation.

The paymaster evaluates a request before signing and remains free to reject any transaction that exceeds acceptable limits.

Examples include:

  • Excessive gas requirements.
  • Large command sets.
  • Unacceptable sponsorship exposure.
  • Policy violations.

The paymaster therefore controls its own exposure.

Simulation Abuse

A malicious user may attempt to obtain sponsorship for transactions that ultimately fail.

GhostShard assumes sponsorship occurs only after simulation.

flowchart LR

    T[Transaction Request]
    --> S[Simulation]

    S -->|Pass| A[Sponsorship]

    S -->|Fail| R[Reject]

Transactions that fail validation or violate policy constraints never receive sponsorship approval.

The protocol imposes no obligation on a paymaster to sponsor any request.

Gas Exposure Control

Maximum exposure is bounded before execution begins.

Conceptually:

\[ \text{Maximum Exposure}= \text{Maximum Gas} \times \text{Gas Price} \]

Execution reserves sufficient funds to cover the worst-case scenario permitted by sponsorship policy.

Consequently:

  • Exposure is known before execution.
  • Exposure is bounded.
  • Exposure cannot exceed approved limits.

A user therefore cannot create unlimited gas liability for a paymaster.

10.4.5 User Protection Against Paymaster Abuse

The trust relationship is intentionally asymmetric.

Users should not be able to abuse paymasters, but paymasters should not be able to control users.

Sponsorship Refusal

A paymaster may refuse sponsorship for any reason.

However, users are not dependent on a particular paymaster.

Alternative sponsorship providers may be used, including self-funded execution.

A refusal therefore affects only a specific sponsorship request and does not prevent protocol usage.

Sponsorship Quote Independence

In GhostShard v0, sponsorship approval is represented as a signed sponsorship quote.

The approval remains cryptographically independent from transaction execution.

The GhostShard SDK may:

  • Request quotes from multiple paymasters.
  • Compare sponsorship terms.
  • Discard previously received quotes.
  • Request replacement quotes.
  • Fall back to self-funded execution.
flowchart LR

    U[User]

    U --> P1[Paymaster A]
    U --> P2[Paymaster B]

    P1 --> Q1[Quote A]
    P2 --> Q2[Quote B]

    Q1 --> SDK[GhostShard SDK]
    Q2 --> SDK

    SDK --> S[Selected Quote]

    SDK -. Discard .-> X[Unused Quote]

Importantly, receipt of a sponsorship quote does not obligate the user to use it.

Quote selection remains entirely under user control.

v0 Sponsorship Architecture

In the current GhostShard v0 architecture, a verifying paymaster may directly submit the sponsored transaction after approval.

Consequently, quote independence is primarily an SDK-level workflow property rather than an onchain requirement.

A user may:

  • Execute through the sponsoring paymaster.
  • Use an alternative execution path.
  • Request sponsorship elsewhere.

Future ERC-20 paymaster architectures introduce a stronger form of quote independence.

In those systems:

  1. The paymaster returns a signed sponsorship quote.
  2. The user selects which shard pays gas fees.
  3. The user signs the gas-payment authorization.
  4. The quote becomes part of the execution bundle.

Under that model, the paymaster cannot finalize execution independently because the user must explicitly choose the gas-paying shard.

GhostShard v0 does not require this flow, but the architecture remains compatible with it.

Sponsorship Policy Control

Each paymaster defines its own sponsorship policies.

Examples include:

  • User allowlists.
  • KYC requirements.
  • Transaction-size limits.
  • Spending limits.
  • Geographic restrictions.
  • Risk-scoring systems.

GhostShard does not impose a universal sponsorship policy.

Instead, sponsorship decisions remain local to the paymaster.

Users remain free to choose providers whose policies best match their requirements.

Expiration Controls

Every sponsorship approval contains an expiration window.

After expiration,

\[ t > t_{\text{validUntil}} \]

the sponsorship becomes invalid.

This prevents indefinite reuse of previously approved sponsorships and limits long-term exposure for both users and paymasters.

Expiration also ensures that discarded sponsorship quotes naturally become unusable after their validity period ends.

10.4.6 Denial-of-Service Considerations

Paymasters remain exposed to conventional infrastructure-level denial-of-service attacks.

Examples include:

  • Excessive sponsorship requests.
  • Repeated simulation requests.
  • API flooding.
  • Network abuse.
  • Automated probing.

These attacks target infrastructure resources rather than protocol security.

Typical mitigations include:

  • Rate limiting.
  • Authentication.
  • Reputation systems.
  • Request pricing.
  • Operational monitoring.

Such protections are operational concerns rather than protocol-level mechanisms.

10.4.7 Future Sponsorship Models

GhostShard v0 adopts a single-paymaster sponsorship architecture.

Future versions may explore more decentralized alternatives, including:

  • Threshold-signed sponsorship.
  • Multi-paymaster approval systems.
  • Sponsorship marketplaces.
  • Shared sponsorship pools.
  • Reputation-based sponsorship networks.
  • ERC-20 settlement paymasters.

These designs may reduce trust concentration and improve infrastructure resilience, but they are not required for the security of GhostShard v0.

10.4.8 Security Conclusion

The GhostShard paymaster model intentionally separates sponsorship authority from asset ownership.

A paymaster may decide whether a transaction is sponsored, but it cannot:

  • Spend user assets.
  • Forge transfer authorizations.
  • Redirect funds.
  • Modify valid transaction bundles.

At the same time, sponsorship exposure remains bounded through simulation, policy enforcement, expiration controls, and bundle-specific approvals.

As a result, paymaster compromise primarily affects sponsorship availability and infrastructure trust rather than fund safety or authorization integrity.

10.5 Relayer Security

Question: Can relayers be exploited, censored, or forced to operate at a loss?

Relayers serve as transaction broadcast infrastructure within GhostShard. They receive transaction bundles, validate them, and submit them to the network.

Unlike routers, relayers do not participate in authorization generation or asset ownership. Their role is operational rather than custodial.

This section analyzes the trust assumptions, attack surfaces, economic risks, and censorship considerations associated with relayer operation.

10.5.1 Security Model

Relayers occupy an infrastructure role between users and the blockchain.

flowchart LR

    U[User]
    --> R[Relayer]

    R --> N[Network]

    N --> C[GhostShard Router]

    C --> A[Assets]

    R -. Broadcast Only .-> C

    R -. No Asset Control .-> A

The relayer may observe transaction bundles and choose whether to broadcast them, but it cannot independently authorize asset movement.

This creates a strict separation between:

  • Broadcast authority.
  • Spending authority.

As a result, relayer compromise cannot directly result in asset theft.

10.5.2 Trust Assumptions

GhostShard assumes that relayers:

  • Broadcast transactions they choose to accept.
  • Maintain accurate local accounting.
  • Perform validation before submission.
  • Simulate execution before accepting economic exposure.

GhostShard does not assume that relayers are honest, censorship-resistant, or continuously available.

A relayer may:

  • Refuse service.
  • Delay submission.
  • Log transaction data.
  • Prioritize certain users.
  • Censor transactions.

However, the relayer is intentionally excluded from critical authorization paths.

Fund Safety

A relayer cannot:

  • Create transfer commands.
  • Forge shard signatures.
  • Redirect outputs.
  • Modify recipients.
  • Spend user assets.

Every transfer remains authorized by shard-owner signatures.

Even a malicious relayer lacks the credentials required to create valid spending authorizations.

Privacy Limitations

Relayers observe the full transaction bundle they broadcast.

Depending on architecture, they may see:

  • Commands.
  • Announcements.
  • Gas parameters.
  • Sponsorship information.
  • Submission timing.

However, relayers do not possess:

  • Viewing keys.
  • Shard private keys.
  • Ownership discovery capabilities.

Consequently, observing a bundle does not automatically reveal sender-recipient relationships.

Privacy implications were analyzed separately in Chapter 8.

10.5.3 Authorization Front-Running and Relayer Bleeding

The primary relayer-specific threat in GhostShard is not unauthorized spending but authorization griefing.

A malicious user may attempt to cause a relayer to pay gas for a transaction that was valid during simulation but becomes invalid before inclusion.

The attack proceeds as follows:

flowchart LR

    U[User]

    U --> B[Valid Bundle]

    B --> S[Relayer Simulation]

    S --> P[Simulation Pass]

    P --> M[Pending Broadcast]

    U --> F[User Front-Runs Bundle]

    F --> C[Shard Consumed]

    M --> X[Relayer Transaction]

    X --> R[Revert]

The user:

  1. Constructs a valid transaction bundle.
  2. Obtains sponsorship approval.
  3. Submits the bundle to a relayer.
  4. Allows the relayer to simulate successfully.
  5. Independently broadcasts the same authorization before the relayer transaction is included.

Because the shard is consumed by the user's transaction first,

\[ \texttt{isShardSpent[shard]} = \texttt{true} \]

when the relayer transaction executes.

The relayer transaction therefore reverts despite having passed simulation.

In this scenario:

  • The user does not lose funds.
  • No unauthorized spending occurs.
  • The protocol remains secure.
  • The relayer may incur transaction costs.

This is a griefing attack rather than a theft attack.

Why the Attack Does Not Compromise Fund Safety

The attacker gains no ability to:

  • Spend another user's assets.
  • Modify transaction contents.
  • Forge signatures.
  • Bypass authorization checks.

The only effect is the potential creation of relayer costs.

Consequently, the attack impacts relayer economics rather than protocol security.

Mitigations

GhostShard reduces the practical impact of authorization griefing through several mechanisms.

Relayer policy controls

Relayers may:

  • Restrict service to known users.
  • Require deposits.
  • Maintain reputation systems.
  • Rate-limit repeated offenders.

Economic filtering

Repeated griefing creates a detectable behavioral pattern.

Relayers can blacklist users that repeatedly submit bundles that become invalid shortly after simulation.

Private submission paths

A relayer may submit transactions through private infrastructure rather than the public mempool, reducing the opportunity for the originating user to race the relayer's transaction.

Future protocol improvements

Future versions may introduce:

  • Relayer deposits.
  • Submission commitments.
  • Anti-griefing bonds.
  • Inclusion commitments.
  • Relay reputation networks.

These mechanisms can further reduce economic exposure without changing authorization security.

10.5.4 Simulation and Validation

Relayers perform local validation before broadcast.

flowchart LR

    B[Bundle]
    --> V[Validation]

    V --> S[Simulation]

    S -->|Pass| T[Broadcast]

    S -->|Fail| R[Reject]

This protects relayers from:

  • Invalid signatures.
  • Malformed bundles.
  • Invalid sponsorship approvals.
  • Predictable execution failures.

Simulation cannot eliminate authorization-front-running griefing because the bundle is genuinely valid at simulation time.

However, it prevents relayers from wasting gas on transactions that are already invalid before submission.

10.5.5 Bundle Manipulation Resistance

A malicious relayer may attempt to alter a transaction before submission.

Examples include:

  • Removing commands.
  • Reordering commands.
  • Replacing announcements.
  • Injecting additional operations.

These attacks fail because transaction validity depends on cryptographic commitments.

The bundle is protected by:

  • Shard-owner signatures.
  • Sponsorship signatures.
  • Authorization validation.
flowchart LR

    O[Original Bundle]
    --> H[Signed Hash]

    M[Modified Bundle]
    --> H2[Different Hash]

    H2 --> X[Verification Failure]

Any modification changes the committed transaction hash and invalidates the associated approvals.

Consequently, relayers can choose whether to broadcast a bundle, but cannot safely modify it.

10.5.6 Censorship Risks

The relayer's most significant power is the ability to refuse service.

A relayer may:

  • Ignore requests.
  • Delay broadcasting.
  • Prioritize specific users.
  • Selectively censor transactions.

This does not compromise fund safety but may affect transaction availability.

flowchart LR

    U[User]
    --> R1[Relayer A]

    R1 -->|Refuses| X[Censored]

    U --> R2[Relayer B]

    R2 --> N[Network]

GhostShard mitigates censorship through optionality rather than protocol enforcement.

Users may:

  • Submit through alternative relayers.
  • Operate private relayers.
  • Broadcast directly.
  • Use self-funded execution.

As long as at least one submission path remains available, censorship by a single relayer cannot permanently block protocol usage.

10.5.7 Relayer Decentralization Assumptions

GhostShard v0 does not require a decentralized relayer network.

Instead, it assumes that users have access to at least one functioning submission path.

The protocol therefore tolerates:

  • Relayer failures.
  • Relayer churn.
  • Relayer replacement.
  • Partial relayer censorship.

Future versions may explore:

  • Decentralized relay networks.
  • Shared broadcast infrastructure.
  • Reputation systems.
  • Relay marketplaces.

However, these are improvements to availability rather than requirements for security.

10.5.8 Security Conclusion

Relayers occupy an operational role rather than a custodial one.

A relayer may:

  • Observe bundles.
  • Refuse service.
  • Delay submission.
  • Consume infrastructure resources.

A relayer cannot:

  • Spend assets.
  • Forge authorizations.
  • Modify valid transactions.
  • Redirect transfers.

The primary risks are therefore economic and availability-related rather than authorization-related.

Under the GhostShard security model, relayer compromise may affect transaction delivery but does not compromise fund safety or authorization integrity.

10.6 Shard Abuse and Spam Resistance

Question: Can protocol state, wallet state, or discovery infrastructure be polluted or weaponized?

GhostShard introduces new protocol objects, including shards, announcements, and ownership-discovery mechanisms. As with any public system, an adversary may attempt to exploit these structures to increase costs, degrade usability, or create operational burdens for users and infrastructure providers.

This section analyzes the primary spam and state-growth vectors within the GhostShard architecture.

10.6.1 Dust Shard Attacks

A dust attack attempts to create large numbers of economically insignificant shards owned by a victim.

An attacker may repeatedly send very small amounts of ETH or tokens to stealth addresses associated with a target user.

flowchart LR

    A[Attacker]
    --> D1[Dust Shard]

    A --> D2[Dust Shard]

    A --> D3[Dust Shard]

    D1 --> U[Victim Wallet]
    D2 --> U
    D3 --> U

The objective is not theft but state pollution.

Potential consequences include:

  • Increased wallet reconstruction work.
  • Larger shard inventories.
  • More ownership records to manage.
  • Additional scanning and indexing overhead.

Importantly, dust shards remain owned by the recipient.

The attacker cannot reclaim or spend them after creation.

Consequently, dust attacks do not compromise:

  • Fund safety.
  • Authorization integrity.
  • Ownership privacy.

The primary impact is operational rather than security-related.

Mitigations

GhostShard naturally limits the effectiveness of dust attacks.

Wallet policies

Wallet implementations may:

  • Ignore shards below configurable thresholds.
  • Hide economically insignificant balances.
  • Aggregate low-value shards during spending.

10.6.2 Meta-Address Spam

An attacker may target a specific meta-address by generating large numbers of valid ERC-5564 announcements.

Unlike dust attacks, the attacker is not attempting to transfer value.

Instead, the goal is to increase ownership-discovery workload.

flowchart LR

    A[Attacker]
    --> N[Large Announcement Set]

    N --> M[Victim Meta-Address]

    M --> W[Wallet Discovery Process]

Potential consequences include:

  • Increased announcement scanning.
  • Larger discovery indexes.
  • Increased synchronization costs.

However, the attacker gains no ownership visibility and cannot force decryption of unrelated announcements.

Mitigations

GhostShard's discovery architecture is specifically designed to reduce announcement-processing costs.

Batch processing

SDk may:

  • Process announcements incrementally.
  • Cache discovery results.
  • Parallelize verification.

10.6.3 Announcement Flooding

Announcement flooding targets the broader network rather than a specific recipient.

An attacker may generate large numbers of transactions containing announcements in an attempt to increase:

  • Event volume.
  • Indexing costs.
  • Blockchain log growth.
flowchart LR

    A[Attacker]
    --> T[Transactions]

    T --> E[Announcement Events]

    E --> N[Network Indexers]

Unlike meta-address spam, announcement flooding affects ecosystem infrastructure rather than individual users.

Security Impact

Announcement flooding does not compromise:

  • Fund safety.
  • Authorization integrity.
  • Recipient privacy.
  • Sender privacy.

Announcements are emitted only as part of valid protocol execution.

An attacker must therefore pay the normal economic costs associated with transaction creation.

The attack increases operational load but does not create a protocol-level security failure.

10.6.4 State Growth

GhostShard maintains a small amount of permanent protocol state.

The most significant source of long-term growth is spent-shard tracking.

Spent-Shard Tracking

Each consumed shard creates a permanent entry:

\[ \texttt{isShardSpent[shard]}=\texttt{true} \]

This mapping grows monotonically over time.

flowchart LR

    S1[Spent Shard]
    --> M[isShardSpent]

    S2[Spent Shard]
    --> M

    S3[Spent Shard]
    --> M

    M --> G[Growing State]

Growth characteristics:

  • One entry per spent shard.
  • Written only during spending.
  • Never written during shard creation.
  • Constant-time lookup.

Because shard creation occurs off-chain through stealth-address derivation, state growth scales with spending activity rather than ownership creation.

Paymaster State

Paymaster storage grows with the number of participating paymasters.

This includes:

\[ \texttt{paymasterDeposits} \]

and related accounting structures.

Growth is expected to remain relatively small because the number of paymasters is substantially smaller than the number of users.

10.6.5 State Growth Limitations

GhostShard v0 does not implement spent-shard pruning.

Consequently:

  • State growth is permanent.
  • Historical spent-shard records remain accessible.
  • Storage requirements increase over time.

This is a deliberate design choice that prioritizes simplicity and replay resistance.

Future versions may explore:

  • State-pruning mechanisms.
  • UTXO commitment schemes.
  • Accumulator-based spent-shard proofs.
  • Alternative replay-protection constructions.

Such mechanisms could reduce long-term storage requirements without changing the ownership model.

10.6.5 Economic Cost as a Spam Deterrent

A common property of the abuse vectors described above is that they impose direct and unavoidable costs on the attacker.

Unlike many traditional denial-of-service attacks, GhostShard spam attacks cannot be performed for free.

Creating dust shards, generating announcements, or flooding discovery infrastructure requires the attacker to execute valid protocol transactions and pay the associated network fees.

flowchart LR

    A[Attacker]
    --> T[Spam Transaction]

    T --> G[Gas Cost]

    T --> N[Network Fees]

    G --> C[Direct Economic Cost]
    N --> C

Consequently, attack cost scales approximately linearly with attack volume:

\[ \text{Attack Cost} \propto \text{Number of Spam Operations} \]

An attacker attempting to create:

  • More dust shards,
  • More announcements,
  • More discovery workload,
  • More network events,

must continuously spend additional capital to do so.

Importantly, these expenditures do not provide the attacker with:

  • Asset access,
  • Ownership visibility,
  • Authorization capabilities,
  • Viewing-key access,
  • Wallet reconstruction capabilities.

The attacker therefore incurs real economic costs while obtaining little or no corresponding security advantage.

This cost asymmetry acts as a natural deterrent against large-scale abuse and helps ensure that spam attacks remain economically expensive relative to their practical impact.

10.7 Key Management Security

Question: What happens if secret material is compromised?

The security of GhostShard ultimately depends on the confidentiality of the cryptographic secrets used to derive ownership, discover incoming transfers, and authorize spending.

Unlike traditional account-based wallets, GhostShard separates responsibilities across multiple classes of keys. As a result, compromise of one key does not necessarily imply compromise of all protocol security properties.

This section analyzes the consequences of compromise for each key class and identifies the resulting security boundaries.

10.7.1 Root Seed Security

The root seed is the master secret from which all protocol keys are deterministically derived.

Conceptually:

\[ \text{Root Seed} \rightarrow {\text{Shard Keys},\ \text{Viewing Keys},\ \text{Future Derived Keys}} \]

The root seed is generated from a domain-separated EIP-712 signature during wallet initialization.

flowchart LR

    U[User EOA]
    --> S[EIP-712 Signature]

    S --> R[Root Seed]

    R --> VK[Viewing Keys]
    R --> SK[Shard Keys]

The root seed represents the highest-value secret within the GhostShard architecture.

Compromise Impact

Compromise of the root seed results in complete loss of security.

An attacker obtaining the root seed can:

  • Derive all shard private keys.
  • Derive all viewing keys.
  • Discover historical transfers.
  • Discover future transfers.
  • Spend all currently controlled shards.
  • Reconstruct the user's entire wallet state.

In practical terms, root-seed compromise is equivalent to full wallet compromise.

Security Boundary

GhostShard v0 does not implement:

  • Root-seed rotation.
  • Root-seed revocation.
  • Key migration.
  • Protocol-level recovery.

Consequently, protection of the root seed remains the user's primary security responsibility.

10.7.2 Viewing Key Compromise

Viewing keys provide ownership-discovery capabilities without granting spending authority.

A viewing key holder can:

  • Discover incoming transfers.
  • Recover stealth-address ownership.
  • Decrypt associated metadata.
  • Reconstruct wallet balances.

However, viewing keys do not authorize spending.

flowchart LR

    VK[Viewing Key]

    VK --> D[Transfer Discovery]
    VK --> M[Metadata Recovery]

    VK -. No Access .-> S[Spending Authority]

Compromise Impact

Viewing-key compromise results primarily in privacy loss.

An attacker may obtain visibility into:

  • Incoming transfers.
  • Transfer timing.
  • Transfer values.
  • Sender metadata.

However, the attacker cannot:

  • Spend assets.
  • Produce transfer authorizations.
  • Modify ownership records.
  • Create valid shard signatures.

Security Boundary

Viewing-key compromise affects privacy but not fund safety.

This separation is an intentional design goal of the GhostShard architecture.

Operational Considerations

Viewing keys may be shared with auditors, accountants, compliance providers, or monitoring systems.

Such sharing should be treated as a deliberate privacy decision because it grants long-term visibility into wallet activity.

10.7.3 Shard-Key Compromise

Each shard possesses an independent spending key.

Ownership authorization occurs at the shard level rather than at the wallet level.

flowchart LR

    Root[Root Seed]

    Root --> S1[Shard Key A]
    Root --> S2[Shard Key B]
    Root --> S3[Shard Key C]

Compromise Impact

Compromise of a shard key affects only the corresponding shard.

The attacker may:

  • Spend that shard.
  • Authorize transfers using that shard.

The attacker cannot automatically:

  • Spend unrelated shards.
  • Recover the root seed.
  • Derive viewing keys.
  • Control the remainder of the wallet.

Security Boundary

This compartmentalization significantly limits blast radius.

Unlike conventional account-based wallets where a single key controls all assets, GhostShard distributes authorization authority across independent shard keys.

Exposure Window

Because shards are one-time-use objects, the usefulness of a compromised shard key ends once the shard has been consumed.

Consequently, shard-key compromise produces a naturally bounded exposure period.

10.7.4 Device Compromise

GhostShard cannot protect users against compromise of the device responsible for key management.

Examples include:

  • Malware.
  • Keyloggers.
  • Remote-access trojans.
  • Memory scraping attacks.
  • Browser compromise.

The consequences depend on which secrets become accessible.

Captured Secret Consequence
Viewing Key Privacy compromise
Single Shard Key Localized fund compromise
Root Seed Full wallet compromise

Security Boundary

Device security lies outside the protocol security model.

GhostShard assumes that cryptographic secrets remain confidential on the user's device.

Once a device becomes hostile, protocol-level protections become substantially weaker.

Mitigations

Operational protections include:

  • Hardware wallets.
  • Secure enclaves.
  • Isolated signing environments.
  • Memory-hard storage protections.
  • Dedicated wallet devices.

10.7.5 Recovery and Rotation Limitations

GhostShard v0 intentionally prioritizes deterministic key derivation and simplicity over complex recovery mechanisms.

Unlike conventional wallet architectures, the root seed is not a randomly generated secret that exists independently of the user's wallet.

Instead, it is deterministically derived from an EIP-712 signature produced by the user's root wallet during initialization.

As a result, loss of a locally stored root seed does not necessarily result in permanent loss of access.

Provided the user still controls the original root wallet, the root seed can be deterministically regenerated and the entire GhostShard key hierarchy reconstructed.

However, GhostShard v0 does not currently support:

  • Viewing-key revocation.
  • Viewing-key rotation.
  • Shard-key rotation.
  • Automatic ownership migration.
  • Recovery from loss of the root wallet itself.

If the root wallet is permanently lost, access to the corresponding GhostShard key hierarchy is also permanently lost.

Similarly, if a viewing key is disclosed, there is no mechanism to revoke or invalidate that disclosure. The compromised party retains visibility into both historical and future transfers associated with that viewing key.

These limitations arise from the deterministic key architecture adopted by GhostShard v0.

Future versions may explore:

  • Hierarchical key rotation.
  • Time-bounded viewing keys.
  • Social recovery systems.
  • Multi-signature shard authorization.
  • Recovery-oriented ownership migration.
  • Wallet-migration procedures for deterministic key hierarchies.

10.8 Smart Contract Security

Question: What prevents contract-level exploits?

This section analyzes the security properties of the GhostRouter and GhostShard contracts, focusing on reentrancy resistance, authorization validation, state consistency, execution atomicity, and protocol immutability.

10.8.1 Reentrancy Analysis

GhostRouter follows a strict checks-effects-interactions execution model and employs OpenZeppelin's ReentrancyGuard on all externally callable state-mutating entry points.

The router performs critical state updates before any asset-transfer operations occur.

Conceptually:

\[ \texttt{isShardSpent}(\texttt{shard}) \leftarrow \texttt{true} \]

occurs before transfer execution begins.

Similarly:

  • Paymaster deposits are debited before user execution.
  • Withdrawal balances are reduced before ETH transfers.
  • Accounting state is updated before external interactions.

Additionally, OpenZeppelin's nonReentrant protection is applied to externally callable entry points, including:

  • executeMesh()
  • withdrawGas()

This prevents malicious contracts from recursively invoking router functions during execution.

Asset transfers are executed through the isolated execution sandbox.

Execution is permitted only when:

\[ \texttt{caller}=\texttt{Router} \]

and rejected otherwise:

\[ \texttt{caller} \neq \texttt{Router} ;\Longrightarrow; \texttt{ExecutionRejected} \]
flowchart LR

    U[External Caller]
    --> V{Caller = Router?}

    V -->|No| R[Reject]

    V -->|Yes| E[Execute Sandbox]

As a result, even if a GhostShard implementation or token contract attempted to reenter the router during execution, nested mesh execution would be blocked by the reentrancy guard.

The onlyRouter restriction on GhostShard further ensures that transfer functions cannot be invoked directly by arbitrary external actors.

Finally, execution occurs within explicitly bounded gas limits supplied by the bundler and paymaster authorization. These limits constrain resource consumption and reduce the impact of malicious implementations attempting to consume excessive gas.

10.8.2 Authorization Validation

Before execution begins, GhostRouter validates the active EIP-7702 delegation target associated with every participating shard.

Conceptually, the following invariant must hold:

\[ \texttt{ActiveImplementation}=\texttt{AuthorizedImplementation} \]

If:

\[ \texttt{ActiveImplementation} \neq \texttt{AuthorizedImplementation} \]

execution immediately reverts with:

\[ \texttt{TargetCodeMismatch} \]
flowchart LR

    S[Shard]

    --> A[Active Implementation]

    A --> C{Matches Authorized Target?}

    C -->|Yes| E[Continue]

    C -->|No| R[TargetCodeMismatch]

This validation ensures that each shard's runtime code points to the expected GhostShard implementation.

A malicious relayer cannot:

  • Substitute implementations.
  • Redirect delegation targets.
  • Submit unauthorized shard executions.
  • Manipulate delegation state to extract gas refunds.

Validation occurs before any state mutation or asset transfer.

Transient storage is used to track shard participation within a single batch execution. This allows multiple operations involving the same shard during execution while ensuring that the shard is permanently retired once the transaction completes.

10.8.3 State Consistency

GhostShard enforces a collection of protocol invariants designed to maintain execution correctness and prevent unauthorized state transitions.

The following conditions are explicitly verified:

  • ShardAlreadySpent — prevents reuse of retired shards.
  • InvalidSignature — ensures transfer authorization originates from the shard owner.
  • InvalidPaymasterSignature — ensures sponsorship approval matches the executed bundle.
  • PaymasterExpired — ensures sponsorship remains within its validity period.
  • InsufficientPaymasterDeposit — ensures sufficient prefunding exists.
  • GasPriceTooHigh — ensures execution remains within approved gas limits.
  • CannotAnnounceSpentShard — prevents retired shards from appearing as new outputs.
  • TargetCodeMismatch — prevents execution under an unexpected delegation target.

Collectively these invariants enforce:

\[ \texttt{Execution} \Rightarrow \texttt{ValidAuthorization} \land \texttt{ValidSponsorship} \land \texttt{ValidDelegation} \land \texttt{ConsistentState} \]

Execution therefore proceeds only under a fully validated authorization and accounting state.

10.8.4 Failure Atomicity

Mesh execution is designed to be atomic.

All user operations execute within the isolated execution sandbox.

If any command fails due to:

  • Invalid signatures.
  • Authorization mismatches.
  • Failed transfers.
  • Invariant violations.
  • Sponsorship failures.

the entire execution reverts.

Conceptually:

\[ \exists i \in \texttt{Commands} : \texttt{Failure}(i) \Longrightarrow \texttt{Revert(All)} \]
flowchart LR

    B[Mesh Bundle]

    --> C1[Command 1]
    --> C2[Command 2]
    --> C3[Command 3]

    C3 --> F[Failure]

    F --> R[Revert Entire Bundle]

Consequently:

  • No partial asset transfers occur.
  • No partially processed shard states persist.
  • No inconsistent ownership state can be created.

Execution outcomes are recorded through the MeshExecuted event, which captures both successful and failed execution paths.

Gas accounting remains deterministic even during failure scenarios.

Relayers are compensated only for actual gas consumed up to the prefunded limit, while unused prefund is automatically returned to the paymaster deposit balance.

10.8.5 Upgrade and Governance Assumptions

GhostRouter and GhostShard are intentionally designed as immutable protocol components.

There is no:

  • Owner account.
  • Admin key.
  • Upgrade proxy.
  • Governance-controlled parameter set.
  • Self-destruct functionality.
  • Arbitrary delegatecall execution path.

Once deployed, protocol behavior cannot be modified.

flowchart LR

    D[Deployment]

    --> I[Immutable Protocol]

    I --> N1[No Admin Keys]
    I --> N2[No Upgrades]
    I --> N3[No Governance Control]

This design eliminates several common attack surfaces:

  • Governance capture.
  • Upgrade vulnerabilities.
  • Admin-key compromise.
  • Privileged execution abuse.

The tradeoff is that discovered bugs cannot be patched in place.

Security therefore depends on:

  • Rigorous design review.
  • Comprehensive testing.
  • Public scrutiny.
  • Independent security audits.

The contracts remain intentionally compact (approximately 378 lines for GhostRouter and 120 lines for GhostShard), making complete audit review and on-chain verification practical.

GhostShard v0 assumes the correctness of:

  • The Ethereum Virtual Machine.
  • EIP-7702 delegation semantics.
  • The ERC-5564 announcement registry.
  • OpenZeppelin security primitives used throughout the implementation.

Under these assumptions, the contract architecture provides strong resistance against common smart-contract attack classes while maintaining deterministic and auditable execution behavior.

10.9 Cryptographic Assumptions

GhostShard v0 derives its security from established cryptographic primitives that are already relied upon by Ethereum and extensively studied within the cryptographic literature.

The protocol introduces no novel cryptographic assumptions. Instead, its security reduces to the security of the underlying primitives used for key exchange, digital signatures, hashing, authenticated encryption, and key derivation.

flowchart LR

A[secp256k1 ECDH] --> B[Shared Secret]
B --> C[HKDF-SHA256]
C --> D[AES-256-GCM Keys]
B --> E[Stealth Address Derivation]

F[Keccak-256] --> E
G[ECDSA secp256k1] --> H[Ownership Authorization]

A successful attack against GhostShard's privacy or ownership model would therefore require breaking one or more of these underlying cryptographic assumptions.

10.9.1 ECDH Security

Stealth address derivation and metadata key generation rely on Elliptic Curve Diffie-Hellman (ECDH) over secp256k1.

Given:

  • (E = eG) (ephemeral public key)
  • (V = vG) (recipient viewing public key)

the protocol derives the shared secret:

[ S = evG ]

Security relies on the Computational Diffie-Hellman (CDH) assumption: given only (E) and (V), it is computationally infeasible to compute (S) without knowledge of either private scalar (e) or (v).

The resulting shared secret is subsequently processed through cryptographic hash functions and HKDF before being used by higher-level protocol components.

A successful break of secp256k1 ECDH would allow an attacker to:

  • Recover shared secrets,
  • Link stealth addresses to recipients,
  • Decrypt announcement metadata,
  • Defeat recipient privacy.

This is the same discrete-logarithm assumption that underlies Ethereum account security and ECDSA signatures.

10.9.2 Stealth Address Security

GhostShard uses ERC-5564-style stealth addressing to decouple public recipient identities from on-chain receiving addresses.

Each stealth shard is deterministically derived from:

  • The recipient's spending public key,
  • The ECDH-derived shared secret.

Without access to the shared secret, an observer cannot:

  • Determine whether a stealth shard belongs to a particular meta-address,
  • Link multiple stealth shards to the same recipient,
  • Recover the shard's private key,
  • Predict future shard addresses.

Stealth address privacy therefore reduces to the security of:

  • secp256k1 ECDH,
  • Keccak-256,
  • Secure key derivation.

Knowledge of a shard address alone provides no practical method for deriving the corresponding private key.

10.9.3 AES-GCM Security

GhostShard encrypts announcement metadata using AES-256-GCM.

AES-GCM provides both confidentiality and integrity guarantees and is widely deployed across modern cryptographic protocols.

Confidentiality

AES-GCM satisfies indistinguishability under chosen-plaintext attack (IND-CPA), meaning ciphertexts are computationally indistinguishable from random data without knowledge of the encryption key.

An observer who does not possess the correct encryption key cannot feasibly recover the plaintext metadata or distinguish encrypted metadata from random data.

Integrity

AES-GCM additionally provides ciphertext authenticity (INT-CTXT).

Any modification to:

  • Ciphertext contents,
  • Initialization vectors (IVs),
  • Authentication tags,

will be detected during decryption with overwhelming probability.

For a 128-bit authentication tag, the probability of successfully forging a valid ciphertext is approximately:

\[ 2^{-128} \]

which is negligible for all practical attack scenarios.

Consequently, an attacker cannot modify encrypted metadata without detection.

IV Collision Analysis

A fresh uniformly random 96-bit initialization vector (IV) is generated for every announcement encryption.

Assuming secure random IV generation, the probability of at least one IV collision after (N) encryptions is approximately:

\[ P_{\text{collision}} \approx \frac{N(N-1)}{2^{97}} \]

by the birthday bound.

For large values of (N), this is often approximated as:

\[ P_{\text{collision}} \approx \frac{N^2}{2^{97}} \]

Even for extremely large announcement volumes, the probability of an IV collision remains negligible.

For example, after:

\[ N = 10^9 \]

encrypted announcements,

\[ P_{\text{collision}} \approx 6.3 \times 10^{-12} \]

which is effectively zero for practical deployment scenarios.

The security analysis assumes IVs are generated using a cryptographically secure random number generator. Under this assumption, accidental IV reuse is not expected to occur during the operational lifetime of the protocol.

10.9.4 HKDF Security

GhostShard uses HKDF-SHA256 to derive cryptographic subkeys from ECDH-generated shared secrets.

Domain-separated context strings are used to prevent key reuse across protocol functions:

  • "ghost-shard-metadata"
  • "ghost-shard-ephemeral"

HKDF security reduces to the security of:

  • HMAC-SHA256,
  • SHA-256 preimage resistance,
  • SHA-256 collision resistance.

Compromise of one derived key does not reveal sibling keys generated under different HKDF contexts.

This property provides cryptographic isolation between metadata encryption, ephemeral derivation, and future protocol extensions.

10.9.5 Signature Security

Ownership authorization relies on secp256k1 ECDSA signatures.

Every transfer command must be signed by the corresponding shard owner.

Security depends on the infeasibility of:

  • Recovering private keys from public keys,
  • Forging valid ECDSA signatures,
  • Producing signature collisions.

An attacker capable of forging valid secp256k1 signatures could authorize arbitrary asset transfers and defeat ownership controls.

This is the same assumption relied upon by Ethereum accounts, transactions, and smart-contract wallets.

10.9.6 Security Reduction Summary

GhostShard introduces no trusted setup and no novel cryptographic primitives.

The protocol's security reduces to the following established assumptions:

Primitive Security Assumption
secp256k1 ECDH Computational Diffie-Hellman
secp256k1 ECDSA Discrete Logarithm Problem
Keccak-256 Preimage Resistance
SHA-256 Preimage & Collision Resistance
HKDF-SHA256 HMAC Security
AES-256-GCM IND-CPA + INT-CTXT

Consequently, breaking GhostShard's privacy or ownership guarantees requires breaking cryptographic assumptions already relied upon by Ethereum itself.

10.9.7 Post-Quantum Considerations

Like Ethereum, GhostShard v0 is not post-quantum secure.

Large-scale quantum computers capable of executing Shor's algorithm would compromise:

  • secp256k1 ECDH,
  • secp256k1 ECDSA,
  • Stealth address derivation,
  • Shared-secret generation.

Grover's algorithm reduces the effective security level of symmetric primitives:

  • AES-256 provides approximately 128 bits of post-quantum security.
  • SHA-256 and Keccak-256 retain reduced but still substantial preimage resistance.

Although GhostShard v0 is not quantum resistant, the architecture was intentionally designed to support future migration paths.

Potential upgrade paths include:

  • Post-quantum key exchange schemes,
  • Post-quantum signature algorithms,
  • Alternative stealth address derivation mechanisms.

The ERC-5564 schemeId field provides a protocol-level mechanism for introducing alternative cryptographic schemes without requiring changes to the surrounding transaction architecture.

10.9.8 Trusted Setup Assumptions

GhostShard requires:

  • No trusted setup,
  • No ceremony,
  • No structured reference string,
  • No multi-party parameter generation process.

All cryptographic operations rely exclusively on deterministic derivation or publicly generated randomness such as:

  • Ephemeral key pairs,
  • AES-GCM initialization vectors.

As a result, GhostShard avoids the operational and trust assumptions commonly associated with zk-SNARK-based privacy systems.

10.10 Security Boundary Summary

GhostShard v0 employs a defense-in-depth security architecture in which fund safety, authorization integrity, privacy, and infrastructure resilience are protected by multiple independent security mechanisms.

The protocol is intentionally designed so that no single participant—including users, relayers, paymasters, builders, or infrastructure providers—can unilaterally compromise all security properties simultaneously.

Instead, successful compromise generally requires violating multiple independent assumptions across cryptographic, protocol, and operational layers.

The following tables summarize the primary security boundaries established throughout this chapter.

10.10.1 Fund Safety

Fund safety is enforced through ownership-bound authorization, one-time-use shard semantics, replay protection, and immutable execution rules.

Threat Primary Protection
Unauthorized spending Shard-private-key ownership enforced through ECDSA signature verification
Signature forgery Security of secp256k1 and ECDSA
Replay attacks One-time-use shard model, permanent spent-shard tracking, transient-storage deduplication
Cross-transaction reuse Authorization binding to chain identifier, router address, and transfer parameters
Authorization theft EIP-7702 delegation separated from transfer authorization
Front-running attempts Atomic bundle execution and bundle-bound sponsorship
Relayer manipulation Signed commands and authorization validation prevent transaction modification
Paymaster abuse Bounded gas sponsorship and deterministic settlement accounting
Contract-level exploits Immutable contracts, authorization validation, replay protection, and atomic execution

Under the assumptions defined in the threat model, asset theft requires compromise of the shard owner's private key or a failure of the underlying cryptographic assumptions.

10.10.2 Authorization Integrity

Authorization integrity ensures that valid permissions cannot be forged, reused, broadened, or repurposed beyond the intent of the signer.

Threat Primary Protection
Cross-contract replay Router-address binding
Cross-chain replay Chain-identifier binding
Recipient substitution Transfer-parameter commitment
Amount modification Transfer-parameter commitment
Bundle modification Paymaster sponsorship binding
Authorization reuse One-time-use shards and delegation lifecycle
Signature confusion Domain separation between EIP-7702 and EIP-191 signatures
Signature phishing Independent authorization domains and key separation

As a result, a valid authorization grants permission only for the specific action originally approved by the shard owner.

10.10.3 Privacy Protection

GhostShard's privacy model is based on unlinkable stealth addresses, encrypted metadata, one-time-use ownership structures, and recipient discovery through ECDH-derived secrets.

Threat Primary Protection
Recipient identification Stealth-address construction
Sender-recipient linkage Independent shard ownership and relayed execution
Metadata disclosure AES-256-GCM encryption using ECDH-derived secrets
Ownership reconstruction One-time-use shards and absence of persistent ownership identifiers
Transaction graph analysis UTXO-style ownership transitions
Meta-address discovery Viewing-key requirement
Announcement scanning View-tag filtering
Wallet reconstruction Independent shard derivation and ownership fragmentation

Privacy guarantees rely on the security of secp256k1, ECDH, HKDF-SHA256, AES-256-GCM, and the assumptions described in Chapter 8.

10.10.4 Infrastructure Resilience

GhostShard minimizes trust in infrastructure providers by ensuring that relayers and paymasters participate in execution without obtaining spending authority.

Infrastructure Component Maximum Adversarial Capability Protocol Mitigation
Relayer Refuse or delay transaction broadcast Multiple relayers and self-relay support
Paymaster Refuse sponsorship or collect transaction metadata Alternative paymasters and self-funded execution
Builder / Block Producer Observe pending transactions and transaction ordering Private submission channels and atomic execution
RPC Provider Observe user requests Infrastructure diversity and self-hosted alternatives
Announcement Indexer Observe public announcements Metadata encryption and viewing-key requirements

Compromise of any single infrastructure provider does not provide the ability to spend user assets.

10.10.5 Economic Security

GhostShard incorporates explicit protections against economic abuse targeting relayers, paymasters, and discovery infrastructure.

Attack Class Mitigation
Paymaster draining Simulation, sponsorship policies, bounded gas exposure
Relayer bleeding Authorization validation and simulation before broadcast
Bundle griefing Bundle-bound sponsorship and replay protection
Dust-shard attacks Economic cost of shard creation and wallet filtering policies
Meta-address spam View tags and attacker-funded announcement publication
Announcement flooding Transaction-cost requirements and event filtering
State-growth attacks Cost proportional to transaction creation

A recurring design principle throughout the protocol is that spam and abuse require the attacker to pay normal network execution costs, creating a direct economic disincentive for large-scale attacks.

10.10.6 Known Limitations

GhostShard v0 intentionally accepts several limitations in exchange for simplicity, auditability, and protocol immutability.

These limitations include:

  • No viewing-key revocation mechanism.
  • No root-wallet recovery mechanism.
  • No key-rotation support for existing shards.
  • Permanent spent-shard storage growth.
  • Immutable contract deployments.
  • Dependence on at least one available transaction-broadcast path.
  • Reliance on established cryptographic assumptions.
  • Lack of formal verification.
  • Absence of a completed third-party security audit.

These limitations do not invalidate the protocol's security model but define the boundaries within which the model is intended to operate.

10.10.7 Final Assessment

Under the assumptions established in the threat model, GhostShard v0 provides strong protections for:

  • Fund safety.
  • Authorization integrity.
  • Ownership privacy.
  • Recipient privacy.
  • Metadata confidentiality.
  • Replay resistance.
  • Infrastructure independence.

Compromise of any single component—including a relayer, paymaster, announcement indexer, or individual shard key—does not automatically result in compromise of the entire system.

The primary security boundary remains the root wallet from which shard keys and viewing keys are derived. Consequently, protection of the root wallet represents the most critical operational security requirement for GhostShard users.

Within that boundary, the protocol's layered architecture ensures that security failures remain localized, bounded, and resistant to escalation.