RESOLVER

Step 2 of reachability — what a destination accepts. Public, answered by the holder, and the only complete path that needs no network.

Answers what does this destination accept. Served by the member holding the account, peer to peer.

No credential required. This is deliberate and load-bearing: it is the complete path from key to capability that requires membership of nothing, and every claim about the protocol's openness rests on it.

`GET /resolver/{key}`

GET /api/path/v1/resolver/path:4a91c2f7e8d3
Path-Version: 2026-09-09.genesis

{key} is an opaque PATH address. Call it at the holder's base URL — from a SONAR answer, or one you already knew.

Response

{
  "kind": "resolver_answer",
  "address": "path:4a91c2f7e8d3",
  "requester": null,
  "valid": true,
  "accepts": [
    { "asset": "USDC", "chain": "base" },
    { "rail": "mobile_money", "currency": "XOF" }
  ],
  "limits": { "max_single": "500000", "currency": "XOF" },
  "commitment": "8f29c41a…",
  "protocol_version": "0.1.0",
  "signed_at": "2026-09-09T10:00:00Z",
  "kid": "op_member_b_2026_01",
  "signature": "…"
}

What it never returns

Returned	Never returned
What can be sent	The holder's name
Applicable limits	Their institution's customer record
A commitment	Their KYC tier or documents
A signature	Their balance or history
	Any other identifier of theirs

A routing question gets a routing answer. Anything more turns a lookup into a disclosure — and the whole privacy model rests on that not happening.

The commitment

A digest over the answer's substance, published separately from the answer.

A payer compares the two before sending and refuses on divergence. A compromised resolver can lie once; it cannot lie consistently against a commitment it does not control.

path.address.commitment_mismatch → do not send

Treat a mismatch as a potentially compromised resolver, not as a transient error to retry.

Errors

Code	Status	Meaning
`path.address.revoked`	410	The address was revoked
`path.core.not_found`	404	No such address

revoked and not_found are distinct here, unlike SONAR's negatives. The payer needs the difference: one means ask for a current address, the other means you have the wrong destination entirely. There is no oracle risk, because reaching this endpoint already means knowing where to ask.

Verify before acting

import { verifyAgainstIssuer } from '@pathprotocol/sdk';

const answer = await path.resolver('path:4a91c2f7e8d3', 'https://api.member-b.com');
const { valid } = await verifyAgainstIssuer(answer, 'https://api.member-b.com');
if (!valid) throw new Error('Refusing to send against an unverified answer');

Worth doing even over TLS. TLS proves you reached the right server; it says nothing about the statement it handed you, and it leaves nothing behind for the argument six months later.

Standing intent beats capability

What comes back reflects the holder's standing intent where one is set, not merely what its infrastructure supports. A member may hold a USDC wallet and still decline USDC this month — the receiver's policy wins, and the answer reflects the policy.