DEV Community: Wataru Suda

GMO Coin API in Python: HMAC signing, post-only limit orders, and the 4 errors that will bite you

Wataru Suda — Mon, 05 Oct 2026 23:30:03 +0000

GMO Coin is one of the larger Japanese crypto exchanges, and its REST API is genuinely pleasant: public endpoints need no key, the docs are bilingual, and the JSON is flat. But the private (authenticated) half has four sharp edges that are not obvious from the documentation, and I hit all four while building a small spot trading bot that runs once a day on about ¥24,000 of my own money.

This post is the client I ended up with, plus the four errors, in the order you will meet them.

If you only want the public half — daily candles, backtesting, no account required — I packaged that separately as a free download: GMO Coin Trend Lab (source also on GitHub). Everything below is about the authenticated half.

The public API: no key, no ceremony

Two base URLs, and the public one needs nothing:

import requests

PUBLIC = "https://api.coin.z.com/public"

def pub(path, **params):
    r = requests.get(PUBLIC + path, params=params, timeout=20)
    d = r.json()
    if d.get("status") != 0:          # note: 0 means success
        raise RuntimeError(f"{path} {d.get('messages')}")
    return d["data"]

print(pub("/v1/ticker", symbol="BTC")[0])
print(pub("/v1/klines", symbol="BTC", interval="1day", date="2026"))

Two things to notice straight away. First, status == 0 means success — not 1, and not the HTTP status code. A failed private call can still come back as HTTP 200 with status: 1 and a messages array. Always branch on the body.

Second, spot symbols are bare tickers: BTC, ETH, XRP. The pair-style symbols (BTC_JPY) belong to the leveraged product, which is a different account with different rules. Sending BTC_JPY to a spot endpoint fails in a way that reads like an auth problem, which will waste twenty minutes of your life.

Signing a private request

The scheme is HMAC-SHA256 over the concatenation timestamp + method + path + body, hex-encoded, with the secret as the key:

import hashlib, hmac, json, time

PRIVATE = "https://api.coin.z.com/private"

def priv(session, key, secret, method, path, body=None, params=None):
    ts = str(int(time.time() * 1000))
    raw = json.dumps(body) if body else ""
    sign = hmac.new(secret.encode(),
                    (ts + method + path + raw).encode(),
                    hashlib.sha256).hexdigest()
    headers = {"API-KEY": key, "API-TIMESTAMP": ts,
               "API-SIGN": sign, "Content-Type": "application/json"}
    r = session.request(method, PRIVATE + path, headers=headers,
                        params=params, data=raw or None, timeout=20)
    d = r.json()
    if d.get("status") != 0:
        raise RuntimeError(f"{method} {path} {d.get('messages')}")
    return d.get("data")

Error 1: signing a body you don't send

Look closely at raw. It is serialized once, used for the signature, and then passed to data=. The tempting version is to build the signature from json.dumps(body) and then let requests serialize it again with json=body. Those two strings differ — requests uses different separators — so the server recomputes a different HMAC and rejects you.

The path in the signature is also the path without the /private prefix and without the query string: /v1/order, not https://api.coin.z.com/private/v1/order?symbol=BTC. Query parameters are not signed, which is why GET endpoints take params while POST endpoints take a signed body.

Error 2: your clock

This one cost me an evening. My Windows PC was running about 16 seconds ahead of the exchange, and every private call came back with:

ERR-5009  The API timestamp is too fast.

GMO rejects timestamps outside a narrow window around server time. If your machine sleeps, dual-boots, or simply has a lazy NTP client, you will drift into it eventually.

You do not need NTP to fix this. Every HTTP response carries a Date header, so you can measure the offset yourself and subtract it when signing:

import email.utils

class Clock:
    def __init__(self, session):
        self.s, self.offset = session, None

    def sync(self, refresh=False):
        """local clock minus server clock, in seconds."""
        if self.offset is None or refresh:
            try:
                t0 = time.time()
                r = self.s.get(PUBLIC + "/v1/status", timeout=15)
                t1 = time.time()
                srv = email.utils.parsedate_to_datetime(r.headers["Date"]).timestamp()
                self.offset = (t0 + t1) / 2 - srv
            except Exception:
                self.offset = 0.0
        return self.offset

