mcpField
B
biii

biii

リモート
github.com/philpof102-svg金融データ010 週間前に更新
リポジトリ

biii について

BIIIは、Base上の加盟店やエージェント向けの非カストディアルな決済・信頼性評価ツールです。決済、オンチェーン検証、レシート、リスク確認を扱い、MCPインターフェースには決済や資産確認などの29個のツールがあります。

主な機能

  1. 01USDCの請求と決済用QRコードの作成
  2. 02オンチェーン送金の検証とレシート発行
  3. 03加盟店、エージェント、トークン化資産の評価
  4. 04請求書の作成と確認
  5. 05レシート記録のCSV出力
  6. 0629個のMCPツールを提供

活用シーン

  1. 01店舗でスマートフォンを使ってBase上のUSDCを受領
  2. 02支払い前に加盟店やトークン資産のリスクを確認
  3. 03エージェント決済用の請求書を作成・検証
  4. 04トランザクションハッシュ付きの会計記録を出力

MCP 対応

MCPサーバーは、決済の作成・検証、信頼性や資産の評価、請求書処理、会計記録の出力に使える29個のツールをエージェントに提供します。

設定

リモートサーバーはインストール不要です。クライアントを選んで設定をコピーするか、ワンクリックで導入できます。

エンドポイントhttps://biii-production.up.railway.app/mcp
インストールコマンドをコピー
Claude CodeTerminal
Cursor.cursor/mcp.json
VS Code.vscode/mcp.json
Claude Desktopclaude_desktop_config.json
Windsurf~/.codeium/windsurf/mcp_config.json

コマンドはターミナルで実行し、JSON は各クライアントの MCP 設定に貼り付けて再起動します。認可が必要なサーバーは初回接続時にログインを求めます。

パッケージ
npmbiii-mcp0.2.1

ツール

29
パラメーター型必須説明
addressstringはい0x 加盟店アドレス
resourceUrlstringいいえ省略可能 — 支払い先のエンドポイント/リソース URL。ローカルで URL を検査し、フィッシング、平文 HTTP、管理パスを検出します

詳細

BIII

エビデンス付きの、Base における安全な支払い判定:29 個のツール、55 個のモジュール、 142 個のテストファイル、独自の上限値を公開する 54 個のプローブ。非カストディアルで、記述子のみを使用し、 すべての判定をオンチェーンで再検証できます。

読み方は「B3」。表記は BIII — 3 本の横棒がある B です。 Base 上の、実店舗で使える USDC レジです。独立した加盟店が、電話 1 台だけで対面で USDC を受け取れます。非カストディアル(加盟店自身のウォレットを使用)、決済端末不要、PSP 不要、KYB の仲介業者も不要です。

B = Base · 3 = 三部作の第 3 フェーズであり、Base の 3 本の柱でもあります。


ギャップ(憶測ではなく、調査に基づく — 2026-07-21)

Base での USDC 受け取りは、オンラインの大企業では解決済みですが、実店舗の独立事業者には未解決です。

既存のサービスこれとは異なる理由
Base Pay(Coinbase)オンライン決済専用 — ブラウザー向けの pay() SDK であり、対面決済も QR もなく、ウェブサイトなしでは利用できません
LyziPSP と実店舗用端末(Ingenico/Verifone)が必要で、決済プロバイダー経由の大企業向けサービスです
Flexa + Base Pay対面で利用できますが、Flexa ネットワークの加盟店である必要があります
BitPay / Binance Pay / Ecoカストディアルな決済処理業者です — KYB と手数料があり、資金を預かります
Shopify POS + USDCShopify が必要です
アドレスと QR のみ(自作)UX も確認も領収書もなく、技術的です

Base で USDC を受け取り、資金を自分のウォレットに保管し、実際の領収書を渡したいカフェ、市場の屋台、配管工、フリーランサーにサービスを提供する人はいません。必要なのは電話 1 台だけで、アカウント開設もなく、2 分で済む方法です。

(上記の日付時点でサービス状況を確認済みです。公に主張する前に再確認してください。Base/Coinbase/Flexa/Lyzi と互換性のあるものを構築しており、提携関係は主張しません。)

三部作 — フェーズ 3:エージェント経済が実世界の人々に支払う

MainStreet   →  WHO is safe to pay            (the reputation oracle)
LAWBOR       →  agent ↔ agent, outcomes PROVEN paid in USDC on Base
BIII         →  agents & humans  →  REAL-WORLD merchants     ← this

BIII は、オンチェーンのエージェント経済と街角の店主をつなぐ架け橋です。同じ「安全に支払える」という原則と、「実際の USDC 送金によって支払いが証明される」という規律を、レジに適用します。

