Talus v2: Building Trust into Agent Execution

Key Takeaways

• Talus v2 merges an agent's permissions, budgets, verification, and scheduling into a single onchain Execution Model. Heavy computation and external data collection stay offchain, while tool permissions, result evidence, payments, and refunds are recorded onchain, making it possible to trace and settle who executed what, under which authority, and at what cost.
• Budgets are fixed before execution: costs are locked per vertex and settled only after the result passes verification, while price snapshots and refunds of unused budget contain mid-run price changes and failures. Three verification paths (basic recording, registered signing keys, and external Move contracts including ZK proofs) let each vertex apply a different level of trust.
• With the v2 mainnet, Leader deposits, tool bonds, and priority fees all converge on the $US token, placing execution records and the token economy on the same settlement layer. Talus's value must now be proven not by registered agents or one-off demos, but by whether the same Task repeatedly generates paid calls, verification decisions, and settlements.

When AI agents generate a simple answer, we can discard it and submit the query again if it is wrong or does not reflect the user's intent. Once an agent calls an external API, transfers assets, or delegates work to another agent, however, even a small error can immediately incur fees or cause asset loss. As agents gain a wider scope of action, they need infrastructure that can verify who executed what, under which authority, and how much was paid as a result. Ultimately, agents only create value when someone delegates real work to them, and delegation requires trust. The more an agent can be trusted, the more it can be given to do.

Talus's v2 addresses this problem by combining permissions, budgets, verification, and scheduling into a single Execution Model. Heavy computation and external data collection remain offchain, while the harness, tool permissions, result evidence, budget payments, asset operation and refund records are stored onchain. This allows the protocol to track and settle a single execution that passes through multiple tools.

This article first examines how permissions are embedded in a harness. It then follows a budget fixed lifecycle before execution and the verification paths through which the chain accepts offchain results.

1. Talus v2: A harness for permissions and budgets

Talus Protocol is a DAG-based workflow engine that divides a task into multiple vertices and calls the next tool based on the preceding result. Each vertex is a tool implemented as an offchain HTTP service or an onchain Move module. Every execution ends with one of several mutually exclusive output variants. For example, a task that checks a market price and submits a buy order when a condition is met can be divided into three vertices: price lookup, condition evaluation, and order submission. Each execution of the price lookup tool then ends with either a success or error variant.

The output variant determines the next branch. When needed, an execution path, called a Walk, can split into several branches that run in parallel or repeat a section under preset rules. The blockchain is the coordination layer that records state transitions in the graph. A Leader subscribes to onchain events and performs the computation by calling the required tools.

The Protocol v2 builds on the tool registry, bond deposits, Signed HTTP, and scheduled execution introduced in v1. It binds the caller, permitted tools, funding source, and verification method directly to each vertex. This turns the graph from a sequence of calls into an execution unit with its own permissions and costs.

As a result, two tasks that follow the same workflow can have different execution traces and results given independent inputs of onchain state. All asset operations are guarded by onchain code instead of trusting the offchain AI model or wallet access. External developers can test this structure through the v2 preview released on the Sui testnet in July.

This article is based on the v2.0.0 mainnet release. The specification remains under active development, and later versions may change some details.

To understand what v2 means by an agent, we need to examine the structures recorded onchain.

In v2, an agent is an onchain actor with one or more skills. These agents are onchain objects with skill guardrails under the Talus protocol smart contracts. Each skill defines which workflow to execute, with which tools, and under which conditions. For each capability record, the agent registry manages its active status, linked graph, required tools, interface revision, and number of scheduled tasks. The interface revision changes when the specification is updated.

A Verifier evaluates a tool's submitted result against predefined conditions. Each tool's verifier configuration is recorded in the tool registry, whether verification uses the built-in registered-key method or an external Move contract, along with the invocation target, required shared objects, and supported submission types for success and error results. Registered signing keys are managed in the network authentication registry. This allows the system to find the appropriate verification logic.

