> ## Documentation Index > Fetch the complete documentation index at: https://docs.kuru.io/llms.txt > Use this file to discover all available pages before exploring further. # Withdrawal Availability > What withdrawal capacity is, how it refills, and why a withdrawal can fail even when you have funds. Every withdrawal needs two things: 1. **Available balance** in your main account for the token you are withdrawing. 2. **Withdrawal capacity**: enough room in Kuru's shared withdrawal budget to cover the withdrawal's USD value. Having funds in your account does not guarantee that a withdrawal will succeed. Capacity must also be available when the transaction executes. ## What withdrawal capacity is Withdrawal capacity is a protocol-wide limit, measured in USD, on how much value can leave Kuru over time. It is **shared across all accounts and all supported tokens**. It is not a personal or per-token limit, so withdrawals by other users draw from the same capacity as yours. Each withdrawal is valued in USD at the token's current price and uses that amount of capacity. There is **no withdrawal queue**. A withdrawal is either paid in full immediately or the whole transaction reverts. ## Where capacity comes from Capacity has two sources. ### The withdrawal bucket The main source is a single global bucket: | Setting | Current mainnet value | | - | - | | Bucket size | \$200,000 | | Refill rate | About \$8,333 per hour (about \$2.31 per second) | | Time to refill from empty | About 24 hours | The bucket refills **continuously**. It does not reset all at once at a fixed time each day. For example, if withdrawals reduce it to \$50,000, it holds about \$58,333 an hour later. It never holds more than \$200,000, so leaving it full does not build up extra capacity. ### Deposit credit Each deposit also adds one-time credit equal to the deposit's USD value. Deposit credit expires **24 hours** after the deposit, even if it is never used. Deposits do not refill the bucket. Withdrawals use the oldest unexpired deposit credit first, then draw from the bucket. At any moment, available capacity is: **unexpired deposit credit + current bucket level** Trades, fees, and transfers between subaccounts do not add capacity. These are the current mainnet settings, and governance can change them. Testnet uses different values. Read `capacityUsd18` and `ratePerSecondUsd18` on the [WithdrawalLimiter](/contracts/withdrawal-limiter) for the live configuration. ## A numbers example Assume USDC is worth exactly \$1, the bucket starts full, there is no deposit credit, and no one else deposits or withdraws. Values show the state after each event. | Time | Event | Deposit credit | Bucket | Total capacity | Result | | - | - | -: | -: | -: | - | | 00:00 | Alice withdraws 150,000 USDC | \$0 | \$50,000 | \$50,000 | Paid in full from the bucket. | | 00:00 | Bob tries to withdraw 80,000 USDC | \$0 | \$50,000 | \$50,000 | The whole transaction reverts. **Nothing is queued** or partially paid. | | 03:00 | Three hours pass | \$0 | \$75,000 | \$75,000 | The bucket refills by \$25,000. | | 03:00 | Carol deposits 10,000 USDC | \$10,000 | \$75,000 | \$85,000 | Carol's credit expires at 03:00 the next day if unused. | | 03:00 | Bob tries again with 80,000 USDC | \$0 | \$5,000 | \$5,000 | Paid in full: \$10,000 from Carol's credit, then \$70,000 from the bucket. | From \$5,000, the bucket is full again about 23.4 hours later. In practice, USD values come from live token prices, and capacity can change between a preview and the transaction. ## If a withdrawal cannot complete The transaction reverts without paying any part of the amount. Check that the funds are available in the main account, the caller has withdrawal permission, the recipient is valid, prices are current, and withdrawals are enabled. If capacity is the problem: * **Wait.** The bucket refills by about \$8,333 per hour. * **Withdraw less.** Choose an amount that fits within current capacity. * **Split large withdrawals.** A withdrawal worth more than \$200,000 can succeed only if unexpired deposit credit covers the difference. Otherwise, split it into smaller withdrawals over time. Other users draw from the same capacity, so it may be used up before your transaction executes. A preview is an estimate at the moment it is read. It does not reserve capacity or guarantee that the withdrawal will succeed. ## What a withdrawal screen should show * The account's **available token balance**. * The **current shared withdrawal capacity** in USD, and an estimated maximum withdrawal in the selected token. * A short explanation that capacity is shared, refills at about \$8,333 per hour up to \$200,000, and that deposit credit expires after 24 hours. * If the amount exceeds capacity, a warning that the whole transaction will fail rather than wait in a queue. Optionally, an estimate of when enough capacity should be available, noting that other withdrawals can use it first. Refresh the estimate immediately before submission, and do not present it as a reservation. ## Approved payouts A withdrawal can also be paid as an approved payout, which does not use shared withdrawal capacity. It requires Kuru's signature. Once Kuru signs, you can withdraw after a **6-hour timelock**. Approved payouts still check funds, pricing, freezes, and protocol pause. They are not a queue or an automatic fallback when capacity runs out. Applications implementing this route should read the [withdrawal reference](/contracts/withdrawal-limiter). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.