Fund Detail: Investment Management
See Core Concepts for the custody model, wallet naming, NAV timing, and the Investment Capacity mechanics this page assumes.
Operations By Screen Group
The groups below use project-owner operating labels and list every operation required to move an entry forward.
Subscriptions
Fiat Funding And Bank Tracking
For a fiat investment, Tahoe provides the investor with the fund's designated bank account details (account and routing information) needed to complete their transfer. Tahoe tracks that bank account and watches for incoming funds matching the investor's expected transfer. Once funds are confirmed received, the investment is ready for the fund manager to Accept.
Incoming Request
An investment amount must fall within the investor's remaining investment capacity for this fund. Enforcement differs by rail:
- Stablecoin — enforced upfront. The frontend should not allow an investor to submit, or a manager to accept, an investment that exceeds remaining capacity — this is a system check, not a manual judgment call.
- Fiat — cannot be enforced upfront, since the investor can technically send whatever amount they want since it's via their bank, and funds are already in the fund's bank account by the time anyone reviews the investment. If the amount received exceeds the investor's remaining capacity, the manager needs to be shown that clearly and prompted to request an updated subscription agreement from the investor (raising their cap) before accepting and issuing shares.
| Button name | Underlying operation | Explanation |
|---|---|---|
| Accept | POST /auth/funds/{slug}/investments/{investment_id}/accept | Records the manager acceptance time and optional note. For a stablecoin investment, accepting triggers the fund movement flow below: an approve transaction (1/2) followed by a send-to-vault transaction (2/2), which is what actually moves the funds from the holding position into the vault. For a fiat investment, there is no on-chain movement to trigger — funds have already arrived in the fund's designated bank account; accepting records the acceptance and prepares the system for the share issuance step. |
Movement Of Investment Funds After The User Selects "Accept" (Stablecoin Only)
Tahoe exposes both on-chain controls through its native fund-owner signing UI. Each prepared operation requires its own verification code. This is authorized through the fund's wallet infrastructure — see Core Concepts for the Manager Signing Wallet and Fund Holding Wallet.
| Button name | Underlying operation | Explanation |
|---|---|---|
| Approve spending (1/2) | USDC.approve(Vault, assets) | The fund wallet grants the Fund Treasury Vault an exact allowance. No money moves. |
| Send to Vault (2/2) | Vault.requestDeposit(assets, investor, fundWallet) | The fund wallet authorizes the request. The Fund Treasury Vault pulls the exact USDC amount with transferFrom and records the deposit as Pending. |
Pending Share Issuance (These Transactions Are In A Single Button, Not Two)
| Button name | Underlying operation | Explanation |
|---|---|---|
| Issue Shares | POST /auth/funds/{slug}/investments/{investment_id}/fulfill with pricePerShare | Opens the fulfillment popup. The fund manager sets the price per share — see Core Concepts → How NAV Pricing Works: this price applies to this specific transaction only, not the fund's most recently entered NAV, and does not set the fund's NAV. The last recorded NAV is shown as reference text for context. The fund manager reviews the calculated share quantity and submits the canonical fulfillment command. The backend stores price_per_share and the amount of USDC or fiat invested, calculates the exact share quantity, and prepares the fund-owned fulfillment operation. |
| Sign Vault fulfillment | Vault.fulfillDeposit(assets, shares, investor) | Tahoe exposes the native owner-signing handoff for the exact asset and share quantities prepared from the fulfillment price. The deposit moves from Pending to Claimable. |
Claimable From Vault (Hidden From The Manager UI, Visible To The Investor)
| Button name | Underlying operation | Explanation |
|---|---|---|
| No manager button: Investor claims shares | Vault.deposit(assets, investor, investor) | The investor selects Claim RWA. Tahoe prepares and submits the investor-authorized on-chain claim through its native wallet handoff. The Fund Treasury Vault issues the fulfilled shares to the investor; the fund manager only monitors this group. |
Redemptions
Awaiting Vault Fulfillment
The investor requests redemption, locking the requested shares and entering the pending redemption queue. Shares are held, not yet burned. When the investor locks the redemption request, they see an estimated redemption value on their side, with a disclaimer: final amount is subject to change with final execution. The final NAV may come in above or below the estimate if something changes between request and execution — this is normal, not an error state. Canonical requests originating outside the app enter this same queue (if any).
- The manager clicks Accept and enters the amount of shares to burn now — this can be a partial amount, leaving the remainder pending, unless the manager performs a full redemption. Accept alone burns the entered amount of shares — no price is set yet. Any pending remainder waits for the manager to come back and accept more of it later; this Accept → Fund → Fulfill sequence can repeat more than once for a single original request until it's fully satisfied.
- Separately, once the manager has a NAV and funds available, the manager sends funds to the Fund Treasury Vault to prepare for the payout.
- Once liquidity is in the vault and the manager is ready to execute, the fund manager signs the exact
Vault.fulfillRedeem(shares, assets, investor)operation, entering the NAV per share being used and confirming the payout amount for the shares being fulfilled at that NAV. This is where pricing actually happens — not on an earlier review screen. The UI distinguishes awaiting signature, submitted, and confirmed. - If liquidity is insufficient at that moment, the manager waits and retries once funds are in place — a changed price on retry starts a fresh confirmation rather than reusing a stale one.
Fulfillment reserves claimable USDC. It does not claim proceeds for the investor.
Fiat redemption payout — not covered by the on-chain operations above. Per Core Concepts: the fund manager sends the bank transfer directly from the fund's own bank account, then manually clicks a Paid Out action in Tahoe to record the payout for ledger purposes — Tahoe has no visibility into the bank transfer itself. There is no separate investor claim step for fiat; the bank transfer itself completes the payout.
Claimable From Vault
This is the current replacement for the screenshot's Pending Payout group. It is hidden from the manager UI but is visible to the investor.
| Button name | Underlying operation | Explanation |
|---|---|---|
| No manager button: Investor claims proceeds | Vault.redeem(shares, investor, investor) — name not finalized | The investor selects the claim action. Tahoe prepares and submits the investor-authorized on-chain claim through its native wallet handoff. The Fund Treasury Vault transfers the claimable USDC to the investor's wallet. |
Investor Holdings
Lists investors currently holding shares in this fund.
Invite Investor
A new action alongside investor holdings that lets the fund manager bring another investor into this specific fund:
- Existing investor (already onboarded elsewhere in the organization, not yet part of this fund) — the manager selects them from a picker and invites them into this fund. This uses the same underlying flow as Add Subscription on their Individual Investor Profile — a signature draft, e-signed subscription agreement, investor confirmation, then Issue Shares — just started from this fund's side instead of the investor's profile.
- New investor — starts the standard invite-new-investor flow (invitation, acceptance, KYC, onboarding form and subscription agreement, review, approval, wallet provisioning), pre-scoped to this fund.
Inferred, not confirmed
The claim that "Invite Investor" and "Add Subscription" trigger the identical underlying flow from two different entry points is Claude's inference from how the pieces fit together, not something confirmed. Flag if that's wrong.
Reporting
| Button name | Underlying operation | Explanation |
|---|---|---|
| Export Fund Investors | GET /auth/investors/export with the current fund filter | Downloads the fund-filtered investor CSV. This does not change wallet, subscription, or redemption state. |
Actors And Permissions
Authentication on the Vue route is not the authorization boundary. The fund-manager API enforces the permissions below for the current site and fund.
| Actor | Read the page | Accept investment | Authorize wallet operation | Fulfill deposit or redemption |
|---|---|---|---|---|
| Owner | funds.read | subscriptions.write | funds.write | funds.write |
| Admin | funds.read | subscriptions.write | funds.write | funds.write |
| Ops | funds.read | subscriptions.write | funds.write | funds.write |
| Auditor | funds.read | Not permitted | Not permitted | Not permitted |
| Investor | No manager access | Not applicable | Authorizes only investor-owned claim/request operations | Claims shares or proceeds in the investor fund page |
The Manager Signing Wallet holder receives the emailed code used for fund-owned authorizations. A manager's page access does not make that manager a wallet holder.
Revision History
| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-08-24 | Initial source-backed description of Investment Management operations. |
| 1.1 | 2026-09-14 | Updated wallet naming (Manager Signing Wallet / Fund Holding Wallet, replacing Self-Custody Wallet). Added capacity-check requirement before Accept, fiat funding and bank-tracking flow, fiat redemption payout description, and NAV-reference-display note. Corrected redemption burn timing to match Core Concepts (burn at Accept, not Request). Underlying operations (function signatures, routes) unchanged except where the burn-timing fix requires Vlad's team to align the contract behavior. |
| 1.2 | 2026-09-14 | Added Investor Holdings section with a new "Invite Investor" action — bring an existing organization investor into this fund, or start the standard new-investor invite flow, pre-scoped to this fund. Inferred (flagged, not confirmed) that this shares its underlying flow with Add Subscription on the Individual Investor Profile. |
| 1.3 | 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. Flagged that the underlying endpoint may need to split in two, or gain a new accept action — route unconfirmed. |
| 1.4 | 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 the old "Review redemption price" screen, which is removed. Removed the now-inaccurate POST .../redemptions/{redemption_id}/fulfill route reference along with the danger callout — folded directly into plain step text. Investor's claim step (Vault.redeem) flagged inline as a name that isn't finalized. |