Execute Intents

Thirdfy validates and executes intents for registered agents. Any DeFi agent can be validated here — protocol-agnostic, runtime-agnostic.

What is Execute Intent?

Thirdfy is the platform that validates and executes intents for registered agents. Any DeFi agent can be validated here — protocol-agnostic, runtime-agnostic.

  • Agent submits an action (e.g. swap, vote, claim)
  • Thirdfy validates: policy, limits, allowed actions
  • Platform signs and fans out to delegated users
  • One intent → many executions (async)

Why Thirdfy?

  • No key custody — Agent never holds user keys
  • Policy enforcement — Per-agent limits, allowlists
  • Fan-out — One intent reaches all delegated users

Two Execution Models

Thirdfy offers two ways for agents to execute actions:

ModelAPIWho constructsWho signs & broadcastsFlow
Execute IntentPOST /api/v1/agent/execute-intentThirdfy (on our platform)Each user's wallet or custody platformAgent submits → Thirdfy validates → fans out to users → each user executes
Build TxPOST /api/v1/agent/build-txThirdfyAgent or userAgent requests tx → Thirdfy validates & builds unsigned tx → agent/user signs & broadcasts

Execute Intent — Thirdfy orchestrates the full flow. Agent submits one intent; we validate, build transactions per user, and fan out. Each user's wallet (or custody platform) signs and broadcasts. One intent → many executions. Use this when you want Thirdfy to handle fan-out to delegated users.

Build Tx — Thirdfy validates and constructs a single unsigned transaction, then returns it to the agent. The agent (or user) signs and broadcasts. Thirdfy does not orchestrate execution. Use this when the agent needs to execute for a specific wallet (e.g. Model B, agent-signed flows).

What fails on-chain vs off-chain?

Failure pointWhereResult
Policy / mandate violationOff-chain (Thirdfy)Intent rejected before any tx is built
Action not in allowlistOff-chain (Thirdfy)Intent rejected
Invalid params, slippageOff-chain (Thirdfy) or on-chainRejected at validation, or tx reverts on-chain
User revokes before executionOff-chainPending executions cancelled; see Security
Tx revert (e.g. insufficient liquidity)On-chainUser's tx fails; no funds moved

Flow

Agent submits intent
         │
         ▼
   Thirdfy validates
         │
         ├── Compliant? ──► Fan out to delegated users
         │                        │
         │                        ▼
         │                  Each wallet executes
         │
         └── Rejected? ──► Intent rejected

Security & How We Protect Users

  • Intent-based security — We verify what actions are allowed, not just who holds keys. Thirdfy inserts a runtime policy enforcement layer between agents and financial infrastructure.
  • Full details — See Security for delegation modes and best practices.
  • Every intent validated before execution — Policy engine evaluates against mandate and policy. Compliant = authorized. Not compliant = rejected.
  • Verifiable enforcement records — Every authorization decision produces a traceable event; full auditability.
  • Mandates — Programmable policies (capital allocation, counterparties, timing, execution parameters). See Policy & Mandates.

Delegation & Execution Modes

  • Two execution modes: x402_custodial (Thirdfy-managed) and non-custodial (user holds keys).
  • Non-custodial (ERC-7710) — Users delegate to agents via supported wallets. Delegation is scoped and time-limited. Status tracked: active, expired, revoked.
  • How we protect users — Policy engine validates every intent against the user's mandate before execution; users retain control.

Gas for Delegated Wallets

Delegated users pay for execution — their wallets execute the action, their capital moves. Credits are consumed per execution. Gas is sponsored (included in Credits) — all transactions executed on our platform are gasless for agents. See Credits for Users for pricing and flow. Agents request; Thirdfy validates; delegated users receive execution.

Fan-Out in Practice

One intent → many executions. Example: Jeff CEO submits a swap intent ("Swap 10 USDC for TFY for all delegated users"). Thirdfy validates. If compliant, the intent fans out to 1,000 delegated users. Result: 1,000 swaps, each validated individually. Each user's wallet executes. Each user pays credits. Bad intents never reach any user.

Agent: "Swap 10 USDC → TFY"
         │
         ▼
   Thirdfy validates
         │
         ├── Compliant? ──► Fan out to User 1, User 2, ... User 1000
         │                        │
         │                        ▼
         │                  Each wallet executes (1,000 swaps)
         │
         └── Rejected? ──► No user receives the intent

Scaling

  • Simple model — One intent → many executions (fan-out); async; validation before fan-out.
  • Action providers — Actions are allowlisted per agent; swap, vote, claim, etc.; protocol defines which actions each agent can request.

Why Hiring DeFi Agents Is the Future

Agents can manage capital autonomously; the protocol validates and protects; delegated users' wallets execute. Scalable, auditable, policy-enforced. The governance layer between decision and execution.

Execute Intent → Agent Gauges

We draw the Execute Intent through the protocol. Because intents are validated and executed here, we can track activity easily and compute scores for incentives. Security governs; the same flow becomes the data source for Agent Gauges.

For Agent Creators

  1. Install Thirdfy skills (see Agent Creators)
  2. Register your agent
  3. Get allowed actions from the API
  4. Choose your model:
    • Execute IntentPOST /api/v1/agent/execute-intent for fan-out to delegated users
    • Build TxPOST /api/v1/agent/build-tx for a single unsigned tx (you sign and broadcast)
  5. Poll status (execute-intent) or sign & broadcast (build-tx)

FAQ