Imagine you've deposited stablecoins into a pool on cSigma. A few weeks later, you decide to pull some funds out. You hit Withdraw and expect the money back shortly- the way a normal bank transfer would work. 

But lending pools don't sit on idle cash. The whole point is that your funds are put to work: deployed to where the interest is generated. So, when you ask to withdraw, the platform must answer a harder question than "can I send this back?" It must figure out how much is available right now, how much is still out earning, and what happens to the gap. 

What "Withdraw" Actually Means in a Deployed Pool?

A withdrawal isn't a single tap. It's a short journey that starts when you submit a request and ends when the funds are back in your wallet. If the pool has enough sitting idle, your request settles immediately. If it doesn't, your request joins a queue, waits for funds to return to the pool, and becomes collectible once that happens. Two separate steps - one to request, one to collect - with a transparent process in between.

What Changed for Lenders? 

Before- Withdrawal was treated as all-or-nothing. If the pool didn't have enough available, the platform blocked you from proceeding and showed a message. There was no way to queue your request or track it- just a dead end. 

After- On both Edge (master pool deposits and yield-bearing token redemptions) and Institution (Atlas master pools), the flow is now transparent. The platform shows you upfront how much can be paid out immediately from available funds, and how much will enter a queue. What can be covered right away is returned straight to you; the rest is tracked as a pending position you can monitor and collect when it becomes available. 

The Reserve: Your First Exit

The reserve is the portion of the pool's total funds that hasn't been deployed- the liquid buffer kept available for withdrawals. 

When you request a withdrawal, the platform checks this buffer against what you're asking for. If it covers your full amount (after accounting for others who queued ahead of you), you receive your funds in one step. If not, whatever the reserve can cover is returned immediately, and the remainder enters the queue. An important nuance: the reserve isn't simply "cash on hand"- it's cash on hand minus what earlier queued lenders are already owed. Your request is evaluated against what's genuinely free. 

The Withdrawal Queue: Waiting in Line, Fairly 

When your full request can't be served from the reserve, it joins the withdrawal queue. The queue is strictly first-in, first-out - every lender is served in the order they requested. 

Each position in the queue tracks how much you're owed and how much has been paid out so far across the whole queue. As funds return to the pool, the system works through entries in order, marking each one as fulfilled when there's enough to cover it. Your wait time depends on where you sit in the line and how quickly capital flows back from deployed positions- both visible to you, not hidden behind the scenes. 

How the Queue Gets Fulfilled: Two Paths Back to Lenders?

The queue doesn't rely on a single trigger. There are two ways funds can return, and positions get fulfilled.

Path A- New deposits build the reserve: When a new lender deposits into the master pool, not all of it gets deployed. A fixed percentage- say, 5%-is held back as reserve. This reserve accumulates as deposits come in, but it doesn't automatically reach queued lenders. The pool manager still needs to trigger a notification to direct that reserve toward the queue. Once they do, pending positions are paid out in order using the available reserve amount. 

Path B- Pool manager returns deployed funds: When the pool manager moves capital back from a deployed position into the pool's reserve, the system automatically checks whether there are any pending queue entries. If there are, it fulfils them in order using the returned amount - no manual step required. The funds land, the queue advances, and the relevant lenders find their positions ready to collect. 

In both cases, once your position is fulfilled, you collect your funds through a separate Claim step, which transfers the actual tokens into your wallet. This deliberate split between fulfilment and collection gives lenders control over when they take custody and keeps the queue's accounting clean regardless of when each lender claims. 

What You See in the Platform: Three Clear States 

A flow like this only works if the interface shows you what's actually happening.

Your deposit moves through a lifecycle, and Edge and Institution surface the parts that need your attention. While your funds are in the pool, they're earning yield - that's the default state of being a lender, so no separate label is needed. The moment you request a withdrawal, two explicit states come into view. Pending is what's sitting in the queue, waiting to be fulfilled, displayed as the pool share amount you're owed. Importantly, a pending position keeps earning yield right up until it's fulfilled- waiting in the queue doesn't mean your capital sits idle. Claimable is what's ready to collect- shown in the actual token you'll receive (e.g., USDC), with a Claim button that only activates when funds are genuinely there. Once a position becomes claimable, it stops earning; it's now sitting aside, ready for you to take custody. These states are read directly from the blockchain, not estimated or cached, so what you see on screen is exactly what you can act on.

This is the part of the design that matters most for trust. The queue can be ordered, and the managers can be diligent- but if you can't tell whether your withdrawal is still earning in the queue or ready to pick up, you can't plan around the flow.

This is the part of the design that matters most for trust. The queue can be ordered, and the managers can be diligent- but if you can't tell whether your funds are still earning, waiting, or ready to pick up, you can't plan around the flow. 

What Pool Managers See on the Other Side?

The withdrawal queue isn't just a waiting room for lenders- it's an operational view for pool managers. 

The manager dashboard shows every pending entry: who is owed what, where their position sits in line, and the total capital needed to clear the queue to any given point. Withdrawals stop being unpredictable events and become a trackable obligation- a number, an order, and a clear set of actions to work through it. 

What Does This Mean Going Forward?

Treating withdrawal as a lifecycle, rather than a pass/fail transaction, opens up better features over time. Clear states make it possible to add things like estimated wait times, partial-claim flows, and pool health indicators that show whether a queue is actively moving or stalled. 

It also sets a more honest expectation with users. Instant withdrawal is something a deployed lending pool can't always guarantee, and the queue is the honest answer to that constraint- not a workaround, but a deliberate design choice that keeps every lender's position safe and fairly ordered. 

Closing 

A lending pool is built to keep capital working. The withdrawal flow exists to make getting it back feel predictable and fair- a clear path for lenders, a manageable obligation for managers, and no surprises in between. The reserve buffer, the queue, and the two fulfilment paths aren't separate mechanics- they're one system built around a straightforward goal: your funds, back to you, in order.