​

Security Test Report

​

Current evidence status

• Gateway and node access: covered. Host checks and private-access guidance exist. Operators must verify their own network exposure.
• Signer-v2 and wallet key safety: pending complete release validation. The controls exist, but this report must not call them covered until fresh Local, WSL2, macOS, fresh Hosting, previous-Hosting migration, cold reboot, rollback, concurrent-send, ambiguous-broadcast, and Local Docker gates pass together.
• Wallet role separation: pending complete release validation. Skill-side Agent selection is fail-closed, but the complete signer role matrix and Mining confused-deputy tests must pass before this report calls the boundary covered.
• Optional Control UI account passkey: covered at its Gateway boundary. Mode, enrollment, approval, and removal have regression coverage; this is not signer custody authorization.
• Signer WebAuthn, fail-closed policy, durable caps/idempotency, and reviewed execution: pending complete release validation. Go owns these controls; the retired split-key/passphrase unlock model is not production custody.
• Agent skills and wallet grants: covered. Skill install/allowlist is separate from Wallet > Skill Grants. Denied actions fail closed.
• Tasks and automation: partial / payment-idempotency gate pending. Saved task definitions remain separate from run history and mining strategy tasks are strategy-only, but concurrent/restarted settlement and marketplace payment workflows must prove one durable execution before release.
• SAT mining runtime: pending signer-workflow idempotency validation. Max-capital, restart, commit-downsizing, and recovery behavior has regression evidence, but every mining mutation still requires the complete stable caller-id, ambiguous-broadcast, crash/restart, and concurrency matrix before unattended operation is called covered.
• SAT protocol maintainer: partial / drill required. Primary maintainer behavior and safe fixed-recipient lanes are documented. Standby, alert delivery, and cleanup backlog evidence must be rerun per deployment.
• Public hosting posture: operator-specific. Every hosted install must rerun network, auth, firewall, signer, and alert checks.

​

What was tested

• gateway and node access
• native signer-v2 key lifecycle, sockets, policy, RPC, caps, and custody
• wallet roles and policy boundaries
• optional Control UI account passkey and separate signer-owned approval
• skill installation, Agent allowlists, and wallet grants
• task creation, task execution policy, and run history separation
• SAT mining wallet isolation
• Fased Network Vault/bond authority
• SAT protocol maintainer primary, standby, monitor, and alert paths

​

Gateway and node access

• gateway auth is enabled for any non-loopback access
• admin UI is private through localhost, Tailscale, or SSH tunnel
• public Fased Network/A2A edge is separate from admin access
• only intended ports are exposed
• Tailscale status is healthy when used
• firewall defaults deny incoming traffic except explicit allows

fased doctor --json
ss -ltnp
sudo ufw status verbose
tailscale status
tailscale serve status

• gateway admin UI is not exposed publicly without authentication
• node/device access is paired or explicitly allowed
• Tailscale or SSH tunnel access is healthy when used
• public Fased Network exposure, if enabled, is separate from admin access

• Security overview
• Gateway security
• Tailscale
• Host security baseline

​

Signer and wallet key safety

• Go owns wallet creation/import/re-encryption, policy, execution RPC, signer WebAuthn, caps, signing, and reconciliation
• Hosting runs the Gateway as app and the signer as fased-signer
• /run/fased-signerd/app.sock is group-authorized 0660; the Gateway has no access to /run/fased-signerd/control.sock (0600)
• /var/lib/fased-signerd/state.db, master.key, and audit.jsonl are signer-owned inside a 0700 directory
• the Gateway has no signer sudo rule and cannot execute app-controlled code as fased-signer
• the fixed root updater verifies exact tagged artifact digest and attestation, gates mutations, snapshots state, and rolls back/quarantines failure
• raw private keys, RPC execution secrets, and signer credentials are not printed in logs, task output, UI, argv, or environment

