Iron bank
Iron bank ties borrowing and withdrawal limits to collateral values, market parameters and available liquidity
Iron bank lets a wallet supply supported assets, borrow against eligible collateral and withdraw only within the account's current risk and liquidity limits. Before signing, compare borrowing capacity, existing debt, oracle-valued collateral and market cash; each can change the amount the contract will accept.
Collateralized borrowing and assigned credit lines
Most wallet positions rely on collateralized borrowing. A supplied asset contributes borrowing power only when the protocol treats it as eligible collateral and applies a positive collateral factor. Existing debt consumes that power, while interest and oracle prices keep changing the calculation.
Assigned credit follows a different boundary. Iron bank can grant an approved protocol a credit limit, allowing that address to borrow within a permissioned allowance rather than relying entirely on collateral held in the same account. Holding a token or connecting an ordinary wallet doesn't create this privilege. Market cash can still restrict either route because the requested asset must be available to leave the pool.
The terms behind each limit
Three values answer different questions. Borrowing capacity describes how much debt the collateral can support, account liquidity measures the unused portion of that capacity and market cash describes the underlying assets the pool can presently release.
Collateral factor
A collateral factor is a market parameter expressed as a proportion of an asset's oracle value. A positive factor lets eligible supply support debt. A zero factor can leave the asset available for supply or repayment while contributing no borrowing power. The live market configuration, rather than an old list or remembered percentage, controls the transaction.
Account liquidity
Account liquidity is the positive difference between risk-adjusted collateral value and borrow value. A shortfall is the opposite state: debt has exceeded the permitted boundary. This account-wide calculation matters because a change in one entered market can affect an action in another.
Available market cash
Pool liquidity places a separate ceiling on borrows and withdrawals. A healthy account can't remove underlying assets the market doesn't hold. Cash may change as other users supply, borrow, repay or redeem, so a displayed maximum is a state-dependent quote rather than a reservation.
Collateral value becomes borrowing capacity
For each eligible market, the protocol applies its collateral factor to the oracle value of the supplied balance. It then combines those adjusted values and compares the total with all outstanding debt. A collateral factor converts the oracle-valued collateral balance into borrowing capacity for that market.
The oracle value matters as much as the token quantity. Falling collateral prices can reduce capacity without any transfer from the wallet, while a rising borrowed-asset price can increase debt value. A factor change can also alter the limit even when both balances stay fixed. A current account-liquidity check reflects all three changes.
What restricts a withdrawal?
A withdrawal must satisfy both account solvency and the selected market's available cash. Removing supply also removes some collateral value when the asset supports debt, so the contract recalculates whether the remaining position can still cover its borrow balance.
Receipt tokens represent the supplied claim, but their balance alone doesn't establish how much underlying liquidity can leave the market. The applicable exchange rate converts the receipt claim into underlying units. Market cash then limits settlement, and the account check may impose a lower amount. A wallet with no debt avoids the collateral constraint, though market state and action-specific controls still apply.
Interest changes the account after the quote
Interest accrual changes debt and supplier claims over time. Borrow balances grow through the market's borrow index, and supplier claims reflect interest through the receipt token's exchange rate. A quote based on an earlier state can therefore differ from the values used when a later transaction executes.
Borrow interest and headroom
The borrow rate responds to the configured interest-rate model and market utilization. As debt accrues, unused borrowing capacity narrows unless collateral value rises enough to offset it. Repaying debt moves the calculation in the other direction after the repayment executes and the market accounts for accrued interest.
Supply interest and protocol reserves
Borrower interest doesn't pass through to suppliers unchanged. The market's reserve factor directs a configured share toward protocol reserves, while the remainder helps determine the supply return alongside utilization. These parameters can differ by market, so one asset's rate or reserve treatment can't establish another's.
A worked limit check before signing
Assume every changing input in this example is hypothetical: eligible collateral is valued at 12 508 account units, its displayed collateral factor is 68%, current debt is 5 406 account units, the target asset has a hypothetical oracle value of one account unit per token and the target market holds 1 742 tokens of available cash.
- Applying the displayed factor gives risk-adjusted collateral of 8 505.44 units.
- Subtracting existing debt leaves 3 099.44 units of account headroom at that snapshot.
- The market has only 1 742 target tokens, so liquidity supplies the lower pre-transaction boundary. A hypothetical request for 1 700 target tokens is worth 1 700 account units in this example and sits below both displayed limits.
- After confirmation, the transaction record and refreshed account state must show whether debt increased and liquidity remained positive. A reverted transaction creates no completed borrow.
Now change two hypothetical live inputs while keeping the collateral value and debt unchanged. If market cash rises to 2 418 target tokens but the collateral factor falls to 61%, adjusted collateral becomes 7 629.88 account units and headroom falls to 2 223.88 account units. The collateral calculation now sets the lower boundary. Wallet confirmation doesn't reserve either value, so execution still uses the state available to the contract.
Each action passes a different set of checks
Supply, borrow, repay and withdrawal operations share a market but don't share one acceptance rule. Reading the fields tied to the intended action avoids treating a successful approval or healthy collateral balance as proof another operation will execute.
- A supply requires a supported, active market plus sufficient token balance and allowance. A configured supply cap may also restrict new deposits.
- A borrow depends on account capacity, market cash and any configured borrow cap or pause state.
- A repayment requires enough of the borrowed asset and an allowance for the transfer. The amount due includes accrued interest.
- A withdrawal depends on the underlying claim, market cash and the account's solvency after collateral leaves.
- Removing a market from collateral use requires the remaining collateral to support every outstanding borrow.
Transaction simulation can expose a failing contract condition before signing, but it doesn't freeze prices, balances or liquidity. The final call runs against the state present when the network includes it in a block.
What happens when the account falls short?
A shortfall means the current risk-adjusted collateral no longer covers the borrow value. New borrowing and collateral-reducing actions should fail, while repayment can reduce the deficit. Price movement, accrued interest or a changed market parameter can produce this state without an outgoing collateral transfer.
Once a position meets the protocol's liquidation conditions, another address may repay part of its debt and receive collateral under the configured liquidation rules. The close factor and liquidation incentive are live parameters, so they shouldn't be inferred from the collateral factor. A failed borrow call is different: when the transaction reverts, it doesn't create a completed debt position.
Protocol credit and flash liquidity use separate boundaries
Collateralized wallet debt is only one lending path in Iron bank. Assigned protocol credit and atomic flash liquidity apply different prerequisites, repayment conditions and commitment boundaries.
Assigned protocol credit
An approved protocol can receive an address-specific borrowing allowance for a specified market. The assigned amount limits how much unsecured or undercollateralized debt the address may carry under that arrangement. Market liquidity and contract controls still apply, and the allowance belongs to the approved address rather than its end users.
Atomic flash liquidity
Iron bank's contract design includes an ERC-3156 flash-loan component. Where the function is enabled, the receiver must return the borrowed principal and required fee within the same transaction. Failure to satisfy the callback and repayment conditions reverts the entire operation. This atomic path doesn't create an open-ended borrow balance or replace a protocol credit line.
Verify the resulting state onchain
A confirmed wallet prompt proves only that a request was signed. The transaction receipt establishes whether the call succeeded, while refreshed balances show the resulting supply claim, debt and account liquidity. Checking the connected network and contract address also prevents a valid transaction on one deployment from being mistaken for activity on another.
For a borrow, the resulting debt balance and remaining liquidity should agree with the successful action. For a repayment, the debt should fall after accrued interest is included. A withdrawal should reduce the receipt claim and underlying market cash by the executed amount. These records provide stronger completion evidence than a pre-sign maximum, which describes a state the market may already have left.
Questions people ask about Iron bank
Can a supplied asset earn interest without increasing borrowing power?
Yes, a supplied asset can represent a lending claim without contributing borrowing capacity. That happens when its collateral factor is zero or the account hasn't enabled it for collateral use where such activation is required. The position may still reflect supply interest, but borrowing against it would require a separate positive collateral contribution.
Why can the displayed borrow maximum fall before confirmation?
The maximum can fall because oracle prices, accrued debt, collateral factors and market cash all feed into the executable limit. Another transaction may consume liquidity before yours is included. A wallet preview uses an earlier state, while the contract evaluates the call against the state available during execution.
When does a repayment release more collateral for withdrawal?
A repayment affects withdrawal capacity after the transaction executes and the market updates the borrow balance with accrued interest. A partial repayment reduces debt without eliminating it. The refreshed account-liquidity value shows whether enough capacity has returned to remove collateral without creating a shortfall.
Does a receipt-token balance equal the same number of underlying tokens?
No, the receipt-token balance represents a claim converted through the market's exchange rate. Interest can increase the amount of underlying assets represented by each receipt token. Redemption still depends on available market cash and, when the supply supports debt, the account's solvency after the requested collateral leaves.
What happens if an Iron bank market is paused or delisted?
The effect depends on the action-specific controls applied to that market. New supply or borrowing may stop while repayment and orderly withdrawal remain available, but the exact permissions come from live contract state. A zero collateral factor can also remove borrowing power without erasing an existing supply claim or debt.
Updated: