How Anchors Connect: Resolver Accounts & Endpoints
By AnchorFactory ·
Every anchor on Keeta has two identities: one on-chain and one off-chain. Understanding the relationship between them is key to working with the asset movement protocol.
Resolver Account (on-chain identity)
A resolver account is a standard Keeta wallet address that represents the anchor on the network. It doesn’t hold funds or process transactions — it serves as a registry entry.
The anchor’s metadata is published to this address, including what the anchor does, which assets it supports, and where its API lives.
When an application calls getProvidersForTransfer() through the Anchor SDK, the SDK reads the network’s service metadata, finds matching resolver accounts, and returns the available providers. The resolver account is how the network knows the anchor exists.
Example: keeta_aabfqkxq6dinrdwermtn3n6uf7q2uudqzov3pn3pbrkjtebr45uspgiva2epm2a
Endpoint URL (off-chain API)
The endpoint is the actual HTTP server that handles anchor operations. This is where simulateTransfer, initiateTransfer, getTransferStatus, and other calls are sent. It’s a regular REST API hosted by whoever operates the anchor.
Example: https://changenow-staging.keeta.com/api
How they connect
Anchor operator publishes metadata to a resolver account on Keeta
Metadata includes: endpoint URL, supported assets, capabilities
Application calls SDK:
getProvidersForTransfer(from, to)SDK reads network metadata at
https://static.network.keeta.com/metadata/servicesFinds resolver accounts that match the requested transfer
SDK returns provider objects with the endpoint URL already resolved
Application calls
simulateTransfer(),initiateTransfer(), etc.These go to the endpoint URL behind the scenes
Key takeaway
The application never needs to hardcode endpoint URLs. It discovers anchors through the resolver, and the SDK handles the rest.
If an anchor operator changes their API server, they update the metadata on their resolver account — all applications pick up the new endpoint automatically.