idios

Idios

Beam 上の AI およびその他のコンピューティング向け、プライベートなエスクローと決済。

AI およびコンピューティングの作業に、プライベートに支払えます。検証可能な納品、エスクローによる支払い、オンチェーンの紛争解決。基盤レイヤーでは金額と当事者が非公開です。

ウェブサイト · AI およびコンピューティングのユースケース · 最新リリース · ライブエクスプローラー

「プライベートに支払い、オンチェーンで検証し、必要に応じて紛争を解決。」

---

デモ

AI エージェントが仕事を引き受け、2 つの作業を他のエージェントにプライベートに再委託し、それぞれの成果を確認して支払いを行い、その後クライアントと決済します。この全過程は Beam メインネット上で行われ、基盤レイヤーでは金額と当事者が一貫して非公開です。

---

理由

公開型の決済手段では情報が漏えいします。すべての契約、すべての支払い、すべての取引相手が、永久に検索可能な記録の一部になります。AI 推論、モデルのトレーニング、科学計算、専有の入力データ、プライベートデータ、または競争上重要な業務を伴う作業では、この可視性は受け入れがたいものです。

Idios は、支払いと決済のプライバシーに関する問題を解決します。支払いは Beam 上のプライベートなエスクローにロックされます。ワーカーは担保をロックします。決済はオンチェーンで行われ、金額と当事者は非公開です。Beam の MimbleWimble プロトコルは、基盤レイヤーで金額と身元を隠します。Idios は、その基盤の上にエスクローを構築したものです。

ERC-8183 は、AI エージェントの作業に対するエスクロー付き支払いを含む Job という、同じ基本プリミティブを Ethereum 上で標準化しています。Idios は Beam 上の独立した、より完全なプロトコルであり、ERC-8183 の移植版ではありません。ERC-8183 には現在ないワーカーの担保と実用的な紛争解決を追加し、金額と当事者を非公開にして決済します。Idios は独自の役割として、Requester、Worker、Arbitrator を使用します。

---

仕組み

決済モードは 2 種類あり、契約の作成時に選択します。

ハッシュ検証済み決済（モード A）

正しい出力が事前にわかっている特定のハッシュである、決定的な作業に適しています。

1. Requester が支払いをロックし、期待する結果のハッシュを指定します。
2. Worker が担保をロックします。
3. Worker が作業を納品し、結果のハッシュをオンチェーンで送信します。
4. ハッシュが一致すると、契約によって支払いと担保が Worker に自動的に解放されます。完了です。

Arbitrator は関与しません。ハッシュが一致すれば、決済は機械的に行われます。

レビュー付き決済（モード B）

非決定的な作業や、Requester による出力のレビューが必要な、範囲が明確でない作業に適しています。

1. Requester が支払いをロックし、レビュー期間と紛争手数料を設定します。
2. Worker が担保をロックします。
3. Worker が作業を納品します（オフバンドまたは IPFS 経由でアップロードし、ハッシュをオンチェーンに記録します）。
4. Requester が作業をレビューし、次のいずれかを行います。
   • 承認すると、Worker が支払いと担保を受け取れるようになります。
   • 異議を申し立てると、紛争手数料がロックされ、案件が仲裁に進みます。
   • レビュー期間が終了するまで何もしない場合、期間終了後に Worker はタイムアウトによって支払いと担保を受け取れます。
5. 異議が申し立てられた場合、M-of-N の Arbitrator レジストリが投票によって、いずれかの当事者を勝者とします。勝者は支払いと担保を受け取ります。紛争手数料は合意形成に投票した Arbitrator に支払われ、勝者には支払われません。

資金は常に適切な当事者に渡ります。Arbitrator は紛争の勝者を決定し、審理の対価として紛争手数料を受け取りますが、支払いや担保に触れることはありません。

2段階の請求

Idios は2段階の請求パターンを採用しています。承認、claim_after_timeout、M-of-N 投票による紛争解決などの承認ステップでは、契約のステータスを設定しますが、資金は移動しません。その後、受益者が自分の鍵で署名して claim を呼び出し、実際に支払いを受け取ります。これは、単一のカーネルで一方の当事者の署名を行いながら、別の当事者に資金を送ることが難しい Beam BVM の制約を回避する方法です。

---

ステータス

Beam メインネットで稼働中 ✅

• cid 41ef8be5 上の v2 コントラクト（Upgradable3、インプレースアップグレード）。当初はブロック 3905992（2026年6月15日）で v6 としてデプロイされ、ブロック 3914637（2026年6月21日）で M-of-N v1 にインプレースアップグレードされ、さらにブロック 3938963（2026年7月8日）で v2 にインプレースアップグレードされました
• M-of-N 仲裁が稼働中：グローバルな仲裁人レジストリ、投票ベースの紛争解決（現在、N は 1）。v2 で登録を強化：BEAM のみ、最低ステーク額 10 BEAM、管理者による共同署名
• ワーカーの評判ボンドが稼働中（v2）：ワーカーはスラッシュ可能なボンドをロックして維持できます。仲裁で紛争に敗れた場合、ボンドはトレジャリーにスラッシュされます
• Mode A のエンドツーエンドに加え、Mode B の4つすべての解決経路を実資金でエンドツーエンド検証済み。また、本番アップグレード前に、v2 のスラッシュライフサイクル全体（ボンド、担保拘束、スラッシュ、トレジャリーへの移送）をメインネットで実証済み
• Dapp 3.3.0 を公開済み。UI で両方のモードをサポート