仕組み

  1. 加盟店が金額を入力します。→ チャージが作成されます(データのみ。加盟店自身のアドレスを使用)。
  2. BIII がユニバーサル QR を表示します。これは、主要なあらゆるウォレット(Base App、Coinbase Wallet、MetaMask、Rainbow…)で読み取れる EIP-681 決済 URI です。
  3. 顧客(または AI エージェント)が、自分のウォレットから Base 上で USDC を支払います。
  4. BIII がチェーンを監視し、各フィールドを照合して送金を検証します。トークン/チェーン/受取人の間違い、支払い不足、未確認の場合は、いかなるときも未払いです。超過分はチップになります。
  5. 双方に、txHash にひも付けられた領収書が発行されます(誰でも Basescan で反証できます)。

BIII は秘密鍵を保持せず、資金を動かしません。 インテントを発行してチェーンを読み取るだけです。署名するのは顧客のウォレットで、「支払い済み」と判断できるのは私たちではなくチェーンだけです。

実行方法

npm test                               # all offline; 1269 assertions across 96 files + a 22-case eval harness (2026-08-05)
node test/suite-total.js               # re-derives that count — two report formats coexist, so grep undercounts it
BIII_MERCHANT=0x<your address> npm run serve   # the non-custodial HTTP surface, :4700
  • lib/till.js — 純粋なコア:金額計算、請求、EIP-681 URI、検証、レシート
  • lib/chain.js — 読み取り専用の Base ウォッチャー(支払いに使われた送金を見つけます。決して捏造しません)
  • lib/server.js — 薄い HTTP 層:/charge、/status、/receipt、/trust(ローカルで安全に支払えるかどうかの判定を、1 回の fetch() で返します。既知の悪質な対象のスクリーニング、このノードの trust-core 分類器、フロアの来歴を組み合わせ、フェイルクローズで、CORS はオープンです。あらゆる Web アプリが MCP なしで支払い前チェックを組み込めます。MCP ツールと lib/vet.js を共有しているため、2 つのインターフェースで判定が食い違うことはありません)、/asset(トークン化資産の真正性を 1 回の fetch で判定します。genuine/impersonation/unsafe/unknown を返し、フェイルクローズです。レジストリにないトークンを誤って genuine と判定することはありません。あらゆるページが組み込める取引前チェックで、オンチェーンで再検証します)
  • lib/trust.js — 信頼の三角形:レピュテーション(MainStreet)+良好な状態(LAWBOR)+決済(チェーン)を組み合わせ、フェイルクローズの判定(unsafe/unknown/trusted/settled)を 1 つ返します
  • lib/invoice.js — Web2 形式の請求書にも同じレジストリを使用:請求書番号、明細(厳密なマイクロ単位計算)、支払期限、請求先を含みます。同じ EIP-681 で支払い、同じチェーン検証の規律で検証し、決済済み/期限超過のライフサイクルを管理します。レシートはカフェの売上と同じ、証明可能な till ロールに記録されます
  • lib/asset.js — トークン化資産(株式/米国債/RWA)にも同じレジストリを使用:そのトークンコントラクトは、真正な発行体のものですか、それともなりすましですか?genuine/impersonation/unsafe/unknown を返し、フェイルクローズです。FBI が警告した類似トークン詐欺を検出し、信頼の三角形(till_vet_asset)に組み込みます。
  • 発行体検証済みレジストリ(data/issuer-verified.json、コミット済み、マルチチェーン) — 強い緑色の「発行体検証済み」バッジを付与する、権威ある、API キー不要で商用利用に安全なレイヤーです。11 チェーンに 183 件(2026-08-05 に hermes/economy/probe-readme-claims.js で集計。このスクリプトはこの文ではなくレジストリを読み取ります)。すべて発行体の直接情報源に基づきます:Dinari dShares(Base 上に 54 件。ファクトリーの DShareAdded イベントからオンチェーンで列挙し、それぞれを symbol()/name() で再検証。scripts/biii-rwa-issuer-direct.js)、Backed / xStocks(Backed 独自の公開 API api.backed.fi から Ethereum/Optimism/BSC/XLayer/Mantle/Arbitrum/Ink に 100 件。API キー不要。さらに Base 上に backed-fi/tokenlists から 12 件。scripts/biii-issuer-backed.js)、Ondo(9 件の OUSG/USDY/rUSDY。公式ドキュメントに基づき、それぞれオンチェーンで検証済み)、および Base 上の単一発行体による 8 件(Circle USDC/EURC、Coinbase cbBTC/cbETH、Franklin Templeton BENJI、Lido、Aerodrome)。 lib/asset-registry はアドレスをキーとして、これをアグリゲーターのデータに優先して統合します。そのため検証済みアドレスの provenance は issuer-official(緑色)となり、それ以外はすべてアグリゲーターの青緑色のままです。
  • scripts/biii-rwa-registry.js — アグリゲーターのフォールバック(青緑色の「掲載済み」レイヤー)を構築します。Coingecko の無料プラン(API キー不要)から data/rwa-registry.json に取り込み、generatedFrom: "coingecko (free)" を設定します。Coingecko はアグリゲーターなので、ここでの一致は provenance: aggregator(青緑色の「掲載済み」)であり、発行体検証済みの緑色にはなりません。さらに、クロスチェック(scripts/biii-issuer-registry.js)では、アグリゲーターに掲載されたシンボルのアドレスが発行体公式のアドレスと異なる場合(類似トークンの可能性あり)に警告します。**フェイルセーフ:**各項目はすべて検証に合格する必要があります(0x+40 桁の 16 進数・整数の chainId・シンボル)。そうでなければ除外されます。スキーマの変更によってレジストリが空になることはあっても、「真正な」アドレスを誤って返すことはありません。
  • lib/export.js — 財務チームに必要な会計エクスポート:till_export は同じ検証済みレシートを会計担当者向け CSV に変換します(QuickBooks/Xero/Excel にインポート可能)。すべての行に txHash と Basescan のリンクが付きます。信頼すべき帳簿ではなく、チェーンへのポインターです。カストディ不要で、再検証できます。
  • lib/meter.js — ホワイトラベルのパイロット導入に向けた使用量→請求の仕組み:till_meter は 1 か月分のレシートを、渡されたプランに基づく請求に変換し、信頼度ごとに分けます。決済済みレシートはオンチェーンで証明可能ですが、判定件数は自己申告(参考情報)であり、その旨が明示されます。純粋でステートレス、カストディ不要です。
  • lib/erc8004.js — 主要なエージェント・レピュテーション標準(ERC-8004)との相互運用:ReputationRegistry.getSummary の結果を、till_trust を別の観点から確認するための、参考情報としての再検証可能なレンズに変換します。フィードバックはクライアントが送信するため(Sybil 攻撃で水増し可能)、支払い可否の判定には決して含めません。参考情報として示し、信頼できるクライアントに絞り込まない限り Sybil に関する注意書きを残し、Base 上で getSummary を再検証できるよう常に案内します。
  • 分散性は主張ではなく、検証可能です — 既知の悪質な対象のフロアにはコンテンツのフィンガープリント(floorFingerprint/till_floor)が含まれます。同じフィンガープリントを持つ 2 つのノードは、名前が明記された公開 MIT リストから再生成できる、同一の客観的なフロアに基づいて判定します。そのため収束の基盤は公開データ+決定論的ハッシュであり、中央管理者ではありません。分類器は複製され(純粋な trust-core)、フロアは公開データに基づいて収束し、相対的なレピュテーションは意図的にローカルに保たれます。差異がある場合も常にフェイルクローズです(データの少ないノードはより慎重になり、決して寛容にはなりません)。
  • lib/identity.js — エージェント連携:npub と/または did:key ↔ Base、トラストレスです。buzz/Nostr アイデンティティ(secp256k1 npub)**または gitlawb アイデンティティ(Ed25519 did:key)**のいずれか、または両方を、支払い可能で信頼性を評価できる Base アドレスに解決します。双方向のアテステーション(存在する各アイデンティティキーが署名し、Base キーも同じ正規化されたメッセージに署名します。誰でも再検証できます)を用います。フェイルクローズです。未検証、アイデンティティキーの署名欠落、アイデンティティキーなし、期限切れの場合は、紐付けではなく単なる申告として扱います。解決しても信頼が確立するわけではありません。アドレスに対して信頼の三角形を実行する必要があります。
  • lib/skyfire.js — Skyfire(Experian のエージェント・アイデンティティレイヤー)との相互運用:(1)KYA JWT のレンズ。エージェントを誰が後ろ盾になっているかを示します(参考情報、リプレイ対策用の aud を確認し、弱いセキュリティ態勢を明示します。exp がない、または audience に紐付いていないトークンにはフラグを立て、厳格な呼び出し元は requireExpiry で拒否します)。(2)authorizeCharge — プログラマブル決済:エージェントの所有者が承認した範囲内の場合に限り、請求を実行可能な EIP-681 インテントにします。トークン、受取人の許可リスト、請求ごとの上限、さらに累積上限のすべてが対象です(資金流出を防止:少額請求を 10 回行っても低い上限を超えられません。不正形式または未指定の上限は「上限なし」と見なさず、拒否します)。どちらもフェイルクローズです。BIII は JWT 署名を自ら検証しません(依存関係なしで委任します)。
  • bin/biii-mcp.js — エージェント連携ブリッジ:あらゆるエージェントが読み込める MCP(29 個のツール。エクスポートされた TOOLS リストから集計しています。ソースコードに対する正規表現では、名前に数字を含む till_b20_authentic が誤って除外されるためです: till_authorize、till_b20_authentic、till_check_invoice、till_check_payment、till_create_charge、 till_create_invoice、till_export、till_floor、till_funder_history、till_key_exposure、till_kya、 till_launch_funder、till_meter、till_open_approvals、till_receipt、till_recovery_offer、 till_resolve、till_roll、till_rug_powers、till_seed_exposure、till_trace_theft、till_trust、 till_verify_delivery、till_vet_agent、till_vet_approach、till_vet_asset、till_vet_meme、 till_vet_merchant、till_watch_wallet)。エージェントは加盟店やトークン化資産を審査し、1 回の呼び出しで信頼の三角形全体を取得し、請求書を発行または支払い、レシートを保管し、帳簿をエクスポートし、使用量を計測し、フロアを証明し、buzz の npub または gitlawb の did:key を Base アドレスに解決し、KYA アイデンティティを読み取り、署名済みの承認範囲内でのみ支出し、証明可能な帳簿(till_roll)を生成できます
  • pitch/trust-triangle.html — 販売可能なホワイトラベルの 1 ページ資料(単体で動作し、テーマに対応)
  • COMPETITION.md — 調査済みの市場動向(作成日記載):決済レール(x402/Stripe)を活用し、標準(ERC-8004/Skyfire KYA)と相互運用し、カストディは行いません。オープンなレイヤーはカストディ不要の信頼レジストリです
  • INTEGRATION-buzz.md/INTEGRATION-gitlawb.md — 誠実なパートナーシップ概要。どちらにも実行可能なオフライン証明が付属します(examples/buzz-agent-pays.js、examples/gitlawb-agent-pays.js。CI でスモークテスト済みのため、デモが古くなりません)。キーペアを持つエージェントが解決して Base に到達し、制裁対象の取引相手はブロックされ、問題のない支払いは txHash に紐付いたレシートとともに決済されます
  • web/ — 加盟店向けモバイルアプリ(PWA):金額 → QR → 支払い完了 ✓ → レシート

