Design proposal: fail-closed counterparty trust verification for payment action providers (signed one-time verdicts, ATC/1.0)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- cryptography, python, typescript
- Domain
- api, backend-api-design, security
Research direction
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.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- TypeScript
- Stars
- 1.3k
- Forks
- 857
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from coinbase/agentkit
-
ERC20 transfer reports "Transferred" when the transaction reverts (receipt status ignored)Possibly taken @AgenticFinanceGraph claimed this 8 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
coinbase/agentkit#1558 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
coinbase/agentkit#1532 · 1 comment ·
Maintainers usually reply within 1 day
-
coinbase-agentkit 0.7.x fails on fresh install: imports solana.rpc.api, which solana>=0.37 removedPossibly taken @JulienKervarrec claimed this 26 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
x402 action provider: optional beforePayment hook to approve or block a paymentPossibly taken @snefhew claimed this today. Open
Difficulty 4/5 1-2 days Newbie friendliness 55/100
Maintainers usually reply within 1 day
-
SPL transfer and Jupiter swap fail for fractional amounts like 2.01Possibly taken @auraseb claimed this 1 day ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
Maintainers usually reply within 1 day
All issues in coinbase/agentkit
Similar issues
-
docs(api): openapi.yaml still documents gif-tools optimize colors as 2-256 instead of 2, 4, 16, 256Openarea: backend documentation priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
snapotter-hq/SnapOtter#2919 ·
Maintainers usually reply within 1 day
-
accepted :+1: bug db/redis
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
beekeeper-studio/beekeeper-studio#4882 · 1 comment ·
Maintainers usually reply within 1 day
-
ready-for-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
konflux-ci/konflux-ui#1630 · 1 comment ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
ahmedkhaleel2004/gitdiagram#233 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
simkimsia/netlify-axi#19 ·
Maintainers usually reply within 1 day