Skip to main content
Use assurance(name) to read Registry’s Resolver provenance and routing-lock flags. Combine these with the deployment’s upgrade policy when assessing the implementation behind a payment instruction.
Universal mode obtains these facts through Lookup’s namespace metadata. Direct compatibility mode reads their Registry equivalents.

​
Limits of the result

The field name trustworthy describes Resolver provenance. It is not a general payment-safety verdict. An approved governed upgrade updates the namespace’s recorded code hash and upgrade counter without setting the taint flag. Therefore, resolverTainted: false does not mean the Resolver has never been upgraded. Inspect Registry’s native_code(node) and the governance policy for that context. The governed testnet rejects new irreversible routing locks, so an unlocked namespace can return trustworthy: false while ordinary resolution works.
  • Payment records can change. Holders may still update their address, memo and text.
  • Destinations can belong to another party. A holder can point to an exchange account; assurance does not verify the person behind a memo.
  • Lookup and RPC remain trust boundaries. This result does not attest Lookup’s current code. Lookup governance can upgrade it without a mandatory delay, and reads depend on your RPC.
For the broader namespace permanence check, see ownership guarantees. For payments, preserve the complete address and memo and call verifyPayment near confirmation. A locked Resolver does not remove a required memo or bind a later payment to an earlier lookup.