Use Cases/DeFi Agents

Your AI agent swapped $2M into an unaudited liquidity pool. The transaction confirmed in 12 seconds. There is no undo button.

DeFi agents execute token swaps, bridge assets, and provide liquidity at machine speed. Veto intercepts each wrapped on-chain tool call before execution, enforcing swap limits, protocol allowlists, and approval workflows. Because on-chain, there is no chargeback.

MiCA (EU)TFRFATF Travel Rule

On-chain is irreversible

In traditional finance, a wire transfer can be recalled within hours. A credit card charge can be disputed for 120 days. On a blockchain, once a transaction confirms, it is final. There is no dispute process, no chargeback mechanism, no compliance officer who can reverse it. For AI agents operating in DeFi, authorization before execution is not a feature. It is the only line of defense.

The cost of ungoverned DeFi agents

DeFi already has bridge exploits, compromised keys, oracle mistakes, and governance attacks. Autonomous agents add a new failure mode: a model can approve allowances, rebalance positions, or call contracts at machine speed without a second signer unless the tool boundary says no.

Regulatory exposure compounds the technical risk. MiCA entered full application on December 30, 2024, requiring crypto-asset service providers to maintain internal control mechanisms and risk management frameworks. Regulation (EU) 2023/1113 applies Travel Rule information requirements to covered crypto-asset transfers where an EU crypto-asset service provider is in scope, with important exceptions for person-to-person transfers without a CASP. FATF Travel Rule expectations are moving into virtual-asset workflows. An AI agent that moves tokens without originator, beneficiary, approval, and policy evidence creates regulatory exposure with every transaction.

Irreversible execution

An agent swaps into a low-liquidity pool. Slippage turns a routine rebalance into avoidable loss. On-chain, the transaction is final. No recall, no dispute, no reversal.

Smart contract risk

An agent interacts with an unaudited contract that drains its token approvals. The contract was deployed 3 hours ago. The agent did not check.

Regulatory exposure

An agent executes cross-border token transfers without Travel Rule compliance. MiCA Article 68 requires internal controls for crypto-asset services. The decision record is missing.

How Veto protects DeFi operations

Veto sits between the AI agent and your on-chain execution path. Each governed tool call, whether swap, bridge, liquidity provision, or contract interaction, is intercepted, evaluated against your policies, and either allowed, denied, or routed for human approval. The governed path applies this boundary.

Token swap authorization

A trading agent receives a signal to swap $500,000 of USDC for ETH on Uniswap. Valid strategy, reasonable market conditions. Without guardrails, the swap executes immediately with whatever slippage the DEX returns. With Veto, the transaction is evaluated: amount exceeds the $50,000 auto-approval threshold, routes to the trading desk for review. The reviewer checks whether pool depth can support the trade before signing.

Cross-chain bridge controls

An arbitrage agent identifies a price discrepancy and initiates a $200,000 bridge transfer from Ethereum to Arbitrum via a bridge protocol. Veto checks the bridge protocol against the approved list, validates the destination chain is permitted, and confirms the value is within bridge transfer limits. A transfer to an unapproved bridge protocol is blocked outright.

Liquidity provision guardrails

A yield farming agent wants to provide $1M in liquidity to a new pool that launched 6 hours ago. Veto blocks the action: pool age is below the 7-day minimum threshold, and the position size exceeds the per-pool cap. The agent is redirected to established pools that meet policy criteria.

Contract interaction controls

An agent attempts to call approve() on an ERC-20 contract with an unlimited allowance (type(uint256).max). Veto blocks unlimited approvals by policy. The agent must specify an exact amount, reducing exposure if the spender contract is compromised.

DeFi agent policies

Policies are YAML, version-controlled, and evaluated locally in your process on the enforcement path.

defi_swap_policy.yaml
rules:
  # Cap swap amounts
  - name: large_swap_approval
    description: Swaps over $50K require trading desk approval
    tool: swap_tokens
    when: args.amount_usd > 50000
    action: require_approval
    message: "Swap of ${{args.amount_usd}} exceeds $50K auto-approval limit"
    approvers: ["trading-desk"]

  # Enforce slippage tolerance
  - name: slippage_cap
    description: Block swaps with excessive slippage tolerance
    tool: swap_tokens
    when: args.max_slippage > 0.03
    action: deny
    message: "Slippage tolerance {{args.max_slippage}} exceeds policy maximum"

  # Token allowlist
  - name: approved_tokens_only
    description: Only trade approved tokens
    tool: swap_tokens
    when: args.token_in NOT IN ["USDC", "USDT", "ETH", "WETH", "WBTC", "DAI"]
    action: deny
    message: "Token {{args.token_in}} is not on the approved trading list"
defi_bridge_policy.yaml
rules:
  # Approved bridge protocols only
  - name: bridge_allowlist
    description: Only use audited bridge protocols
    tool: bridge_assets
    when: args.bridge_protocol NOT IN ["stargate", "layerzero", "wormhole", "across"]
    action: deny
    message: "Bridge protocol '{{args.bridge_protocol}}' is not approved"

  # Bridge value cap
  - name: bridge_value_limit
    description: Large bridge transfers require approval
    tool: bridge_assets
    when: args.amount_usd > 100000
    action: require_approval
    message: "Bridge transfer of ${{args.amount_usd}} exceeds $100K limit"

  # Block unlimited token approvals
  - name: no_unlimited_approvals
    description: Block unlimited token allowances on governed calls
    tool: approve_token_spending
    when: args.amount == "unlimited"
    action: deny
    message: "Unlimited token approvals are prohibited by policy"

Integration with DeFi agent frameworks

