- HOME >
- Yodaka
Yodaka
yodaka(よだか)です。2021年から仮想通貨を触っています。Bot開発もしています。
こんにちは、ぼっちbotterよだかです。 今週の振り返りをざっくりまとめていきます。 今週は「エッジ検証パイプラインの整備とマシン稼働の安定化に注力した1週間」でした。 botを走らせつつ、同時に開発も進めるというスタイルでbotterをしているのですが、私が使っているPC1台ではそれがしんどくなってきたので、新しい機材を注文したというのが本記事執筆時点での現状です。 初めに結論をいうと「今のPCじゃ開発継続はキツいので、新しいPCを注文したよ」ってことです。 今回の記事は、この1週間で何をしていたのか ...
0. まえがき:なぜ 24 時間ランが難しいのか 長時間 ― とりわけ 24 時間連続 ― で暗号資産取引所(今回は Bybit v5)の WebSocket フィードを取り込み、ファイルへロスなく保存し続けるのは意外とハードルが高い作業です。私自身、最初の試行錯誤では 「PC がフリーズする」 や 「突然 Recorder プロセスがいなくなる」 といったトラブルに何度も遭遇しました。本節では、その壁を整理しながら「そもそも何が難しいのか」を俯瞰します。 もう一つ保険積んだ。ある程度知見が貯まってきたの ...
暗号資産の取引ボットを開発するとき、「中央集権型取引所(CEX)用に組んだコードを、そのままオンチェーン DEX に流用できるだろう」と考えがちです。ところが実際には、データ取得の流れから監視体制、リスクガードに至るまで設計思想が大きく異なります。本記事では、CEX ボットと Hyperliquid のようなロールアップ系 DEX ボットを比較しながら、価格フィード、注文執行、監視ポイント、ガス管理などの要点を整理します。まずは“最小限のガード”で素早く運用を始めるアプローチを紹介し、そのうえで段階的に ...
試験録画で Mac がフリーズし、ログも残らず、Parquet 生成はエラー祭り──。「とりあえず動くスクリプト」を Bybit の 24 時間連続レコーダーへ昇華させるまでには、小さなつまずきの連続です。 本記事では、WebSocket ストリームの非同期設計、ファイルローテーション、メモリ圧迫の真犯人探し、そして Makefile での一発自動化──という一連の格闘を、実際に詰まったログと修正版スクリプト付きで振り返ります。 「過学習しがちなバックテスター」「固まる Mac に怯えるトレーダー」「24 ...
こんなに短いコードなのに、一日中泥臭くハマるとは思いませんでした。1分、5分、30分、そして1時間……想定どおりにスムーズに動くと思いきや、サブスクライブのフォーマットミスや0バイトファイル、秒単位のズレ、空のFunding CSV、Fillゼロの即落ち…気づけば夕方。 本記事では、「バックテスト・パイプライン構築のリアル」と題して、1分ランから24時間ランまでの道のりで直面した5つの教訓を、トラブルレスキューの視点も交えてまとめます。開発中のみなさんが同じ罠にハマらないよう、軽いノリでザクっとお届けしま ...
こんにちは。ぼっちbotterよだかです。 今回も過去1週間の振り返りを書いていきます。 ざっくりまとめると「データ集めに奔走した1週間」という感じでした。 「自前の秒足用データくらいサクッと集められるでしょ」という軽い気持ちでコード書き始めて、半日後に1,000行以上のスクリプトになっているので、リファクタしては再び走らせて、、、みたいなことをやっています。 1時間とか6時間とかかけて検証しなければならないので、今回の記事はその合間に書いています。(データ集め中にまとまった時間ができたので思考整理がてら ...
「WebSocketで取引所のストリームを録画するだけだから、すぐ終わるだろう」 そう思って始めたはずのRecorder(レコーダ)開発。しかし実際には、「録れているように見えて録れていない」「一見動いているが、内部で破損している」「例外が出ないままファイルが壊れている」といった**“静かなバグ”**との闘いが続きました。 このブログでは、取引所のpublic streamを長時間・安定・安全に録画するために、筆者が取り組んだ実装改善の記録を5つのポイントに絞ってまとめます。具体的には、gzipフッタの整 ...
マーケットメイカー戦略において、「スプレッドが開いた瞬間にだけ発注する」ロジックは、効率よく期待値を積み上げる上で極めて重要なアプローチです。しかし、その「スプレッドが開いたかどうか」をどう検知し、どのように記録・分析するか?という点については、意外と情報が整理されていません。 本記事では、自作のMarket Maker Botにおいて「秒足クロスによる全約定→即ヘッジ」という手数料ループから脱却するために、板幅(Top-of-Bookのbid/ask差)を基準としたスプレッド判定ロジックを導入するまでの ...
セクション1|はじめに — 秒レベルで精度を上げたかった話 トレード戦略の調整を続ける中で、どうしても無視できなくなってきたものがあった。それは「時間分解能(どれくらい細かく時間軸で物事を測定できるか)」だ。 私は現在、板寄せ系の自動取引戦略を継続開発している。本番環境での稼働も視野に入れつつ、パフォーマンスチューニングを繰り返している段階だが、とある時点でバックテストと実運用の数値が乖離していることに気づいた。 バックテストでは、「このロジックなら Maker fill 比率は高くなるはずだ」と思ったも ...
1. はじめに ─ なぜ “ログと DB の分離” がボット運用の死活を分けるのか 結論:テキストログ と 構造化データ(DB) を “同じ場所/同じ設計思想” で扱うと、いつか必ず ボットが止まるか、データが飛ぶか、どちらかが起こる。 取引ボット――とくに FR (Funding Rate) × Market Making のように保有時間が数秒〜数時間 と振れ幅の大きい戦略では、「1 秒毎に大量に吐き出されるイベントログ」 と「1 取引で 1 行残る実績レコード」 が同居します。 区分特性具体例破綻シ ...