> 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/faq/06-verification.md). # Verification {% hint style="info" %} **Audience:** Nexus adopters and integrators. **Goal:** Answer how off-chain results are accepted or rejected so you can choose and troubleshoot the correct per-vertex verifier mode. {% endhint %} This page answers "what evidence must this off-chain result carry?" Authorization decides who may act; verification decides whether the submitted evidence satisfies the vertex's configured policy. #### Verification modes **What are the verification modes, and how much trust does each give?** Each off-chain DAG vertex selects exactly one `ToolVerifierMode`: * **`None`** — workflow uses the ordinary submission path without verifier proof. Use it only when application risk permits trusting the submission. * **`RegisteredKey`** — the Leader signs the schema-ordered canonical input hash; the Tool signs the response-domain message containing that Leader signature, the execution-derived nonce, and the domain-separated SHA-256 of canonical response BCS. Workflow resolves the active Leader and Tool keys and recomputes the commitments and nonce on-chain. This proves authenticated canonical evidence, not semantic truth. * **`External`** — workflow atomically calls the Tool's configured on-chain verifier and consumes `Accept` or `Reject`. Confidence depends on the registered method, package governance, witness, immutable object list, and verifier logic. The ToolRegistry checks that a Tool advertises the selected support before the DAG stores the mode. On-chain vertices cannot set an off-chain verifier field. **Does the Leader verify a RegisteredKey Tool response locally?** No production local verdict is made. The leader requires a well-formed v3 Tool signature for a `RegisteredKey` vertex, parses it, and carries it with the canonical result into workflow. The on-chain RegisteredKey verifier resolves active keys and verifies both signatures against authoritative execution context. The SDK exposes a `verify_response` helper for tests and other callers, but that public helper is not evidence that the production leader uses it. **What does the verification verdict look like?** `VerificationVerdict` carries `VerifierDecision::Accept` or `VerifierDecision::Reject`. `ToolVerificationResolvedEvent` records the verifier kind, optional witness ID, and decision. Rejection prevents the result from advancing and follows the workflow rejection/failure path. `RegisteredKeyAuxiliary` contains only `input_hash`, `nonce`, `leader_signature`, and `tool_signature`. It does not contain HTTP method/path/query, raw request or response body, time-window claims, status, Tool key ID, or a full HTTP transcript. **Is there a hardware-enclave or trusted-execution mode?** No. The active spectrum is exactly `None`, `RegisteredKey`, and `External`. **Runtime configuration boundary** **Is signed HTTP optional or required?** That question has three separate answers: * The **DAG vertex** selects `None`, `RegisteredKey`, or `External`. * The **leader** either has a signing key or does not; there is no global optional/required leader mode. Without a key, `RegisteredKey` fails before invocation while `None` and `External` send unsigned requests that Toolkit `Required` rejects. * The **Toolkit** config is `Disabled` or `Required`; there is no optional mode. `Required` rejects unsigned/invalid requests and signs canonical results with the configured per-FQN Tool key. For a functioning RegisteredKey path, the selected build must expose an active public Leader key binding, the Tool must advertise matching support, the Toolkit must use `Required`, and the DAG must select `"verifier":"registered_key"`. Public docs do not publish Leader process key setup; retain the public binding and on-chain verification evidence instead. **Economic backing** **What stops a Tool from returning dishonest results?** Verification supplies evidence; Tool collateral supplies a separate economic/governance mechanism. Tool registration locks `Coin` collateral. A matching ToolRegistry administrative capability may apply bounded endorsement/slashing operations, but the contracts do not infer dishonesty from a signature failure or encode one universal adjudication trigger. Leader stake uses separate authority and state. **What happens to collateral after honest unregistration?** After the configured lock period, the Tool owner may claim the remaining US collateral: ``` nexus tool unregister --tool-fqn nexus tool claim-collateral --tool-fqn --owner-cap ``` SUI transaction gas, US Tool collateral, Leader stake, and workflow Tool charges are distinct balances. *** **Where do I go next?** * [Authorization](/faq/05-authorization.md) — understand active key registration and allowlists. * [Verify an off-chain Tool result](/guides/tool-development/verify-offchain-tool-result.md) — run the complete RegisteredKey setup and negative checks. * [Troubleshooting](/faq/08-troubleshooting.md) — review confidentiality and transport gotchas. * [`verifier`](/reference/move/nexus_interface/verifier.md) and [`registered_key_verifier`](/reference/move/nexus_registry/registered_key_verifier.md) — inspect the exact proof types and checks. * [Glossary](/glossary/glossary.md) — review verifier mode, verdict, collateral, and slashing terms. --- # 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/faq/06-verification.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.