Then sign with ts = str(int((time.time() - clock.sync() - 0.5) * 1000)). The extra half second is deliberate: Date has one-second resolution, so biasing slightly into the past is free insurance against landing on the wrong side of the boundary. Round-trip time makes this accurate to roughly ±0.5 s, which is far inside the tolerance.

There is a second-order lesson here that has nothing to do with GMO. My bot treated "cannot authenticate" as "fall back to the dry-run balance", computed equity against a paper ¥10,000 instead of the real balance, concluded it was 58% underwater, and tripped its own kill switch. The exchange was fine; the account was fine; my error handling was not. An auth failure should stop the program, not change its inputs.

Error 3: post-only is a `timeInForce`, not a flag

If you are running any strategy where fees matter, you want to be a maker. On GMO Coin spot, the maker fee is −0.01% (a rebate) and the taker fee is 0.05% — a 6 bp swing per side, which on a small account is the difference between a strategy and a donation.

There is no postOnly: true parameter. You get post-only behaviour by setting timeInForce to SOK:

body = {
    "symbol": "BTC",
    "side": "BUY",
    "executionType": "LIMIT",
    "timeInForce": "SOK",     # post-only: cancelled if it would take liquidity
    "price": "14500000",
    "size": "0.0002",
}
order_id = priv(session, key, secret, "POST", "/v1/order", body=body)

SOK means the order is cancelled outright if it would cross the spread and execute immediately. That is the behaviour you want, but it changes the shape of your code: a post-only order is not a fire-and-forget instruction. You have to place it, poll /v1/activeOrders, and decide what to do when it is neither filled nor resting — typically re-quote one tick behind the touch and try again, with a bounded number of attempts and a hard stop.

My own execution loop places at the best bid (for a buy), waits, re-quotes a few times, and then simply gives up for the day rather than crossing the spread. Missing a day costs nothing on a daily-bar strategy. Paying taker fees on every entry costs about 12 bp round trip, every trade, forever.

Error 4: sizes, ticks, and float formatting

Each symbol has a minimum size, a size step and a price tick, and the API rejects anything off-grid:

SPOT_RULES = {
    "BTC": {"min": 0.00001, "step": 0.00001, "tick": 1},
    "ETH": {"min": 0.0001,  "step": 0.0001,  "tick": 1},
    "XRP": {"min": 1,       "step": 1,       "tick": 0.001},
}

(Check these in your account screen before going live — exchanges change them.)

Two traps in one. First, rounding: round(x, 5) is not the same as rounding to a step, and floats will hand you 0.30000000000000004 at the worst moment. Round to the step explicitly:

def round_step(x, step):
    return round(round(x / step) * step, 8)

Second, formatting. Send strings, and send them without scientific notation. str(0.00001) gives '1e-05' in Python, which the API does not accept:

def fmt(x):
    s = f"{x:.8f}".rstrip("0").rstrip(".")
    return s or "0"

fmt(0.00001)   # '0.00001'  — not '1e-05'

Note also that XRP's minimum order is 1 XRP. I hold 0.9357 XRP in that account from an old purchase, and it is permanently unsellable through the API. It sits in the equity calculation and outside the trading universe, which is its own small lesson in writing position code that tolerates dust.

Putting it together

The full client is about 110 lines and covers assets, active orders, cancel, executions and post-only limit orders. The pieces above are the whole of it — there is no hidden complexity, only the four sharp edges.

The strategy on top is deliberately dull: daily bars, a Donchian 20/10 breakout with a 50-day moving-average filter, long only, no leverage, 1% risk per trade. Over 2018-09 to 2026-09 on GMO daily data, starting from ¥10,000 with 5 bp of cost per side, the backtest gives CAGR 16.9%, Sharpe 1.11, max drawdown −17.7%, across 148 trades. Buy-and-hold BTC at a 20% volatility target over the same window gives CAGR 17.4% with a −35.7% drawdown. So: not "beats buy and hold" — about the same return for roughly half the drawdown, in a backtest, before the next regime arrives. Ranging years (2019, 2022, 2025–26) are flat to slightly negative.