Permission management begins when an agent capability declares tool registry identifiers and names as its fixed tools. The system checks this list against the tool registry when the capability is registered. At execution time, the permission object binds the capability identifier, interface revision, graph, and current vertex. This limits the approval to a single execution or a specific scheduled task.

Even when an agent has several capabilities, only the permitted tool set applies to that execution. Scheduled tasks do not share broad, long-term authority. Instead, an approval tied to a task identifier is copied into the execution object created for each occurrence.

When execution begins, the execution object records the selected graph, caller, agent capability and revision, scheduled task, and occurrence. Walks, per-vertex evaluations, and terminal states for each Walk, including success, failure, join, abort, and cancellation, accumulate under a single execution identifier. This allows the system to trace the result produced by a specific capability revision.

Protocol state is versioned at every root object, and each execution pins the immutable package configuration captured at creation. The protocol can therefore upgrade without breaking live agents, while existing tool and agent records migrate to the new package versions. The capability revision in the registry must be linked onchain to the reference captured at execution time. Only then can the system reconstruct the permissions and results of a past execution after the protocol has been updated.

2. Budgets fixed before execution are the basis of cost control

This section examines how the protocol handles costs. It fixes the budget before execution and records spending at each step.

An agent capability declares its funding and scheduling policies together with the tools it will use. Either the user or the agent can pay the execution cost. Under the self-funded model, the agent designates a Vault, a dedicated account funded in advance, as the payment source and sets a maximum budget for each capability.

Cost handling follows a two-step process. The system first locks a budget for the vertex to execute and pays the tool after the result is finalized. Each tool behind a vertex has a cashier with a mandatory fixed SUI price, where zero represents public access, and optional finite credit and time pass products. The tool can assign credits or passes to agents or users. When execution begins, the protocol will select the lowest cost supported by the tool and execute only after the invocation cost is locked. Each execution has an onchain execution payment that stores the budget from task reserve. The payment object will be used as the source of funds if the fixed Sui price is selected.

The snapshot price continues to apply even if the tool changes its price during execution. This protects the execution from price changes after it has started. Finite credits and time passes are prepaid usage rights that the tool owner can sell or grant to agents and users. A time pass expires and a finite credit has a limited number of uses; either settles the vertex without drawing on the execution budget.

If a model call fails after a price lookup, or if a transaction expires, the system settles only the costs already incurred and releases the unused locked budget. The accounting record therefore reflects a failure at the vertex where it occurred.

Recurring execution is managed through three layers: Task, Schedule, and Occurrence. One-time jobs enter a queue, while recurring jobs create their next occurrence under a periodic policy with a defined start time and interval. A scheduled Task records the budget for each Occurrence and the remaining reserve. A Task can also attach a priority fee in $US, giving its occurrences precedence in Leader dispatch; Leaders later withdraw their $US share from the priority fee vault.

When an Occurrence begins, part of the reserve becomes its execution budget. After completion, the amount is settled or refunded, and the remaining balance carries over to the next Occurrence. The reserve object stores the history of each Occurrence to prevent the same budget from being allocated twice. An operator can replenish the reserve or cancel the remaining Schedule, which keeps the budget for a long-running Task under per-Occurrence control.

Talus also separates result delivery from payment. Even after a tool submits its result, settlement or expiry occurs only after verification. The execution payment object records the maximum locked budget, actual spending, and refunds for each vertex. After execution ends, anyone can still trace which tool spent how much and how much was returned.

3. Verification paths connect onchain state with offchain computation

How does a blockchain decide whether to accept a result produced offchain? The chain does not perform the computation itself. It remains as a coordination layer that synchronizes execution order, permissions, and cost states. Trust therefore depends on the path through which an offchain result is submitted and the evidence attached to it.

The Leader introduced above serves as the coordinator and connects the onchain and offchain components. It detects onchain events, dispatches the next vertex, calls the designated tool, and submits the result back to the chain. In the most recent version, Leaders must register onchain and stake with $US token. The protocol can slash this deposit for violations. Each execution request assigns a primary and a backup Leader so that the backup can take over if the primary fails to respond.

