7. Economic Model

GhostShard is designed not only as a privacy protocol, but also as an economically sustainable system.

While cryptographic mechanisms establish ownership, authorization, and privacy, the long-term viability of the protocol depends on aligning the incentives of its participants. Users, paymasters, and relayers must each have clear economic motivations to participate, while the costs and risks associated with protocol operation remain predictable and bounded.

This chapter examines the economic structure of GhostShard, including sponsored execution, relayer incentives, paymaster funding, cost allocation, and risk management. The objective is to ensure that protocol participation remains practical, sustainable, and economically rational for all actors.

Economic Principles

The GhostShard economic model is designed around four core principles.

1. Rational Participation

Protocol participants should maximize expected utility by following the protocol rather than deviating from it.

Users obtain privacy and usability benefits, paymasters control sponsorship policies, and relayers receive compensation for transaction inclusion. The protocol is structured so that honest participation provides the clearest path to economic benefit.

2. Bounded Economic Exposure

The financial risk faced by any participant should remain predictable and constrained.

Gas sponsorship, relayer reimbursement, and execution settlement are all designed with explicit limits that prevent unbounded losses and allow participants to reason about worst-case outcomes before committing resources.

3. Sustainable Cost Allocation

Execution costs should be allocated transparently to the parties responsible for incurring them.

Sponsored transactions, relayer compensation, and settlement accounting ensure that protocol operation remains economically sustainable without requiring custodial intermediaries, lockups, or protocol-level inflation.

4. Incentive Alignment

The incentives of protocol participants should reinforce the reliability and availability of the system.

Paymasters are incentivized to sponsor legitimate activity, relayers are incentivized to process valid transactions, and users are incentivized to construct transactions that can be executed successfully. The resulting incentive structure promotes efficient protocol operation while minimizing coordination requirements.

Economic Foundations

GhostShard combines several complementary mechanisms to achieve these goals:

Cryptographic guarantees, which prevent unauthorized spending and signature forgery.
Protocol-level constraints, which bound execution outcomes and settlement behavior.
Sponsored execution mechanisms, which enable gas abstraction while maintaining predictable cost allocation.
Market-based participation, which allows relayers and paymasters to operate as independent service providers.

Together, these mechanisms create an ecosystem in which privacy, usability, and economic sustainability reinforce one another.

Status

Component	Status
Paymaster deposit and withdrawal system	Implemented
Relayer reimbursement mechanism	Implemented
Escrow debt accounting	Implemented
Relayer FIFO execution queue	Implemented
Double Simulation gas engine	Implemented
Competitive relay market	Planned
Paymaster staking mechanism	Planned
Decentralized relayer networks	Research
Alternative sponsorship markets	Research

The remainder of this chapter analyzes how these components interact to allocate costs, manage risk, and align incentives across the GhostShard ecosystem.

7.1 Relayer Economics

The relayer is responsible for transaction inclusion.

It receives signed mesh transaction bundles from users, verifies their validity, and broadcasts them to the network. Although the relayer does not participate in asset custody or protocol governance, it plays a critical role in transaction execution and sponsored gas settlement.

Economically, the relayer occupies an unusual position: it initiates transaction submission and temporarily assumes execution risk, but receives reimbursement through the protocol's settlement process.

flowchart LR

    A[User Bundle]
        --> B[Relayer Validation]

    B --> C[Transaction Broadcast]

    C --> D[GhostRouter Settlement]

    D --> E[Relayer Reimbursement]

    E --> F[Relayer Profit Margin]

7.1.1 Reimbursement Mechanism

Relayers are reimbursed through the settlement process executed by the GhostRouter.

After transaction execution completes, the router calculates the final gas cost and transfers the corresponding amount to the transaction submitter (msg.sender), which is the relayer.

(bool callSuccess, ) = msg.sender.call{value: totalGasCost}("");
require(callSuccess, "Bundler fee payment failed");

The reimbursement amount is denominated in the chain's native asset and is bounded by the paymaster prefund established before execution.

As a result, relayers recover the cost of successful transaction execution directly from protocol settlement rather than from users.

7.1.2 Profit Model

Relayer revenue is derived from the difference between conservative sponsorship estimates and actual execution requirements.

