Skip to content

Gas costs

Mainnet gas costs for Banq, broken down by what each protocol pays gas for. Banq numbers are pulled from mainnet activity — every cell links to a real on-chain trace. Aave V3 numbers are from the Cyfrin gas audit (May 2025) plus warm-path Foundry snapshots; Benqi numbers are from mainnet receipts on qiAVAX/qiUSDC (2026-04-14, Avalanche).

A gas measurement on a lending pool depends heavily on whether storage slots are warm or cold, whether the user is already in the position-marker set, whether the operation involves the same token on both sides, and whether the position has any debt at all. Rather than a single number, this page reports a min / max envelope per operation — the spread is structural, not noise.

Warm-path summary

The warm path assumes the user already holds positions in the pool, vault state is loaded, and the user is already in the position-marker set. This is the steady-state cost — what most users pay on most operations.

OperationAave V3Banq MinBanq MaxBenqi
Supply / Mint146k229k (0xb4dc8515)349k (0xcaa7f16c)148k
Borrow247k274k (0xf2fb935f)412k (0xce913a08)851k
Repay / Settle176k195k (0x36396c7e)217k (0x1410ec8c)135k
Withdraw / Redeem165k161k (0xa560fbf1)354k (0x271fcd1a)1,010k

Supply / Mint (warm)

Borrow (warm)

Repay / Settle (warm)

Withdraw / Redeem (warm)

Cold vs warm envelope

The cold path is the first time a particular slot, user, or token is touched in a pool. Cold cost is paid per token side and per user, not per pool — adding a second token to a user's position re-pays the same cold premium that the first token did, regardless of pool age. Onboarding a new user re-pays the full cold-mark insert (+25k) regardless of the pool's age.

Supply / Mint (cold/warm, min/max)

Borrow (cold/warm, min/max)

Repay / Settle (cold/warm, min/max)

Withdraw / Redeem (cold/warm, min/max)

Gas categories

Each stacked bar above is broken down into six categories:

  • Health Check — position balance reads across pool tokens (single-side or cross-pair totalOf legs)
  • Position Accounting — mint / burn position tokens, reindex, interest accrual
  • Oracle — TWAP price-feed reads (Oracle::mixQuotes or minQuote)
  • Vault / Custody — ERC4626 deposit / redeem, share accounting
  • Token Transfers — ERC20 transferFrom / transfer
  • Base Overhead — tx cost, modifiers, guards, protocol logic

Key insights

Each warm op has a structural short-circuit

Each Banq warm op has a structural short-circuit that the Min trace exploits and the Max trace does not.

  • Supply Min avoids the cold-mark insert because the user is already in the large-holder set; Max pays the full +25k cold per-user mark on a virgin user, plus cold first-of-tx Pool slots.
  • Borrow Min is self-pair (same token on both legs — no oracle, no cross-token reads, ~106k saved); Max is cross-pair and forces all four totalOf legs plus Oracle::mixQuotes.
  • Settle Min is exact-amount (no max-sentinel totalOf) and keeps the user in-set; Max passes type(uint256).max AND drains the user out-of-set (+46k upfront totalOf, +8k mark(false)).
  • Redeem Min runs against a flat account (zero debt, oracle elided); Max is fully cross-token contended (+131k cross-token health, +19k oracle, plus interest reindex). At 161k → 354k (+120%), redeem has the largest min/max gap of any op.

Cold cost is per-token and per-user

Adding a second token (XPOW supply Cold Max at 404k) byte-for-byte mirrors the first (APOW supply Cold Min at 404k) — the per-token cold premium repeats. Onboarding a new user re-pays the full cold-mark insert (+25k) regardless of pool age. The Cold Max borrow (483k) combines new-user state with cross-pair contention to define the realistic gas ceiling for any borrow on this pool.

Versus Aave V3 / Benqi

Banq's redeployed Pool uses a single-side health check — only the operated token's positions are read; the oracle leg is invoked only when the user holds debt on the other pool token. Self-pair operations (same token supplied & borrowed) skip the oracle entirely, dropping warm borrow Min to 274k. Even contended cross-pair borrows fold both NAVs into one Oracle::mixQuotes(supplyAmt, borrowAmt, src, dst) call (~18.8k).

