Delegation & protection

Thirdfy governs who may act and whether each action is allowed before wallets sign or venues accept orders. Delegation scopes, custody modes, venue readiness, and policy checks apply whether you integrate via CLI, MCP, or REST.

Start here (most builders)

If you are building your own agent (solo automation, not fan-out to thousands of user wallets), use agent_wallet + email login. This is the simplest production path.

No MetaMask EIP-712 delegation grant on this lane. Email proves agent ownership; Thirdfy still runs preflight, credits, and policy before every write.

Hosted agents on EarnOrg use this same lane.

Walkthrough: Quick start — simplest dev path. CLI: Authentication. MCP: Onboarding.

Agent policy limits

Every agent key carries a policy. Thirdfy checks it on every write, on every surface (MCP, CLI, REST, Console), whatever the model asks for. It applies to agent_wallet agents too, which need no delegation grant.

A write over the daily limit is refused with blockedReason: POLICY_DAILY_LIMIT, plus dailyLimitUsd, dailyUsedUsd and remainingUsd. An action outside the allowlist returns 403.

Policies are set through Thirdfy's control plane, not by the agent. Hosted platforms such as EarnOrg set them from their deploy settings.

Which model should I use?

Pick the lane that matches your use case. For solo agent_wallet + email (no MetaMask grant), use Start here (most builders). Use the chart below when you need user wallet delegation, fan-out, or a venue-specific signer.

flowchart TD
  A["What are you building?"] --> U{"Primary use case"}
  U -->|"Solo agent you run"| AW["agent_wallet + email login"]
  U -->|"User external wallet"| B{"Venue or chain"}
  U -->|"Many delegated subscribers"| G["execute-intent + mandates"]
  B -->|"EVM swap, earn, bridge"| C["Gator / ERC-7710"]
  B -->|"Hyperliquid perps"| D["HL API wallet + fund execution wallet"]
  B -->|"Polymarket orders"| E["Privy signer + CLOB credentials"]
  B -->|"CEX e.g. Bitfinex"| F["credentialRef API keys"]
  AW --> H["preflight, then walletExecute or run"]
  C --> H
  D --> H
  E --> H
  F --> H
  G --> H

Why delegation for autonomous agents

Autonomous agents need bounded authority to act on user capital. Users retain custody. Thirdfy validates every intent before execution. The same model applies when a human delegates to an agent and when a publisher agent fans out actions to many delegated subscribers through execute-intent.

Without delegation and policy:

• Agents could not scale to thousands of delegated wallets safely.
• Users could not revoke or time-limit authority.
• Venues with different signer models (EVM, perps API wallet, CLOB) would not have a single governance layer.

Delegation establishes permission. Preflight and the policy engine enforce it on every write.

Two layers of protection

Hosted platforms such as EarnOrg, a separate hosted agent platform that integrates with Thirdfy for execution, may add a third layer before production launch: template evals and launch validation on the EarnOrg side. A production-ready agent can still fail Thirdfy preflight on a bad trade. Verification at launch and verification per action are complementary.

From intent to execution

Every write follows the same governance lifecycle:

Agents reason in natural language but broadcast structured transactions. The risk is mismatch: wrong token, wrong amount, unintended route, or missing venue setup. Thirdfy blocks before sign or broadcast when policy or readiness fails.

Independent governance gate

The agent's model proposes. Thirdfy API validates. The runtime does not approve its own writes.

• Hosted runtimes on EarnOrg (and similar partner platforms) run their own schedule and decision loop. EarnOrg hosts the agent; adapters call Thirdfy preflight and execute for each write. The runtime does not self-check policy.
• CLI and MCP are connectors. Policy, delegation, and credits live in the Thirdfy API, not in your agent repository.
• Fail-closed by default. If verification fails, nothing broadcasts.

Where Thirdfy fits

