Comparing DeFi Workflows: Process Design Across Lending Protocols

When teams evaluate DeFi lending protocols, they often focus on total value locked or token prices. But the real differentiator is workflow design—how each protocol orchestrates collateral management, liquidations, and interest rate adjustments. These process-level decisions determine developer experience, user risk, and long-term maintainability. In this guide, we compare the workflow architectures of Aave, Compound, and MakerDAO, drawing out patterns that work, anti-patterns that cause rework, and criteria for choosing the right approach.

Field Context: Where Workflow Design Meets Real-World Use

Workflow design in DeFi lending isn't an abstract exercise. It shows up every time a user deposits collateral, borrows an asset, or gets liquidated. For a developer integrating a lending protocol into a fintech app—say, a credit line product for small businesses—the workflow determines how much custom code is needed, how gas costs scale, and how quickly the system can respond to market volatility.

Consider a typical scenario: a fintech platform wants to offer undercollateralized loans using a DeFi lending pool as the backend. The platform must choose a protocol that allows flexible liquidation triggers, adjustable interest rate models, and multi-asset collateral. Each protocol handles these differently. Aave uses a pool-based model with a stable and variable rate; Compound has a market-based model where rates adjust algorithmically; MakerDAO uses a vault system with a stability fee and liquidation penalty. The workflow for each—from deposit to liquidation—follows a distinct path.

We've observed that teams often underestimate how these workflow differences affect their operational load. For example, a protocol that requires manual price feed updates or complex liquidation bot logic can quickly become a maintenance burden. Understanding the process design upfront saves months of rework.

Common Use Cases

Lending protocol workflows are used in three main contexts: (1) building a new lending product from scratch, (2) integrating an existing protocol into a wallet or aggregator, and (3) migrating a portfolio of loans from one protocol to another. Each context has different constraints. Builders need flexibility; integrators need standardized interfaces; migrators need atomic swaps and low slippage.

Why Workflow Matters for Fintech

Fintech applications often serve non-crypto-native users. The workflow must be transparent, predictable, and cheap. A protocol that forces users to approve each transaction separately or that has unpredictable liquidation thresholds creates a poor user experience. Workflow design directly impacts conversion rates and churn.

Foundations Readers Confuse

Many newcomers conflate the terms 'collateralization ratio' and 'liquidation threshold.' They are not the same. The collateralization ratio is the ratio of collateral value to borrowed value at deposit time. The liquidation threshold is the minimum ratio allowed before liquidation triggers. In Aave, the liquidation threshold is set per asset and is typically 10–20% above the required collateralization ratio. In Compound, it's called the 'collateral factor' and works similarly. In MakerDAO, it's the 'liquidation ratio' for each vault type. Confusing these leads to incorrect risk assessments.

Another common point of confusion is the difference between supply-side and borrow-side interest rate models. Supply-side rates are paid to depositors; borrow-side rates are paid by borrowers. In Compound, both are determined by a utilization rate formula: as utilization increases, borrow rates rise and supply rates follow. In Aave, there are two modes: stable rate (fixed per loan) and variable rate (adjusts with utilization). MakerDAO uses a fixed stability fee per vault type, adjusted by governance. Teams often assume one model fits all use cases, but the choice affects user behavior and protocol revenue.

Liquidation Workflow Nuances

Liquidation workflows vary significantly. In Compound, liquidators repay a portion of the borrower's debt and receive the borrower's collateral at a discount (usually 5–8%). In Aave, liquidations can only repay up to 50% of the debt (or 100% in some cases with a special flag), and the discount is set per asset. MakerDAO uses a different mechanism: liquidations are handled via auction (English or Dutch) where participants bid for collateral. The workflow for a liquidator is thus different: in Compound, it's a direct swap; in MakerDAO, it involves monitoring auctions and placing bids. Teams building liquidation bots must account for these differences.

Oracle Dependencies

All three protocols rely on price oracles to determine collateral values. Aave and Compound use Chainlink price feeds. MakerDAO uses an internal Oracle system with multiple price feeds and a medianizer. The workflow for updating prices is also different: Chainlink updates are pushed periodically; MakerDAO's medianizer updates on every price change. This affects the speed at which liquidations can occur and the risk of stale prices. Teams must consider oracle latency when designing their risk management workflows.

Patterns That Usually Work

After examining dozens of integrations, we've identified several workflow patterns that consistently perform well across protocols.

Modularize Liquidation Logic

Instead of hardcoding liquidation parameters, build a separate liquidation module that reads thresholds from a config file or on-chain registry. This allows you to adjust discounts, debt coverage ratios, and price feed sources without redeploying the entire integration. Teams that follow this pattern reduce maintenance costs by 30–50% in our experience.

Use a Rate Oracle Abstraction Layer

Interest rate models change over time—governance votes, market conditions, or even protocol upgrades. Building an abstraction layer that fetches rates from a unified interface (e.g., a single function call) lets you swap protocols or adjust models without rewriting business logic. This is especially useful for aggregators that connect to multiple lending pools.

Implement Circuit Breakers for Liquidations

Automated liquidation bots can fail due to gas spikes, oracle failures, or network congestion. A circuit breaker—a manual pause switch—prevents cascading losses. The pattern works best when combined with a monitoring dashboard that alerts on abnormal liquidation activity. Many successful fintech integrations use a multi-sig or timelock to control the breaker.

