Iron bank
Iron bank actions become comparable when each uses the same recorded context and action-specific completion checks
Iron bank comparisons are reliable when supply, borrow, repay and redeem actions are measured against the same recorded fields. Capture the wallet balance, iToken balance, borrow balance, account liquidity, market cash and transaction status before acting, then read those fields again after confirmation. The differences show the net change across the observation window; a quote or successful wallet prompt alone doesn't establish the final position.
On this page
Keep the network, market, asset and wallet unchanged between options, and record the block for each observation. If a shared identifier changes, label the records instead of treating them as equivalent. Different blocks also require you to account for gas conditions, interest accrual and market parameters.
Supply and borrow alter different sides of the record
Two actions can use the same market and still require different success tests. A supply transfers underlying tokens from the wallet into the lending market and credits the account with iTokens. Whether that supplied position adds borrowing power also depends on its collateral treatment, so an increased iToken balance doesn't establish a matching increase in account liquidity.
A borrow moves underlying tokens from market cash to the account and creates or increases debt. The position must have enough borrowing capacity unless it uses an assigned protocol credit line, and the market needs enough available cash to release the requested amount. A confirmed borrow should therefore appear in both the wallet balance and the recorded debt.
Comparing only the wallet's token change would collapse these distinct effects into one number. Keep the supplied position, debt and remaining account liquidity in separate columns, even when both actions involve the same underlying asset.
Quotes, submissions and confirmed transactions need separate records
Before signing, an interface quote is provisional because account values, available cash and accrued interest can change. After inclusion, the receipt fixes the execution status and block context. A reverted transaction may still consume network gas while leaving the lending balances unchanged, so submission and completion belong in separate records.
Which fields belong in the starting snapshot?
A useful starting snapshot identifies the network, market contract, wallet and underlying asset. Those identifiers prevent a comparison from silently crossing into another deployment or similarly labelled market. Record the requested action and amount beside them so the later state change has a defined comparison target.
Position fields should include the wallet's underlying balance, its iToken balance and its borrow balance. Add account liquidity or shortfall because an unchanged token balance doesn't prove unchanged borrowing capacity. If the supplied asset's collateral status is visible, preserve that state as well.
Market conditions need their own line. Available cash can constrain borrowing or redemption, while the interest state can move debt and the underlying value represented by iTokens. Save live parameters as observations rather than treating a remembered value as permanent.
Finally, record the block number used for the reads. Read the after-state at the transaction's block when no later transaction in that block changes the same position, or at a clearly identified later block with intervening activity accounted for. A block number bounds the observation, but it doesn't by itself isolate the tested action from other transactions or interest accrual.
Matched evidence for repayment and redemption
A reader comparing a partial repayment with a collateral redemption should hold the wallet, market and observation rule constant. The actions produce different balance movements, so the test is whether each caused its promised state change at the cost recorded in its receipt.
- The context passes when both records name the same network, market, wallet and asset; any difference fails the comparison.
- The starting position passes when debt, iTokens, underlying balance and account liquidity come from one identified block.
- The request passes when the signed action and requested amount match the option written in the record.
- The receipt passes when execution succeeded and its target, sender, block and actual network fee are preserved.
- The end state passes when the expected balance changed and unrelated fields haven't been substituted as proof.
For repayment, reconcile the amount the contract accepted and the intervening interest accrual with the starting and ending debt. For redemption, the iToken position should fall and underlying tokens should return if the action was allowed. If either transition is missing, stop the cost comparison and investigate that branch instead of treating it as a completed option.
A successful receipt doesn't establish the resulting position
A successful receipt establishes that the transaction executed without reverting. It also supplies the block, transaction target, sender, gas used and emitted logs. That evidence is stronger than a wallet notification, which may only show that the transaction was submitted.
The receipt still needs a position read. An event can identify a supply, borrow, repayment or redemption and show the values the contract recorded, while the account snapshot shows the resulting balances and liquidity. Together they explain the action; neither a refreshed interface card nor a changed wallet balance provides the whole result by itself.
Interest accrual changes the comparison baseline
Borrow balances accrue interest, so debt can rise between the starting read and confirmation even when the requested action stays fixed. A repayment delta should be interpreted against that accrued balance, not against an older interface value captured at an unspecified time.
Supplied value is represented through the iToken exchange rate rather than a guaranteed one-to-one token count. An unchanged iToken balance can therefore represent a different underlying claim after interest accrues. This is why the iToken quantity and its represented underlying value should remain separate fields.
Account liquidity may also move when an oracle value or market parameter changes. Close block spacing reduces noise, but it doesn't make those inputs constant. Preserve the inputs visible for each observation, compare the remaining delta with the action's expected effect and treat any unexplained remainder as a mismatch.
Why can two supported actions show different costs?
Different actions touch different contract state, so they can use different amounts of gas. On an EVM transaction, gas used multiplied by the effective gas price gives the execution fee. Some networks add data or operator fees, so include those components when comparing total cost. A token approval may also require its own transaction before a supply or repayment, while another path may already have sufficient allowance.
Network cost and position economics shouldn't be merged. Borrowing starts or increases interest-bearing debt, supplying creates an interest-bearing claim and repaying reduces future debt accrual. The relevant values come from the requested amount, the transaction receipt, elapsed time and live market state, not from a promised fixed outcome.
Repayment and redemption need different completion evidence
A repayment is complete when the contract accepts the transfer and the event or block-scoped reads show the intended account's debt was reduced from its accrued balance. The wallet's underlying balance should also reflect the outgoing tokens. If the request relied on an older debt display, newly accrued interest can leave a residual balance even after a successful partial repayment.
A redemption is complete when iTokens are exchanged for underlying tokens and the resulting transfer reaches the intended account. The request can still be constrained by market cash and account liquidity. If redeeming collateral would leave the account below its requirement, a successful quote from an earlier state doesn't override the transaction-time check.
Trace a mismatch from receipt status to position reads
When a transaction has a receipt but the expected field appears unchanged, first pin every read to the receipt's network, market, wallet and block. A dashboard connected to another deployment or account can display a valid value for the wrong position.
Next, inspect the called contract and the action event. Match the account, asset and recorded amount to the proposed action. Token symbols aren't enough because they don't identify a contract or market.
If the transaction reverted, record it as a failed action and retain the paid network fee. Then check the specific prerequisite involved, such as allowance, account liquidity, market cash or a paused operation. There is no after-state to compare as a completed lending action.
If execution succeeded, recalculate the before-and-after deltas from block-scoped reads. Separate accrued interest and the network fee from the transferred amount. An unexplained difference remains a mismatch; it shouldn't be averaged into the other option's result.
Similar actions require different account and amount checks
Supplying an asset and enabling it as collateral aren't the same state change. Supply affects the iToken position, while collateral treatment affects whether that position supports debt. A market's collateral factor determines how much of an eligible supplied asset's oracle value can support borrowing.
Repaying debt and redeeming supply also move opposite sides of the account. The first reduces a liability, while the second removes a supplied claim and may reduce borrowing headroom. Where both redemption forms are exposed, one can specify iToken units and the other underlying units, so the requested amount must be labelled with its unit.
Use the same identity fields and observation rule for every option, then apply the action-specific pass condition. This method can establish what a confirmed transaction changed and what it cost at that time. It can't turn a quote, estimate or pending submission into final account state.
Still wondering about Iron bank?
What should I preserve if an Iron bank action is questioned later?
Preserve the network, market contract, wallet, asset, requested action, requested amount and starting block. Keep the transaction hash, receipt, event values and ending block with the matching balance reads. This record distinguishes what the wallet proposed from what the contract executed and what the account showed after confirmation.
When does an action comparison need a fresh starting snapshot?
Take a fresh snapshot whenever the wallet, network, market, asset or proposed amount changes. A preceding transaction also creates a new baseline because it may alter balances, allowance, debt or account liquidity. Material time between attempts matters as well, since borrow interest and market conditions can move without another transaction from that wallet.
Can a transaction hash identify the account whose lending position changed?
A transaction hash leads to the receipt and identifies the outer transaction sender, but that address doesn't always prove which account record changed. A contract integration may act for another account. Match the event's account fields and the block-scoped position reads before assigning the resulting debt, supply or redemption to a wallet.
Does a lower gas estimate prove one Iron bank path costs less?
A lower estimate doesn't prove the confirmed path was cheaper. Estimates use a provisional state and don't set the effective gas price paid after inclusion. Compare the total confirmed fee from successful receipts, including any network-specific fee components, then keep approval transactions and lending interest separate from that fee.
Why can an approval succeed while the following supply still fails?
An approval only changes how many tokens a contract may transfer from the wallet. It doesn't execute the supply or prove the later market action will pass. The supply can still fail if the balance or allowance is insufficient at execution, the operation is paused or another applicable market check rejects the transaction.
Updated: