Skip to main content
resolve() answers “what does this name pay to right now?” — it follows the namespace owner’s current resolver pointer, whatever that is. For a reclaimable namespace, the owner can repoint that resolver at will. That is holder sovereignty, not a bug — but before a high-value payment, you may want to know whether the mapping can move at all. assurance(name) is that check: an opt-in trust verdict on the name’s namespace resolver.

​
What it reads on chain

One call fires four reads against the immutable Registry, in parallel, for the name’s namespace node: trustworthy is the conjunction: locked, attested, and never upgraded. When it’s true, the name→address mapping is served by a resolver whose code has never changed, whose identity the Registry vouches for, and whose pointer can never be swapped — the resolution is immutable and cannot be changed underneath the payer between your check and the payment. These three legs are the on-chain proof behind a permanent ownership guarantee at the resolution layer. The other guarantee dimensions are enforced elsewhere: a reclaimable name can be taken back by its issuer, and a timed name stops resolving at expiry — both through the generation gates that resolve() itself already honors on every read. assurance() adds the piece resolve() can’t tell you: whether the resolver serving those answers is itself pinned.

​
How a wallet should render it

  • Gate, don’t decorate, high-value sends. For amounts above your threshold, check trustworthy alongside the confirm-time verify(). If it’s false, show the send anyway — most names on reclaimable namespaces are perfectly legitimate — but drop any “verified/immutable” badge and consider a one-line notice that the namespace owner can change where this name points.
  • Badge on trustworthy, not on the individual legs. The three booleans exist so power users and explorers can see why a verdict is what it is; a payment UI needs only the conjunction.
  • Don’t cache the verdict across sessions. It’s four cheap parallel reads; fetch it when you’re about to rely on it.
assurance() is opt-in — resolve() never runs it for you. Resolution deliberately follows the owner’s pointer regardless of assurance, because repointing is a legitimate right on non-permanent namespaces. It’s your UI’s job to decide when immutability matters enough to check.

​
Error semantics

Like every read, a failed chain read throws SoranError — it never comes back as a falsely reassuring or falsely alarming verdict. A malformed name also throws before any network call.

​
Next

Ownership guarantees

Permanent, reclaimable, timed — the full model.

SDK reference

Every method, typed.