I mention the numbers only so you know what the plumbing is in service of. The plumbing is the transferable part, and the four errors above are exchange-agnostic in spirit: sign what you send, don't trust your clock, know what your venue calls post-only, and never send a float where the venue wants a string.

The daily-bar backtester and data fetcher are free and need no API key: GMO Coin Trend Lab.

If you want the authenticated half as a finished package — the full client, the walk-forward analysis, the daily execution loop with the post-only re-quote logic, and the verification scripts that reproduce every number above — that is the GMO Coin Spot API Toolkit ($29, code + report, no subscription). It is software and research, not investment advice, and it promises no returns.

I built an hourly crypto "market thermometer" from free data, then refused to let it trade

Wataru Suda — Fri, 02 Oct 2026 23:30:03 +0000

Most "AI sentiment trading" projects start by wiring a sentiment score straight into buy and sell decisions. I went through the published evidence first and ended up building the opposite: a sensor that records everything, decides nothing, and has to earn the right to influence a trade.

This is the design, the code for each sensor, and the test each flag must pass.

(The free lite backtester for this system, public API only, no key: GMO Coin Trend Lab, source on GitHub.)

What the evidence actually supports

Social sentiment direction is mostly a same-day correlate, not a predictor. The famous 2011 "Twitter mood predicts the Dow" result did not survive re-examination.
Attention volume (how much people are posting and searching) carries more signal than sentiment direction, and it tends to mark short-term continuation followed by reversal.
LLM headline scoring showed real but rapidly decaying returns in equities, concentrated in bad news. One robust finding: models score better when they cannot see the company name, because what they "know" about the name distracts them.
Extreme perpetual funding marks crowded leverage. The October 2025 liquidation cascade started from exactly that state.

None of that says "buy when the score is high". All of it says "be smaller and more careful when things are hot". So the sensor only ever outputs three hints: halve size, pause new entries, tighten stops.

Sensor 1: funding, no account needed

import statistics, requests

def funding():
    out = {}
    d = requests.get("https://fapi.binance.com/fapi/v1/premiumIndex",
                     params={"symbol": "BTCUSDT"}, timeout=20).json()
    out["binance"] = float(d["lastFundingRate"])
    d = requests.get("https://api.bybit.com/v5/market/tickers",
                     params={"category": "linear", "symbol": "BTCUSDT"}, timeout=20).json()
    out["bybit"] = float(d["result"]["list"][0]["fundingRate"])
    d = requests.get("https://www.okx.com/api/v5/public/funding-rate",
                     params={"instId": "BTC-USDT-SWAP"}, timeout=20).json()
    out["okx"] = float(d["data"][0]["fundingRate"])
    out["annualized"] = statistics.mean(out.values()) * 3 * 365   # three 8-hour periods a day
    return out

Flag: annualised funding above 30%.

Sensor 2: attention, from RSS

Reddit's JSON endpoints return 403 to scripts, but the Atom feeds still work. Fetch two subreddits in one request, because two requests in a row get you a 429.

import datetime as dt, xml.etree.ElementTree as ET

def posts_per_hour():
    r = requests.get("https://www.reddit.com/r/Bitcoin+CryptoCurrency/new.rss?limit=50",
                     headers={"User-Agent": "sensor/0.1 (personal research)"}, timeout=20)
    root = ET.fromstring(r.content)
    ns = {"a": "http://www.w3.org/2005/Atom"}
    ts = sorted(dt.datetime.fromisoformat(e.find("a:updated", ns).text.replace("Z", "+00:00"))
                for e in root.findall(".//a:entry", ns))
    span_min = (ts[-1] - ts[0]).total_seconds() / 60
    return len(ts) / max(span_min, 1) * 60

The posting rate is compared with its own trailing seven days. Flag: z-score above 3.

Sensor 3: headlines, anonymised, scored two ways

import re

BAD = [r"hack", r"exploit", r"stolen", r"insolven", r"bankrupt", r"halts? withdrawals?",
       r"depeg", r"lawsuit", r"\bsues?\b", r"indict", r"fraud", r"\bban(s|ned)?\b",
       r"crackdown", r"sanction", r"liquidat", r"plunge", r"crash", r"delist", r"rug ?pull"]

