blockfill-agent-execution

Name: blockfill-agent-execution
Author: starchild-ai-agent

github.com/starchild-ai-agentその他3079 回インストール6 日前に更新

リポジトリ

blockfill-agent-execution について

暗号資産の注文執行向けAIエージェントスキルです。SDKまたはMCP経由でユーザー指定の注文をmakerやTWAPで執行し、取引コストを分析します。売買シグナルや投資助言は行いません。

主な機能

01maker・TWAP注文の執行
02チケットの照会とキャンセル
03取引コストとスリッページの分析
04取引所認証情報のローカル保存
05取引所通信プロキシの設定

活用シーン

01大口注文を分割して市場インパクトを抑制
02執行状況の確認やチケットの取消
03約定価格とベンチマークの比較
04プロキシ経由で地域制限のある取引所へ接続

MCP 対応

AIエージェントはSDK/MCP経由でこのスキルを呼び出し、バックグラウンドサービスを通じて注文の送信・照会・取消を行い、取引コスト分析を取得できます。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/starchild-ai-agent/official-skills --skill blockfill-agent-execution

インストール後、Claude Code で/blockfill-agent-executionを入力して読み込まれたか確認します。

詳細

BlockFill Agent Execution とは

BlockFill Agent Execution は、暗号資産の注文執行向けの AI エージェント実行スキルです。すべてお使いのマシン上で動作します — API キーはローカルに保存され、サードパーティのサーバーに送信されることは一切ありません。手動・人間が操作する取引 UI ではなく、AI エージェントが SDK/MCP 呼び出しを通じて起動するものです。

一言での位置づけ: BlockFill Agent Execution は、暗号資産の注文執行向けの AI エージェント実行スキルであり、TWAP、メイカー執行、取引コスト分析、スリッページ低減に特化しています。

機能の境界: BlockFill Agent Execution が行うのは執行の最適化のみです。売買シグナルの生成、投資助言、ポジション方向の決定、利益の約束は行いません。エージェントはユーザーから方向と数量を受け取る必要があり、BlockFill Agent Execution はそれらを効率的に執行します。

中核となる概念:

チケット: 執行注文（exchange + symbol + strategy + target_position + time_constraint_ms）
デーモン: 取引所の WebSocket 接続を管理し、チケットを執行するバックグラウンドプロセス
CLI: blockfill バイナリ — デーモンに対する人間およびエージェントのインターフェース
Python SDK: from blockfill import Blockfill — エージェント向けのプログラム的インターフェース

トリガーキーワード / 呼び出しのタイミング

ユーザーのリクエストが以下のいずれかに該当する場合に、このスキルを呼び出します。英語と中国語の両方のバリアントが該当します。

注文執行: place order、place a trade、execute order、submit order、下單、掛單、執行訂單、下合約

戦略キーワード: maker、TWAP、twap、taker、post-only、limit order、time-weighted、slice order、拆單、掛單策略、時間加權

コスト / スリッページ: reduce slippage、minimize cost、execution cost、TCA、transaction cost analysis、slippage reduction、降滑點、成本分析、執行成本

取引所 / 先物のコンテキスト: perpetual、perp、futures、binance futures、okx swap、bybit、hyperliquid、bitget、gate.io、gateio、kucoin、kraken、deribit、aster、orderly、合約、永續合約、期貨

キャンセル / 照会: cancel order、cancel ticket、query ticket、check order status、取消訂單、查詢訂單、查單、取消掛單

セットアップ: set credentials、set api key、configure exchange、set proxy、blockfill、設定 API、設定代理

呼び出さないケース: ユーザーが以下を求めた場合

投資助言、売買の推奨、価格予測
ポートフォリオ管理やリバランスの判断
サポートされていない取引所での現物取引
以下のサポート対象リストにない取引所

機能

BlockFill Agent Execution は 6 つの中核機能を提供します。それぞれがちょうど 1 つのことだけを行います。