検証済みの解決経路（開発中にメインネットで実資金を使用。以下のジョブ ID は、インプレースの M-of-N アップグレードに先行する v5 および v6 のデプロイでのものです）：

経路	ステータスの流れ	ジョブ
Mode A ハッシュ一致	Open → Active → Closed（単一のトランザクション）	22224
Mode B 承認	Open → Active → AwaitingApproval → Settled → Closed	11112, 33335
Mode B 紛争、ワーカーに解決	Open → Active → AwaitingApproval → Disputed → ResolvedToBob	11113
Mode B 紛争、依頼者に解決	Open → Active → AwaitingApproval → Disputed → ResolvedToAlice	11114
Mode B タイムアウト	Open → Active → AwaitingApproval → Settled → Closed	11115
Mode B 仲裁人のタイムアウトによる無効化	Open → Active → AwaitingApproval → Disputed → Voided	20002

---

コントラクト

CID: 41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f
Current version: v2 (SID a61f3a93), upgraded in place from M of N v1 on 8 July 2026 at block 3938963
Version history: v6 (deploy) -> M of N v1 (21 June 2026, block 3914637) -> v2 (8 July 2026, block 3938963); cid unchanged throughout
Deployed at block: 3905992 (original v6 deploy; cid unchanged across all Upgradable3 upgrades)
Constructor params: default_review_window=10080, arbitrator_timeout_blocks=20160, upgrade_delay=1440, min_approvers=1
Explorer: https://explorer.0xmx.net/?network=mainnet&type=contract&id=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f

役割

役割	説明
user	コントラクトのライフサイクルに関与する依頼者（Alice）またはワーカー（Bob）。ワーカーは評判ボンドを保有することもできます（v2）。
arbitrator	M-of-N 仲裁人レジストリのメンバー。ステーク（BEAM のみ、最低 10 BEAM、v2 では管理者による共同署名あり）を預けて登録し、紛争中のコントラクトに投票して、報酬の一部を請求します
manager	コントラクトのパラメーターをデプロイして確認します（1回限り。コントラクトのセットアップ時に使用）
treasury	プロトコルのトレジャリー。デプロイ時にデプロイ用ウォレットから設定されます。Active 状態からの返金時に没収されたワーカーの担保、無効化された紛争の紛争手数料、およびスラッシュされたワーカーのボンド（v2）を、sweep と slash_sweep で回収します。

役割ごとのアクション

user のアクション

アクション	説明
create_a	Mode A のコントラクト（ハッシュ検証による決済）を作成します。支払いをロックします。
create_b	Mode B のコントラクト（レビュー後の決済）を作成します。支払いをロックし、レビュー期間と異議申し立て手数料を設定します。
commit	ワーカーが担保をロックし、ステータスが Active に移行します。
submit_delivery	ワーカーが結果のハッシュを送信します。Mode A では、ハッシュが一致すると同時に支払いが行われ、コントラクトは直接 Closed に移行します。Mode B では、AwaitingApproval に設定されます。
approve	依頼者が Mode B の納品を承認し、ステータスが Settled に移行します（資金の移動はまだありません）。
dispute	依頼者が Mode B の納品に異議を申し立て、異議申し立て手数料をロックし、ステータスが Disputed に移行します。
claim_after_timeout	レビュー期間の終了後、ワーカーが請求します（Mode B）。ステータスが Settled に移行します。
claim	Settled、ResolvedToBob、または ResolvedToAlice のコントラクトから、受取人が資金（支払い＋担保）を受け取ります。Settled の請求では、ステータスが Closed に移行します。Resolved のコントラクトはステータス 6/7 のまま維持されます。view_dispute の winner_paid フラグに支払いが記録されます。Mode A のコントラクトは自動的に支払いが行われるため、請求できません。
refund	期限切れのコントラクト（Open または Active）から、依頼者が支払いを取り戻します。Active の場合、ワーカーの担保はトレジャリーに没収されます。ステータスが Refunded に移行します。
void_dispute	誰でも実行できます。異議申し立てから arbitrator_timeout_blocks が経過した後、仲裁人が解決していない異議申し立てを無効化できます。ステータスが Voided に移行します。
void_claim_requester	Voided のコントラクトから、依頼者が支払いを取り戻します。
void_claim_node	Voided のコントラクトから、ワーカーが担保を取り戻します。
view_job	現在のジョブ状態を読み取ります。
view_dispute	ジョブの M-of-N 異議申し立て記録を読み取ります。凍結された N としきい値、投票数、解決結果、およびワーカーの保証金が異議申し立てによって拘束されているかどうかが含まれます（v2）。
worker_register	継続的なレピュテーション保証金をロックします（v2）。BEAM のみ、金額は任意で、ワーカーのコントラクト公開鍵に紐付けられます。没収の対象となり、仲裁で敗訴すると保証金全額がトレジャリーに没収されます。
worker_deregister	レピュテーション保証金の引き出しを開始します。回収待機期間が始まります。
worker_reclaim	待機期間（= arbitrator_timeout_blocks）の経過後、保証金を全額回収します。未解決の異議申し立てによって保証金が拘束されている間は停止し、保証金が没収された場合は永久に停止します。
view_worker_bond	ワーカーの保証金（ステーク、状態、拘束数）を読み取ります。デフォルトでは自身の鍵を参照します。別のワーカーの保証金を確認するには、worker_pk を渡します。
get_key	このコントラクトにおけるユーザーの公開鍵を返します。（ワーカーは作成前にこれを依頼者と共有します。）

