SHILDO Docs / Privacy

Privacy

Shildo hides payment metadata before it reaches public chain infrastructure. This page explains threat model, cryptographic tools, shielded transfer behavior, and compliance view keys.

Threat model

Shildo assumes public chain observers, indexers, and mempool watchers are adversarial. The protocol protects against:

  • Linkability between sender and receiver on public explorers
  • Amount inference from on chain calldata for shielded paths
  • Memo leakage through transaction input fields
  • Cross chain correlation of the same payment across hops

Shildo does not protect against compromise of the sender device, loss of seed phrase, or voluntary disclosure of a view key.

What stays private

FieldShielded sendPlain send (demo)
Sender → receiver linkHidden on public railsVisible
AmountMasked in explorerVisible
MemoStored in shielded_memo column onlyVisible in memo column
Route metadataEncrypted off chainN/A

Cryptographic mechanism

Intents are encrypted client side using keys derived from the user seed. Groth16 zk SNARK proofs validate correctness without revealing private witness values. The proof attests:

  1. The commitment exists in the vault merkle tree
  2. The sender had sufficient balance in the settlement state
  3. The nullifier has not been spent before
  4. The new root correctly accumulates the intent

Public chain observers only see proof verification success and an updated state root hash. They cannot reconstruct plaintext intent fields from chain data alone.

Shielded transfers in the demo wallet

Enable Shield transfer on the send form. The UI calls process_transfer with p_is_shielded = true. The database function stores plaintext amount internally but sets memo to null and moves the memo into shielded_memo. The network explorer masks amount and memo columns for shielded rows.

-- Shielded row behavior (simplified)
memo          → NULL on public view
shielded_memo → stored server side
is_shielded   → true
explorer UI   → shows "Shielded" instead of amount

View keys

Each shielded transfer can emit a view key. The key is derived from the intent ciphertext and user master key. Holders can decrypt:

  • Exact amount and asset
  • Recipient endpoint
  • Memo text
  • Timestamp and route id

View keys are never published on chain by default. Users share them with auditors through out of band channels. This enables compliance without global transparency.

Privacy vs performance

Proof generation adds latency compared to plain ERC-20 transfers. Shildo targets sub second proof generation on prover hardware and ~1.2s Base finality. Batch verification on Base amortizes gas for high volume integrators.

Comparison to public transfers

PropertyPublic transferShildo shielded
Explorer visibilityFullMinimal
AuditabilityGlobalSelective via view key
Proof requiredNoYes
Cross chainManual bridgesUnified settlement on Base