What is Compound?

Introduction

Compound is a decentralized lending protocol that lets people supply crypto assets to earn interest or borrow against collateral without relying on a bank or a centralized exchange. That sounds simple, but the important shift is structural: instead of matching one lender with one borrower, Compound creates shared liquidity pools and lets code set the price of credit. That design solved a practical problem early DeFi kept running into; lending markets are hard to scale if every loan needs a counterparty, negotiation, and ongoing management.

The idea that makes Compound click is this: it turns credit into a pool problem rather than a person-to-person problem. If enough assets sit in a common pool, lenders do not need to know who is borrowing, and borrowers do not need to wait for a specific lender. What matters is whether the pool has enough available liquidity and whether the borrower has posted enough collateral.

Once you see that, the rest of Compound follows naturally.

• interest rates
• collateral rules
• liquidations
• tokenized deposit receipts

How did Compound enable pooled money markets on-chain?

Before pooled lending designs became standard, a lending system often had to answer a difficult coordination question: who lends to whom, on what terms, for how long, and with what enforcement? On a blockchain, that is expensive and awkward. Compound's answer was to stop thinking in terms of individual loans and instead create a separate money market for each asset.

In the original Compound design, each market is a pool of one asset, such as ETH or an ERC-20 token. Suppliers deposit that asset into the pool. Borrowers can draw from the same pool if they have enough collateral elsewhere in the protocol. The interest rate is not negotiated loan by loan. It is derived algorithmically from how heavily that pool is being used.

This is why the utilization ratio matters so much. In the whitepaper, utilization is defined as Borrows / (Cash + Borrows), where Cash is the amount sitting available in the market and Borrows is the amount already borrowed. If utilization is low, there is idle capital, so borrowing should be cheaper and supply yields lower. If utilization is high, liquidity is scarce, so borrowing becomes more expensive and supply yields rise. Here is the mechanism: price moves in response to pool stress, and that price change is what pushes the system back toward balance.

The protocol does not promise that liquidity will always be there. Instead, it uses the interest-rate curve as an incentive system. When a market gets heavily utilized, higher rates are supposed to attract more suppliers and discourage marginal borrowing. That is an elegant design, but also a real constraint: users depend on incentives, not guarantees.

What are cTokens in Compound v2 and how do they accrue interest?

In Compound v2, when a user supplies assets, they do not simply have an internal balance in a database. They receive cTokens, ERC-20 tokens that represent their claim on the pool. If you supplied USDC, for example, you would receive the corresponding cToken for that market. These tokens are the protocol's accounting device.

The key is that a cToken does not usually grow in raw unit count as interest accrues. Instead, its exchange rate against the underlying asset increases over time. The v2 documentation describes this directly: cTokens represent supplied assets, and as interest accrues, each cToken becomes redeemable for more of the underlying. That means your deposit earns yield because the redemption value changes, not because the protocol keeps sending you separate interest payments.

This design is useful for both users and integrators. For users, it makes the supply position portable and visible as a standard token balance. For wallets, apps, and other protocols, it makes the lending position composable, because the position is represented on-chain by an ERC-20 token. The analogy is a claim ticket whose face value floats upward over time. That explains the accounting model well, but it fails in one place: unlike a paper ticket, the cToken is itself programmable and can be transferred or integrated into other smart-contract systems.

How does borrowing against collateral work on Compound?

Borrowing on Compound is overcollateralized. A user first supplies assets, then chooses whether those assets count as collateral. The protocol applies a collateral factor to each market (a number between 0 and 1 in the original design) to determine how much borrowing power that collateral creates.

The mechanism is straightforward. Suppose an asset is worth $100 and has a collateral factor of 0.75. Compound does not treat that as $100 of safe borrowing capacity; it treats it as $75. That haircut exists because collateral prices move, and the protocol needs a margin of safety before a position becomes insolvent. The Comptroller, Compound's policy and risk contract in v2, checks whether a user's total collateral-adjusted value is sufficient before allowing a borrow or withdrawal.

A concrete example makes this less abstract. Imagine a user supplies an asset to Compound and now holds the corresponding cTokens. The market value of that supplied asset gives them some borrowing capacity after the collateral factor is applied. They borrow another asset from a different pool. At this point, the protocol is tracking not a personal promise to repay, but a solvency condition: does the discounted value of the collateral still exceed the borrowed value? As market prices move and interest accrues, that condition can tighten or loosen automatically.

This structure is designed for users who already hold crypto and want either yield on idle balances or liquidity without selling. It is less suited to someone seeking an unsecured consumer-style loan. Compound is not trying to evaluate income, identity, or reputation. It replaces that entire credit-underwriting problem with on-chain collateral and automated enforcement.

What happens when a Compound position becomes undercollateralized?

If collateral falls too much in value, or the borrowed balance grows too large, the account can cross the line from safe to undercollateralized. Compound handles that with permissionless liquidation. In the whitepaper's model, if an account's borrow exceeds its capacity, any address that holds the borrowed asset can repay part of the debt and receive the borrower's collateral at a discount, subject to a close factor limiting how much can be repaid at once.