仲裁人のアクション（M-of-N、v2 強化レジストリ）

アクション	説明
register	stake を預け入れて、グローバルな仲裁人レジストリに参加します。v2 の制限：BEAM のみ、最低 10 BEAM、カーネルにプロトコル管理者の共同署名が必要です（仲裁人の没収機能が実装されるまでは、登録は審査制です）。完全に退出した ID は再登録できます。省略可能な arb_index（デフォルトは 0）を指定すると、スロットごとに異なる鍵が生成されます。
vote	Disputed のコントラクトに投票します。side 0 は依頼者（Alice）、1 はワーカー（Bob）への配分を意味します。M 件の一致する投票が集まると解決します。
claim_reward	異議申し立ての解決後、コンセンサスに達した投票者が異議申し立て手数料の分配分（dispute_fee / M、端数はトレジャリーに回収）を請求します。
deregister	レジストリから退出します。ステークの回収待機期間が始まります。
reclaim	待機期間（arbitrator_timeout_blocks と同じ）の経過後、ステークを回収します。
view_arb	レジストリ（現在の仲裁人数と自身に割り当てられたインデックス）を読み取ります。
get_mofn_key	指定された arb_index に対応する仲裁人の公開鍵を返します。
get_key	このコントラクトにおける仲裁人のベース公開鍵を返します。

トレジャリーのアクション

Action	Description
sweep	没収された資金を回収します。対象は、Active 経路を経て Refunded になった契約のワーカー担保、または Voided になった契約の紛争手数料です。
slash_sweep	スラッシュされたワーカーの評判ボンドを回収します（v2）。ボンドを拘束していた未解決の紛争がすべて終了するまで待機します。
get_key	このコントラクトのトレジャリーの公開鍵を返します。

ステータスコード

0 = Open               (just created, awaiting worker commit)
1 = Active             (worker has committed collateral)
2 = AwaitingApproval   (Mode B, worker has delivered, in review window)
3 = Disputed           (Mode B, requester has disputed, awaiting arbitrator)
4 = Settled            (beneficiary can claim, payment + collateral)
5 = Refunded           (terminal, requester reclaimed funds after expiry)
6 = ResolvedToAlice    (arbitrators sided with requester, requester can claim; stays 6 after the claim, winner_paid in view_dispute records it)
7 = ResolvedToBob      (arbitrators sided with worker, worker can claim; stays 7 after the claim, winner_paid in view_dispute records it)
8 = Closed             (terminal, claim has been collected)
9 = Voided             (terminal, arbitrators never resolved a dispute in time, parties reclaim)
10 = Cancelled         (terminal, both parties agreed to cancel, everyone made whole in the cancel tx)

---

クイックスタート（dapp UI）

Idios を最も簡単に利用する方法は、Beam ウォレットの DApp Store を使うことです。次の 2 つのウォレットで利用できます。

• デスクトップ（Windows、Mac、Linux）：beam.mw の公式 Beam Desktop ウォレットです。標準的な利用方法であり、多額の資金を保管する場合に適しています。
• Android：PriviMW は、独自の DApp Store と暗号化メッセージ機能を内蔵した、コミュニティ製の Beam ウォレットです。最新の APK をインストールしてください。オープンソースですが、外部監査はまだ受けていません。新しいウォレット全般と同様、Idios の実行や日常的な金額の利用には適しています。

どちらのウォレットでも、次の手順に従ってください。

1. ウォレットを作成し、メインネットに同期して、少額の BEAM を入金します。

   同じ名称とティッカーを持つ、無関係な 2 つのコインがあります。Idios は Beam Mimblewimble（プライバシーチェーン、beam.mw、2019 年からメインネット稼働）上で動作し、Beam Network（無関係な Avalanche のゲーム用サブネット）上では動作しません。必ず Mimblewimble のほうを購入してください。

   Beam Mimblewimble は MEXC、Gate、CoinEx で取り扱われています。Binance、Coinbase、Kraken では取り扱われていません。取引所アカウントを使わずに ETH から BEAM へ手早く交換するには、コミュニティ運営のサービスである buybeam.my を利用できます。制限が 2 つあります。交換額は BEAM で 1 ドル相当以上である必要があり、それ未満の金額ではウォレットに何も送金されません。また、1 回の交換上限は 100 ドルです（流動性プールが小さいため、これを超える金額の購入には取引所を利用してください）。

