Fund Treasury Vault

See Core Concepts for the custody model and wallet naming this page assumes.

Important: The "Fund Treasury Vault" is the fund's ERC-7540 Vault smart contract, not an independently signing wallet. Its operations are authorized by the fund wallet or investor controller, depending on the operation.

It holds fund USDC, records asynchronous subscription and redemption requests, exposes claimable results, and represents fund shares through its ERC-20 interface.

Assets And Shares

Item	Meaning
Asset	USDC held by the Fund Treasury Vault.
Share	The ERC-20 fund share represented by the Fund Treasury Vault contract.
Pending deposit	USDC has entered the Fund Treasury Vault, but the asset/share pair is not claimable.
Claimable deposit	Fulfillment has fixed the asset/share pair and the investor can claim shares.
Business redemption request	An investor's request recorded in PostgreSQL before on-chain execution; it does not lock or burn shares.
Pending redemption	requestRedeem has burned the selected shares and recorded a redemption entitlement awaiting fulfillment.
Claimable redemption	Fulfillment has reserved the asset amount and the investor can claim USDC.

Subscription Operations

1. The fund wallet approves the exact USDC allowance.
2. requestDeposit pulls the approved USDC into the Fund Treasury Vault and records a pending deposit.
3. The fund manager sets the price per share in the Fulfill in Vault popup, which calculates the exact share quantity and prepares the fulfillment operation.
4. The fund wallet authorizes fulfillDeposit after pricing and protocol checks are ready.
5. The investor authorizes deposit to claim the already-issued shares, transferring them to the investor's wallet.

Manager acceptance does not record pricing. The Fulfill in Vault operation is the only step in this workflow that may change price_per_share, and it is also when shares are issued (minted) — they are then held by the Fund Treasury Vault until the investor claims them. Claiming transfers the already-issued shares to the investor's wallet; it does not mint new shares.

Redemption Operations

The planned stablecoin redemption workflow starts with a business request in PostgreSQL. Blockchain execution begins only after the manager has selected an amount, set its price, and provided the required liquidity. The existing Vault supports the contract operations below; backend orchestration and delegated execution must satisfy the linked requirements before this flow is enabled.

1. Record the request. The investor submits the number of shares they want to redeem. The backend stores the request in PostgreSQL without calling requestRedeem. Shares remain in the investor's wallet at this stage. Prior investor authorization is required for the manager or platform to execute later on their behalf.
2. Prepare the amount, price, and funds. The manager selects all or part of the requested shares, sets the NAV per share for that batch, and confirms the calculated USDC payout. The manager provides sufficient free USDC in the Fund Treasury Vault before approving execution. Only the amount needed for settlement must return from the strategy; the rest of the fund can remain invested.
3. Approve execution. Once the price, liquidity, share availability, and investor authorization prerequisites are satisfied, the manager approves the selected batch. Approval starts processing; it is not proof that a blockchain transaction has succeeded.
4. Initiate the on-chain request. The manager or platform uses the investor's authorization to execute requestRedeem for the approved share amount, keeping the investor as the share owner and redemption controller. In the current Vault implementation, successful execution burns those shares and records a pending redemption entitlement. A database approval alone does not burn shares.
5. Fulfill the redemption. The fund wallet, as the Vault's authorized fulfillment controller, executes fulfillRedeem with the approved shares and exact USDC payout. This records the approved share/asset pair on-chain, reserves the payout, and makes it claimable. requestRedeem alone does not make a payout claimable.
6. Claim the payout. The investor calls redeem or withdraw to claim the USDC from the Fund Treasury Vault. The platform may perform this step automatically only with appropriate investor authorization and a compatible execution path. Manager approval or fulfillment authority does not itself grant permission to claim for the investor.
7. Reconcile and repeat. The backend links each batch's confirmed request, fulfillment, and claim to the original business request. Any unprocessed remainder stays in PostgreSQL for a later batch, with its own price and funding prerequisites. The original request is fully completed only when no requested shares remain outstanding and every batch has been fulfilled and fully claimed. Partial claims remain unfinished; a cancelled remainder must be recorded separately from a fully paid request.

Request, fulfillment, and claim are distinct contract operations. One business approval does not make them atomic. If execution stops after a confirmed request, the backend must resume that outstanding redemption without burning the same batch again.

See Redemption Operations: Potential Issues for authorization, liquidity, interruption recovery, and batch-accounting requirements.

See Redemption Workflow for the current interactive manager and investor handoffs from business request through payout.

Liquidity Boundary

Free USDC can move from the Fund Treasury Vault to the fund wallet through drawdownStrategyAssets. Approved USDC can return through returnStrategyAssets. Assets reserved for claimable redemptions are not available for strategy drawdown. The current Vault Operations page monitors these balances but does not expose drawdown or return buttons.

Operator Rules

• Verify the canonical pending request and controller before fulfillment.
• Wait for finalized dealing NAV and liquidity readiness where required.
• Submit fulfillment once and wait for chain-backed reconciliation.
• Treat Pending, Claimable, and Claimed as distinct states.
• Never treat manager acceptance or fulfillment as the investor's claim.

Return to Investment Management.

Revision History

Version	Date	Change
1.1	2026-09-14	Renamed "Self-Custody Wallet" to "fund wallet." Corrected redemption timing to match the confirmed model: shares lock at request, burn at Accept — not burned immediately at request. Added Core Concepts linkage. Corrected share-issuance timing: shares are issued (minted) at Fulfill in Vault, held by the Fund Treasury Vault, and transferred (not minted) at investor claim — this page previously said the opposite; Core Concepts was correct. Underlying operations and ERC-7540 characterization unchanged.
1.2	2026-09-14	Split the merged accept+price redemption step into two distinct steps — Accept (burns shares, no price yet) and a separate Price and Fund step once NAV is available — matching Core Concepts' Accepted / Priced & Funded stages, which this page had collapsed into one action.
1.3	2026-09-17	Corrected the redemption steps again per Jay's own written process: Accept can be partial (manager enters a share amount to burn, rest stays pending), added a distinct funding step (manager sends liquidity to the vault) between Accept and fulfillment, and moved pricing to happen at the fulfillRedeem signature itself rather than an earlier review screen. Removed the "required fix" danger callout — folded directly into the plain step text once the order itself was correct. Investor's claim step now describes the action in plain English only; the underlying function name is explicitly unconfirmed.