H-Scope: wallet behavior scanning

H-Scope is the wallet-behavior layer of the H-Series. Give it any on-chain address and it returns deterministic behavioral signals, an entity-posture tier, an activity band, the recent transactions behind the read, and AI-written reasoning over the result. It answers one question: how does this wallet behave, and what kind of actor runs it. The output is descriptive context, an advisory signal, not a risk or compliance verdict.

What it does

• Deterministic signals. Each signal is a pure predicate over a normalized, chain-agnostic feature set, grouped by category (flow, cadence, counterparty, identity, structure, lifecycle, and chain-native markers). Signals are descriptive behavior, never a verdict.
• Two reproducible axes. The signals reduce to an entity-posture tier (none / minimal / moderate / institutional / core-institutional) and an activity band (Dormant / Low / Medium / High), each a fixed function of the fired signals, so a scan is reproducible from the same on-chain data.
• Advisory narrative. Each scan carries a narrative overlay: a deterministic gloss (always present) plus an optional AI-written llmSummary (added only when the backend has the LLM tier enabled). It reads the result back in plain language and never invents or overrides a score.
• Multi-chain. One engine across XRPL, Stellar, Hedera, Base, and Solana. A thin per-chain adapter reads the address; the engine is the same everywhere.
• On-chain calibration. The posture tiers are calibrated against a labeled corpus of on-chain-verified wallets, anchored to a dedicated Hedera Consensus Service topic (0.0.10631992) as immutable, operator-signed, versioned snapshots, so the calibration is tamper-evident and reconstructible from a public mirror replay.

Using it from the showroom

The showroom is at h-series.xr-utilities.com/scope. The landing page is itself the scan tool.

1. Paste an address. Enter any on-chain address into the scan form on the front page.
2. Pick the chain. Select the chain the address lives on (XRPL, Stellar, Hedera, Base, or Solana).
3. Scan. Run the scan. It is free here and abuse-gated, with the full report.
4. Read the result. You get the wallet class, the entity-posture tier, the activity band, the fired signals with descriptions, the recent transactions behind them (amount and asset per line), and the advisory narrative.

There is no sign-in required for a showroom scan. The $0.10 fee applies only to the programmatic agent API.

Using it from an agent (the backend)

The backend is at h-scope.xr-utilities.ai. An agent scans an address with a single paid call. The address to scan is the subject field, a CAIP-10 identifier (for example eip155:8453:0x... on Base, hedera:mainnet:0.0.x on Hedera). There is no separate chain field; the chain is read from the CAIP-10 prefix.

1. Call POST /scan with { subject }. Without payment the server responds 402 Payment Required and a payment-options envelope (the accepts array, one entry per configured stablecoin rail).
2. Pay over x402. Construct a signed payment for one of the advertised rails and resubmit with an X-Payment header carrying the base64 x402 envelope. The facilitator is never trusted; settlement is re-verified on chain and replay-guarded. The scan runs only after the payment verifies, and if the scan fails the payer is not charged (deferred rails do not capture; already-moved rails refund).
3. Read the result.

POST https://h-scope.xr-utilities.ai/scan
  X-Payment: <x402 envelope (base64)>
  Content-Type: application/json
  {
    "subject": "eip155:8453:0x<address>",
    "mode":    "full"          // optional: pre_auth | standing | full (default full)
  }
  -> 200 {
       "subject":        "eip155:8453:0x...",
       "activityScore":  0,
       "activityLevel":  "Low | Medium | High | Dormant | Unknown",
       "entityPosture":  { "score": 0, "tier": "none | minimal | moderate | institutional | core-institutional", "contributors": [ ... ] },
       "classification": { "primary": "exchange", "roles": [ "..." ], "label": "..." },
       "label":          "...",
       "confidence":     "low | med | high",
       "signals":        [ { "id": "NET_OUTBOUND_SWEEP", "category": "flow", "description": "..." } ],
       "advisoryFlags":  [ ... ],
       "recentActivity": [ { "hash": "...", "direction": "out", "assetAmount": "...", "assetSymbol": "..." } ],
       "headline":       "...",
       "schemaVersion":  "0.0.8",
       "narrative":      { "deterministicGloss": "...", "llmSummary": "...", "provenance": { ... } }  // llmSummary present only when the LLM tier is enabled
     }

