5. Cryptographic Foundation
5.1 Overview
GhostShard's privacy model is built on a layered cryptographic architecture that combines deterministic identity derivation, stealth addressing, encrypted metadata, and selective disclosure.
Rather than introducing a new cryptographic primitive, GhostShard composes established standards and techniques—including ERC-5564, elliptic-curve Diffie-Hellman (ECDH) key exchange, authenticated encryption, and deterministic key derivation—into a unified ownership model for the EVM.
The cryptographic layer serves four primary purposes:
- Deriving protocol-specific keys from a user's root identity.
- Creating unlinkable stealth ownership units (shards).
- Enabling private recipient discovery and metadata exchange.
- Supporting selective disclosure without exposing unrelated activity.
These mechanisms provide the foundation upon which higher-level protocol properties are built. Recipient privacy, shard ownership, announcement discovery, encrypted asset metadata, and compliance-oriented disclosure all originate from the cryptographic layer.
However, cryptography alone does not provide the complete GhostShard privacy model. Ownership ambiguity, mesh execution, transaction propagation privacy, gas sponsorship, and economic incentives emerge from the protocol architecture described in later chapters.
This chapter follows the lifecycle of a shard from key generation to optional disclosure. It begins with identity and key derivation, proceeds through stealth address creation and discovery, then concludes with metadata protection, selective disclosure mechanisms, and the resulting security properties.
By the end of this chapter, the reader will understand how GhostShard transforms a conventional EVM account into a system capable of private ownership, private discovery, and controlled disclosure while remaining compatible with existing Ethereum infrastructure.
5.2 Identity and Key Hierarchy
The GhostShard cryptographic architecture begins from a single root identity and deterministically derives all protocol keys required for ownership, discovery, viewing, and local data protection.
This design provides three primary properties:
- Recoverability — a single wallet backup is sufficient to recover the entire GhostShard identity.
- Key Separation — spending, viewing, and encryption capabilities remain cryptographically independent.
- Stateless Deployment — no protocol-specific secrets must be stored on-chain or registered with a trusted service.
Every GhostShard user begins with a standard EVM Externally Owned Account (EOA). Through a deterministic derivation process, this EOA becomes the root of the entire GhostShard key hierarchy.
5.2.1 Key Hierarchy Overview
The derivation process can be viewed as a cryptographic tree.
flowchart TD
A[EOA Private Key]
A --> B[EIP-712 Identity Signature]
B --> C[Root Seed]
C --> D[Spending Key]
C --> E[Viewing Key]
C --> F[Database Encryption Key]
D --> G[Stealth Ownership]
E --> H[Shard Discovery]
F --> I[Shard Storage Protection]A single identity signature produces a root seed.
The root seed is expanded into multiple protocol keys through domain-separated key derivation.
Compromise of one derived key does not reveal any other derived key.
5.2.2 Root Identity
GhostShard does not introduce a separate wallet system.
Instead, the user's existing EOA acts as the root cryptographic identity.
To initialize the protocol, the EOA signs a structured EIP-712 message containing its account address and protocol domain parameters.
The resulting signature serves as a deterministic identity proof from which all protocol keys are derived.
Because the signature originates from the user's existing wallet, no additional seed phrase or protocol-specific backup mechanism is required.
5.2.3 Root Seed Derivation
Let
denote the EIP-712 identity signature produced by the user's EOA.
The protocol derives a root seed
by computing
where
is a uniformly distributed 256-bit value.
The signature itself consists of the standard ECDSA tuple
but only the final signature encoding is used as input to the hash function.
The root seed never leaves the client device and is never transmitted or stored on-chain.
5.2.4 Deterministic Key Derivation
GhostShard derives protocol keys from the root seed using HKDF-SHA256.
Let
represent a domain-separated HKDF invocation.
The protocol derives:
Spending Key Material
Viewing Key Material
Database Encryption Key
Distinct context labels provide domain separation between outputs.
Consequently,
are computationally independent despite sharing the same root seed.
5.2.5 Spending Keys
The spending key controls ownership and authorization of GhostShard assets.
The derived key material must be converted into a valid secp256k1 private scalar.
Let
denote the order of the secp256k1 elliptic curve.
The normalized spending key
must satisfy
Invalid outputs are repeatedly hashed until a valid scalar is obtained.
The corresponding public key is
where
is the secp256k1 generator point.
The spending key ultimately controls stealth ownership and authorizes shard spending.
5.2.6 Viewing Keys
The viewing key enables ownership discovery without granting spending authority.
The derived viewing scalar
is normalized in the same manner:
Its public key is
The viewing key is used during ERC-5564 announcement scanning and ownership detection.
Possession of
allows a user to discover assets but does not permit asset movement.
This separation forms the foundation for selective disclosure and auditing workflows.
5.2.7 Database Encryption Keys
GhostShard maintains local metadata describing:
- Discovered shards
- Transaction history
- User labels
- Cached protocol state
This information may contain privacy-sensitive information despite never appearing on-chain.
The database encryption key is derived as
Unlike spending and viewing keys, no elliptic-curve normalization is required.
The key is used directly as symmetric encryption material for storage protection.
5.2.8 Security Properties
Deterministic Recovery
The same identity signature always produces the same root seed:
Recovery therefore requires only access to the original wallet.
No protocol-specific backup procedure is necessary.
Key Separation
Domain-separated HKDF invocations ensure that:
Compromise of one key does not reveal any other derived key.
Minimal Trust Surface
No derived key material is transmitted over the network.
No protocol-specific secrets are stored on-chain.
All derivation occurs locally within the GhostShard SDK.
Wallet Compatibility
Because the root identity originates from a standard EOA signature, GhostShard remains compatible with existing wallets and account-management infrastructure.
5.2.9 Future Extensions
The current implementation derives protocol keys from ECDSA-based identities and secp256k1 cryptography.
Future versions may support:
- Hardware Security Modules (HSMs)
- Trusted Execution Environments (TEEs)
- Multi-signature identity roots
- Post-quantum signature schemes
Because the architecture is built around deterministic key expansion rather than a specific signature algorithm, future identity systems can be introduced without redesigning the remainder of the protocol.
The hierarchy therefore provides a migration path for future cryptographic upgrades while preserving compatibility with existing GhostShard ownership structures.
5.3 Meta-Addresses
A meta-address is a reusable public receiving identifier that allows third parties to derive stealth ownership units for a recipient without learning the recipient's ownership graph.
Unlike a conventional EVM address, a meta-address does not hold assets, sign transactions, or participate directly in protocol execution. Instead, it serves as a cryptographic template from which fresh one-time shard addresses are deterministically derived.
The meta-address is therefore best understood as a receiving identity rather than an ownership identity.
5.3.1 Overview
GhostShard adopts the meta-address construction defined by ERC-5564.
Each user publishes two public keys:
- A spending public key
- A viewing public key
Together these keys form a reusable receiving identifier.
Let
denote the spending public key and
denote the viewing public key.
The user's meta-address is defined as
A sender uses
to derive a unique stealth shard for each transfer.
The recipient uses the corresponding private keys to discover and control the resulting shard.
5.3.2 ERC-5564 Meta-Address Structure
GhostShard v0 uses ERC-5564 Scheme ID 1, which specifies secp256k1 stealth addresses with view tags.
The encoded payload consists of:
where
and both public keys are compressed secp256k1 points.
The resulting binary representation contains:
| Component | Size |
|---|---|
| Scheme ID | 1 byte |
| Spending Public Key | 33 bytes |
| Viewing Public Key | 33 bytes |
for a total payload size of
The human-readable ERC-5564 representation is encoded as
st:<chainIdentifier>:0x<schemeId><spendingPubKey><viewingPubKey>
where the payload is hex encoded.
5.3.3 Public Key Construction
The meta-address is derived from the spending and viewing private keys introduced in Section 5.2.
Let
and
denote the corresponding private scalars.
Their public keys are
and
where
is the secp256k1 generator point.
Both public keys are stored in compressed form before inclusion in the meta-address.
5.3.4 Publishing Meta-Addresses
Meta-addresses may be distributed through either off-chain or on-chain mechanisms.
Off-Chain Distribution
The preferred approach is direct sharing.
Examples include:
- QR codes
- Contact exchange
- Messaging applications
- Application-level address books
Because no on-chain registration occurs, no public relationship exists between the user's EOA and receiving identity.
This provides the strongest privacy guarantees.
ERC-6538 Registration
Users may optionally register their meta-address through the ERC-6538 Registry.
The registry maps an EOA to a meta-address using:
registerKeys(
uint256 schemeId,
bytes stealthMetaAddress
)
Registration simplifies discovery but introduces an explicit public link between:
This trade-off improves usability at the cost of additional public metadata.
GhostShard therefore treats registration as optional rather than mandatory.
5.3.5 Receiving Identity Separation
A fundamental property of the design is the separation between receiving identities and ownership identities.
The meta-address itself:
- Cannot hold assets
- Cannot authorize transactions
- Cannot execute protocol actions
- Cannot spend shards
Its sole purpose is the derivation of future ownership units.
This separation ensures that publication of a meta-address does not expose any spendable asset.
Even complete knowledge of
provides no ability to control shards.
Only possession of the corresponding private keys grants ownership.
5.3.6 Dual-Key Architecture
GhostShard inherits ERC-5564's dual-key model.
The spending key and viewing key serve distinct purposes.
The spending key participates in stealth ownership generation.
The viewing key participates in recipient discovery.
Formally,
and
with both keys derived independently through the domain-separated hierarchy described in Section 5.2.
This separation ensures that ownership discovery and asset spending remain independent capabilities.
Consequently:
- Discovery authority does not imply spending authority.
- Spending authority does not reveal viewing secrets.
- Auditing workflows can be implemented without exposing ownership control.
This property becomes important for selective disclosure mechanisms introduced later in this chapter.
5.3.7 Privacy Properties
Meta-addresses provide several important privacy guarantees.
Reusable Receiving Identity
A single meta-address can safely receive an unlimited number of transfers.
Each transfer produces a distinct stealth shard.
Observers cannot determine whether two shards originated from the same meta-address.
Recipient Unlinkability
Given a stealth shard address
an observer cannot efficiently determine which recipient meta-address generated it.
The derivation process requires knowledge of private viewing material unavailable to third parties.
No Ownership Exposure
The meta-address itself never appears as the owner of any asset.
Only derived shards hold assets.
Ownership therefore remains separated from public receiving identities.
Optional Public Discoverability
Users may choose whether to register their meta-address publicly.
This allows privacy and usability requirements to be balanced according to application needs.
5.3.8 Future Extensions
ERC-5564 intentionally supports multiple cryptographic schemes through the scheme identifier field.
Future GhostShard versions may introduce:
- Post-quantum stealth address schemes
- Alternative elliptic curves
- Threshold ownership constructions
- Hardware-backed receiving identities
The meta-address abstraction remains unchanged.
Only the underlying cryptographic scheme associated with the scheme identifier would change.
This design provides a forward-compatible migration path while preserving the remainder of the GhostShard architecture.
5.3.9 Summary
Meta-addresses provide the public receiving layer of GhostShard.
They allow recipients to publish a reusable receiving identity while keeping ownership distributed across independent stealth shards.
By separating receiving identities from ownership identities, GhostShard avoids exposing long-lived ownership relationships while preserving compatibility with the ERC-5564 ecosystem.
The next section describes how senders use a recipient's meta-address to derive one-time shard addresses through elliptic-curve Diffie-Hellman key exchange.
5.4 Stealth Address Generation
Stealth address generation is the process by which a sender creates a one-time ownership unit for a recipient using the recipient's meta-address.
The sender derives a fresh shard address that only the intended recipient can discover and control.
No interaction with the recipient is required, and no ownership information is revealed on-chain beyond the resulting shard address and announcement metadata.
GhostShard adopts the stealth address construction defined by ERC-5564 Scheme 1 and extends it as the foundation of the disposable ownership model.
5.4.1 Overview
The stealth address generation process can be summarized as:
flowchart LR
A[Recipient Meta Address]
A --> B[Viewing Public Key]
A --> C[Spending Public Key]
D[Ephemeral Keypair]
B --> E[ECDH Shared Secret]
D --> E
E --> F[Stealth Public Key]
C --> F
F --> G[Shard Address]The sender combines:
- The recipient's public keys
- A newly generated ephemeral keypair
to derive a unique shard address.
The recipient later performs the same computation and independently discovers ownership.
5.4.2 Ephemeral Key Generation
For every transfer, the sender generates a fresh ephemeral private key
where
is the order of the secp256k1 curve.
The corresponding ephemeral public key is
where
is the secp256k1 generator point.
The ephemeral keypair is used exactly once.
After announcement publication, the ephemeral private key is discarded.
The ephemeral public key
is included in the ERC-5564 announcement so that the recipient can later reconstruct the same shared secret.
5.4.3 Shared Secret Construction
Let
denote the recipient's viewing public key.
The sender computes an Elliptic Curve Diffie–Hellman (ECDH) shared point
The x-coordinate of the resulting point is extracted and hashed:
where
is the shared secret scalar used throughout the remainder of the derivation process.
Only the sender and recipient can compute
because both parties possess one side of the ECDH exchange.
5.4.4 Stealth Public Key Derivation
Let
denote the recipient's spending public key.
The shard public key is computed as
This operation produces a valid secp256k1 public key corresponding to a unique ownership unit.
The resulting key is mathematically independent from every previously generated shard.
Each transfer therefore produces a distinct ownership address even when the same recipient receives multiple assets.
5.4.5 Shard Address Creation
The shard public key is converted into a standard Ethereum address using the normal EVM address derivation procedure.
Let
denote the uncompressed shard public key.
The shard address is
where
returns the final twenty bytes of the hash output.
The resulting address is indistinguishable from any ordinary EVM externally owned account.
No protocol-specific address format is required.
5.4.6 Recipient Reconstruction
When scanning announcements, the recipient extracts the ephemeral public key
and computes
Substituting
gives
The sender and recipient therefore derive the same shared point.
The recipient computes the same shared secret
and reconstructs the identical shard public key
and shard address
without any communication with the sender.
5.4.7 Shard Private Key Recovery
Because
the corresponding private key is
Only the recipient can compute this value because only the recipient possesses
The shard private key grants complete control over the ownership unit and is subsequently used for transaction authorization within the GhostShard execution model.
5.4.8 Relationship to Disposable Ownership
Every stealth address generation event produces a new shard.
No shard address is reused.
Repeated transfers to the same recipient therefore create independent ownership units:
rather than accumulating activity around a persistent address.
This property forms the cryptographic foundation of GhostShard's disposable ownership model.
Ownership becomes fragmented across ephemeral shards rather than concentrated around long-lived accounts.
5.4.9 Future Extensions
The current construction relies on secp256k1 and ECDH as defined by ERC-5564 Scheme 1.
Future versions may introduce alternate stealth-address schemes through the ERC-5564 scheme identifier mechanism.
Potential upgrades include:
- Alternative elliptic curves
- Threshold stealth ownership
- Hardware-backed key derivation
- Post-quantum key exchange systems
Regardless of the underlying cryptographic primitive, the high-level structure remains unchanged:
The disposable ownership model therefore remains compatible with future cryptographic migrations.
5.5 Announcement Discovery
Stealth address generation creates a shard, but creation alone is insufficient.
The recipient must also discover that the shard exists, determine that it belongs to them, and recover the information necessary to manage it.
GhostShard adopts the ERC-5564 announcement mechanism as its discovery layer.
Each newly created shard is accompanied by an on-chain announcement containing the information required for recipient discovery and metadata recovery.
The announcement reveals the existence of a shard while preserving recipient privacy.
Only the intended recipient can determine ownership of the announced shard.
5.5.1 Overview
The announcement discovery process can be viewed as a recipient-side filtering and reconstruction procedure.
flowchart LR
A[ERC-5564 Announcement]
A --> B[Extract Ephemeral Public Key]
B --> C[Compute Shared Secret]
C --> D[View Tag Check]
D --> E[Derive Shard Address]
E --> F[Ownership Match]
F --> G[Decrypt Metadata]
G --> H[Register Shard]Every recipient independently performs this process.
No trusted indexer, coordinator, or registry is required for ownership discovery.
5.5.2 Announcement Structure
GhostShard publishes one ERC-5564 announcement for every newly created shard.
Conceptually, an announcement contains four fields:
where:
- \(\text{schemeId}\) identifies the stealth-address scheme.
- \(A_{\text{shard}}\) is the resulting shard address.
- \(E\) is the ephemeral public key.
- \(M\) is the encrypted metadata payload.
The announcement is emitted atomically alongside shard creation.
If shard creation fails, the announcement is reverted as part of the same transaction.
This guarantees consistency between ownership creation and ownership discovery.
5.5.3 Recipient Scanning
Recipients continuously scan the ERC-5564 announcement stream.
For each announcement, the recipient extracts the ephemeral public key
and computes the shared point
S’=sk
Using the procedure defined in Section 5.4, the recipient derives
where
is the shared secret scalar.
Only recipients possessing the correct viewing key can derive the correct shared secret.
All other observers obtain meaningless results.
5.5.4 View Tag Filtering
Performing a complete stealth-address reconstruction for every announcement would be computationally expensive.
To reduce scanning cost, GhostShard uses the ERC-5564 view tag mechanism.
The view tag is defined as:
where
is the shared secret.
The view tag is stored in plaintext within the announcement metadata.
Upon receiving an announcement, the recipient computes
and compares it against the published value.
If
the announcement is immediately discarded.
Because the view tag contains eight bits, a random announcement passes the filter with probability
Consequently, approximately
of unrelated announcements are rejected before any further processing is required.
The view tag improves discovery efficiency while revealing only a negligible fraction of the shared secret.
5.5.5 Ownership Verification
Announcements that pass the view tag filter undergo ownership verification.
Using the shared secret
the recipient reconstructs the shard public key
and derives the corresponding address
If
the announcement is confirmed as belonging to the recipient.
Otherwise the announcement is discarded.
Ownership detection therefore requires no interaction with the sender and no disclosure of recipient identity.
5.5.6 Metadata Recovery
After ownership has been confirmed, the recipient decrypts the announcement payload.
The metadata contains information describing the newly created shard, including:
- Asset type
- Token contract
- Token amount
- NFT identifier
- Optional encrypted sender metadata
The decryption process is described in Section 5.6.
Successful decryption completes the discovery process and transforms an anonymous on-chain address into a usable ownership object within the recipient's wallet.
5.5.7 Discovery Complexity
The discovery algorithm scales linearly with the number of announcements.
Let
represent the total number of announcements observed by a recipient.
The discovery cost is
with view-tag filtering reducing the number of expensive ownership reconstruction operations to approximately
under normal conditions.
As network activity grows, recipients therefore process only a small fraction of announcements beyond the initial filtering stage.
This property enables practical large-scale stealth-address discovery without requiring specialized infrastructure.
5.5.8 Relationship to Ownership Privacy
Announcement discovery reveals that a stealth transfer occurred.
It does not reveal the recipient.
Observers can see:
- The announcement
- The shard address
- The ephemeral public key
Observers cannot determine:
- Which recipient owns the shard
- Which meta-address was used
- Whether two shards belong to the same recipient
- Whether a shard is a payment or change output
Ownership discovery therefore remains private even though announcements themselves are publicly visible.
5.5.9 Future Extensions
Future versions of GhostShard may introduce additional discovery optimizations, including:
- Larger view tags
- Indexed discovery services
- Chain-specific announcement aggregators
- Zero-knowledge ownership discovery schemes
These improvements affect discovery efficiency but do not alter the fundamental ownership model.
Regardless of the discovery mechanism used, ownership remains recoverable only by entities possessing the appropriate viewing key.
5.6 Metadata Confidentiality
Stealth address discovery identifies ownership, but ownership discovery alone is insufficient for practical asset management. Recipients must also learn what assets a shard contains and, in some cases, who created the shard.
GhostShard therefore associates each shard announcement with metadata describing the shard's contents. The protocol separates metadata into two categories:
- Public asset metadata, which describes the asset contained within the shard.
- Private sender metadata, which may contain sender identity information, payment references, invoice identifiers, or application-specific notes.
Public asset metadata remains unencrypted for efficient discovery and parsing, while private sender metadata is protected through authenticated encryption derived from the shard's ECDH shared secret.
5.6.1 Metadata Architecture
Each ERC-5564 announcement contains a metadata payload associated with a single shard.
The metadata structure is divided into a plaintext header and an optional encrypted section.
flowchart LR
A[View Tag]
B[Asset Type]
C[Token Address]
D[Amount / Token ID]
E[Encrypted Sender Information]
A --> B --> C --> D --> EThe plaintext header allows recipients to efficiently identify shard contents after discovery.
The encrypted section protects information that could reveal relationships between counterparties.
5.6.2 Shared Secret Derivation
Metadata encryption reuses the ECDH shared secret generated during stealth address creation.
Let
where:
- \(e\) is the sender's ephemeral private key.
- \(V\) is the recipient's viewing public key.
The shared secret is derived as:
where \(x(S)\) denotes the x-coordinate of the ECDH point.
A dedicated encryption key is then derived using HKDF-SHA256:
The HKDF context string provides domain separation, ensuring that metadata encryption keys remain independent from any other keys derived from the same shared secret.
5.6.3 Metadata Layout
The metadata payload begins with a fixed-width plaintext header.
| Offset | Size | Field |
|---|---|---|
| 0 | 1 byte | View Tag |
| 1 | 1 byte | Asset Type |
| 2 | 20 bytes | Token Address |
| 22 | 32 bytes | Amount or Token ID |
The total header size is:
Asset types are encoded as:
| Value | Asset |
|---|---|
| 0 | Native Asset |
| 1 | ERC-20 |
| 2 | ERC-721 |
For native assets, the token address field is set to the zero address.
When sender metadata is present, the encrypted section is appended after the header:
| Field | Size |
|---|---|
| IV | 12 bytes |
| Ciphertext | Variable |
| Authentication Tag | 16 bytes |
The complete structure is therefore:
+-----------------------------+
| Plaintext Header (54 bytes) |
+-----------------------------+
| AES-GCM IV (12 bytes) |
+-----------------------------+
| Encrypted Sender Metadata |
+-----------------------------+
| GCM Authentication Tag |
+-----------------------------+
5.6.4 Authenticated Encryption
GhostShard v0 uses AES-256-GCM for sender metadata protection.
A random 96-bit initialization vector is generated for every encryption operation:
Sender metadata is encrypted as:
where:
- \(C\) is the ciphertext.
- \(T\) is the authentication tag.
Only recipients capable of deriving the correct shared secret can reconstruct \(K_{meta}\) and decrypt the ciphertext.
5.6.5 Confidentiality and Integrity
The encrypted metadata provides both confidentiality and authenticity.
Confidentiality
Only the intended recipient possesses the viewing key required to reconstruct the ECDH shared secret.
Consequently, only the intended recipient can derive \(K_{meta}\) and recover the encrypted sender information.
Observers can view the ciphertext but cannot distinguish its contents from random data.
Integrity
AES-GCM provides authenticated encryption.
Any modification of the ciphertext, initialization vector, or authentication tag causes decryption to fail.
Recipients can therefore detect tampering without requiring additional signatures or verification mechanisms.
5.6.6 Design Rationale
GhostShard intentionally leaves asset information unencrypted while protecting sender-specific information.
This design choice provides several advantages:
- Recipients can quickly understand shard contents after discovery.
- Wallet synchronization remains efficient.
- Asset balances can be indexed without decryption.
- Sender identity and payment references remain private.
The protocol therefore encrypts the information that reveals relationships between participants while leaving operational asset information directly accessible.
5.6.7 Summary
Metadata confidentiality extends stealth ownership by protecting information associated with a shard after discovery.
GhostShard derives a dedicated metadata encryption key from the stealth-address ECDH shared secret and uses AES-256-GCM to protect sender-specific information.
The resulting design preserves efficient asset discovery while ensuring that sensitive counterparty information remains visible only to the intended recipient.
5.7 Selective Disclosure
GhostShard's announcement architecture naturally supports selective disclosure.
Because every shard announcement is derived from an independent ECDH exchange, disclosure can be scoped to individual announcements rather than entire ownership histories.
This property allows users to reveal information about specific transfers without exposing unrelated protocol activity.
5.7.1 Transaction-Scoped Shared Secrets
For each announcement, the sender generates a fresh ephemeral key pair:
and derives an ECDH shared secret with the recipient's viewing public key:
where:
- \(e_i\) is the ephemeral private key.
- \(V\) is the recipient's viewing public key.
- \(x(\cdot)\) denotes the x-coordinate of the ECDH point.
Because a new ephemeral key is generated for every announcement,
with overwhelming probability.
Each announcement therefore possesses an independent cryptographic disclosure boundary.
5.7.2 Metadata Confidentiality
The shared secret is used to derive the metadata encryption key through HKDF-SHA256:
The resulting key encrypts announcement metadata using AES-256-GCM.
Only parties capable of reconstructing the corresponding shared secret can decrypt the protected metadata.
Consequently, metadata visibility is scoped to individual announcements rather than to an entire ownership identity.
5.7.3 Disclosure Isolation
A fundamental property of the design is disclosure isolation.
flowchart LR
A[Announcement A]
--> SA[Shared Secret A]
B[Announcement B]
--> SB[Shared Secret B]
C[Announcement C]
--> SC[Shared Secret C]
SA -. disclosed .-> V[Verifier]
SB -. remains private .-> X[Hidden]
SC -. remains private .-> XKnowledge of:
provides no computational advantage in deriving:
or
because each secret originates from an independent ECDH exchange.
As a result, disclosure can remain bounded to individual announcements.
5.7.4 Deterministic Disclosure References
Section 5.8 introduces deterministic shared-key generation.
Instead of generating ephemeral keys randomly, an ephemeral key may be deterministically derived from an external reference such as:
- Invoice identifiers
- Payment references
- UUIDs
- Business records
For a disclosure reference \(R\):
The corresponding ephemeral public key is:
This allows announcements to be reconstructed from external records while preserving the same selective disclosure properties.
Deterministic references therefore provide a mechanism for reproducible transaction proofs without requiring persistent storage of ephemeral keys.
5.7.5 Security Properties
The selective disclosure mechanism provides the following properties:
Bounded Disclosure
Disclosure of one announcement reveals no information about unrelated announcements.
Independent Verification
Third parties can verify disclosed announcements without obtaining ownership-level visibility.
Ownership Preservation
Selective disclosure reveals information about a specific transfer rather than a user's complete ownership graph.
5.8 Deterministic Shared Key Generation
The selective disclosure model described in Section 5.7 assumes that each announcement is created using a randomly generated ephemeral key pair.
While this approach provides strong privacy properties, it introduces operational complexity for institutions processing large numbers of payments. In such environments, payment verification may require long-term retention of disclosure material associated with individual transactions.
Deterministic Shared Key Generation is a proposed extension that allows disclosure material to be reconstructed from structured off-chain data rather than stored indefinitely.
This mechanism is intended primarily for institutional accounting, auditing, and reconciliation workflows.
5.8.1 Motivation
Under the standard ERC-5564 workflow, each announcement uses a randomly generated ephemeral private key:
The corresponding public key is included in the announcement and later participates in stealth-address derivation.
For ordinary users this approach is sufficient.
For institutions, however, maintaining disclosure records for thousands or millions of transactions can create operational overhead.
The objective of deterministic shared key generation is to allow transaction-specific proof material to be reconstructed from existing business records rather than permanently stored.
5.8.2 Deterministic Ephemeral Key Derivation
Instead of generating a random ephemeral key, the sender derives the key from structured transaction data using HKDF-SHA256.
where:
- (e) is the ephemeral private key.
- (L) is a structured transaction label.
- (\text{salt}) is a fixed protocol value.
"ghost-shard-ephemeral"is the HKDF context string.
The resulting public key is:
where (G) is the secp256k1 generator point.
The derived key behaves identically to a randomly generated ephemeral key from the perspective of the stealth-address protocol.
5.8.3 Structured Transaction Labels
The label is intended to encode information already known to both parties during normal business operations.
A representative format is:
where:
| Component | Purpose |
|---|---|
| Asset Type | Prevents cross-asset collisions |
| Token Address | Prevents cross-token collisions |
| Amount / Token ID | Prevents cross-value collisions |
| Reference | Invoice ID, settlement reference, UUID, etc. |
| Shard Index | Distinguishes multiple outputs within a transaction |
The label is never published on-chain.
Only the resulting announcement is visible.
5.8.4 Mesh Transaction Support
GhostShard mesh transactions may generate multiple outputs associated with the same payment workflow.
To ensure that each output derives a unique stealth address, the label includes a shard index.
flowchart LR
A[Invoice Reference]
A --> B0[Shard Index 0]
A --> B1[Shard Index 1]
A --> B2[Shard Index 2]
B0 --> S0[Stealth Address 0]
B1 --> S1[Stealth Address 1]
B2 --> S2[Stealth Address 2]Each shard index produces a unique deterministic ephemeral key and therefore a unique stealth address.
This allows a recipient to reconstruct all disclosure material associated with a payment using only the original business reference and the output count.
5.8.5 Institutional Disclosure Workflow
A typical institutional workflow proceeds as follows:
- An invoice or settlement reference is created.
- The sender derives deterministic ephemeral keys from the reference and transaction parameters.
- Announcements are published normally through the ERC-5564 workflow.
- The recipient records the business reference rather than individual disclosure keys.
- During an audit, the reference is supplied to a disclosure system.
- The disclosure system reconstructs the deterministic ephemeral keys and verifies the associated announcements.
flowchart LR
I[Invoice Reference]
I --> D[Deterministic Derivation]
D --> A[Announcements]
A --> V[Verification]This eliminates the need to archive per-transaction disclosure material while preserving the ability to verify historical payments.
5.8.6 Entropy Requirements
The security of deterministic derivation depends on the unpredictability of the transaction reference.
Low-entropy identifiers such as sequential invoice numbers are unsuitable because they may be susceptible to enumeration attacks.
GhostShard recommends references containing at least 128 bits of entropy.
Examples include:
- UUIDv4 identifiers
- Cryptographically generated settlement references
- Randomized payment identifiers
High-entropy references ensure that deterministic derivation remains computationally infeasible to brute force.
5.8.7 Security Properties
Deterministic derivation preserves the fundamental security properties of the underlying stealth-address protocol.
Independent Disclosure Boundaries
Distinct labels produce distinct ephemeral keys:
with overwhelming probability.
As a result, disclosure associated with one reference does not reveal information about another.
No Viewing-Key Exposure
Verification relies on reconstruction of transaction-specific proof material rather than disclosure of the recipient's viewing key.
This preserves the bounded-disclosure philosophy introduced in Section 5.7.
Operational Simplicity
Institutions may archive compact business references instead of maintaining large stores of disclosure artifacts.
The reference itself becomes the retrieval mechanism for future verification.
5.8.8 Scope and Future Work
Deterministic Shared Key Generation is not part of GhostShard v0.
The current implementation uses randomly generated ephemeral keys for all announcements.
The design is included here because it provides a natural extension of the selective disclosure model and enables future compliance workflows without requiring disclosure of viewing keys.
Future research directions include:
- Hierarchical deterministic disclosure trees.
- Time-bounded audit references.
- MPC-based disclosure reconstruction.
- Zero-knowledge proofs over deterministic references.
- Regulatory reporting systems built on reconstructed announcement histories.
5.10 Summary
This chapter defined the cryptographic foundations of GhostShard.
Beginning from a single EOA-derived root identity, the protocol deterministically derives independent spending, viewing, and encryption keys while preserving recoverability and key separation.
Using ERC-5564 meta-addresses, recipients publish a reusable receiving identifier from which senders can derive one-time stealth shards. Through ECDH-based stealth address generation, ownership is established without requiring recipient interaction and without exposing recipient identities on-chain.
ERC-5564 announcements provide the discovery mechanism that allows recipients to locate newly created shards and recover associated metadata. Metadata confidentiality is achieved through authenticated encryption derived from transaction-specific shared secrets, enabling private sender attribution and payment references.
The chapter also introduced GhostShard's selective disclosure model, in which transaction-specific cryptographic boundaries allow users to reveal individual payments without exposing unrelated activity. Finally, it described deterministic shared key generation as a future extension for institutional auditing and compliance workflows.
Together, these mechanisms provide the cryptographic primitives required for private ownership, recipient discovery, metadata protection, and bounded disclosure.
The next chapter builds on these primitives to describe how shards are combined into mesh transactions and how ownership is transferred within the GhostShard execution model.