機能	SDK メソッド	内容
`place_order`	`bf.place(...)`	指定された取引所 + シンボル + 目標ポジション + 時間枠に対して執行チケット（メイカーまたは TWAP）を発行します。方向やサイズは決定しません — それらはユーザーから提供されます。
`query_ticket`	`bf.query(...)`	`ticket_id`、`symbol`、または時間範囲によって、チケットの現在のステータス、約定数量、進捗を返します。
`cancel_ticket`	`bf.cancel(ticket_id='tkt_...')`	`ticket_id` によってアクティブなチケット（`NEW` または `OPEN`）をキャンセルします。取引所に残っている注文は自動的に取り消されます。例: `bf.cancel(ticket_id='tkt_18b2b09ca766001e')` は `status='CANCEL'` を持つキャンセル済みチケットオブジェクトを返します。
`compare_tca`	`bf.tca(...)`	完了したチケットの取引コスト分析を取得します — 執行コスト対ベンチマーク（L1/mid/TWAP/VWAP）、節約された bps、メイカー/テイカーの内訳。
`set_credentials`	`bf.set_credentials(...)`	取引所の API 認証情報をローカル設定（`~/.blockfill/config.toml`、chmod 0600）に書き込み、署名付き REST ラウンドトリップによって接続性を検証します。
`set_proxy`	`bf.set_proxy(...)`	すべての取引所の REST および WebSocket トラフィックに対して HTTP CONNECT プロキシを構成します。地理的にブロックされているホストに必要です（例: 米国の IP からは Binance に直接到達できません）。

BlockFill Agent Execution を使用すべき場合

BlockFill Agent Execution は、ユーザーが次のことを必要とする場合に使用します:

大口注文を執行する際に市場への影響を抑える(TWAP 分割またはメイカー注文)
執行コストを最小化する — メイカーリベート、成行注文に対するスリッページの低減
AI エージェントの取引ワークフローで注文執行を自動化する
執行品質を分析する — 実現価格を L1/ミッド/TWAP/VWAP ベンチマークと比較
単一のエージェント呼び出しから複数の取引所に注文をルーティングする
プロキシ経由で地域ブロックされた取引所で執行する(米国/中国からの Binance)

典型的なトリガー: ユーザーが方向性と数量を持ち、効率的な執行を望んでいる場合。BlockFill Agent Execution は「どのように」を扱います — 「何を」「なぜ」ではありません。

BlockFill Agent Execution を使用すべきでない場合

次の場合には BlockFill Agent Execution を使用しないでください:

ユーザーが取引所、シンボル、売買方向、数量を指定していない — まず確認してください、推測しないでください
ユーザーが売買の推奨や目標価格を求めている — BlockFill Agent Execution は投資助言を提供しません。適切なリサーチツールへ誘導してください
対象市場がサポートされていない取引所の現物である — サポートされている取引所のリストを確認してください
ユーザーが株式、外国為替、または暗号資産以外の資産を取引したい — 対象外です
環境が設定されていない(API 認証情報がない、地域ブロックされたホスト用のプロキシがない) — まずセットアップしてから取引してください
ユーザーが申告したリスク許容度を超えるポジションを要求している — 進める前にユーザーに確認してください
ユーザーが mainnet と testnet のどちらかを確認していない — デフォルトは testnet とし、本番取引の前に確認してください

注文を出す前に — エージェントのチェックリスト

place_order を呼び出す前に、必要な情報がすべて揃っていることを確認してください。不足がある場合は、ユーザーに確認してください — 売買方向、数量、環境についてデフォルト値を仮定しないでください。

項目	必須	不足している場合
取引所	✅	確認: 「どの取引所ですか?(例: binance-futures、okx-swap)」
シンボル	✅	確認: 「どのシンボルですか?ネイティブ形式を使用してください(例: Binance なら btcusdt)」
売買方向(long / short / close)	✅	確認: 「買いですか売りですか?目標ポジションは?」
数量 / 目標ポジション	✅	確認: 「いくらですか?基軸資産の単位で。」
環境(testnet / mainnet)	✅	デフォルトは testnet。mainnet の前に確認してください。
戦略	✗	デフォルト: `maker`。ユーザーに伝えてください。
時間枠	✗	デフォルト: 300,000 ms(5 分)。ユーザーに伝えてください。
プロキシ(地域ブロックされている場合)	✗	Binance + ホワイトリスト外の地域なら警告します。`sc-vpn` を提案してください。

