ddgg blog.

Development of the Seven Split Automated Trading Program for Stablecoin (USDT)

Using the characteristics of stablecoins (USDT) with low exchange rate fluctuations, I created a grid trading bot that steadily generates profits with small amounts.

·~5 min read·1010 views·Updated: Oct 5, 2026
Development of the Seven Split Automated Trading Program for Stablecoin (USDT)

Using the characteristics of stablecoins (USDT) with low exchange rate fluctuations, I created a grid trading bot that consistently generates profits with small amounts.

One day, while listening to the radio, I heard the author of Seven Split and the representative of Split Invest talking, which led to this project.

There are many automated trading bots in the market, but most target highly volatile coins like Bitcoin and Ethereum.
In contrast, I aimed for modest but steady profits in the low-volatility USDT/KRW market (following the strategy of Seven Split..)

The chosen asset, Tether, is a stablecoin pegged to the dollar, which has a low risk of sharp declines and tends to move sideways within a certain range, making it suitable for grid strategies.

Technology Stack

  • Python

  • SQLite (WAL: Write-Ahead Logging mode)

  • Upbit REST API

  • Rich (terminal dashboard)

  • Telegram Bot API (buy/sell notifications)

What is Grid Trading?

Grid trading is a strategy that places buy/sell orders at regular price intervals (grids).
For example, in my case, I set the grid interval to 3 won:

  • Buy at 1,476 won -> Sell at 1,479 won

  • Buy at 1,473 won -> Sell at 1,476 won

  • Buy at 1,470 won -> Sell at 1,473 won

In this way, when the price goes down, it automatically buys in parts, and when it goes up, it sells each position individually. The profit per transaction is not large, but it accumulates by repeating this 24 hours a day.

Profit Structure

Currently in the verification phase, when the buy amount per transaction is set to 50,000 won and the grid interval to 3 won:

Buy: 50,000 KRW + Commission 25 KRW = 50,025 KRW

Sell: 50,101 KRW - Commission 25 KRW = 50,076 KRW

Net Profit: About 51 KRW / transaction

The commission rate on Upbit is 0.05%, so approximately 50 won is spent on commissions for each round trip of buying/selling.
A total profit of 101 won occurs at a 3 won interval, and after deducting the commission of 50 won, about 51 won remains as net profit per transaction.
While it's not a large profit, if many transactions are executed in a day, the profits will accumulate.

Architecture

main.py          ─ Entry point (daemon / dashboard)
├── strategy.py  ─ Grid trading logic
├── upbit_api.py ─ Upbit REST API wrapper
├── database.py  ─ SQLite position/trade management
├── dashboard.py ─ Rich terminal dashboard
└── notifier.py  ─ Telegram notifications
main.py          ─ Entry point (daemon / dashboard)
├── strategy.py  ─ Grid trading logic
├── upbit_api.py ─ Upbit REST API wrapper
├── database.py  ─ SQLite position/trade management
├── dashboard.py ─ Rich terminal dashboard
└── notifier.py  ─ Telegram notifications

To operate 24 hours, the server runs as a systemd service, and when monitoring is needed, it can be run separately in dashboard mode (--dashboard-only) for verification.

Position Lifecycle

Limit buy order → pending_buy (if there is a difference of more than 3 steps, cancel the order)
        ↓ Execution
     active (holding)
        ↓ Limit sell order
   pending_sell (waiting to sell)
        ↓ Execution
      sold (completed, profit confirmed)
Limit buy order → pending_buy (if there is a difference of more than 3 steps, cancel the order)
        ↓ Execution
     active (holding)
        ↓ Limit sell order
   pending_sell (waiting to sell)
        ↓ Execution
      sold (completed, profit confirmed)

All orders are placed as limit orders.

Why Limit Orders?

Initially, I implemented it with market buy + market sell. (I incurred losses here..)
While the logic was simple and it executed immediately, there is a bid-ask spread of about 1-2 won in the USDT/KRW market. When buying at market price, it gets executed at the sell price, and when selling at market price, it gets executed at the buy price. Although I set the grid interval to 3 won, if I incur a loss of 1-2 won due to the spread, there may be no actual margin or even a negative situation.

Intent: Buy at 1,476 won → Sell at 1,479 won (3 won profit)
Actual: Buy at 1,477 won → Sell at 1,478 won (1 won profit, loss after commission)
Intent: Buy at 1,476 won → Sell at 1,479 won (3 won profit)
Actual: Buy at 1,477 won → Sell at 1,478 won (1 won profit, loss after commission)

After switching to limit orders, I was able to execute exactly at the grid price and achieve the intended profit.

Incident Log

Infinite Buy Incident

This was the incident that caused the most significant loss. The SQLite DB became read-only, and after a buy order, an error occurred where it could not record the position. Since the position was not recorded, it kept returning False regarding whether it was the amount bought, causing the bot to repeatedly buy at the same grid.
It ended up buying all the balance in Upbit, resulting in an excess purchase of about 450,000 won.. This caused commission fees and mental shock.

After this incident, I strengthened the DB safety measures.
1. Check DB accessibility every tick
2. Immediately stop the bot if DB write fails
3. Automatically stop after 3 consecutive errors

Grid Interval Optimization

Initially, I started with a 10 won interval, but there were no transactions at all for an entire day..
The 52-week price range of USDT/KRW is about 1,339 to 1,655 won, and the daily fluctuation is usually around 5-15 won, so a 10 won interval was too wide.
When I reduced it to 5 won, transactions began to occur, and I ultimately decided to set it to 3 won.
A 1 won interval incurs more commission (about 50 won for a 50,000 won basis) than the profit, resulting in a loss. The minimum interval considering the commission was about 2 won.

Terminal Dashboard

When running the server in --dashboard-only mode, you can see the rendered dashboard using the Rich library.

When buy/sell transactions are executed, detailed notifications including commissions are sent via Telegram.

Conclusion

Through this project, I once again realized that defensive programming is extremely important in financial systems. In general web services, bugs may only cause user inconvenience, but in financial services, bugs are directly related to money. A single DB write failure led to an excess purchase of 450,000 won, and the difference between market and limit orders resulted in losses of several won per transaction.

Thanks to starting with a small amount from the verification phase, I was able to avoid significant losses, and now it operates stably, accumulating several transactions of 51 won profit each day.

Share
← Back to List