The narrative block is a read-only advisory overlay: the deterministicGloss is always present, and the AI-written llmSummary is added only when the backend has the narrative LLM tier enabled (NARRATIVE_LLM_ENABLED=true plus a DeepSeek key). It never alters the scored result. If an upstream chain read is transiently unavailable the scan returns 503 (upstream chain data temporarily unavailable), not a fabricated “not found”; an authoritative not-found returns a normal 200 with exists:false.

GET /config returns the live contract: the scan price, the supported chains, the accepted x402 payment options per chain, the full signal catalog, and the set of classifications. Treat it as the source of truth. Agents that prefer a tool interface can reach the same scan through the H-Series MCP passthrough at https://mcp.xr-utilities.ai/mcp via the h_scope_scan tool (paid) and h_scope_config (free), with the same x402 flow; the tool takes subject, an optional mode, an optional relationshipTo, and a payment_signature.

Relationship scans

POST /scan takes an optional relationshipTo address, which scans the subject in relation to a reference wallet and returns deterministic tie data. Useful for “is this counterparty connected to a known-bad wallet” checks before you transact.

POST https://h-scope.xr-utilities.ai/scan
  {
    "subject":        "<caip10 of the wallet to scan>",
    "relationshipTo": "<caip10 of the reference wallet>"
  }
  -> 200 { ..., "relationship": {
       "reference":           "<caip10>",
       "sameChain":           true,
       "directInteraction":   { ... },   // did the two transact directly
       "sharedCounterparties":[ ... ],    // counterparties both touched
       "comparativePosture":  { "subjectScore": 0, "referenceScore": 0, "delta": 0, "subjectRelative": "..." }
     } }

Same-chain pairs get the on-chain directInteraction and sharedCounterparties (bounded to the recent-activity window); cross-chain pairs get comparativePosture only. Descriptive and advisory, never a verdict.

Scan modes

POST /scan accepts an optional mode of pre_auth, standing, or full, which affects which signals fire. pre_auth is a lightweight pre-authorization read; standing and full are heavier behavioral reads for standing consumers. The live mode list is served from GET /config.

Wallet classes

A scan leads with a wallet class, not a number. The response classification is { primary, roles[], label }, drawn deterministically from a fixed taxonomy (served at GET /config under classifications):

exchange, issuer, contract (deployed code / infrastructure), institution, whale, automated, dust-beacon, fresh, dormant, personal, undetermined.

primary is the single best-fit class; roles[] are the secondary behaviors that also matched, in priority order. Each scan also carries a confidence of low, med, or high, reflecting how much in-window evidence backs the read. The taxonomy is chain-agnostic (an exchange on Solana and on XRPL classify identically) and carries no risk, compliance, or sanctions terms by design.

The abuse-flag signal

When a scan verdict shows an abuse shape (a scam label, or a drain / dust-beacon / clawback advisory flag), H-Scope emits a scope.abuse_flag signal onto the shared SIEM audit topic, keyed to the scanned address (not the requestor). The emitted category is one of a fixed set (scam, drain, dust-beacon, clawback), and it carries public-safe scalars only (the flag category, the coarse chain, the posture tier), never raw signals, counterparties, or amounts. The signal feeds the subject’s H-Cert behavioral standing. It is descriptive, advisory, and fire-and-forget: it never blocks or alters the scored verdict.

Attributed and metered scans (requestor identity)

By default a paid POST /scan is anonymous and rate-limited by IP. A caller can instead identify itself so the scan is attributed to a stable requestor and metered per identity. The requestor is who asked, always distinct from the scanned subject (a third-party address). Two ways to present an identity, each gated on its own flag on the backend:

• An OIDC bearer token in the Authorization: Bearer <token> header, accepted when the backend has IDENTITY_BRIDGE_ENABLED and its issuer/audience policy configured. The verified identity resolves to oidc:<issuer>:<sub>.
• A connected-wallet session in the X-Wallet-Authorization header (base64url of { message, signature } JSON), accepted when the backend has WALLET_ATTRIBUTION_ENABLED and a non-empty allowed-domain list. The verified identity resolves to the wallet’s CAIP-10.

When a valid identity is present the scan response echoes it back as a top-level requestor field, and that identity (not your IP) becomes the rate-limit key. A present-but-invalid token or credential is a hard 401 (invalid_identity with a reason), never a silent downgrade to anonymous. Absent headers leave the scan anonymous and IP-limited, unchanged. Attribution is optional and off unless the operator has enabled the matching path.

