Iron bank separates debt repayment from redemption of supplied assets

Repayment and redemption undo different positions

Supply and borrowing create separate sides of an account. Repaying lowers the amount owed in one borrow market; it doesn't return supplied assets. Redeeming burns IBTokens to return market assets and reduces the supply position; it doesn't settle debt elsewhere. Closing both sides therefore requires two state changes, even when an interface presents them as one flow.

The state terms needed before unwinding

The borrow balance, IBToken balance, exchange rate, account liquidity and market cash answer different questions. Read them from one block context when possible, since interest can accrue and available cash can change before confirmation.

Borrow balance is the underlying amount the account owes after accrued interest. An IBToken balance represents a share of supplied assets, so its number shouldn't be read as an equal number of market-asset units. The exchange rate connects those units and determines how many IBTokens the contract burns for a requested market-asset amount.

Account liquidity compares the protocol-valued collateral and debt used by the account risk check. Market cash is narrower: it's the market asset available for release at that moment. A redemption can fit the account's collateral limit yet still fail when the market lacks enough cash.

Repayment changes debt without returning collateral

A repayment transfers the borrowed underlying asset into its market and reduces the borrower's recorded debt. The paying wallet needs the asset and, where the token uses an allowance, enough approval for the market contract. A partial payment lowers the balance without closing it. It also leaves the supplied position and its IBTokens in place.

The balance displayed before signing can age while the transaction waits for inclusion. For a full payoff, use a fresh debt read or a supported full-balance option rather than copying an older amount. The Repay event identifies the payer and borrower, records the amount paid and includes the resulting account debt from that execution. Read the balance again because the event proves only the repayment it records.

Redemption converts IBTokens into market assets

A redemption burns IBTokens and sends the requested market asset to the recipient. The v2 redeem call requests a market-asset amount or uses its maximum-value option for the full supply balance. The exchange rate determines how many IBTokens the contract burns.

Collateral rules and available market cash still apply. If the supplied position supports remaining debt, the protocol checks whether removing it would create an account shortfall. Even an account with enough IBTokens can't force a market to transfer more of an asset than its current cash. Reducing the request may solve a cash constraint, but it won't cure a collateral shortfall of the same size.

View image file

Which action should come first?

Repayment comes first when the proposed redemption would leave too little collateral for an outstanding borrow. Lower debt creates collateral headroom; redemption consumes it. Reversing that order can make the withdrawal fail or leave the account closer to liquidation.

A supply position not contributing collateral may be redeemable while other debt remains. The same can apply when separate collateral leaves enough account liquidity after the proposed redemption. That permission comes from the account's live risk calculation, not from its IBToken balance alone.

For a partial exit, decide whether the immediate aim is lower debt or returned underlying assets. A partial repayment can improve account liquidity without unlocking the entire requested withdrawal. A smaller redemption can fit within existing headroom while leaving both supply and debt open.

Debt and supply don't automatically cancel because their values happen to match. Ordinary repayment requires the borrowed market asset, while ordinary redemption returns market assets represented by IBTokens. When those are different assets, obtaining the repayment asset is a separate action with its own transaction conditions.

A durable record of the reversal

Save the selected network, chain ID, wallet address, market contract and underlying token address before signing. Add the relevant token decimals, starting wallet balance, IBToken balance, borrow balance, account liquidity and market cash. A block number or block tag makes those readings comparable later.

For each submission, retain the transaction hash, nonce, requested action and amount. After inclusion, record the receipt status, block number, gas used and relevant event data. The receipt establishes what transaction entered the chain; event fields and contract reads show which account and market changed.

Take the final balance readings after confirmation and attach their block number. This matters because a later debt read can include more accrued interest than the receipt-time value. Keep private keys, seed phrases and unsigned recovery material out of the record. None of them helps establish the position change.

Stop conditions before the next signature

Before signing, confirm every applicable condition against live state:

• Repay first if redeeming the asset would leave too little collateral for an open borrow.
• Pause when the paying wallet lacks the borrowed asset or the required token allowance.
• Reduce or defer a redemption exceeding the market's available underlying cash.
• Repay more or redeem less if the proposed withdrawal would create an account shortfall.
• Stop if the prompt's network, account or market differs from the starting record.

View image file

Network cost is driven by execution gas and the fee parameters at inclusion, not by a promised fixed charge. An approval, repayment and redemption may require separate transactions. A reverted call can still consume network gas even though the debt and supply balances remain unchanged.

Balances and settings after repayment or redemption

A completed reversal leaves the selected debt or supply position at the intended onchain state. It doesn't necessarily clear every related setting. A token allowance can remain after repayment, and the market stays entered while the account still has supply or debt there.

Record any residual IBToken amount, borrow balance and allowance rather than assuming a clean screen means all three disappeared. Revoking an unused allowance is a separate transaction. A small balance also needs its own explanation, such as a partial action or interest added before the payoff reached the chain.

Confirmed repayment and redemption don't have an undo button. Borrowing again or supplying again creates a new position under the market conditions available then. The saved record proves the completed state transition; it can't promise that a later transaction will restore the previous terms.