Before sponsorship approval, the paymaster computes gas limits using Double Simulation and signs a transaction-specific sponsorship quote.

The signed value includes a preVerificationGas component:

\[ G_{\text{pvg}}^{\text{paymaster}}= G_{\text{totalEstimate}}-G_{\text{execution}} \]

This value accounts for costs that are difficult to predict precisely at signing time, including:

L1 data availability fees
EIP-7702 authorization payload overhead
Calldata-related costs
Network-specific execution overhead

Because these costs can fluctuate between quote generation and transaction inclusion, paymasters typically provision conservatively.

Prior to broadcast, the relayer performs its own simulation and computes an independent estimate:

\[ G_{\text{pvg}}^{\text{relayer}}= G_{\text{totalSimulated}}-G_{\text{executionSimulated}} \]

The difference between these values creates the relayer's execution margin:

\[ M_{\text{relayer}}= G_{\text{pvg}}^{\text{paymaster}}-G_{\text{pvg}}^{\text{relayer}} \]

When network conditions remain stable or improve between sponsorship approval and transaction inclusion, the relayer may realize a positive margin.

The relayer is therefore incentivized to:

Submit valid transactions efficiently.
Broadcast when execution conditions are favorable.
Minimize failed executions.
Maintain accurate simulation infrastructure.

7.1.3 Relayer Risk Management

Relayers assume execution risk and therefore perform independent validation before broadcasting transactions.

flowchart TD

    A[Received Bundle]

    --> B[Escrow Check]

    --> C[Simulation]

    --> D[Gas Validation]

    --> E[Queue Acceptance]

    --> F[Broadcast]

Before accepting a bundle, the relayer verifies:

Escrow Sufficiency

The sponsoring paymaster must possess sufficient available deposit capacity after accounting for all pending transactions.

This prevents acceptance of transactions that cannot be settled.

Execution Validity

The relayer independently simulates execution using the same state-override model used during sponsorship approval.

Transactions predicted to revert are rejected before broadcast.

Gas Adequacy

The relayer verifies that the paymaster's signed gas limits remain sufficient under current network conditions.

If the relayer determines that execution would exceed the approved limits, the transaction is rejected.

Together, these checks reduce the likelihood of executing transactions that would produce economic losses.

7.1.4 Censorship Power

The relayer's primary discretionary power is censorship.

A relayer may refuse to broadcast a valid transaction despite possessing the ability to do so.

The protocol cannot eliminate this possibility, but it minimizes its impact through architectural design.

Multiple Relayers

Bundles are not bound to a specific relayer.

Users may submit identical bundles to multiple relayers simultaneously.

Self-Relay

Users may bypass third-party relayers entirely and submit transactions directly through private RPC infrastructure or block-builder endpoints.

FIFO Processing

The reference implementation processes accepted transactions through a strict FIFO queue.

This limits discretionary reordering within a relayer's local execution pipeline.

Because censorship forfeits potential execution revenue while providing no direct economic benefit, relayers are generally incentivized to process valid transactions rather than ignore them.

7.1.5 Competitive Relay Market

GhostShard is designed to support a competitive relay ecosystem.

Because transaction bundles are self-contained and independently verifiable, any compatible relayer can execute them.

No protocol-level dependency exists on a specific relay operator.

Future relay markets may compete on:

Reliability
Inclusion speed
Geographic distribution
Fee efficiency
Sponsorship partnerships

As relay participation increases, competition naturally encourages improved service quality and reduced execution friction.

In the long term, GhostShard anticipates a heterogeneous relay ecosystem similar to existing block-builder and transaction-relay markets.

7.3 Escrow Accounting

Sponsored execution introduces a settlement timing problem.

When a relayer accepts a mesh transaction, it must determine whether the sponsoring paymaster possesses sufficient funds to cover the transaction's worst-case execution cost. However, the actual execution cost is not known until the transaction has been included and settled on-chain.

Between relay acceptance and on-chain settlement, a portion of the paymaster's deposit is economically committed but not yet charged. During this period, relayers must ensure that sponsorship capacity is not allocated multiple times.

Escrow accounting provides this protection.

7.3.1 In-Flight Debt Tracking

Each relayer maintains an internal accounting structure that tracks the total worst-case liability associated with pending transactions for every paymaster.