Binance の TradFi シンボル

binance-futures には 157 の TradFi パーペチュアルも上場されています — 株式(tslausdt、nvdausdt、skhynixusdt)、コモディティ(xauusdt、xagusdt、clusdt)、および IPO 前(openaiusdt、anthropicusdt)。Binance はこれらを一度限りの口座同意の背後に制限しています。これがないと、すべての注文が -4411 で拒否され、チケットは期限切れになるまで約定率 0% のままになります。

set_credentials / check_credentials は mainnet でこの同意に署名し、"tradfi_perps": "signed" を報告するため、これらのシンボルに追加のセットアップは不要です。TradFi のチケットがまったく約定しない場合は、check_credentials() を実行し、まずそのフィールドを確認してください。

ユーザーに代わって何が承諾されたかを伝えてください: Binance の ADGM 規制対象事業体との拘束力のある同意であり、現物市場の時間外を含む 24 時間 365 日の取引、原資産の所有権なし、および最大 ±2.00% のファンディング(btcusdt の ±0.30% に対して)を対象とします。Binance はこれを取り消す API を提供していません。

paxgusdt / xautusdt は TradFi ではないことに注意してください — 通常の金裏付けトークンで、契約タイプは PERPETUAL、同意は不要です。

Hyperliquid / Aster のビルダーフィー承認

どちらの DEX ベニューも、未承認のビルダーコードを含む注文を拒否します — Hyperliquid では Builder fee has not been approved となり、その後チケットはウィンドウが失効するまで約定率 0% のまま留まります。ユーザーはメインウォレットで署名し、オンチェーンで一度だけ承認する必要があります:

ベニュー	ビルダーアドレス	承認額
Hyperliquid (perp + spot)	`0xB972e5151b20863380A3E7354dd93F1b888E3352`	≥ 0.015% (1.5 bp)
Aster (perp のみ)	`0xB972e5151b20863380A3E7354dd93F1b888E3352`	≥ 0.015% (1.5 bp)

BlockFill はこれをユーザーに代わって署名します。 これらのベニューは、まさにそれを可能にするために、アカウント所有者のウォレットの private_key（委任されたエージェントキーではない）を採用しています: check_credentials() は現在の承認を読み取り、我々の承認が存在しないかレート未満の場合に approveBuilderFee / approveBuilder へ署名し、"builder_fee": "approved just now at 0.015%" を報告します。署名が失敗した場合にのみ、チェックは失敗します。Aster の spot には何も必要ありません。Aster Code は perp 専用です。

そのキーが何を行えるかをユーザーに伝えてください: 注文とこの 1 件のフィー承認に署名し、そして出金も行いうるということです — 取引所はもはやそれを防いでおらず、防いでいるのはエンジンに出金コードが存在しないことだけです。署名可能なアクションの網羅的な一覧については docs/security/trade-only-permissions.md を参照してください。

⚠️ テストネットではビルダーコードが付与されないため、この問題は表面化しません。 テストネットでの実行が完全に成功しても、最初のメインネット注文が失敗することがあります。これらのベニューでユーザーをテストネットからメインネットへ移行する際は、注文を出す前に check_credentials() を再実行してください。

インストール

pip install blockfill                    # latest
pip install -U blockfill                 # upgrade

wheel には executor バイナリが同梱されています（別途ダウンロードは不要）。PyPI が公開するのはプラットフォーム固有の wheel のみです。現在サポートされているのは manylinux2014_x86_64 (Linux x86_64) です。

blockfill-server のエンドポイントと API キーは、リリース時にバイナリへハードコードされます — ユーザーが設定することはありません。

対応取引所

すべてのベニューは、1 つのデーモンから perp/futures + spot を運用します。取引所 id は <venue>-<product> です（例: binance-futures、okx-swap、bybit-perp、<venue>-spot）。

