> 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/guides/tap-development.md).

# Custom TAP Package Development

{% hint style="info" %}
**Audience:** Nexus adopters and integrators.

**Goal:** Follow the Talus Agent Package (TAP) sequence that produces a package, Tool, DAG, skill binding, and verified execution without guessing the ownership boundaries.
{% endhint %}

This series teaches how to build, register, and operate a custom **Talus Agent Package (TAP)** skill end-to-end. Each page is short and self-contained; together they take you from an empty directory to a working Agent that calls an on-chain Move Tool which transfers SUI to a recipient address.

{% hint style="warning" %}
**Required before this guide:** Complete [Prepare for On-Chain Development](/talus-docs-v2.1.0/guides/getting-started/prepare-onchain-development.md). It establishes the public Move Registry dependencies, selected-network package IDs, and committed `Move.lock` that every TAP Move package needs.
{% endhint %}

The guides use public interfaces and ordinary Sui/Nexus commands without an additional documentation package. For the local published-bytecode test checkpoint, use the released `nexus tap test` command from [Prepare for On-Chain Development](/talus-docs-v2.1.0/guides/getting-started/prepare-onchain-development.md#local-published-bytecode-tap-tests); the same 2.1.0 CLI/SDK path remains authoritative for release and network operations.

> **Prereqs.** You should already be comfortable with the [Setup guide](/talus-docs-v2.1.0/guides/getting-started/setup.md) (CLI install, Sui wallet, `nexus conf set`) and have read the [On-chain Tool Development guide](/talus-docs-v2.1.0/guides/tool-development/build-onchain-tool.md) for Move Tool fundamentals (`UIDRequirements`, witness types, `TaggedOutput`, `OnchainToolResult`, and registration mechanics).

### What a TAP package skill is

A custom TAP package skill combines up to three things behind one registry identity:

1. A **TAP Move package** — your custom Move code: shared state objects, the witness type that ties a vertex tool to your package, and any business-logic helpers the tool needs (e.g. coin custody). At the protocol level this is optional: `register_skill` itself doesn't take a package id, so a skill whose DAG uses only off-chain HTTP tools and no on-chain state doesn't need one. This tutorial's skill uses an on-chain transfer tool, so the package contents below are required.
2. A **DAG** — the workflow definition the leader executes when the skill runs. For this tutorial the DAG has a single vertex that calls one on-chain Move tool.
3. A **skill config** (`skill.tap.json`) — declares the DAG and the skill's input, payment, schedule, fixed-Tool, and shared-object requirements. The CLI resolves the sibling `tap/` package from the config location.

A skill lives under an **Agent** (also on-chain). Mutable custody of the `Agent` object is the lifecycle authorization handle, and the registry stores the Agent's active flag plus skill records. Each skill record carries the DAG binding, simplified requirements, and a `current_interface_revision` that fresh Tasks use. `nexus tap bind` / `nexus tap register-skill` create revision `1` with the skill record, and `nexus tap update-skill` moves the active skill contract to a new revision for future Tasks.

The active skill contract has these important parts:

* **DAG binding** points to the published DAG that workflow execution should run. The concrete shared objects a skill needs, such as this tutorial's `TutorialState`, are supplied as execution inputs rather than stored in a separate endpoint-revision table.
* **`requirements.input_commitment`** is an opaque byte vector that identifies the expected input shape. When the skill artifact is created from a published DAG, the CLI derives this commitment from the DAG's entry inputs.
* **`requirements.payment_policy`** is either `UserFunded` or `AgentFunded { max_budget_mist }`; user-funded Tasks reserve MIST from the signer's Nexus SUI balance, while agent-funded Tasks draw from the Agent's payment vault.
* **`requirements.schedule_policy`** is `Once` or `Recurring { min_interval_ms, max_occurrences }` and bounds the Task schedules that may use the skill.
* **`requirements.fixed_tools`** records required Tool FQNs. The fixed-tool list rejects only an identical `(tool_registry_id, tool_fqn)` pair; the same FQN with a different stored registry ID is not rejected by that duplicate check. Skill registration then checks only whether the FQN is registered at transaction time; the pinned code does not validate the stored registry ID or DAG membership, and `update_dag` does not rerun the check. For asset-sensitive use, independently read back the DAG vertex/FQN, Tool ID, registry ID, immutable schema, authorization mode, and application policy; stronger enforcement remains unresolved.

#### What we'll build

The tutorial's skill exposes a single vertex tool that does one job: **drain a SUI treasury sitting in the TAP package's shared state into a recipient address** passed as a workflow input. The state is funded out-of-band (we'll add a `fund_treasury` helper), and each skill execution moves the treasury balance to the recipient. The workflow dispatches the walk, the leader runs the Move tool, the recipient receives SUI.

{% hint style="warning" %}
**This tutorial is intentionally minimal.** The transfer Tool uses the standard on-chain execution mode and the skill config carries an empty `fixed_tools` list, so any valid DAG dispatch against this Tool can drain the treasury — there is no package-specific caller capability or sender check. Treat the state and funds as disposable demonstration assets. A Fixed Tool records an FQN registration dependency; it is not, by itself, proof of DAG membership, registry-ID equality, substitution prevention, or asset authorization.
{% endhint %}

#### End-to-end flow

```
nexus tap scaffold        →  empty TAP package skeleton + skill.tap.json
        │
        ▼
edit Move source          →  add state object + on-chain transfer tool
        │
        ▼
nexus tap validate-skill  →  local-only checks (no chain)
        │
        ▼
sui client publish        →  publishes the Move package and creates shared state
        │
        ▼
nexus tool register       →  registers the on-chain transfer tool in ToolRegistry
        │
        ▼
nexus dag publish         →  publishes the DAG after the Tool exists
        │
        ▼
nexus tap create-skill-   →  derives the skill artifact from the published DAG
        artifact
        │
        ▼
nexus tap bind            →  creates an Agent + registers the skill atomically
        │
        ▼
fund the treasury         →  one-shot Move call that deposits SUI into state
        │
        ▼
nexus task schedule       →  creates a funded Task and its first Occurrence
        │
        ▼
nexus execution inspect   →  follows the Execution and durable Tool result
        │
        ▼
verify + settle           →  check recipient/state, settle Occurrence, close Task
```

Each arrow is one short stop on the way. The next six pages walk through them.

#### Pages

1. [Scaffold the TAP package](/talus-docs-v2.1.0/guides/tap-development/scaffold-and-package.md) — `nexus tap scaffold`, plus the Move state module the scaffold doesn't write for you.
2. [Write the on-chain transfer tool](/talus-docs-v2.1.0/guides/tap-development/onchain-transfer-tool.md) — the `transfer_vertex` Move module that the workflow invokes.
3. [DAG and skill config](/talus-docs-v2.1.0/guides/tap-development/dag-and-skill-config.md) — wire the on-chain Tool's FQN into `dag.json` and adjust `skill.tap.json`.
4. [Publish, register, bind](/talus-docs-v2.1.0/guides/tap-development/publish-register-bind.md) — publish the package, register the Tool, publish the DAG, create the skill artifact, and run `tap bind`.
5. [Execute and verify the transfer](/talus-docs-v2.1.0/guides/tap-development/execute-and-verify-transfer.md) — fund the treasury, schedule a Task, follow its Occurrence and Execution, verify the transfer, and settle.
6. [Upgrade the TAP package](/talus-docs-v2.1.0/guides/tap-development/upgrade-tap-package.md) — validate a compatible package upgrade, move the registered Tool pointer, and rerun the same DAG without changing the Tool identity.

#### What this guide does **not** cover

The TAP package CLI surface is broader than what one tutorial can show. After you finish the series, the [CLI reference](/talus-docs-v2.1.0/reference/cli/tap.md) covers:

* Vault funding and Agent-funded Task scheduling (`nexus tap vault deposit` and `nexus task schedule --agent-funded`).
* Address-funded scheduling (`nexus gas deposit` and `nexus task schedule`, the default funding mode).
* Updates for already-bound skills (`nexus tap update-skill`).
* Inspecting occurrence payment and settlement (`nexus task occurrence cost`, `nexus task occurrence inspect`, and `nexus execution inspect`).


---

# 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/guides/tap-development.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.