14. Appendices

Reference material that would interrupt the flow of the main paper but is essential for reproducibility, verification, and deep understanding of the protocol.

Appendix Structure

Appendix	File	Description
A — Protocol Parameters	`01-protocol-parameters.md`	Constants, thresholds, caps, derivation paths, scheme IDs
B — Gas Measurement Dataset	`02-gas-measurement-dataset.md`	Raw benchmark data for all 22 measured transactions
C — Threat Model Assumptions	`03-threat-model-assumptions.md`	Explicit security assumptions
D — Example Mesh Transaction	`04-example-mesh-transaction.md`	Step-by-step walkthrough with diagram description
E — ERC-5564 Announcement Format	`05-erc5564-announcement-format.md`	Binary layout and example announcement
F — Glossary	`06-glossary.md`	Terms used throughout the paper
## Appendix A — Protocol Parameters

Constants, thresholds, caps, and derivation paths that define GhostShard v0 behavior. A reviewer should be able to reproduce protocol behavior from this appendix.

A.1 Deployment Parameters

Parameter	Value	Description
Chain	Arbitrum Sepolia (421614)	Testnet deployment
GhostRouter	`0x6f67E047D1Fe5de0b62b187c28dB1cf1F4f560fb`	Singleton execution coordinator
GhostShard	`0x295549A545E41af6cbCe09AbF012de172AC321AE`	EIP-7702 delegation target
ERC-5564 Announcer	`0x55649E01B5Df198D18D95b5cc5051630cfD45564`	Announcement publisher
Solidity Version	0.8.24^	Compiler version (GhostRouter, GhostShard)
Solidity Version	0.8.23	Compiler version (ERC-5564 Announcer)
Optimizer Runs	200	Solidity optimizer setting

A.2 CREATE2 Salts

Contract	Salt	Notes
GhostRouter	`0x...`	Deterministic deployment address
GhostShard	`0x...`	Deterministic deployment address

Full salt values to be published upon mainnet deployment.

A.3 Dust Thresholds

Parameter	Value	Description
`minDustThreshold`	10,000 wei	Fixed minimum output value (v0)

Planned: Per-token dust thresholds derived from paymaster quotes (see Section 2.8).

A.4 Compression Caps

Parameter	Value	Description
`extraShards` formula	`random(floor(sqrt(walletSize) * 0.8))`	Compression shard count
Hard cap	15	Maximum compression shards per transaction

A.5 Transaction Limits

Parameter	Value	Description
Max transfer commands (`N_t`)	29	Largest measured transaction
Max input shards (`N_i`)	9	Largest measured transaction
Max output announcements (`N_o`)	8	Largest measured transaction
Max fee per gas	`baseFee * 2 + 1.5 gwei`	Fixed gas price strategy (v0)

A.6 Viewing Key Derivation Paths

Key	HKDF Info String	Purpose
Spending Key	`"ghost-shard-spending-key"`	Shard ownership, transfer authorization
Viewing Key	`"ghost-shard-viewing-key"`	Announcement discovery, metadata decryption
DB Encryption Key	`"ghost-shard-db-encryption-key"`	Local storage encryption
Metadata Key	`"ghost-shard-metadata"`	Announcement metadata encryption
Ephemeral Key	`"ghost-shard-ephemeral"`	Deterministic ephemeral key derivation (planned)
Audit Key	`"ghost-shard-audit-key"`	Time-bounded viewing key derivation (planned)

All derived via HKDF-SHA256(rootSeed, info).

A.7 Scheme IDs

Scheme ID	Scheme	Curve	Status
1	ERC-5564 Stealth Address	secp256k1	v0

Additional scheme IDs may be registered for post-quantum alternatives (see Section 10.9.7).

A.8 Asset Type Encoding

Value	Asset Type
0	Native ETH
1	ERC-20
2	ERC-721

A.9 Gas Settlement Constants

