BitEvo applies the existing Agent Authority & Evidence Audit method to one trading-bot workflow: exchange permissions, pre-trade evidence, exact order/effect confirmation and recovery. The object is the authority chain around execution — not strategy profitability.
The review asks whether capability has moved ahead of evidence, object binding or recovery control. It does not grant exchange access or execution authority.
Inventory read/trade permissions, prove withdrawals are disabled for the scoped bot key, bind access to approved network origins where supported, separate bot capital from the master account, and define key rotation/revocation ownership.
Check how API credentials are provisioned, isolated and redacted. Public scope preparation never accepts API keys, secrets, private keys or wallet seeds.
Map which evidence must be fresh before an order may be proposed: instrument, account, size, market state, liquidity/slippage controls, pair age where relevant, frequency limits and loss/drawdown controls. Thresholds are system-specific, not universal BitEvo defaults.
Separate intent, exchange acknowledgement, open order, partial fill, fill, cancel and resulting position. A successful API response is not treated as proof that the intended market effect occurred.
Test duplicate prevention, stale-state handling, cancel/reconcile paths, kill/hold behavior and restart from a known state. Flattening or key revocation is tested only when separately authorized in a safe environment.
Identify who may expand symbols, accounts, order types, leverage, sizing, execution venues or credential permissions, and require evidence-bound owner approval before authority expands.
The final 10–20 scenarios are agreed in written Rules of Engagement. These reference cases are scope prompts, not evidence that a customer system has been tested.
Expected evidence can include redacted exchange permission screenshots/exports, policy/configuration, logs with secrets removed, sandbox/testnet results and independent state read-back. Withdrawal execution, live-funds trading and production penetration are outside the default scope.
Authority/effect map, evidence contract, scenario results, finding cards, repair backlog and one retest. A key control is Withdraw disabled; other controls include IP allowlisting where supported, isolated sub-accounts, secret isolation/redaction and exact order/fill reconciliation.
can_trade=false. BitEvo does not place orders, connect exchange keys through the public form, execute withdrawals, manage customer capital, promise profit, certify a bot as universally safe, or treat API acknowledgement as proof of a fill. Strategy discovery, backtesting and profitability review are different work.
Use the existing Primary Audit intake. Describe permissions and evidence in redacted form; do not submit API keys, secrets, private keys, wallet seeds or production credentials.
Prepare trading-bot audit scope