2. ウォレットの DApp Store から Idios dapp をインストールします。デスクトップでは、リリースから最新の .dapp ファイルをサイドロードすることもできます。

3. インストール済みアプリから Idios を開きます。

dapp を開くとランディングページが表示され、3 つの入口から選べます。

• コントラクトを開始：依頼者として、取引条件（コントラクト ID、支払い、期限、ワーカーの公開鍵）を入力します。ハッシュ検証型決済（成果物ファイルをアップロードし、dapp がローカルで SHA-256 ハッシュを計算）またはレビュー型決済（レビュー期間と紛争手数料を設定）を選択します。コントラクトを作成します。ワーカーからのオファーリンクを使ってアクセスした場合、フォームには自動的に情報が入力されます。
• コントラクトオファーを生成：ワーカーとして、合意した取引条件を入力し、完成した成果物をアップロードするか（モード A）、レビュー設定を指定して（モード B）、［Generate Offer］をクリックします。依頼者に送るための、共有可能なテキストブロックとリンクが生成されます。
• 自分のコントラクト：ローカルで追跡しているすべてのコントラクトの現在のステータスを確認できます。条件に応じて操作ボタンが表示されます。期限切れのコントラクトを返金する、モード B の納品物を承認または紛争にする、コントラクトが Settled になった場合や自分に有利な形で Resolved になった場合に資金を請求する、といった操作が可能です。

期限ブロックに関する注意：Beam メインネットでは、約 60 秒ごとにブロックが生成されます。作成トランザクションが期限切れ前に承認されるよう、expiry_block は少なくとも current_block + 200 に設定してください。実際のコントラクトでは、current_block + 1440（約 24 時間）がより一般的です。

---

CLI の使用方法

Beam CLI ウォレットを使って、コントラクトを直接操作します。スクリプト作成、インテグレーションの構築、または dapp で提供されている範囲を超えた役割を担う場合に便利です。

前提条件

• Beam CLI ウォレットのバイナリ。Beam のリリースページから入手できます
• idios_app.wasm のコピー。このリポジトリからダウンロードするか、ソースからビルドできます（ビルドを参照）
• 接続先の Beam メインネットノード。自分で実行するか、eu-node01.mainnet.beam.mw:8100 などのパブリックノードを使用してください。

すべての例では、Beam Mimblewimble メインネット上の稼働中の Idios コントラクト（cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f）とパブリックノードを使用しています。このコントラクトは v2 で、Upgradable3 を介してその場でアップグレードされています（2026 年 6 月 21 日に v6 から M of N v1 に、その後 2026 年 7 月 8 日に v2 にアップグレード）。そのため cid は変更されず、すべてのユーザー側の呼び出し（create、commit、submit_delivery、approve、dispute、claim、refund）は以前とバイト単位で同一です。必要に応じて、ご自身のノードまたは cid に置き換えてください。

このコントラクトの worker の公開鍵を取得する

worker の公開鍵はコントラクト固有です（CID が鍵導出に含まれるため）。create を実行する前に、worker は次を実行します。

./beam-wallet shader \
  --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=get_key,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

出力は、そのコントラクトに対する worker の node_pk です。これを依頼者に送信してください。

コントラクトを表示する

./beam-wallet shader \
  --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=view_job,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f,job_id=<N>" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

Mode A コントラクトを作成する（ハッシュ検証済み決済）

./beam-wallet shader \
  --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=create_a,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f,job_id=<N>,subnet_id=1,epoch=1,expiry_block=<FUTURE>,payment=<GROTH>,asset_id=0,node_pk=<WORKER_PUBKEY>,result_hash=<HASH>" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

支払い額の単位は groth です（1 BEAM = 100,000,000 groth）。たとえば、payment=5000000 は 0.05 BEAM です。

Mode B コントラクトを作成する（レビュー済み決済）

./beam-wallet shader \
  --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=create_b,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f,job_id=<N>,subnet_id=1,epoch=1,expiry_block=<FUTURE>,review_window_blocks=<N>,payment=<GROTH>,dispute_fee=<GROTH>,asset_id=0,node_pk=<WORKER_PUBKEY>" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

担保を預け入れる（worker）

./beam-wallet shader \
  --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=commit,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f,job_id=<N>,collateral=<GROTH>" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

納品を送信する（worker）

./beam-wallet shader \
  --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=submit_delivery,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f,job_id=<N>,delivery_hash=<HASH>" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

コントラクトは状態からジョブのモードをすでに把握しています。view_job は Mode A の場合は 65（ASCII の「A」）、Mode B の場合は 66（ASCII の「B」）を返します。

