Design proposal: fail-closed counterparty trust verification for payment action providers (signed one-time verdicts, ATC/1.0)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- cryptography, python, typescript
調査の方向性
Start by reading the payment action provider integration, especially BasePayActionProvider, and the policy-hook scaffolding referenced in #1349. Review the 14 conformance vectors and the existing pay-mcp-bridge tests, which demonstrate deny-before-spend behavior across failure classes. The issue defines the desired verification and fail-closed behavior, but leaves implementation scope, trust-band semantics, configuration, and completion criteria to clarify.
索引モデルが issue の本文から書いたものです。
説明
Language Implementation
- TypeScript
- Python
Feature Type
- Framework Extension
🚀 The feature, motivation and pitch
AgentKit agents can send USDC to counterparties they have never interacted with (#1565 covers this from the decision side). Today, a pre-spend trust check has no standard, verifiable primitive to consume: reputation scores are unsigned and replayable, so a policy hook built on them cannot be fail-closed by construction — an unverifiable score is indistinguishable from a spoofed one, and a missing field silently becomes "score = 0" or "score = OK" depending on the client.
Proposal: a counterparty trust verification hook for payment action providers (BasePayActionProvider and similar), consuming Agent Trust Cards (ATC/1.0) — Ed25519-signed agent identity cards whose verification produces a one-time signed verdict: verdict_id, trust band (B0–A1), per-stage outcomes, sha256 digest of the canonical signed subtree, JCS (RFC 8785) canonicalisation, two-sided validity window, pinned CA anchors.
The hook runs before a transfer:
- obtain the counterparty's ATC/1.0 card (from payment metadata or a card URL the counterparty presents);
- verify it — via a verification endpoint, or locally (the reference scorer is small and dependency-free);
- enforce a configured minimum trust band: verdict below threshold, missing field, bad signature, or verifier unreachable ⇒ deny by default (fail-closed; deny-before-invoke is the invariant);
- attach the signed
verdict_id+ band to the transaction record for audit.
This composes with the policy-hook scaffolding in #1349: verification supplies evidence; the policy layer remains the single authority that decides.
Production evidence (already running):
- Live x402 verification endpoint on Base mainnet (0.01 USDC/verify; 0.08 USDC per 10-card batch — batch fits marketplace/escrow flows), ATC/1.0, x402 v2:
https://uta-trust-api.eddyflores100.workers.dev/v1 - 14/14 conformance vectors public (canonicalisation byte-exact against published canonical files)
- Fail-closed runtime bridge with 17 green tests demonstrating the deny-before-spend invariant across 6 failure classes: https://github.com/alicelabs-llc/universal-trust-adapter/tree/main/pay-mcp-bridge
- Crosswalk to ERC-8004 (identity + reputation registries deployed on Base) showing how cards layer on 8004 identities: https://github.com/alicelabs-llc/universal-trust-adapter/blob/main/docs/crosswalks/erc-8004-atc-v1.md
Alternatives
- Static YAML/JSON policy snapshots (#1349's direction): necessary, but a snapshot cannot answer "is this counterparty trustworthy right now" — no runtime evidence.
- Unsigned reputation APIs (score-only endpoints): not fail-closed; see above.
- ERC-8004 reputation read directly on-chain: valuable, but per-action weighting is unstandardised; ATC verdicts are signed by a pinned CA with explicit, published scoring semantics.
Additional context
Related: #1565 (pre-payment counterparty trust check — complementary: it makes the pay/caution/skip decision, ATC verdicts supply the verified identity evidence behind it), #1349 (policy hook scaffolding — the natural host for this hook).
Non-goals: no duplication of wallet runtime authority; no per-payment remote dependency by default (verification at first interaction + TTL re-check suffices for most flows); strictly opt-in configuration.
Happy to provide the reference scorer port, the conformance vectors, or a minimal provider implementation in TypeScript or Python.
- 主要言語
- TypeScript
- スター
- 1.3k
- フォーク
- 871
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
coinbase/agentkit のほかの issue
-
Python: Permit2 approval in CdpSmartWalletActionProvider.swap always reports failure (integer vs string receipt status)対応中かも @0xLittleDream が 1 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
メンテナーはふだん 1 日以内に返信
-
Moonwell redeem fails on Base Sepolia and uses 18 decimals for cbBTC対応中かも @sebxt が 4 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
coinbase/agentkit#1578 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
ERC20 transfer reports "Transferred" when the transaction reverts (receipt status ignored)対応中かも @AgenticFinanceGraph が 13 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
coinbase/agentkit#1558 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
[TypeScript] `ViemWalletProvider` rejects a wallet client from a newer viem than the exactly pinned one (TS2345, `tokens` missing on `Client`)対応中かも @PrabalParihar が 4 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
coinbase/agentkit#1532 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
coinbase-agentkit 0.7.x fails on fresh install: imports solana.rpc.api, which solana>=0.37 removed対応中かも @JulienKervarrec が 31 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
coinbase/agentkit の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
awesome-dsh-plugin/awesome-dsh-plugin#9184 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
farion1231/cc-switch#8829 ·
メンテナーはふだん 1 日以内に返信
-
[core-client] Remove unused hand-maintained transport helpers after the definition-table cutoverオープンdoc-audit enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100