Folks finance withdrawals depend on available pool liquidity
Folks finance limits withdrawals of underlying assets to the liquidity available in the relevant lending pool. Your deposit balance can therefore exceed the amount the pool can release. A smaller withdrawal may succeed when the full amount cannot, provided your position satisfies collateral requirements and the transfer meets applicable controls. Before signing, you can change the amount or stop. After submission, the transaction’s actual state determines the next action: an unprocessed request, a failed cross-chain message, and a completed withdrawal require different handling. Completion means the intended assets reached the receiving address and the deposit record reflects the withdrawal.
Requesting less when the full balance is unavailable
The ordinary withdrawal path releases a chosen amount from an existing deposit, subject to the pool and account checks applying when execution occurs. In the Algorand app, the withdrawal control sits beside the deposited asset, where the amount is entered before wallet authorization. For xChain, the cross-chain lending app, check before signing that the asset supports the receiving chain and that the intended receiving address is registered to your account on that chain. An available balance alone doesn’t establish that the entire amount can leave the pool.
When liquidity is the binding restriction, a smaller request can fit within available capacity. Waiting for additional liquidity is another possibility. Neither action removes a separate collateral restriction, and reducing the amount won’t resolve an unrelated message failure.
Pool liquidity sets the immediate redemption ceiling
Borrowed assets are unavailable for immediate redemption, so the pool must compare a requested withdrawal with the liquidity remaining after outstanding borrowing. The depositor’s recorded entitlement and the pool’s available assets answer different questions.
The xChain pool contract rejects an underlying-asset withdrawal when its amount exceeds calculated available liquidity. That check occurs during execution. An earlier display can’t reserve the same liquidity against other transactions. Deposits and repayments made with incoming assets can replenish liquidity, while borrowing and withdrawals consume it. Consequently, a request fitting the displayed amount can encounter different conditions by the time the contract processes it.
Collateral creates a separate limit on withdrawal
A deposit supporting debt can face a tighter withdrawal limit than pool liquidity allows because the remaining collateral must continue supporting the outstanding loan.
Borrowing capacity depends on collateral amounts, asset prices, and the applicable collateral factors. Removing collateral reduces that capacity. The withdrawal calculation must account for the position after removal, including its outstanding borrowing. Even a well-funded pool cannot make an otherwise invalid collateral withdrawal permissible.
The Algorand app distinguishes ordinary deposit withdrawal from reducing collateral through loan management. The xChain withdrawal process also checks the resulting collateral position. Repaying debt can reduce the collateral requirement, although it doesn’t automatically resolve every pool or transfer constraint. A collateral restriction calls for reviewing the loan position; a liquidity shortage calls for reviewing the pool’s available assets.
What can I change after requesting a withdrawal?
You can revise an unsigned withdrawal, but a submitted request must be handled according to its execution state rather than edited like a draft.
Closing a wallet prompt before authorization stops that unsigned request. Closing the app after submission doesn’t cancel an operation already sent to the network. Once a withdrawal completes, putting the assets back requires a new deposit subject to the conditions applying then. It doesn’t erase the withdrawal or restore earlier rates. Cross-chain recovery functions address specific failed messages; they aren’t a general undo button for completed transfers.
Matching the deposit reduction to received assets
A completed withdrawal should reconcile the amount removed from the lending position with the underlying assets delivered to the intended receiving address. The transaction record helps distinguish a completed transfer from a display awaiting an update.
In xChain, lending state changes occur on the hub, while delivery can require a message to the receiving chain. A successful initiating transaction therefore doesn’t, by itself, establish that the receiving address has the assets. The relevant records include the withdrawal amount, its execution status, and the destination transfer. A balance reduction without confirmed delivery requires examining the remaining message status.
Compare quantities in the same asset units. A changing currency valuation can’t establish how many tokens the withdrawal delivered.
Failed cross-chain messages need the matching recovery action
A failed xChain withdrawal message can require a retry after its cause is resolved, with the appropriate permissions and message details. Repeating the original withdrawal as a fresh request is a different operation.
The messaging router records failures with their message identifiers and error information. Those records distinguish a failed instruction from one still awaiting delivery.
At the hub, retry processing retains the withdrawal instruction while allowing specified return-message settings to change. It doesn’t provide a general way to rewrite the requested amount. The hub’s reversal function handles failed messages for deposits, repayments, and creating a loan with a deposit. It doesn’t reverse a withdrawal request. The token-receiving contract also supports retrying a failed delivery rather than reversing it.
An unresolved message remains relevant even when the app window closes. Its later execution could still change the position or deliver assets.
A partial withdrawal leaves a measurable remainder
Consider a hypothetical deposit worth 847 units of its underlying asset, with a planned withdrawal of 317 units and available pool liquidity of 367 units. Assume the deposit has no outstanding debt, the destination is supported, and all other checks pass. The arithmetic holds interest and rounding effects constant and treats transaction fees separately.
The planned amount fits within the available liquidity. After reviewing the amount and destination, the depositor signs the request. If execution and delivery complete for 317 units, the receiving address gains that amount and the deposit remainder is 530 units: 847 minus 317. The withdrawal record and destination receipt establish the result.
Now change one condition before signing: available liquidity falls to 227 units. The original request no longer fits. The depositor stops that unsigned request and chooses 227 units instead. If those conditions hold through execution, a completed withdrawal leaves 620 units deposited: 847 minus 227.
The remaining 620 units aren’t a scheduled payout. A later withdrawal needs a fresh liquidity check. If the original request had already been submitted, its status would need resolving before treating it as abandoned.
Interest accrual doesn’t supply immediate cash
A deposit can continue accruing interest under the lending model while available liquidity remains too low to redeem its full underlying value.
Utilization measures borrowing relative to total deposits. Higher utilization generally raises borrowing costs and deposit returns through the rate model, encouraging a change in supply and demand. That incentive doesn’t compel an immediate repayment or new deposit. An increasing deposit balance can therefore coexist with limited withdrawal capacity. Interest describes the position’s accounting growth; available liquidity describes what the pool can release at that moment.
Transfer capacity can constrain a funded withdrawal
xChain transfer limits can restrict outgoing delivery even when the lending pool has sufficient liquidity and the account passes its collateral checks.
These controls limit transfers within configured periods. The token-receiving contract checks available transfer capacity before sending assets to the recipient. A failure at that stage concerns delivery capacity, so comparing the withdrawal amount only with pool liquidity misses the cause. The failed message and error identify the relevant restriction. Capacity settings and message conditions determine whether a retry can proceed; the pool balance alone cannot provide a completion time.
A completed exit preserves its transaction history
Withdrawing the full eligible balance removes that deposit exposure once delivery completes, while the withdrawal remains part of the transaction history.
The remaining position record matters when the account has other deposits or borrowing. An empty balance for one asset doesn’t establish that every obligation has ended. In xChain, deleting a loan requires the loan to be empty; deletion is separate from transferring withdrawn assets. Neither operation rewrites earlier confirmed events.
For reconciliation, retain the transaction identifiers and the amounts actually executed. A withdrawal entry records the lending change, while a destination transfer records receipt. In xChain, the named lending event is
Withdraw.
Everyday questions about Folks finance
-
Does high pool utilization mean my deposit has been lost?
- High utilization means a large share of deposited assets has been borrowed; it doesn’t by itself establish a loss. It explains why immediately available liquidity can be small. Determining whether a separate loss occurred requires evidence beyond the utilization figure, such as the actual position accounting and any unrecoverable debt.
-
Are transaction costs still payable for a partial withdrawal?
- A partial withdrawal still requires transaction processing and can incur network costs. Cross-chain operations also involve messaging costs determined by the selected messaging mechanism and its parameters. Reducing the withdrawal amount doesn’t necessarily reduce those costs proportionally, so several separate withdrawals can cost more than one.
-
Can withdrawing fTokens give me the underlying asset during a liquidity shortage?
- fTokens represent a claim on deposited assets; receiving them doesn’t itself deliver the underlying asset. In xChain, the separate fToken withdrawal operation is subject to pool configuration and collateral checks. It changes how the deposit claim is held. Redeeming that claim for the underlying asset still requires the liquidity needed for that redemption.
-
Which receiving chain can an xChain withdrawal use?
- The receiving chain must be compatible with the withdrawn asset, and delivery uses the address registered to the account on that chain. A matching token name elsewhere doesn’t establish compatibility. The chain and registered receiving address belong to the withdrawal’s routing requirements, independently of whether enough pool liquidity exists.
-
How does rounding affect an exact withdrawal amount?
- xChain converts between underlying-asset amounts and fToken amounts using the deposit interest index and defined rounding rules. When the request specifies an underlying amount, the required fToken amount rounds upward. Displayed balances may hide that precision, so the executed amount and remaining position are more useful for reconciliation than rounded screen totals.
-
When a lending pool is deprecated, can an existing deposit still be withdrawn?
- The xChain underlying-asset withdrawal logic permits withdrawals from a deprecated pool, subject to liquidity and the other applicable checks. Deprecation blocks certain new activity without automatically disabling this exit operation. This rule doesn’t mean a deprecated pool always has enough liquidity, and the separate fToken withdrawal operation is blocked when the pool itself is deprecated.