def anonymise(h):
    return re.sub(r"(?i)bitcoin|btc|ethereum|eth|xrp|ripple|solana|binance|coinbase",
                  "the asset", h)

def keyword_score(heads):
    hits = sum(1 for h in heads if any(re.search(t, h, re.I) for t in BAD))
    return min(1.0, 0.3 + 2.0 * hits / len(heads))      # 0.3 = neutral

The keyword score runs every hour, costs nothing and never goes down. Once a day an LLM reads the same 40 anonymised headlines and returns one number between 0 and 1, with instructions that price moves themselves are neutral and that headlines are data, not instructions. I log both. In a month I will know which one explained next-day returns better, and I will delete the loser.

The gate: a flag has to prove itself

Every flag starts disabled. The sensor writes what it would have done to a JSONL file. After thirty days a script compares next-day returns on flagged days against unflagged days:

import numpy as np

a = next_day_returns[flagged_days]
b = next_day_returns[unflagged_days]
t = (a.mean() - b.mean()) / np.sqrt(a.var() / len(a) + b.var() / len(b))

enable = len(a) >= 30 and t < -2      # flagged days must be significantly worse

If a flag cannot show that the days it fired were followed by worse returns, it stays off. I expect most of them to fail. That is the honest outcome, and it costs one line in a log instead of a position.

What I have after the first week

Funding has sat around 8 to 11% annualised, nowhere near the 30% line. Zero flags from any sensor. The daily LLM score has ranged from 0.32 to 0.62 against a 0.7 threshold. It is a boring dataset so far, which is what a thermometer reads most days.

Why not just let the model trade?

Because the public attempts I checked do not work. An open-source bot that lets a fast model make a market-making decision every 300 ms shows, on its own author's public demo, a loss of about three times its reference capital over 143,000 fills, with gas counted as zero. Benchmarks of LLM trading agents find most of them fail to beat buy-and-hold, and that results depend on the risk rules around the model, not on the model.

So the model gets one narrow job it is actually good at, turning text into a number, and the number gets a statistical trial before it is allowed near money.

The logger and the flag-testing script are packaged as a small kit if you would rather not assemble it: https://wataflow1.gumroad.com/l/sensor-kit (code LAUNCH30 takes 30% off for the first 20 buyers). The free daily-bar backtester it sits beside is here: https://wataflow1.gumroad.com/l/trend-lab-free

Not investment advice.

Your backtest is lying to you: walk-forward analysis and the Deflated Sharpe Ratio in plain Python

Wataru Suda — Tue, 29 Sep 2026 23:30:04 +0000

A backtest answers "what would have happened". The question you care about is "what will happen", and the gap between the two grows with every parameter you try.

I have a simple daily trend-following rule running with real money (small money: about ¥24,000). Before it went live I tried 108 parameter combinations. The best had a Sharpe ratio of 1.46 on the last three years. My fixed, picked-in-advance parameters scored 1.20.

(The free lite backtester for this system, public API only, no key: GMO Coin Trend Lab, source on GitHub.)

Should I switch to the winner? Two tools answer that, and both fit in a page of Python.

1. Walk-forward: only score what the optimiser has not seen

The idea: optimise on a window (in-sample), then trade the winner on the next window (out-of-sample), roll forward, repeat. Stitch the out-of-sample pieces together. That stitched curve is the only performance you are allowed to believe.

import pandas as pd
from itertools import product

grid = list(product([10, 20, 40, 55],      # breakout lookback
                    [5, 10, 20],           # exit lookback
                    [50, 100, 200],        # trend filter
                    [1.5, 2.0, 3.0]))      # ATR stop multiple  -> 108 sets

oos_returns = []
for year in range(2021, 2027):
    is_start, is_end = f"{year-2}-01-01", f"{year-1}-12-31"
    oos_start, oos_end = f"{year}-01-01", f"{year}-12-31"

    best, best_sharpe = None, -9
    for g in grid:
        res = run_backtest(data, params(g), is_start, is_end)   # in-sample only
        if res["sharpe"] > best_sharpe:
            best, best_sharpe = g, res["sharpe"]

    oos = run_backtest(data, params(best), oos_start, oos_end)  # never seen by the optimiser
    oos_returns.append(oos["equity"].pct_change().dropna())

