tangle-network · drewstone · Jun 15, 2026 · Jun 15, 2026
diff --git a/pages/blueprints/ai-agent-sandbox/dapp-and-indexer.mdx b/pages/blueprints/ai-agent-sandbox/dapp-and-indexer.mdx
@@ -62,7 +62,7 @@ The sandbox app is iframe-first. The parent dapp should:
 
 ## Bad copy to avoid
 
-Do not name the product after one harness. The Sandbox SDK supports OpenCode plus 12 peer backend types: Claude Code, Kimi Code, Codex, AMP, Factory Droids, Pi, Hermes, Forge, OpenClaw, ACP, Cursor, and CLI base. The current Sandbox UI picker exposes a subset plus NanoClaw. The AI Agent Sandbox blueprint's current all-harness sidecar advertises Claude Code, Codex, OpenCode, Kimi Code, and Gemini CLI. The product boundary is the sandbox service instance and operator API.
+Do not name the product after one harness. The Sandbox SDK supports OpenCode plus 13 peer backend types: Claude Code, Kimi Code, Codex, AMP, Factory Droids, Pi, Hermes, Forge, OpenClaw, NanoClaw, ACP, Cursor, and CLI base. The current Sandbox UI picker exposes OpenClaw and NanoClaw while deferring Pi, Forge, ACP, and Cursor. The AI Agent Sandbox blueprint's current all-harness sidecar advertises Claude Code, Codex, OpenCode, Kimi Code, and Gemini CLI. The product boundary is the sandbox service instance and operator API.
 
 Use capability language instead:
 

diff --git a/pages/blueprints/ai-agent-sandbox/runtime-and-harnesses.mdx b/pages/blueprints/ai-agent-sandbox/runtime-and-harnesses.mdx
@@ -7,7 +7,7 @@ description: Runtime backends, capability discovery, harnesses, and AI credentia
 
 The sandbox is the product. Harnesses are tools inside the sandbox.
 
-Do not describe this blueprint as an OpenCode integration, a Codex integration, or a Claude integration. The Sandbox SDK supports OpenCode plus 12 peer backend types: Claude Code, Kimi Code, Codex, AMP, Factory Droids, Pi, Hermes, Forge, OpenClaw, ACP, Cursor, and CLI base. A blueprint service instance asks its operator for the live runtime set through `GET /api/capabilities`.
+Do not describe this blueprint as an OpenCode integration, a Codex integration, or a Claude integration. The Sandbox SDK supports OpenCode plus 13 peer backend types: Claude Code, Kimi Code, Codex, AMP, Factory Droids, Pi, Hermes, Forge, OpenClaw, NanoClaw, ACP, Cursor, and CLI base. A blueprint service instance asks its operator for the live runtime set through `GET /api/capabilities`.
 
 ## Runtime backends
 

diff --git a/pages/blueprints/ai-trading/operator-requirements.mdx b/pages/blueprints/ai-trading/operator-requirements.mdx
@@ -62,7 +62,7 @@ Public admission means public cost exposure. Every accepted bot can use CPU, dis
 
 The operator install path defaults new bots to paper trading. Paper mode uses live market data and simulated fills; it should not move capital.
 
-AI keys are optional. If you set `ZAI_API_KEY`, `ANTHROPIC_API_KEY`, `TANGLE_API_KEY`, or OpenCode model/env settings, agentic activation and chat can use those settings when the selected sidecar advertises OpenCode. Treat OpenCode as one harness inside the same capability model as Claude Code, Kimi Code, Codex, AMP, Factory Droids, Pi, Hermes, Forge, OpenClaw, ACP, Cursor, CLI base, or a smaller blueprint sidecar subset. The operator docs are clear: there is no built-in per-bot, per-day, or total LLM spend cap today. Use provider-side billing limits.
+AI keys are optional. If you set `ZAI_API_KEY`, `ANTHROPIC_API_KEY`, `TANGLE_API_KEY`, or OpenCode model/env settings, agentic activation and chat can use those settings when the selected sidecar advertises OpenCode. Treat OpenCode as one harness inside the same capability model as Claude Code, Kimi Code, Codex, AMP, Factory Droids, Pi, Hermes, Forge, OpenClaw, NanoClaw, ACP, Cursor, CLI base, or a smaller blueprint sidecar subset. The operator docs are clear: there is no built-in per-bot, per-day, or total LLM spend cap today. Use provider-side billing limits.
 
 ## Public endpoint
 

