6. Execution Model

The cryptographic mechanisms described in Chapter 5 establish ownership, discovery, privacy, and selective disclosure. This chapter describes how those ownership units become executable transactions on the EVM.

GhostShard's execution model combines EIP-7702 delegation, multi-authorization execution, mesh transaction construction, paymaster-sponsored gas settlement, and relayer-assisted broadcasting. Together, these components enable multiple independent shards to participate in a single atomic transaction while preserving the ownership, privacy, and custody guarantees established by the protocol.

The execution model is designed around four principles:

Atomicity — all shard operations succeed or fail together.
Independent custody — assets remain under the control of individual shards until execution.
Delegated programmability — shards temporarily acquire execution logic through EIP-7702 delegation.
Gas abstraction — users may execute transactions without directly managing native gas assets.

Status

Component	Status
EIP-7702 delegation	Implemented
Multi-authorization execution	Implemented
Atomic mesh execution	Implemented
Pre-scan code integrity verification	Implemented
Transient storage deduplication	Implemented
Double simulation engine	Implemented
Paymaster deposit and withdrawal system	Implemented
Relayer FIFO queue	Implemented
Batched authorization compression	Implemented
Self-protection simulation	Planned
Alternative execution engines	Research

Measured transaction costs are evaluated in Chapter 11.

6.1 EIP-7702

GhostShard requires execution capabilities that are not available to traditional EOAs and are difficult to achieve within existing account-abstraction architectures.

Specifically, the protocol requires:

1. Per-Transaction Code Execution

Shards must execute transfer operations such as:

transferNative
transferERC20
transferERC721

without permanently deploying code to every shard address.

EIP-7702 enables temporary delegation of execution logic while preserving the shard as a standard EOA.

2. Multi-Authorization Execution

A single mesh transaction may consume multiple input shards.

Each shard must independently authorize participation in the transaction while contributing assets toward a common atomic state transition.

EIP-7702 allows a transaction to carry multiple authorizations, enabling atomic execution across multiple independently owned shards.

3. Independent Asset Custody

Each shard maintains direct ownership of its assets.

The protocol cannot rely on pooled balances or shared custody without undermining the shard ownership model.

EIP-7702 preserves per-shard ownership semantics by delegating execution to individual shards rather than routing assets through a centralized execution account.

Comparison with Alternative Models

Property	Traditional EOA	ERC-4337	EIP-7702
Programmable execution	No	Via EntryPoint	Via delegation
Multi-authorization per transaction	No	No	Yes
Alternative mempool required	No	Yes	No
Asset custody model	Independent	Independent	Independent
Bundler dependency	No	Yes	No
Native paymaster support	No	Yes	Via Router

Design Rationale

GhostShard adopts EIP-7702 because its core operation—atomic execution across multiple independently owned shards—requires native support for multiple authorizations within a single transaction.

While ERC-4337 provides a powerful account abstraction framework, its execution model centers around a single user operation processed through a shared EntryPoint contract. This architecture is not naturally suited to GhostShard's ownership model, where multiple EOAs must authorize a common transaction while retaining independent custody of their assets.

GhostShard does not require:

A mandatory EntryPoint contract.
A specialized mempool.
Bundler participation for correctness.
Shared asset custody.

Instead, it requires only a temporary execution primitive capable of coordinating multiple EOAs within a single atomic transaction.

EIP-7702 provides precisely this capability.

flowchart LR

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

    A --> D[7702 Authorization]
    B --> D
    C --> D

    D --> E[GhostRouter]

    E --> F[Atomic Mesh Execution]

    F --> G[Output Shards]

By delegating execution logic to individual shards only for the duration of a transaction, EIP-7702 enables atomic mesh execution while preserving the protocol's privacy, custody, and ownership guarantees.

For these reasons, EIP-7702 forms the foundation of the GhostShard execution model.

6.2 Transaction Lifecycle

A GhostShard transaction progresses through five distinct phases before reaching final settlement on-chain.

The lifecycle begins with local bundle construction inside the SDK, proceeds through sponsorship approval and relayer validation, executes atomically through the GhostRouter, and finally reconciles wallet state after confirmation.

flowchart LR

    A[Bundle Construction]
    --> B[Paymaster Quote]

    B --> C[Relayer Validation]

    C --> D[On-Chain Execution]

    D --> E[Post-Execution Synchronization]

Each phase has a clearly defined responsibility, security boundary, and failure domain.

6.2.1 Phase 1 — Bundle Construction (SDK)

The SDK constructs a complete mesh transaction bundle locally.

flowchart TD

    A[Coin Selection]

    A --> B[Shard Key Recovery]

    B --> C[EIP-7702 Authorizations]

    C --> D[Stealth Output Generation]

    D --> E[Metadata Encryption]

    E --> F[Transfer Signatures]

    F --> G[Command Fusion]

    G --> H[Command Randomization]

    H --> I[Final Bundle]

Coin Selection

The coin-selection engine selects input shards and computes:

Payment outputs
Change outputs
Optional compression outputs

as described in Section 6.6.

Shard Key Recovery

For each selected shard, the SDK reconstructs the shard private key:

\[ [ k_{\text{shard}}=(k_{\text{spend}} + SS) \bmod n ] \]

where

\[ [ SS=\operatorname{Keccak256} \left( x(v \cdot E) \right) ] \]

and:

(v) is the viewing private key.
(E) is the announcement ephemeral public key.
(n) is the secp256k1 curve order.

EIP-7702 Authorizations

Each input shard signs an EIP-7702 authorization delegating execution to the GhostShard implementation contract.

Because shards follow a UTXO-style ownership model, authorization nonces remain fixed at zero.

Stealth Output Generation

New payment and change shards are generated using the stealth-address construction described in Chapter 5.

