Wallet safety

The scc-tui wallet has a transfer-safety workspace that runs before any transaction is submitted. This page explains what it actually checks.

Plan / review / submit

Every transfer goes through three explicit phases:

  1. Plan — TUI shows the constructed transaction including: signer, recipient, amount, fee estimate, expected nonce, expiration height.
  2. Review — multiple safety bindings run against the planned tx (see below). User must explicitly confirm.
  3. Submit — only after explicit confirm; signed locally; submitted to the configured RPC.

You cannot submit a transaction without going through review. There is no "fast path" that skips checks.

What review actually checks

BindingWhat it verifies
Recipient postureIs the recipient address known? Has it received transfers before? Is it on the local recipient book?
Risk gateSender-risk score against historical patterns (rate, value, novelty).
Recovery stateAre you submitting from an account currently in recovery? (Recovery-required writes are blocked by the protocol — closed in SECURITY-1 round 2.)
Network stateIs the chain in safe-mode? Is your RPC node reporting operational_state: healthy?
Fee estimateDoes the fee match current network conditions? Is it suspicious (way over expected)?
Governance bindingsAre there pending governance proposals that affect your account / contract?
Local hold/releaseDid you put a local hold on this address? (Local hold = TUI refuses to submit to it without an explicit override.)

Suspicious-transfer escalation

When risk thresholds trip, the TUI escalates rather than silently allowing the tx:

  • Yellow warning: required acknowledgement, single-press confirm
  • Orange warning: required acknowledgement + typed confirmation phrase
  • Red warning: blocked by default, requires an --unsafe-override flag to bypass

Most users never see anything past yellow. Red is reserved for clear scam patterns (e.g. transfer to a known phishing address from R94's watchlist).

What the wallet does NOT do

  • It does not verify the recipient's identity. You're responsible for the address.
  • It does not detect every scam — the watchlist is only as good as the data feeding it.
  • It does not communicate with Syntarie servers about your wallet contents. Your private key never leaves your machine.

Test coverage

  • 801 tests passing in scc-tui as of 80e5a51.
  • Transfer-review tests cover: plan, review, risk binding, recovery binding, governance binding, local hold/release.
  • The recently-shipped --testnet preset (Vanta sprint, 2026-04-26) bundles RPC URL + bearer token; faucet keybinding is testnet-only.

Recovery flow

If you lose your ~/my.key file:

  • If you set up signed-backup recovery (encrypted backup package), restore from the TUI's account workspace using your backup file.
  • If you set up device hierarchy (multi-device + guardian set), the TUI's recovery workspace queries account-recovery status over RPC and walks you through the guardian-intent flow.
  • If you did neither, the funds at that address are permanently inaccessible. Self-custody means you bear this risk.

For the testnet, just scc-node keygen ~/my-new.key and request fresh test SCC from the faucet.

Source pointers

  • scc-tui/src/workspace/transfer_compose.rs — plan / review / submit flow
  • scc-tui/src/workspace/risk_binding.rs — risk gates
  • scc-tui/src/workspace/recovery_binding.rs — recovery state checks
  • interface/src/rpc/wallet_account_surface.rs — RPC routes (reject_recovery_required_writes SECURITY-1 closure)