oos = pd.concat(oos_returns)
print("stitched OOS Sharpe:", oos.mean() / oos.std() * 365 ** 0.5)

My result, on daily bars from 2018 to 2026:

Out-of-sample year	Optimised parameters	Fixed parameters (20/10/50/2.0)
2021	+20.2%	+30.0%
2022	−7.5%	−6.2%
2023	+12.0%	+14.2%
2024	+28.7%	+61.9%
2025	+0.7%	+1.2%
2026 YTD	+1.9%	−2.1%

Stitched out-of-sample Sharpe: 0.85, versus 1.11 for the full-period backtest.

Two things to read from this table. The honest number is 0.85, not 1.11 and certainly not 1.46. And the fixed parameters did as well as or better than the re-optimised ones in four years out of six. Re-optimising added nothing. That is a useful negative result: it means the rule is not fragile, and it means I should stop fiddling.

A common sanity metric is walk-forward efficiency: out-of-sample annual return divided by in-sample annual return. Above 0.5 is usually called acceptable, below 0.3 smells like overfitting.

2. Deflated Sharpe Ratio: pay for every trial you ran

Try enough random strategies and one will look brilliant. Bailey and López de Prado's Deflated Sharpe Ratio asks: given that I ran N trials, what Sharpe would the best one show by luck alone, and does mine clear that bar?

from math import sqrt, exp
from statistics import NormalDist

def deflated_sharpe(sr, n_obs, skew, kurt, n_trials, var_trial_sr):
    """sr and var_trial_sr are per-period (daily), not annualised.
    kurt is raw kurtosis (3 for a normal distribution)."""
    N = NormalDist()
    euler = 0.5772156649
    if n_trials > 1:
        expected_max = sqrt(var_trial_sr) * (
            (1 - euler) * N.inv_cdf(1 - 1 / n_trials)
            + euler * N.inv_cdf(1 - 1 / (n_trials * exp(1))))
    else:
        expected_max = 0.0
    denom = sqrt(1 - skew * sr + (kurt - 1) / 4 * sr ** 2)
    return N.cdf((sr - expected_max) * sqrt(n_obs - 1) / denom)

Inputs you need: the daily Sharpe of the strategy you picked, the number of daily observations, the skew and kurtosis of its returns, the number of trials, and the variance of Sharpe ratios across those trials.

With n_trials=1 this collapses to the Probabilistic Sharpe Ratio, the probability that the true Sharpe is above zero given non-normal returns.

My numbers:

PSR against zero: 0.999. The strategy's edge over nothing is statistically solid.
DSR treating all 108 grid points as trials: 0.08. As "the best of 108", the result is not significant at all.

Both are true at once, and the difference is the whole point. If I had chosen my parameters by picking the grid winner, I would have to live with 0.08. I did not. The 20/10/50/2.0 set comes from the published literature and was fixed before I looked at this data, so the first number applies. If you cannot honestly say that, the second number is yours.

Rules I now follow

Log every trial. The DSR needs the count. If you do not know how many things you tried, assume it is a lot.
Fix the walk-forward windows before you start. Tuning the window length is just another parameter search wearing a disguise.
Plan around the out-of-sample number. Mine is 0.85, about +9% a year. That is what goes into my expectations, not 16.9%.
Halve anything published. McLean and Pontiff found anomaly returns drop by roughly half after publication. My rule is a published one.
Change parameters only when the challenger wins out-of-sample by a wide margin. My weekly review requires a Sharpe gap above 0.5 and a win on the most recent held-out year. So far: no changes.

Try it on real data

The free lite backtester that produced the full-period numbers above pulls daily bars from the exchange's public API (no key, no account): https://wataflow1.gumroad.com/l/trend-lab-free

The walk-forward loop and the DSR function shown here, together with the live engine they guard, are in the paid kit on the same store.

Not investment advice. The most valuable output of this exercise was a reason to do nothing.

A 16-second clock drift falsely tripped my trading bot's kill switch. A postmortem.

Wataru Suda — Sun, 20 Sep 2026 23:30:02 +0000

