Build DeFi protocols that use AI for the decisions that change constantly.

DeFi protocols that use hardcoded parameters for dynamic market conditions will eventually get those parameters wrong.

Traditional DeFi protocols use fixed parameters: 150% collateral ratio, fixed interest rate curves, static liquidation bonuses. These parameters are set by governance and updated slowly. AI-enhanced DeFi protocols can adjust these parameters dynamically based on market conditions, collateral volatility patterns, liquidity depth and user behaviour — creating protocols that are more capital-efficient in stable conditions and safer during market stress. The challenge is trust: on-chain smart contracts cannot simply call a centralised AI model. The AI computation must be verifiable — either via ZK proofs, trusted execution environments (TEE) or off-chain computation with on-chain challenge mechanisms.

The AI-DeFi engineering stack.

System Layers

• AI Computation Layer: Off-chain ML models, inference infrastructure, model versioning
• Verification Layer: ZK proofs for computation, TEE attestation, optimistic verification
• Oracle Layer: AI-computed values as oracle inputs, price feeds, risk scores
• Smart Contract Layer: Parameter consumption, dynamic adjustment logic, safety bounds
• Monitoring Layer: Model performance, parameter impact, safety metric tracking

Core Technical Capabilities

• AI Risk Assessment

  ML models that compute collateral risk scores based on: asset volatility, liquidity depth, correlation with other collateral, historical drawdown patterns. Scores update continuously and feed on-chain as oracle values.

• Dynamic Parameter Optimisation

  Reinforcement learning or optimisation models that recommend collateral ratios, interest rate curve parameters and liquidation bonuses based on market conditions — with governance-approved bounds that the AI cannot exceed.

• AI Liquidation Engine

  ML models that optimise liquidation strategy: which positions to liquidate in what order to minimise bad debt, optimal liquidation bonus to clear positions quickly, prediction of liquidation cascades during market stress.

• AI Yield Optimisation

  Portfolio rebalancing models that optimise yield across protocols given current rates, gas costs, lock-up periods, liquidity constraints and user risk preferences.

• Verifiable AI Computation

  ZK proofs that prove AI model execution was correct without revealing model weights. Trusted Execution Environment (TEE) integration via EigenLayer or Lit Protocol for verified off-chain computation.

• DeFi Fraud Detection

  ML models that detect wash trading, flash loan manipulation, governance attacks and sybil behaviour on-chain — producing fraud risk scores that protocols can consume for access control.

How we think about AI in DeFi.

AI in DeFi is only useful if the results can be trusted on-chain. Verifiability is the first engineering problem, not the last.

• Off-chain computation, on-chain consumption

  Smart contracts cannot run ML models directly — they are too computationally expensive and the environment is not suited for floating-point arithmetic. The practical architecture: ML models run off-chain, results are formatted as oracle values that smart contracts consume. The challenge is: how does the smart contract trust the oracle value? This is the ZK proof or TEE problem.

  Axiom:

• Governance bounds prevent AI from exceeding safety limits

  An AI model that can set any collateral ratio from 0% to infinity is a liability. The correct design: governance sets the allowed range (e.g., collateral ratio between 120% and 200%), the AI model recommends within that range based on current conditions. The model cannot exceed governance-approved bounds regardless of what it computes.

  Axiom:

• Model updates must be governed like contract upgrades

  Updating an ML model that determines liquidation parameters is equivalent to upgrading a core DeFi contract — it affects all users and their funds. Model updates should follow the same governance process as contract upgrades: proposal, community review, timelock, deployment. Silent model updates are not acceptable for protocols managing user funds.

  Axiom:

• Simulation before production deployment

  Every AI-computed parameter change should be simulated against historical data (what would have happened to protocol health if this model had been running?) and against stress scenarios (what happens to protocol health if ETH drops 40% in one hour with the AI parameters?) before deployment.

  Axiom:

AI-DeFi architecture decisions.

• Verifiability approach?

  Impact: TEE via EigenLayer for most production use cases — sufficient trust guarantees with reasonable complexity. ZK proofs for the specific computations where trustless verification is worth the proving cost (simple models, high-value parameters).

  • ZK proofs (zkML) — most trustless, proving complex models is slow/expensive
  • Trusted Execution Environment (TEE) — hardware-based trust, EigenLayer AVS
  • Optimistic verification — challenge period, practical for non-latency-sensitive
  • Centralised oracle with multi-sig — pragmatic, lower trust guarantees

• ML model complexity?

  Impact: Lightweight ML (XGBoost, linear models) for DeFi parameters — they are fast, auditable and sufficient for risk scoring. Deep learning only when accuracy improvements justify verifiability complexity.

  • Simple rules-based (decision trees) — verifiable, auditable, less adaptive
  • Lightweight ML (logistic regression, XGBoost) — fast inference, easier to verify
  • Deep learning — highest accuracy, hardest to verify, slow inference
  • Reinforcement learning — adaptive, explores parameter space, non-deterministic

• Update frequency?

  Impact: Event-triggered + periodic: update parameters when market conditions change significantly (volatility spike, liquidity drop) plus periodic scheduled updates. Avoids unnecessary updates in stable conditions.

  • Per-block — maximum responsiveness, high gas cost, complexity
  • Per-epoch (hourly/daily) — balance responsiveness and cost
  • Event-triggered — update on significant market moves
  • Governance-triggered — humans decide when to update