Mode B：approve、dispute、claim_after_timeout

# Requester approves
./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=approve,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f,job_id=<N>" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

# Requester disputes
./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=dispute,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f,job_id=<N>" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

# Worker claims after review window expires
./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=claim_after_timeout,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f,job_id=<N>" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

仲裁人：登録、投票、報酬の請求（M of N）

紛争は M of N の投票によって解決されます。仲裁人は一定額のステークを預けてグローバルレジストリに参加し、紛争中のコントラクトに投票します。合意に達すると、報酬の分配分を請求できます。ステークがスラッシュされることはありません。これはシビル攻撃への耐性と、仲裁人自身の利害関与を確保するためのものです。v2 では登録に制限があります。ボンドは BEAM で、10 BEAM 以上（stake=1000000000）である必要があります。また、登録カーネルにはプロトコル管理者の署名も必要です。そのため、仲裁人へのスラッシュ機能が提供されるまでは、レジストリへの参加は審査制です（登録については下記にお問い合わせください）。本番環境で v2 より前に行われた唯一の登録は、引き続き有効です。すべての仲裁人呼び出しで arb_index は省略可能で、省略時は 0 が使われます。各インデックスからそれぞれ異なる鍵が導出されるため、1 つのウォレットで複数のインデックスを使用できます。ステークの単位は groth です（1 BEAM = 100,000,000 groth）。

# Register as an arbitrator (one time, posts the stake; v2 requires 10 BEAM minimum
# and the admin co signature in the same kernel)
./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=arbitrator,action=register,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f,stake=1000000000" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

# View the registry (current arbitrator count and your index)
./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=arbitrator,action=view_arb,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

# Vote on a dispute. side=0 awards the requester (Alice), side=1 awards the worker (Bob).
# The contract freezes N (registry size at filing) and M (= N/2 + 1); only arbitrators
# registered at or before the filing block may vote. Resolves when M matching votes land.
./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=arbitrator,action=vote,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f,job_id=<N>,side=<0|1>" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

# Claim your reward share after the dispute resolves (consensus voters only; dispute_fee / M each)
./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=arbitrator,action=claim_reward,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f,job_id=<N>" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

# Deregister, then reclaim the stake after the cooldown (= arbitrator_timeout_blocks)
./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=arbitrator,action=deregister,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=arbitrator,action=reclaim,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

仲裁人の各スロットには、MofnArbKeyID { tag 'N', ctx 1, m_Idx } を介して導出される固有の公開鍵があります。該当する arb_index を指定して action=get_mofn_key を実行すると、ご自身の公開鍵を確認できます。

ワーカーのレピュテーションボンド（v2）

ワーカーは、契約用公開鍵、つまり仕事を受ける際に使用する同じ鍵に対して、いつでも没収可能なボンドをロックできます。このボンドは、Idios のレピュテーションを構成するオンチェーン側の要素です。誠実に仕事をすれば保有に費用はかからず、契約終了時に全額を取り戻せます。一方、仲裁された紛争で敗れた場合、ボンド全額がトレジャリーに没収されます。金額は任意で、BEAM のみです。オフチェーンのスコアリーダーにボンド額が表示されるため、少額のボンドも見抜かれます。リストに掲載されたボンドは、資金を用意しなくても、どのリクエスターでもオンチェーンで直接確認できます。詳しくはdocs/verify_worker_bond.mdをご覧ください。

仕組み：有効なボンドを保有するワーカーのジョブに対して紛争が申し立てられると、ボンドに制約がかかり、紛争が終了するまで取り戻せなくなります。そのため、ワーカーは紛争の最中に登録を解除して、係争中の裁定を回避することはできません。定足数による解決でリクエスターが勝った場合、ボンド全額が没収されます（没収は最大 1 回です）。ワーカーが勝った場合、または仲裁人のタイムアウトによって紛争が無効になった場合は、制約が解除され、ボンドはそのまま残ります。紛争の申し立て後に登録されたボンドは、その紛争による没収の対象にはなりません。ボンドの登録、制約、没収、取り戻しのブロック、トレジャリーへの送金を含むライフサイクル全体は、メインネット上で実際の資金を使って実証済みです。

# Lock a reputation bond (any amount in groth, BEAM only)
./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=worker_register,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f,stake=<GROTH>" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

# Read a bond (defaults to your own key; add worker_pk=<PUBKEY> to inspect another worker)
./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=view_worker_bond,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

# Exit: deregister, wait out the cooldown (= arbitrator_timeout_blocks), reclaim in full
./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=worker_deregister,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=worker_reclaim,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

ワーカーボンドの状態：0 は登録済み、1 は登録解除中、2 は消失、3 は没収済みです。没収されたボンドは取り戻せません。制約の対象となっているすべての紛争が終了した後、トレジャリーは role=treasury,action=slash_sweep,worker_pk=<PUBKEY> を使ってボンドを回収します。その後、対象のアイデンティティは最初からボンドを登録し直すことができます（没収の記録はジョブ履歴に残ります）。

