Building a Grid Trading Bot on Bithumb
TECH INSIGHT / EXPLAINED
A grid bot places limit orders at predefined price levels and manages the inventory created when they fill. Oscillation can create completed buy–sell pairs; it does not turn every price movement into profit. This design note uses hypothetical numbers, not an account performance claim.
Local execution of the actual project
These captures show the existing project UI or functions executed locally with non-private sample inputs. Each caption states the scope of the execution.
Define the interval before calculating a return
If the reference price is 100 and levels are 98 and 102, each level is 2% away from the reference. Buying at 98 and selling at 102 is a gross return of 4/98 ≈ 4.0816%, not 2%. A different design might buy at 98 and sell at the next level, 100. Record exactly which pair each order belongs to; “gap” alone is ambiguous.
A completed cycle and the inventory left behind
For a hypothetical 10 units bought at 98 and sold at 100, with fees of 0.1% of notional on each side, net realized profit is 10×(100−98)−0.001×10×(98+100)=18.02 quote units. This assumed fee is an arithmetic example, not Bithumb’s current rate. If another 10 units bought at 96 are now marked at 90, their unrealized loss is 60 before fees. Reporting only the 18.02 completed-cycle gain hides a declining total account value.
An order is a state machine
Use planned → submitted → acknowledged → partially filled → filled/canceled/unknown. Place replacement sells only for reconciled net available filled quantity; fees charged in the base asset can reduce it. A timeout after submission means unknown, not failed. Query the exchange before creating another order. Store exchange IDs and strategy/order generation IDs so a restart cannot recreate an entire live grid.
Reset is a migration, not a reset button
Pause new placement, request cancellation, reconcile all terminal states and fills, recalculate available cash and inventory, then build a new grid. A cancellation request can race with a fill. Re-centering does not erase inventory losses. Bound total inventory, outstanding notional, and allowed price range before placing any orders. A range exit should freeze new buys until the chosen risk policy can be applied.
Bithumb integration and the dashboard
Use the documented API version consistently. Query order constraints and fees, round price/quantity to accepted increments, and validate minimum notional after rounding. Begin with a read-only dashboard bound to 127.0.0.1. Any settings/reset endpoint needs authenticated non-GET requests and server-side limits; a hidden button is not authorization. Store keys outside the page, and omit withdrawal privileges. First replay partial fills, late fills after cancel, and restart with existing orders using recorded fixtures.
Documentation and next steps
Content and examples reviewed: 2026-09-29
댓글
댓글 쓰기