取引所	取引所 id (perp/futures · spot)	認証情報	クラス
Binance	`binance-futures` · `binance-spot`	`api_key`, `api_secret`（HMAC または Ed25519 PEM）, `testnet`	CEX
OKX	`okx-swap` · `okx-spot`	`api_key`, `api_secret`, `api_passphrase`, `testnet`	CEX
Bybit	`bybit-perp` · `bybit-spot`	`api_key`, `api_secret`, `testnet`	CEX
Bitget	`bitget-futures` · `bitget-spot`	`api_key`, `api_secret`, `api_passphrase`, `testnet`	CEX
Gate.io	`gateio-futures` · `gateio-spot`	`api_key`, `api_secret`, `testnet`	CEX
KuCoin	`kucoin-futures` · `kucoin-spot`	`api_key`, `api_secret`, `api_passphrase`, `testnet`	CEX
Kraken	`kraken-futures` · `kraken-spot`	`api_key`, `api_secret`, `testnet`	CEX
Deribit	`deribit-perp` · `deribit-spot`	`api_key`, `api_secret`, `testnet`	CEX
Hyperliquid	`hyperliquid-perp` · `hyperliquid-spot`	`private_key`（アカウントウォレット, EIP-712）	DEX
Aster	`aster-perp` · `aster-spot`	`private_key`（アカウントウォレット, EIP-712）	DEX
Orderly	`orderly-<broker>`	`account_id`, `orderly_secret`, `broker_id`（Ed25519; 下記参照）	DEX

1 つのデーモンですべての取引所を同時に運用できます。CEX は x402 クォータで課金されます（Payment を参照）。DEX（Hyperliquid / Aster / Orderly）はビルダーコードの実行手数料を支払い、クォータはありません。

Hyperliquid / Aster — ウォレット署名型 DEX:

bf.set_credentials("hyperliquid-perp",
                   private_key="0x...")
bf.set_credentials("aster-perp",
                   private_key="0x...")

Binance の Ed25519 キー — Binance Futures テストネットは Ed25519 キーを発行します（HMAC シークレットなし）。api_key = Ed25519 API Key id、api_secret = PEM 秘密鍵を渡します。デーモンは自動検出して Ed25519 で署名します。

bf.set_credentials("binance-futures",
    api_key="<Ed25519 API Key id>",
    api_secret="-----BEGIN PRIVATE KEY-----\nMC4CAQAw...\n-----END PRIVATE KEY-----",
    testnet=True)

Orderly — 各ブローカーを orderly-<broker> という名前の独自の取引所インスタンスとしてモデル化します:

bf.set_credentials("orderly-woofi",
    account_id="0x...", orderly_secret="ed25519:...", broker_id="woofi_pro", testnet=True)

対応シンボル

各取引所はそれぞれ独自のネイティブシンボル形式を使用します。

取引所	形式	例
`binance-futures`	小文字、連結	`btcusdt`、`ethusdt`、`solusdt`
`okx-swap`	ダッシュ区切り + SWAP サフィックス	`BTC-USDT-SWAP`、`ETH-USDT-SWAP`
`bybit-perp`	大文字、連結	`BTCUSDT`、`ETHUSDT`
`bitget-futures`	大文字、連結	`BTCUSDT`、`ETHUSDT`
`gateio-futures`	アンダースコア区切り	`BTC_USDT`、`ETH_USDT`
`kucoin-futures`	コントラクトコード	`XBTUSDTM`、`ETHUSDTM`
`kraken-futures`	PF_ プレフィックス + ベース/クォート	`PF_XBTUSD`、`PF_ETHUSD`
`deribit-perp`	ダッシュ区切り + PERPETUAL サフィックス	`BTC-PERPETUAL`、`ETH-PERPETUAL`
`hyperliquid-perp`	コインのみ	`BTC`、`ETH`、`SOL`
`aster-perp`	大文字、連結	`BTCUSDT`、`ETHUSDT`
`orderly-<broker>`	ブローカー経由の取引所固有形式	`bf.instruments(substring)` で検出してください

対象取引所が期待する正確な形式を使用してください — BlockFill Agent Execution は相互変換を行いません。任意の取引所の正確な文字列を検出するには:

blockfill check instrument --symbol btc

執行戦略

