Maple finance
Maple finance pool state, deposit boundaries, and share confirmation
Maple finance requires the chosen pool to accept the intended asset from the connected wallet at the moment of execution. Before committing funds, match the pool contract, wallet permissions, deposit capacity, share preview, withdrawal design, and transaction details. A wallet prompt alone does not complete a deposit. Completion means the transaction confirms, the asset balance changes as expected, and the designated receiver obtains the pool shares recorded by the contract.
A valid deposit requires the intended pool, an eligible wallet, the supported asset, available capacity, and a confirmed increase in pool shares.
Pool state sets the deposit boundary
A deposit is executable only while the pool identity, access rules, capacity, and quoted share path agree. These inputs meet at the pool contract, which accepts the asset and issues shares. A change in the receiver’s permission or the pool’s remaining capacity can block the same amount that produced a quote moments earlier.
Each stage pairs evidence for proceeding with a stop or recovery condition. They follow the handoff from the selected pool to the resulting share balance without assuming that a displayed opportunity remains available.
| Stage | Evidence to proceed | Stop or recovery condition |
|---|---|---|
| Identify the pool | The selected pool contract and connected network match the intended pool record. | A contract or network mismatch requires reselection before any asset approval. |
| Check access | The pool is active, the deposit call is not paused, and the receiving wallet satisfies the pool’s current permission rules. | An inactive pool or paused deposit call requires a stop. An ineligible receiver must complete the applicable access process or leave the transaction unsubmitted. |
| Check the asset and capacity |
The wallet holds the designated asset, and maxDeposit covers the intended amount.
|
A different asset, insufficient balance, or lower limit requires a corrected amount or a stop. |
| Read the share quote |
previewDeposit returns the expected shares for the selected asset amount at the current block.
|
A zero or unexplained quote should be refreshed and reconciled before signing. |
| Authorize and deposit | The spender, asset, receiver, amount, and pool call match the intended deposit path. | An unfamiliar spender or altered call should be rejected and rebuilt from the selected pool. |
| Confirm completion | The receipt succeeds, the asset transfer is recorded, and pool shares reach the receiver. | A pending or reverted receipt is incomplete; missing shares require reconciliation before another attempt. |
Available capacity can change the immediate outcome. A lower amount may fit a reduced cap, while a permission failure will remain even after the amount changes. The live restriction determines whether adjustment or stopping is the appropriate response.
The pool contract and its managers divide responsibility
The pool contract holds the accounting interface that accepts assets, tracks shares, and exposes entry and exit functions. Maple pools implement the ERC-4626 tokenized vault interface, with additional protocol rules around permissions and withdrawals. The standard makes asset-to-share accounting legible, but it does not make every receiver eligible or every exit immediately available.
The PoolManager supplies accounting and configuration around the pool. State-changing calls pass through its permission checks, while the PoolPermissionManager controls whether a given address can perform the requested action. A public configuration and a permissioned configuration therefore present different prerequisites even when their deposit functions look similar.
The WithdrawalManager governs the path out of a position. Its configuration matters before entry because a deposit-capable pool can still require a request, a queue, or a withdrawal window before shares can be redeemed or assets are delivered. Reading these contracts as one system prevents a deposit quote from being mistaken for a complete statement about access or liquidity.
Asset units and pool shares answer different questions
The deposit amount states how many units of the pool asset leave the wallet, while the share quote estimates the ownership units issued in return. previewDeposit estimates shares at the current block but does not apply the receiver limits reported by maxDeposit.
Pool accounting can change between preview and execution, so compare a fresh quote with the transaction details. Do not assume that the asset and share numbers are equal; the contract’s accounting determines their relationship.
What must agree before the wallet signs?
The transaction is ready only when its identities, limits, and expected output describe the same deposit. Check the connected wallet as both caller and possible receiver, since the address receiving shares can differ from the signer. The wallet prompt should preserve the intended receiver rather than silently substituting another address.
- Match the pool contract and connected network to the selected opportunity.
- Match the asset contract and amount to the pool’s designated deposit asset.
-
Check the receiver’s current
maxDepositagainst the intended amount. - Compare the current share preview with the minimum outcome that remains acceptable.
- Confirm the spender, receiver, contract call, and available network-fee balance.
A nonzero share preview cannot override a lower deposit limit. Likewise, sufficient wallet funds do not establish permission to enter the pool. Each value answers a separate question, and all of them must support the same transaction before the signature creates an authorization or broadcasts a deposit.
Approval and deposit create separate commitments
A token approval authorizes a spender to transfer the specified asset within its allowance; it does not itself create pool shares. The later deposit call transfers assets and mints shares to the named receiver. Some supported contract paths can combine token approval and deposit through a permit, but the signed data still identifies an asset, spender, amount, and deadline. When approval is separate, its successful receipt should be established before the deposit transaction is prepared.
The receipt must reconcile with both balances
A completed deposit has three connected records: a successful transaction receipt, an asset movement, and a share credit. A transaction hash proves submission, not execution. Once the receipt is final, its status and Deposit event provide the executed asset and share amounts. Those values should agree with the underlying-asset debit and the share credit for the receiver named in the transaction.
The share balance is measured in vault ownership units, while balanceOfAssets expresses their current underlying-asset equivalent. Confusing those views can make a correct deposit look short or inflated. If another address was intentionally selected as receiver, its share balance carries the completion evidence. A successful receipt with no increase at that address calls for contract-level reconciliation before another transaction is sent.
Exit mechanics belong in the entry decision
The withdrawal mechanism can make a valid entry unsuitable even when a deposit is immediately available. Pools can use different WithdrawalManager configurations, including queue-based and cyclical designs. The applicable manager determines whether the holder submits a request, waits for liquidity or a window, and then redeems shares or receives assets through the configured process.
A queue-based Withdrawal Manager processes requests in first-in, first-out order as liquidity becomes available. That arrangement does not promise an immediate exit at the moment of deposit. For another configuration, timing depends on its cycle and withdrawal window. The pool’s live terms and manager address therefore belong beside the deposit checks, not after funds have entered.
Exit accounting can also differ from the entry view when a loan impairment creates unrealized losses. Maple maintains exit-aware conversion functions so those losses can affect what withdrawing shares represent. A zero maxRedeem or maxWithdraw may reflect the active withdrawal rules rather than the absence of a share balance. The next decision is whether that exit path fits the intended holding period.
Pool limits and incomplete transaction evidence define the stop conditions
A zero maxDeposit is a stop condition for that receiver at that state. It identifies unavailable capacity without identifying the cause by itself. Pool access, remaining capacity, and any active restriction must be separated before changing the amount.
Rejecting a wallet prompt leaves the proposed call unexecuted. A broadcast transaction that reverts also fails to mint shares, although a network fee may still be consumed. A rejected prompt produces no transaction receipt, while a reverted transaction produces a failed receipt.
A pending transaction has not reached the completion boundary. Submitting another deposit while its outcome is unknown can create duplicate exposure if both eventually confirm. Reconcile the pending transaction’s status before preparing a replacement or a fresh call.
A successful receipt without visible shares first calls for checking the receiver argument, connected network, and direct on-chain share balance. Interface display delays do not change the contract record. Resubmission is premature until those locations have been compared.
An unexpected asset movement or share amount requires the same bounded response: retain the receipt, compare its event values with the two balances, and stop if the discrepancy remains unexplained. The next decision is whether updated pool state supports a fresh quote or whether the attempted deposit should end.
Maple finance - common questions
When should a pool quote be refreshed before signing?
Refresh the quote after changing the asset amount, receiver, wallet, or connected network, and whenever signing has been delayed. The preview reflects pool accounting at a particular block, so later accounting activity may change the expected shares. Recheck maxDeposit at the same time because the share preview does not apply receiver limits or remaining deposit capacity.
Does a different receiver address require a new eligibility check?
Yes, the receiver should be checked independently because maxDeposit is evaluated for a specified receiving address. Permissioned pool rules may also distinguish one wallet from another. A signer who is eligible does not automatically establish that a separate receiver can accept the shares, so both the transaction argument and the receiver-specific limit need to agree.
What remains authorized if the deposit transaction reverts?
A separately confirmed token approval can remain active even when the later deposit reverts. The failed deposit does not mint shares, but it does not automatically cancel an earlier approval. If a permit-based call combined token approval and deposit in one transaction, a revert rolls back both state changes. Inspect the allowance before retrying or revoking access.
Will reducing the amount fix a deposit that was rejected?
A smaller amount helps only when the previous amount exceeded the wallet balance or the receiver’s current deposit limit. It does not resolve an incorrect asset, wrong network, ineligible receiver, paused operation, or mismatched contract. Read the failure condition first, then obtain a fresh maxDeposit value and share preview before deciding whether a reduced amount is executable.
How long should I wait before treating a pending deposit as failed?
A pending transaction has no universal failure deadline because confirmation depends on the connected network and the transaction’s fee settings. Treat it as unresolved until the network reports success, a revert, or a dropped or replaced transaction. Do not infer completion from elapsed time or submit the same deposit again while the original transaction could still confirm.