Core Concepts

Every page in this directory assumes the reader already understands a few things about how Tahoe works. This page states those things once, plainly, so no other page has to re-explain or re-derive them, and so nobody (human or AI) has to guess.

If a claim on another page ever seems to contradict something here, this page wins. Flag the conflict for correction.

Tahoe Provisioned wallets as defaults

Neither fund managers nor investors hold private keys, manage a seed phrase, or sign a raw onchain transaction themselves. Tahoe provisions a wallet for each side, scoped to their role. Nobody using Tahoe needs to know or care that their actions happen onchain at all.

Actor	Wallet	What they authorize
Fund manager	Manager Signing Wallet (one per person with permission)	Fund-controlled actions: accepting investments, issuing shares, moving funds to trusted addresses, fulfilling redemptions
Fund (no direct operator)	Fund Holding Wallet (one per fund, shared)	Holds fund assets before they move into the Fund Treasury Vault — only moves when directed by an authorized Manager Signing Wallet action
Investor	Tahoe-provisioned investor wallet	Their own subscription and redemption actions: requesting, claiming

A future version may offer true self-custody (the fund manager holding their own keys) as an option. It is not the default today, and no current page should describe it as though it already exists.

What "Signing" Means

Every page in this directory uses the word "signs" — the fund wallet signs fulfillDeposit, the investor signs redeem, and so on. On Tahoe, this never means a person is presented with a raw transaction and a private key. It means:

1. The person is sent a 2FA code.
2. Entering that code is their proof of authorization for the specific action.
3. Tahoe's backend then executes the onchain action on their behalf.

This is true for every money-moving or share-moving action, for both fund managers and investors, with no exceptions in the current product.

The Wallets on a Fund

Every fund has three distinct wallet concepts. Confusing them is the single most common source of misunderstanding in earlier drafts of these docs.

Wallet	What it is	What it does
Manager Signing Wallet	One per person whose role has permission for these actions	Authorizes fund-controlled actions via 2FA: approving spend, accepting investments, issuing shares, fulfilling redemptions, moving funds to a trusted destination
Fund Holding Wallet	One per fund, shared across all managers on that fund	Holds fund assets before they move into the Fund Treasury Vault. No one operates it directly — it only moves when directed by an authorized Manager Signing Wallet action.
Fund Treasury Vault	The deployed vault contract itself	Physically holds USDC, tracks pending and claimable balances, and implements the fund's share token

The Manager Signing Wallet authorizes and directs; the Fund Holding Wallet holds, on direction only; the Fund Treasury Vault holds and settles. No fund manager or investor personally controls the keys to any of these.

Planned: multi-signature support for the Manager Signing Wallet. The fund manager will define an approval threshold and designate which people can check or sign a given wallet action, so a single person cannot unilaterally move funds. This is an approved future scope item, not a current capability. Implementation approach is undecided and may change before it's built. Will be added in V2 or V3.

How NAV Pricing Works

NAV is set per transaction, not per period. There is no "current NAV" that automatically applies to whatever happens next. Each time a transaction is fulfilled in the vault, the fund manager enters the price for that specific transaction at that moment.

To give the manager context without implying a default:

• The Record NAV screen shows the last recorded NAV as small reference text near the entry field.
• The Fulfill in Vault / execute-order screen also shows the last recorded NAV as small reference text.

In both cases this is read-only reference information. It is never pre-filled and never applied automatically.

All price changes are displayed on a preview confirmation screen before final execution.

Investment Capacity

Every investor has an investment cap per fund, set by their most recently approved subscription agreement — a fund-manager-authored template the investor fills in with their intended investment amount and e-signs. Accepting the subscription agreement includes the fund manager counter-signing it.

• The cap accumulates, it isn't a one-time allowance. An investor can sign a $5M agreement, invest $2M, later sign a new agreement for $1M more (raising the cap to $6M), then invest the remaining $4M.
• A cap never decreases on its own. Redeeming does not lower the cap — it frees up room underneath it, since a redemption reduces how much of the cap is currently invested, not the cap itself. The investor can invest again into that freed-up room, or raise the cap further with a new subscription agreement.
• Investment Management's Accept action must check remaining capacity before accepting a new investment — an investment that would exceed the current cap should not be acceptable.
• Investors can request more room directly: the investor portal includes an "Increase Subscription Capacity" action that starts a new subscription agreement.

This is why an investor's profile shows a Remaining Capacity figure — it isn't a static configured limit, it's derived (cap minus currently invested amount), and it moves as agreements are signed, investments are accepted, and redemptions are paid out.

The Investment Lifecycle

An investment moves through the same named states regardless of whether funding arrives as fiat or as USDC. There is no cancellation window on the holding step — once funds are locked, the flow moves forward to acceptance or rejection, not back.