diff --git a/pages/blueprints/operator-matrix.mdx b/pages/blueprints/operator-matrix.mdx
@@ -43,7 +43,7 @@ The three first-party blueprints do not fail the same way. A sandbox operator ru
 
 ## Harnesses are not the product boundary
 
-The sandbox product is the sandbox service instance plus its operator API. The Sandbox SDK supports OpenCode, Claude Code, Kimi Code, Codex, AMP, Factory Droids, Pi, Hermes, Forge, OpenClaw, ACP, Cursor, and CLI base. The current all-harness sidecar in the sandbox blueprint advertises Claude Code, Codex, OpenCode, Kimi Code, and Gemini CLI through `GET /api/capabilities`.
+The sandbox product is the sandbox service instance plus its operator API. The Sandbox SDK supports OpenCode, Claude Code, Kimi Code, Codex, AMP, Factory Droids, Pi, Hermes, Forge, OpenClaw, NanoClaw, ACP, Cursor, and CLI base. The current all-harness sidecar in the sandbox blueprint advertises Claude Code, Codex, OpenCode, Kimi Code, and Gemini CLI through `GET /api/capabilities`.
 
 That endpoint is the contract the app should read. Do not make docs or UI copy pretend OpenCode, Codex, or any one harness is the integration. Harness support can change by publishing a new sidecar image without changing the blueprint ABI.
 

diff --git a/pages/developers/api/reference/ITangleServices.mdx b/pages/developers/api/reference/ITangleServices.mdx
@@ -57,9 +57,9 @@ Approve a service request as one of its operators.
 
 _Single entrypoint covering every approval mode. Pass empty/zero fields on `ApprovalParams` to opt out of the corresponding capability:_
 
-- `securityCommitments == []` — no per-asset commitment supplied. Only valid when the request has no security requirements OR the only requirement is the protocol-default TNT requirement (auto-filled at min-exposure).
-- `blsPubkey == [0,0,0,0]` — operator does NOT register a BLS pubkey for aggregated job-result signing. BLS is opt-in; the protocol accepts any operator.
-- `teeCommitments == []` — operator does NOT bind to a TEE attestation profile.
+- `securityCommitments == []` - no per-asset commitment supplied. Only valid when the request has no security requirements OR the only requirement is the protocol-default TNT requirement (auto-filled at min-exposure).
+- `blsPubkey == [0,0,0,0]` - operator does NOT register a BLS pubkey for aggregated job-result signing. BLS is opt-in; the protocol accepts any operator.
+- `teeCommitments == []` - operator does NOT bind to a TEE attestation profile.
 
 #### getTeeCommitmentRoot
 