The accumulated liability is:

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

where each term represents the maximum potential settlement cost of a pending transaction.

Before accepting a new transaction, the relayer calculates the paymaster's remaining sponsorship capacity:

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

The transaction is accepted only if:

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

where:

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

If the condition holds, the relayer reserves the corresponding capacity and records the transaction as in flight.

flowchart LR

    A[Paymaster Deposit]
        --> B[Subtract In-Flight Debt]

    B --> C[Available Capacity]

    C --> D{Worst-Case Cost Covered?}

    D -->|Yes| E[Accept Transaction]

    D -->|No| F[Reject Transaction]

7.3.2 Economic Guarantees

Escrow accounting provides two important guarantees.

No Over-Allocation

The aggregate worst-case cost of all pending transactions can never exceed the paymaster's available deposit.

As a result, relayers cannot reserve sponsorship capacity that does not exist.

No Concurrent Deposit Reuse

Every accepted transaction immediately reserves capacity before entering the relay queue.

Even if multiple transactions are pending simultaneously, the same deposit balance cannot be allocated more than once.

Together, these guarantees ensure that relay acceptance remains economically conservative.

7.3.3 Escrow Release

Reserved capacity is released once the transaction reaches a terminal state.

After transaction confirmation, the relayer:

Observes the transaction receipt.
Releases the reserved worst-case allocation.
Updates local accounting.

The release process is independent of the actual settlement amount.

Actual gas reconciliation is performed entirely on-chain by GhostRouter. The relayer's escrow system exists solely to prevent over-allocation while transactions remain pending.

To avoid permanent lockups caused by networking failures or missed receipts, relayers may release reservations automatically after a configurable timeout period.

7.3.4 Edge Cases

Failed Execution

If inner mesh execution fails, the transaction still consumes gas and the sponsoring paymaster remains responsible for settlement.

However:

All asset transfers revert.
All announcement operations revert.
All shard-spent state changes revert.

The relayer releases the escrow reservation once the failed receipt is observed.

Delayed Inclusion

A transaction may remain pending longer than expected.

If a timeout policy releases the reservation before inclusion occurs, subsequent on-chain settlement remains correct because sponsorship accounting is ultimately enforced by GhostRouter.

Escrow accounting only influences local relay acceptance decisions.

Deposit Withdrawal During Flight

A paymaster may withdraw funds after a transaction has been accepted but before it has been included.

If the remaining deposit becomes insufficient, the router's on-chain validation rejects execution.

The transaction fails safely, but the relayer may still incur gas costs associated with submission.

This represents the primary economic risk in the v0 sponsorship model.

7.3.5 Future Requirement: Paymaster Staking

The v0 architecture relies entirely on paymaster deposits.

Deposits are sufficient for funding gas costs, but they do not provide relayers with a reliable measure of paymaster trustworthiness.

A paymaster can possess sufficient funds at quote time, withdraw them before inclusion, and cause relayers to expend resources on transactions that ultimately fail.

To support a competitive multi-paymaster ecosystem, future versions of GhostShard will introduce a staking mechanism similar in spirit to the model used by ERC-4337 paymasters.

Importantly, stake and gas deposits serve entirely different purposes.

Property	Gas Deposit	Stake
Purpose	Prefund execution costs	Economic trust signal
Location	GhostRouter	Dedicated staking contract
Used for gas payment	Yes	No
Withdrawable immediately	Yes	No
Subject to withdrawal delay	No	Yes
Subject to slashing	No	Yes

Gas deposits remain operational liquidity used during transaction settlement.

Stake functions as an economic bond that signals long-term commitment and provides backing against harmful behavior.

Under a future staking model:

Paymasters lock stake in a dedicated staking contract.
Stake becomes subject to a withdrawal delay.
Relayers evaluate both deposit sufficiency and stake size before accepting transactions.
Misbehavior that causes relayer losses may result in partial stake slashing.
Larger and longer-duration stakes increase relayer confidence.

flowchart TD

    A[Paymaster]

    A --> B[Gas Deposit]
    A --> C[Stake]

    B --> D[Execution Funding]

    C --> E[Trust Signal]
    C --> F[Slashing Backing]

    E --> G[Relayer Acceptance]
    F --> G