• Oracle infrastructure?

  Impact: Chainlink Functions for applications that can use it — established infrastructure with existing trust. EigenLayer AVS for custom verifiable computation requirements.

  • Chainlink Functions — off-chain computation with Chainlink verification
  • API3 dAPIs — first-party data, DAO-governed
  • Custom oracle with guardian multi-sig — full control, more trust required
  • EigenLayer AVS — verifiable computation, newer infrastructure

• Safety bounds approach?

  Impact: Multi-layer: hard-coded absolute limits in the contract (cannot be exceeded regardless of what AI recommends), governance-set advisory bounds (reviewed regularly), and monitoring alerts if recommendations approach limits.

  • Hard-coded bounds in contract — most secure, inflexible
  • Governance-set bounds — flexible, slower to change
  • Multi-layer (contract + governance + monitoring) — defence in depth
  • No bounds — do not do this

• Model governance?

  Impact: Timelock + guardian for production AI-DeFi protocols — models can be proposed and deployed after a review period, with an emergency guardian that can pause AI parameter updates if anomalous behaviour is detected.

  • Developer-controlled — fastest updates, least decentralised
  • Multi-sig controlled — team accountability, some community trust
  • DAO governance — community control, slow update process
  • Timelock + guardian — community review period with emergency override

What PROPELOO builds.

• Dynamic Collateral Ratios

  ML model that adjusts collateral requirements per asset based on volatility regime, liquidity depth and market stress indicators — increasing safety during risk periods.

• AI Interest Rate Curves

  Optimisation model that adjusts borrow/supply rates to maintain target utilisation across market conditions — more capital-efficient than fixed kinked curves.

• Liquidation Optimisation

  ML system that prioritises liquidation order, optimal bonus calibration and cascade prevention during market stress events.

• AI Yield Aggregator

  Portfolio optimiser that allocates capital across DeFi protocols to maximise risk-adjusted yield given current rates, lock-ups and gas costs.

• DeFi Risk Scoring

  On-chain risk score oracle for wallet addresses — creditworthiness for undercollateralised lending, fraud risk for access control, counterparty risk for institutional DeFi.

• Verifiable AI Oracle

  TEE-based or ZK-based oracle that provides AI-computed values on-chain with cryptographic proof of correct computation — trustless AI for DeFi.

The AI-DeFi stack.

• ML Infrastructure

  Stack: Python (scikit-learn, XGBoost), PyTorch (neural models), MLflow (model registry), AWS SageMaker (training)

• Verifiability

  Stack: EigenLayer AVS (TEE), Chainlink Functions, ZK frameworks (EZKL for zkML), Lit Protocol (TEE)

• Smart Contracts

  Stack: Solidity 0.8+, Foundry, OpenZeppelin, Chainlink Consumer

• Data Sources

  Stack: Chainlink Price Feeds, Pyth Network, The Graph (on-chain data), Dune Analytics

• Simulation

  Stack: Tenderly fork simulation, Custom Python market simulator, Historical backtesting harness

• Monitoring

  Stack: OpenZeppelin Defender, Forta Network, Custom parameter monitoring, Grafana + Prometheus

AI-DeFi security requires on-chain and off-chain safeguards.

• Oracle manipulation

  AI oracle values are as manipulable as price oracle values. Multi-source aggregation, deviation thresholds and circuit breakers on AI-computed parameters prevent manipulation.

• Model adversarial attacks

  Adversarial inputs designed to fool the AI model into recommending dangerous parameter settings. Model robustness testing, input validation and governance bounds that cannot be exceeded regardless of model output.

• Model updates as attack vector

  A compromised model update could deploy malicious parameters. Model update governance (timelock + multi-sig) and monitoring for anomalous parameter recommendations after updates.

• TEE trust assumptions

  TEE security depends on hardware manufacturer trust (Intel SGX, ARM TrustZone) and the absence of known hardware vulnerabilities. Monitor TEE vendor security advisories.

• Off-chain infrastructure compromise

  If the off-chain ML inference server is compromised, it can feed malicious values to the on-chain oracle. Infrastructure security, attestation verification on-chain and anomaly detection.

• Emergency pause

  The AI parameter system must have an emergency pause that returns to hardcoded safe parameters. Triggered automatically on anomaly detection or manually by the guardian multi-sig.

From protocol design to AI-enhanced DeFi.

1. 01. Protocol Analysis

   Identify parameters that benefit from dynamic adjustment, model required outputs, define safety bounds.

2. 02. ML Model Development

   Feature engineering, model selection, training, backtesting on historical protocol data.

3. 03. Verification Infrastructure

   EigenLayer AVS or Chainlink Functions for verifiable off-chain computation.

4. 04. Oracle Contracts

   On-chain oracle contracts that consume AI values with safety bounds enforcement.

5. 05. Protocol Integration

   Smart contract modification to consume AI parameters, governance approval.

6. 06. Simulation & Testing

   Historical simulation of AI parameters, stress testing, adversarial testing.

7. 07. Staged Deployment

   Testnet deployment, limited mainnet deployment, monitoring, full deployment.

Frequently Asked Questions