> 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/concepts/10-registered-keys-and-signed-tool-communication.md). # Registered Keys and Signed Tool Communication {% hint style="info" %} **Audience:** Tool developers, Leaders, and integrators using signed off-chain communication. **Goal:** Bind identities to active keys and verify Signed HTTP v3 requests without duplicating the generic verifier model. {% endhint %} `NetworkAuth` is the on-chain key-binding surface for Tool and Leader identities. It records which public keys an identity registered, which key ID is active, and which keys are revoked. The binding lets a verifier resolve a signature to an identity without trusting an out-of-band key list.

Phase 1: Register Leader and Tool keys before dispatch.

Phase 2: Leader and Tool exchange signed HTTPS evidence.

Leader submits Tool evidence in a Workflow transaction — Phase 3: Leader submits Tool evidence in the Workflow transaction. Keyed facts: Tool response = signed response submission; Leader evidence = signed response + Leader key; Workflow tx resolves Tool ID + capability key; NetworkAuth exposes active/revoked key state; the final check verifies signature + Tool allowlist.

### Key bindings and lifecycle A FQN is the client-facing lookup handle: resolve it through ToolRegistry to the stable Tool object ID, then resolve the NetworkAuth binding for that Tool ID. A Leader binding is keyed by the Leader capability ID. Registering a key requires proof of possession for that identity and registration slot. Rotation registers a new key ID and changes the active binding; revocation makes a key unacceptable even if its signature verifies cryptographically. Do not assume a cached canonical request can be replayed with the same nonce across rotation: request a new nonce, obtain a new signed request, and confirm effects with authoritative readback. Retain the identity, stable object or capability ID, key ID, rotation event, and revocation state with the request evidence. #### Identity and allowlist ownership NetworkAuth answers **which public key is active for this Tool or Leader identity**. It is the on-chain source used to register and rotate keys and to export or refresh the Toolkit's local `AllowedLeadersFileV1`. It does not decide whether an endpoint should accept every valid Leader. The Toolkit or Tool configuration owns that local policy: `allowed_leaders` embeds an allowlist, while `allowed_leaders_path` points to a file-backed `AllowedLeadersFileV1`; the Toolkit endpoint authenticates against that local allowlist without making RPC calls. Each accepted entry should match the intended Leader capability or identity and active key ID, and the file must be refreshed after key rotation. The workflow performs the on-chain check: it resolves the current NetworkAuth binding and applies the configured Tool/Leader identity checks when accepting the signed evidence. The Toolkit endpoint performs the local check against its exported allowlist; a valid NetworkAuth signature from a Leader absent from `allowed_leaders` or its configured path remains unauthorized for that Tool. See the [RegisteredKey verification guide](/guides/tool-development/verify-offchain-tool-result.md) and the exact [Toolkit allowlist reference](/reference/toolkit/rust.md) for configuration fields. #### Signed HTTP v3 Signed HTTP v3 has two signed messages. The Leader signs only the schema-ordered canonical input hash. The Tool signature binds the response domain, the Leader signature, the deterministic invocation nonce, and the canonical response hash. HTTP method, path, query, raw body bytes, arbitrary headers, status, and wall-clock claims are transport fields rather than signed-message fields; HTTPS protects them in transit. The receiver resolves the active NetworkAuth key, checks the Leader input signature and Tool response signature, then rejects replay, unknown identity, inactive key, revoked key, or a mismatched signed commitment. Use short participant names and keep the exact schema-order, response-domain, nonce, and canonical-response rules in the [Tool communication guide](/guides/tool-development/tool-communication.md). HTTPS protects method, path, query, raw body, headers, and status; it does not prove which registered Tool or Leader signed the message. #### Leader and Tool signatures The same key-binding model serves two identities. A Leader signature proves the assigned Leader produced or submitted the execution evidence. A Tool signature proves the registered Tool endpoint produced the response. The verifier still checks which identity the selected vertex requires and whether the configured trust mode is `RegisteredKey`. #### Toolkit modes and failures Toolkit integrations can select the signed communication mode for an off-chain Tool. A request with a missing or malformed signature, impossible identity binding, replayed nonce, commitment mismatch, or different FQN that prevents a stamped verdict aborts without a verification result. An invalid active-key signature presented through a valid `RegisteredKey` verdict path can instead produce `VerifierDecision::Reject` failure evidence. Keep the no-result branch separate from durable rejection recovery. Key verification is one verifier choice, not the entire verifier model. Return to [Verifiers and Result Trust](/concepts/04-verifiers-and-result-trust.md) for `None`, `RegisteredKey`, and `External`, and continue to [On-Chain Result Resolution](/concepts/11-onchain-result-resolution.md) for settlement after a verdict. #### Verification checklist 1. Resolve the Tool FQN to its stable Tool object ID, or resolve the Leader capability ID, from the relevant registry. 2. Read the active key ID and revocation state from NetworkAuth. 3. Reconstruct the canonical commitment and verify the nonce boundary. 4. Verify the signature with the active public key. 5. Record the failure reason when any identity, key, nonce, or commitment check fails. **Next** Continue to [On-Chain Result Resolution](/concepts/11-onchain-result-resolution.md) after signed evidence has been checked. --- # 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/concepts/10-registered-keys-and-signed-tool-communication.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.