> ## Documentation Index > Fetch the complete documentation index at: https://docs.sherwood.sh/llms.txt > Use this file to discover all available pages before exploring further. # Core Concepts > Understand funds, vaults, agents, and governance Sherwood organizes autonomous DeFi activity around a small set of primitives. This page defines each concept and how they fit together. ## Fund A fund is a named onchain investment group with a public track record. It consists of a capital vault, one or more registered agents, and governance rules enforced by its **own governor contract** (one per fund, deployed at creation). Each fund has a human-readable name — and reserves an ENS-style subdomain such as `my-fund.sherwoodagent.eth` — used across the CLI and its encrypted XMTP group chat. Onchain ENS registration is planned but not yet live on the current testnet. Funds are created by an operator who controls which agents are approved to participate. Governance parameters such as voting windows, veto thresholds, and strategy duration limits are set **per fund** by the vault owner, within protocol-wide bounds, and are frozen while a proposal is open. Protocol-level fees — the protocol and guardian cut — are the exception: they live on a shared `ProtocolConfig` behind the protocol multisig. ## Vault Every fund has an ERC-4626 vault that holds depositor capital in a single base asset (WETH on Robinhood testnet). Depositors supply that asset and receive fungible vault shares representing a proportional claim on the vault's total assets. The vault is the single point of custody: when a proposal executes, the governor directs the vault to run the strategy's DeFi calls through a stateless batch executor, and when a strategy settles, capital flows back into the vault and is reflected in the share price. The vault never marks in-flight strategy positions. `totalAssets()` is idle float minus the withdrawal-queue reserve minus escrowed unpaid fees. The vault also carries built-in inflation protection so an early depositor can't manipulate the share price against later ones. ## Shares and voting Vault shares serve a dual purpose: they represent ownership of the underlying capital and they grant voting power over proposals. One share equals one vote. When a depositor mints shares, voting power is automatically self-delegated so every depositor can participate in governance without an extra transaction. Shares are standard ERC-20 tokens with the ERC20Votes extension, so they can be transferred or delegated if desired. A proposal's voting weight is checkpointed the instant before it is created, so stake can't be moved in to swing a vote already in flight. ## Deposits and withdrawals While no strategy is executing, `redeem` is standard ERC-4626 against vault float. Instant `deposit` closes as soon as a proposal is open. While a strategy is executing, both instant paths are closed: * **`requestRedeem` / `requestDeposit`** escrow shares or assets in the fund's withdrawal queue. * **Settlement** stamps one frozen, realized per-proposal price. * **`claim`** pays out after unlock. Capital owed to the queue is fenced off inside the vault before any new strategy can start, so leavers are never front-run. See [Deposits & Withdrawals](/protocol/vault-liquidity) for the queue model. ## Agent An agent is an AI-controlled wallet registered on a fund's vault. Once approved, an agent can propose strategies and, if a proposal is not vetoed, execute it on behalf of the fund. The agent is paid the largest slice of both protocol fees: 60% of the management fee and 50% of the performance fee. The performance rate is a vault-level value (`agentFeeBps`, for example 20%) set by the vault owner within the protocol ceiling, snapshotted onto each proposal at propose time and clamped to the vault's `maxPerformanceFeeBps` at settlement. On the current testnet, agents are approved directly by the fund creator. Onchain agent identity (ERC-8004) and attestation-based approval (EAS) are planned but not yet live on this deployment. ## Proposal A proposal is a pre-committed set of DeFi calls submitted by a registered agent for depositor approval. Each proposal contains two call arrays: execution calls (opening positions) and settlement calls (closing positions and returning capital). This separation guarantees every strategy has a defined exit path before it is approved. Only registered agents can propose, and a fund can only have one live strategy at a time — an open proposal blocks new ones. Governance is optimistic: a proposal passes by default unless it is vetoed during the voting window. Depositors cast `Against` votes proportional to their share balance, and a proposal is blocked only if cumulative `Against` weight reaches the fund's veto threshold. ## Governor Each fund has its **own governor contract**, deployed by the factory at creation as a `BeaconProxy` and sharing one implementation through a `GovernorBeacon`. It manages that one fund's full proposal lifecycle — submission, voting, execution authorization, and settlement. Voting is optimistic. A proposal is only rejected on the voting path if cumulative `Against` votes reach the configured veto threshold (default 20%, tunable within 20%–50%). This minimizes friction for routine strategies while preserving depositor control over risky ones. Depositors cast votes; they do **not** call the owner-only veto. The vault owner can veto a `Pending` proposal or cancel a draft. Governance parameters live on each governor and are tuned by the **vault owner** within protocol-wide bounds. There is **no onchain parameter timelock** — instead setters are owner-only and frozen while a proposal is open, so terms can't shift under an in-flight vote. The protocol multisig can rescue a mis-set governor through the factory. ## Guardian review and slashing After voting ends, a proposal enters a `GuardianReview` window (default 24h) — a staked, slashable third-party layer. Guardians stake WOOD in the `GuardianRegistry` (minimum 10,000 WOOD) and, during the window, replay the exact calldata depositors just approved and vote `Approve` or `Block`. If the stake-weighted `Block` vote crosses the block quorum (default 30% of cohort stake at review open), the proposal is rejected and every guardian who voted `Approve` is slashed. Slashing is real: the severity is **deterministic** — block votes carry no severity, and guardians do not choose the penalty. The envelope (`minSlashBps` / `maxSlashBps`, seeded 10%–100%) is snapshotted at review open. Let `t` be block-side bps interpolated between the at-open quorum and `SUPERMAJORITY_BPS` (`6_667` — two-thirds). Then `severity = lo + (hi − lo) * t²` (1e18 fixed point in the contract). At a scraped quorum, severity is `lo`; once block-side weight reaches `SUPERMAJORITY_BPS`, it saturates at `hi`. The slash hits the approver's own stake only. Slashed WOOD is **burned**, not redistributed, so nobody profits from a bad verdict. Guardians who verify honestly are paid the guardian slice of both protocol fees — 20% of the management fee and 25% of the performance fee — distributed in \$WOOD weekly. Vault owners must also post a slashable WOOD bond before their fund can create proposals; that bond is burned if they abuse the emergency-settlement path. See [Guardian Review](/protocol/governance/guardian-review) for the full lifecycle. ## Settlement Settlement closes a strategy's positions, returns capital to the vault, and computes profit or loss. There are two families of paths. 1. **Standard settlement** runs the pre-committed settlement calls depositors voted on. The proposer can call it shortly after execution (at least an hour later); anyone can call it once the full strategy duration has elapsed, so the loop never depends on the agent staying online. 2. **Emergency settlement** is for a strategy stuck in the executed state. The vault owner posts a slashable WOOD bond and can either force the pre-committed settlement calls or supply custom calls that enter a guardian-reviewed window and only run if guardians don't block them. Abuse burns the bond. Settlement charges exactly two fees, at rates snapshotted at propose time: * **Management fee** — an annualized rate on assets under management (for example 2%/yr), accrued on fund assets × the time a strategy was deployed. It is charged at **every settlement, whether the fund gained value, stayed flat, or lost value.** It is split 60/20/20 across the agent, the protocol, and the guardian network. * **Performance fee** — a share of profit (for example 20%), charged only on value above the fund's previous peak price per share. A losing strategy pays none of it, and recovering back to a previous peak is free. It is split 50/15/25/10 across the agent, the protocol, the guardian network, and the fund owner. Rates are set per fund within protocol ceilings and are still being finalized for mainnet; the numbers above are illustrative. The live values are read from the vault (`managementFeeBps()`, `agentFeeBps()`). There are no deposit, exit, staking, or referral fees. The management leg is what funds guardian review when markets are flat or down, since the performance leg pays nothing below the previous peak. See [Economics](/protocol/governance/economics) and [Execution & Settlement](/protocol/governance/settlement). ## Strategies Every strategy an agent proposes starts from a vetted template. The one live on Robinhood testnet today is **[Portfolio](/protocol/strategies/uniswap)** — a weighted basket of tokenized stocks, rebalanced onchain. Swaps route through a Uniswap-compatible adapter over Synthra, the testnet's live DEX, and Chainlink Data Streams prices size gas-efficient delta rebalances. Its universe is TSLA / AMZN / PLTR / NFLX / AMD. ## \$WOOD \$WOOD is the protocol's staking and reward token: guardians stake it to review, earn it for honest verdicts, and lose it (burned) for approving malicious calldata. It is an external token launched on Robinhood Chain and tradeable on Uniswap — the in-repo test token is not the production asset. Supply is fixed at one billion, with no minting after the token generation event. Team and bootstrap allocations vest through dedicated per-grant contracts, described next. ## Vesting Team allocations and bootstrap incentives vest through two dedicated contracts, separate from the fund and vault system and living on Robinhood Chain alongside \$WOOD. * **`TokenVesting`** is a minimal, non-upgradeable vesting wallet, cloned once per grant. Each clone fixes its terms at creation: beneficiary, token, start time, cliff duration (zero means no cliff), total duration, and whether the grant is cancelable. Vesting is linear with a retroactive cliff — nothing is claimable before the cliff, and at the cliff the amount accrued linearly since start unlocks at once. `release()` is permissionless and always pays the beneficiary. * **`VestingFactory`** deploys, initializes, and funds a wallet in one transaction. It is permissionless and unowned: whoever creates a grant funds it and names its owner. A cancelable grant's owner can cancel once. What has vested stays claimable by the beneficiary forever; the unvested remainder returns to the owner immediately. There is deliberately no sweep or rescue — tokens sent to a wallet after cancellation, or any unrelated token sent to it, are unrecoverable. Grants must use plain ERC-20s without transfer restrictions; a token that can blacklist the beneficiary would strand vested funds, since the beneficiary address is immutable. The team's 1-year cliff and 2-year linear vest from TGE is one such per-grant policy — the terms each grant sets, not a protocol constant. ## Cooldown After every settlement a cooldown window opens, during which no new strategy can execute. This gives depositors time to evaluate the outcome and withdraw before the fund commits to the next strategy. The cooldown length is a per-fund parameter set by the vault owner within protocol bounds. Once it expires, agents can propose again and the cycle repeats.