> 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/07-leaders.md). # Leaders {% hint style="info" %} **Audience:** Developers and integrators who need the public execution model. **Goal:** Understand the public Leader role and the protocol contracts a Leader must satisfy while advancing work. {% endhint %} A **Leader** is an eligible protocol actor that advances an occurrence or execution under on-chain authority. Protocol state assigns eligible Leaders and constrains each submission by the pinned workflow, Tool, verifier, authorization, and payment state.
Scheduler advertises work for a DAGExecution

Phase 1: Scheduler advertises work for a DAGExecution.

Leader invokes Tool and records verifier evidence

Phase 2: Leader invokes Tool and records verifier evidence.

Accepted result settles the execution payment

Phase 3: Accepted result settles the execution payment.

### Public responsibilities * Observe eligible work and select an occurrence that protocol state assigns to the Leader. * Dispatch or advance the occurrence or execution using the workflow contract and its pinned inputs. * Invoke the selected on-chain or off-chain Tool with the required request and authorization context. * Submit the Tool result, failure evidence, and configured verifier evidence back to execution. * Participate in payment settlement and retain the evidence needed to associate payable work with the execution. The Leader does not redefine the DAG, replace the selected Tool, choose a different verifier, or bypass the payment state. Those choices are committed by the Agent skill, Task, Tool registry record, and execution state. #### Contract interactions * **Scheduler:** exposes eligible Task occurrences and applies timing, funding, and schedule constraints before work can advance. * **Workflow contracts:** own the DAG, walks, worksheets, result objects, and execution transitions that a Leader calls. * **Tool and verifier configuration:** identifies the Tool FQN, schema, timeout, authorization mode, and trust choice the Leader must use. * **Registries:** resolve the Agent, Tool, verifier, Leader, and network-key identities that the execution names. * **NetworkAuth:** supplies the active key binding used when Leader or Tool signatures are required; detailed key rules live in [Registered Keys and Signed Tool Communication](/talus-docs-v2.1.0/concepts/10-registered-keys-and-signed-tool-communication.md). * **Payment state:** records the Task reserve, ExecutionPayment, result affordability, and settlement outcome; see [Payment Vaults, Reserves, and Settlement](/talus-docs-v2.1.0/concepts/06-payment-vaults-reserves-and-settlement.md). #### Evidence boundary An accepted Tool response is not enough by itself. The Leader’s submission must match the execution’s current walk, selected Tool, verifier mode, and payment state. For on-chain result creation and pending settlement, follow [On-Chain Result Resolution](/talus-docs-v2.1.0/concepts/11-onchain-result-resolution.md). For exact public fields and functions, use the generated [Leader reference](/talus-docs-v2.1.0/reference/move/nexus_registry/leader.md). **Next** Continue to [Registries and Discovery](/talus-docs-v2.1.0/concepts/08-registries-and-discovery.md) to see how each identity is resolved on chain. --- # 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/07-leaders.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.