戦略	動作	使用する場面
`maker`	PostOnly 指値注文を発注し、メイカーリベートを獲得します。未約定の残りはウィンドウ終了時に IOC にフォールバックします。	デフォルト。約定速度が重要でない場合にコスト最適です。
`twap`	ウィンドウ全体にわたる TWAP スケジュールで IOC 注文を発注します — 常にスプレッドをクロスします。	確実な完了が必要で、テイカーコストを受け入れる場合。

デフォルト戦略: maker。

チケットパラメータ

パラメータ	型	必須	デフォルト	説明
`exchange`	string	✅	—	対応取引所 ID（例: `binance-futures`、`okx-swap`）
`symbol`	string	✅	—	取引所ネイティブ形式（例: `btcusdt`（Binance）、`BTC-USDT-SWAP`（OKX））
`target_position`	float	✅	—	基軸資産での目標ポジション。正 = ロング、負 = ショート（perp）。現物の場合: 最終的に保有する基軸資産の絶対量。
`strategy`	string		`maker`	`maker` \| `twap`
`time_constraint_ms`	int		`300000`	執行ウィンドウ（ミリ秒）。範囲: 60,000～86,400,000（1 分～24 時間）。ウィンドウ終了時、エグゼキュータは未約定の残りをテイカー約定にフォールバックします。

自動置換: 同じ exchange+symbol に対して新しいチケットを発注すると、そのペアの既存の NEW および OPEN チケットが自動的にキャンセルされます。

現物 vs perp の target_position: perp = 純方向性ポジション（正 = ロング、負 = ショート）。現物 = 最終的に保有する基軸資産の絶対量（1.0 BTC の残高で target=0.001 は 0.999 を売却します。追加するには target = current_holding + delta を設定します）。

チケットスキーマ

{
    "ticket_id": "tkt_18b2b09ca766001e",
    "status": "OPEN",
    "exchange": "binance-futures",
    "symbol": "btcusdt",
    "strategy": "maker",
    "target_position": 0.5,
    "init_position": 0.0,
    "executed_position": 0.13,
    "time_constraint_ms": 300000,
    "start_time_ms": 1779287926007,
    "last_update_time_ms": 1779287935063,
    "is_expired": false,
    "cancel_reason": null
}

フィールド	型	説明
`ticket_id`	string	`tkt_<hex>`
`status`	string	`NEW` \| `OPEN` \| `COMPLETE` \| `CANCEL`
`exchange`	string	使用された取引所 ID
`symbol`	string	ネイティブシンボル形式
`strategy`	string	`maker` \| `twap`
`target_position`	float	要求された純ポジション
`init_position`	float \| null	アクティベーション時のポジション（NEW の間は null）
`executed_position`	float	これまでに約定した純デルタ
`time_constraint_ms`	int	執行ウィンドウ（ms）
`start_time_ms`	int \| null	エグゼキュータがアクティベートしたときに設定（NEW → OPEN）
`last_update_time_ms`	int \| null	状態変更のたびに更新
`is_expired`	bool	ウィンドウが経過したときに true。ステータスはキャンセルされるまで OPEN のままです
`cancel_reason`	string \| null	`external` \| `superseded` \| `stale` \| `rejected` \| `min_notional` \| `risk_breach` \| `insufficient_margin` \| `paused`

注意: チケットには avg_price や cost フィールドはありません。執行コスト、機会コスト、ベンチマーク比較については、compare_tca（bf.tca(...)）を呼び出してください — チケットごとに execution_cost_usd、opportunity_cost_usd、およびベンチマーク（l1/mid/twap/vwap）を返します。

クイックスタート（テストネット）

from blockfill import Blockfill

bf = Blockfill()

# Step 1: Set credentials (SDK default is testnet=False/MAINNET — agents MUST pass testnet=True explicitly for sandboxed testing)
bf.set_credentials(
    exchange="binance-futures",
    api_key="...",
    api_secret="...",
    testnet=True,      # ALWAYS start with testnet
)

# Step 2: Start daemon (~50s warmup while it fetches market data)
bf.start()
bf.status()  # DaemonStatus(running=True, ready_exchanges=['binance-futures'], ...)

