SHILDO Docs / Security
Launch App

Security

Privacy infrastructure built on modern cryptography with selective transparency for compliance. This page covers cryptographic guarantees, operational security, and demo wallet limitations.

Cryptographic isolation

Every shielded route is sealed with Groth16 zk SNARK proofs before touching public mempools. Verifier contracts on Base reject invalid proofs. The trusted setup ceremony output is pinned by hash on chain. Circuit upgrades require governance timelock.

Proof system properties

  • Completeness valid intents always produce acceptable proofs
  • Soundness invalid intents cannot forge proofs without breaking cryptography
  • Zero knowledge proofs reveal no witness beyond public inputs

Key management

User master keys are derived from the BIP39 seed phrase client side. Shildo servers never receive plaintext seeds in the demo wallet. Only a SHA-256 hash of the normalized seed is stored for sign in lookup.

seed_hash = SHA256(normalize(seedPhrase))
// Stored in wallets.seed_hash
// Used to authenticate sign in, not to spend on chain

Selective transparency

View keys allow auditors to decrypt specific transfers. Public explorers never receive plaintext intent fields for shielded sends. Organizations can define policy for when view keys must be archived.

Finality and reorgs

Base settlement core targets ~1.2s median finality for proof inclusion. Relayers should wait for finalized block depth before irreversible delivery on outer chains. The demo explorer surfaces last finalized block and last safe block counters for visibility.

Monitoring and anomaly detection

Route integrity checks run on every shielded path. Anomaly signals flag:

  • Mismatched settlement roots between Base and relayer cache
  • Replay attempts with duplicate nullifiers
  • Delivery amount drift vs proof public inputs
  • Relayer stake below collateral threshold

Relayer security

Relayers stake SHILDO on Base. Fraudulent delivery claims can be challenged with merkle proofs against the settlement root. Successful challenges slash stake and compensate affected users from the insurance pool.

Smart contract practices

  • Verifier contracts are non upgradeable unless governance passes timelock upgrade
  • Pause guardian can halt proof submission during incidents
  • External audits required before mainnet launch

Demo wallet security notes

Seed phrases are generated client side. Supabase stores ledger balances only. RLS policies in the demo schema allow anon access for prototyping. Never use demo seeds with real funds. Rotate Supabase keys before any production deployment.

Reporting vulnerabilities

Report security issues to security@shildo.com with proof of concept and impact assessment. Do not disclose publicly until patched.