fased wallet signer doctor --json
fased wallet status --json
sudo systemctl status fased-signerd.service fased-host-updater.service --no-pager
sudo stat -c '%U:%G %a %n' \
  /var/lib/fased-signerd \
  /var/lib/fased-signerd/state.db \
  /var/lib/fased-signerd/master.key \
  /var/lib/fased-signerd/audit.jsonl \
  /run/fased-signerd/app.sock \
  /run/fased-signerd/control.sock

• signer doctor passes
• configured wallets show protocol-v2 capability, exact policy/network hashes, and no legacy Node keystore path
• app can connect only to the application socket and has no signer sudo
• no raw key material appears in the report

​

Wallet role separation

• Agent wallet sends use only allowed Agent-role wallets
• Mining capital and mining submit use the mining wallet path
• Vault bond and staking use the Vault/bond authority path
• archive first durably tightens the native policy to deny-all, then unregisters; failure to lock must leave the wallet registered

• generic wallet-capable skills can use only explicitly granted Agent wallets
• Mining wallets are reserved for SAT mining and sweep behavior
• Vault wallets are reserved for manual custody, Fased Network bond, and staking
• wallet aliases such as @wallet:agent, @wallet:mining, and @wallet:vault resolve to the intended role and do not silently cross roles

​

Control UI account passkey

• passkey-off mode does not claim signer custody authorization
• passkey-on mode authenticates sensitive Gateway approval/settings actions
• first passkey enrollment can happen without an existing passkey
• Gateway passkey removal updates Gateway approval state only

• wallet send approval
• Gateway wallet/settings approval
• passkey remove with deleted wallets
• no stale wallet id aliases after deletion

• Gateway passkey state never substitutes for signer WebAuthn
• no stale “passkey on with no usable passkey” state remains after removal
• first passkey enrollment remains possible

​

Native signer WebAuthn, policy, and durable execution

• missing policy and empty operations/programs/assets/destinations deny all
• every executable asset has positive per-transaction and daily caps
• every manual native Agent, Mining, or Vault review requires signer WebAuthn bound to the exact digest, decoded intent, policy hash, nonce, and expiry
• native signer credential registration, listing, and fenced atomic revocation work through the signer-only launcher/control socket; revocation invalidates pending proof authority and refuses removal of the last credential unless the host administrator gives the explicit last-credential confirmation
• request ids, cap reservations, daily totals, signed bytes, and reserved/broadcast/confirmed/failed/unknown states survive restart
• an ambiguous result reconciles the exact existing signature and is never automatically rebroadcast

• new wallets activate the exact signer-owned role baseline and remain denied outside its typed operations, reviewed destinations, and positive caps; legacy explicit deny-all wallets remain deny-all until one owner-reviewed baseline activation
• concurrent requests cannot both consume the same remaining cap
• restarting does not reset daily accounting or create a replacement request
• the legacy split-key/passphrase unlock and Node custody routes remain absent

​

Agent skills and wallet grants

• skill install does not grant wallet access
• Agent skill allowlist does not grant wallet access
• wallet grants define wallet ids, chains, caps, actions, and automation level
• denied wallet actions fail closed
• mining and Vault wallets are not exposed to generic wallet-capable skills

• install a wallet-capable skill with no wallet grant and verify it cannot send
• grant only one Agent wallet and verify other wallets are unavailable
• verify cap failures are explicit and logged

• a skill can be installed without gaining wallet authority
• a skill can be allowed for an Agent without gaining wallet authority
• wallet authority appears only after a narrow Wallet > Skill Grant
• grant caps, actions, wallet ids, chains, and automation level are visible

​

Tasks and automation

• a task can run with no wallet access
• a task can run with selected skills only
• a mining strategy task can inspect mining status/history and propose strategy changes without funding, withdrawing, sending, or changing capital risk
• local-only mining tasks do not add web search unless explicitly requested
• task run output records model, skill, delivery, memory, and wallet-policy context

• Agent > Tasks shows saved task definitions, not mining or wallet history
• run history stays audit data and does not inflate task counts
• task templates do not silently grant web, wallet, bond, send, or mining-capital access
• mining strategy tasks can change strategy intent only when configured; they cannot fund, withdraw, send, bond, start, stop, claim, or change capital risk

