cryptobot – BSC trading bot (PoC)

TL;DR

• What it does: CLI + optional web UI for wallets, approvals, swaps (with retries), tx inspection, and basic monitoring.
• Who it’s for: A private playground for execution ergonomics and reliability tactics.
• Biggest result: faster iteration on end-to-end execution flows (metrics depend on RPC quality + liquidity).

Context

I wanted a small, private codebase to prototype BSC/PancakeSwap execution flows end-to-end: wallets, approvals, swaps, and lightweight “watch” tooling.

Constraints: this is intentionally not a public repo. It’s a single-dev PoC focused on iteration speed, not a production trading system (no hosted infrastructure, no “bot-as-a-service”, no secrets committed).

Problem

On-chain execution is latency-sensitive and failure-prone: RPCs can stall, approvals are easy to forget, and manual workflows (tx copy/paste + receipt checking) are error-prone.

Existing approaches didn’t fit what I wanted: either too heavyweight (full trading frameworks) or too opaque (black-box bots). I needed something hackable that makes the execution flow explicit.

Goals (and non-goals)

Goals:

• A CLI that can do the basics quickly: balances, approvals, swaps, tx inspection, and a couple of monitoring loops.
• Experimentation with retry tactics (send/retry with controlled nonce/gas strategy) and multi-RPC connectivity.
• A minimal web API/UI to trigger and observe a buy/sell flow in a more “dashboard-like” way.

Non-goals (optional):

• Production-grade safety guarantees (key management/HSMs, extensive backtesting, strategy research tooling).
• Publishing keys, wallet files, addresses, or private endpoints in docs.

Solution Overview

I built a Python CLI around a small PancakeSwap interaction layer (router/factory/wallet/transactors), then added a “fast swap” retrier for controlled re-attempts.

Separately, I added a lightweight FastAPI service (plus a Vue frontend) to trigger buy/sell orders and poll execution status.

High-level Architecture

[CLI (click)] ------------------------------+
    |                                      |
    | calls                                | calls
    v                                      v
[PancakeSwap interaction layer]       [FastAPI API] <--- [Vue UI]
    | (router/factory/wallet)              |
    |                                      |
    v                                      v
[RPC Connection Pool / Transactors]    [Local file storage for orders/status]
    |
    v
[BSC RPC nodes] --> [PancakeSwap contracts + token contracts]

Stack

Key Implementation Details

Core flow

• Load wallet file (JSON) and derive checksummed address.
• Resolve token address (symbol mapping or checksum address).
• Ensure approval when needed (token allowance to Pancake router).
• Build swap order (input token, output token, amount, optional fixed output).
• Execute via a transactor (normal, multi-conn, or fake/reporter) and track the resulting tx hash.
• Inspect receipt status later with tx command or via API polling.

Design choice: explicit composition

I kept execution logic explicit and modular: “wallet + transactor + router + order” rather than hiding everything behind a single mega-command. It’s more verbose, but it makes it easier to swap in alternative nonce/gas strategies or different RPC selection policies.

Performance / reliability

• Connection pooling: pick “fast” RPC connections for polling/filters and isolate slower nodes.
• Retries: a dedicated fast-swap retrier can re-attempt execution with controlled delays.
• Failure visibility: CLI helpers print tx hashes and a follow-up command to inspect receipts.

Demo / Results

• CLI-driven buy/sell flows (token approve → swap → tx receipt check).
• Monitoring loops (price quotes, transfer-event volume buckets).
• API-driven execution (configure order → execute → poll → sell).

Notes on metrics:

• End-to-end “execute → mined” varies widely; RPC quality and token liquidity dominate.
• The main operational metric was time-to-first-tx-hash (submission speed).

What improved

• Reduced manual steps (approvals, tx lookup, repeated quoting).
• Faster iteration on execution strategies in one contained codebase.

Challenges

• RPC instability and inconsistent latency.
  • Fix: connection pooling + switchable transactors + retry-based execution paths.
  • Outcome: fewer dead ends and faster diagnosis when calls fail.

Lessons Learned

• Execution is mostly “systems engineering”: latency, failure modes, and observability matter as much as contract calls.
• Keeping flows composable (wallet/transactor/router/order) makes experimentation easier.

Future Work

• Add safer config handling and clearer separation of “demo” vs “real” execution modes.
• Improve metrics (structured logs, timestamps, success/failure counters).
• Harden the FastAPI storage model (schema/versioning; avoid hardcoded wallet aliases).