Redemption Operations: Potential Issues

Before enabling the planned redemption workflow, account for the issues below. The sequence is workable with the existing Vault, but a database request, manager approval, confirmed burn, funded claim, and completed payout represent different milestones.

1. Authorization To Request And Claim

A PostgreSQL request does not grant blockchain permissions. To initiate requestRedeem, the caller must be the share owner, an approved operator, or a caller with sufficient share allowance. An authorized delegated wallet can also execute as the investor. The fund manager's fulfillment role alone does not authorize taking investor shares.

Claiming requires separate authority: the investor/controller, their approved operator, or authorized execution through their wallet. Share allowance alone does not authorize a claim. Keep the investor as the redemption controller and bind the intended payout receiver to the authorized operation.

Prior authorization must identify the Vault, chain, investor, permitted actions, total share limit across batches, validity period, and applicable pricing terms. Check remaining authority before every batch, including amounts already committed to in-flight operations. Expiry or revocation must stop new execution; it cannot undo a transaction that has already succeeded.

2. Shares Can Change While A Request Waits

Recording a request does not lock shares. The investor may transfer them, submit another request, or become unable to redeem because of token restrictions before the manager acts.

Track reservations across business requests to prevent duplicate commitments, and recheck spendable shares and permissions at execution. Database reservations cannot prevent transactions outside the platform. If execution fails before the burn, retain an unexecuted request rather than recording a successful redemption.

3. Funded Cash Is Not Yet Reserved For A Batch

Check free USDC, not the Vault's total token balance. Funds reserved for deposits or existing claimable redemptions are unavailable for a new fulfillment.

Moving USDC into the Vault does not assign it to a particular investor. Another fulfillment or strategy drawdown can consume free liquidity before the selected batch executes. Coordinate approvals and funding in the backend; the contract's liquidity check remains decisive. The payout becomes reserved only after successful fulfillRedeem.

When returning money previously drawn into the strategy, use returnStrategyAssets with the required allowance so the transfer and strategy accounting agree. A plain USDC transfer into the Vault does not reduce its recorded strategy assets.

4. Execution Can Stop After Shares Burn

In the current Vault, requestRedeem burns shares and records a pending entitlement. fulfillRedeem subsequently reserves the payout, and redeem or withdraw transfers it. Separate transactions do not roll back together. There is no ordinary cancellation operation that restores shares after a successful request.

Persist each batch and its operation identities, reconcile uncertain outcomes before retrying, and resume from the last confirmed step. A failed or timed-out fulfillment must not cause another burn. Completion must use canonical confirmed evidence and account for chain reorganizations.

Atomic request and fulfillment could ensure that a burn and its funded claim succeed together, but that requires a compatible execution path with the correct permissions and rollback behavior. It is not a guarantee of the current separate-transaction flow. An asynchronous flow with explicit recovery remains a valid option.

5. Approved Pricing Must Match Fulfillment

The manager sets the batch price before approval. The Vault does not independently verify that NAV: fulfillRedeem receives the exact shares and assets, which establish the on-chain exchange ratio.

Bind the share amount, price, rounded USDC payout, investor controller, and Vault to the approval. Use exact token units. Retrying the same approved operation must preserve those terms; a change requires a new approval before execution. Keep business submission, approval, on-chain request, and pricing dates distinct so a processing delay does not silently change the applicable price or queue priority.

6. Partial Batches And Claims Need Separate Accounting

Keep the original business request and its unprocessed remainder separate from the accepted execution batches. Each batch needs its own share amount, approved payout, and request, fulfillment, and claim evidence.

The Vault aggregates pending and claimable balances by investor controller; it does not retain the PostgreSQL request or batch identifiers. The current backend waits for earlier claims before fulfilling more for that controller. Allowing several outstanding fulfilled batches requires reconciliation of their combined balance: a partial claim does not identify an individual business batch.

Do not mark the parent request fully completed after the first batch is paid. Require all requested shares to be processed and all payouts fully claimed. If the unexecuted remainder is cancelled, record that outcome separately.

7. Delegation Does Not Automatically Enable Claims

EIP-7702 delegation alone does not define the allowed actions or make a multi-step operation atomic. Check the actual wallet implementation and investor permissions for both request and claim execution.

The checked-in scoped executor accepts individual request and fulfillment calls, but does not permit redeem or withdraw claims or provide the complete atomic batch. Its request path also requires the share owner to be the executing wallet. Automatic claims therefore need a compatible investor-authorized execution path; they must not be assumed available just because a wallet has delegation enabled.

8. External Payments Do Not Close Vault Claims

A USDC transfer directly from the fund wallet to the investor does not consume the Vault's pending or claimable entitlement. An already fulfilled claim would remain available, creating a risk of paying twice. Marking the database row paid cannot change that contract state.

For this workflow, settle through the Vault's claim operation and reconcile the actual payout. A failed claim transaction leaves the claimable entitlement intact; it does not reverse an earlier successful burn. Reserved cash stays in the Vault until claimed, even if the fund otherwise keeps its assets invested.

Return to Redemption Operations.