This transforms relay participation from a binary trust decision into a market-driven assessment of economic credibility.

Paymasters seeking greater transaction volume must maintain stronger economic commitments, while relayers gain objective criteria for evaluating sponsorship risk.

7.3 Escrow Accounting

When a relayer accepts a mesh transaction for broadcast, the paymaster's on-chain deposit must cover the transaction's worst-case gas cost. But the relayer does not immediately know the actual cost — it only knows the prefund amount (the maximum). The actual cost is only known after the transaction is included in a block and executed.

This creates a timing problem: between the moment the relayer accepts the transaction and the moment the on-chain reconciliation occurs, the paymaster's deposit is "committed" but not yet charged. During this window, the relayer must ensure it does not over-commit the paymaster's deposit.

7.3.1 In-Flight Debt Accumulator

The relayer maintains an in-memory paymasterDebtAccumulator, which tracks the aggregate worst-case liability of all pending (in-flight) transactions associated with a given paymaster.

For a paymaster \(p\), the accumulated liability is:

\[ \text{InFlightDebt}_p=\sum_{i=1}^{n} \text{WorstCaseCost}_i \]

where each term represents the maximum possible settlement cost of a pending transaction.

Before accepting a new relay request, the relayer computes the paymaster's available sponsorship capacity:

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

The worst-case execution cost of the candidate transaction is:

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

The transaction is accepted only if:

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

If the condition holds, the relayer reserves the corresponding sponsorship capacity by adding the transaction's worst-case cost to the paymaster's in-flight debt accumulator and then enqueues the transaction for execution.

7.3.2 Consistency Guarantees

The escrow accounting system provides two critical guarantees:

No over-commitment. The sum of worst-case costs for all in-flight transactions never exceeds the paymaster's on-chain deposit.
No double-spending of deposits. Each transaction's worstCaseCost is deducted from the net available balance before the transaction is enqueued. Even if two transactions are in flight simultaneously, their combined worst-case costs cannot exceed the deposit.

7.3.3 Escrow Release

The escrow lock is released when the transaction is confirmed on-chain. A background poller watches for the transaction receipt and:

Reads the actual totalGasCost from the MeshExecuted event.
Subtracts worstCaseCost from the in-flight debt accumulator (releasing the lock).
The difference between worstCaseCost and actualCost is the surplus that was returned to the paymaster's deposit on-chain.

If the receipt is not observed within 120 seconds, the escrow lock is released anyway (timeout fallback). This prevents permanent deadlock in case of network issues.

7.3.4 Edge Cases

Transaction reverts. If a transaction reverts, the on-chain prefund is fully returned to the paymaster (the debit is part of the reverted state). The relayer's in-flight debt is released by the background poller when it observes the receipt.

Transaction not mined. If a transaction is not mined within the timeout, the escrow lock is released. The transaction may still be mined later. In this case, the on-chain reconciliation will still work correctly because the prefund debit and surplus refund are handled entirely on-chain.

Paymaster withdrawal during flight. If the paymaster withdraws funds while a transaction is in flight, the on-chain InsufficientPaymasterDeposit check will cause the transaction to revert. The relayer's escrow accounting prevents this in the normal case, but a concurrent withdrawal could create a race condition. The on-chain check is the ultimate safety net.

7.3.5 Future Requirement: Paymaster Staking

The current v0 escrow accounting system relies on a simple deposit model: the paymaster deposits ETH into GhostRouter, and the relayer checks that the deposit covers the worst-case cost. This works for a trusted or known paymaster operator, but it does not scale to a competitive relay market with multiple unknown paymasters.

In a multi-paymaster environment, relayers need a reliable way to assess whether a paymaster is trustworthy before accepting and broadcasting transactions. A paymaster could sign a quote, have sufficient deposit at the time of acceptance, and then withdraw funds before the transaction is included in a block — causing the transaction to revert and costing the relayer gas.

Future versions of GhostShard must implement a paymaster staking mechanism to address this. It is critical to understand that staking is entirely separate from gas deposits — they serve different purposes and exist in different contracts.

Gas deposits (the current v0 model) are held in GhostRouter and are used to prefund transaction gas costs. They are a working balance: debited before execution, refunded after settlement. They can be withdrawn at any time (subject to in-flight debt checks).