# Step 3: Place a ticket
ticket = bf.place(
    exchange="binance-futures",
    symbol="btcusdt",
    target_position=0.1,      # base asset units (BTC)
    strategy="maker",         # default
    time_constraint_ms=60_000,  # 60 seconds
)
print(ticket.ticket_id, ticket.status)

診断

bf.check_credentials() -> None
# Hits a SIGNED REST endpoint per configured exchange; prints one line each:
# ✓ <name> / ✗ <name> <reason>.
# Detects: wrong key/secret, IP whitelist mismatch, testnet/mainnet mix-up,
# network/proxy/geo block. Auto-invoked at end of set_credentials().

bf.positions() -> list[dict]
# Aggregated positions from each running executor.
# Each entry: {exchange, symbol, size, entry_price, update_ts_ms}

bf.open_orders() -> list[dict]
# Active orders on each configured exchange right now.

bf.nav() -> dict
# Net Asset Value across all running executors.
# {exchanges: [{exchange, nav, wallet_balance, margin_value, unrealized_pnl}],
#  total_nav, exchanges_queried}

bf.tca(ticket_id=None, symbol=None, from_ms=None, to_ms=None, limit=100,
       history=False) -> list[dict]
# Transaction cost analysis for completed tickets.
# history=False: active session (in-memory).
# history=True:  persistent across all sessions (blockfill-server).
# Each entry: benchmarks (l1/mid/twap/vwap), fills, maker/taker breakdown,
# execution_cost_usd, opportunity_cost_usd, duration_ms.

bf.instruments(substring) -> list[dict]
# Per-exchange instrument lookup — returns native-format symbols matching
# substring. Use this to find the exact symbol string before placing.

プロキシ / 地理制限の回避

Binance に直接到達できないホスト (米国の IP は HTTP 451 を返します) では、取引所の REST および WebSocket トラフィックを HTTP CONNECT プロキシ経由でルーティングします。

Starchild ユーザー — 無料の sc-vpn スキル、18 か国、月間 500 GB:

bf.set_proxy("http://jp:[email protected]:8080")   # Japan (lowest latency for Binance)
bf.set_proxy("http://sg:[email protected]:8080")   # Singapore
bf.set_proxy("http://hk:[email protected]:8080")   # Hong Kong
bf.set_proxy()                                      # clear proxy

アジア太平洋	ヨーロッパ	アメリカ大陸
`jp` 日本	`uk` イギリス	`ca` カナダ
`sg` シンガポール	`de` ドイツ	`br` ブラジル
`hk` 香港	`fr` フランス	`mx` メキシコ
`kr` 韓国	`nl` オランダ
`tw` 台湾	`ch` スイス
`au` オーストラリア	`it` イタリア
`in` インド	`es` スペイン
	`se` スウェーデン

任意の HTTP CONNECT プロキシも使用できます:

bf.set_proxy("http://user:[email protected]:8080")

set_proxy はデーモンを再起動するため、新しい設定が有効になります。プロキシは REST と WebSocket の両方 をカバーします — すべての取引所の WS 接続がトンネルされます。

実際の注文を出す前に、到達可能性を確認してください:

bf.set_proxy("http://jp:[email protected]:8080")
bf.set_credentials("binance-futures", api_key=..., api_secret=...)
# set_credentials auto-runs check_credentials() — a ✓ proves both proxy + auth work.

障害モード

何かが失敗した場合は、この順序で診断します: 認証情報 → プロキシ → 環境 → シンボル → 証拠金。