Each output receives a fresh ephemeral keypair and therefore a unique ownership address.

Metadata Encryption

Output metadata is encrypted using the ECDH-derived shared secret and AES-256-GCM as described in Section 5.6.

Transfer Authorization

Each transfer command is authorized using an EIP-191 signature over:

\[ [ ( \text{chainId}, \text{router}, \text{shard}, \text{assetType}, \text{token}, \text{recipient}, \text{value}, \text{announcements} ) ] \]

Command Fusion

Commands targeting the same recipient and asset may be merged into a single transfer operation.

ERC-721 transfers are never fused.

Command Randomization

Commands are shuffled before submission to avoid leaking construction order and wallet behavior patterns.

6.2.2 Phase 2 — Paymaster Quote

The completed bundle is submitted to a paymaster for sponsorship approval.

sequenceDiagram

    participant SDK
    participant Paymaster

    SDK->>Paymaster: Bundle + User Signature

    Paymaster->>Paymaster: Verify User

    Paymaster->>Paymaster: Double Simulation

    Paymaster-->>SDK: Signed Quote

The paymaster:

Verifies user authorization.
Executes Double Simulation.
Computes precise gas limits.
Signs the sponsorship quote.

The resulting quote contains:

Verification gas limit
Execution gas limit
Expiration timestamp
Paymaster signature

The quote serves as a cryptographic commitment to sponsor execution under the specified conditions.

6.2.3 Phase 3 — Relayer Validation

The SDK submits the fully assembled bundle to a relayer.

sequenceDiagram

    participant SDK
    participant Relayer

    SDK->>Relayer: Signed Bundle

    Relayer->>Relayer: Escrow Check

    Relayer->>Relayer: Simulation

    Relayer->>Relayer: Queue Insertion

    Relayer-->>SDK: Accepted

Before broadcast, the relayer performs several defensive checks:

Verify paymaster escrow coverage.
Simulate execution using EIP-7702 state overrides.
Reject invalid bundles.
Insert valid bundles into a FIFO execution queue.

The relayer cannot modify transaction contents.

It may delay execution or refuse service, but correctness remains fully enforced on-chain.

6.2.4 Phase 4 — On-Chain Execution

The relayer broadcasts the bundle as an EIP-7702 transaction.

Execution proceeds through six stages.

flowchart LR

    A[Authorization Processing]
    --> B[Pre-Scan]
    --> C[Prefund Reservation]
    --> D[Paymaster Validation]
    --> E[Sandboxed Execution]
    --> F[Gas Settlement]

Step 0 — Authorization Processing

The EVM processes all EIP-7702 authorizations.

Each shard temporarily delegates execution to the GhostShard implementation contract.

This delegation exists only for the duration of transaction execution.

Step 1 — Pre-Scan

GhostRouter verifies delegated code integrity.

For every transfer command:

Read shard bytecode using EXTCODECOPY.
Extract the delegated implementation address.
Verify the implementation matches the authorized target.

This prevents execution against missing, modified, or unauthorized delegated code.

Step 2 — Prefund Reservation

The router computes the worst-case execution cost: $$ [ \text{requiredPrefund}=( G_{\text{verification}} + G_{\text{execution}} + G_{\text{preVerification}} ) \times \text{gasPrice} ] $$

The amount is reserved from the sponsoring paymaster deposit.

Step 3 — Paymaster Validation

The router:

Reconstructs the paymaster hash.
Verifies the EIP-191 signature.
Checks quote expiration.
Confirms sponsorship validity.

Execution proceeds only if all validation checks succeed.

Step 4 — Sandboxed Execution

The router executes:

innerExecuteMesh(commands, announcements)

through an isolated internal execution boundary.

This ensures:

External callers cannot trigger shard transfers directly.
Protocol invariants are preserved.
Settlement logic always surrounds execution.

Announcement Processing

Each announcement is validated and emitted through the ERC-5564 announcer contract.

Announcements and transfers remain fully atomic.

Transfer Processing

For every transfer command:

Check transient deduplication state.
Verify the shard has not already been spent.
Mark the shard as spent.
Recover the command signer.
Verify signer ownership.
Execute delegated transfer logic.

All transfers execute atomically.

If any transfer fails, the entire mesh transaction reverts.

Step 5 — Gas Settlement

After execution:

Actual gas consumption is measured.
Settlement is bounded by the prefunded amount.
Unused funds are refunded.
Relayer reimbursement is paid.
Settlement events are emitted.

6.2.5 Phase 5 — Post-Execution Synchronization

After confirmation, the SDK reconciles local wallet state.

flowchart TD

    A[Transaction Receipt]

    --> B[Parse MeshExecuted]

    --> C[Delete Consumed Shards]

    --> D[Add Change Shards]

    --> E[Advance Sync Cursor]

    --> F[Future Announcement Discovery]

The wallet performs the following updates:

Deletes consumed input shards from the local shard store.
Adds newly created change shards.
Advances the synchronization cursor.
Discovers future incoming shards through announcement scanning.

Spent shards are removed rather than retained.

Because shards follow a UTXO-style ownership model and may only be spent once, retaining spent shards provides little operational value while increasing local storage requirements. Deleting spent shards keeps wallet state compact and ensures synchronization cost remains proportional to active ownership rather than historical activity.

6.2.6 Failure Modes