Parameter	Value	Description
`POST_EXECUTION_OVERHEAD`	Protocol-defined	Fixed allowance for settlement gas
Execution cushion	`1.3 × G_inner + 40,000`	Gas limit multiplier from Double Simulation
Escrow timeout	120 seconds	In-flight debt release timeout
## Appendix B — Gas Measurement Dataset

Raw benchmark data for all 22 measured mesh transactions on Arbitrum Sepolia. This dataset underlies the analysis presented in Chapter 11. All transactions can be independently verified using the provided transaction hashes.

B.1 Complete Transaction Data

Tx ID	Tx Hash	Asset	N_t	N_o	G_pre	G_ver	G_exe	G_total
TX-01	`0x87b43dbce90687e6ad96d013925dee478d8e15678bce7ca78ec2b8c874a89a43`	ERC-20	11	4	198,057	160,502	532,227	890,786
TX-02	`0x25f476cb1b63ac14c0f983edfe0af9bfba8cb5ae6f8afd206dce395475da2f98`	ERC-20	11	5	212,100	163,929	584,556	960,585
TX-03	`0xc67865e17fce55b2c286e6569b4034eee6129dcfb763b5e7277fd4aedb2fa8d4`	ERC-20	18	5	309,746	232,601	830,770	1,373,117
TX-04	`0x69894eac8c0d6be406f505b527332d9e94330b0e1c4783922267fc0423af2019`	ERC-20	10	5	208,378	154,139	557,482	919,999
TX-05	`0x77cbeb852876df808d88c6354259f2655b1f058cd1d1846d07ea8b8454daecf0`	ERC-20	14	5	285,254	193,330	722,067	1,200,651
TX-06	`0x44d4ee559ba734895cf72289f08a5fff130f317a1fa855faad6e8e359a069f93`	ERC-20	17	5	326,604	222,776	831,657	1,381,037
TX-07	`0xc166ba4a86bc37492e0fc378c48ae695c21094d978e76434ffaa6a497cd6ad30`	ERC-20	19	3	379,519	235,530	808,876	1,423,925
TX-08	`0x29c67796e35b584e3acc1d4546831f7f5504e5a8f9d1ba8690b86e802350c0c8`	ERC-20	29	6	455,238	344,502	1,301,237	2,100,977
TX-09	`0x543ee862c58e4772b6af4ec53b93c07c18df09dab367dc729f710808f96c9f58`	ERC-20	12	5	227,236	173,724	611,648	1,012,608
TX-10	`0xca2b3a9e48c7272699c8218b90a1c59df3e696c80f358956ddc6a4dd7ab6e069`	ERC-20	21	6	327,216	265,569	983,147	1,575,932
TX-11	`0xbd8aeda8dc43e66ee6363d63d5b91008a6e00f91a3f797f1e3545d424462e212`	NATIVE	17	5	247,675	222,776	824,118	1,294,569
TX-12	`0xf246a76632252221301d9cdf391c4363e2fe4376a4bb053e30e144d0dc310855`	NATIVE	11	5	206,516	163,929	629,579	1,000,024
TX-13	`0xfe3255a6ce5ca785a70232a0834004bc8ae654f0da2c009f72dba095af229b9f`	NATIVE	12	6	202,134	177,156	694,568	1,073,858
TX-14	`0x3feb3ae84570d659007bbe2a727764e68f4f75d40996258f6b199a9eb2c35bc5`	NATIVE	9	5	171,313	144,354	549,354	865,021
TX-15	`0xf9162951f6d807e19cb4b841fb697fe9390c202c177358b6e7a40995b6730d5b`	NATIVE	12	3	200,331	166,865	538,710	905,906
TX-16	`0x8c422f4e50288030f6638f98a62d63588a437c0204a2f71ac37bc34d3138d82a`	NATIVE	23	8	319,599	292,210	1,260,029	1,871,838
TX-17	`0xec9871e10fcb1e0d4520aa1249d9f3c48938bb3b730b6f0a3be277c82dbe8dda`	NATIVE	12	4	201,816	170,294	598,358	970,468
TX-18	`0x911e33f82b7d759fca8809834c4733d52d0a29a127b5870c2ee45a3d0316df0d`	NATIVE	9	4	183,053	140,933	518,273	842,259
TX-19	`0xfcb413a7a95e81bd6aa01b70dcc1d016244c025d74e1a40e63b1f14a9efbb3cd`	NATIVE	22	7	304,924	278,883	1,147,087	1,730,894
TX-20	`0x472fd8f5ca7c78a7babd541c9aa67bdb6f427ca3d1b5986940a7a78409487055`	NATIVE	13	4	208,173	180,091	625,079	1,013,343
TX-21	`0x408b036b08a3bbcfdf047149bf925c237e6ddbcfbe82b520f8c50390819b24b4`	ERC-721	1	1	79,520	52,681	98,909	231,110
TX-22	`0x30dc24e76cd4329aa7ee9032251ef50f7f77cc063c16300314a8e9ca7d4d4eaf`	ERC-721	1	1	81,120	52,681	98,909	232,710

