Benqi wallet setup and lending or staking confirmation checks
Benqi lending and liquid staking transactions require the correct wallet account, Avalanche C-Chain funds and a review of the requested action. Before signing, match the asset, amount and permission to your intended operation. After confirmation, check the resulting supply position or staking balance against the transaction record.
last updated
The short version: Check the connected account, spending permission and expected balance change before signing a lending or liquid staking transaction.
Prepare a supply request and catch an approval-only result
For a token supply that requires spending permission, approval normally precedes the deposit. A successfully executed approval without a new supply balance means that permission changed; it does not establish that the deposit happened. Begin with the connected account and its existing supplied balance so that the eventual change has a clear comparison point.
Check the account and funds before approval, then verify the deposit:
- Continue only when the connected account holds the selected asset on Avalanche C-Chain and enough native AVAX for approval and deposit fees.
- Before approval, match the token and spending contract to the intended supply operation.
- Keep the approved allowance within the amount that you intend to authorize.
- Before submitting the deposit, review its amount, collateral setting and estimated network fee.
- Accept completion when the deposit record and the updated supplied position agree.
If the wallet reports confirmation while the supplied balance remains unchanged, inspect which transaction confirmed. An approval-only record calls for checking the remaining allowance and the deposit preview before continuing. A successful deposit record calls for reconciling the account and displayed position, rather than immediately sending another deposit.
Match the connected account to Avalanche C-Chain
The connected account must match the account that holds the funds, and its selected network must match the network used by the application. Avalanche C-Chain mainnet uses chain ID 43114. A familiar network label alone does not establish that the configuration points to mainnet.
Changing the network displayed in a wallet does not transfer assets between networks. Likewise, selecting another account changes which balances the application reads. Compare the full account address when resolving a mismatch, especially when the wallet contains several accounts with similar names. The balance that matters is the selected asset balance on the required chain, not the combined value shown on a wallet home screen.
How much AVAX should remain available for gas?
Leave enough native AVAX to cover the wallet's estimated network cost for the pending action and any separate transaction that you intend to submit. The required amount changes with network conditions and the operation. A token approval and a subsequent supply transaction can each incur a fee.
When AVAX is also the input for lending or liquid staking, its spendable balance must cover both the input and transaction costs. Treat a maximum-amount shortcut as something to review. A displayed estimate describes the request under the conditions used to calculate it; it does not establish a permanent fee for future transactions.
Read the spending permission before accepting it
Connection permission
Connecting a wallet lets an application interact with the selected account through the wallet. Connection alone does not supply assets or establish a lending position. A subsequent wallet request may authorize a different action, so read its contents even when it follows immediately after connection. Reject a request that does not correspond to the operation that you initiated.
Token allowance
An ERC-20 approval authorizes a specified spender to transfer tokens up to an allowance. The spender, token and authorized amount therefore deserve separate attention. A large allowance grants broader permission than the immediate deposit needs. Where the wallet supports editing that allowance, distinguish the amount of permission from the amount that the application proposes to supply.
An existing sufficient allowance can remove the need for another approval. Native AVAX does not use the ERC-20 allowance mechanism, so an AVAX transaction and a token supply need not produce identical prompts. The number of wallet requests is not a reliable test of whether either operation completed.
Inspect the lending preview before committing funds
Supply and collateral settings
A supply preview should correspond to the asset and amount that you selected. Where the application offers collateral settings, review whether the deposit will support borrowing. Supplying and borrowing are distinct actions; a supply does not itself create a loan. The displayed position preview helps identify how the proposed deposit changes the existing account.
Borrowing against an existing deposit
Borrowing requires deposited collateral and enough borrowing capacity for the requested amount. Review the projected position after the loan, including its collateral health and borrowing cost. The application calculates that preview using market conditions and configured parameters. A preview that permits a transaction does not fix future collateral prices or prevent interest from increasing outstanding debt. Falling collateral value or growing debt can make the position eligible for liquidation, where collateral is seized to repay debt.
Confirm the selected market as well as the asset. Core Markets can share collateral across supported assets, while Avalanche Ecosystem Markets operate separately in isolated pools. Check that the selected pool recognizes your deposit as collateral.
What should the liquid staking preview show?
The liquid staking preview should identify the AVAX input and the expected sAVAX output, with enough available AVAX remaining to cover the transaction. Benqi liquid staking accepts AVAX on the C-Chain and issues sAVAX on the C-Chain. This entry path does not require the user to move the staking input manually to the P-Chain.
The two token quantities need not match. sAVAX represents a share of pooled staked AVAX, and its AVAX value reflects the pool's exchange relationship. Compare the expected output in token units, rather than expecting the received balance to equal the AVAX input. A fiat valuation introduces another changing input and cannot establish the minted quantity.
Receiving sAVAX also does not automatically supply it to a lending market. Keep those separate operations distinct when reading the requested transaction.
The boundary between reviewing and submitting
An unsigned transaction request can be rejected without executing that request. Once a signed transaction reaches the network, closing the application does not retract it. A finalized transaction cannot be undone by dismissing the confirmation screen. Any later withdrawal or unstaking action has its own conditions.
Before signing, compare the sending account, destination contract, native value and described action with the request that you intended. Token amounts can appear in transaction data rather than the native-value field. A zero native-value transfer therefore does not establish that no tokens are involved. If the wallet cannot explain a request clearly enough to identify its purpose, rejection preserves the opportunity to investigate before submission.
Which records establish that the transaction completed?
Completion requires a transaction record for the intended operation and a corresponding change in the correct account's position or token balance. A transaction hash identifies a request; its existence alone does not prove successful execution. The record should match the selected network, sending account and destination contract.
For lending, compare the supplied or borrowed position with the action that the record describes. For liquid staking, check the received sAVAX quantity. Network costs also affect the native AVAX balance, so the total AVAX reduction can exceed the staking or supply input. Preserve token units when comparing amounts; changing fiat prices can obscure an otherwise consistent transaction.
Separate stable checks from changing transaction details
Account identity, asset identity and the distinction between approval and execution remain useful checks across transactions. Gas estimates, spending allowances, available liquidity and lending parameters describe a particular request or market state. Reusing a previous amount or screenshot does not establish that the next request has the same conditions.
Review changed inputs again after editing an amount, changing accounts or returning to an unfinished request. The expected result changes when those inputs change. If a previously acceptable preview now requests a different permission, shows less borrowing capacity or produces a different staking output, assess the revised request before signing it.
Helpful answers
Does disconnecting my wallet remove an existing token approval?
Disconnecting the wallet does not revoke an existing token allowance. Revocation changes the permission recorded on the blockchain and normally requires a transaction with a network fee. Disconnecting ends the application's wallet connection, while the previously authorized spender retains whatever allowance remains.
Can rejecting a supply request leave an earlier approval active?
Rejecting a supply request can leave a previously confirmed approval active. The approval and supply are separate operations, so rejecting the later request does not reverse the earlier permission change. Review the remaining allowance if you decide to abandon the deposit.
Will importing sAVAX into my wallet create another staking transaction?
Adding an existing token to a wallet's display does not create another staking position. The wallet reads the balance associated with the token contract and account. A token symbol alone does not identify that contract, so displaying a similarly named token does not establish ownership of the intended asset.
Should a token supply transaction show its deposit amount as native AVAX value?
A token supply can encode its deposit amount in contract-call data while showing zero native AVAX value. The native-value field measures AVAX transferred with that call, not every token movement that execution may produce. Read the decoded action and token amount alongside the destination contract.
When does an approval need to be submitted again?
Another approval may be necessary when the intended spender lacks enough allowance for the proposed token amount. Allowances belong to a particular owner, token and spender relationship. Changing the connected account or spending contract can therefore change whether an earlier permission applies.