There are three paths for submitting offchain results to the chain:

1. A basic path that records the result as submitted.
2. A signed path that submits the request and response with a previously registered signing key.
3. An external verification path in which a Move contract checks predefined conditions.

The signed path proves integrity: that the submitted outputs were computed by the registered tool from the legitimate inputs. An external verification contract checks the output with auxiliary data against onchain state. This solution can verify the tool with a computed zero-knowledge proof against the onchain commitment, or other user-customized constraints can guard the correctness of the tool outputs. The verifier setting returns an acceptance or rejection result and a hash that summarizes the reason for its decision. Each vertex in the same graph can therefore use a different level of verification.

If the Verifier accepts the result, the next vertex receives the data. If the result is rejected or expires, the system processes the failure and refunds the unused budget. The verification decision directly controls settlement.

Both the decision and settlement are recorded as Sui transactions. With a transaction hash and execution identifier, a third party can determine which result came from which vertex of a specific execution.

4. What Talus/acc tested

Source: Talus

Talus ran the first four-week cohort of Talus/acc with the Sui Foundation and Cicada Capital and announced the winners in July. The program supported teams that combined onchain AI agent frameworks with execution-focused use cases. More than 50 teams worldwide applied across RWA, AI, DeFi, and gaming, and seven reached Demo Day. These are domains where the people on the other side have real money at stake and no reason to trust an operator's AI infrastructure simply because the operator says it is sound. The top three teams were:

• 1st place, SuperStake (@superstakefun): An Agentic Game Engine in which AI agents autonomously create and play games in real time. Human spectators watch the matches and predict or bet on the outcomes.
• 2nd place, Agama (@agamafinance): A yield infrastructure layer for real-world asset tokens. It provides underwritten credit vaults and a synthetic dollar to connect private credit markets with DeFi demand.
• 3rd place, Noodles Finance (@NoodlesFi): A DeFi application for the Sui ecosystem that provides market lookup, position entry, and yield tracking.

These projects provide an initial test of whether Talus can control a sequence of actions that includes price lookup, decision-making, asset deployment, and changes to game state. The cohort used v1, however. The next test is whether these projects migrate fully to the permission and budget system in v2 and produce meaningful mainnet usage. The first ecosystem migrations to v2 are already underway.

5. Repeated execution will determine the value of Talus

Talus v2 combines an agent's permissions, budget, verification, and Schedule into a single onchain state and model. The permitted actions are fixed before execution. Budget locks and settlement limit spending, while evidence and verification decisions record the basis for accepting a result.

The v2 mainnet release denominates Leader deposits, tool bonds, and priority fees in Talus's $US token and routes all execution requests through the scheduler as a single entry point.

The execution graph defines the protocol's structure, while the $US token defines stake and priority fees. This places Talus's execution records and its token economy on the same settlement layer. This is the protocol's trajectory in miniature: v1 proved the model works, v2 makes it production-grade infrastructure, and the convergence of deposits, bonds, and fees on a single token is the groundwork for the next stage, a decentralized economic engine.

The remaining question is whether this structure can prove itself through repeated execution beyond demos. As the cost of creating an agent falls, the number of registered agents or prototypes becomes a weak measure of actual infrastructure use. The more relevant measure is how often the same Task produces paid calls, verification decisions, and settlement across multiple Occurrences. It also matters how often agents that pay real costs and tools that receive revenue interact within the same Task.

Per-vertex success and refund rates, the share of executions processed through external verification contracts, and the number and deposit distribution of independent Leaders can separate simple registration from actual use.

Infrastructure proves its value when the same Task runs reliably each day, rather than ending with a one-time demo. The main indicators are how long recurring occurrences continue, how often paid vertices run, and whether operators continue to replenish their reserves.

Mainnet v2 is now live, and the specification will continue to evolve. Talus has entered the stage where production use must validate its design. The volume and duration of recurring executions on these harnesses will show whether an onchain AI agent ecosystem can develop around Talus.