資金の請求（受益者）

契約が Settled、ResolvedToAlice、または ResolvedToBob になると、受益者は claim を呼び出します。契約はジョブの状態から支払い額と担保額を読み取るため、支払額を渡す必要はありません。

./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=claim,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f,job_id=<N>" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

3 つのケースすべてで、受益者は payment + collateral を受け取ります。M of N 仲裁では、紛争手数料は勝者に渡されません。claim_reward を通じて、合意形成に参加した投票者に分配されます（仲裁人のセクションを参照）。残額はトレジャリーに送られます。

返金（リクエスター、期限経過後）

期限切れの契約が Open または Active の場合に、expiry_block を過ぎると返金できます。Active の場合、ワーカーの担保は没収されてトレジャリーに送られます。

./beam-wallet shader --shader_app_file=idios_app.wasm \
  --shader_args="role=user,action=refund,cid=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f,job_id=<N>" \
  --node_addr=eu-node01.mainnet.beam.mw:8100

---

リポジトリ構成

idios_contract.h       Contract Shader header (job struct, status enum, method IDs)
idios_contract.cpp     Contract Shader (on chain logic, escrow, claim, dispute resolution)
idios_app.cpp          App Shader (wallet side transaction builder)
idios_contract.wasm    Compiled contract (build product, not committed; loaded on chain at deploy)
idios_app.wasm         Compiled app shader (used by wallet to construct kernels)
build_v2.sh            Build script
idios-dapp-src/        Mirror of the dapp source (BeamMW template fork)
idios-mcp-server/      MCP server exposing contract actions as agent tools
idios-agent-daemon/    Daemon automating the worker and client roles

---

ビルド

コントラクトとアプリのシェーダーは C++ で記述され、Beam Shader SDK を使ってビルドされます。

bash build_v2.sh

idios_contract.wasm（約 11 KB）と idios_app.wasm（約 28 KB）が生成されます。

---

アーキテクチャに関する補足

2 段階の請求。 承認、claim_after_timeout、M of N 投票による紛争解決などの承認ステップで、コントラクトのステータスが設定されます。その後、受益者は自分の鍵で署名した Method_15 Claim を呼び出し、実際に資金を受け取ります。これは、1 つのカーネルで一方の当事者の署名を行いながら、別の当事者に資金を送ることが難しい Beam BVM の制約に対処する方法です。

仲裁人への連絡。 紛争解決のために仲裁人へ連絡するには、Telegram で @tappyoak にメッセージを送ってください。契約 ID、自分の役割、紛争の簡単な説明を添えてください。

相手方との連絡。 契約のすべての当事者はすでに Beam ウォレットを使用しており、ウォレットにはプライベートメッセージ機能が組み込まれているため、リクエスター、ワーカー、仲裁人は外部アプリを使わずに直接連絡を取り合えます。右上のアカウントメニューから Beam Messenger を開いてください。チャットを始めるには、「New chat」をクリックし、相手方の Beam メッセージアドレスを「Address」欄に貼り付け、相手の名前を入力して追加します。メッセージを入力し、ctrl+enter、Mac では command+enter を押すか、右側の「Send」をクリックして送信してください。他の人から連絡を受ける際に伝える自分のメッセージアドレスは、同じ「New chat」ダイアログに表示される「My address」です。メッセージは Beam の SBBS レイヤーを通じてウォレット間で送信され、オンチェーンに投稿されることはありません。紛争の解決は引き続き上記の仲裁人を通じて行います。ここで説明した機能は、相手方との連絡調整に使うものです。 M of N 仲裁（稼働中）。 コントラクトは、各スロットが継続的なステークに裏付けられた、グローバルな仲裁者レジストリを保持します。紛争の申請時に、その紛争に対して N（申請時点のレジストリの規模）と M（= N/2 + 1）が固定され、申請ブロック以前に登録された仲裁者のみが投票できます。M 件の一致する投票が集まると、コントラクトによって解決されます。合意に達した投票者は紛争手数料を分配します（各自が dispute_fee / M を受け取り、端数はトレジャリーに入ります）。仲裁者が勝者側の資金を受け取ることはありません。仲裁者のステークがスラッシュされることはありません。v2 以降、登録には制限が設けられており（BEAM のみ、最低 10 BEAM、管理者の共同署名が必要）、少額のボンドによってレジストリが乗っ取られることはありません。

現在 N は 1 で、仲裁者は 1 名のみ登録されています（連絡先は下記）。次の優先事項は、独立した仲裁者をさらに登録することです。仲裁者のスラッシュ機能が実装されるまでは、登録に 10 BEAM のステークと管理者の共同署名（審査制）が必要なため、参加をご希望の場合は上記の連絡先までご連絡ください。MCP サーバーとエージェントデーモンは v2 の機能に対応しています（M of N の支払額、ワーカーボンドのツール、紛争の表示）。投票は意図的に人間が CLI から行う操作としており、エージェントのツールにはしていません。そのため、エージェントが紛争を裁定することは決してありません。dapp には従来の単独仲裁者向けコンソールが引き続きあります。アップグレード後もエスクローのフローはバイト単位で同一のため、そこに支障はありません。dapp の仲裁者向け機能の改修（UI からの登録、投票、claim_reward）は、外部の仲裁者が必要になるまで保留しています。上記の CLI の方法は、今すぐ利用できます。