B.2 Measurement Methodology

All measurements were obtained from the MeshExecuted event emitted during execution.

Metric	Symbol	Description
Total Gas	G_total	Total transaction gas consumed
Contract Gas	G_contract	Gas consumed inside GhostRouter
Execution Gas	G_execution	Gas consumed inside innerExecuteMesh()
Transfer Commands	N_t	Number of transfer commands executed
Output Announcements	N_o	Number of ERC-5564 announcements published
Preverification Gas	G_pre	Transaction-level overhead
Verification Gas	G_ver	Protocol validation overhead

Derived quantities:

G_pre = G_total - G_contract

G_ver = G_contract - G_execution

G_execution = directly measured

B.3 Summary Statistics

By Asset Type

Asset	Count	G_total Range	G_execution Range
ERC-20	10	890,786 to 2,100,977	532,227 to 1,301,237
NATIVE	10	842,259 to 1,871,838	518,273 to 1,260,029
ERC-721	2	231,110 to 232,710	98,909

Overall

Metric	Min	Max	Mean
Transfer Commands (N_t)	1	29	12.5
Output Announcements (N_o)	1	8	4.5
Total Gas	231,110	2,100,977	1,137,847
Preverification Gas	79,520	455,238	245,674
Verification Gas	52,681	344,502	190,084
Execution Gas	98,909	1,301,237	738,512

B.4 Regression Models

Relationship	Model	R-squared
Total Gas vs Transfer Commands	G = 194,728 + 67,722 * N_t	0.984
Total Gas vs Output Announcements	G = 103,991 + 221,410 * N_o	0.649
Verification Gas vs Transfer Commands	G_ver = 42,000 + 10,200 * N_t	0.97
Execution Gas vs Transfer Commands	G_exe = 48,000 + 43,500 * N_t	0.99

B.5 Amortization Summary

Metric	1 Transfer	29 Transfers	Improvement
Total Gas per Transfer	approx. 232,000	approx. 72,447	approx. 3.2x
Execution Gas per Transfer	approx. 98,909	approx. 44,870	approx. 2.2x
Verification Gas per Transfer	approx. 52,681	approx. 11,879	approx. 4.4x
Preverification Gas per Transfer	approx. 79,520	approx. 15,698	approx. 5.1x
## Appendix C — Threat Model Assumptions

Explicit security assumptions underlying the GhostShard v0 security analysis (Chapter 10). All security claims in the paper are contingent on these assumptions holding.

C.1 Cryptographic Assumptions

##	Assumption	Primitive	Consequence if Broken
C.1.1	secp256k1 discrete logarithm problem remains hard	ECDSA, ECDH	Shard private keys recoverable; all ownership and authorization broken
C.1.2	Computational Diffie-Hellman (CDH) holds on secp256k1	ECDH	Shared secrets recoverable; stealth addresses linkable to recipients
C.1.3	Keccak-256 preimage resistance	Hashing	Address derivation reversible
C.1.4	SHA-256 preimage and collision resistance	HKDF	Derived keys recoverable from sibling keys
C.1.5	HMAC-SHA256 security	HKDF	Domain separation between derived keys fails
C.1.6	AES-256-GCM satisfies IND-CPA + INT-CTXT	Symmetric encryption	Metadata confidentiality broken; ciphertext forgeable
C.1.7	AES-256 retains ~128-bit security against Grover's algorithm	Symmetric encryption	Post-quantum metadata security maintained