Type	Explanation	Fiat	Stablecoin
Locked	The investor's funds are committed and held.	Investor sends funds to the fund's designated bank account (provided by the fund organization).	Investor transfers stablecoin from their personal wallet to their Tahoe-provisioned wallet, then locks the investment into the fund's deposit contract (the vault).
Accepted	The fund manager accepts the investment.	When the fund manager receives the bank transfer for the investment, they select Accept so the system records the acceptance to the ledger and prepares to issue shares to the investor's Tahoe-provisioned wallet address.	Accepting the investment moves the locked funds from the vault's pending position into the Fund Treasury Vault, making them accessible to the fund manager, and prepares the system for share issuance.
Funds transferred (Background task)	Funds move into the Fund Treasury Vault, made accessible to the fund manager.	N/A — funds are already in the bank account.	Happens automatically as part of Accept, not a separate manager action. Recorded as its own ledger event for audit purposes even though it's atomic with Accepted.
Shares issued	Shares are issued at the price the manager set for this transaction.	Fund manager issues shares at the correct NAV to the investor's Tahoe-provisioned wallet address.	Fund manager issues shares at the correct NAV to the investor's Tahoe-provisioned wallet address.
Claimed	The investor claims the issued shares.	Investor claims their shares to their Tahoe-provisioned wallet (needs to be automated in the future).	Investor claims their shares to their Tahoe-provisioned wallet (needs to be automated in the future).

Every one of these transitions is its own timestamped event in the Ledger — see below.

The Redemption Lifecycle

Type	Explanation	Fiat	Stablecoin
Locked	Investor locks a redemption request by locking their shares into the contract. Shares are held, not yet burned.	Investor requests redemption; shares are locked pending fund manager review.	Investor requests redemption; shares are locked into the contract pending fund manager review.
Accepted	Fund manager sees the locked request in the UI and accepts it, which burns the shares.	Fund manager accepts the request; shares are burned.	Fund manager accepts the request; shares are burned.
Priced & funded	This is not a Tahoe task. Fund manager waits for the NAV (from fund admin or their own calculation), uses it to determine the payout amount, and adds sufficient liquidity to the vault.	Fund manager determines cash payout amount from NAV and prepares funds.	Fund manager determines stablecoin payout amount from NAV and adds liquidity to the vault.
Paid out	Fund manager executes the redemption using the accepted NAV.	Fund manager sends the bank transfer directly from the fund's own bank account, then manually clicks "Paid Out" in Tahoe to record the payout — Tahoe has no visibility into the bank transfer itself, so this click is the record-keeping step.	Payout funds are locked in the vault for the investor to claim.
Claimed	Investor claims the issued payout.	N/A — the bank transfer itself completes the payout; there is no separate claim step.	Investor claims their payout to their Tahoe-provisioned wallet.

Cancellation is not a V1 requirement for either the investment or redemption flow. It may be added in a later version.

Redemptions can be partial. At Accept, the manager can burn only some of the requested shares, leaving the rest pending. The Accepted → Priced & Funded → Paid Out cycle above can repeat more than once for a single original request until it's fully satisfied — and each cycle can land at a different NAV, since the unfulfilled remainder keeps earning yield while it waits.

The Ledger Is the Source of Truth

Ledger is Tahoe's audit-grade record of everything above. It is not a status summary — every state change in every lifecycle gets its own timestamped row, not just the current state. Related rows share an ID (for example 415-1, 415-2, 415-3) so one investor's full investment flow can be traced without collapsing it into a single row, and the fund has a date/timestamp of all transactions.

Ledger also records:

• Manager actions that touch money or NAV — NAV records created, edited, or deleted; strategy drawdowns and returns — each with the acting team member, timestamp, and amount.
• Planned: investor-to-investor transfers, once built (technically possible today since fund tokens are whitelist-transfer-only, but not yet a live feature).
• Planned: distributions, once that feature ships — each distribution event will log here the same way.

Non-financial admin actions (investor invitations, KYC/B investor status changes, manual adjustments to KYC/B forms, permission changes, profile edits, and similar) are out of scope for Ledger. Those are covered by Tahoe's separate Organization audit page.

Live vs. Planned, at a Glance

Item	Status
Tahoe-provisioned wallets for managers and investors, 2FA-authorized signing	Live
NAV set per transaction at fulfillment	Live
Investment capacity set and tracked via subscription agreements	Live
Subscription agreement e-signing with fillable fields on an uploaded document	Partial — document + signature block exist; fillable text-field placement on the document does not yet — needed for V1
Ledger as event-level audit log	Live (this spec)
Auto claim tokens or stablecoins for the investor	Planned for V2
Multi-signature manager wallet approvals	Planned V2/3
Investor-to-investor transfers	Planned V2
Distributions	Planned V2
Redemption/investment cancellation	Not in V1 — may return later
Fund-manager self-custody option	Not in V1 — future consideration for V2/3

Where to Go Next

• Brand Style Guide
• Create a Fund
• Investors & Onboarding
• Investment Management
• NAV Management
• Vault Operations
• Ledger
• Manager Signing Wallet & Fund Holding Wallet
• Fund Treasury Vault

Revision History

Version	Date	Change
1.0	2026-08-24	Established early in this docs review as the shared source of truth for custody, signing, wallet naming, NAV timing, investment capacity, and lifecycle stages. Iteratively refined across many sessions since — this table starts tracking from the most recent structural change forward.
1.1	2026-09-17	Added a note to the redemption lifecycle: a single redemption can cycle through Accepted → Priced & Funded → Paid Out more than once (partial redemptions), and each cycle can land at a different NAV since the unfulfilled remainder keeps earning yield while pending.