ワーカーの評判ボンド（v2）。 ワーカーは、自身のコントラクト公開鍵にひも付けて、継続的なスラッシュ可能ボンドをロックできます。紛争を申請すると、有効なボンドが拘束され（紛争が終了するまで回収できなくなります）、定足数によるワーカー不利の解決が行われると、ボンド全額がトレジャリーにスラッシュされます。ワーカー有利の解決または無効化の場合、ボンドはそのまま解放されます。スラッシュされたボンドのトレジャリーへの移動は、そのボンドを拘束したすべての紛争が終了するまで保留されるため、古い紛争が新たに再登録されたボンドに影響を与えることはありません。これは Idios の評判システムのオンチェーン部分です。次に実装するのは、オフチェーンのスコア読み取り機能です。

コントラクト固有の鍵。 各当事者は、コントラクト ID を入力の一部として Env::DerivePk を使用し、公開鍵を導出します。コントラクト A におけるワーカーの公開鍵は、コントラクト B における公開鍵とは異なります。node_pk を create に渡す前に、必ず対象のコントラクトで get_key を実行してください。

返金のセマンティクス。 refund は、expiry_block を過ぎた後、期限切れのコントラクトから依頼者への支払いを返します。これは 2 つのケースで機能します。ワーカーが一度もコミットしていない場合（ステータスが Open）、支払いはそのまま返されます。ワーカーがコミットしたものの納品しなかった場合（ステータスが Active）も、依頼者に返されるのは支払いのみで、ワーカーの担保はどちらの当事者にも返されず、トレジャリーに没収されます。これにより、コミットした後に連絡を絶ったワーカーにペナルティを科すとともに、担保は常にトレジャリーに入り、依頼者には渡らないため、依頼者が期限を短く設定してワーカーのステークを奪うことを防ぎます。納品済みのジョブは返金できず、解決手続きに進む必要があります。

無効化のセマンティクス。 紛争が申請され、arbitrator_timeout_blocks 以内に仲裁者が解決しない場合、その期間が経過した後、誰でも void_dispute を呼び出してコントラクトを Voided 状態にできます。その後、依頼者は void_claim_requester で支払いを回収し、ワーカーは void_claim_node で担保を回収し、トレジャリーは紛争手数料を回収します。これにより、仲裁者が不在でも資金が閉じ込められることはありません。

ブリッジなし、クロスチェーンなし。 Idios は Beam メインネット上だけで動作します。ラップ済み資産も、別のチェーンもありません。

---

Idios で AI エージェントを実行する

idios-mcp-server/ はすべてのコントラクト操作を MCP ツールとして公開するため、MCP に対応するあらゆるエージェントフレームワーク（Claude Code、LangGraph、CrewAI、AutoGen）で、平易な言葉を使ってプライベートエスクローコントラクトの作成、作業、決済、異議申し立てができます。26 個のツールで、両方のモードでの作成、担保、納品、承認、リアルタイムの投票状況を確認できる異議申し立て、二重請求を防止するガード付きの請求、復旧手順、v2 ワーカー評判ボンドまで、ライフサイクル全体をカバーします。異議申し立てへの投票は意図的にエージェントツールから除外されているため、エージェントが自分に有利な裁定を下すことは決してありません。

pip install idios-mcp-server でインストールするか、このリポジトリから実行してください。まずは idios-mcp-server/QUICKSTART.md をご覧ください。何もない状態から、メインネット上でエージェントが決済するコントラクトを作成するまでの手順を説明しています。

---

エージェントランタイムデーモン

このリポジトリの idios-agent-daemon/ は、Idios コントラクトにおける自分の役割を自動化する小規模な Python デーモンです。チェーンをポーリングして追跡中のコントラクトを監視し、ステートマシンが次の段階に進むと適切なコントラクト呼び出しを実行します。Beam CLI ウォレットと一緒に自分のマシンで実行し、起動時にパスワードを一度入力すれば、あとは任せられます。

次の 2 つの当事者の役割に対応しています。

• ワーカー commit、submit_delivery、claim（勝訴した異議申し立てを含みます。オンチェーンの winner_paid フラグで保護されるため、支払い済みの請求は再試行されません）。
• クライアント ハッシュ一致時の自動承認、期限切れ後のオプションの自動返金、勝訴した異議申し立ての請求。

どちらの役割でも、仲裁人のタイムアウトを過ぎた場合は古い異議申し立てを無効化し、Voided 状態のコントラクトから自分の分を取り戻します。仲裁人の役割はありません。異議申し立ての解決は CLI を介した人間による M-of-N 投票であり、自動化されることはありません。

