How to Evaluate Non-Custodial Trading Automation
**Answer first:** "Non-custodial" should describe a verifiable custody and signing boundary, not a marketing category or a universal safety guarantee. Before choosing trading autom
Answer first: "Non-custodial" should describe a verifiable custody and signing boundary, not a marketing category or a universal safety guarantee. Before choosing trading automation, confirm where keys live, where transactions are signed, which permissions exist, how releases are verified, what happens on failure, and how every fee is calculated.
Start with the operating model
Products that look similar in a trading interface can have different trust boundaries. A useful comparison begins with the operating model rather than a list of "best" vendors.
| Operating model | Questions to verify | Typical trade-off |
|---|---|---|
| Local desktop client | Does signing stay on the device? How is the installer verified? | More device and update responsibility for the user |
| Browser application | Which wallet permissions are requested? What can the web origin initiate? | Lower setup friction with browser and origin dependencies |
| Messaging bot | Who creates and stores the bot wallet or signing secret? | Convenient commands can hide a wider custody boundary |
| API-connected service | Where are API credentials stored and which actions can they authorize? | Automation depends on credential scope and server controls |
| Self-built framework | Who maintains dependencies, infrastructure, monitoring, and incident response? | Maximum control with an ongoing engineering burden |
None of these labels proves that a product is secure. The architecture only tells you what evidence to request.
What non-custodial should let you verify
A meaningful claim should answer four questions:
- Where is the signing key generated?
- Can the key or an equivalent signing capability leave the user's boundary?
- Which process constructs and signs a transaction?
- How can the user revoke permissions and stop execution?
A connected wallet is not enough evidence. A platform may avoid holding the raw private key while still receiving broad approvals, delegated credentials, session keys, or API permissions. Review the complete authorization path.
Security and release checklist
| Control | Evidence to request |
|---|---|
| Key custody | A documented signing flow and storage boundary |
| Permissions | Exact wallet, token, contract, API, and filesystem permissions |
| Release provenance | Official download location, version history, checksum, and signing status |
| Updates | How update authenticity is checked and whether rollback is possible |
| Network behavior | RPC, relay, telemetry, update, and support endpoints contacted |
| Failure controls | Spending limits, slippage limits, cancellation, fallback, and stop behavior |
| Incident response | Security contact, disclosure process, logs, and recovery guidance |
| Fees | Trigger, basis, exclusions, network costs, and dispute path |
Treat screenshots and marketing copy as orientation, not proof. Verify claims against current official documentation and, where possible, reproduce the behavior in a controlled environment.
Test the failure path, not only the happy path
Simulation can help expose reverts, approval mistakes, state changes, and fee assumptions before signing. It cannot reproduce every future block, provider outage, reorganization, malicious dependency, or market movement.
A responsible evaluation should include:
- an unavailable RPC or relay;
- an expired quote or changed state;
- insufficient balance or allowance;
- a transaction that fails simulation;
- a transaction that is accepted by an endpoint but not included;
- a lost network connection;
- a revoked permission;
- a stop or cancellation request.
Document the expected behavior for each case before moving from evaluation to live execution.
Where FRB fits
FRB Agent is a Windows desktop execution assistant for user-configured workflows. Its product documentation states that signing material remains local to the user's environment. FRB is not a wallet, exchange, validator, builder, block engine, or general private-RPC service.
The current release page publishes the installer filename and checksum and states the current code-signing status. Users should verify those release facts before installation. The pricing and risk pages define the fee basis and the costs or losses that can still occur.
These statements describe FRB's documented operating model. They do not establish that FRB is the best choice for every user or that local execution removes smart-contract, market, device, configuration, network, or operational risk.
How to compare candidates fairly
Use the same test case, device class, network conditions, transaction type, and observation window for every candidate. Separate measured facts from product claims.
| Decision area | Fair comparison method |
|---|---|
| Custody | Trace key creation, storage, signing, export, and revocation |
| Reliability | Test documented failure scenarios repeatedly |
| Latency | Measure the same path locally and publish the methodology |
| Fees | Calculate the complete cost from official terms and receipts |
| Support | Verify support channels and incident procedures |
| Coverage | Test the specific chain, contract, and route you need |
| Privacy | Inspect documented data collection and actual network requests |
Do not infer profitability from latency, inclusion, or simulation results. Profitability depends on market conditions, strategy, fees, competition, execution, and risk.
Methodology and limitations
This guide provides a due-diligence framework, not a vendor ranking. It intentionally avoids third-party price, performance, custody, and feature claims that were not revalidated from primary sources on the review date. Product behavior and terms can change after publication.
FRB-specific statements are linked to the current product, security, pricing, and release pages. Readers evaluating another product should apply the same questions to that provider's current official documentation.
Next step: Use the FRB Security checklist as a model for documenting the custody, permission, release, and failure boundaries of any candidate.
Frequently asked questions
Does a wallet-connect button prove that a tool is non-custodial?
No. Verify where keys are created and stored, where signing happens, what permissions are granted, and whether access can be independently revoked.
Is local execution automatically safe?
No. Local execution can reduce a custody dependency, but users must still verify the installer, protect the device, review permissions, and test failure paths.
Should products be ranked by advertised speed?
No. Compare locally reproducible measurements together with custody, permissions, fees, reliability, support, and release provenance.
Related Articles
Further reading & tools
Discussion
No notes yet. Add the first observation, or share the link with your team on X (@MCFRB).