Failure Point	Outcome	Cost Bearer
Missing delegated code	Pre-scan fails and transaction reverts before execution	Relayer
Invalid delegated implementation	Pre-scan fails and transaction reverts before execution	Relayer
Invalid paymaster/user signature	Validation fails and transaction reverts before execution	Relayer
Sponsorship expired	Validation fails and transaction reverts before execution	Relayer
Gas price exceeds signed quote	Transaction rejected before execution	Relayer
Insufficient paymaster deposit	Transaction rejected before execution	Relayer
Relayer simulation failure	Bundle never broadcast	User
Paymaster quote denied	Transaction never constructed	User
Relayer censorship	Transaction never broadcast	User (alternative relayer or self-relay)
Shard already spent	Atomic execution reverts	Paymaster/User
Invalid shard signature	Atomic execution reverts	Paymaster/User
Transfer command validation failure	Atomic execution reverts	Paymaster/User
Asset transfer failure	Atomic execution reverts	Paymaster/User
Announcement validation failure	Atomic execution reverts	Paymaster/User

The atomic execution model guarantees that no partial state transitions occur.

If any validation step, announcement, or transfer operation fails, the entire mesh transaction reverts and all state changes are discarded.

6.3 Execution Architecture

GhostShard's execution architecture consists of two on-chain components with strictly separated responsibilities:

GhostRouter: validates, coordinates, and settles execution.
GhostShard: performs asset transfers.

This separation minimizes the trusted execution surface while preserving atomic transaction execution.

6.3.1 GhostRouter

GhostRouter is the execution coordinator of the GhostShard protocol.

Every mesh transaction passes through a single router instance. The router validates execution prerequisites, coordinates announcements and transfers, enforces ownership rules, and settles sponsored gas costs.

GhostRouter never takes custody of user assets.

Assets remain held by shards throughout execution. The router's role is limited to validating and orchestrating state transitions.

flowchart LR

    A[Input Shards]
        --> B[GhostRouter]

    B --> C[Announcement Processing]
    B --> D[Transfer Execution]
    B --> E[Gas Settlement]

    D --> F[Output Shards]

Responsibilities

1. Delegation Integrity Verification

Before execution begins, the router verifies that every input shard is delegated to the expected implementation.

For each transfer command, the router:

Reads the shard's delegated code.
Extracts the delegated implementation address.
Verifies that the implementation matches the authorized delegation target.

This prevents execution against unexpected, modified, or substituted implementations.

2. Sponsorship Prefunding

Prior to execution, the router reserves the maximum potential gas cost from the sponsoring paymaster deposit.

After execution, the router:

Measures actual gas consumption.
Refunds unused prefunded value.
Pays relayer compensation.
Records execution results.

3. Paymaster Authorization

The router validates sponsorship approval before execution by:

Reconstructing the paymaster authorization payload.
Applying the EIP-191 signing domain.
Recovering the signing address.
Verifying signer ownership.
Verifying quote expiration.

Only valid sponsorships may proceed to execution.

4. Sandboxed Mesh Execution

Mesh execution occurs inside an isolated internal execution context controlled exclusively by the router.

This guarantees that:

External callers cannot invoke shard transfer logic directly.
Protocol validation always precedes execution.
Settlement always follows execution.

5. Announcement Coordination

The router coordinates all ERC-5564 announcements associated with a mesh transaction.

Announcements and transfers execute atomically. If execution reverts, all announcements revert alongside it.

This guarantees that a shard can never exist without its corresponding announcement.

6. Gas Reconciliation

Following execution, the router:

Measures actual gas consumed.
Computes final settlement.
Refunds unused sponsorship funds.
Pays relayer compensation.
Emits execution records.

Settlement is always bounded by the amount prefunded before execution.

State

Variable	Purpose
`isShardSpent`	Permanent tracking of consumed shards
`paymasterDeposits`	Sponsored gas deposits
`POST_EXECUTION_OVERHEAD`	Fixed allowance used during settlement calculations

6.3.2 GhostShard

GhostShard is the execution implementation delegated to shards through EIP-7702.

Where GhostRouter coordinates protocol execution, GhostShard performs a single responsibility: moving assets under router authorization.

The design is intentionally minimal. Every additional capability increases attack surface, audit complexity, and execution cost. Consequently, GhostShard contains only the functionality required to transfer assets already owned by a shard.

flowchart LR

    A[Shard Address]

    --> B[EIP-7702 Delegation]

    --> C[GhostShard]

    C --> D[Native Transfer]

    C --> E[ERC20 Transfer]

    C --> F[ERC721 Transfer]

The shard itself remains the asset owner. GhostShard merely provides executable logic when temporarily delegated through EIP-7702.

Design Principles

Minimal execution surface — no announcement handling, sponsorship logic, ownership tracking, upgrade mechanisms, or administrative controls.
Router-only authority — only GhostRouter may invoke shard transfer functions.
Asset-specific execution — transfer paths are specialized for each supported asset type.

Asset Transfer Responsibilities

Asset Type	Operation
Native ETH	Transfer value
ERC-20	Transfer fungible tokens
ERC-721	Transfer non-fungible tokens

Native assets are transferred directly from the shard balance using a low-level call that forwards all remaining gas, ensuring compatibility with contract recipients.

ERC-20 assets are transferred through direct token contract invocation, supporting both standard and non-standard token implementations.

ERC-721 assets are transferred from the shard address to the recipient through the NFT contract's transfer interface. The shard must already own the token being transferred.

Receiving Assets

A shard may receive assets at any time, including:

Direct ETH transfers.
ERC-20 token transfers.
ERC-721 token transfers.
Stealth payments.

Because shards are ordinary EVM addresses, no special deposit logic is required. Assets remain dormant within the shard until consumed by a future mesh transaction.

6.3.3 Security Boundaries

GhostRouter and GhostShard deliberately separate coordination from asset movement.

Component	Responsibility
GhostRouter	Validation, authorization, announcements, settlement
GhostShard	Asset movement only

The router determines whether a transfer may occur.

GhostShard determines how that transfer is executed.

This separation keeps shard implementations extremely small while centralizing protocol-critical validation inside a single audited execution coordinator.

Immutable Router Authority

The router address is fixed during deployment and cannot be modified.