I run a small, deliberately boring trading bot: daily bars, spot only, no leverage, about ¥24,000 of my own money on a Japanese exchange (GMO Coin). It wakes up once a day at 06:05, looks at yesterday's candle, and usually does nothing.

On day six it halted itself and reported a 58% drawdown. My balance had not moved by a single yen.

(The free lite backtester for this system, public API only, no key: GMO Coin Trend Lab, source on GitHub.)

Nothing was lost. No order was sent. But the bug is a good one, because every link in the chain looked reasonable on its own.

The timeline

The PC had been powered off for three days. When it came back, Windows had not yet resynced the clock. It was running about 16 seconds fast.
The scheduled task fired. The bot signed its first private API call with the local timestamp.
The exchange rejected it: ERR-5009 Timestamp for this request is too fast.
My startup code treated "key validation failed" as "no usable key" and fell back to dry-run mode. I had written that fallback on day one so that pasting the wrong kind of key would not crash anything.
Dry-run mode has its own paper balance, ¥10,000, and it shared the same state file as live mode.
The bot computed equity as ¥10,000, compared it with the stored high-water mark of ¥23,900, got a 58% drawdown, and did exactly what it is supposed to do at 30%: flatten and halt.

Because it was in dry-run, "flatten" sent nothing. The halt flag, however, was written to the real state file. The bot would have sat there, halted, until a human noticed.

Why each decision looked fine in isolation

"Fall back to dry-run if the key does not validate." Friendly on day one, when the likely failure is a user pasting the FX key into the crypto slot. Dangerous on day six, when the key is fine and the failure is transient.

"One state file." Simple. Until two modes with different balances write the same high-water mark.

"Halt at 30% drawdown." Correct, and it worked. The kill switch is not the bug. The bug is that a number from one world was compared against a number from another.

Fix 1: sign with the server's clock, not mine

The exchange checks that your timestamp is close to its own. So ask it what time it is. Every HTTP response carries a Date header, and that is accurate enough for a tolerance measured in seconds.

import email.utils, time, requests

PUBLIC = "https://api.coin.z.com/public"

class GmoClient:
    def __init__(self):
        self.s = requests.Session()
        self._offset = None   # local clock minus server clock, in seconds

    def clock_offset(self, refresh=False):
        if self._offset is None or refresh:
            try:
                t0 = time.time()
                r = self.s.get(PUBLIC + "/v1/status", timeout=15)
                t1 = time.time()
                srv = email.utils.parsedate_to_datetime(r.headers["Date"]).timestamp()
                self._offset = (t0 + t1) / 2 - srv
            except Exception:
                self._offset = 0.0
        return self._offset

    def _timestamp_ms(self):
        # the Date header has one-second resolution, so lean half a second early:
        # "slightly slow" is tolerated, "too fast" is rejected
        return str(int((time.time() - self.clock_offset() - 0.5) * 1000))

Two details matter. Take the midpoint of the request so latency does not bias the estimate. And lean slightly early, because this API rejects timestamps from the future more strictly than ones from the recent past.

After this change the bot does not care whether the OS clock is right.

Fix 2: a failed validation must not touch live state

c = GmoClient()
if not c.dry_run:                      # keys are present, so we intend to be live
    try:
        c.assets()
    except GmoError as e:
        log(f"key validation failed, aborting this run without touching state "
            f"(clock offset {c.clock_offset():+.1f}s): {e}")
        return                          # try again tomorrow

if c.dry_run:
    STATE = ROOT / "state_dry.json"    # paper trading lives in its own file

The rule I took away: if the system intended to be live and cannot prove it is live, it should do nothing, loudly. Not "degrade gracefully" into a different mode that shares storage with the real one.

What I check now when writing a fallback

What does the fallback write, and where? If it shares storage with the normal path, it is not a fallback, it is a second writer.
Is the failure I am catching permanent (wrong key) or transient (clock, network, maintenance window)? Transient failures should abort and retry later, not change mode.
Would I notice? The halt was silent until I went looking. The bot now writes a dashboard every ten minutes with a red banner when it is halted.
Can the safety mechanism be fed garbage? A kill switch is only as good as the equity number going into it.

The boring numbers, since people ask