ビジネスモデル — パートナーが再販する信頼+ブリッジレイヤー

BIIIは、加盟店を1つずつ成長させるためだけのアプリではありません。すでに加盟店を抱えている企業が組み込む、ホワイトラベルの信頼+ブリッジレイヤーです。

顧客基盤はパートナーが提供します。BIIIは、信頼できるUSDC決済と、人間/エージェント間のブリッジ、そして検証可能なレシートを提供します。PSP、ネオバンク、加盟店プラットフォーム、Baseエコシステムのアプリに販売します。

その話し合いに使う1ページ資料 — 信頼の三角形、4つの判定状態、ホワイトラベルの分担、レシート、そして誠実な業界概観 — は pitch/trust-triangle.html にあります(自己完結型、テーマ対応、外部リクエストなし)。

LyziはPSP向けのホワイトラベルですが、端末/エンタープライズ向けで、人間のみを対象としています。BIIIもホワイトラベルに対応しており、さらにAIエージェントによる決済、偽造できない消費者向けレシート、非カストディアル運用を実現します(パートナーが加盟店の資金に触れることはないため、送金業者としての資金保管ライセンスは不要です)。この組み合わせが差別化の要です。

方針:流通網を持つパートナーを心から歓迎します。Base/Coinbase/Flexa/Lyziと互換性のある形で構築し、契約が締結されるまでは提携を主張しません(誇大な宣伝はしません)。

