DeFAI means AI applied to decentralized finance

DeFAI is shorthand for decentralized finance combined with artificial intelligence. In practical terms, it describes AI interfaces, recommendation systems, agents or automated policies that help a person understand or perform DeFi actions. It does not describe one protocol design, one level of autonomy or one standard of safety.

The term is also sometimes used for decentralized AI infrastructure, such as distributed compute or model networks. That is a different subject. This guide uses DeFAI to mean AI inside a DeFi workflow: reading onchain state, comparing actions, preparing transactions or executing a narrow mandate.

The useful question is not “Does it use AI?” Ask what the system can observe, what it can decide, what it can sign, and which independent control can stop it.

Five kinds of DeFAI system

SystemTypical outputExecution authorityMain risk
Research interface Explains protocols, positions or transactions None Stale, incomplete or invented information
Transaction copilot Builds a proposed swap, deposit or withdrawal User reviews and signs A plausible explanation hides a harmful transaction
Recommendation agent Ranks opportunities or proposes an allocation User or manager approves Weak assumptions, incentives or risk comparison
Policy-bound executor Calls approved functions within explicit limits Restricted wallet or smart account Permissions exceed the intended mandate
Onchain allocator Rebalances a vault or portfolio over time Contracts plus an operator or agent Strategy, contract, oracle and liquidity failures combine

These categories can be combined. A conversational interface may sit in front of a policy-bound executor, for example. The interface should not be mistaken for the control boundary: a friendly answer does not reveal what the signing account is technically allowed to do.

The DeFAI action path

01ObserveRead wallet, protocol, market and risk state with timestamps.
02ProposeProduce a typed action with assumptions and expected costs.
03ConstrainApply asset, venue, function, size and loss limits outside the model.
04SimulateCheck the transaction path, state changes, approvals and failure cases.
05ExecuteSign only the permitted call with bounded slippage and expiry.
06ReconcileCompare intended and actual state, then alert, pause or recover.

The model belongs in the proposal stage, not at every boundary. Deterministic checks should decide whether a token, contract, function and amount are allowed. Transaction simulation can reveal an expected state change, but it cannot eliminate smart-contract, oracle, governance or network risk.

A worked example: moving a stablecoin position

Imagine that an agent finds a higher displayed supply rate in Protocol B than in Protocol A. A weak system treats the rate difference as the decision and immediately moves the position. A controlled system first records the exact contracts, rate sources, timestamp, expected holding period and all transaction steps.

It then estimates withdrawal and deposit gas, swap costs if the assets differ, liquidity, reward-token assumptions and the probability that the quoted rate changes. Policy checks reject unapproved contracts, excessive token allowances, breached concentration limits or a transaction simulation that does not match the proposal. If approval is required, the user sees the actual calls and maximum loss conditions—not only a conversational summary.

expected net benefit = projected carry difference − execution costs − exit costs − modeled risk charge

This formula is a decision frame, not a promise that every risk can be converted into one reliable number. Contract failure, governance intervention and unavailable liquidity can create losses outside a simple rate comparison.

Permissions matter more than personality

A DeFAI agent can sound cautious while holding an unsafe credential. Inspect the enforceable permission model before judging its explanations. A useful mandate answers all of the following questions:

  • Assets: which tokens can enter, leave or be approved?
  • Contracts: which exact addresses and protocol versions are permitted?
  • Functions: can the account swap, borrow, bridge, withdraw or change permissions?
  • Size: what limits apply per action, protocol, asset and day?
  • Time: when does authority expire, and how quickly can it be revoked?
  • Price: what slippage, oracle freshness and minimum-output rules are enforced?
  • Recovery: who can pause the system, unwind exposure or replace a compromised key?

Ethereum's current security guidance emphasizes access control, independent review and disaster recovery because deployed contracts and stolen assets can be difficult to repair. The same discipline should extend to any AI layer that can call those contracts.

Where DeFAI systems fail

Bad information becomes a confident action

An agent may rely on a stale API, mislabeled token, manipulated social post or incomplete protocol history. An answer that cites a source can still overreach beyond what that source proves. Important state should be verified against authoritative endpoints and assigned an explicit freshness limit.

Untrusted data behaves like an instruction

Tool-using agents may encounter token metadata, websites, governance text or other untrusted content. If that content can override the user's mandate, the system is vulnerable to agent hijacking or indirect prompt injection. Trusted instructions and untrusted data need a hard separation, and the execution policy must remain outside the language model.

The transaction succeeds but the strategy fails

A valid onchain transaction proves that a state transition occurred. It does not prove that the price was fair, the protocol was safe, the strategy was suitable or the opportunity was described completely. Read the trade-proof scope guide before treating cryptographic evidence as investment evidence.

One component fails and leaves partial exposure

Multi-step actions may cross swaps, lending markets, bridges or derivatives. One completed step and one failed step can leave an unintended asset, debt or directional exposure. Recovery logic must begin from observed onchain state rather than blindly retrying the original plan.

How to evaluate a DeFAI product

ClaimEvidence to requestWhat remains unproven
“Finds the best yield”Protocol universe, timestamps, fee model and rejected optionsFuture rates, liquidity and contract safety
“Non-custodial”Key owner, allowance scope, upgrade roles and withdrawal pathAbsence of every privileged control
“Autonomous”Callable functions, policy limits, pause path and action logCorrect judgment in new conditions
“Audited”Named code version, report, date, scope and unresolved findingsSafety after upgrades or integrations
“Verifiable”Exact statement the proof or record establishesStrategy quality and offchain completeness

How DeFAI relates to adjacent categories

Use the AI trading agents guide to inspect planning, tools and execution controls. Use onchain asset management when the question is who owns the assets, how a portfolio mandate is enforced and how performance is accounted for. The automated trading systems guide covers the wider operational loop from data through recovery.

Sources and scope

The taxonomy and worked example are editorial models for evaluating the category. They are not a certification of a product, evidence that a specific product feature is available or individualized financial advice.