C.2 Protocol Assumptions

##	Assumption	Description
C.2.1	EIP-7702 behaves as specified	Delegation semantics, nonce handling, and authorization processing follow the EIP-7702 specification
C.2.2	Paymaster signatures cannot be forged	Only the legitimate paymaster can produce valid sponsorship quotes
C.2.3	Users protect viewing keys	Viewing key material remains confidential on user devices
C.2.4	Users protect root seeds	Root seed is not extracted by malware, keyloggers, or physical attacks
C.2.5	Relayers may be malicious	Relayers can censor, delay, or observe bundles but cannot forge authorizations
C.2.6	At least one broadcast path is available	Users can always reach the network through some relayer or self-relay
C.2.7	ERC-5564 announcer contract is correct	Announcements are emitted atomically with transfers
C.2.8	CREATE2 deployment is deterministic	GhostRouter and GhostShard deploy at expected addresses on all target chains

C.3 Out-of-Scope Assumptions

The following are explicitly not covered by the v0 security model:

##	Threat	Mitigation Layer
C.3.1	Endpoint compromise (malware, keyloggers)	Operational security
C.3.2	Social engineering and phishing	User education, wallet UI
C.3.3	Physical device theft or coercion	Hardware wallets, duress protocols
C.3.4	Global network surveillance (nation-state)	VPN, Tor, private relay infrastructure
C.3.5	Large-scale fault-tolerant quantum computers	Post-quantum migration (future work)
C.3.6	Malicious wallet interfaces	Wallet audit, user verification
C.3.7	ERC-7702 specification changes	Protocol upgrade (no admin keys in v0)

C.4 Adversary Capability Summary

Adversary Class	Can Observe	Can Modify	Cannot
Passive Observer	All on-chain data	Nothing	Forge signatures, access keys
Active Protocol Participant	Bundles, timing, metadata	Censor, delay	Forge authorizations
Counterparty	Own transaction history	Nothing	View unrelated transactions
Infrastructure	Network metadata, mempool	Reorder, censor	Break cryptography
Economic	Protocol economics	Submit valid txs	Spend without keys
Cryptographic	All public data	Nothing	Break secp256k1, AES-GCM, SHA-256
## Appendix D — Example Mesh Transaction

A complete step-by-step walkthrough of a single mesh transaction, from user intent to on-chain execution. This appendix expands on the abbreviated examples in Chapters 2, 5, and 6.

D.1 Scenario

Alice wants to pay Bob 2.5 ETH privately. Alice's wallet holds 7 shards across 3 ETH denominations. Bob has published his ERC-5564 meta-address.

D.2 Transaction Lifecycle

Step 1 — Coin Selection

Alice's SDK filters her shard pool for Native ETH shards and shuffles them:

Shard	Balance	Selected?
Shard A	0.8 ETH	Yes (payment)
Shard B	1.0 ETH	Yes (payment)
Shard C	0.3 ETH	Yes (compression)
Shard D	0.7 ETH	Yes (payment)
Shard E	0.4 ETH	No
Shard F	1.2 ETH	No
Shard G	0.6 ETH	No

Selected: Shards A, B, C, D (total: 2.8 ETH).

Shard C is included for compression and is not strictly required to satisfy the payment amount.

Step 2 — Allocation Engine

The 2.8 ETH is distributed across payment and change outputs:

Output	Type	Amount	Recipient
Output 1	Payment	1.2 ETH	Bob (stealth shard)
Output 2	Payment	1.3 ETH	Bob (stealth shard)
Output 3	Change	0.15 ETH	Alice (stealth shard)
Output 4	Change	0.15 ETH	Alice (stealth shard)