Benqi's Comptroller still iterates all entered markets on borrow / redeem, causing extreme gas spikes (851k–1,010k). Aave V3 benefits from efficient isolation-mode health checks and cheap Chainlink reads, but Banq's warm settle Min (195k) and warm redeem Min (161k) both undercut Aave V3 outright; Banq warm borrow Max (412k) loses to Aave V3 (247k) only when the user holds cross-pair debt.

Trace sources

All Banq numbers above come from real mainnet traces on Pool P000 (0x172698a1…9725). Replace the hash prefixes with full block-explorer URLs to inspect each one.

  • Warm Min — cheapest exact-amount warm trace per op: supply 0xb4dc8515 (229k, APOW ≈ 1 unit), borrow 0xf2fb935f (274k, self-pair APOW — no oracle), settle 0x36396c7e (195k, XPOW dust), redeem 0xa560fbf1 (161k, full-drain XPOW dust).
  • Warm Max — most expensive warm trace per op: supply 0xcaa7f16c (349k, new user — cold per-user mark slot), borrow 0xce913a08 (412k, cross-pair: APOW collateral, XPOW debt — full 4-leg health + mixQuotes), settle 0x1410ec8c (217k, max-sentinel + drain-out-of-set), redeem 0x271fcd1a (354k, fully cross-token contended).
  • Cold Min — first-of-kind from the 2026-05-01 batch: supply 0xa2d1d5a4 (404k, first-ever APOW deposit), borrow 0x549a5f70 (354k, first-ever borrow, self-pair), settle 0xf5e3a287 (201k), redeem 0x1ac1277a (171k, first redeem on flat account).
  • Cold Max — most expensive cold trace per op: supply 0x4398edd1 (404k, first-ever XPOW deposit — per-token cold mirror), borrow 0x39d1b9d2 (483k, new user fully-cold cross-token), settle 0xc2b4c17b (204k), redeem 0x925dc637 (185k, single-leg minQuote against outstanding cross-token debt).

The corresponding spec/TTXs_*.md files live in the protocol repository (banq.git).

Other operations

These operations are not in the warm/cold mainnet trace set above — numbers are Foundry estimates with optimizer ON, against an isolated test pool. They may differ from mainnet costs once the redeployed pool has accumulated real state.

OperationXPower BanqAave V3Compound V3Notes
Supply with lock~138kn/an/aLock state added
Redeem with lock-expiry~155kn/an/aRing-buffer cleanup
Lock (retroactive)~75kn/an/a
Transfer Supply~75k~78k~78kLock-aware proportional
Transfer Borrow (with both approvals)~95kn/an/aInverted direction
Liquidation (full)~298k~389k~370k
Liquidation (16 slots)~6,750kn/an/aWorst case — all ring slots active

The 16-slot liquidation case is unusual — it requires the victim to have all 16 ring-buffer slots active, which is an edge case. Typical liquidations clear positions with 0–3 active slots and run ~300k gas.

Why Banq is generally cheaper

The protocol's log-space interest accumulation saves ~1,200 gas per accrual versus the multiplicative index used by incumbents. This compounds across operations.

The lock-aware transfer adds gas relative to plain ERC20 transfer, but only when locks are non-zero — fully unlocked positions transfer at near-baseline cost.

Why the worst-case liquidation is expensive

A liquidation that propagates lock state across all 16 ring-buffer slots performs significant arithmetic per slot. This is the "worst case" — typical liquidations run ~300k gas.

Keepers should price gas into their bot's profitability calculation. A profitable liquidation requires the bonus to exceed gas + opportunity cost.

Optimisation tips

  • Batch operations. A single tx with multiple operations is cheaper than separate txs.
  • Use approve once. Standing approvals save per-call gas at the cost of standing-approval risk.
  • Skip MAX_UINT256 for partial settles. Pass the exact amount when you know it — the difference is 195k vs 217k for warm settle.
  • Stay in the position-marker set. Don't fully drain a token side unless you're closing the position — re-entering pays the cold-mark insert again (+25k).
  • Self-pair when you can. If your strategy can hold the same token on both sides of a position, you skip the oracle entirely (~106k saved on borrow).

Where to go next