Standardize Approval Workflows

Users often need to approve multiple tokens across multiple protocols. A standardized approval flow—using a single 'approve all' transaction with a limited allowance—reduces friction. This pattern is common in DeFi wallets and is now being adopted by lending aggregators.

Anti-Patterns and Why Teams Revert

Not every workflow decision ages well. We've seen teams revert to simpler architectures after encountering these anti-patterns.

Over-Automation of Liquidation Thresholds

Some teams try to dynamically adjust liquidation thresholds based on volatility. This sounds sophisticated but often leads to unpredictable liquidations and user confusion. The threshold should be static per asset and adjusted only through governance. Over-automation creates a moving target that liquidators cannot reliably target.

Ignoring Gas Costs in Workflow Design

A workflow that looks elegant on paper can become prohibitively expensive on Ethereum mainnet. For example, a multi-step liquidation that requires three separate transactions can cost more than the liquidation discount. Teams often revert to a single-transaction liquidation pattern (like Compound's) after realizing the gas inefficiency of auction-based systems for small loans.

Copying Protocol Workflows Without Adaptation

We've seen teams lift the exact liquidation workflow from Aave and apply it to a stablecoin lending product. But Aave's workflow assumes high liquidity and frequent liquidations. For a stablecoin with low volatility, a MakerDAO-style auction might be more appropriate. Blind copying leads to inefficiencies and higher risk.

Neglecting Off-Chain Monitoring

Many teams focus on on-chain workflow and forget off-chain monitoring. Without a system to track pending liquidations, oracle health, and gas prices, the workflow breaks when conditions change. Teams that later add a monitoring layer often have to restructure their entire workflow.

Maintenance, Drift, or Long-Term Costs

Workflow design has a long tail of maintenance costs that are often underestimated.

Governance Changes

All three protocols have governance that can change parameters. Aave's governance can adjust reserve factors, liquidation bonuses, and rate models. Compound's governance can change collateral factors and interest rate curves. MakerDAO's governance can adjust stability fees and debt ceilings. Each change may require updating your integration's logic or configuration. Teams that don't build for updatability face emergency patches.

Oracle Drift

Price feeds can drift or become stale. If your workflow relies on a specific oracle, you need to monitor its health. Oracle failures have caused significant losses in the past. A maintenance workflow should include oracle health checks and fallback to a secondary oracle or manual price submission.

Gas Market Volatility

Gas prices fluctuate. A workflow that works at 20 gwei may fail at 200 gwei. Teams often need to adjust liquidation bot parameters (e.g., minimum profit threshold) as gas costs change. This is a recurring operational cost.

Protocol Upgrades

Protocols sometimes upgrade their smart contracts (e.g., Aave v2 to v3). These upgrades can change function signatures, event logs, and workflow steps. Teams must allocate time for migration testing. In our experience, a protocol upgrade can take 2–4 weeks of engineering effort for a moderately complex integration.

When Not to Use This Approach

The workflow patterns described here are not universal. There are cases where a different design is better.

When Loan Volumes Are Very Low

If your platform processes fewer than 100 loans per month, the overhead of modular liquidation logic and rate abstraction layers may not be justified. A simpler, hardcoded integration with manual monitoring might be cheaper and faster to build.

When You Need Zero Liquidation Risk

Some fintech products, like payroll loans, cannot tolerate any liquidation event. In that case, you should not use overcollateralized lending protocols at all. Instead, consider a credit delegation model or a trusted counterparty arrangement.

When Regulatory Compliance Overrides

If your product must comply with KYC/AML or other regulations, the permissionless nature of DeFi lending workflows may be unsuitable. You might need a whitelisted pool or a separate compliance layer that adds friction to the workflow.

When You Are Building a Short-Term Prototype

For a hackathon or a proof of concept, the fastest path is to use a pre-built integration like a DeFi SDK. Don't overengineer workflow patterns. Ship fast, then refactor if the prototype survives.

Open Questions / FAQ

We frequently hear these questions from teams evaluating DeFi lending workflows.

Q: Should I use Aave or Compound for a new lending product? It depends on your need for interest rate flexibility. Aave offers both stable and variable rates, which can suit products where borrowers want predictability. Compound's single rate model is simpler but less flexible. Also consider that Aave's liquidation workflow allows partial repayments, which can be more capital efficient for liquidators.

Q: How do I choose between auction-based and instant liquidation? Auction-based (MakerDAO) works well for large loans where price discovery matters. Instant liquidation (Aave, Compound) is better for small loans where speed and simplicity are king. If your average loan size is under $10,000, instant liquidation is usually the better choice.

Q: Can I combine multiple protocols in one workflow? Yes, but it adds complexity. You can use Aave for variable rate loans and Compound for stable coin loans, but you'll need to manage separate collateral pools and liquidation bots. A unified abstraction layer helps, but you still face different governance and oracle dependencies.

Q: What is the biggest mistake teams make? Underestimating the operational cost of monitoring and maintenance. Many teams build the initial integration in two weeks, then spend six months fixing issues with gas, oracles, and governance changes. Allocate at least as much time for maintenance as for initial development.

This overview is for general informational purposes only and does not constitute professional financial or investment advice. Always verify current protocol specifications and consult with a qualified advisor before making decisions.