Payment is split across two outputs to obscure the 2.5 ETH total.

Change is split across two outputs to match the output count.

Step 3 — Stealth Address Generation

For each output, the sender generates a fresh ephemeral keypair and derives a stealth address:

For Output 1 (Bob):

ephemeralPrivate e1 <- random
ephemeralPublic  E1 = e1 * G

sharedSecret
s1 = Keccak256(x(e1 * pk_view_Bob))

shardPublic
pk1 = pk_spend_Bob + s1 * G

shardAddress
A1 = last20(Keccak256(pk1_uncompressed))

The same process is repeated for Outputs 2, 3, and 4.

Each output produces a unique unlinkable stealth address.

Step 4 — Announcement Generation

Each output receives an ERC-5564 announcement:

Announcement 1

schemeId         = 1
stealthAddress   = A1
ephemeralPubKey  = E1
viewTag          = firstByte(s1)
metadata         = AES-256-GCM(K_meta, IV, senderInfo)

senderInfo contains encrypted payment references such as invoice identifiers and memos.

Only Bob can decrypt this information using his viewing key.

Step 5 — Authorization Generation

Each input shard signs two authorizations.

EIP-7702 Authorization

Delegates execution to the GhostShard implementation.

authDigest =
Keccak256(
  0x05 ||
  RLP(chainId, implementation, nonce)
)

authSig =
ECDSA(shardPrivateKey, authDigest)

Transfer Command Signature

Authorizes the specific transfer operation.

cmdDigest =
Keccak256(
  chainId,
  router,
  shard,
  assetType,
  token,
  to,
  value,
  announcements
)

cmdSig =
ECDSA(
  shardPrivateKey,
  EIP-191(cmdDigest)
)

Step 6 — Command Fusion

Commands targeting the same shard and asset type may be merged.

If Shard A funds multiple outputs, the commands can be fused into a single aggregated transfer.

Step 7 — Command Randomization

Transfer commands are shuffled before submission.

Output ordering therefore carries no semantic meaning.

Step 8 — Paymaster Quote

The SDK submits the bundle to a paymaster.

The paymaster:

Verifies Alice's identity.
Runs Double Simulation.
Computes gas limits with an execution cushion.
Signs a sponsorship quote.

Step 9 — Relayer Validation

The relayer:

Checks paymaster escrow sufficiency.
Simulates execution.
Inserts the bundle into the relay queue.
Broadcasts an EIP-7702 transaction.

Step 10 — On-Chain Execution

EVM processes EIP-7702 authorizations

Shard A delegates to GhostShard
Shard B delegates to GhostShard
Shard C delegates to GhostShard
Shard D delegates to GhostShard

GhostRouter.executeMesh()

1. Pre-scan
   - Verify delegated code

2. Prefund
   - Reserve maximum gas cost

3. Validate
   - Verify paymaster quote

4. innerExecuteMesh()

   For each command:

   - Check transient deduplication
   - Verify shard not already spent
   - Mark shard as spent
   - Recover signer
   - Execute transfer

   For each announcement:

   - Validate format
   - Emit ERC-5564 announcement

5. Settlement

   - Measure actual gas
   - Refund surplus
   - Pay relayer

Step 11 — Post-Execution Synchronization

Alice

Alice's SDK:

Removes consumed shards A, B, C, and D.
Adds change shards (Outputs 3 and 4).
Advances the sync cursor.

Bob

Bob's SDK:

Scans new ERC-5564 announcements.
Uses view-tag filtering.
Trial decrypts surviving announcements.
Recovers Outputs 1 and 2.
Adds two new shards (1.2 ETH and 1.3 ETH).

D.3 On-Chain Visibility

Visible	Hidden
Four input shards consumed	Controller of input shards
Four output shards created	Controller of output shards
Four ERC-5564 announcements	Decrypted sender metadata
Relayer as transaction sender	Alice's identity
Total gas consumed	Individual transfer amounts
MeshExecuted event	Which outputs are payment versus change

