Alchemix
Alchemix borrowing requires available collateral and permission to mint alAssets
Alchemix loan confirmation requires enough borrowing capacity in the selected position and authorization for the transaction’s caller. Before signing, match the collateral, requested alAsset amount, position identifier, and recipient to the intended loan. For v3, distinguish token-spending approval from permission to borrow against an existing position. After submission, check the successful borrowing transaction and its mint record. An approval receipt alone does not establish that the loan reached the recipient.
Last updated ·
In short: Available collateral and borrowing permission are separate checks, and a successful approval does not confirm an alAsset loan.
Continue from the funded position, or resolve missing permission
A funded v3 position can support borrowing when its available capacity and the caller’s permissions cover the request. Start with the position holding the collateral, rather than entering a fresh deposit automatically. Its account identifier connects the borrowing request to the debt it will create.
If a delegated borrowing request reports insufficient mint allowance, address that permission before submitting the loan. Adding collateral does not grant borrowing authority. Keep the requested amount and destination unchanged while examining the permission, so an unrelated edit does not obscure the cause.
Match the account and collateral before entering the amount
The connected account, selected deployment, and position identifier must describe the position you intend to use. Check these before interpreting any balance.
Position ownership identifies who can authorize borrowing
For the direct v3 mint operation, the caller must own the position NFT. Delegated borrowing uses a separate mint allowance associated with that position. A wallet may display a position without having the authority needed for the proposed transaction. Confirm the signing account, particularly after switching wallets or transferring a position.
Wallet holdings differ from deposited collateral
MYT vault shares held in a wallet do not automatically form collateral inside an Alchemist position. Confirm the deposited balance against the selected account record. Keep the share amount distinct from its underlying value and the alAsset borrowing amount; these quantities describe different parts of the transaction. The protocol converts collateral value into debt-token units when calculating capacity.
How much can this position borrow before confirmation?
Available borrowing capacity depends on the position’s valued collateral, outstanding debt, and the configured minimum collateralization requirement. Use the position-specific amount, not a percentage copied from an older loan.
In v3,
getMaxBorrowable
calculates remaining capacity after accounting for existing debt. Treat its result as a state-dependent reading. A preview does not reserve capacity or freeze the account until execution. Refresh it after another transaction changes the position, and compare the request in the same token units.
Separate permission to move collateral from permission to create debt
Token allowance authorizes a spender to move the approved token, while mint allowance authorizes borrowing against a particular position. Inspect the permission type before accepting an approval request.
Collateral approval names a token and spender
A token deposit can require spending approval for the contract receiving that input. Review the token, spender address, and allowance amount together. An approval granted to another contract does not satisfy this request. Limit the authorization to the intended operation when the wallet and transaction flow support that choice.
Mint approval names a position and borrowing delegate
V3 delegated borrowing through
mintFrom
consumes the caller’s mint allowance for the selected position.
The owner grants that permission through
approveMint. Inspect both the spender and position identifier: permission for one position does not authorize borrowing against another.
The signing request defines what you authorize
Before confirmation, compare the wallet’s decoded request with the operation you prepared, including any actions bundled into it. Check the transaction destination, requested borrowing amount, recipient, and position identifier. The transaction destination may be a contract, while the recipient identifies where the minted tokens go.
A combined deposit-and-borrow operation needs scrutiny of both inputs. Where the selected v3 router operation includes a minimum share output and deadline, inspect those conditions before signing. The minimum concerns the vault shares received during conversion; it does not specify a later exchange price for the borrowed alAsset.
Required approvals change the transaction cost
The cost of completing a loan depends partly on which permissions already exist and which transactions remain necessary. Budget for the actual approval and borrowing requests the wallet presents. Execution fees depend on gas consumption and the applicable fee per gas, so a collateral amount alone cannot determine them. A reverted transaction can still consume gas. Keep the network-fee balance separate from collateral you intend to deposit.
A missing mint allowance blocks a request within borrowing capacity
Granting the missing borrowing permission can make this request executable without changing its collateral. Consider a hypothetical delegated v3 loan: the owner selects an existing funded position, requests 136 units of its alAsset, and observes capacity of 219 units. The delegate’s mint allowance is zero. These amounts and account conditions are illustrative.
The request fits the displayed capacity, leaving 83 units before other state changes. Permission is the missing prerequisite. The owner checks the delegate address and authorizes 136 units for that position. This example assumes borrowing remains enabled and the account continues to satisfy the contract’s other checks.
After the authorization confirms, the delegate refreshes the position and simulates the borrowing request again. A successful simulation permits proceeding to wallet confirmation; it does not establish completion. The separate authorization also adds an execution cost whose amount depends on its gas consumption and fee conditions.
The expected result is a successful mint of 136 units to the selected recipient. In this example, the confirmed mint record identifies that position, recipient, and amount, and the recipient balance increases by 136 units without intervening transfers. Those observations confirm delivery. They say nothing about how quickly future repayments will reduce the debt.
A successful receipt must match the borrowing action
Completion requires a successful borrowing receipt whose recorded operation matches the intended position, recipient, and amount. A transaction hash identifies a submission; it does not by itself demonstrate successful execution. Likewise, an approval confirmation proves a permission change, which is a different result from borrowing.
For v3, inspect the
Mint
event and compare its fields with the request. Check the recipient’s token balance and refresh the position’s debt record. Account synchronization can affect the displayed debt, so an old screenshot plus the borrowed amount is not always a complete reconciliation. Preserve the receipt’s block context when comparing records.
Keep the confirmed record separate from later position changes
Retain the transaction hash, network, position identifier, borrowed amount, and recipient after confirmation. These details connect the completed loan to subsequent debt and collateral records. A later balance change does not alter which amount the original transaction minted.
If the interface remains stale, compare its position identifier and network with the confirmed receipt before considering another submission. A second successful borrowing transaction creates another obligation. Later repayment, withdrawal, and redemption activity requires its own reconciliation; the original receipt establishes the borrowing event, not the position’s future value or repayment date.
Alchemix: what people ask
Can I cancel an alAsset loan by rejecting the wallet request?
Rejecting an unsigned borrowing transaction prevents that request from being submitted through the wallet. It does not reverse a separate approval or deposit that already confirmed. After broadcast, closing the wallet or browser does not cancel the transaction; its execution status determines whether the borrowing occurred.
What happens when a v3 router transaction passes its deadline?
A router operation with a deadline reverts if execution occurs after that deadline. The deadline applies to that transaction, not to the lifetime of an existing loan. Review a newly prepared request before signing it, including its amount, any applicable minimum output, and updated expiry.
Does revoking mint permission erase a confirmed loan?
Revoking mint permission prevents further borrowing under that authorization but does not repay existing debt. V3 separates allowance management from repayment operations. A confirmed loan remains associated with its position after permission changes, so the debt record must be checked independently of the allowance record.
When can repayment follow a newly confirmed v3 mint?
V3 prevents its burn and repay operations from executing in the same block as that position’s mint. An attempted same-block repayment can therefore fail even when the required tokens are available. Execution in a later block must still satisfy the chosen repayment operation’s other conditions.
How should raw token amounts be interpreted in a borrowing request?
Interpret raw amounts using the decimals of the token each field represents. A collateral-share quantity and a debt-token quantity can use different scales. Match the wallet’s formatted amount to the intended asset before signing; equal-looking raw integers do not necessarily represent equal token quantities.
Is borrowing available whenever a position displays unused capacity?
Unused capacity alone does not establish that borrowing is available. V3 also checks authorization and protocol state, including whether loans are paused. A position can display collateral headroom while the mint operation remains unavailable. Increasing the network fee does not override those contract conditions.