addrbookFor publishers
← The evidence ledger

Evidence row 258701

Observed , by probe.mcp/1.

Kind
mcp.tools
About
endpoint 9b389dae-f9e1-4697-af43-ebc78a6d5407
Recorded
Previous row
None: the first of its kind about this subject
Body SHA-256
2e6458258e45fcb5f5d57519f1c3166b7a2854c4d7f309a7a7aedd4bba8b08b4
Leaf
0x11170e694c5c77c345b4166864e5766ced41982ae8aef33bc954ad981ae67ea9

What was observed

{
  "count": 4,
  "tools": [
    {
      "description": "Check a recipient wallet BEFORE your agent pays it — a pre-payment guard. Pass the pay-to address a service asked you to pay; returns whether Verantis knows the wallet, its EARNED reputation tier, and human-readable reasons. A wallet IS a settlement rail, so the reply names the rail it settles on ('rail': chain + protocols), its host, on-chain buyer retention (distinct buyers, repeat rate, distribution), and the host's OTHER rails ('also_settles_on'). If 'shared_wallet' is true the address fronts many services (a relay/treasury) so the reputation reflects the pool, not one service — treat with care. An unknown or low-reputation recipient is a reason to pause.",
      "inputSchema": {
        "properties": {
          "pay_to": {
            "description": "recipient wallet address (0x… for Base/EVM, base58 for Solana)",
            "type": "string"
          }
        },
        "required": [
          "pay_to"
        ],
        "type": "object"
      },
      "name": "check_wallet"
    },
    {
      "description": "Index-level statistics: services, verification breakdown, data freshness.",
      "inputSchema": {
        "properties": {},
        "type": "object"
      },
      "name": "directory_stats"
    },
    {
      "description": "Search Verantis's verified directory of machine-payable services (x402, MPP). Results are UNIFIED per service (host): each carries its settlement rails ('rails': base / solana / tempo), and every rail has its OWN reputation, price, and buyer retention — never blended. Pass 'chain' and 'matched_rail' marks that chain's rail so you see the reputation for the rail you'll actually pay on. 'coming_soon' lists advertised chains not yet measured. Each rail's 'wallet_scope' says if its pay-to wallet is 'dedicated' (the buyers/payments/volume are this service's own) or 'shared' (a relay/treasury fronting 'wallet_services' services, so those figures are the pool's inbound, not this service alone). Prefer verified=true before paying anyone.",
      "inputSchema": {
        "properties": {
          "chain": {
            "description": "settlement network, e.g. base, solana, polygon, tempo",
            "type": "string"
          },
          "exclude_concentrated": {
            "default": false,
            "description": "exclude services from operators with many listings under one registrable owner (a neutral concentration signal, not a fraud claim)",
            "type": "boolean"
          },
          "limit": {
            "default": 10,
            "description": "maximum number of results to return (default 10)",
            "type": "integer"
          },
          "max_latency_ms": {
            "description": "reject services slower than this (ms)",
            "type": "integer"
          },
          "max_price_usd": {
            "description": "max price per call in USD",
            "type": "number"
          },
          "min_score": {
            "description": "minimum trust score 0-100 — set high (e.g. 85) for money-moving tasks",
            "type": "integer"
          },
          "protocol": {
            "description": "restrict to one payment protocol: x402 or mpp",
            "enum": [
              "x402",
              "mpp"
            ],
            "type": "string"
          },
          "proven_only": {
            "default": false,
            "description": "only services that have EARNED reputation over time (excludes 'new' services and 'watch' services whose on-chain payments are concentrated / not yet broadly distributed). Reputation is earned via consistent history + on-chain buyer retention; a brand-new well-behaved service is verified but new, not top-trust.",
            "type": "boolean"
          },
          "query": {
            "description": "what you need, e.g. 'twitter data', 'web search', 'rpc ethereum'",
            "type": "string"
          },
          "require_fresh": {
            "default": false,
            "description": "live re-probe stale results before returning — use before paying real money; adds ~1s per stale service",
            "type": "boolean"
          },
          "verified_only": {
            "default": true,
            "description": "only services that passed the latest live probe",
            "type": "boolean"
          }
        },
        "required": [
          "query"
        ],
        "type": "object"
      },
      "name": "find_paid_service"
    },
    {
      "description": "Full unified record for one service host: every settlement rail it accepts on, each with its own reputation, price, buyers, volume and history, plus coming-soon chains. Each rail's 'wallet_scope' marks a 'shared' pay-to wallet (buyers/volume are pooled inbound across 'wallet_services' services, not this one alone) vs 'dedicated' (this service's own). Pass the host (domain).",
      "inputSchema": {
        "properties": {
          "domain": {
            "description": "the service host / domain to look up, e.g. api.nansen.ai",
            "type": "string"
          }
        },
        "required": [
          "domain"
        ],
        "type": "object"
      },
      "name": "get_service"
    }
  ]
}