The observer sees four inputs and four outputs.

There are:

2^4 - 2 = 14

possible partitions of payment outputs and change outputs.

The actual payment of 2.5 ETH spread across two outputs is therefore obscured among many valid interpretations.

Appendix E — ERC-5564 Announcement Format

Binary layout and structure of ERC-5564 stealth address announcements as used by GhostShard v0.

E.1 Meta-Address Format

A meta-address is the public receiving identifier that allows anyone to derive stealth shards for a recipient.

Component	Size	Description
Scheme ID	1 byte	Cryptographic scheme identifier (1 = secp256k1)
Spending Public Key	33 bytes	Compressed secp256k1 point (`pk_spend`)
Viewing Public Key	33 bytes	Compressed secp256k1 point (`pk_view`)
Total	67 bytes

Human-readable encoding (ERC-5564):

st:<chainIdentifier>:0x<schemeId><spendingPubKey><viewingPubKey>

E.2 Announcement Structure

Each mesh transaction output publishes one ERC-5564 announcement.

Plaintext Header (54 bytes)

Offset	Size	Field	Description
0	1 byte	View Tag	First byte of shared secret (scan filter)
1	1 byte	Asset Type	0 = Native, 1 = ERC-20, 2 = ERC-721
2	20 bytes	Token Address	Zero address for native assets
22	32 bytes	Amount / Token ID	Transfer amount (fungible) or token ID (NFT)

Encrypted Section (Variable Length)

Field	Size	Description
IV	12 bytes	AES-256-GCM initialization vector
Ciphertext	Variable	Encrypted `senderInfo` payload
Auth Tag	16 bytes	GCM authentication tag

Metadata Encryption

sharedSecret =
Keccak256(
  x(ephemeralPrivate * pk_view_recipient)
)

K_meta =
HKDF-SHA256(
  sharedSecret,
  "ghost-shard-metadata"
)

(IV, ciphertext, authTag) =
AES-256-GCM(
  K_meta,
  random(96),
  senderInfo
)

Only the intended recipient, possessing sk_view, can derive sharedSecret and decrypt the metadata.

E.3 View Tag Filtering

The view tag enables efficient announcement scanning without performing full ownership verification for every announcement.

Scanning Wallet

1. Read viewTag from announcement
2. Compute candidateSharedSecret
   = sk_view * ephemeralPubKey

3. Compute candidateTag
   = firstByte(
       Keccak256(
         x(candidateSharedSecret)
       )
     )

4. If candidateTag != viewTag
      Skip announcement

5. If candidateTag == viewTag
      Perform full ownership verification

Expected reduction factor:

Approximately 256-to-1 fewer
full ownership checks

E.4 Example Announcement (Hex)

Plaintext Header

View Tag:
0xA7

Asset Type:
0x01 (ERC-20)

Token Address:
0x6B175474E89094C44Da98b954EedeAC495271d0F

Amount:
0x0000000000000000000000000000000000000000000000010A7C...

Encrypted Section

IV:
0x3F2A...

Ciphertext:
0x8B71...

Authentication Tag:
0xE4C9...

E.5 Announcement Lifecycle

1. Sender derives stealth address
   from recipient meta-address

2. Sender generates ephemeral keypair
   (e, E)

3. Sender computes shared secret
   using ECDH

4. Sender encrypts metadata
   using an HKDF-derived key

5. Sender publishes announcement
   together with the transfer

6. Recipient scans announcements

7. Recipient reconstructs
   the shared secret

8. Recipient decrypts metadata

9. Recipient adds the discovered
   shard to local wallet state

E.6 Compatibility

GhostShard uses ERC-5564 Scheme ID 1 (secp256k1).

The scheme ID field allows future migration to alternative cryptographic schemes without modifying the announcement infrastructure.

Examples include:

Post-quantum key exchange schemes
Hybrid secp256k1 plus post-quantum deployments
Future ERC-5564-compatible cryptographic systems

