Privacy Model

GHOST implements layered privacy through compartmentalization. Different participants can observe different subsets of protocol data, and no single participant can reconstruct the complete picture.

Information Visibility by Role

Data Item	Users	GHOST Server	CRE (TEE)	On Chain Observers
Deposit amounts	Own only	All	All	Vault level only
Encrypted rate bids	Own only	Ciphertext only	Plaintext (ephemeral)	Not visible
Plaintext rates	Own only	Never	During matching only	Never
Borrow intent amounts	Own only	All	All	Not visible
Match proposals	Own only	All	Generated by CRE	Not visible
Loan terms	Parties only	All	All	Not visible
Collateral amounts	Parties only	All	All	Not visible
Transfer amounts	Parties only	All	All	Vault level only
Credit scores	Own only	All	All	Not visible

Encryption Scheme

Rate bids are encrypted using ECIES (Elliptic Curve Integrated Encryption Scheme) on the secp256k1 curve, implemented via the eciesjs library (v0.4, WASM compatible).

Encryption flow:

1. The client fetches the CRE public key from the server's /cre-public-key endpoint
2. The client encrypts the rate bid using encrypt(crePublicKey, rateBid)
3. The encrypted blob is submitted as part of the lend intent
4. The server stores the blob without the ability to decrypt it
5. The CRE fetches the encrypted blob and decrypts it using decrypt(crePrivateKey, blob)
6. After matching, the decrypted rate is used to compute loan terms and then discarded

Key properties:

• The CRE private key is stored as a DON secret, split across threshold nodes
• Each encryption uses a fresh ephemeral key pair (ECIES property), so identical rates produce different ciphertexts
• The server cannot correlate rate values across different intents by comparing ciphertexts

Privacy Guarantees

What is private

• Lending rates: No entity other than the CRE TEE sees plaintext rates during the matching window. After matching, rates are discarded from TEE memory.
• Rate ordering: The relative ordering of bids is never exposed to the server. The server cannot determine which lender offered the cheapest rate.
• Individual lender profitability: Since each lender earns their bid rate (discriminatory pricing), an observer cannot infer a lender's rate from the loan terms visible to the borrower.

What is not private

• Deposit and loan amounts: These are visible to the server and to the involved parties. Amount privacy requires the future ZK vault implementation.
• Participant addresses: Addresses are stored in the server for routing. Stealth addresses are planned for the production architecture.
• Collateral ratios: The server knows the collateral amount and loan principal, so it can compute the ratio.
• Credit tier: Stored on the server for collateral multiplier calculations.

Privacy Degradation Vectors

Vector	Impact	Mitigation
Server database leak	Exposes amounts, addresses, loan terms, credit scores. Does not expose rates.	Encrypt at rest; server is not the rate authority
CRE TEE side channel	Could theoretically leak rates during decryption	Chainlink TEE hardening; threshold execution reduces single node risk
Traffic analysis	Timing of deposits and intents could correlate identities	Epoch based batching reduces timing signal; all intents processed together
Collateral amount inference	If collateral multiplier schedule is known, collateral amount reveals credit tier	Multiplier schedule is public by design; this is accepted

Future Enhancements

The ZK vault architecture (documented in the ZK Vault section) introduces several additional privacy properties:

• Amount privacy via Pedersen commitments on BN254
• Address privacy via stealth addresses with elliptic curve Diffie Hellman
• Proof privacy via zero knowledge proofs that verify correctness without revealing inputs
• Compliance privacy via ZK KYC proofs that verify eligibility without revealing identity