dapp の My Contracts ページには、追跡中の各コントラクトカードに このコントラクトを自動化 ボタンがあります。このボタンで生成されるデーモン設定スニペットは、そのままデーモンの設定に貼り付けられます。セットアップと設定については idios-agent-daemon/README.md をご覧ください。

---

ロードマップ

このロードマップはパートナー主導です。フェーズ 0 はメインネットで稼働しています。フェーズ 1 は次回のリリースとして計画されています。それ以降はすべて、実際の需要に応じて決まります。

フェーズ 0（リリース済み）：メインネットで稼働中

• Beam メインネット上の M of N v1 コントラクト（cid 41ef8be5...）。2026 年 6 月 21 日に Upgradable3 を介して v6 からその場でアップグレード：グローバルな仲裁人レジストリ、投票ベースの紛争解決、ステークベースのシビル耐性
• v2 アップグレード。2026 年 7 月 8 日（ブロック 3938963）に Upgradable3 を介してその場で実施：仲裁人登録の強化（BEAM のみ、最低 10 BEAM、管理者の共同署名）およびスラッシュ可能なワーカーの評判ボンド。スラッシュの全ライフサイクルをメインネットで実証済み
• ハッシュ検証（モード A）とレビュー（モード B）の両方に対応した決済
• モード B の 4 つの解決経路をメインネットでエンドツーエンド検証済み：承認、どちらか一方への裁定、レビューのタイムアウト、仲裁人のタイムアウトによる無効化
• ワーカーの担保最低額、双方合意によるキャンセル、レビュー期間終了時のフォールバック（v5 の最小限の修正セット）
• Dapp 3.3.0（引き続き v6 のエスクローサーフェスを使用。バイト単位で同一のため影響なし。仲裁人サーフェスの再設計は延期）
• BEAM と Nephrite（NPH）による決済。どちらもメインネットでテスト済みで、asset_id によるその他の Beam 機密資産にも対応
• エクスプローラーパーサー、エージェントランタイムデーモン（ワーカーと依頼者の役割）、v2 の全ツールセットを備えた MCP サーバー、Dapp のデーモン設定エクスポート

フェーズ 1（次回）：真の分散化と評判

• 仲裁人を増やします。現在 N は 1 です。別々の運営者が管理する、独立した鍵をあと 2 つ追加すれば、実質的な 2-of-3 のクォーラムになります。10 BEAM のステークと管理者の共同署名が必要です（スラッシュ機能のリリースまでは選定制です）。参加を希望する場合はお問い合わせください。CLI は現在利用可能で、サーフェスの再設計は後日行います
• Dapp の仲裁人コンソールを再設計：UI から登録、投票、claim_reward を行えるようにし、廃止された単一仲裁人用の裁定ビューを置き換えます。MCP サーバーとエージェントデーモンは 2026 年 7 月に v2 サーフェスへ移行しました（M of N の支払額、ワーカーボンド用ツール、紛争ビュー。廃止された裁定フローは削除済み）。外部の仲裁人が UI を必要とするまで延期します。現在は CLI を利用してください
• 仲裁人のスラッシュ。v1 のステークはシビル耐性のみを目的としています。合意に反する投票を行った仲裁人へのスラッシュは、Upgradable3 を介してその場で実施する次のコントラクトアップグレードです
• プライバシーを保護する評判。ワーカーボンドとスラッシュ機能は v2 でリリース済みです。残るのは、オフチェーンのスコアリーダーと、評判を公開ハンドルに紐付けつつ取引履歴を漏らさないための、Beam NameService を介した有料ハンドルです

フェーズ 2：ペイロードの配信と大規模な成果物

• 大規模な作業成果物。現在、納品物は 32 バイトのハッシュで識別され、コンテンツはオフバンドでやり取りされます。次の段階では Beam Desktop に統合された IPFS レイヤーを使い、ワーカーが暗号化した納品物を公開し、依頼者が取得できるようにします。一方、コントラクトがコミットするのは引き続きハッシュのみです
• 暗号化されたペイロード。鍵はオフバンドで交換します。オンチェーンのハッシュは拘束力のあるコミットメントとして維持し、ペイロードの正式な保存場所を定めます
• 1 回の受け渡しで扱える範囲を超える大容量の作業ファイルに対応

フェーズ 3 以降：今後の研究（パートナー主導）

• パートナーから具体的なニーズがある場合に、用途を限定したジョブクラス向けのプログラムによる検証機能（例：JSON スキーマとの一致、決定論的な出力の同等性）
• 排出とスラッシュを備えた分散型仲裁人ネットワーク（パートナー主導）。Idios は Beam コントラクトのまま維持し、外部のインセンティブレイヤーが運営者のステーキングとスラッシュを担います
• 実際のパートナーから必要とされる場合に限り、クロスチェーン決済に対応します。基本方針：Beam メインネットを利用し、ブリッジは行いません

---

貢献

Idios はまだ初期段階にあり、急速に開発が進んでいます。Beam 上で開発していて統合を希望する場合は、issue を作成するか、直接お問い合わせください。