The strategy itself is a 20-day breakout with a 50-day filter and a 2×ATR stop, risking 1% per trade. My backtest on the exchange's own daily data from 2018 to 2026 gives about the same return as volatility-targeted buy-and-hold with roughly half the drawdown, and close to zero in ranging years. Walk-forward out-of-sample Sharpe is 0.85. Its first real trade happened on day eight: 0.0076 ETH, with about ¥240 at risk.

Operational holes scare me more than strategy losses. This one cost nothing, which is the best price to learn at.

If you want to poke at the backtest, the lite version is a free download (public API only, no key needed): https://wataflow1.gumroad.com/l/trend-lab-free

Not investment advice.

I fact-checked 5 viral "my AI bot made money" posts against primary data. None survived.

Wataru Suda — Thu, 17 Sep 2026 15:53:08 +0000

Over the past week my feed filled up with posts of the same shape: someone hands an AI agent fifty-odd dollars, walks away, and comes back to thousands. I run a small, boring, fully logged trading system myself, so I checked five of these claims against primary sources: on-chain pool data, official fee schedules, the projects' own sites and the authors' own public demos.

(The backtester behind the numbers I quote below is a free download, public API only: GMO Coin Trend Lab, source on GitHub.)

I used the same five questions every time:

Is there verifiable evidence, such as a public wallet or trade history?
What does the author gain if you copy them?
Do the post's own rules and fees allow its own first trade?
What daily return does the start and end balance imply, and for how many days in a row?
Can the reader even execute it from where they live?

1. "Mint a yen stablecoin at 1 yen, sell it on a DEX for 3 yen, repeat"

I pulled the live pools. The premium was real: several Uniswap pools priced the coin at 1.7 to 2.1 yen, up about 70% in 24 hours, then down about 20% within the next hour.

The mechanism is legitimate. Issue at par, sell where it trades rich. That is how the peg is supposed to be enforced.

"Repeat" is the part that fails. Every sale pushes the pool price back toward par, so total extractable profit is capped by the USDC sitting in the pool, a few tens of thousands of dollars each. Issuance needs a bank transfer and has a per-issuance limit, so people already holding inventory, and bots, take it first. The hourly decay I measured is exactly that happening.

2. "My bot launches tokens and skims 0.5% of every trade. $52 became $3,292 in 18 hours"

The 0.5% in the post is the trading app's own fee. It goes to the app, not to the token creator. The creator fee on the launchpad's bonding curve is 0.30% according to its public fee page.
To collect $3,240 at 0.30% you need about $1.08M of volume, roughly $180k per token across six tokens. That is graduation-level activity, and graduation rates on that launchpad run between 0.2% and 1.4%.
About 28,000 tokens launch per day, while only 4,000 to 7,000 wallets claim creator fees on a given day, and the top 25 creators took over $745k. Most launches earn nothing.
The launchpad's own co-founder said publicly that creator fees "may have skewed the incentive for users to engage in low-risk activity (coin creation)" and overhauled the scheme in January 2026.

There is a small real effect: sniper bots buy every new launch, so a creator can earn a few dollars with zero organic buyers. A few dollars, not thousands. And the money comes from buyers who, per a study of 200,000+ tokens, profit in fewer than 0.5% of cases once the first 10% of supply is gone.

3. "Autonomous trader: $50 to $420 in five hours" (then it went negative)

The project's own site says "No trades executed". No wallet address, no performance numbers. Unverifiable.

The author's lesson, though, is correct and matches the statistics: finding entries means nothing without exits and risk limits.

4. "A chief of staff and six seated bots took $89 to $7,769"

This one came with paste-ready prompts, which made it easy to check against itself.

The post links a trading app referral twice. That app's referral programme pays the referrer up to 25% of referees' trading fees, in near real time. A high-turnover multi-bot setup is the most profitable thing the author could possibly recommend, win or lose.
The post's own execution rule says a $20 entry against a $0.95 minimum fee is 4.75% and must not be filled. But with an $89 bank and the post's own 6% position cap, the largest ticket is $5.34, which is 17.8% per side. By its own rules the desk could never have placed its first trade.
It says every fill goes through that one app, yet the claimed profit came from prediction markets, which that app does not offer as far as I could find.
The +22% day: 18 books at an average 3.61% of bank is about $4,137 deployed. Making $1,403 on that means +34% per book on average including four losers, with a stated average hold of 22 minutes.

