Transparency & Safety Report 2026: Why Experts Trust FRB Agent

Answer first — FRB Agent's 2026 safety posture rests on three architectural choices that are individually verifiable, not just claimed: (1) non-custodial by design — the desktop agent runs locally, private keys are decrypted into the agent's address space and never leave the user's hardware; the dashboard sees telemetry, never keys; (2) Authenticode-signed Windows builds with SHA-256 hashes published on the Releases page, so users can cryptographically verify the binary they run matches what FRB Labs built; (3) simulation-gated execution — every live send goes through fork-replay first, so reverts and revert-causing trades are caught in software before any real ETH leaves the wallet. Beyond these, the agent ships strategy-level safeguards (slippage caps, per-trade gas budget, per-session ETH budget, canary sizing) by default, and /trust plus /vulnerability document how to audit and how to report. This report is structured so a sceptical reader can verify each claim independently rather than take our word for it.

Mastery path

• Risk management for MEV trading bots
• Crypto trading bot security best practices (2026)
• Desktop vs Telegram security revolution
• Safety & transparency report (current)
• Slippage & budget guards

Architecture: why "non-custodial" actually means something here

The single biggest security choice FRB Agent makes is the local-execution architecture. To make this tangible:

• Where the private key lives. Encrypted with Windows DPAPI on disk. Loaded into the agent's address space at session start. Cleared from memory at exit. Never sent over the network.
• Where transactions are signed. Locally, by the agent, using the loaded key. The signed-bytes payload is what leaves the machine — not the key.
• What the dashboard at /app sees. Telemetry: hostname, region, uptime, recent bundle outcomes, latency snapshots. None of these include the key.
• What FRB infrastructure stores. Account-level metadata (subscription status, profit-fee accounting), telemetry, support tickets. No private keys in any backend system.

This is verifiable in two ways: behaviourally (block the agent's outbound network and watch which calls fail), and statically (the agent's binary can be inspected and the key-handling code traced — Authenticode verification ensures the binary you inspect is the one being run).

Compare this to a Telegram bot or cloud-hosted bot, where you literally hand the private key to the provider's servers. There's no architectural choice that recovers from that delegation; the provider has the key.

Verification: what users can confirm themselves

Two checks every user can run before installation:

SHA-256 against published hash

powershell

Get-FileHash .\FRB-Setup-X.Y.Z.exe -Algorithm SHA256
Copy

The output hash must match the value published on /releases for that version. A mismatch means the file on disk is not the file FRB published — do not run it. This catches supply-chain tampering between the FRB build server and the user's hard drive.

Authenticode signature

Right-click the .exe → Properties → Digital Signatures.

• Signer must be "FRB Labs Ltd."
• Certificate chain must validate to a trusted root.
• Digest algorithm: SHA256.

A signature signed with anything other than FRB Labs Ltd. is a phishing attempt. A signature that fails to validate often means an out-of-date Windows root-certificate store; run Windows Update first, then re-check.

The full walkthrough is in Windows setup: verify SHA-256 & start with simulation.

Simulation as a safety control

The agent's simulation engine isn't a feature — it's a safety control. Every live send first runs as a fork-replay against current chain state, catching:

• Reverts from L1-data-fee underestimation on OP Stack chains.
• Slippage from cross-DEX path changes between strategy entry and signing.
• Honeypot tokens with non-standard transfer or sell behaviour.
• Gas-oracle drift if base fee moves between simulate and would-be-send.

A trade that fails simulation never enters the live path. This converts a class of "lost gas to a bad trade" failures into "rejected the trade in software, no on-chain cost."

Strategy-level safeguards shipped by default

Beyond the architecture and the simulation, every strategy enforces:

• Slippage cap per pool class (tighter on stablecoins, wider on volatile pairs).
• Per-trade gas budget — reject the send if priority fee exceeds the configured cap.
• Per-session ETH/native budget — strategy stops itself when cumulative spend hits the cap.
• Canary sizing for new strategies (1/10× until 50 trades show <10% realised-vs-sim gap).
• Public mempool fallback OFF by default — opt-in, not opt-out.

These are configured at the agent level rather than at the "I'll remember" level — they're enforced regardless of operator discipline.

Operational transparency

The infrastructure side:

• Status page at /status for current chain reachability and relay health.
• Vulnerability disclosure policy at /vulnerability — how to report a security finding and what response timelines look like.
• Trust verification at /trust — independent third-party signals (signed-build attestations, on-chain accounting verification, public release artefacts).
• Releases at /releases — every build, with its published SHA-256, available for verification before install.

Common security-related questions

"Can FRB withdraw funds from my wallet?" No. The agent uses your private key to sign transactions you've authorised through the strategy config. There's no path that lets FRB sign a withdrawal on your behalf because the key never leaves your machine.

"What if FRB's servers get hacked?" The dashboard, telemetry backend, and support systems are sensitive but contain no private keys. A breach there is account-data exposure (similar to any SaaS), not fund exposure. Your wallet remains under your control on your hardware.

"Has FRB been audited?" A third-party security audit was scoped for Q2 2026; report publication will be linked from this page when complete. Until then, the architecture is structured for self-verification — Authenticode-signed binaries with published hashes, deterministic build process documented for reproduction.

"What happens if I lose my Windows machine?" Same as any non-custodial setup: if you have your seed phrase / private key backed up off the machine, you can recover the wallet on a new device. If your only copy of the key was on the lost machine, the funds are unrecoverable. This is intrinsic to non-custodial design — there's no centralised system that can recover keys for you.

Reporting and disclosure

If you find a security issue:

1. Do not publish details publicly first.
2. Submit through /vulnerability with reproducible steps.
3. We aim for first response within 48 hours and a fix within bounded timelines depending on severity.

Working with FRB on a security finding doesn't waive any of the user's rights — including the right to publish after coordinated disclosure.

References

• FRB Releases & published SHA-256
• FRB Vulnerability disclosure
• FRB Trust verification
• Microsoft: Authenticode signature verification