Stake is a separate economic bond locked in future router contracts. It is never used to pay for gas. Its sole purpose is to serve as a trust signal and slashing backing. The two balances are independent:

Property	Gas Deposit	Stake
Contract	GhostRouter	Staking contract
Purpose	Prefund gas costs	Trust signal / slashing backing
Withdrawable	Yes (subject to in-flight checks)	Only after withdrawal delay
Consumed by	Transaction execution	Slashing on misbehavior
Amount needed	\(\geq\) worst-case gas cost	Determined by relayer trust requirements

The staking model works as follows:

The paymaster locks a stake in GhostRouter. This stake is entirely distinct from the gas deposit held. The stake cannot be withdrawn immediately — it is subject to a withdrawal delay.
The relayer uses the stake as a trust signal. Before accepting a transaction, the relayer checks two separate things: (a) the paymaster's gas deposit in GhostRouter covers the worst-case cost, and (b) the paymaster's staked amount in the staking contract meets the relayer's minimum trust threshold. A paymaster with a large, long-duration stake is less likely to behave maliciously, because the stake can be slashed if the paymaster causes relayer losses.
Slashing conditions. If a paymaster signs a quote and then withdraws its gas deposit before the transaction is included — causing the transaction to revert and the relayer to lose gas — a portion of the stake (not the gas deposit) is slashed and used to compensate the relayer. The gas deposit and the slashed stake are entirely separate pools of funds.
Stake as a yardstick. The staked amount and withdrawal delay give relayers a concrete metric for deciding which paymasters to trust. A relayer can configure minimum stake requirements and prefer paymasters with larger, longer-duration stakes. This creates a natural market: paymasters who want more relayer volume must stake more and commit to longer durations.

This staking mechanism transforms the relayer's trust decision from a binary "does the deposit cover the cost?" check into a continuous "how trustworthy is this paymaster?" assessment based on separate economic commitment. It is essential for a decentralized, multi-paymaster relay market.

7.4 Chapter Summary

GhostShard's economic model is designed to align the incentives of all protocol participants while ensuring that financial exposure remains bounded throughout execution.

The protocol separates transaction execution from transaction funding through sponsored execution. Users authorize transfers, paymasters provide execution funding, and relayers provide transaction inclusion. Each participant performs a narrowly scoped role with clearly defined incentives and responsibilities.

Economic Roles

Participant	Primary Responsibility	Economic Incentive
User	Authorize asset movement	Obtain privacy-preserving transfers without managing execution infrastructure
Paymaster	Sponsor transaction execution	Support users, applications, or future fee-based sponsorship models
Relayer	Broadcast transactions	Capture execution margin while receiving gas reimbursement

Risk Allocation

The protocol intentionally distributes risk according to participant responsibilities.

Participant	Primary Economic Risk
User	Failed execution of self-funded transactions
Paymaster	Sponsorship costs bounded by prefunded limits
Relayer	Broadcasting transactions that later become unprofitable or invalid

No participant is exposed to unbounded financial liability.

Sponsored execution is constrained through paymaster deposits, escrow accounting, prefunding, and settlement reconciliation. Relayers independently verify execution conditions before broadcasting, while paymasters retain explicit control over sponsorship authorization.

Economic Properties

The resulting system provides four key properties:

Execution costs remain bounded and predictable.
Sponsorship capacity cannot be over-allocated.
Participants retain control over their own economic exposure.
Honest participation is economically preferable to deviation.

These properties allow GhostShard to provide gas abstraction and privacy-preserving transfers without introducing custodial intermediaries, trusted operators, or protocol-level economic dependencies.

Future Evolution

The current v0 model prioritizes simplicity and deployability.

Future versions may introduce:

Paymaster staking mechanisms.
Competitive sponsorship markets.
ERC-20-denominated gas payment systems.
Decentralized relay ecosystems.
Alternative sponsorship and reimbursement models.

These extensions are intended to strengthen market formation and participant incentives without changing the protocol's core execution architecture.

In summary, GhostShard's economic model ensures that transaction execution, sponsorship, and settlement remain economically sustainable while preserving the protocol's broader goals of self-custody, privacy, and compatibility with existing EVM infrastructure.