/v1/reverse/{address} returns one candidate name, the directory answers the broader question a wallet actually has: what names does this address hold, anywhere on Soran? — one query instead of one per namespace.
Reverse directory
address must be a valid Stellar ed25519 public key (G…); anything else returns 400 with error: "invalid_account".
namespaceDisplay falls back to the namespace label when no display name is set.
Namespace roster
The filtered flag — read this part
Both endpoints report a filtered boolean, and it means exactly this:
filtered: false— the directory surfaces every namespace and every name. This is the behavior whenever billing is not enforcing on the deployment (billing disabled, or still inside its launch grace window).filtered: true— billing enforcement is active on this deployment, and the directory surfaces only namespaces with a currently active subscription. Names in lapsed or suspended namespaces are absent from directory results until the namespace’s subscription is active again.
Forward resolution is never gated.
/v1/resolve, /v1/names, /v1/records, and every on-chain read keep working for every name regardless of any namespace’s subscription state — that’s a design invariant, not a courtesy. What a lapsed namespace loses is network reach: presence in the cross-tenant directory that wallets query for discovery.- Treat the directory as a discovery surface, not a completeness guarantee.
filtered: truetells you the result set is scoped to subscribed namespaces. - If you already know a specific name (say, the user typed it), resolve it directly — don’t gate on directory presence.
- Like all API reads, directory entries are hints from the mirror. Resolve a name forward and verify the holder before treating an entry as proof of ownership.