Morpho blue
Morpho blue helps you prepare and verify your first position
Morpho blue lets you prepare a first position by fixing one market's loan asset, collateral asset, oracle, interest rate model, and LLTV before signing. Decide whether you'll supply the loan asset, post collateral only, or borrow against collateral. Read the live rate, available liquidity, fee, and health data, then review any required permission. After confirmation, match the market ID and position owner to the new supply shares, collateral balance, or borrow shares onchain.
A reliable first position starts with one verified market and ends when its onchain balance matches the action you intended.
Lock the market identity before the first signature
Five market parameters, one chain, and one contract deployment define where the action lands. Record them before reviewing rates or balances, since a familiar asset pair can exist in more than one market.
Match the chain and deployment
Your wallet must be connected to the chain containing the selected market. Check the contract destination in the transaction request as well. A matching interface label doesn't prove the wallet is using the intended chain or deployment, and an approval sent elsewhere won't prepare the position you meant to open.
Bind the five market parameters
The loan token, collateral token, oracle, interest rate model, and liquidation loan-to-value threshold form the market's parameter set. Their contract addresses and LLTV matter, not just token symbols. The resulting market ID is the compact reference you'll use when comparing the preview, transaction logs, and position record.
Identify the position owner
The signer, position owner, and asset receiver aren't always the same address. A direct action may use one wallet for every role, while an integration can act on behalf of another address. Verify the owner field before signing because its record, rather than the transaction sender alone, holds the position.
Choose the balance the first action should create
Three entry actions produce different records. Supplying the loan asset creates supply shares in that market. Supplying collateral increases the collateral field without earning lending interest. Borrowing creates borrow shares and transfers loan assets to the chosen receiver, but it also requires sufficient collateral value, acceptable position health, and available market liquidity.
A collateral deposit doesn't create debt by itself. Likewise, a loan-asset supply isn't collateral for a separate borrow position. Decide which field should change before comparing the final record, especially when an interface offers a combined collateral-and-borrow transaction.
Separate fixed market inputs from live readings
Each Morpho blue market is identified by its loan token, collateral token, oracle, interest rate model, and LLTV. Those parameters remain attached to the market after creation. Changing one points to a different market ID rather than an edited version of the existing market.
The oracle output, utilization, rate, liquidity, aggregate balances, and your accrued debt can move between preview and confirmation. The current market fee also isn't part of the identifying tuple. Preserve the fixed fields while refreshing values whose meaning depends on the latest block.
Read liquidity, rate, and health as connected limits
Available liquidity limits a new borrow and can restrict a supplier's immediate withdrawal. Utilization feeds the selected interest rate model, so the displayed borrow and supply rates can change as market totals change. A previewed rate is a live reading, not a fixed term attached to the position.
For a borrower, the oracle converts collateral into loan-asset value and the LLTV defines the liquidation boundary. Debt grows as interest accrues, while the oracle value can move independently. A transaction may satisfy the boundary during simulation yet fail later if the relevant state changes before execution. Keeping some distance from the limit reduces that narrow execution risk but doesn't remove later liquidation exposure.
Narrow permissions to the action being prepared
The wallet needs any token the action transfers from it and enough of the chain's execution token to submit the transaction. Supplying requires the loan asset, posting collateral requires the collateral asset, and repayment later requires the loan asset. A displayed portfolio value can't replace the spendable balance of the exact token contract.
Token allowances permit transfers
An ERC-20 approval allows a specified spender to transfer tokens within its allowance. It doesn't supply, post collateral, borrow, or repay on its own. Review the spender, token address, and allowance amount. An interface using a permit may replace a separate approval transaction, but the signed permission still deserves the same checks.
Position authorization permits management
Protocol authorization is broader than a token allowance. An authorized address can manage the authorizer's positions across markets, so a request for this permission shouldn't be treated as a market-specific token approval. Confirm the authorized address and whether the intended route needs that scope.
Execution funds remain separate
The transaction can fail when the wallet can't pay network execution costs, even if every token balance required by the action is sufficient. Keep that balance separate from the amount committed to the position. A simulation rejection before broadcast differs from an onchain revert, which can consume an execution fee.
Preview the committed state before sending
Before sending, identify the position field the requested action should change. Match the chain, market ID, token contract, amount, position owner, receiver, and any deadline or share-price bound shown by the route. For a borrow, inspect projected debt and health alongside available liquidity. For a supply, confirm the loan asset and expected supply shares.
Wallet simulation can expose a revert before signing, but it can't freeze state until inclusion. Treat it as a coherent preview from a particular block. If the transaction request changes after the preview, inspect the revised fields instead of relying on the earlier result.
A reverted atomic attempt preserves the starting position
Every amount and live reading in this example is hypothetical. A reader prepares one atomic action using 76 collateral-asset units and requests 31 loan-asset units. The preview shows 34 loan-asset units of available liquidity and a healthy projected position, so the requested borrow fits the displayed state.
The transaction later receives a reverted status. The expected completion was a collateral balance plus borrow shares, but the position record still shows zero for both fields. Because the two actions were bundled atomically, the revert preserved the starting position even though network execution may have cost a fee.
A fresh read now shows a hypothetical 29 loan-asset units of liquidity. The reader keeps the hypothetical 76-unit collateral input, lowers the request to 26 loan-asset units, and reviews a new health preview before signing again. The confirmed transaction transfers 26 loan-asset units to the receiver, while the onchain record shows 76 collateral units and nonzero borrow shares. If collateral and borrowing had been submitted separately, the collateral field would need its own check before any retry.
Pending, reverted, and confirmed remain different states
A wallet signature authorizes a transaction request. Once the network accepts the broadcast, the transaction is pending. Neither state proves the protocol record changed. During that interval, liquidity, interest, and oracle data can continue moving.
A receipt with a failed status means the attempted state changes reverted. A successful receipt means the transaction executed, but the logs and position owner still need to match the intended market. A dropped or replaced transaction has a different outcome from an onchain revert, so check its nonce and look for a receipt or replacement before resubmitting.
Confirm completion in the correct position fields
Completion evidence depends on the action. Read the position under the selected market ID and intended owner, then compare the field tied to the transaction. Logs help identify what executed, but the resulting position is the durable record needed for reconciliation.
Loan-asset suppliers receive supply shares
A successful direct supply increases the owner's supply shares. The shares represent a proportional claim on the market's supplied loan assets, so the share count shouldn't be mistaken for a fixed token balance. Convert the shares using current market totals when checking the asset-equivalent value.
Collateral owners receive an asset balance
Collateral is recorded directly as an asset amount rather than as interest-bearing supply shares. Confirm the collateral field increased for the intended owner. If the transaction supplied collateral on behalf of another address, looking only at the signer's position can make a completed action appear missing.
Borrowers receive debt shares and loan assets
A completed borrow increases borrow shares for the position owner and sends the requested loan asset to the receiver. Check both outcomes because the two addresses can differ. A receiver's wallet balance alone doesn't prove which market or owner carries the debt, especially when that wallet already held the same token.
Reconcile shares, assets, and delayed displays
Supply and borrow positions use shares, while collateral uses an asset amount. Interest changes the asset value represented by debt and supply shares without requiring their counts to change on every block. Fresh conversion data is therefore needed when comparing a later interface value with the original transaction amount.
An interface can also lag behind the confirmed chain state while its index updates. Recheck the chain, market ID, owner, and transaction receipt before repeating an action. Resubmitting solely because a screen is stale can create an unintended second supply or borrow.
Plan the exit boundary before committing funds
A supplier can withdraw only when the market has enough available liquidity. A borrower must clear the debt before removing all collateral, while a partial collateral withdrawal must leave the position healthy. Full repayment by the current borrow-share balance helps avoid residual debt caused by interest or rounding.
Repayment may require a fresh loan-token allowance or permit, and the intended receiver should be checked again for withdrawals. For either a full or partial exit, reconciliation is complete when the relevant supply or borrow shares and the collateral field match the intended remainder, and withdrawn assets reach the chosen receiver.
Morpho blue: common questions
Does an approval transaction create a Morpho blue position?
No. A token approval only gives the named spender permission to transfer up to the approved amount. The position changes only when a supply, collateral, borrow, repay, or withdrawal action executes successfully. Check the approval's token and spender, then look for a separate successful protocol transaction and the corresponding position field.
Why can a successful transaction show no balance in the market I expected?
The transaction may have been only an approval, or the action may have used another chain, market ID, or position owner. Start with the receipt and logs, then match the five market parameters and the on-behalf address. If those are correct, a delayed interface index may be hiding state already visible in the onchain position record.
Can I switch interfaces and keep managing the same position?
Yes, if the new interface targets the same chain, protocol deployment, market ID, and position owner. The underlying position belongs to that onchain combination rather than to a particular interface. A vault deposit or a transaction routed into a different market is a different record, even when the displayed assets look similar.
Which records should I save after the first position action?
Keep the transaction hash, chain, market ID, position-owner address, and successful receipt status. Recording the intended action and receiver also makes later reconciliation easier. These public identifiers are enough to locate the transaction and position again; a seed phrase or private key should never be stored with them.
When is a reverted borrow ready for another attempt?
Retry only after identifying which live condition or permission caused the revert. Refresh available liquidity, oracle-dependent health, accrued debt, allowance, execution funds, and the wallet nonce. Then simulate the revised request against a recent block. Repeating an unchanged request can fail again, while changing markets without noticing creates a separate position.
Do I need a new token approval to repay the first borrow?
Repayment requires the payer to provide the loan asset through the route's accepted allowance or permit. An existing allowance may be sufficient if its token, spender, and remaining amount match the repayment request. For a full close, using the fresh borrow-share balance helps clear interest and rounding that an older asset quote may miss.
Will a supply-only position face borrower liquidation?
No. A direct loan-asset supply with no debt isn't subject to borrower liquidation, and collateral posted without debt remains healthy under the core health check. Liquidation applies after a collateralized debt position crosses its market's LLTV boundary. Suppliers can still face different risks, including realized bad debt and insufficient liquidity for an immediate withdrawal.
How can debt change between the preview and confirmation?
Borrow debt accrues interest according to the market's live rate, and an asset amount is represented internally by borrow shares. State can move between simulation and block inclusion, while share-to-asset conversion uses the applicable market totals and rounding. Compare the confirmed borrow shares and a fresh asset conversion instead of expecting an old preview to remain exact.
· updated