This prevents execution from being redirected toward a malicious coordinator.

No Independent Execution

GhostShard cannot initiate transfers independently.

All execution must originate from a validated router invocation, preventing shards from bypassing protocol-level safeguards.

Atomic Failure Propagation

GhostShard never handles failures locally.

Any failed transfer propagates back to the router, causing the entire mesh transaction to revert.

As a result, execution remains atomic: either all transfers succeed or no state changes occur.

6.3.4 Core Invariants

GhostRouter enforces the following protocol invariants:

Single-Spend Protection — a shard may be consumed at most once.
Atomic Discovery — announcements and transfers succeed or fail together.
Authorization Correctness — only authorized shard owners may initiate transfers.
Delegation Integrity — delegated implementations must match authorized implementations.
Bounded Settlement — gas reimbursement cannot exceed prefunded limits.

These invariants hold regardless of relayer behavior, transaction ordering, or sponsorship configuration.

6.4 Transaction Construction

Before a mesh transaction can be executed, the SDK must determine which shards to consume, how their balances should be redistributed, and how the resulting transaction should be encoded for execution.

Transaction construction consists of three stages:

Coin Selection — selecting input shards and determining output allocations.
Compression — reducing long-term shard fragmentation during normal transaction activity.
Mesh Assembly — encoding the selected inputs and outputs into an atomic EIP-7702 transaction.

Together, these stages transform a set of independent shards into a single executable transaction while preserving privacy, efficiency, and atomicity.

flowchart LR

    A[Wallet Shards]

    --> B[Coin Selection]

    --> C[Compression Selection]

    --> D[Allocation Engine]

    --> E[Output Splitting]

    --> F[Announcement Generation]

    --> G[Authorization Generation]

    --> H[Mesh Transaction]

    --> I[EIP-7702 Execution]

The transaction construction pipeline converts a fragmented shard set into a single executable mesh transaction. Each stage contributes either privacy, efficiency, or fragmentation control before execution occurs on-chain.

6.4.1 Coin Selection

Coin selection determines which shards participate in a transaction and how their balances are distributed across payment and change outputs.

Unlike traditional UTXO systems, GhostShard coin selection is designed not only to satisfy a payment amount, but also to preserve privacy and improve long-term wallet health.

Objectives

Coin selection simultaneously pursues three goals:

Objective	Purpose
Privacy	Prevent observers from inferring payment relationships from transaction structure
Efficiency	Minimize unnecessary inputs and execution costs
Compression	Reduce shard fragmentation during normal transaction activity

Selection Strategy

The coin-selection engine follows a randomized, fingerprint-resistant strategy.

Step 1 — Candidate Selection

The wallet filters its shard pool to shards holding the required asset type and removes empty shards.

The resulting candidate set is shuffled using a cryptographically secure random number generator.

Step 2 — Payment Coverage

Shards are accumulated until the selected balance is sufficient to satisfy the payment amount and dust constraints.

Step 3 — Compression Inclusion

Additional shards may be selected for compression purposes, allowing wallet fragmentation to be reduced opportunistically during normal transactions.

The compression strategy is described in Section 6.4.2.

Step 4 — Capacity Allocation

The engine computes a safe allocation for each selected shard, ensuring that no shard contributes more value than it controls.

Step 5 — Randomized Distribution

Payment value is distributed across multiple shards using randomized allocations.

The final allocation phase deliberately avoids a deterministic "cleanup shard" pattern that could reveal the exact payment amount.

Step 6 — Output Splitting

Payment outputs and change outputs are further divided into multiple randomized allocations.

This creates the many-to-many transaction structure that forms the basis of GhostShard's execution model.

Dust Protection

Every participating shard must produce both:

A payment contribution.
A change contribution.

The protocol therefore enforces a minimum dust threshold to prevent the creation of economically unusable outputs.

Fingerprint Resistance

The construction process avoids deterministic transaction patterns by:

Randomizing shard selection order.
Randomizing payment allocations.
Randomizing output counts.
Avoiding final-shard cleanup behavior.
Shuffling command execution order.

As a result, observers cannot reliably distinguish payment inputs from non-payment inputs.

6.4.2 Compression

Compression is the mechanism used to bound long-term wallet fragmentation.

Because every received payment creates a new shard, wallet shard counts naturally increase over time. Without intervention, transaction costs and local wallet state would grow indefinitely.

Compression reduces this growth by consuming additional shards during ordinary transactions and consolidating their balances into fewer outputs.

Fragmentation Growth

Consider a user who receives 100 independent payments.

Without compression:

100 deposits create 100 shards.
Future transactions require increasingly large input sets.
Execution costs increase with wallet fragmentation.

Compression counteracts this process by gradually reducing shard count whenever transactions are constructed.

Compression Strategy

During coin selection, the SDK may include additional shards beyond those strictly required for payment.

These shards are consumed alongside payment inputs and their balances are redistributed into the transaction's output set.

flowchart LR

    A[Payment Inputs]
    B[Compression Inputs]

    A --> C[Mesh Transaction]
    B --> C

    C --> D[Consolidated Outputs]

Compression therefore occurs naturally during normal wallet activity and requires no dedicated maintenance transaction.

Compression Scaling

The number of compression shards grows sublinearly with wallet size.

Wallet Size	Compression Shards
$\leq 3$	0
$\leq 100$	$\sim \sqrt{n}/2$
$\leq 500$	5--10
$> 500$	8--15

A hard cap prevents compression from dominating transaction costs.

Privacy Benefits

Compression provides several secondary privacy benefits.

Wallet Size Obfuscation

Observers cannot infer total wallet size from the number of inputs participating in a transaction.

Amount Obfuscation

Additional compression inputs increase total transaction value, making it difficult to distinguish payment value from consolidation value.

