Security considerations for the current Devnet implementation and guidance toward production readiness.

• User funds (lamports in escrow vaults)
• Wallet private keys
• Program upgrade authority
• Integrity of on-chain state transitions

• PDA-based deterministic account ownership model
• Explicit signer constraints in instructions
• Error checks for invalid states and mismatched profiles
• Frontend transaction signature normalization for safer explorer linking

• Demo technician keypair in localStorage is not production-grade

• Program ID / IDL drift after deploy can cause unsafe behavior

• Users may attempt transactions without enough lamports

• Asset metadata in Supabase (assets table) is public-read in demo; production should enforce hospital-scoped RLS.
• Evidence integrity relies on SHA-256 hash stored at upload (evidence_hash) and verified client-side before approval (SEC-03).
• Edge Function evidence is the sole writer; it verifies on-chain tx before insert (TD-08).

• Off-chain metadata and evidence storage depend on Supabase availability and correct RLS/policies.
• Misconfigured RLS or exposed service role key could allow unauthorized writes/reads.
• Edge Function must be deployed and VITE_SUPABASE_FUNCTIONS_URL set; otherwise evidence flow is disabled.
• Supabase project is a centralized dependency — consider failover/backup strategy for production.

• Never commit secrets/private keys
• Use dedicated deployment key management
• Verify program/IDL alignment on each release
• Use explicit environment separation (dev/test/prod)

• Follow docs/RUNBOOK.md
• Capture transaction signatures and logs
• Classify impact scope before remediation

• Enforce distinct hospital/technician wallets per role (drop single-wallet demo path)
• Add monitoring/alerting for failed tx patterns
• Introduce audit and formal security review before mainnet