┌──────────────────────────────────────────────────────────────────────────────┐
│     SECURITY — Thirdfy as Governance Layer Between Agents and Capital        │
└──────────────────────────────────────────────────────────────────────────────┘

  ┌──────────────────┐     ┌──────────────────┐     ┌──────────────────┐
  │   DEVELOPERS     │     │     THIRDFY      │     │  USERS &         │
  │   (Agent         │────▶│  GOVERNANCE      │────▶│  ENTERPRISES     │
  │   Creators)      │     │  LAYER           │     │  (Delegated)     │
  │                  │     │                  │     │                  │
  │  Submit intents  │     │  • Validate      │     │  Delegate,       │
  │                  │     │  • Enforce policy│     │  set mandates,   │
  │                  │     │  • Audit trail   │     │  execute         │
  └──────────────────┘     └──────────────────┘     └──────────────────┘
         │                            │
         │     No intent reaches      │
         │     users without          │
         └────► validation ◄──────────┘

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.

• Every intent validated before execution. The policy engine evaluates against mandate and policy. Compliant means authorized. Not compliant means rejected.
• Verifiable enforcement records. Every authorization decision produces a traceable event.
• Mandates. Programmable policies for capital allocation, counterparties, timing, and execution parameters.

Thirdfy validates action params, policy, and mandate. It does not replace your own strategy review of what the agent was asked to do in natural language.

Signing moments

What does the user sign? Depends on execution mode:

For non-custodial flows: users sign an EIP-712 delegation message to authorize an agent within scope and time limits. At execution time, the wallet signs the actual on-chain transaction. Thirdfy never holds signing keys.

Delegation modes

Gator and ERC-7710 lifecycle

Thirdfy uses a Gator-compatible ERC-7710 delegation model (delegationModel=gator_erc7710) for external wallet authority:

1. delegation create — API builds a Gator-style payload with erc20PeriodTransfer caveats for the owner wallet to sign.
2. Wallet sign — Owner signs with MetaMask or another supported wallet. Private keys never leave the wallet.
3. delegation activate — Persists the signed delegation, manager, executor/session account, expiry, and permission metadata.
4. delegation inspect / balance — Shows status, expiry, revocation, executor, and remaining period allowance.
5. Execute — hybrid, thirdfy, or compatible paths run only when the active binding and on-chain caveats cover the requested action.

CLI vs MCP: thirdfy-agent delegation create → wallet sign → delegation activate is one shell flow. MCP uses separate tools (delegationCreate, delegationActivate, etc.). See MCP execution tools.

CLI alias: delegation grant maps to the create/sign/activate flow.

Full command reference: Agent CLI reference.

Console mandate

The Console mandate is a separate grant from agent delegation. It lets Thirdfy Console, its Command chat and its Automations act from your wallet. It is an ERC-7710 grant per chain, with a daily USD cap and an expiry.

Revoking the Console mandate does not touch any agent delegation, and the reverse.

MetaMask integration

Thirdfy supports MetaMask Smart Accounts and scoped wallet permissions for production delegation flows. The Jeff Agent with MetaMask pilot validated end-to-end authorize flows: users grant scoped delegation, agents execute under policy, and users can revoke.

Wallet apps vs API: Consumer wallets may request permissions through ERC-7715-style smart account kits. The Thirdfy API exposes Gator/ERC-7710 delegation payloads for create, activate, and verify. Both aim at scoped, time-limited authority without Thirdfy holding user keys.

Operators: Operate with Console. Builders: CLI walkthrough below and Delegation and JSON.

Execution lanes (runMode)

agent_wallet is not a delegated user flow. When runMode is agent_wallet and the identity is agent-owned, the API executes from the agent wallet and bypasses subscription/delegation binding checks. Policy, credits, and funding gates still apply.

Approval patterns

Fanout and directory checks

Publisher fanout. One registered agent can act for many delegated subscribers under mandate. See Execute intents for the execute-intent model.

Directory readiness. Apps and operators should call authenticated directory routes (readiness, delegation-status, preflight) before showing execute controls. The API resolves agentApiKey server-side in validation-only lanes so browsers never need agent secrets.

Venue-specific delegation boundaries

Details per venue: Integrations.

Before broadcast (on-chain writes)

For EVM spot and earn paths, Thirdfy applies additional safety before sponsored broadcast:

