Skip to content
TruCore logoTruCore

CLI › Guides › Production Bot Basics

Production Bot Basics

Operational hygiene for running automated agents with ATF in production. This guide covers profile separation, receipts retention, and audit workflows.

Prerequisites

  • You have completed the Simulate, Verify, Execute guide and understand the core workflow.
  • You have a mainnet-beta profile with a funded wallet and Helius RPC.
  • Your bot or agent script can call the ATF CLI programmatically.

1. Profile Separation

Use separate profiles for each environment and each bot. This keeps wallet keys, RPC endpoints, and network settings isolated. A misconfigured devnet profile should never accidentally execute on mainnet.

Create production profile

npx @trucore/atf@1.5.1 profile create --name prod-bot-alpha

Create staging profile

npx @trucore/atf@1.5.1 profile create --name staging-bot-alpha

Naming convention: Use a pattern like {env}-{bot}-{identifier} (e.g. prod-bot-alpha, staging-bot-alpha). This makes profile listing and audit trails clear.

2. Receipts Retention

Every simulation produces a receipt. In production, store these receipts durably. They serve as your audit trail and can be re-verified at any time without contacting the ATF server.

At minimum, retain these fields for each transaction:

  • request_id for correlation
  • decision (ALLOWED or BLOCKED)
  • content_hash for integrity proof
  • timestamp for ordering
  • Transaction signature (after send) for on-chain correlation

List receipts

npx @trucore/atf@1.5.1 receipts list

Export receipt as JSON

npx @trucore/atf@1.5.1 receipts verify --receipt last --json

Pipe the JSON output to a file or logging system for durable storage.

3. Audit and Re-verification

Receipts use a deterministic content hash model. Given the same receipt fields, the same hash is always produced. This means you can re-verify any receipt later:

Re-verify a stored receipt

npx @trucore/atf@1.5.1 receipts verify --file ./archived-receipt.json
Receipt: req_prod_20260228_001
Decision: ALLOWED
Content hash (server):  0x4d8f...c3e2
Content hash (local):   0x4d8f...c3e2
Status: Integrity verified

If the hashes match, the receipt is intact. No server contact is needed. This is the foundation of ATF's trustless verification model.

4. Monitoring and Alerting

For production bots, build monitoring around these signals:

  • Decision rate: Track the ratio of ALLOWED to BLOCKED decisions. A sudden spike in blocks may indicate a policy misconfiguration or market condition change.
  • Verification failures: Any hash mismatch should trigger an alert. This should never happen under normal conditions.
  • RPC latency: Monitor rpc ping results. Degraded RPC performance affects the entire workflow.
  • Receipt gaps: If a simulation succeeds but no receipt is stored, your logging pipeline may have a gap.

Production Readiness Checklist

  • ☐Dedicated production profile with mainnet-beta network
  • ☐Helius (or equivalent) RPC endpoint configured and tested
  • ☐Doctor passes with all checks green
  • ☐Receipt storage pipeline in place
  • ☐Verify gate enabled in bot workflow (simulate --verify before send)
  • ☐Monitoring and alerts for BLOCKED decisions and verification failures
  • ☐Pinned CLI version (no @latest)

Using an MCP-compatible agent runtime? TruCore also exposes ATF as a hosted MCP endpoint with five standard tools for policy evaluation and receipt verification.