Maple finance

Maple finance incomplete deposits: wait, retry, adjust, reconcile, or stop

Maple finance deposits are complete only when the intended transaction succeeds onchain and the designated receiver gains pool shares. If the record remains pending, wait or replace that transaction; if it reverts, diagnose the cause before retrying; if balances disagree after success, reconcile the exact contract, receiver, and transaction before doing anything else.

Classify the unfinished deposit before acting

Start with the transaction record, not the interface message. Identify the connected wallet, intended receiver, pool or router contract, underlying asset, requested amount, and action that the wallet signed. Those details separate an unsubmitted request from an approval, a deposit, or an unrelated transaction.

No deposit hash means no onchain deposit has been identified. The wallet may have been closed, or it may have produced only an approval or permission signature.

An approval can succeed without a deposit following it. In that state, the asset balance and pool-share balance remain unchanged, but the approved spender may retain an allowance. Locate the approval transaction and check whether a separate deposit call was ever broadcast before repeating either action.

A deposit hash with no final receipt is pending, dropped, or replaced. Check the hash through more than one reliable chain view, then compare the wallet’s account nonce with the transaction nonce. A pending call may still execute, so broadcasting a separate deposit can create a second valid instruction.

A final receipt creates a firmer boundary. A reverted deposit failed and did not mint shares. A successful receipt shows that the transaction completed without an outer revert, but it does not prove that the intended deposit occurred. Confirm the target, decoded action, receiver, asset movement, and resulting share balance.


Pending, failed, and successful records mean different things

Pending records require patience or a deliberate same-nonce replacement. Failed records require a cause-specific correction, while successful deposit records require balance reconciliation rather than another submission. Maple pool contracts implement ERC-4626, so a deposit exchanges underlying assets for vault shares issued to a receiver. A successful approval or signature is not the same state change.

When should you wait instead of retrying?

Wait while the deposit hash remains pending and no confirmed transaction has consumed its nonce. The transaction may simply be awaiting inclusion. If the wallet offers a fee-bump or replacement function, use that controlled path only after confirming that it targets the same nonce and represents the action you intend.

A missing hash in one interface does not establish failure. Query the account history and receipt again through another chain view. If a replacement has confirmed, inspect that receipt. If the account nonce has advanced without the original hash succeeding, identify the transaction that used it before deciding whether a new deposit is needed.

When should you wait instead of retrying?: A missing hash in one interface does not establish failure. Query the account history and receipt again through another chain view. If a replacement has confirmed, inspect that receipt.; If the account nonce has advanced without the original hash succeeding, identify the transaction that used it before deciding whether a new deposit is needed.

View full-size image


A five-outcome decision checklist

The onchain state separates the normal path from edge cases and determines the next action. Each choice below ends with evidence that can be checked independently of a loading screen.

  1. Wait when the deposit hash remains pending and no transaction with the same nonce has confirmed.
  2. Retry only after the original deposit reverted, was never broadcast, or was replaced by a confirmed transaction that did not deposit. Recheck the contract, receiver, permission, pool status, balance, allowance, and live capacity before submitting again.
  3. Adjust when a live limit is below the requested amount or the wallet lacks enough underlying assets, allowance, or network-fee funds.
  4. Reconcile when the receipt succeeded but the expected shares are absent from the connected wallet. Inspect the recorded receiver and the event before sending anything again.
  5. Stop when the target contract or receiver cannot be verified, the wallet request differs from the intended action, or another deposit may still confirm.

A deposit is complete when one confirmed deposit call moves the intended asset and issues the corresponding shares to the recorded receiver. Anything less belongs to one of the unresolved states above.


Retry only after the original attempt cannot still complete

A new deposit is appropriate only after the first attempt is known not to have completed. For a reverted call, read the error and recheck the live inputs that govern execution. For a transaction that was never broadcast, rebuild the request from the intended pool and receiver rather than reusing an unexplained wallet prompt.

If the hash appears dropped, compare the account nonce across reliable chain views. A wallet can replace an EVM transaction by submitting another transaction with the same nonce and a sufficient fee, but a fresh deposit with a later nonce is a separate instruction. Both instructions can execute if the original remains valid and eventually confirms.


Adjustment fixes capacity, permission, and input mismatches

For Maple pools, maxDeposit reflects the receiver’s permission and the capacity remaining below the pool’s liquidity cap. A quote obtained earlier can therefore become unusable when capacity or receiver eligibility changes before execution. Read the live value for the actual receiver rather than assuming that a prior amount remains acceptable.

Reduce the amount only when it exceeds the live deposit maximum and a smaller amount remains valid. A smaller request does not repair a wrong asset, wrong contract, ineligible receiver, inactive pool, or missing authorization. Those conditions require correcting the relevant input or stopping.