Output Ambiguity

Compression outputs are indistinguishable from payment outputs once the transaction is constructed.

As a result, observers cannot reliably identify which shards are payment and which are for consolidation.

Atomicity

Compression occurs within the same atomic transaction as payment execution.

If execution fails:

No shards are consumed.
No compression occurs.
No state changes are applied.

Compression therefore inherits the same atomicity guarantees as ordinary transfers.

6.4.3 Mesh Transactions

A mesh transaction is the fundamental execution unit of the GhostShard protocol.

It is a single EIP-7702 transaction that atomically:

Consumes multiple input shards.
Creates multiple output stealth addresses.
Publishes ERC-5564 announcements.
Transfers assets between participants.

The result is a many-to-many transaction structure with no deterministic relationship between inputs and outputs.

flowchart LR

    subgraph Inputs
        S1[Shard A]
        S2[Shard B]
        S3[Shard C]
        S4[Shard D]
    end

    subgraph Mesh
        M[GhostShard Mesh Transaction]
    end

    subgraph Outputs
        O1[Recipient 1]
        O2[Recipient 2]
        O3[Change 1]
        O4[Change 2]
        O5[Change 3]
    end

    S1 --> M
    S2 --> M
    S3 --> M
    S4 --> M

    M --> O1
    M --> O2
    M --> O3
    M --> O4
    M --> O5

Unlike a traditional transfer, no output is funded by a single identifiable input. Every output may contain value originating from multiple shards, while every shard may contribute value to multiple outputs. The observable transaction therefore forms a many-to-many value graph rather than a one-to-one transfer.

Value Redistribution

Coin selection and allocation redistribute value across both payment and change outputs.

flowchart TD

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

    A --> M
    B --> M
    C --> M

    M[Allocation Engine]

    M --> P1[Recipient Output 1]
    M --> P2[Recipient Output 2]

    M --> C1[Change Output 1]
    M --> C2[Change Output 2]
    M --> C3[Change Output 3]

    M --> AN[ERC-5564 Announcements]

Because both payment and change outputs emerge from the same redistribution process, observers cannot reliably determine which outputs represent payments and which represent wallet-controlled change.

Structure

A mesh transaction consists of three payloads.

Authorization List

Each input shard contributes an EIP-7702 authorization.

Every authorization delegates execution to the GhostShard implementation contract.

authorizationList = [
    auth_1,
    auth_2,
    ...
    auth_n
]

Transfer Commands

Transfer commands describe the asset movements to be executed.

Each command specifies:

Source shard.
Asset type.
Token address.
Destination stealth address.
Transfer amount or token identifier.
Shard authorization signature.

Announcements

Each output stealth address receives a corresponding ERC-5564 announcement containing:

The stealth address.
The ephemeral public key.
Encrypted metadata.

Announcements enable recipients to discover outputs during future scans.

Execution Semantics

Mesh transactions execute atomically.

flowchart LR

    A[EIP-7702 Delegations]

    --> B[Pre-scan Validation]

    --> C[Announcement Preparation]

    --> D[Asset Transfers]

    --> E[Settlement]

Execution proceeds as follows:

The EVM applies EIP-7702 delegations.
GhostRouter performs pre-scan validation and shard-spend checks.
Announcements are prepared and queued.
Asset transfers execute.
Settlement finalizes the transaction state.

If any step fails, the entire transaction reverts (apart from the EIP-7702 delegation itself).

No shards are consumed, no announcements are emitted, and no assets move.

Why "Mesh"

The term mesh refers to the transaction's many-to-many structure.

Unlike traditional transfers:

Multiple inputs may fund multiple outputs.
Multiple inputs may contribute to a single recipient.
A single input may contribute to multiple outputs.

There is no observable one-to-one mapping between inputs and outputs.

This combinatorial ambiguity is a core source of privacy within the protocol.

Command Fusion

Before final assembly, compatible transfer commands may be merged.

Commands sharing the same:

Source shard
Asset type
Token
Recipient

can be fused into a single command.

This reduces:

Signature verification overhead.
Transfer execution overhead.
Total transaction gas cost.

ERC-721 transfers are excluded because token identifiers cannot be aggregated.

Ordering Resistance

The SDK randomizes command ordering before submission.

Announcements inherit this randomized ordering.

Consequently, observers cannot distinguish payment outputs from change outputs based solely on transaction position.

Failure Semantics

Mesh transactions are atomic.

If execution fails:

Shard consumption reverts.
Asset transfers revert.
Announcement publication reverts.
Output creation reverts.

Only gas consumed before the revert remains spent.

No partial state transitions can occur.

6.5 Shard Authorization Model

GhostShard requires three independent authorization layers before a mesh transaction can execute:

EIP-7702 delegation, which authorizes executable code on each shard.
Multi-authorization execution, which enables multiple shards to participate in a single atomic transaction.
Transfer authorization, which authorizes specific asset movements from each shard.

Together, these layers ensure that execution authority, transaction participation, and asset transfers are independently validated.

6.5.1 EIP-7702 Delegation

Before a shard can participate in a mesh transaction, it must temporarily delegate execution to the GhostShard implementation contract.

Authorization Creation

For each input shard, the SDK constructs an authorization tuple:

\[ (\text{chainId}, \text{implementation}, \text{nonce}) \]

and signs it using the shard's private key.

The authorization digest is computed as:

\[ H_{\text{7702}}=\operatorname{Keccak256} \left( 0x05 ;|; \operatorname{RLP} ( \text{chainId}, \text{implementation}, \text{nonce} ) \right) \]

where (0x05) is the EIP-7702 transaction type prefix.

The resulting signature ((yParity, r, s)) is included in the transaction's authorization list.

Fixed Nonce Model

GhostShard adopts a UTXO-style ownership model in which every shard may be consumed at most once.

