> 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/guides/tap-development/execute-and-verify-transfer.md). # Execute and Verify the Transfer {% hint style="info" %} **Audience:** Nexus adopters and integrators. **Goal:** Execute the Talus Agent Package (TAP) transfer flow with disposable funds and verify the resulting Task, execution, state change, and recovery boundary. {% endhint %} Time to run the skill. From here on you need the values captured on the previous page: ```bash PKG= STATE= AGENT= SKILL= ``` Pick a recipient address. The example uses a complete illustrative address; use an address you control if you want to inspect the received coin later: ```bash RECIPIENT=0x000000000000000000000000000000000000000000000000000000000000face ``` {% hint style="danger" %} This tutorial Tool has no package-specific caller capability or sender check. Any actor able to schedule a compatible DAG can choose the recipient and drain the stored coin. Use disposable demonstration assets only. {% endhint %} ### 1. Fund the treasury The Tool empties whatever coin is sitting in `TutorialState.treasury`. Deposit 0.1 SUI before scheduling the workflow. `fund_treasury` is a public Move function, so a small PTB can split a coin from gas and pass it in: ```bash sui client ptb \ --split-coins gas '[100000000]' \ --assign deposit \ --move-call "$PKG::tutorial_transfer::fund_treasury" "@$STATE" deposit.0 \ --gas-budget 50000000 \ --json > fund-treasury.json jq '.effects.status' fund-treasury.json ``` The `100000000` is MIST (0.1 SUI). The PTB: * splits one 0.1 SUI coin from the transaction's gas coin; * consumes that coin in `fund_treasury(state, coin)`; * leaves the remainder of the gas coin with its owner. Confirm the shared state after the transaction: ```bash sui client object "$STATE" --json > tutorial-state-funded.json jq '.content.treasury // .content.fields.treasury' tutorial-state-funded.json ``` The exact parsed JSON wrapper depends on the Sui CLI response shape, but the decoded treasury option must contain the deposited coin. The transaction effects plus the fresh state read are stronger evidence than terminal text alone. #### 2. Fund and schedule the Task The V2 LTS target uses the durable `Task → Occurrence → Execution` model. A Task owns the reusable operation, controller, funding reserve, failure policy, and Schedule. Each scheduling opportunity becomes a permanent Occurrence; dispatch creates the Execution that contains walks and Tool results. This skill is `UserFunded`, so the default address-funded path reserves MIST from the configured signer's Nexus SUI balance. Inspect and fund that balance first: ```bash nexus gas balance --json nexus gas deposit --amount 200000000 --json nexus gas balance --json ``` The scheduling command below withdraws 50,000,000 MIST for the Task reserve and uses address-balance gas with a default 100,000,000-MIST gas budget. Before submitting, confirm at least 150,000,000 MIST remains in that address balance; the 200,000,000-MIST deposit provides a margin when starting from zero. `nexus gas deposit` itself selects an owned SUI coin, which must cover both the deposit and its transaction gas budget. Owned coin balances alone do not satisfy the later Task's address-balance requirement. Keep enough address balance, or supply `--sui-gas-coin`, for settlement and closure too. Build the entry input once and schedule one immediate Occurrence: ```bash INPUT_JSON=$(jq -cn \ --arg state "$STATE" \ --arg recipient "$RECIPIENT" \ '{transfer_vertex: {"0": $state, "1": $recipient}}') nexus task schedule \ --agent-id "$AGENT" \ --skill-id "$SKILL" \ --input-json "$INPUT_JSON" \ --prepay-amount-mist 50000000 \ --occurrence-budget-mist 50000000 \ --now \ --json > task-schedule.json ``` The receipt identifies the shared Task and every Occurrence allocated by the transaction. Never assume the first occurrence number is zero; read it from the receipt: ```bash TASK=$(jq -r '.task_id' task-schedule.json) OCCURRENCE=$(jq -r '.delta.scheduled[0].reference.occurrence_id' task-schedule.json) echo "TASK=$TASK OCCURRENCE=$OCCURRENCE" ``` Scheduling performs four durable actions: 1. Resolves the Agent skill and its pinned DAG and requirements. 2. Creates a Task controlled by the configured signer and reserves its address-funded MIST. 3. Adds an immediate Occurrence to the Task's Schedule. 4. Makes that Occurrence available for leader dispatch; dispatch creates the deterministic Execution. #### 3. Wait for the recipient balance to increase Follow the Occurrence until it either completes or needs an operator action: ```bash nexus task occurrence inspect \ --task-id "$TASK" \ --occurrence-id "$OCCURRENCE" \ --follow \ --json > occurrence.json ``` Then inspect the Execution selected by that Task/Occurrence pair: ```bash nexus execution inspect \ --task-id "$TASK" \ --occurrence-id "$OCCURRENCE" \ --json > execution.json ``` On success, the leader called `transfer_vertex::execute(requirements, result, state, recipient, ctx)`. The Tool consumed the treasury coin, transferred it to `RECIPIENT`, satisfied the registered witness, and finalized a `transferred` result. Verify both sides of the business-state change: ```bash sui client balance "$RECIPIENT" --json > recipient-balance.json sui client object "$STATE" --json > tutorial-state-after.json jq '.content.treasury // .content.fields.treasury' tutorial-state-after.json ``` The recipient balance should include the transferred amount and the treasury option should be empty. A balance can include unrelated coins, so retain `execution.json`, the state before/after, and transaction effects when you need auditable proof. #### 4. Inspect the Execution and settle the Occurrence Capture the inspection output and transaction effects immediately after the transfer. Testnet transaction history can be pruned after only a few days, so an older successful run may report `history is incomplete: missing transaction …`. The Task/Occurrence record can remain available while Execution reconstruction is unavailable. Keep the original receipts, collection time, CLI version, network, and IDs; a new walk does not recover the old history. See [Capture Testnet evidence promptly](/guides/agent-usage/execute-and-settle-agent.md#capture-testnet-evidence-promptly) before retrying. `nexus execution inspect` replays the ordered Execution history. Look for the `transferred` `OnchainToolResult` variant with `amount` and `recipient` matching the funded state and submitted input. The Execution is runtime history; the Occurrence is the durable scheduler record that must be settled. Inspect cost and settlement state: ```bash nexus task occurrence cost \ --task-id "$TASK" \ --occurrence-id "$OCCURRENCE" \ --json > occurrence-cost-before-settle.json nexus task occurrence inspect \ --task-id "$TASK" \ --occurrence-id "$OCCURRENCE" \ --json ``` If the Occurrence is `finished`, settle it into the Task: ```bash nexus task occurrence settle \ --task-id "$TASK" \ --occurrence-id "$OCCURRENCE" \ --json > occurrence-settle.json ``` Settlement records the final outcome, returns unused reserve according to the address-funded policy, and clears the Task's in-flight accounting. If the occurrence missed its deadline, use `nexus task occurrence expire`; if an Execution exceeded its workflow timeout, inspect it and use `nexus task occurrence abort-expired` only when the CLI reports that action. #### 5. Cost summary and Task cleanup Read cost again after settlement and inspect the Task: ```bash nexus task occurrence cost \ --task-id "$TASK" \ --occurrence-id "$OCCURRENCE" \ --json > occurrence-cost-after-settle.json nexus task inspect --task-id "$TASK" --json > task-after-settle.json ``` The cost view explains reserve, consumption, and refund for this occurrence. The Task is closable only when it is not finalized, its Schedule is idle, and it has no in-flight occurrences. This one-shot tutorial can then release Task resources: ```bash nexus task close --task-id "$TASK" --json ``` Do not close a Task that still has advertised, pending, recurring, or in-flight work. Use `pause`, `cancel`, occurrence settlement/recovery, and a fresh `task inspect` until the Task is idle. #### What you built End-to-end, your skill now does this on every call: 1. The invoker funds a Task reserve and schedules an Occurrence for the Agent skill. 2. The scheduler advertises the Occurrence; a leader dispatch creates its Execution. 3. The leader calls `transfer_vertex::execute` with framework-owned requirements/result inputs plus `TutorialState` and the recipient. 4. The Tool transfers the coin, satisfies its witness, and finalizes the durable `transferred` result. 5. The Execution records runtime history; the Occurrence records scheduler state and settlement; the Task owns the remaining reserve until cleanup. 6. The operator verifies the recipient/state change, settles the Occurrence, and closes the idle one-shot Task. Re-running means funding the treasury again and scheduling a new Task. Each run receives new Task, Occurrence, Execution, transaction, and object-version identities. {% hint style="warning" %} `public(package)` prevents other packages from calling `take_treasury` directly, but it does not authenticate the external actor who schedules a compatible DAG. For production asset custody, add a reviewed application capability/sender policy and keep the Tool's authorization checks aligned with the Agent skill contract. {% endhint %} #### Next steps The natural follow-up reading is: * [CLI reference: `nexus task`](/reference/cli/task.md) for Task, Occurrence, recovery, cost, and cleanup commands. * [CLI reference: `nexus execution`](/reference/cli/execution.md) for ordered Execution history. * [CLI reference: `nexus tap`](/reference/cli/tap.md) for Agent vaults and skill updates. * [Upgrade the TAP package](/guides/tap-development/upgrade-tap-package.md) for a compatible package upgrade and owner-authorized Tool-pointer change. --- # 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/guides/tap-development/execute-and-verify-transfer.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.