​

SAT mining runtime

• a max-capital target does not consume the whole funded miner-capital balance
• high configured commit is reduced instead of missing a cycle when free capital changes
• the watcher keeps minimum-entry continuity reserve when possible
• one pending cycle can still submit the next cycle without spending all free capital
• low free capital submits minimum when possible instead of idling
• service restart preserves active mining mode when locked capital exists

• after restart, mining stayed running=true, enabledWanted=true, and drainOnly=false
• cycles 5933669, 5933670, and 5933671 submitted successfully after the continuity fix
• settled cycles claimed successfully while the runtime kept free continuity capital instead of entering a long skipped-cycle gap

• setting target/max close to total miner capital must not self-lock the wallet into repeated skipped cycles
• skipped cycles are still possible when free capital is below minimum entry, RPC is unavailable, or cycle claim has not cleared, but max-capital target alone should not create a long idle gap

​

SAT protocol maintainer

• primary service: fased-sat-maintainer.service
• standby timer: fased-sat-maintainer-standby.timer
• monitor timer: fased-sat-maintainer-monitor.timer
• primary runner lock prevents double-running
• standby skips while primary is active
• standby can run one maintenance pass after primary is stopped
• primary can restart after standby takeover
• monitor checks:
  • no recent successful maintainer pass
  • maintainer failure streak
  • low payer SOL
  • registry reserve below launch buffer
  • pending treasury and distributor lanes
• pending mining-cycle backlog
• cleanup/reclaim problem streak

systemctl --user status fased-sat-maintainer.service
systemctl --user list-timers fased-sat-maintainer-standby.timer fased-sat-maintainer-monitor.timer --all
tail -n 20 ~/.fased/sat-maintainer.jsonl
cat ~/.fased/sat-maintainer-monitor-state.json

• one primary pass runs at a time
• standby does no work while primary is healthy
• standby can take over after primary stops
• repeated maintainer calls do not double-claim, over-refill, or redirect funds
• monitor state reports freshness and failure streaks
• low payer SOL, reserve shortfall, pending lanes, and cleanup backlog produce actionable alert state

​

What is still operator-specific

• which interface the gateway binds to
• whether gateway auth is enabled
• which ports are publicly reachable
• whether Tailscale, SSH tunnel, or reverse proxy policy is correct
• whether secrets were pasted into chat, config screenshots, task output, or logs
• whether installed skills and dependencies are trusted
• whether wallet grants match intended operational risk
• whether alert delivery actually reaches the operator

​

What this report does not claim

• all future versions are safe
• every third-party skill is safe
• every hosted deployment is configured correctly
• public RPC providers are reliable
• wallet loss is impossible
• SAT mining produces predictable economic outcomes
• Fased Network or SAT mainnet launch is complete

​

What should stay separate

• Mining page: miner-owned mining controls.
• Fased Network page: bond, staking, and Vault authority state.
• Wallets page: wallet roles, grants, Gateway passkeys, review intent, and balances.
• Native signer: keys, policy, signer WebAuthn, execution RPC, durable caps, and reviewed execution.
• Agent Tasks: saved automation definitions.
• Logs/history: what already happened.
• Security report: evidence that the boundaries above still hold.

​

Release gate

• gateway access is private or authenticated
• signer doctor passes
• wallet role separation passes
• Control UI account passkey and separate signer-owned approval are not conflated
• signer policy/RPC hashes, positive caps, and role-specific typed operations match the intended wallets
• fresh Local, WSL2, macOS, Hosting, prior-Hosting migration, cold reboot, rollback, concurrent-send, ambiguous-broadcast, and Local Docker checks pass
• skill wallet grants are narrow
• task templates do not include unexpected wallet or web access
• maintainer primary, standby, and monitor are active if SAT protocol maintenance is enabled
• alerts have at least one real delivery sink configured for production

​

Read next