As a result, for v0 authorization nonces remain permanently fixed at:

\[ \text{nonce} = 0 \]

Replay protection is provided by the router's permanent spent-state tracking rather than by sequential account nonces.

On-Chain Processing

When the EIP-7702 transaction is received, the EVM processes the authorization list before executing the transaction body.

For each authorization:

Verify the authorization signature.
Recover the shard address.
Install delegated code
Continue to the next authorization.

After authorization processing completes, every participating shard executes using the delegated GhostShard implementation.

Delegation Persistence

Delegations remain installed until explicitly replaced or cleared.

GhostShard does not require delegation cleanup because spent shards are permanently invalidated through router-enforced spent-state tracking.

This eliminates the need for an additional cleanup transaction and reduces overall execution costs.

6.5.2 Multi-Authorization Execution

A mesh transaction may consume multiple shards simultaneously.

To support this, a single EIP-7702 transaction carries one authorization per input shard.

All authorizations are processed before execution begins, enabling atomic multi-shard execution without requiring specialized bundler infrastructure or account-abstraction entry points.

Authorization Structure

struct Authorization {
    address targetAddress;
    uint32 chainId;
    uint32 nonce;
    uint8 yParity;
    bytes32 r;
    bytes32 s;
}

Every authorization delegates to the same GhostShard implementation contract, while each authorization is signed by a different shard private key.

Transient Storage Deduplication

A single shard may appear in multiple transfer commands within the same mesh transaction.

For example, one shard may fund several payment outputs and several change outputs simultaneously.

To prevent false double-spend detection, GhostRouter uses EIP-1153 transient storage to distinguish:

shards already consumed in a previous transaction; and
shards already processed within the current transaction.

The first occurrence of a shard performs permanent spent-state validation.

Subsequent occurrences within the same transaction are permitted through transient tracking.

This allows a shard to participate in multiple transfer commands while preserving global single-spend guarantees.

Authorization Uniformity

During execution, the router verifies that each shard's delegated implementation matches the implementation authorized by the corresponding EIP-7702 authorization.

This prevents delegated code substitution and guarantees execution consistency across all participating shards.

6.5.3 Transfer Authorization

Delegation authorizes code execution.

Transfer authorization authorizes the specific movement of assets.

Every transfer command is signed independently using the shard's private key under EIP-191.

Command Structure

struct TransferCommand {
    address shard;
    AssetType assetType;
    address token;
    address to;
    uint256 value;
    bytes signature;
    Authorization authorization;
}

Each command represents a single asset transfer originating from a specific shard.

Signature Construction

The SDK constructs a transaction-specific authorization digest:

\[ H_{\text{cmd}}=\operatorname{Keccak256} \Big( \text{chainId}, \text{router}, \text{shard}, \text{assetType}, \text{token}, \text{recipient}, \text{value}, \text{announcements} \Big) \]

The shard private key signs this digest using EIP-191.

Announcement Binding

The complete announcement set is included in the signed payload.

As a result, a valid transfer authorization is inseparable from the stealth addresses and encrypted metadata created during transaction construction.

An attacker cannot modify announcement data, substitute recipients, or redirect outputs without invalidating the signature.

Domain Separation

The inclusion of:

chainId, and
router

provides domain separation.

This prevents:

cross-chain replay attacks;
cross-router replay attacks; and
accidental interpretation as a valid Ethereum transaction.

On-Chain Verification

During execution, GhostRouter performs the following validation steps:

Reconstruct the command digest.
Apply the EIP-191 message prefix.
Recover the signing address.
Verify that the recovered address equals the command's shard address.

If verification fails, execution reverts immediately.

Command Fusion

After transaction construction, commands sharing the same:

\[ (\text{shard},\ \text{assetType},\ \text{token},\ \text{recipient}) \]

may be merged into a single command by summing transfer amounts.

Fusion reduces signature verification costs and transfer overhead while preserving execution semantics.

ERC-721 commands are excluded from fusion because token identifiers are non-additive.

All signatures are produced after fusion, ensuring that the final aggregated transfer amount is cryptographically authorized.

6.6 Sponsored Execution

GhostShard supports sponsored execution, allowing users to submit transactions without maintaining a native gas balance.

Execution sponsorship is provided through two cooperating entities:

Paymasters, which authorize and fund transaction execution.
Relayers, which broadcast transactions and assume execution risk.

Together, these components enable gas abstraction while preserving the protocol's trust-minimized execution model.

6.6.1 Paymaster Authorization

Before a transaction can be relayed, a paymaster must explicitly approve sponsorship.

This approval takes the form of a signed commitment that binds the sponsorship to a specific execution context.

Sponsorship Flow

sequenceDiagram

    participant SDK
    participant Paymaster

    SDK->>Paymaster: Bundle + User Authorization

    Paymaster->>Paymaster: Verify User

    Paymaster->>Paymaster: Double Simulation

    Paymaster->>Paymaster: Construct Sponsorship Hash

    Paymaster-->>SDK: Signed Sponsorship Quote

The process proceeds as follows:

The SDK submits the completed bundle to a paymaster.
The paymaster verifies user eligibility.
The paymaster executes Double Simulation to estimate execution costs.
The paymaster computes a sponsorship commitment.
The paymaster signs the commitment and returns a sponsorship quote.

Sponsorship Commitment

The sponsorship hash commits to the complete execution context:

\[ H_{\text{paymaster}}=\operatorname{Keccak256} \Big( \text{chainId}, \text{router}, \text{commandsHash}, \text{announcementsHash}, \text{validUntil}, \text{limitsHash} \Big) \]

The paymaster signs this hash using EIP-191.

Any modification to the execution context invalidates the sponsorship.

Signature Scope