信頼のロードマップ — 両者を安全に

  • 現在: 支払者はオンチェーンのフィールド単位の検証によって保護されます。加盟店は、MainStreetの「安心して支払える」評判(till_vet_merchant)を通じて審査できます。これは助言目的です。
  • 次の段階(ZK): プライバシーを保護する証明により、個人情報をさらすことなく、双方が重要な事実を証明できるようにします — 「この加盟店は検証済みです」「この支払者は信頼できる/資金を保有しています」 — データのダンプではなく、ゼロ知識バッジとして実現します。レシートはすでに決済を証明します。ZKは当事者を証明します。(設計は追跡中、まだ構築されていません — リリースまではZKに関する主張をしません。)

レシートと帳簿(人間向けのレイヤー)

lib/ledger.js は、決済を暗号資産に詳しくない人でもすぐに読める紙のチケット(加盟店、B3-####、商品、金額、チップ、✓ 支払済み、検証リンク)と、加盟店向けの証明可能な日次集計に変換します — すべての明細をオンチェーンで再確認でき、1つのtxHashは1回だけ計上され、水増しできない帳簿です。今日、対面でのUSDC決済にこれを提供しているところはありません。信頼を目に見える形にします。

妥協できない原則

設計上、非カストディアル · ディスクリプターのみ(署名せず、資金を保管しない) · 「支払済み」の唯一の真実の情報源はチェーン · 誰でもすべてのレシートを再検証可能 · 実際の数値のみを使用し、利用状況や提携を捏造しない

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。