症状	考えられる原因	修正方法
`check_credentials` が `✗ <exchange> IP not whitelisted` を出力する	API キーが現在の送信元 IP とは異なる IP に紐付けられている	送信元 IP (またはプロキシ IP) を取引所の API キーホワイトリストに追加する
`check_credentials` が `✗ <exchange> connection refused` / HTTP 451 を出力する	地理ブロック (例: 米国 IP → Binance)	プロキシを設定する: `bf.set_proxy("http://jp:[email protected]:8080")`
`check_credentials` が `✗ <exchange> invalid signature` を出力する	`api_secret` が間違っている、またはキータイプが間違っている (HMAC と Ed25519)	認証情報を再確認する。Binance テストネットは HMAC ではなく Ed25519 を使用します
チケットが 30 秒以上 `NEW` のまま	取引所が `ready_exchanges` に含まれていない (エグゼキュータがまだウォームアップ中、または初期化に失敗)	`bf.status()` → `ready_exchanges` を確認する。`blockfill logs` で初期化エラーを確認する
チケットの `cancel_reason: min_notional`	注文サイズ × 価格 < 取引所の最小想定元本	数量を増やすか、より大きな想定元本を使用する
チケットの `cancel_reason: insufficient_margin`	ポジションに対する証拠金が不足している	数量を減らすか、証拠金を追加する
チケットの `cancel_reason: rejected`	取引所が注文を拒否した (シンボル停止、無効なパラメータ)	`bf.instruments(substring)` でシンボルを確認する。シンボル形式を検証する
`status` が 90 秒以上経過しても `ready_exchanges: []` を表示する	デーモンが 1 つ以上の取引所の初期化に失敗した	`blockfill stop && blockfill start` を実行する。ログでエラーを確認する
Binance スポット (テストネット) で NAV = 0	テストネットは `getUserAsset` エンドポイントをサポートしていません	想定内です — テストネットの NAV は代わりにマーケットティッカーのルーティングを使用します

問題が解決しない場合は、GitLab Issues または Telegram サポートをご覧ください。完全なナレッジベースについては docs/troubleshooting.md を参照してください。

支払い — x402 クォータ

クォータは (アカウント, 取引所) のペアごとに追跡されます。各ペアは 無料枠 から始まります; クォータは各チケットの TCA が確定したときに課金されます。無料枠を使い切ったら、x402 経由で Base 上の USDC を支払って追加購入します — ガスレスの EIP-3009 transferWithAuthorization です。デーモンはウォレットキーを保持し、ローカルで署名します; マシンから出るのは署名のみで、キーが出ることはありません。

bf.set_payment("0x<64-hex private key>")     # store EVM wallet key
bf.topup("binance-futures", usdc=1.0)        # → {exchange, usdc, quota_balance, tx_hash}

CEX 取引所 (Binance、OKX、Bybit、Bitget、Gate.io、KuCoin、Kraken、Deribit) はクォータを使用します。DEX (Hyperliquid、Aster、Orderly) はビルダーコードの実行手数料を直接支払います — クォータはありません。

blockfill-server が見るのは署名と 匿名化された (SHA-256 ハッシュ化された) アカウント ID のみです — 取引所の API キーやウォレットキーが見られることは決してありません。

一般的なエージェントのフロー

from blockfill import Blockfill
import os

bf = Blockfill()

# (Optional) configure proxy first if in a geo-blocked region
# bf.set_proxy("http://jp:[email protected]:8080")

# Set creds — SDK automatically verifies via signed REST
bf.set_credentials(
    "binance-futures",
    api_key=os.environ["BINANCE_API_KEY"],
    api_secret=os.environ["BINANCE_API_SECRET"],
    testnet=True,           # always confirm testnet vs mainnet with user
)

# Start daemon
bf.start()  # auto-waits ~50s for warmup

# Place ticket
ticket = bf.place(
    exchange="binance-futures",
    symbol="btcusdt",
    target_position=0.1,   # +0.1 BTC long
    strategy="maker",
    time_constraint_ms=300_000,
)

# Monitor
import time
while ticket.status in ("NEW", "OPEN"):
    time.sleep(5)
    ticket = bf.query(ticket_id=ticket.ticket_id)[0]
    print(f"filled: {ticket.executed_position} / {ticket.target_position}")

# TCA
tca = bf.tca(ticket_id=ticket.ticket_id)
print(tca)

bf.stop()

サポート

GitLab Issues: https://gitlab.com/quantech-services-group/blockfill-agent-execution/-/issues
Telegram: @blockfill_support

Markdown 対応

ログインしてコメント

基本情報

作者: starchild-ai-agent
リポジトリ: starchild-ai-agent/official-skills
カテゴリ: その他
インストール数: 79
GitHub スター: 30

問題を報告