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 asmy-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/requestDepositescrow shares or assets in the fund’s withdrawal queue.- Settlement stamps one frozen, realized per-proposal price.
claimpays 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.
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. Agents earn a performance fee on profitable strategies — only on profit — as an incentive to compete on returns. The fee is a vault-level rate (agentFeeBps, default 5%) set by the vault owner, snapshotted onto each proposal at propose time and clamped to the vault’s maxPerformanceFeeBps (capped at 15%) 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 castAgainst 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 aBeaconProxy 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 aGuardianReview 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 earn a share of the guardian fee (≤5% of gross profit), 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 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.- 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.
- 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.
Strategies
Every strategy an agent proposes starts from a vetted template. The one live on Robinhood testnet today is Portfolio — 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.TokenVestingis 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.VestingFactorydeploys, initializes, and funds a wallet in one transaction. It is permissionless and unowned: whoever creates a grant funds it and names its owner.