@@ -75,7 +75,7 @@ Returns `keccak256(abi.encode(commitments))` over an operator's `TeeAttestationC
 function teeNonceFor(uint64 requestId) external view returns (bytes32)
 ```
 
-Canonical TEE attestation nonce binding for `requestId` on this contract on this chain. Operators MUST submit this exact value as `nonceBinding` in any `TeeAttestationCommitment` for the request — it eliminates cross-request attestation replay at approval time.
+Canonical TEE attestation nonce binding for `requestId` on this contract on this chain. Operators MUST submit this exact value as `nonceBinding` in any `TeeAttestationCommitment` for the request - it eliminates cross-request attestation replay at approval time.
 
 #### blsPopMessage
 

diff --git a/pages/developers/api/reference/generated/ITangleServices.mdx b/pages/developers/api/reference/generated/ITangleServices.mdx
@@ -57,9 +57,9 @@ Approve a service request as one of its operators.
 
 _Single entrypoint covering every approval mode. Pass empty/zero fields on `ApprovalParams` to opt out of the corresponding capability:_
 
-- `securityCommitments == []` — no per-asset commitment supplied. Only valid when the request has no security requirements OR the only requirement is the protocol-default TNT requirement (auto-filled at min-exposure).
-- `blsPubkey == [0,0,0,0]` — operator does NOT register a BLS pubkey for aggregated job-result signing. BLS is opt-in; the protocol accepts any operator.
-- `teeCommitments == []` — operator does NOT bind to a TEE attestation profile.
+- `securityCommitments == []` - no per-asset commitment supplied. Only valid when the request has no security requirements OR the only requirement is the protocol-default TNT requirement (auto-filled at min-exposure).
+- `blsPubkey == [0,0,0,0]` - operator does NOT register a BLS pubkey for aggregated job-result signing. BLS is opt-in; the protocol accepts any operator.
+- `teeCommitments == []` - operator does NOT bind to a TEE attestation profile.
 
 #### getTeeCommitmentRoot
 
@@ -75,7 +75,7 @@ Returns `keccak256(abi.encode(commitments))` over an operator's `TeeAttestationC
 function teeNonceFor(uint64 requestId) external view returns (bytes32)
 ```
 
-Canonical TEE attestation nonce binding for `requestId` on this contract on this chain. Operators MUST submit this exact value as `nonceBinding` in any `TeeAttestationCommitment` for the request — it eliminates cross-request attestation replay at approval time.
+Canonical TEE attestation nonce binding for `requestId` on this contract on this chain. Operators MUST submit this exact value as `nonceBinding` in any `TeeAttestationCommitment` for the request - it eliminates cross-request attestation replay at approval time.
 
 #### blsPopMessage
 

diff --git a/pages/developers/blueprint-contexts/introduction.mdx b/pages/developers/blueprint-contexts/introduction.mdx
@@ -27,7 +27,7 @@ The Context pattern offers several significant benefits in software design and d
 
 1. **Decoupling**: By passing dependencies through a Context, we decouple the job implementation from the specific implementations of its dependencies. This makes the code more modular and easier to maintain.
 
-2. **Testability**: With a Context, it's easier to mock or stub dependencies during unit testing, allowing for more comprehensive and isolated tests.
+2. **Testability**: With a Context, tests can replace RPC clients, keystores, or service clients with mocks and fixtures.
 
 3. **Flexibility**: Contexts allow for easy swapping of implementations, which is particularly useful when adapting to different environments (e.g., development, staging, production).
 

diff --git a/pages/developers/blueprint-qos.mdx b/pages/developers/blueprint-qos.mdx
@@ -350,9 +350,9 @@ event MetricViolation(
 
 Violation reasons include:
 
-- `"required metric missing"` — a required metric was not reported
-- `"value below minimum"` — reported value < `minValue`
-- `"value above maximum"` — reported value > `maxValue`
+- `"required metric missing"` - a required metric was not reported
+- `"value below minimum"` - reported value < `minValue`
+- `"value above maximum"` - reported value > `maxValue`
 
 Slashing is intentionally decoupled from validation. Auto-slashing from metric violations is dangerous because transient spikes or network delays could trigger false positives. Instead:
 

diff --git a/pages/developers/blueprint-runner/background-services.mdx b/pages/developers/blueprint-runner/background-services.mdx
@@ -86,6 +86,6 @@ Now that you understand background services, it might be helpful to take a look
 - [Consumers](/developers/blueprint-runner/consumers) - How to handle job results
 - [Building a Blueprint Runner](/developers/blueprint-runner/building) - Step-by-step guide to building your own Blueprint Runner
 
-## Conclusion
+## Before You Ship
 
-Background services are powerful components that enhance the capabilities of your Blueprint Runner by providing continuous support operations. By implementing well-designed background services, you can build more robust, efficient, and feature-rich Blueprints.
+Verify that each background service starts, reports failure, and shuts down cleanly. If the service owns a connection, lock, or local process, its shutdown handler should release that resource before the runner exits.
diff --git a/pages/developers/blueprint-runner/building.mdx b/pages/developers/blueprint-runner/building.mdx
@@ -165,7 +165,7 @@ let result = BlueprintRunner::builder(tangle_config, env)
 
 The `run` method starts the Blueprint Runner and returns a result indicating whether it ran successfully or encountered an error.
 
-With this, the Blueprint Runner, the centerpoint of your Blueprint is ready to be used!
+With this, the Blueprint Runner can start and serve the components you attached to the builder.
 
 ## Next Steps
 
@@ -175,6 +175,6 @@ After building your Blueprint Runner, you might want to explore:
 - [Producer Patterns](/developers/blueprint-runner/producers#producer-patterns)
 - [Consumer Patterns](/developers/blueprint-runner/consumers#consumer-patterns)
 
-## Conclusion
+## Before You Ship
 
-Building a Blueprint Runner involves setting up various components that work together to execute your Tangle Blueprint. By following this guide and adhering to best practices, you can create a robust and efficient Blueprint Runner for your blueprint service on the Tangle Network.
+Run the runner against a local node or testnet, submit one real job, and keep the transaction hash plus runner logs. A runner is ready for operators only after it can start, receive a job, execute the handler, and return the expected result.
diff --git a/pages/developers/blueprint-runner/consumers.mdx b/pages/developers/blueprint-runner/consumers.mdx
@@ -99,6 +99,6 @@ Now that you understand consumers, learn about:
 - [Producers](/developers/blueprint-runner/producers) - How to capture and process events
 - [Building a Blueprint Runner](/developers/blueprint-runner/building) - Step-by-step guide to building your own Blueprint Runner
 
-## Conclusion
+## Before You Ship
 
-Consumers are essential components that translate job results into meaningful actions in your Blueprint Runner. By implementing robust and efficient consumers, you can ensure that your Blueprint operates reliably and effectively.
+Check the consumer path with a successful result and a failed result. The runner should record the outcome, retry only when the action is safe to repeat, and surface enough context for an operator to debug the failure.
diff --git a/pages/developers/blueprint-runner/jobs.mdx b/pages/developers/blueprint-runner/jobs.mdx
@@ -101,6 +101,6 @@ Now that you understand jobs, it might be helpful to take a look at:
 - [Consumers](/developers/blueprint-runner/consumers) - How to handle job results
 - [Building a Blueprint Runner](/developers/blueprint-runner/building) - Step-by-step guide to building your own Blueprint Runner
 
-## Conclusion
+## Before You Ship
 
-Jobs are the core building blocks of your Blueprint, encapsulating the business logic that processes events and produces meaningful results. By implementing well-designed jobs, you can create powerful and flexible Blueprints that can handle a wide range of use cases.
+Test each job with valid input, invalid input, and an execution failure. The handler should reject malformed calls before doing work and return errors that let a consumer decide whether to retry, alert, or stop.
diff --git a/pages/developers/blueprint-runner/producers.mdx b/pages/developers/blueprint-runner/producers.mdx
@@ -97,6 +97,6 @@ Now that you understand producers, learn about:
 - [Consumers](/developers/blueprint-runner/consumers) - How to handle job results
 - [Building a Blueprint Runner](/developers/blueprint-runner/building) - Step-by-step guide to building your own Blueprint Runner
 
-## Conclusion
+## Before You Ship
 
-Producers are essential components that capture and prepare events for processing in your Blueprint Runner. By implementing robust and efficient producers, you can ensure that your Blueprint reliably processes desired events.
+Run the producer against the real event source or a recorded fixture. It should emit the same `JobCall` shape the router expects, preserve ordering where the service requires it, and stop cleanly when the runner shuts down.
diff --git a/pages/developers/blueprint-runner/routers.mdx b/pages/developers/blueprint-runner/routers.mdx
@@ -74,6 +74,6 @@ Now that you understand routers, check out:
 - [Consumers](/developers/blueprint-runner/consumers) - How to handle job results
 - [Building a Blueprint Runner](/developers/blueprint-runner/building) - Step-by-step guide to building your own Blueprint Runner
 
-## Conclusion
+## Before You Ship
 
-Routers are a fundamental component of Blueprint Runners, enabling efficient job execution and management. By properly configuring and utilizing routers, you can build robust and performant Blueprints.
+Submit at least one job per route and one unknown job ID. The router should dispatch known calls to the intended handler, reject unknown calls clearly, and preserve the error shape your consumers expect.
diff --git a/pages/developers/cli/keys.mdx b/pages/developers/cli/keys.mdx
@@ -158,7 +158,7 @@ The Tangle CLI supports the following key types:
 
 ## Best Practices
 
-1. **Backup your keys**: Always keep a secure backup of your keys or mnemonic phrases.
-2. **Secure your keystore**: Ensure your keystore directory has appropriate permissions.
+1. **Back up recovery material**: Store mnemonic phrases offline and test recovery before funding an account.
+2. **Lock down your keystore**: Restrict the keystore directory to the OS user that runs the CLI, for example with `chmod 700 <keystore-dir>` on Linux/macOS.
 3. **Use different keys for different environments**: Use separate keys for testnet and mainnet.
 4. **Never share your private keys**: Keep your private keys confidential.
diff --git a/pages/developers/endpoints.mdx b/pages/developers/endpoints.mdx
@@ -1,5 +1,19 @@
 import NetworkTabs from "../../components/NetworkResources.tsx"
 
-# Resources
+# Network Resources
+
+Use this page when you need the public dapp, chain endpoints, explorers, wallet metadata, or source repos for Tangle.
+
+## What to use
+
+| Need                             | Use                                                                     |
+| -------------------------------- | ----------------------------------------------------------------------- |
+| Stake, delegate, or inspect apps | The Tangle dapp for the target network.                                 |
+| Read chain state                 | The public RPC or WSS endpoint for the target network.                  |
+| Check transactions and contracts | The EVM explorer for the target network.                                |
+| Build protocol integrations      | The `tnt-core` contracts and generated bindings for the current branch. |
+| Build or run Blueprint services  | The Blueprint SDK and product-specific blueprint docs.                  |
+
+Public RPC endpoints are shared infrastructure. Production apps and operators should use their own RPC provider or a monitored endpoint when reliability matters.
 
 <NetworkTabs />
diff --git a/pages/developers/key-contacts.mdx b/pages/developers/key-contacts.mdx
@@ -7,7 +7,7 @@ Primary points of contact for Tangle Network security, operations, and complianc
 | Founder and CEO    | Drew Stone | drew@tangle.tools  |
 | Security Contact   | Drew Stone | drew@tangle.tools  |
 | Compliance Contact | Drew Stone | drew@tangle.tools  |
-| General Inquiries  | —          | hello@tangle.tools |
+| General Inquiries  | -          | hello@tangle.tools |
 
 ## Reporting Security Issues
 

diff --git a/pages/developers/slashing.mdx b/pages/developers/slashing.mdx
@@ -58,7 +58,7 @@ The operator must post `config.disputeBond` in native asset. `SLASH_ADMIN` posts
 
 A `SLASH_ADMIN_ROLE` holder that is also the `proposer` of a slash CANNOT dispute their own
 proposal. Without this, a single role-holder could propose, immediately self-dispute (no bond),
-and freeze operator stake for the full `disputeResolutionDeadline` window — and (when
+and freeze operator stake for the full `disputeResolutionDeadline` window - and (when
 `treasury == admin`) capture the operator's bond on auto-execution. To dispute as
 `SLASH_ADMIN`, route the dispute through a different admin-keyed account or the operator.
 

diff --git a/pages/gateway/api-generation.mdx b/pages/gateway/api-generation.mdx
@@ -50,6 +50,6 @@ Authorization: Bearer sk-tan-YOUR_KEY
 
 | Status | Code        | Description                                     |
 | ------ | ----------- | ----------------------------------------------- |
-| 400    | —           | Missing or invalid generation ID                |
-| 401    | —           | Authentication required                         |
+| 400    | -           | Missing or invalid generation ID                |
+| 401    | -           | Authentication required                         |
 | 404    | `not_found` | Generation not found or belongs to another user |
diff --git a/pages/gateway/authentication.mdx b/pages/gateway/authentication.mdx
@@ -38,7 +38,7 @@ POST /api/siwe/verify
 
 ## SpendAuth (On-Chain Payment)
 
-EIP-712 signed payment authorization. No account needed — pay operators directly on-chain.
+EIP-712 signed payment authorization. No account needed - pay operators directly on-chain.
 
 ```bash
 curl -H "X-Payment-Signature: {\"commitment\":\"0x...\",\"amount\":\"1000000\",...}" \