Compound is a Decentralized Lending Protocol Requiring ERC-20 Approval Before Borrowing

From Market Selection to Recorded Debt

The Compound borrower workflow moves through five decisions: market, collateral, allowance, supply amount, and base-asset withdrawal, with each choice constraining the next action.

1. Select a Compound III market and match its network in the wallet. A Comet market exposes one configured base asset and its own collateral list.
2. Connect the intended address through MetaMask, WalletConnect, or another EVM wallet, then select a listed ERC-20 collateral token.
3. Enter the collateral amount. If the existing allowance is insufficient, sign the token’s approval transaction and wait for its receipt.
4. Submit the supply transaction. After confirmation, check that the protocol balance and displayed borrow capacity increased by the supplied amount’s risk-weighted value.
5. Enter a base-asset amount below capacity, review the withdrawal, confirm it, and verify both the wallet receipt and the new debt balance.

At direct-contract level, a first use produces three state-changing transactions: ERC-20 approval naming Comet as spender, supply, and base withdrawal. A sufficient existing allowance removes the approval, leaving two. An interface can instead batch supply and withdrawal through Compound’s Bulker helper; that route targets Bulker, requires its own token allowance and Comet manager permission, and changes the signature sequence. Network switching and wallet connection remain prerequisites rather than protocol transactions.

The Approval Transaction Changes Allowance, Not Collateral

The ERC-20 approval transaction gives the selected supply spender authority over one token; by itself, it neither supplies collateral nor creates a borrow balance.

ERC-20 defines approve with two inputs: a spender address and a uint256 amount. That 256-bit amount ranges from zero through 2^256−1, and a later approval overwrites the earlier allowance for the same owner-spender pair. A successful call emits one Approval event. The separate transferFrom mechanism lets the authorized contract pull collateral during supply, reducing the allowance unless the token uses the maximum value as a persistent sentinel. An allowance therefore belongs to one token contract, one wallet owner, one spender, and one chain, with its own independently stored value in contract state. Additional context appears in Compound why rewards matter in practice.

Direct supply sets the Comet proxy as spender. A batched Bulker route approves Bulker and separately lets it act as manager for the Comet account. Wallet token balances remain unchanged at this stage. A gas payment appears because approval writes contract state, yet the position shows no added collateral until supply executes.

Allowance Size Determines Whether Supply Proceeds

Allowance size determines whether Compound reaches the supply step, because the selected spender cannot transfer an amount above the token contract’s recorded authorization for that wallet.

An exact allowance covers only the entered amount; a larger allowance supports later supplies without another approval. Under ERC-20 semantics, the recorded value persists until transferFrom consumes it or a new approve call overwrites it. The supply transaction reverts when the remaining value is lower than the requested transfer, so no partial collateral credit appears. This is an allowance mismatch, not a borrowing decision.

An interface can display a stale allowance while a receipt is still being indexed. Reading the same owner, token, spender, and chain after confirmation resolves that ambiguity; changing any one of those four fields means the displayed approval belongs elsewhere.

Network and Market Selection Fix the Contract Route

Network and market selection fixes Compound’s contract route before any signature, because identical token tickers on different chains reference separate balances, allowances, and contracts.

Ethereum uses chain ID 1, Base uses 8453, Arbitrum One uses 42161, Optimism uses 10, and Polygon PoS uses 137. The wallet network must match the selected Compound III deployment before approval. Ethereum, Base, Arbitrum, Optimism, and Polygon each maintain independent transaction histories, even when the interface presents similar market names. The market choice then identifies a specific Comet proxy and one base asset, such as USDC, WETH, WBTC, USDS, USDT, or wstETH.

A wallet network change after market selection invalidates the earlier route displayed by the interface. Reselect the market, asset, and amount after switching, because an allowance recorded on one chain cannot authorize a supply on another chain.

Collateral Supply Creates Capacity Only After Confirmation

The Compound supply transaction moves the approved token into Comet, credits the account’s collateral balance, and recalculates capacity only after successful execution.

Compound III exposes three supply entry points at contract level: supply, supplyTo, and supplyFrom. A direct action credits the connected address through supply, while a Bulker action calls into the same Comet position. During execution, Comet measures the amount received, adds it to that account’s collateral balance, and checks the market’s supply cap. The whole transaction reverts if the cap would be exceeded. Approval capacity and market supply capacity are separate gates: the first belongs to the token contract, while the second belongs to the selected Comet configuration. Neither gate is established by the ticker alone, because every deployment points to specific token and proxy addresses on one chain.

Token precision controls the integer shown in transaction data. USDC and USDT use 6 decimal places, WBTC uses 8, while WETH, USDS, and wstETH use 18. Thus, one USDC equals 1,000,000 base units, whereas one WETH equals 1,000,000,000,000,000,000 base units. The interface handles this conversion, but a decoded wallet view or block explorer exposes the underlying integer.