Veto wraps your existing tool implementations. Your DEX router calls, bridge SDK integrations, and contract interaction functions stay outside the policy surface. The SDK intercepts at the tool boundary.

defi_agent.ts
import { Veto } from "veto-sdk";

const veto = new Veto({ apiKey: process.env.VETO_API_KEY });

// Existing DeFi tools stay behind the policy check
const defiTools = {
  swap_tokens: async (args: {
    token_in: string;
    token_out: string;
    amount_usd: number;
    max_slippage: number;
    dex: string;
  }) => {
    return await dexRouter.executeSwap(args);
  },

  bridge_assets: async (args: {
    token: string;
    amount_usd: number;
    source_chain: string;
    dest_chain: string;
    bridge_protocol: string;
  }) => {
    return await bridgeSDK.transfer(args);
  },

  provide_liquidity: async (args: {
    pool_address: string;
    amount_usd: number;
    token_a: string;
    token_b: string;
  }) => {
    return await liquidityManager.addPosition(args);
  },
};

// Wrap each tool with Veto
const protectedTools = veto.wrapTools(defiTools, {
  policy: "defi",
  context: { agent_id: "yield-optimizer-v3" },
});

// Use protectedTools in your agent framework
// ElizaOS, Virtuals GAME, Olas, LangChain: supported

The authorization check adds local decision-path overhead. Policy evaluation happens locally in your process.

Regulatory evidence mapping

DeFi regulation is crystallizing globally. Veto policies map to the requirements your review team cares about.

MiCA (EU Markets in Crypto-Assets)

Full application since December 30, 2024. Requires crypto-asset service providers to maintain internal control mechanisms, risk management frameworks, and client asset segregation.

  • Veto policies serve as documented internal control mechanisms
  • Decision records provide risk management documentation
  • Per-agent, per-tenant policy scoping supports asset segregation

TFR (Transfer of Funds Regulation)

Applies Travel Rule originator and beneficiary information requirements to covered crypto-asset transfers involving in-scope EU CASPs.

  • Bridge and transfer tools can require metadata fields before execution
  • Audit logs capture full transfer context for evidence reporting
  • Policy rules can block transfers missing required Travel Rule data

FATF Recommendation 16

Travel Rule expectations are moving into virtual-asset workflows. Veto records the transfer context reviewers need before an agent signs.

  • Cross-border transfer policies enforce jurisdiction-specific rules
  • Approval workflows route high-risk transfers for evidence review
  • Exportable decision records support regulatory examination

Common DeFi agent policies

Block

  • Swaps exceeding daily limits
  • Interactions with unaudited contracts
  • Unlimited token approvals
  • Bridge transfers to unapproved chains
  • Liquidity to pools under minimum age
  • Swaps with slippage above cap

Allow

  • Swaps within threshold limits on approved DEXs
  • Transfers between approved chain pairs
  • Liquidity to established pools
  • Token approvals with exact amounts
  • Balance and price queries

Require Human Approval

  • Swaps above configurable threshold
  • First interaction with new protocol
  • Bridge transfers above value cap
  • Liquidity positions above pool limit
  • Token approvals above spending cap

Where the risk lands

Allowances

Unlimited approvals and stale delegates let one destructive call become an account-draining path.

Contracts

Unknown contracts, proxy upgrades, and chain mismatches need allowlists before execution.

local

Policy evaluation time. Auto-approved transactions proceed with no Veto Cloud round trip.

Veto vs alternatives

CapabilityVetoPrompt-basedSmart contract auditsForta and monitoring
Pre-execution enforcement
Swap amount limits
Protocol allowlistsPartial
Human review approvals
Slippage enforcement
MiCA/TFR decision recordsPartial
Argument-level control
Agent-agnosticPer modelN/A
Open source core

What Veto does not do

Veto authorizes the agent's decision to interact. It does not audit smart contract code, prevent MEV extraction, prove protocol solvency, or reverse executed transactions. Combine Veto with contract audits (CertiK, Trail of Bits), runtime monitoring (Forta), and risk management (Chaos Labs) for defense in depth.

Frequently asked questions

Can Veto help block my agent from interacting with a rug-pull contract?
Veto denies governed interactions with contracts not on your allowlist. This is the enforceable boundary: if the contract address is not pre-approved, the call is denied before submission. Veto does not predict future exploits of contracts on your allowlist; combine it with contract audits and runtime monitoring.
How does Veto handle MEV and sandwich attacks?
Veto can enforce maximum slippage tolerances before the transaction is submitted. If your policy caps slippage, governed swaps above that tolerance are denied before submission. Veto does not operate at the mempool level and does not use private transaction relays like Flashbots Protect. It blocks governed transactions that violate the policy before submission.
Does Veto work with ElizaOS, Virtuals GAME, and other crypto agent frameworks?
Yes. Veto wraps tool functions at the call boundary, not the framework. ElizaOS, Virtuals GAME, Olas, and raw LangChain/OpenAI/Anthropic clients fit when your code dispatches the tools. The authorization check happens before your tool implementation executes.
Does Veto make my protocol pass MiCA review?
No single tool makes a protocol pass MiCA review. MiCA requires organizational governance, risk management frameworks, client asset segregation, and ongoing reporting: most of which are operational, not technical. What Veto provides is the runtime control path: documented policies, decision records, and approval workflows that your review team can point to as evidence of internal controls under MiCA Article 68.
How does policy evaluation latency affect on-chain execution?
Core policy evaluation runs in-process before the transaction leaves your application. Auto-approved transactions can stay on the local decision path. Only transactions routed for human approval introduce intentional delay: you are choosing to pause before a high-risk on-chain action, not adding accidental latency.

Related use cases

On-chain is forever. Authorize before you execute.

One blocked unauthorized swap is the control the treasury desk needs.