Dual-scheme announcements, where both secp256k1 and post-quantum announcements are published for the same recipient, remain compatible with the ERC-5564 announcement model.

Appendix F — Glossary

Terms used throughout the paper, organized by category.

Core Concepts

Term	Definition
Shard	A one-time-use stealth address (standard EOA) that holds assets. Created when value is received, consumed when spent, permanently retired after use. Has no contract code and no identifiable bytecode.
Mesh Transaction	A single atomic EIP-7702 transaction that consumes N_i input shards, creates N_o output shards, and publishes N_o encrypted announcements. Inputs and outputs have no observable one-to-one mapping.
Disposable Ownership	The property that ownership units (shards) exist for a single ownership cycle and are permanently retired. No persistent address accumulates history.
Ownership Topology	The structure of who owns what on a ledger. GhostShard operates at this layer by making ownership relationships ambiguous rather than concealing individual transactions.
Privacy Set	The set of participants among which an individual is indistinguishable. In GhostShard, the privacy set is all protocol participants by default.

Cryptographic Primitives

Term	Definition
Meta-Address	A reusable public receiving identifier (ERC-5564 format) consisting of a spending public key and a viewing public key. Does not hold assets; used only to derive stealth shards.
Stealth Address	A one-time address derived from a meta-address via ECDH. Each transfer produces a unique, unlinkable address.
Ephemeral Key	A fresh keypair generated by the sender for each transfer. The ephemeral public key is published in the announcement; the private key is discarded after use.
View Tag	The first byte of the ECDH shared secret, stored in plaintext in announcements. Enables an approximately 256-to-1 reduction in ownership checks during scanning.
ECDH	Elliptic Curve Diffie-Hellman key exchange. Used to derive shared secrets between sender and recipient without communication.
Root Seed	The 256-bit master secret derived from an EIP-712 identity signature. All protocol keys are deterministically derived from the root seed via HKDF-SHA256.

Keys

Term	Definition
Spending Key (sk_spend)	Private key that controls shard ownership and authorizes transfers. Derived from the root seed via `HKDF(rootSeed, "ghost-shard-spending-key")`.
Viewing Key (sk_view)	Private key that enables announcement discovery and metadata decryption. Does not grant spending authority. Derived from the root seed via `HKDF(rootSeed, "ghost-shard-viewing-key")`.
DB Encryption Key (K_db)	Symmetric key for encrypting local wallet storage. Derived from the root seed via `HKDF(rootSeed, "ghost-shard-db-encryption-key")`.
Metadata Key (K_meta)	Per-transaction symmetric key for encrypting announcement metadata. Derived from the ECDH shared secret via `HKDF(sharedSecret, "ghost-shard-metadata")`.
Shard Private Key (sk_shard)	The private key controlling a specific stealth shard. Computed as `(sk_spend + s) mod n`, where `s` is the shared-secret scalar. Only the recipient can derive this key.

Protocol Components

Term	Definition
GhostRouter	The singleton on-chain execution coordinator. Validates authorizations, verifies delegation integrity, coordinates announcements, executes transfers, and settles gas. Immutable and adminless.
GhostShard	The EIP-7702 delegation target. Contains only asset-transfer logic (native assets, ERC-20, ERC-721). Callable only through GhostRouter.
ERC-5564 Announcer	On-chain contract responsible for publishing stealth-address announcements.
GhostShard SDK	Off-chain client library handling key management, shard discovery, coin selection, transaction construction, and synchronization.
Paymaster	Off-chain service that sponsors transaction execution. Maintains ETH deposits in GhostRouter, verifies users, simulates execution, and signs gas quotes.
Relayer	Off-chain service that broadcasts signed mesh transactions to the network. Can censor transactions but cannot steal or modify funds.
Double Simulation	Gas-estimation pipeline consisting of `eth_call` and `eth_estimateGas`. Used to isolate preverification, verification, and execution gas components.

Transaction Structure