That discount is not a side feature. It is the incentive that makes the system self-healing. Liquidators spend capital and gas to repair unsafe positions; the discount compensates them for doing that work quickly. If liquidation were optional but unrewarded, bad debt could linger. By making it profitable, Compound turns risk management into an open market activity.

The trade-off is equally important. Liquidation protects the protocol as a whole, not the borrower. A user who borrows too aggressively can lose collateral into a fast-moving market. So Compound works best for people who understand that borrowing power is not free capital; it is conditional liquidity that must be managed.

How does Compound III (Comet) differ from v2, and what are the trade-offs?

Compound did not stay frozen in its original form. The current documentation for Compound III, also called Comet, describes a more focused market structure: users supply crypto assets as collateral in order to borrow a single base asset, and users can also earn interest by supplying that base asset. In the initial Ethereum deployment documented by Compound, that base asset is USDC.

This is a meaningful architectural shift. In v2, each asset had its own lending market, and many assets could be both supplied for yield and borrowed. In Compound III, the design centers a market around one borrowable base asset, while other supported assets serve mainly as collateral. That narrows the problem the protocol is solving. Rather than building a many-to-many web of borrowable assets inside one risk engine, it builds a cleaner system around a single debt asset per market.

The likely benefit is simpler risk and capital management. A single base asset means accounting and liquidation logic can be more direct, and parameter choices can be more targeted. The cost is that the system is less general than v2's broader multi-asset borrowing design. For users who mainly want to post volatile collateral and borrow a common unit like USDC, that trade-off is often attractive.

The Compound III docs also describe supporting contracts that matter for real usage. The main user-facing contract is the proxy for a Comet market, and the docs emphasize that integrators should interact with the proxy rather than implementation contracts directly. There is also a Bulker contract that can batch several actions into one transaction, such as wrapping ETH, supplying collateral, borrowing the base asset, and claiming rewards. That does not change the economic logic, but it improves usability by reducing the friction of multi-step interactions.

What governance and trust risks should users understand when using Compound?

Compound is decentralized in the sense that its core lending logic runs on-chain and user positions are governed by smart-contract rules. But it is not trustless in the simplistic sense of "nothing important can change." The whitepaper explicitly describes admin control in the early protocol, including the ability to list markets, update interest-rate models, change the oracle, and withdraw reserves, with an intended transition toward community governance.

That governance layer matters because lending protocols are not static machines. Markets need parameter updates. New collateral types need review. Risk models need adjustment. Compound's repositories and docs also make clear that governance remains part of how the protocol evolves, especially in the Comet architecture with configurators, factories, and upgradeable proxies.

For users, the practical lesson is simple: when you use Compound, you are not only taking market risk from volatile collateral and changing interest rates. You are also accepting governance risk and smart-contract risk. Compound has emphasized audits, public verifiability, bug bounties, and formal verification work, but none of those eliminate risk. They reduce some failure modes; they do not abolish them.

Why does Compound matter for DeFi lending and shared liquidity?

Compound's long-term significance is not just that it is a lending app. It helped establish the standard DeFi pattern in which pooled liquidity, utilization-based pricing, tokenized deposit claims, and permissionless liquidation work together as one system. That pattern became foundational across on-chain credit markets.

For a user, Compound is for two broad situations that naturally emerge from that mechanism. If you have crypto that would otherwise sit idle, you can supply it and earn a variable return. If you want liquidity without selling your assets, you can post collateral and borrow against it. Both uses depend on the same core invariant: the protocol must always keep enough collateral discipline that the pool remains solvent even as users come and go anonymously.

That is the memorable way to think about Compound: it is a machine for turning overcollateralized crypto into shared liquidity. Suppliers provide the inventory. Borrowers create demand. Interest rates move with utilization. Liquidators enforce the edge of solvency. Everything else is implementation detail around that core design.

How do you evaluate a DeFi lending or collateral market before using it?

Evaluate a DeFi lending or collateral market by checking its core parameters (collateral factors, liquidation incentives, oracles, and utilization dynamics) and then use Cube Exchange to research token markets or execute trades after you finish the checklist. Cube can surface price history and on-chain activity for related tokens so you can act on your assessment without leaving the workflow.

1. Read the market docs: note each asset’s collateral factor, close factor, liquidation incentive (discount), and oracle sources. Record those numbers for any asset you plan to supply or buy exposure to.
2. Check utilization and supply/borrow rate curves on-chain or in analytics; flag markets with persistent near-100% utilization or steep rate slopes that can cause rapid price pressure.
3. Inspect tokenized supply accounting (cToken exchange rate or Comet balances) and protocol reserves to estimate how much buffer the market has before undercollateralization spreads.
4. Run a simple stress check: simulate a plausible price drop (for example 20–40% depending on asset volatility) and apply collateral factors and liquidation discounts to see if the position would be liquidatable; if it would, reduce position size or avoid buying related tokens.