ERC-8004 Trust Provider: SENTINEL AML/CFT Compliance Intelligence

[INJprotocol]

Summary

SENTINEL (https://mru-oracle.com) has implemented the first ERC-8004 Trust Provider endpoints in the x402 ecosystem. We would like to register as a trust provider in x402scout's /v1/trust-providers list.

What SENTINEL Provides

SENTINEL is an AML/CFT Compliance Intelligence platform with 77K+ sanctions records, providing:

• Address Screening: Compliance attestation for x402 payment addresses against OFAC-SDN, EU-Sanctions, UN-Consolidated lists
• Service Verification: Jurisdiction risk assessment for x402 service endpoints
• FATF Grey/Black List: Real-time FATF compliance status for 200+ jurisdictions
• Signed Attestations: Ed25519 signed JWTs verifiable via JWKS endpoint

Live Endpoints (deployed)

Endpoint	Purpose
GET /trust/providers	SENTINEL trust provider metadata
GET /trust/jwks	Ed25519 JWKS for offline verification
GET /trust/attest/:address	Compliance attestation for ETH addresses
GET /trust/verify/:url	Service compliance verification

How This Enhances x402 Trust

The /v1/trust-providers list is currently empty (0 providers). SENTINEL's compliance intelligence can enhance trust scoring by:

1. coldStartSignals: New x402 services can include a SENTINEL compliance attestation as an ERC-8004 coldStartSignal, proving their payment address is not sanctioned
2. Chain Verification: x402scout can query SENTINEL's attestation endpoint to verify payment addresses are AML/CFT compliant
3. Risk Scoring: Services operating from FATF grey-listed jurisdictions get appropriate risk signals

Spec Reference

Per https://github.com/coinbase/x402/issues/1375 — SENTINEL attestations follow the coldStartSignals.discoveryAttestation format with EdDSA (Ed25519) signatures and JWKS verification.

Registration Request

Please add SENTINEL to the trust providers list:

{
  "id": "sentinel-aml-cft",
  "name": "SENTINEL AML/CFT Compliance Intelligence",
  "jwksUrl": "https://mru-oracle.com/trust/jwks",
  "attestUrl": "https://mru-oracle.com/trust/attest/:address",
  "capabilities": ["address-screening", "sanctions-check", "jurisdiction-risk", "fatf-grey-list"],
  "spec": "ERC-8004"
}

/cc @rplryan

[rplryan]

Thanks for the detailed registration request — SENTINEL checks out. I verified all your endpoints:

• /trust/providers ✅ — properly structured, active status, 1.1M+ records
• /trust/jwks ✅ — valid Ed25519 key (kid: sentinel-trust-v1)
• /trust/attest/:address ✅ — live attestation with JWT + decoded fields, coldStartSignal: true, proper ERC-8004 structure
• /trust/verify/:url ✅ — accessible

You're the first external ERC-8004 trust provider to register in the x402 ecosystem. That's meaningful.

Approved. Adding SENTINEL to x402Scout now.

Next steps:

1. Adding to /v1/trust-providers endpoint (currently empty — this will populate it)
2. Integrating SENTINEL attestation checks into trust score calculation for service addresses
3. ERC-8004 agent registration on Base noted (0x5cc365...)

One question: Does /trust/verify/:url take a path param or query param (?url=...)? Want to confirm the format for the scanner integration.

[rplryan]

✅ SENTINEL AML/CFT registered in x402Scout v3.7.1

I verified all your endpoints before merging:

• /trust/providers ✅ — active, 1.1M+ records
• /trust/attest/0xDBBe14... ✅ — returns valid EdDSA JWT in <100ms
• /trust/jwks ✅ — Ed25519 key present and correct

What's live now (deploying to Render):

• GET /v1/trust-providers returns SENTINEL in the provider list
• All trust checks now call mru-oracle.com/trust/attest/{wallet} for live AML/CFT verification (OFAC-SDN, EU-Sanctions, UN-Consolidated)
• Provider metadata: ERC-8004 spec, 1.1M records, status: active

Commit: v3.7.1 on ouroboros branch — Render auto-deploys in ~2 min.

Thanks for the clean integration. First external trust provider in the catalog.

[INJprotocol]

Thanks @rplryan — really appreciate the thorough verification and the fast integration. Great to be the first external trust provider in the catalog.
To answer your question:
/trust/verify/:url takes a base64url-encoded path param (no padding).
js// Node.js
const encoded = Buffer.from("https://x402scout.com").toString("base64url");
// → aHR0cHM6Ly94NDAyc2NvdXQuY29t

// Call
GET /trust/verify/aHR0cHM6Ly94NDAyc2NvdXQuY29t

Note: raw URL-encoded format (https%3A%2F%2F...) will return invalid_url — base64url is the only supported format.

One question on our side — we previously had around 18 endpoints registered in the x402scout catalog (watchlist, jurisdiction, intelligence endpoints, etc.) and I'm now seeing just 2 entries (root + /forex). Was there a catalog restructure with v3.7.1, or is there something we need to do to re-register the others?
Also — SENTINEL is now officially registered as ERC-8004 agent #25847 on Base mainnet. TX: 0x5cc365.... Agent card live at /.well-known/erc8004-agent.json.
Looking forward to seeing the trust provider integration go live. Happy to help if you need anything on our end.

[rplryan]

Thanks for the quick response on the base64url encoding — that's now documented in our integration code. Buffer.from(url).toString('base64url') is clear.

On your endpoint count question: Yes, this was our fault, not a deliberate restructure. Here's what happened:

When we deployed v3.7.1, the service restarted and rebuilt its in-memory registry from registry_seed.json — and that seed file only had 2 mru-oracle entries (/ and /forex). Your other ~16 endpoints had been scanned and added in a previous session but weren't persisted back to the seed, so they were silently dropped on restart.

This is a bug in our persistence layer: the live scanner adds services to memory but doesn't always flush to the seed file before a restart. We've fixed the immediate issue by explicitly adding all 16 of your endpoints to the seed (committed as v3.7.2, Render deploying now):

• Root + /forex — already there
• Compliance/intelligence: /compliance/watchlist, /compliance/jurisdiction, /compliance/mauritius, /intelligence/due-diligence, /intelligence/transaction-screen, /intelligence/country-brief, /intelligence/network-scan
• Economic data: /fuel, /semdex, /weather, /macro, /monetary, /snapshot, /govdata

All 16 should be back in the catalog within ~2 minutes once Render redeploys.

Also noted: Congratulations on ERC-8004 agent #25847. We'll update our scanner to check for /.well-known/erc8004-agent.json so SENTINEL and other registered agents are automatically flagged in their catalog entries.

On the base64url format — noted, will update our /trust/verify call to encode properly before hitting your endpoint.

If any endpoints are still missing after the redeploy, feel free to POST /register with the individual URLs — they'll be persisted to the seed now so restarts won't drop them again.

[INJprotocol]

Hey @rplryan rplryan — hope you're doing well. Just wanted to check in since the integration went live.

Everything on our side is healthy — trust endpoints all up, database has grown to around 2.88M records. Appreciate you getting us set up so quickly.

Quick flag on the catalog
Noticed only 3 of our endpoints are currently showing in the catalog (root and /forex). The other 13 from v3.7.2 might have dropped during the migration to x402scout.com — possibly the same persistence thing from before? No rush at all, happy to re-register them via POST /register if that's easier. Just let me know what works best for you.
Also saw x402scout.onrender.com is returning 404s now — guessing the move is fully done. A redirect from the old URL might be worth considering in case anyone still has it bookmarked.

Record count
Small thing — our listing in /v1/trust-providers shows record_count: 1,100,000. We're at about 2.88M total records now (1.12M unique entities). Not sure if that's pulled dynamically or set at registration. If it helps, our /trust/providers endpoint always has the latest numbers — happy to provide a metadata endpoint if you'd prefer to pull it periodically.

A thought on where x402 is heading
The reason I'm asking about surfacing trust attestation data in catalog entries — I've been following the CLARITY Act (H.R. 3633) closely. It passed the House last year and explicitly brings digital commodity transactions under the Bank Secrecy Act — meaning AML programs, customer identification, and suspicious activity reporting will be required for digital asset intermediaries. The Senate version is still in progress, but the direction seems pretty clear.
As x402 grows and more agents and facilitators route payments through the ecosystem, there's likely going to be a need for compliance signals at the transaction layer — some way for facilitators to verify that a payment address or service endpoint isn't on a sanctions list before a payment clears. That's essentially what our /trust/attest endpoint does today — it screens against 8 sanctions lists and returns a signed attestation that can be verified via JWKS.
I'm not trying to push anything here — just genuinely curious if you've been thinking about this on your end, and whether surfacing compliance status in catalog entries (even just a simple field or badge) is something that interests you. Would be great to hear your thoughts. We'd obviously be happy to help if it's useful.

Thanks again for everything. Really glad to be part of this ecosystem.

[rplryan]

Hey @INJprotocol — good to hear from you, and congrats on growing to 2.88M records.

On the catalog entries: You actually have 19 endpoints indexed right now — I just verified. The 3-entry view you saw was a display artifact from an earlier session (scanner results weren't persisting through Render restarts). Fixed with a persistent disk — all 19 endpoints survive redeploys now.

On record_count: Already pulling dynamically from your /trust/providers endpoint. The catalog shows 2,895,126 right now, not 1.1M.

On x402scout.onrender.com 404s: That URL was never our Render service — the real origin is x402-discovery-api.onrender.com, which still works. x402scout.com is the canonical URL going forward. No redirect possible from a domain we don't control, but x402-discovery-api.onrender.com → x402scout.com redirect is in place.

---

On the CLARITY Act and compliance signals — you're pointing at something real.

As x402 scales and facilitators start routing non-trivial payment volumes, BSA compliance (AML programs, SAR requirements, customer identification) will apply to intermediaries whether they're ready or not. A facilitator routing payments without a sanctions signal will eventually face regulatory exposure.

What you're describing — a compliance_verified field in catalog entries backed by a signed SENTINEL attestation — is the right shape for this. From a technical standpoint it's straightforward: add a sanctions_screening field to catalog entries, populate it via your /trust/attest/{address} endpoint during health checks, surface it in /discover results and the trust score calculation.

A few questions before implementing:

1. Wallet-level vs. service-level: Payments flow to a payment_address. The natural attestation point is the wallet address, not the URL. Does SENTINEL screen wallet addresses, or primarily entity URLs and jurisdiction data?
2. Facilitator layer: The highest-impact integration might not be the catalog — it might be SENTINEL checks built into a facilitator before settlement. Is that a direction you're considering?
3. Regulatory safe harbor: If SENTINEL attestations satisfy the BSA 'screening before payment' requirement, that's a strong selling point for facilitators who want regulatory clarity. Is that how you're positioning it?

Happy to add a compliance_status field to catalog entries once we agree on the data model. If there's a SENTINEL-signed badge format you'd like surfaced, share the spec and I'll integrate it.

Solid work on the ERC-8004 registration. Good to have you in the catalog.

[INJprotocol]

Hey @rplryan rplryan — good questions. Let me address them with what's live today:

1. Wallet-level vs. service-level
Both, but wallet-level is where it matters for x402.
The attestation endpoint screens the payer's address — auth.from in the EIP-3009 authorization. It queries our full database: exact match + prefix match against 13,000+ sanctioned crypto addresses sourced from OFAC SDN, Circle USDC blacklist, Tether blacklist, Ransomwhere, OpenSanctions, UK OFSI, and others.
You can try it now:
GET https://mru-oracle.com/trust/attest/{address}
Returns a signed EdDSA JWT — verifiable offline via the JWKS at /trust/jwks. The attestation includes: screening result, lists checked, risk level, recommendation (PROCEED / REVIEW_REQUIRED / DO_NOT_TRANSACT), and a timestamp. No API key needed — trust infrastructure is free.
One thing we're paying attention to: ERC-4337 smart wallets. auth.from becomes a contract address, not an EOA. We're working on deployer tracing so the beneficial owner gets screened, not just the proxy.

2. Facilitator integration
Agreed — the facilitator is the right place, not the catalog.
The payer address is already available at verify() time. One call to /trust/attest/{auth.from} between verify and settle gives the facilitator a signed compliance artifact. If the result is DO_NOT_TRANSACT, reject before settlement. If PROCEED, settle and cache the attestation.
The design question I'd want your input on: how should this surface in the facilitator spec?
Our thinking is an optional complianceCheck hook — a function the facilitator calls between verify() and settle(). SENTINEL would be the first provider, but the interface stays provider-agnostic. If someone wants to use Chainalysis or their own screening, same hook. That way it's part of the protocol, not locked to us.
On failure modes: if screening is unreachable, our approach is cache hit → proceed, cache miss → block. TTL adapts to the address risk profile. We also have continuous monitoring (/compliance/monitor/subscribe) for retroactive designations — an address cleared today can be sanctioned tomorrow.
To be clear about scope: we do list-based screening (sanctions lists, blacklists, published regulatory data). We don't do on-chain graph analysis or transaction tracing — that's a different layer at a different price point. Every attestation says screening_scope: "list-based" so there's no ambiguity.

3. Regulatory positioning
The attestation is a compliance artifact, not a legal shield.
It documents that screening was performed: timestamp, provider, lists checked, result, cryptographically signed. If a regulator asks "did you screen before settling?", the facilitator produces the JWT. That's the evidence.
The enforcement pattern supports this. Recent OFAC actions — Bittrex ($53M), Exodus ($3.1M, Dec 2025), ShapeShift ($750K, Sep 2025) — all targeted the absence of screening controls, not occasional false negatives. A facilitator with documented, systematic screening has a fundamentally different posture than one without.
What the attestation does NOT provide: legal opinion, KYC/CIP (that's the facilitator's obligation), SAR filing (requires human judgment), or guaranteed protection. It's one layer. The right one for protocol-level integration, but one layer.

What would be most useful to you?
I could see this going a few directions — catalog badge, facilitator hook spec, or just a reference implementation showing the screening call in a facilitator flow. Curious which would move things forward on your end.