• Quote broadly, execute narrowly. Compare routes, then build only the best executable path for the current chain, wallet mode, and provider.
• Simulation where possible. Read-only eth_call or gas estimation before handing calldata to the wallet when the provider supports it.
• Unknown providers fail closed. Actions must be registered in the capability matrix for the target chain and execution mode.

Off-chain venues (Hyperliquid, Polymarket, CEX) use credential resolution, readiness, policy profiles, and venue-specific setup checks instead of Gator calldata redemption.

Mandates and policy engine

Mandates are user-defined policies that govern what actions an agent can perform. When you delegate, you set a mandate. Every intent is validated against it.

1. Agent submits intent.
2. Policy engine evaluates against mandate and protocol constraints.
3. Compliant = authorized. Intent fans out or executes.
4. Not compliant = rejected. No execution.

You can control capital allocation, counterparties, timing, and execution parameters.

Revocation

Users can revoke delegation at any time. Revocation stops future authorizations. Pending executions (tx not yet signed) are cancelled. Transactions already broadcast complete. Every revocation is recorded for audit.

CLI walkthrough

Typical delegated execution sequence:

thirdfy-agent delegation create --json ...
# User signs EIP-712 grant in wallet
thirdfy-agent delegation activate --json ...
thirdfy-agent preflight --json ...
thirdfy-agent run --json ...
thirdfy-agent intent-status --intent-id <id> --json

See Delegation and JSON for automation details.

Custody boundary

Does Thirdfy custody assets? No. Thirdfy never holds user funds in a pooled account.

Funds sit in user-owned wallets. For x402 custodial flows, funds sit in a per-user provider wallet the user owns. Thirdfy validates intents; the key holder executes.

Venue readiness

Do this before your first live write, not after a runtime failure.

1. Pick the provider from Integrations (Hyperliquid, Polymarket, Morpho, etc.).
2. List prerequisites with MCP getProviderActions or CLI thirdfy-agent actions --json for that provider and chain.
3. Run preflight validation-only with the action you plan to execute.
4. Complete setup (allowances, Bridge2 funding, CLOB credentials, CEX keys) per the venue page.

Trading, yield, prediction, and CEX actions each have different setup. The catalog and provider tools are the source of truth for prerequisites.

Fail-closed policy

If identity, delegation, policy, or catalog validation fails, writes block with explicit reasons. Reads that are allowlisted for anonymous or bootstrap modes remain constrained by tool authProfile.

What preflight checks

Use thirdfy-agent preflight --json, MCP preflight tools, or directory preflight for validation-only runs before live writes.

Common blocker families

Audit and traceability

Thirdfy records authorization decisions across the stack:

• Delegation lifecycle. Create, activate, inspect, revoke events and binding status.
• Preflight outcomes. Validation-only runs before writes (CLI, MCP, directory).
• Execution and credits. Completed actions with provider attribution on credit debits.
• Fanout context. Subscriber scope on execute-intent when a publisher acts for many wallets.

Use these records for operator review, support, and compliance workflows.

Security

Thirdfy does not custody or control user funds. Our security model focuses on protecting delegation permissions, policy enforcement, API integrity, and system availability.

• User and agent wallets hold keys. Thirdfy validates intents and routes execution when policy allows.
• Delegation grants are scoped and revocable. Preflight fails closed when binding or mandate checks fail.
• API keys, agent credentials, and venue secrets are handled per product auth docs. Do not embed secrets in agent repos.

Report issues: security@thirdfy.com or Discord.

Service uptime

Thirdfy targets 99.9% monthly uptime for MCP services and public APIs, excluding scheduled maintenance. Uptime is measured as successful API request availability from independent monitoring endpoints. Service credits or other remedies for SLA breaches are defined in enterprise agreements for affected customers.

Best practices

• Scope delegation. Use time-limited, action-scoped mandates.
• Preflight before writes. Run validation-only checks in CI and before production cron cycles.
• Review allowlists. Ensure agent actions match your risk tolerance.
• Monitor activity. Check execution history, credit usage, and delegation status.

Wallet glossary

Related

• World ID delegation
• Execute Intents
• Delegation API
• Agent CLI
• Thirdfy MCP
• Integrations
• EarnOrg on Thirdfy
• Integrations