> 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/reference/toolkit/rust.md). # Toolkit Rust **Audience:** Nexus toolkit integrators (Rust). **Area:** Toolkit Rust public API. **Generated from:** Nexus SDK toolkit public API at release `v2.1.0` commit `45d397aafcfbeeeaf5032d5fb9fa5d99b3f36205` (generated inventory preserved below). This page documents the public Rust surface that the Nexus Toolkit exports for tool authors and runtime integrators. The items are grouped by source file and listed in declaration order. #### `toolkit-rust/src/lib.rs` **`AnyResult`** ```rust pub type AnyResult = anyhow::Result; ``` Convenience result alias re-exported by the toolkit crate. **`env_logger`** ```rust pub use env_logger; ``` Re-export of the logging initialization crate used by the toolkit runtime. **`debug`** ```rust pub use log::debug; ``` Logging macro re-export for toolkit and tool runtime code. **`warp`** ```rust pub use warp; ``` HTTP framework re-export used by the toolkit runtime and bootstrap macro. **`StatusCode`** ```rust pub use warp::http::StatusCode; ``` HTTP status code type used throughout the toolkit runtime and tool trait helpers. **`toolkit-rust/src/nexus_tool.rs`** **`AuthContext`** ```rust pub type AuthContext = nexus_sdk::signed_http::v3::wire::AuthenticatedRequest; ``` Authenticated request context available to Tools when signed HTTP is required. It contains the Leader capability ID, Leader key ID, canonical input hash, Leader signature, and deterministic nonce after request authentication. **`NexusTool`** ```rust pub trait NexusTool: Send + Sync + 'static ``` Trait implemented by a Nexus tool service. **`Input`** ```rust type Input: JsonSchema + DeserializeOwned + Send; ``` The input payload type for the tool. **`Output`** ```rust type Output: JsonSchema + Serialize + Send; ``` The output payload type for the tool. **`fqn`** ```rust fn fqn() -> ToolFqn; ``` Returns the fully qualified tool name used by the runtime and metadata endpoint. **`timeout`** ```rust fn timeout() -> Duration ``` Returns the tool timeout, which defaults to 10 seconds. **`invoke`** ```rust fn invoke(&self, input: Self::Input) -> impl Future + Send; ``` Runs the tool for a single invocation request. **`authorize`** ```rust fn authorize(&self, _ctx: AuthContext) -> impl Future> + Send; ``` Optional policy hook that runs after signed HTTP authentication and before invocation. **`health`** ```rust fn health(&self) -> impl Future> + Send; ``` Returns the health status used by `GET /health`. **`path`** ```rust fn path() -> &'static str; ``` Returns the relative HTTP path for the tool, defaulting to the web root. **`description`** ```rust fn description() -> &'static str; ``` Returns the human-readable description surfaced in metadata. Implementations must provide meaningful text: SDK registration rejects an empty or whitespace-only description. **`new`** ```rust fn new() -> impl Future + Send; ``` Constructs a tool instance, usually so dependencies can be injected for tests. **`meta`** ```rust fn meta(url: Url) -> Value; ``` Builds the metadata JSON used by `GET /meta`. **`toolkit-rust/src/config.rs`** **`ENV_TOOLKIT_CONFIG_PATH`** ```rust pub const ENV_TOOLKIT_CONFIG_PATH: &str = "NEXUS_TOOLKIT_CONFIG_PATH"; ``` Environment variable that points the runtime at its JSON config file. **TLS runtime selection** When both nonempty TLS credential paths are configured, `bootstrap!` terminates TLS in the toolkit runtime. It explicitly selects the Rustls `ring` provider before building the server configuration so another provider enabled by a Tool dependency cannot make provider selection ambiguous. The runtime serves plain HTTP only when both TLS variables are absent. A missing, empty, or unmatched certificate/key path is a startup configuration error. **`SignedHttpMode`** ```rust pub enum SignedHttpMode { Disabled, Required, } ``` Signed HTTP policy for the toolkit runtime. **`Disabled`** Do not require signature headers. **`Required`** Reject requests that are missing or fail signature verification. **`ToolkitRuntimeConfig`** ```rust pub struct ToolkitRuntimeConfig { /* private fields */ } ``` Validated runtime config for the toolkit HTTP server. **`from_env`** ```rust pub fn from_env() -> anyhow::Result ``` Loads config from `ENV_TOOLKIT_CONFIG_PATH` when set, otherwise uses runtime defaults. **`from_path`** ```rust pub fn from_path(path: impl AsRef) -> anyhow::Result ``` Parses config from a JSON file on disk. **`from_json_bytes`** ```rust pub fn from_json_bytes(bytes: &[u8]) -> anyhow::Result ``` Parses config from JSON bytes. **`from_json_str`** ```rust pub fn from_json_str(json: &str) -> anyhow::Result ``` Parses config from a JSON string. **`invoke_max_body_bytes`** ```rust pub fn invoke_max_body_bytes(&self) -> u64 ``` Returns the maximum allowed `/invoke` request body size. **`signed_http_is_required`** ```rust pub fn signed_http_is_required(&self) -> bool ``` Returns whether the runtime requires signed HTTP requests. **`has_tool`** ```rust pub fn has_tool(&self, tool_id: &str) -> bool ``` Returns whether signed HTTP configuration contains an entry for the Tool id. The entry may omit response-signing material. **Toolkit JSON contract** `ToolkitRuntimeConfig` has no top-level config version and uses optional per-Tool `response_signing_key`. Keep this exact JSON shape consistent across config, tests, and verification examples. `ToolkitRuntimeConfig` reads one strict JSON object. Unknown fields fail parsing. ```json { "invoke_max_body_bytes": 10485760, "signed_http": { "mode": "required", "allowed_leaders_path": "", "tools": { "xyz.dummy.tool@1": { "response_signing_key": "0000000000000000000000000000000000000000000000000000000000000000", "replay_cache_ttl_ms": 300000 } } } } ``` | Field | Contract | | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `invoke_max_body_bytes` | Optional request-body limit in bytes; defaults to 10 MiB. `/invoke` requires `Content-Length` within the limit. | | `signed_http.mode` | `disabled` or `required`; omission inside the section defaults to `required`. Omitting the whole section disables signed HTTP. | | `signed_http.allowed_leaders_path` | Path to a v3 `AllowedLeadersFileV1` JSON file. A relative path resolves from the Toolkit process working directory, not from the config file. A file-backed resolver refreshes this path during key lookup and retains the prior allowlist if a refresh fails. | | `signed_http.allowed_leaders` | Inline alternative with `{ "version": 1, "leaders": [...] }`. Use one allowlist source; when both are present, inline data is selected. | | `signed_http.tools` | Nonempty map from exact Tool FQN to its runtime signing configuration. | | `response_signing_key` | Optional 32-byte Ed25519 private key encoded as hex, base64, base64url, or Sui’s 33-byte base64 form with a leading zero flag. When present, the Toolkit signs successful canonical Tool result BCS; RegisteredKey result evidence requires it. The zero key above is test material only. | | `replay_cache_ttl_ms` | Optional positive completed-entry lifetime; defaults to 300,000 ms. | Set the config path before `bootstrap!` starts: ```bash export NEXUS_TOOLKIT_CONFIG_PATH="$PWD/toolkit-config.json" cargo run ``` There is no Tool KID or external replay-store field. Tool identity selects the active on-chain Tool key. Replay state is process-local memory keyed by deterministic nonce and canonical input hash: in-flight reuse is rejected, an exact completed retry returns cached canonical bytes, and completed entries expire after the configured TTL. In `Required`, the Toolkit verifies the Leader signature over the schema-ordered canonical input hash and reconstructs that hash from the resolved body before invocation. When `response_signing_key` is configured, it signs successful canonical result BCS; without that key, request authentication still applies but the response carries no Tool signature. A signed response can still encode a semantic Tool `err` variant; consumers must decode the canonical result and distinguish `ok` from `err`. The Tool signature binds the v3 response domain, Leader signature, deterministic nonce, and domain-separated response hash. Method/path/query/raw JSON, time-window claims, status, and other headers are not signed; authenticated HTTPS protects those fields and plaintext transport. The v3 request headers are `X-Nexus-Sig-V`, `X-Nexus-Leader-Id`, `X-Nexus-Leader-Key-Id`, `X-Nexus-Input-Hash`, `X-Nexus-Leader-Signature`, and `X-Nexus-Nonce`. A signed canonical response carries only `X-Nexus-Sig-V` and `X-Nexus-Tool-Signature`. Gateways must forward every listed request and response header without renaming or dropping it. Set both `NEXUS_TOOL_TLS_CERT_PATH` and `NEXUS_TOOL_TLS_KEY_PATH` for direct Toolkit TLS, or protect the gateway-to-Tool hop equivalently. **`toolkit-rust/src/serde_tracked.rs`** **`WithSerdeErrorPath`** ```rust pub struct WithSerdeErrorPath(pub T); ``` Transparent wrapper that preserves serde error paths while serializing and deserializing the inner value. **`toolkit-rust/src/runtime.rs`** **`bootstrap!`** ```rust bootstrap!(Tool); bootstrap!([Tool, OtherTool]); bootstrap!(([127, 0, 0, 1], 8080), Tool); bootstrap!(([127, 0, 0, 1], 8080), [Tool, OtherTool]); ``` Macro that loads toolkit configuration, serves `GET /health`, `GET /meta`, and `POST /invoke`, and supports `--meta` for printing tool metadata without starting the server. --- # 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/reference/toolkit/rust.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.