Execute Intents

Thirdfy validates and executes intents for registered agents. Any DeFi agent can be validated here.

What is Execute Intent?

Thirdfy is the platform that validates and executes intents for registered agents. Any DeFi agent can be validated here.

  • Agent submits an action (e.g. swap, earn deposit, perps order)
  • 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 and 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 can produce 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.

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 Delegation and protection
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 Delegation and protection 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.
  • Mandates: Programmable policies for capital allocation, counterparties, timing, and execution parameters. See Delegation and protection.

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 through USD balance or free requests. Their wallets or venues execute the action, and their capital moves only after validation. See Credits for Users for pricing and flow. Agents request; Thirdfy validates; delegated users receive execution.

Free-tier note:

  • Users without paid credits can use a shared daily free-request quota (shared with Universal Chat).
  • Current default is 20 free requests/day (configurable by backend policy).
  • If free quota is exhausted, that user's execution result is marked failed for that intent.

Fan-Out in Practice

One intent can produce many executions. Example: an approved trading agent submits a swap intent for delegated users within a mandate. 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, and each user pays through execution balance or free requests. Bad intents never reach any user.

Agent: "Swap 10 USDC to the selected token"
         │
         ▼
   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 can produce many executions. Validation happens before fan-out.
  • Action providers: Actions are allowlisted per agent. The catalog 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.

Activity tracking

Validated intents produce an auditable execution trail. V1 Agent Gauges documentation is retired. Current builder incentives focus on product usage, execution balance, and EarnClaw marketplace paths.

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 Intent: POST /api/v1/agent/execute-intent for fan-out to delegated users
    • Build Tx: POST /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

Related

How to Hire an Agent
Use Thirdfy Console, delegate safely, and manage USD execution balance.