After confirmation, the wallet’s token balance falls by the supplied amount and collateralBalanceOf rises for the same account and asset. That function returns a 128-bit unsigned balance. Borrow capacity changes only after this recorded collateral state exists.

Borrow Capacity Converts Collateral Into a Base-Asset Limit

In most cases, Compound borrow capacity equals each supplied collateral value multiplied by its configured borrow collateral factor, summed across the account inside one Comet market.

Comet requires its configured price feeds to use 8 decimals before applying each collateral asset’s borrow collateral factor. The selected market then expresses available capacity in its single base asset. The borrow collateral factor sets the opening limit, while a separate, higher liquidation collateral factor creates a buffer for later price movement.

In this single hypothetical worked example, every changing input is invented: collateral value 10,000 units, borrow collateral factor 80%, requested base withdrawal 5,000 units, and later collateral value 9,000 units. Initial capacity equals 10,000 × 80%, or 8,000 units. After borrowing 5,000, headroom is 3,000 and capacity use is 62.5%. If collateral value becomes 9,000 while the factor and debt stay unchanged, capacity becomes 7,200. Headroom then equals 2,200 units, and capacity use rises to 69.44%. After the decline, the account carries 5,000 units of debt supported by 7,200 units of risk-weighted capacity.

The Confirmation Screen Is a State-Change Preview

The Compound confirmation step should identify the selected network, sending account, token amount, destination contract, requested method, and variable network gas before signing.

Approval goes to the collateral token contract and names either the Comet proxy or Bulker as spender, based on the selected route. Direct supply and base-asset borrow calls target Comet; at contract level, borrowing uses withdraw. Comet exposes three withdrawal routes: withdraw, withdrawTo, and withdrawFrom, with the latter two adding recipient or authorized-manager behavior. A batched route instead targets Bulker and presents multiple actions in one invocation. Gas is paid in the chain’s native asset, and its amount reflects execution conditions rather than a protocol-fixed charge.

Execution Turns a Base Balance Into Recorded Debt

The Compound withdrawal transaction transfers the configured base asset to the recipient and records debt when the account lacks an equal positive base supply balance.

In Compound III, withdrawing the configured base asset first reduces any positive base balance, and any remaining amount becomes a negative borrow balance. A balance above zero represents supplied base, zero marks the boundary, and a balance below zero represents borrowing. One withdrawal can therefore contain both a return of supplied base and a new borrow. Comet checks the resulting account against borrow collateral factors before completing the transfer.

Borrow interest accrues per second through the base borrow index, with 31,536,000 seconds used for annual rate conversion. The displayed rate moves with market utilization, so the receipt fixes the borrowed amount rather than a lifetime interest total. Each market also sets a baseBorrowMin; a new negative balance below that configured minimum reverts with BorrowTooSmall, while an existing debt above the threshold proceeds under the same capacity check.

Receipt Checks Separate Approval, Supply, and Borrow

A Compound verification pass compares three receipts with three state reads: allowance after approval, collateral after supply, and negative base balance after withdrawal.

An EVM transaction hash is 32 bytes, shown as 64 hexadecimal digits after the 0x prefix. A contract address is 20 bytes, or 40 hexadecimal digits after that prefix; the displayed address therefore contains 42 characters. Match the approval receipt’s token and spender, then match the supply and withdrawal receipts to the selected Comet route. Hashes prove transaction identity, while addresses prove destination identity.

The final observable state has four parts: the collateral token left the wallet, Comet records collateral, the borrowed base asset entered the recipient wallet, and the base balance records debt. If the interface lags, the confirmed receipt and direct contract reads remain the decisive state on that network.

An Allowance Error Has a Deterministic Recovery Path

A Compound allowance error resolves by checking the exact authorization tuple - owner, token, spender, amount, and chain - before resubmitting the collateral supply transaction.

Start with the approval receipt. A pending receipt has not changed finalized allowance state, and a reverted receipt changed nothing. Wait for success, then read the allowance before signing supply again.

When approval succeeded but supply still reports insufficient allowance, compare the connected wallet with the approval owner, the collateral contract with the approved token, and the selected supply contract with the spender. Confirm that the remaining amount covers the planned supply. Changing from a direct Comet call to a Bulker route after approval creates a spender mismatch, while changing markets replaces the direct Comet address.

For a token implementation that rejects a direct nonzero-to-nonzero allowance change, submit an approval for zero and wait before setting the new value. That recovery adds two approval transactions before the supply transaction, for three state changes in total. Once the corrected supply confirms, refresh the collateral balance and capacity, then proceed to the base-asset withdrawal.

Later Adjustments Reuse the Same Position State

Later Compound adjustments reuse the same position state: supplying base repays debt, withdrawing base adds debt, and withdrawing collateral consumes available capacity. A full base repayment route can pass the MaxUint256 sentinel, equal to 2^256−1, so Comet calculates the accrued debt at execution. Repayment requires base-token allowance before supply. After debt reaches zero, collateral withdrawal still uses one transaction, while a partial withdrawal succeeds only when the remaining collateral supports the updated account.