What the leaf hashes

{"body":"2e6458258e45fcb5f5d57519f1c3166b7a2854c4d7f309a7a7aedd4bba8b08b4","id":258701,"kind":"mcp.tools","method":"probe.mcp/1","observed_us":1793030339252597,"prev":null,"subject":"9b389dae-f9e1-4697-af43-ebc78a6d5407","subject_kind":"endpoint"}

Proof

Fold these into the leaf in order, hashing each sorted pair with keccak256, to reach the root of (296695 rows).

  1. 0x1116d0bfdc258e600bf5cb8db8d69c5fc8278a7406f52388293c04966dd4f5df
  2. 0x7401ede99e45d5b38f449b3811363f948b8a1c20342355e9a0e669f9375fc984
  3. 0xe732a76bdf5bd8607d39395bbfefbbe3f9ca9052f2ed75607a3002ad9ca0df0f
  4. 0x809548c5919683f8451ddc9a98dc2ffc27199ac30baf6844a34a7c52a9dda5ed
  5. 0x48c980d2f1e5b4098ea7ddf8c7e0b5b8ab11dc8e8060eaa44cdd06878dec7c22
  6. 0x9f1ee524cdc398e7d8adac4d2729ce2d225159cec549998c69b6cbb6788fa03b
  7. 0x4c859df6898e8d6f3fa82a0dc2c60c07a89d87fe94650ec47c92a72870eda1b8
  8. 0xe2308168fafc03db75ac738ccbe262189b944e6b3f5679b3dd0746bbc7f6738e
  9. 0x6636667d35b8a5cad1e61d09b134d4162fabb1d272343782d568d56acb39a500
  10. 0x59eeaadc4738eed3343bd128dc8e9beeacada4d8b43799e35d914cb411b97394
  11. 0xb3d22f508aaf8117a0a5454390284c48363baa096e225b30af56d708d8dcd0b3
  12. 0xc02d9eff6ef94d46d90d54320548f18fc3f05787047265548577569253c19969
  13. 0x294f7935f78a896b5f246a7c9a7ee1b023720acdb03fff3cd549c63479848ec9
  14. 0xb49e8c2564256e5322e375cb619d9ac70fd17c1d1eba9c991bba4cb6428f45cc
  15. 0x60582ab4b41e72eb70eb0bce07fbf0fb4d2b62a8bad5be50f5d16d511adc746c
  16. 0xc6a4d7899a0f442958e26505011190b7cff2483611c1b94eba9043e0ba9ac36e
  17. 0x8c756542e482157df0c36464d75c937b845e4423dbbcfad08f0cf8d5a16b9a13
  18. 0x20704208aa6923d6b2450ef74ede87a6e0265d46447926038fe9506e9e154b2d
  19. 0x9b9ce5b74b9bab5121612ef6b64920a8d453cbf311096a423eef9702747e868a
Day root
0xf43e8dcc3d451a4788b26be904c55e8c4c0fa75c9666796c51db38d37e2c0df8
Chained
0x702d5ac508f08b0d1accf36af25822d8e5660367494edd17a642fb61e158a57a
Published
On Arc Testnet, block 69251483: 0x495162f8936e19f0039918feebe6c307f327cd6bf8c37219620b1970041fa9ae

How to check it · This row as JSON