> 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/11-onchain-result-resolution.md).

# On-Chain Result Resolution

{% hint style="info" %}
**Audience:** Agent developers, Tool developers, Leaders, and integrators.

**Goal:** Follow one on-chain Tool result from creation through committed settlement or a public timeout path.
{% endhint %}

On-chain result resolution is the bridge between a Move Tool call and a durable workflow transition. The Tool creates an `OnchainToolResult`, the workflow consumes exactly one result into one `CommittedToolResult`, and settlement decides whether the walk can advance.

For the recovery procedure, follow [Recovery boundaries](/talus-docs-v2.1.0/guides/agent-usage/execute-and-settle-agent.md#recovery-boundaries) and [Verification and recovery](/talus-docs-v2.1.0/guides/agent-usage/execute-and-settle-agent.md#verification-and-recovery). Those sections cover Task reserve refill, live ExecutionPayment top-up, exact timeout help, separate Occurrence settlement, and the Settled/zero-in-flight proof before closing. The `invocation_id` and broken-result branches require a client whose bindings match the selected network packages and effects.

<figure><picture><source srcset="/files/LhVnG0uXgzmU0gFxz6F2" media="(prefers-color-scheme: dark)"><img src="https://3395888576-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLPrUNT846cHDCVQcRD3f%2Fuploads%2Fgit-blob-593a37927a58115790a8ca16491ad4f8bb2d8c74%2Fd13-commit-result-light.svg?alt=media" alt="Commit one Tool result before affordability settlement"></picture><figcaption><p>Phase 1: Commit one Tool result affordability settlement and advance. Keyed facts: Execute Tool → Create result → Finalize + share → Consume one result → Materialize result; sufficient settlement removes and advances the committed result, while insufficient capacity retains Pending result and its ExecutionPayment lock.</p></figcaption></figure>

<figure><picture><source srcset="/files/yGSue00ybTR3PbFyTj2F" media="(prefers-color-scheme: dark)"><img src="https://3395888576-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLPrUNT846cHDCVQcRD3f%2Fuploads%2Fgit-blob-e6cd8f57dc5820ac0f061a2d2b6ca9177c23b675%2Fd13-shortfall-recovery-light.svg?alt=media" alt="Retain a result until caller or Agent capacity is restored"></picture><figcaption><p>Phase 2: Retain a result until caller or Agent capacity is restored.</p></figcaption></figure>

<figure><picture><source srcset="/files/Jg2uk6vLJ1swuY2sH73b" media="(prefers-color-scheme: dark)"><img src="https://3395888576-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLPrUNT846cHDCVQcRD3f%2Fuploads%2Fgit-blob-0472bef9cd8c6b486d0399c93f72ac2b313985a3%2Fd13-expiry-resolution-light.svg?alt=media" alt="Expiry resolves a pending walk after settlement guards"></picture><figcaption><p>Phase 3: Resolve an expired walk with guards. Keyed facts: the permissionless Expiry resolver compares --now with the deadline; the Expired branch refunds ExecutionPayment and removes the raw result; the Active walk continues without abort.</p></figcaption></figure>

### Create, finalize, and consume

An on-chain Tool receives the result object and its worksheet requirements, writes a tagged output, and calls the protocol finalization path. Finalization and sharing make the result available to the workflow. The normal rule is one exact committed result for one active walk vertex; a second result cannot be silently substituted. The explicit exception is a provisional primary Tool `_err_eval`: an assigned secondary Leader may replace it only when the exact vertex, assigned Leader, failure evidence, and result record checks pass.

The committed result carries the accepted output or failure evidence needed by the walk and payment path. An on-chain Tool may already have mutated application state atomically before this later consume/commit/settlement step; cleanup, refund, or abort does not undo that mutation. Make such effects idempotent or compensatable and verify application business state independently from the result and payment objects. A consumer that waits for an accepted result before mutating state is a separate application pattern. The result object itself is execution state, not application business state; see [DAG and Execution](/talus-docs-v2.1.0/concepts/05-workflow-dag-execution.md) for the state taxonomy.

#### Secondary retry and broken-result cleanup

A secondary Leader replacement of a provisional primary `_err_eval` is not ordinary duplicate-result submission; it is an authority- and evidence-checked replacement that still resolves one committed result for the walk. Keep that branch separate from normal affordability settlement. A durable verifier `Reject` or failure variant can be committed as workflow evidence, but a malformed, wrong-binding, or structurally uncommittable submission may abort before any committed result exists; repair the submission rather than searching for a result to settle.

There are three different timeout boundaries. A **committed-result timeout** resolves the committed result and its payment/Invocation state. A **malformed or uncommittable raw `OnchainToolResult` cleanup** can, after the active walk’s stored effective timeout snapshot expires, be permissionlessly consumed and deleted only through a selected public SDK/PTB cleanup or abort builder that explicitly exposes that operation. The stored effective `timeout_ms` includes the Tool timeout and five-second leader-evaluation buffer; the public recovery boundary uses the active walk’s stored timeout snapshot and evidence checks. The caller must prove the exact walk index, shared result object reference, active Tool witness ID, selected ToolRegistry binding, and invalid-stamp evidence: cleanup applies when the result does not contain all four exact required stamps for the execution, Leader registry, Tool witness, and result object. If the selected CLI/SDK build does not expose a cleanup builder and evidence inspection, stop; do not attempt cleanup and do not substitute a ToolCashier or revenue-collection candidate. Cleanup is not successful result settlement. The committed-result timeout and the primary/secondary `_err_eval` replacement window are separate boundaries; do not use raw-result cleanup as a substitute for either. A later Tool timeout update does not rewrite an active walk. See the generated [execution submission reference](/talus-docs-v2.1.0/reference/move/nexus_workflow/execution_submission.md), [execution settlement reference](/talus-docs-v2.1.0/reference/move/nexus_workflow/execution_settlement.md), [SDK workflow reference](/talus-docs-v2.1.0/reference/sdk/actions-workflow.md), and [DAG execution diagnosis](/talus-docs-v2.1.0/concepts/05-workflow-dag-execution.md) for the public recovery boundary.

#### Pending settlement and affordability

After commitment, settlement checks the available `ExecutionPayment`, the Tool charge, leader payable amount, and any policy-backed Invocation lock. When the amount is affordable, the protocol settles the result, removes the committed result when no further resolution is needed, and advances the walk.

When payment is insufficient after commitment, the walk remains `PendingSettlement`, the committed result and Invocation lock remain, and the execution records an insufficient-settlement marker. Any caller may add a nonzero SUI coin to the live `ExecutionPayment`; this does not change the recorded source, controller, refund recipient, or policy terms. A refill from an Agent vault requires the matching Agent authority. The public refill helpers also invoke `emit_payment_ready_walk_requests` and can request other active walks whose payments are ready, but they do not settle this pending committed-result walk. After the top-up, run `nexus tap execution settle --execution-id <id> --walk-index <index>`. The selected CLI/SDK settlement transaction clears the eligible committed result and then invokes `emit_payment_ready_walk_requests`, so verify that the marker, committed result, and lock clear and that each payment-ready active walk receives its request.

#### Timeout and permissionless resolution

If the responsible submission window expires, an eligible permissionless caller can resolve the expired active walk or take the documented abort path. Abort requires at least one active walk at the double-timeout boundary, no committed result awaiting settlement, and zero payment vertex locks after any exact Invocation refund. `nexus tap execution resolve-expired-walk --execution-id <id> --walk-index <index> --invocation-id <invocation-id>` refunds the locked Invocation before applying the abort transition; omit the ID only when the selected command proves one unique candidate. The SDK/CLI can discover finalized invalid-stamp `OnchainToolResult` objects, pass them into the abort transaction, clean them, and abort atomically; a consumable or unfinalized raw result still blocks abort. `nexus tap execution abort --execution-id <id>` handles remaining eligible expired active walks only after these guards hold. A `PendingSettlement` walk must be settled, never aborted. Expiry is a protocol condition, not an instruction to reveal internal service operation.

#### Locks and payment

Nexus uses an `Invocation` to identify the execution, vertex, Tool, cashier, beneficiary, policy, amount, and refund source, with linear lock and settlement receipts showing whether the accepted result charged, refunded, or remains pending. Its payment-side `ExecutionPaymentVertexLock` contains `vertex_key`, `invocation_id`, and `amount`; it does not duplicate the full policy record. Correlate both objects and the transaction effects instead of inferring beneficiary, policy, or refund state from the payment lock alone. Exact fields and builders remain in the generated [Invocation reference](/talus-docs-v2.1.0/reference/move/nexus_tool/invocation.md) and payment references.

#### What proves completion

1. Read the `OnchainToolResult` creation and finalization effects.
2. Confirm one exact result was consumed into one `CommittedToolResult`.
3. Inspect pending settlement and the affordability decision.
4. If insufficient, add a nonzero SUI coin to the live `ExecutionPayment`, or use matching Agent authority for an Agent-vault refill, then retry until the pending marker clears.
5. If expired, record the permissionless resolution or abort evidence.
6. Confirm the committed result was removed and the walk advanced after successful settlement.

Result resolution supplements [DAG and Execution](/talus-docs-v2.1.0/concepts/05-workflow-dag-execution.md) and [Payment Vaults, Reserves, and Settlement](/talus-docs-v2.1.0/concepts/06-payment-vaults-reserves-and-settlement.md); neither should repeat this full lifecycle.

**Next**

Continue to [Scheduling](/talus-docs-v2.1.0/concepts/12-scheduling.md) when a resolved execution should create future occurrences.


---

# 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/11-onchain-result-resolution.md?ask=<question>&goal=<user_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.