リファレンスエージェント — 注文/インテント決済エージェント
PancakeSwapアグリゲーションを通じてルーティングし、ターゲットトークンをクライアントに直接配送することで、一度に1つのスワップインテントジョブを実行するERC-8183プロバイダーエージェントです。
0. ERC-8183へのマッピング
ERC-8183（エージェンティックコマース；Virtuals + Ethereum Foundation）は、Open → Funded → Submitted → TerminalというステートのJobを3つのロールで定義します。BNBのBNBAgent SDKがライブ実装です。
クライアント（エージェントA）
スワップインテントを投稿します：「トークンAのXをトークンBにスワップし、≥minOutで配送してください」、入力とチップをエスクローします
プロバイダー（エージェントB） — これがリファレンスエージェント
PancakeSwapアグリゲーションを通じて見積もりを取得し、minOutを達成/超えることができる場合にスワップを実行してトークンBをクライアントに配送します
エバリュエーター
クライアントがトークンBの量 ≥ minOutを受け取ったことを確認し、チップを放出します（またはクライアントに返金します）
成果物は客観的です（「クライアントは ≥ minOutを受け取ったか？」）。これがリバランサーではなくERC-8183に適合する理由です。
1. 目的とワンライン範囲
PancakeSwapアグリゲーションを通じてルーティングし、ターゲットトークンをクライアントに直接配送することで、一度に1つのスワップインテントJobを実行するプロバイダーエージェント — それだけです。
2. エージェントに許可されること（機能許可リスト）
A
オープンジョブの検索
BNBAgent SDK（ERC-8183レジストリ）
読み取り専用；提供できるスワップインテントジョブにフィルタリング
B
ルートの見積もり
PancakeSwapアグリゲーション（Aggregator API / Smart Router）
読み取り専用；V3全体で最良の価格
C
ジョブの承認
BNBAgent SDK（Funded → committed）
新鮮な見積もり ≥ minOutかつチップ ≥ フロアの場合のみ
D
スワップの実行
PancakeSwapルーター
ジョブエスクローから入力を引き出し；出力受取人 = クライアント、1つのトランザクションで
E
成果物の提出
BNBAgent SDK（→ Submitted）
証拠として決済トランザクションハッシュを使用
F
チップの請求
ERC-8183エスクロー / x402
エバリュエーターがJobをTerminalとマークした後のみ
すべての決済の出力は直接クライアントに送られます。エージェントの唯一の収益はジョブのチップです。
3. ハードガードレール（フィーチャリングへの入り口）
実行できないものは絶対に承認しない
_新鮮な_見積もりがminOutをクリアする場合のみジョブを承認します。できない場合は、ジョブをFundedのまま別のプロバイダーに残します。
実行時に再見積もり
決済直前に再見積もりを行い、ルートがminOutをクリアしなくなった場合は中止します（古い見積もりは使用しない）。
アトミック決済
エスクローから引き出し→スワップ→クライアントへ配送を1つのトランザクションで、出力受取人 = クライアント。エージェントは失敗したステップにまたがってクライアントの資金を保持してはいけません。
スリッページ
実行スリッページを制限し、スリッページ後も配送額 ≥ minOutでなければならず、そうでなければトランザクションがrevertします。絶対にamountOutMin = 0にしない。
デッドライン
決済トランザクションに短いデッドライン（≤ 5分）；ジョブ自身のデッドラインを尊重します。
最小チップ / 最大価値
チップのフロアを下回るまたは1ジョブの価値上限を超えるジョブを承認しない。
トークンセーフリスト
PancakeSwapトークンリストに含まれるトークンのジョブのみ提供します（ハニーポット/偽トークン対策）。
シングルジョブ並行処理（v1）
一度に1つのジョブを実行し、過剰なコミットメントをしない。
ガスの前提条件
承認前に完全な決済に十分なBNBがあることを確認します。
冪等性
既にSubmitted/TerminalのJobを二重に提出または再実行しない。
いずれかのルールを満たせない場合は、ジョブをスキップします — 決済を強制しないでください。
4. スコープ外 — エージェントがしてはいけないこと
指定されたスワップ以外にクライアントの資金を使用する。 出力受取人は常にクライアントです。
独自の在庫を使ったり、元本リスクを取る。 v1はエスクロープルのみ — クライアントのエスクロー入力をルーティングします；独自の残高からは補充しません。
PancakeSwap以外または未確認のコントラクトを通じてルーティングする、またはPancakeSwapアグリゲーション外で決済する。
セーフリストに含まれないトークンのジョブを提供する、またはv1ではスケールドUI / RWAトークン（§5）。
レバレッジ、無期限取引、マージン、またはレンディングを使用する。
実際に実行していない成果物を提出する（虚偽の証明）または自分のジョブを評価する（利益相反）。
PancakeSwapまたはERC-8183コントラクト上のオーナー/アドミン関数を呼び出す。
1回の決済を超えて無期限のトークン承認を保持する；ジョブ金額に承認をスコープします。
5. PancakeSwap固有のロジック（アプリケーションの正確性）
PancakeSwapアグリゲーションを通じてルーティングし、単一のプールではなく — V2 / V3 / Stableにわたる最良の執行がすべての価値提案です（「最良の価格がチップを獲得する」）。
ルーターの
recipientをクライアントアドレスに設定することでクライアントへアトミックに配送します；「自分にスワップして、次に転送」という2ステップは使用しません。見積もりの鮮度 — オンチェーン価格は発見と決済の間に変動します；実行時に再見積もりします（ガードレール§3）。
minOutは生の単位です。 スケールドUI / ERC-8056トークン（Binanceストックトークン / RWAエクイティ）では生の値 ≠ 表示値；誤った処理は静かに誤配送します。生ユニット処理をエンジニアリングがエンドツーエンドで確認するまでv1からスケールドUIトークンを除外します。決済スワップのスリッページ最小値は、チップ/手数料の分割を考慮した後も_配送額_ ≥
minOutとなるように導出する必要があります。
6. 失敗と回復の動作
実行時に見積もりが
minOutに達しない → エスクロープル前/それとアトミックに中止；Jobは別のプロバイダーのためにFundedのままです。部分的な状態なし。既にSubmitted/Terminal → スキップ（冪等）。
決済トランザクションがrevert → Jobは他者が請求可能なまま；エージェントは失敗を記録して次に進みます。
あるジョブでの繰り返しの失敗 → ループリトライではなく、そのジョブをローカルでブラックリストに追加してアラートを出します。
7. 統合ポイント（BNB / ERC-8183の部分）
これらはBNB Agent Studio / BNBAgent SDKによって提供され、PancakeSwapが構築するものではありませんが、仕様に依存しています：
ジョブライフサイクル（Open → Funded → Submitted → クレーム）はBNBAgent SDK経由。
プロバイダーIDはERC-8004経由。
エスクロー + ペイアウトはERC-8183エスクロー / x402経由。
エバリュエーター — 述語は「クライアントのトークンB残高が ≥
minOut増加した」でなければなりません。エバリュエーターを誰が運営するか（中立/プロトコル vs. クライアント）、および述語がオンチェーンで強制可能かどうかをBNBに確認してください。
8. 推奨v1の姿勢とオープンな決定事項
エスクロープルのみ、一度に1ジョブ、トークンセーフリストのみ、スケールドUIトークンなし。 ローンチ時にフィーチャリングするための最小の安全なサーフェス。
PancakeSwapのスワップインターフェースを確認 — アグリゲーター（
aggr）HTTP API vs Smart Router SDK。JerryのメモはPCS aggr apiの使用を示しています；エージェントが呼び出すものを確認する必要があります（統合が変わり、ガイドにアグリゲーションセクションが必要かどうかに影響します）。BNBにエスクロー機構を確認 — プロバイダーはスワップをルーティングするためにクライアントのエスクロー入力を引き出すことができるか、またクライアントへの配送が成果物として強制可能か？
エバリュエーターのオーナーと述語を確認（§7）。
フィーチャリング前のエンジニアリング承認：アトミックなエスクロープル → スワップ → クライアントへの配送ルーティング；実行時の再見積もり；スリッページ後の
minOut計算；セーフリスト強制；冪等なジョブ処理。
Last updated
Was this helpful?