Field	Purpose
`chainId`	Prevents cross-chain replay
`router`	Prevents cross-contract replay
`commandsHash`	Prevents command modification
`announcementsHash`	Prevents announcement modification
`validUntil`	Limits sponsorship lifetime
`limitsHash`	Prevents gas-limit modification

On-Chain Verification

Before execution begins, GhostRouter validates the sponsorship by:

Verifying the sponsorship has not expired.
Reconstructing the sponsorship hash.
Recovering the signer.
Verifying signer ownership.

Execution proceeds only if all checks succeed.

User Authorization

Paymasters may impose arbitrary sponsorship policies.

The reference implementation uses an allowlist-based model in which users must first obtain sponsorship approval from the paymaster service.

Importantly, paymaster approval does not grant spending authority.

Even a compromised paymaster cannot move user assets because valid shard signatures remain mandatory for every transfer.

6.6.2 Relayer Escrow Accounting

Once a relayer accepts a sponsored transaction, the associated paymaster deposit becomes economically committed before on-chain settlement occurs.

To prevent over-allocation of sponsorship funds, relayers maintain an internal escrow accounting system.

In-Flight Debt Tracking

For each paymaster, the relayer tracks the worst-case cost of all pending transactions:

\[ \text{InFlightDebt}=\sum \text{WorstCaseCost}_i \]

This value represents sponsorship capacity that has been reserved but not yet settled on-chain.

Acceptance Rule

Before accepting a transaction, the relayer verifies:

\[ \text{AvailableCapacity}=\text{Deposit}-\text{InFlightDebt} \]

and requires:

\[ \text{AvailableCapacity} \ge \text{WorstCaseCost} \]

where:

\[ \text{WorstCaseCost}=( G_{\text{verification}} + G_{\text{execution}} + G_{\text{preVerification}} ) \times \text{gasPrice} \]

Transactions that exceed available capacity are rejected.

Escrow Guarantees

This mechanism provides two important guarantees:

No sponsorship over-commitment.
No concurrent double-allocation of paymaster deposits.

A relayer can never reserve more sponsorship capacity than is currently available.

Escrow Release

Reserved capacity is released once execution completes.

The relayer observes the transaction receipt, determines the final settlement outcome, and removes the corresponding reservation from the in-flight debt tracker.

If confirmation is not observed within a predefined timeout window, the reservation is released automatically.

Withdrawal Race Conditions

A paymaster may withdraw funds after sponsorship approval but before execution.

In such cases, the router's on-chain deposit checks remain authoritative.

If insufficient funds remain available, execution reverts before settlement occurs.

6.6.3 Gas Settlement

Gas settlement is the final stage of sponsored execution.

After mesh execution completes, GhostRouter reconciles actual gas consumption against the prefunded sponsorship amount.

Prefunding

Before execution begins, the router reserves the maximum potential execution cost:

\[ \text{Prefund}=( G_{\text{verification}} + G_{\text{execution}} + G_{\text{preVerification}} ) \times \text{gasPrice} \]

This amount is temporarily deducted from the sponsoring paymaster's deposit.

Cost Measurement

After execution completes, the router computes actual gas consumption:

\[ \text{TotalGasUsed}=( G_{\text{start}}-G_{\text{end}} ) + G_{\text{overhead}} + G_{\text{preVerification}} \]

The corresponding settlement cost is:

\[ \text{TotalGasCost}=\text{TotalGasUsed} \times \text{gasPrice} \]

Settlement Bound

Settlement is capped by the prefunded amount:

\[ \text{TotalGasCost} \le \text{Prefund} \]

A paymaster can never lose more than the amount reserved prior to execution.

Surplus Recovery

Unused sponsorship capacity is returned to the paymaster:

$$ \text{Refund}=\text{Prefund}

\text{TotalGasCost} $$

This mechanism prevents overcharging while allowing conservative gas estimation.

Relayer Compensation

After settlement is finalized, the relayer receives reimbursement equal to the measured execution cost.

Settlement follows a strict checks-effects-interactions ordering:

Validate execution.
Update accounting state.
Compute refunds.
Compensate the relayer.

This prevents re-entrancy during settlement.

Execution Records

Every execution produces a settlement record containing:

Relayer identity
Paymaster identity
Total gas consumed
Total gas cost
Inner execution metrics
Execution status
Revert information (if applicable)

These records provide an auditable history of sponsored execution.

Failed Execution

Inner mesh execution may fail for several reasons:

A shard has already been spent.
A shard signature is invalid.
Transfer validation fails.
Asset transfer execution fails.
Announcement validation fails.

When this occurs:

All transfer operations revert.
All announcement operations revert.
All spent-state updates revert.
No user assets move.
No new shards are created.

However, the outer router execution continues.

The router still measures gas consumption, performs settlement, refunds any unused prefund, and reimburses the relayer.

As a result, failed execution remains economically chargeable.

6.7 Simulation Pipeline

GhostShard replaces heuristic gas estimation with a simulation-driven execution model.

Before a transaction is approved or broadcast, both the paymaster and relayer independently simulate execution. This approach allows gas limits to be derived from actual protocol behavior rather than static estimates, improving accuracy while reducing the risk of underfunded execution.

This section describes the Double Simulation engine used for gas estimation and the relayer-side simulation process used for execution validation.

6.7.1 Double Simulation

GhostShard v0 derives gas limits through native node simulation rather than heuristic gas formulas.

Motivation

Traditional gas estimators often rely on hardcoded models of the form:

gas =
baseCost
+ perShardCost × shardCount
+ perCommandCost × commandCount
+ ...

Such approaches require protocol-specific gas accounting logic that must be maintained as contracts evolve, gas schedules change, and execution environments differ across networks.

