BTC合約の注文でエラーが出たら、まず建玉モードを確認してください。焦ってすぐに再試行しないでください。
スクリプトで $BTC の合約を管理するとき、売買方向と保有(ポジション)方向は別物です。バイナンスの現在のU本位合約ドキュメントには、単方向モードでは positionSide のデフォルトが BOTH であること、そして双方向モードでは LONG または SHORT を指定する必要があり、reduceOnly パラメータは送信できないこと(false を入れても例外ではない)と明記されています。
調査はこの順で行うのがおすすめです:まず口座の現在の建玉モードを確認し、次にリクエスト内の side、positionSide、reduceOnly を照合し、最後に注文の返答と実際の建玉を確認します。エラーを消すためだけに保護パラメータを削除して再送するのはやめてください。リクエストが通ったからといって、それが以前の減倉(減らす目的)に今も合致しているとは限りません。
もう一つの違いとして、明確なパラメータ拒否とネットワークタイムアウトは同じではありません。タイムアウトに遭遇したら、まず注文記録で受理されたかどうかを確認し、その後で次の手を決め、重複の委託を避けてください。
ここではパラメータのルールだけを分解して説明し、発注指示は提供しません。合約にはレバレッジと約定(実行)リスクがあります。あなたは現在、単方向の建玉ですか、それとも双方向ですか?
#合约教程 #リスク管理
スクリプトで $BTC の合約を管理するとき、売買方向と保有(ポジション)方向は別物です。バイナンスの現在のU本位合約ドキュメントには、単方向モードでは positionSide のデフォルトが BOTH であること、そして双方向モードでは LONG または SHORT を指定する必要があり、reduceOnly パラメータは送信できないこと(false を入れても例外ではない)と明記されています。
調査はこの順で行うのがおすすめです:まず口座の現在の建玉モードを確認し、次にリクエスト内の side、positionSide、reduceOnly を照合し、最後に注文の返答と実際の建玉を確認します。エラーを消すためだけに保護パラメータを削除して再送するのはやめてください。リクエストが通ったからといって、それが以前の減倉(減らす目的)に今も合致しているとは限りません。
もう一つの違いとして、明確なパラメータ拒否とネットワークタイムアウトは同じではありません。タイムアウトに遭遇したら、まず注文記録で受理されたかどうかを確認し、その後で次の手を決め、重複の委託を避けてください。
ここではパラメータのルールだけを分解して説明し、発注指示は提供しません。合約にはレバレッジと約定(実行)リスクがあります。あなたは現在、単方向の建玉ですか、それとも双方向ですか?
#合约教程 #リスク管理