Asset balance, allowance, and network-fee funds answer different questions. The wallet needs the underlying asset for the deposit and the chain’s fee asset for execution. A conventional ERC-20 route also needs sufficient allowance for the contract that will transfer the deposit asset.


Reconcile approval, asset movement, and pool shares

Approval and deposit may be separate transactions. A confirmed approval changes an allowance but does not issue pool shares. Maple pool contracts expose depositWithPermit for assets that support ERC-2612, combining the permit and vault deposit in one transaction. When permit and deposit execute atomically, a revert cancels both state changes inside that call.

For a successful deposit, compare the receipt with the underlying asset and share balances around the confirmed block. The deposit event records the asset amount, share amount, and receiver. Share units need not equal asset units numerically, so use the event and the relevant vault conversion rather than expecting a one-to-one count.

If the connected wallet lacks the shares, inspect the recorded receiver before treating them as missing. A successful call may have issued shares to another address supplied in the transaction. If the receipt contains no intended deposit call or deposit event, identify what actually executed and stop before resubmitting.

Reconcile approval, asset movement, and pool shares: If the connected wallet lacks the shares, inspect the recorded receiver before treating them as missing. A successful call may have issued shares to another address supplied in the transaction.; If the receipt contains no intended deposit call or deposit event, identify what actually executed and stop before resubmitting.
Visual summary: Reconcile approval, asset movement, and pool shares.

View full-size image


When should you stop instead of submitting again?

Stop when the contract address cannot be matched to the intended pool route, the receiver is unfamiliar, the asset or amount changes unexpectedly, or multiple attempts may still be pending. Also stop after a successful receipt that shows unexplained asset movement or an unintended receiver. Preserve the hash and transaction details, avoid further signatures, and resolve the discrepancy before creating another state change.


Interface lag does not alter the chain record

A stale interface can continue showing pending after a transaction has confirmed. Refreshing the position, reconnecting the same wallet, or checking another chain view may reveal the receipt and share balance. These display actions do not execute, cancel, or repair a deposit.

Changing an RPC provider can expose a missing receipt or pending hash. It cannot turn a reverted call into a deposit.

The reverse problem also occurs: an interface may show a submitted request before the network has accepted it. Without a discoverable hash or account-history entry, treat the deposit as unconfirmed and inspect the wallet activity before rebuilding the request.


Evidence to retain for unresolved deposits

Keep the transaction hash, network, sending wallet, receiver, target contract, action type, nonce, receipt status, and any revert message. Record the underlying asset and pool-share balances before and after the relevant block. These details distinguish a display delay from an approval-only state, failed execution, replacement, or receiver mismatch.

Evidence to retain for unresolved deposits: Keep the transaction hash, network, sending wallet, receiver, target contract, action type, nonce, receipt status, and any revert message.; Record the underlying asset and pool-share balances before and after the relevant block.; These details distinguish a display delay from an approval-only state, failed execution, replacement, or receiver mismatch.

View full-size image

A support request never needs a seed phrase or private key. Avoid sharing raw signatures that could still authorize an action, and redact unrelated wallet activity. The named onchain record for a completed ERC-4626 entry is the Deposit event.

Maple finance: common questions

Why was a network fee charged when no Maple pool shares arrived?

A reverted EVM transaction can still consume a network fee because validators executed it before the contract rejected its state change. The reverted deposit does not mint pool shares, and changes inside that call do not persist. Check whether the charged amount was the network fee rather than the underlying asset. A separately confirmed token approval may remain active.

Does a pending Maple deposit earn pool yield?

No confirmed pool-share position exists while the deposit transaction remains pending. If the chain later confirms the deposit, the confirmed execution creates the shares used in the pool’s accounting, even when the interface updates later. Check the receipt and receiver’s share balance because an interface label alone cannot show whether the transaction succeeded, failed, or was replaced.

How can a deposit preview succeed when execution later fails?

An ERC-4626 preview estimates shares under the state available when it is called, but it does not prove that execution requirements will pass. Deposit limits, receiver permission, allowance, balance, pool status, and onchain state can differ by execution time. Maple’s live maxDeposit value addresses capacity and receiver permission, so compare it with the intended amount immediately before submitting the deposit.

Will a same-nonce replacement create two Maple deposits?

A confirmed EVM replacement that uses the same account nonce prevents the original transaction from confirming separately because that nonce can be consumed only once. The risk changes when a wallet sends another deposit with a new nonce: the original may still confirm, followed by the later deposit. Verify the original nonce, replacement hash, and final receipts before creating a fresh instruction.

Are pool-share units supposed to match the deposited asset units?

Pool-share units do not have to match the deposited asset units numerically. ERC-4626 vaults convert assets into shares using the vault’s accounting at execution. Use the successful Deposit event, including its recorded share amount, and the receiver’s pool-share balance change. Numerical inequality alone does not show that a deposit is incomplete.
Updated ·