GhostShard aims to remain compatible with existing EVM infrastructure while avoiding unnecessary protocol complexity. Rather than maintaining custom estimation formulas, the protocol derives gas limits directly from node execution through simulation.

This approach provides a simpler operational model, automatically adapts to future protocol upgrades, and captures chain-specific costs such as rollup data fees without requiring continual recalibration of estimation heuristics.

Architecture

The Double Simulation engine performs two independent simulations, one with state overrides.

Simulation 1 — Execution Simulation

eth_call

The Router returns the following:

Inner mesh gas used $$(G_{\text{inner}})$$
Contract level gas used $$(G_{\text{execution}})$$

Measures pure EVM execution costs, including:

Signature verification
Delegation integrity checks
Transient storage operations
Asset transfer execution
ERC-5564 announcement processing

Simulation 2 — Total Cost Simulation

eth_estimateGas

derives:

The total node level gas $$(G_{\text{totalEstimate}})$$

Measures the complete node-level transaction cost, including:

EVM execution
EIP-7702 authorization overhead
Calldata costs
L1 data fees on rollups(If applicable)
Client-specific transaction overhead

Gas Layer Separation

Combining the two simulations isolates the major gas components.

Pre-verification overhead is derived as:

\[ G_{\text{preVerification}}=G_{\text{totalEstimate}}-G_{\text{execution}} \]

Verification overhead is derived as:

\[ G_{\text{verification}}=G_{\text{execution}}-G_{\text{inner}} \]

The execution gas limit is then computed as:

\[ G_{\text{call}}=1.3 \times G_{\text{inner}} + 40{,}000 \]

The 30% multiplier provides tolerance for minor execution variance, while the fixed buffer accounts for storage initialization and settlement overhead.

State Overrides

Both simulations execute against identical temporary state overrides.

Synthetic Relayer Balance

A temporary balance is assigned to the simulated relayer address, ensuring sponsorship checks cannot fail due to insufficient funds.

Delegation Overrides

Input shard accounts are temporarily assigned delegated runtime code:

0xef0100 || SHARD_IMPLEMENTATION

This reproduces the post-authorization execution environment without modifying chain state.

Properties

The Double Simulation architecture provides several advantages.

Execution Accuracy

Gas limits are derived from actual execution behavior rather than heuristic assumptions.

Protocol Adaptability

Gas schedule changes automatically propagate into estimates without requiring protocol updates.

Rollup Compatibility

Network-specific costs such as calldata pricing and L1 settlement fees are captured automatically.

Deterministic Estimation

Paymasters and relayers execute the same simulation pipeline and therefore derive identical gas parameters.

Limitations

Simulation remains an approximation of future execution.

Minor differences may arise from storage warming effects, state changes between simulation and inclusion, or client-specific execution details.

The execution cushion is intended to absorb these variations.

6.7.2 Relayer Simulation

Before broadcasting a transaction, the relayer independently validates that execution is expected to succeed.

This simulation serves as a relayer-side safety mechanism and is separate from paymaster gas estimation.

Execution Validation

The relayer performs an execution simulation using the same state-override environment employed by the Double Simulation engine.

The simulation verifies that:

Delegation integrity checks succeed.
Sponsorship validation succeeds.
Transfer signatures are valid.
Mesh execution completes without reverting.

Transactions that fail simulation are rejected before broadcast.

This prevents relayers from submitting transactions that are known to fail.

FIFO Scheduling

Accepted transactions are inserted into a first-in-first-out execution queue.

Transactions are broadcast sequentially rather than concurrently.

This design:

Prevents relayer nonce conflicts.
Simplifies sponsorship accounting.
Eliminates relayer-side transaction reordering.

Receipt tracking occurs asynchronously after broadcast.

A background process monitors transaction confirmation and updates sponsorship accounting independently of queue execution.

Private Transaction Submission

Transactions are broadcast through private RPC infrastructure whenever available.

Private submission reduces exposure to public mempool observers and mitigates front-running and transaction-copying attacks.

Examples include builder-connected RPC endpoints and private order-flow networks.

Censorship Resistance

Relayers are not trusted for liveness.

A relayer may refuse to broadcast a transaction, delay execution, or selectively censor users.

GhostShard mitigates these risks through multiple submission paths:

Users may submit to multiple relayers simultaneously.
Users may self-relay transactions directly.
Users may resubmit transactions if expected inclusion does not occur.

As a result, relayers can delay execution but cannot prevent users from eventually reaching the network.

Relayer Protection

Relayer simulation serves a defensive purpose.

By validating execution before broadcast, relayers avoid submitting transactions that would immediately fail validation.

This reduces unnecessary network load, protects sponsorship capacity, and prevents avoidable execution failures from entering the relay queue.

6.8 Chapter Summary

GhostShard executes transactions through atomic mesh execution built on EIP-7702 delegation.

Transaction construction begins with coin selection, compression, and mesh assembly inside the SDK. Input shards authorize execution through EIP-7702 delegations and transfer signatures, while paymasters and relayers coordinate sponsored execution.

On-chain, GhostRouter validates authorizations, verifies delegation integrity, coordinates announcements, executes transfers through delegated GhostShard implementations, and settles gas sponsorships. All execution occurs atomically: if any validation, announcement, or transfer fails, the entire transaction reverts.

To support reliable sponsored execution, GhostShard employs simulation-driven gas estimation rather than heuristic gas models. Paymasters and relayers independently simulate transactions before approval and broadcast, ensuring that execution limits closely reflect actual network costs.

Together, these components transform GhostShard's ownership model into an executable privacy-preserving transaction system while maintaining self-custody, atomicity, and compatibility with existing EVM infrastructure.

Wallet Size	Compression Shards
\(\leq 3\)	0
\(\leq 100\)	\(\sim \sqrt{n}/2\)
\(\leq 500\)	5--10
\(> 500\)	8--15