POST https://h-scope.xr-utilities.ai/scan
  Authorization: Bearer <oidc-token>          // OIDC path
  X-Wallet-Authorization: <base64url({message,signature})>  // wallet path (alternative)
  X-Payment: <x402 envelope (base64)>
  { "subject": "eip155:8453:0x<address>" }
  -> 200 { ..., "requestor": "oidc:https://issuer.example/:user-123" }

When the backend also has the HCS attribution trail configured, the same identified scan anchors a tamper-evident, hashes-only record to a dedicated Hedera Consensus Service topic off the response path. That record carries no raw requestor and no raw subject (both are HMAC’d) and binds the exact scored-read hash. It is fire-and-forget and never blocks or alters the scan.

Sibling and provider integration (backend-to-backend)

Two paths exist for another service integrating H-Scope directly rather than paying per scan. Both are backend-to-backend; a normal customer or agent uses the paid POST /scan above.

Free authenticated sibling channel

A registered sibling service pulls a scan free by signing each request with its ed25519 key instead of paying. Send three headers on POST /scan:

• X-Sister-Id: the registered sibling id (h-scope-showroom, h-grant, or h-cert).
• X-Sister-Ts: unix seconds when the request was signed.
• X-Sister-Sig: base64 ed25519 signature over the canonical message ${ts}\n${method}\n${path}\n${bodyHashHex}, where bodyHashHex is the lowercase hex sha256 of the raw request body bytes and method/path are POST and /scan.

The backend verifies the signature against the sibling’s registered public key (SHOWROOM_SISTER_PUBKEY, H_GRANT_SISTER_PUBKEY, or H_CERT_SISTER_PUBKEY, each an SPKI DER base64 ed25519 key; an unset key leaves that sibling off, fail-closed). The timestamp must fall inside a 120-second freshness window (with a 5-second future skew tolerance). A valid signature serves the scan free; a present-but-invalid signature is rejected 401; absent headers fall through to the paid x402 path. Each signature is single-use: it is consumed in a durable cross-replica slot (the sha256 of the signature, never the raw bytes) the first time it is presented, so a captured request cannot be replayed within the window; a re-presented signature is rejected 401.

POST https://h-scope.xr-utilities.ai/scan
  X-Sister-Id:  h-grant
  X-Sister-Ts:  <unix seconds>
  X-Sister-Sig: <base64 ed25519 over `${ts}\n POST \n /scan \n sha256hex(body)`>
  { "subject": "<caip10>" }
  -> 200 { ... }   // free, no payment

Two-party H-Seal provider co-signature

When a sibling anchors an H-Seal execution receipt for a scan result (H-Grant, on the sister-key path above), H-Scope co-signs it so the anchored receipt names H-Scope as the provider that computed the scan, not a caller self-attestation. When the backend has HSCOPE_ID and HSCOPE_KEY set, the /scan response carries an _hSeal block:

  -> 200 { ..., "_hSeal": {
       "providerIdentity":        "hedera:mainnet:<HSCOPE_ID>",
       "providerSignature":       "...",
       "providerSignatureScheme": "...",
       "providerIssuedAt":        0,
       "requestHash":             "...",   // over { subject, mode, relationshipTo? }
       "responseHash":            "..."    // over the response body BEFORE _hSeal is added
     } }

The block is an EIP-712 provider_attest over { providerIdentity, requestHash, responseHash, providerIssuedAt }, signed with H-Scope’s own Hedera account key (secp256k1, distinct from the shared operator) using the shared @xr-utilities/h-seal-provider SDK. The sibling lifts the block onto the receipt; H-Seal verifies it by recovering the secp256k1 address and matching the account’s on-chain key (the mirror is never trusted), so the receipt is genuinely two-party (caller = the sibling, provider = H-Scope). requestHash commits to the scanned subject and mode; responseHash is over the body before _hSeal is attached, so it is not self-referential. The block is advisory and fail-open: unset vars leave the response unchanged and the receipt self-attested, and a signing error never blocks or alters the scored scan (_hSeal is never part of the scored verdict).

Where to go next

• Run a free scan from the showroom at h-series.xr-utilities.com/scope.
• For the exact endpoints, payment envelope, and signal catalog, see the H-Scope reference.
• The posture signal feeds discovery, delegation, and gating across the suite. See how it composes in Start here, and read how it feeds a subject’s standing in H-Cert.