> For the complete documentation index, see [llms.txt](https://docs.talus.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.talus.network/talus-docs-v2.1.0/concepts/08-registries-and-discovery.md).
# Registries and Discovery
{% hint style="info" %}
**Audience:** Developers and integrators who resolve Nexus identities.
**Goal:** Understand registries as the on-chain discovery solution for Agents, Tools, Verifiers, Leaders, and network keys.
{% endhint %}
After the Agent, Tool, Verifier, execution, payment, and Leader are known, the remaining problem is discovery: how does a caller resolve the exact identity and configuration on chain? Nexus uses shared registries as indexes and configuration surfaces; they do not replace custody of the objects or capabilities they describe.
### Agent discovery
The Agent registry exposes an Agent record, its active status, skill records, DAG binding, committed requirements, and active interface revision. The Agent object remains the custody handle for mutable identity and Agent-funded payment state. An embedded Agent can be associated with an application shared object while its skill record remains discoverable through the registry.
#### Tool and verifier discovery
The Tool registry resolves an FQN to the stable Tool object ID and exposes the immutable registration schema plus the configured timeout, price, witness, authorization, and verifier settings. NetworkAuth binds the Tool ID for key verification; Leader bindings use the Leader capability ID. External verifier registration is attached to the Tool, so a caller can resolve the method, witness, and shared-object requirements for the selected trust mode. Execution price and walk-timeout snapshots, rather than a later directory read, are the durable values for work already admitted.
The registry is a lookup and configuration boundary. Read the separately custodied Tool owner capabilities before attempting a Tool mutation, and verify the DAG vertex, registry identity, schema, and application policy when a skill declares a fixed Tool.
#### Leader discovery
The Leader registry exposes the public Leader records and the protocol state used to determine eligible work. An execution names the relevant network and responsibility assignment; later submissions are checked against that assignment rather than against an unpinned off-chain list.
This page explains how a caller finds a Leader, not how a service operates. The public execution role and contract interactions are in [Leaders](/talus-docs-v2.1.0/concepts/07-leaders.md).
#### Network-key discovery
NetworkAuth binds an off-chain identity to its public keys. A Tool or Leader identity resolves to a key binding with active key ID, registered keys, and revocation state. Signed communication uses that binding to decide which signature is accepted; key rotation and canonical request rules belong to [Registered Keys and Signed Tool Communication](/talus-docs-v2.1.0/concepts/10-registered-keys-and-signed-tool-communication.md).
#### Discovery sequence
1. Resolve the Agent and skill record.
2. Resolve each DAG or fixed Tool by FQN and compare the stored registry identity.
3. Resolve the verifier mode and its external configuration when required.
4. Resolve the network and eligible Leader assignment.
5. Resolve the active NetworkAuth key before checking a signed message.
6. Retain the resolved IDs and configuration in the execution evidence.
Registries solve identity discovery; they do not authorize an application’s business-state mutation, replace a Tool owner capability, or make a private hosted service public.
**Next**
Continue to [Authorization and Fixed Tools](/talus-docs-v2.1.0/concepts/09-authorization-and-fixed-tools.md) to see how a resolved identity is constrained to the intended workflow vertex.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.talus.network/talus-docs-v2.1.0/concepts/08-registries-and-discovery.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