Term	Definition
Transfer Command	A signed instruction specifying source shard, asset type, token, destination address, transfer amount, and authorization.
Authorization (EIP-7702)	A shard's delegation of execution authority to the GhostShard implementation contract. Processed by the EVM before transaction execution.
Announcement	An ERC-5564 event containing a stealth address, ephemeral public key, view tag, and encrypted metadata.
Command Fusion	Merging multiple transfer commands targeting the same shard, asset, and recipient into a single command. ERC-721 commands are never fused.
N_t	Number of transfer commands executed in a mesh transaction.
N_i	Number of input shards consumed.
N_o	Number of output shards created and announcements published.

Coin Selection and Compression

Term	Definition
Coin Selection	The algorithm that determines which shards participate in a transaction. Optimizes for privacy, efficiency, and compression simultaneously.
Compression	Consuming additional shards beyond those strictly needed for payment in order to reduce long-term wallet fragmentation.
Compression Shards	Shards included for consolidation rather than payment. Scales sublinearly with wallet size and is capped.
Dust Threshold	The minimum output value below which a shard becomes economically unrecoverable.
Wallet-Size Obfuscation	The property that observers cannot infer total wallet size from a single transaction because compression selection is randomized and non-linear.

Gas Decomposition

Term	Definition
G_total	Total transaction gas consumed.
G_preverification	Transaction-level overhead including EIP-7702 authorization processing, calldata, and node overhead.
G_verification	Gas spent on protocol validation, including signatures, delegation checks, paymaster validation, and replay protection.
G_execution	Gas spent on productive work such as transfers, announcements, and settlement.
Amortization	Reduction in effective gas per transfer as bundle size increases and fixed costs are spread across more work.

Privacy and Security

Term	Definition
Recipient-Change Ambiguity	Observers cannot determine which outputs represent payments and which represent change. For N_o outputs, there are `(2^N_o) - 2` possible partitions.
Ownership Unlinkability	Observers cannot reliably determine which shards belong to the same owner.
Selective Disclosure	Ability to prove specific transactions without exposing unrelated financial activity.
Disclosure Tier	Level of visibility granted to an auditor. Tier 1: single transaction. Tier 2: bounded historical disclosure. Tier 3: full viewing-key access.
Viewing Key Rotation	Time-bounded derivation of sub-keys from the root viewing key. Planned but not implemented.
Replay Resistance	Prevents reuse of valid authorizations through spent-shard tracking, chain-scoped authorizations, and paymaster binding.
Censorship Resistance	Users retain the ability to transact even if individual relayers refuse service.

Economic Terms

Term	Definition
Gas Sponsorship	A paymaster covers transaction gas costs so users do not need ETH inside their shards.
Paymaster Deposit	ETH held in GhostRouter backing sponsored transactions.
Escrow Accounting	Relayer-side tracking of in-flight transaction liability.
Relayer Margin	Difference between conservative paymaster gas estimates and relayer execution estimates.
Paymaster Staking	Separate economic bond backing slashing and long-term commitment. Planned.

Standards and EIPs

Term	Definition
EIP-712	Signed Typed Data standard used to derive the root seed.
EIP-191	Signed Message standard used for transfer-command and paymaster-quote signatures.
EIP-7702	Temporary Account Abstraction via authorization lists. Enables atomic multi-shard execution.
EIP-1153	Transient Storage Opcodes (`TLOAD`, `TSTORE`). Used to prevent false double-spend detection within a transaction.
EIP-1559	Fee-market mechanism based on base fee and priority fee.
ERC-20	Fungible Token Standard supported natively by GhostShard.
ERC-721	Non-Fungible Token Standard supported natively by GhostShard.
ERC-5564	Stealth Address Standard defining meta-addresses and announcements. GhostShard uses Scheme ID 1.
ERC-6538	Optional registry mapping EOAs to stealth meta-addresses.
ERC-4337	Account Abstraction architecture. GhostShard does not use ERC-4337 due to its single-sender execution model.
ERC-1155	Multi-token standard not currently supported by GhostShard v0.