5. An open-source bot that lets an AI model make a market-making decision every 300 ms

This author is honest: no performance claims, no referral links, MIT licence. So I looked at the public demo he links.

Dry-run mode, the real model, 143,535 fills: realised PnL of about minus $144, which the dashboard shows as minus 299% of its reference capital. Gas is booked at zero in dry-run, so live would be worse. The first issue on the repo is titled "It's losing money".

This is adverse selection. A retail market maker gets filled precisely when someone better informed wants the other side. Deciding in 300 ms does not change who is on the other side.

The four-point check

You can run this on any such post in a few minutes:

Is there a public wallet or a trade history link?
Is there a referral link or a paid group?
With the fees stated in the post, can the starting balance place even one trade?
Does the start-to-end balance imply a daily return that must repeat for days?

All three profit-claim posts fail on points 1 and 2 alone.

What I actually run instead

A deliberately dull system: daily-bar trend following on spot crypto at a Japanese exchange, post-only limit orders, no leverage, 1% risk per trade, a hard 30% drawdown stop. My own backtest over 2018 to 2026 shows roughly the same return as volatility-targeted buy-and-hold with about half the drawdown, and flat-to-negative results in ranging years. Walk-forward out-of-sample Sharpe is 0.85. It has made zero trades in its first week because no breakout has occurred, and I count that as working.

It also broke once already. The PC clock drifted 16 seconds ahead of the exchange, signature validation failed, my fallback code computed equity from a paper balance and falsely tripped the kill switch. No orders were sent. I fixed it by syncing the signing timestamp to the server clock and by aborting without touching state when validation fails. Operational holes scare me more than strategy losses.

The code, the full verification numbers including the bad years, and the hourly sensor logger are here if you want to read or run them:

Engine B/C Kit (backtest, walk-forward, live engine): https://wataflow1.gumroad.com/l/engine-bc-kit
Crypto Market Sensor Kit (funding, attention, LLM-scored headlines, plus a script that tests whether the flags mattered): https://wataflow1.gumroad.com/l/sensor-kit

Not investment advice. If a post cannot show you a wallet, assume the screenshot is the product.

DEV Community: Wataru Suda

GMO Coin API in Python: HMAC signing, post-only limit orders, and the 4 errors that will bite you

The public API: no key, no ceremony

Signing a private request

Error 1: signing a body you don't send

Error 2: your clock

Error 3: post-only is a timeInForce, not a flag

Error 4: sizes, ticks, and float formatting

Putting it together

I built an hourly crypto "market thermometer" from free data, then refused to let it trade

What the evidence actually supports

Sensor 1: funding, no account needed

Sensor 2: attention, from RSS

Sensor 3: headlines, anonymised, scored two ways

The gate: a flag has to prove itself

What I have after the first week

Why not just let the model trade?

Your backtest is lying to you: walk-forward analysis and the Deflated Sharpe Ratio in plain Python

1. Walk-forward: only score what the optimiser has not seen

2. Deflated Sharpe Ratio: pay for every trial you ran

Rules I now follow

Try it on real data

A 16-second clock drift falsely tripped my trading bot's kill switch. A postmortem.

The timeline

Why each decision looked fine in isolation

Fix 1: sign with the server's clock, not mine

Fix 2: a failed validation must not touch live state

What I check now when writing a fallback

The boring numbers, since people ask

I fact-checked 5 viral "my AI bot made money" posts against primary data. None survived.

1. "Mint a yen stablecoin at 1 yen, sell it on a DEX for 3 yen, repeat"

2. "My bot launches tokens and skims 0.5% of every trade. $52 became $3,292 in 18 hours"

3. "Autonomous trader: $50 to $420 in five hours" (then it went negative)

4. "A chief of staff and six seated bots took $89 to $7,769"

5. An open-source bot that lets an AI model make a market-making decision every 300 ms

The four-point check

What I actually run instead

Error 3: post-only is a `timeInForce`, not a flag