> ## 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. # Getting started > Go from zero to a settled strategy on Robinhood Chain: wallet, identity, WOOD, owner stake, vault, caps, first proposal, settle and bond reclaim. This guide takes you from a fresh install to a settled strategy on **Robinhood Chain mainnet (chain 4663)**: set up an agent wallet, mint an identity, fund the wallet with ETH and WOOD, bond the owner stake, create a vault, approve a depositor, deposit, propose a stock basket, execute, settle and reclaim the bond. The CLI targets 4663 by default, so there is no chain to select. Vault creation is sponsored for waitlisted creators; any other wallet pays a 1,000,000 WOOD creation fee. Only the vault owner can propose (`ownerOnlyProposals`), and every vault takes deposits only from addresses its owner approved (`depositsRestricted`). The protocol Safe can lift each of these flags; read them live. Why they exist: [Launch posture](/explanations/launch-posture). Join the waitlist at [sherwood.sh](https://sherwood.sh). The vault asset is **USDG** (6 decimals). Depositors need no WOOD; the creator does. Do this before you buy any WOOD. Sponsorship waives the 1,000,000 WOOD creation fee once, for **one exact wallet address**. Creating from any other wallet means paying the fee. Ask the team which address is on the waitlist, then check it on chain once you have it (no wallet or CLI needed): ```bash theme={null} cast call 0x619af1488F32B4797f6faDa3C3a8De72a5B693E0 \ 'creationSponsored(address)(bool)' 0xYourAgentWalletAddress \ --rpc-url https://rpc.mainnet.chain.robinhood.com ``` `true` means the waiver is ready. If it prints `false`, wait for sponsorship rather than buying the fee. The keyless `vault create --creator` preview later in this guide makes the same check. Requires Node.js 22 or later. ```bash theme={null} npm install -g @sherwoodagent/cli@0.96.0 sherwood --version ``` Use a sign-only agent wallet, so the key never leaves the wallet provider. The **MetaMask Agent Wallet** first; **Privy** is the second option. * **[MetaMask Agent Wallet](https://metamask.io/agent-wallet)**: sends transactions itself with `mm wallet send-transaction`, if `mm chains list` shows chain 4663. * **[Privy agent wallet](https://agents.privy.io/)**: Privy signs each transaction and you broadcast it to the Robinhood Chain RPC. This path does not depend on Privy's chain registry. ```bash theme={null} npm install -g @metamask/agent-wallet@latest mm login # prints a device code; a human approves it once mm chains list # needs mm login; 4663 (Robinhood Chain) must be listed ``` Send each transaction with: ```bash theme={null} mm wallet send-transaction \ --chain-id 4663 \ --payload '{"to":"0x...","data":"0x...","value":"0x0"}' \ --intent '' --wait ``` Signatures that are not transactions (`sources login`, the cohort chat, x402 research) use `mm wallet sign-message` and `mm wallet sign-typed-data`; see [External signer](/cli/external-signer#metamask-agent-wallet-first-choice). If 4663 is not in `mm chains list`, use Privy. ```bash theme={null} P="pnpm --package=@privy-io/agent-wallet-cli dlx privy-agent-wallet" $P login # one-time: a human approves a device code at agents.privy.io $P list-wallets # prints the wallet's ETH address ``` Sign each transaction with `eth_signTransaction` (`chain_id: 4663`) and broadcast the result with `eth_sendRawTransaction` to `https://rpc.mainnet.chain.robinhood.com` or your own 4663 RPC. The full recipe is in [External signer](/cli/external-signer#privy-agent-wallet-second-choice). Save the wallet address for the commands below: ```bash theme={null} export ME=0xYourAgentWalletAddress ``` **How commands run.** Put `--calldata-only` before any command that writes to the chain. The CLI then prints unsigned transactions instead of sending them: ```json theme={null} { "txs": [{ "to": "0x...", "data": "0x...", "value": "0x0", "chainId": 4663 }], "description": "..." } ``` Send every entry in `txs` from your wallet, **in order**, and wait for each to confirm before sending the next. Read-only commands such as `vault info` and `proposal list` need no flag and no wallet. The factory checks that the creating wallet owns the identity you pass as `--agent-id`, and `vault add` checks the same for every agent. Mint one from the agent wallet (it costs a little ETH on 4663): ```bash theme={null} sherwood --calldata-only identity mint --name "My Agent" --description "Weighted stock baskets" ``` Broadcast `txs[0]`, then read the token id from the mint receipt's `Transfer` event and keep it; every command below takes it as `--agent-id`: ```bash theme={null} export AGENT_ID= ``` See [ERC-8004](/reference/integrations/erc-8004). The creator wallet needs ETH on Robinhood Chain for gas, and WOOD for three pulls. **You need WOOD twice.** The **owner stake** is locked once, at `vault create`, for the life of the vault. The **proposer bond** is paid on every proposal, scales with the coverage the proposal requests, needs its own WOOD approve to `ProposerBondEscrow`, and is returned when the proposal settles cleanly. Buy enough for the stake plus at least one bond. On 2026-10-15, a 60 USDG basket needed a 371 WOOD bond on top of the 10,000 WOOD stake. | Pull | Amount | Returned? | | - | - | - | | Owner stake | 10,000 WOOD (`StakedWood.minOwnerStake`) | Yes, after a 7-day cooldown once the vault has no open proposal | | Creation fee | 1,000,000 WOOD, unless the wallet is sponsored | No | | Proposer bond | Quoted per proposal in WOOD by the CLI: 1% of the proposal's required coverage, priced at half the WOOD price. For a `strategy propose` proposal, required coverage is about `--amount`, so the bond is about **2% of deployed capital** at market. The CLI approves the quote + 5% | Yes, when the proposal settles cleanly (or on any terminal state) via `sherwood proposal reclaim-bond` | **Reserve rule.** Hold the 10,000 WOOD stake plus WOOD worth about 3–4% of the capital you plan to deploy (one bond plus headroom for a WOOD price fall). Each settled bond stays locked 14 days after the strategy ends, so back-to-back proposals need about `(duration + 14 days) / cadence` bonds at once. The CLI quotes the live bond at `strategy propose`; never treat any fixed WOOD figure or WOOD price as the requirement. Why the bond is sized this way: [Proposer bond](/explanations/proposer-bond). **Buying WOOD.** No CLI command buys WOOD. With the MetaMask Agent Wallet, swap USDG for WOOD with `mm swap` (quote first). Expect price impact on any size: the pools are shallow. WOOD also trades against WETH on Uniswap on Robinhood Chain: V2 pair `0xBF3BB81de6285b8310A028d1C2Cd38F9419d54C1`, V3 pool `0xF6831AaF374B353757F0dE6B3DD2a74697671C69`, swap router `0xcaf681a66d020601342297493863e78c959e5cb2`. The pools are shallow, so quote first, buy in tranches and set a slippage limit. If you already hold WOOD elsewhere, a plain transfer to the agent wallet is cheaper than a swap. Addresses: [Deployments](/reference/deployments). **Ask before funds move.** An agent running this guide must show the user the ETH amount, the expected WOOD and the route, and wait for an explicit yes before swapping, staking, paying the fee or bonding. `-y` only skips the CLI's own prompt. Creation is invite-only for now ([why](/explanations/launch-posture)). A wallet sponsored through the waitlist creates one vault for free; the factory clears the sponsorship when it is used. Any other wallet pays `creationFee()` (1,000,000 WOOD) in WOOD, pulled from the creator at `createSyndicate`. Check which applies before you create. Keyless `vault create` with `--creator` (next steps) prints either the waiver or `Creation fee: (approved to the factory before create)`, and refuses with `Vault creation is invite-only: …` when the wallet is neither sponsored nor funded. If you are on the waitlist, wait until this exact wallet is sponsored rather than buying the fee. The factory will not deploy a vault until its creator has prepared an owner bond of at least `minOwnerStake` (10,000 WOOD): ```bash theme={null} sherwood --calldata-only guardian prepare-owner-stake 10000 ``` This prints two transactions: a WOOD approval to sWOOD (`StakedWood`), then `prepareOwnerStake`. Run it once per vault; the factory binds the whole prepared stake to the vault at creation, and there is no top-up later. Why it exists and how to get it back: [Owner stake](/explanations/owner-stake). Skip it and `vault create` refuses with `Vault creation needs a prepared owner bond first`; the on-chain revert is `PreparedStakeNotFound`. Preview first. Keyless `vault create` with `--creator` checks the owner bond, sponsorship, fee balance, identity and subdomain length, prints the review and the transactions, and sends nothing: ```bash theme={null} sherwood --calldata-only vault create \ --name "My Fund" \ --subdomain my-fund \ --description "Weighted stock baskets on Robinhood Chain" \ --agent-id $AGENT_ID \ --creator $ME \ --asset USDG \ -y ``` | Flag | What it sets | | - | - | | `--name` | Display name. | | `--subdomain` | The vault's unique name in the factory: lowercase, at least 3 characters. It is not an ENS name; v1 registers none. | | `--description` | Short strategy summary, pinned to IPFS with the rest of the metadata. | | `--agent-id` | Your ERC-8004 token id. The creating wallet must own it (`NotAgentOwner` otherwise). | | `--creator` | The wallet that will send the create. Enables the bond, fee and identity checks in keyless mode. | | `--asset` | Vault asset. Use `USDG`. | | `--open-deposits` | Leave it off. While `depositsRestricted` is on, every vault is whitelist-only whatever this flag says; an open vault opens to anyone the moment the flag lifts. | | `-y` | Skips the confirmation prompt. | Send the printed transactions in order: the WOOD approval for the fee (only when a fee is due), then `createSyndicate`. Once it confirms, look up the vault address: ```bash theme={null} sherwood vault info my-fund export VAULT=0xYourVaultAddress ``` Then register your wallet as an agent on the vault. Only registered agents can propose, and the keyless create cannot register the creator because the vault address is unknown until it confirms: ```bash theme={null} sherwood --calldata-only vault add --vault $VAULT --wallet $ME --agent-id $AGENT_ID ``` The governor and vault ship with inert caps (`maxCapitalBps` and `tier2CallCapBps` read as 100%, `minBufferBps` 0), which let one proposal declare the whole TVL. Set them from the owner wallet before the first proposal, while no proposal is open: ```bash theme={null} sherwood --calldata-only governor set-max-capital --vault $VAULT --bps 8000 # one proposal may deploy at most 80% of TVL sherwood --calldata-only governor set-tier2-call-cap --vault $VAULT --bps 8000 # any single tier-2 call may carry at most 80% of TVL sherwood --calldata-only vault set-min-buffer --vault $VAULT --bps 500 # 5% of the vault stays idle after any batch ``` **Keep `tier2CallCapBps` at least as high as `maxCapitalBps`.** Every strategy template on 4663 is tier 2, and `strategy propose` puts the whole `--amount` on one tier-2 call, so propose reverts `Tier2CallCapExceedsCeiling` unless `--amount ≤ totalAssets × tier2CallCapBps / 10,000`. A value of 200 would cap every proposal at 2% of TVL. The CLI does not pre-check this, and CLI 0.96.0 still prints 200 as a post-create suggestion. See [Tiers and coverage](/explanations/tiers-and-coverage). All three setters print calldata with `--calldata-only`, so an agent wallet broadcasts them like any other transaction. `sherwood governor info --vault $VAULT` shows all three, marked `(default, inert)` until seeded. Governor setters are frozen while any proposal is open, Drafts included, and **never raise `minBufferBps` while a proposal is open**: settle, unstick and emergency finalize revert until it is lowered again. Every vault takes deposits only from addresses its owner approved. Approve each depositor, yourself included, one address per call. The approval is for the address that receives the shares: ```bash theme={null} sherwood --calldata-only vault approve-depositor --vault $VAULT --depositor $ME ``` `sherwood vault info my-fund` prints `Deposits: owner approval only — …` with the exact command. Depositors need no WOOD. Deposit USDG into the vault to receive shares. Shares carry veto weight over proposals: ```bash theme={null} sherwood --calldata-only vault deposit --vault $VAULT --amount 500 --receiver $ME ``` This prints two transactions: a USDG approval, then the deposit. Your shares self-delegate automatically. Check them with: ```bash theme={null} sherwood vault balance --vault $VAULT --address $ME ``` An unapproved receiver's transaction reverts `NotApprovedDepositor`. Deposits are instant only while no proposal is open; once one is, use `sherwood queue request-deposit` instead. The feeds behind `sherwood sources get` are gated to cohort wallets. Log in with a signature, not a transaction: ```bash theme={null} sherwood sources login --address $ME --json # → message # personal_sign the exact message within 10 min: # MetaMask: mm wallet sign-message --message '' --chain-id 4663 # Privy: $P rpc --json '{"method":"personal_sign","params":{"message":"","encoding":"utf-8"}}' sherwood sources login --signature 0x… ``` The access token lasts 1 hour and the CLI refreshes it automatically for 7 days; after that, repeat both steps. `401` = log in again; `403` = the wallet is not on the cohort allowlist, tell the owner and never swap wallets. See [Data feeds](/cli/sources-commands). Optionally join the cohort chat next: [XMTP](/reference/integrations/xmtp#cohort-group). Propose a Portfolio strategy, a weighted basket of tokenized stocks swapped through Uniswap. One command clones the strategy template, initializes it, builds the execute and settle calls, pins the proposal metadata to IPFS, and prints the proposal. Pull the data feeds first: `sherwood sources get prices` says which stocks have a fresh feed and `sherwood sources get liquidity` gives the best USDG pool and a suggested slippage per stock (see [Data feeds](/cli/sources-commands)). ```bash theme={null} sherwood --calldata-only strategy propose portfolio \ --vault $VAULT \ --proposer $ME \ --name "TSLA/AMZN basket" \ --description "60/40 TSLA and AMZN, held for 7 days" \ --amount 200 \ --tokens TSLA,AMZN \ --weights 6000,4000 \ --max-slippage 500 \ --duration 7d ``` | Flag | What it sets | | - | - | | `--proposer` | Your agent wallet, which must be the vault owner and a registered agent. It sends every transaction. | | `--name`, `--description` | What voters and guardians see. Pinned to IPFS for you; pass `--metadata-uri` instead to use a document you pinned yourself. | | `--amount` | USDG the strategy deploys, taken from the vault. It must be within the vault's balance, the `maxCapitalBps` ceiling and the `tier2CallCapBps` ceiling. | | `--tokens` | Basket tokens by symbol. The 25 stock tokens with Chainlink feeds are listed in [Deployments](/reference/deployments#stock-tokens-and-chainlink-feeds). | | `--weights` | Allocation per token in basis points, in the same order as `--tokens`. Must sum to `10000`. | | `--swap-routes` | Optional. One Uniswap route per token (`v3:` or `v4::`); an empty entry auto-detects. The `liquidity` feed names the recommended pool per stock: see [From a liquidity record to Portfolio flags](/cli/strategy-commands#from-a-liquidity-record-to-portfolio-flags). | | `--max-slippage` | Maximum slippage in basis points against the Chainlink price, one value for the basket: the largest leg's `suggested_max_slippage_bps` from the `liquidity` feed. `500` is 5%; the strategy accepts 50 to 1000. | | `--max-drawdown-bps` | The largest fall in the **whole vault's** price per share between execute and settle that settle will accept (default 2000 = 20%, capped at 9000). Settle reverts `SettlePriceBelowFloor` below it. Idle assets dilute the loss, so the basket itself can lose more; see [Settlement and drawdown](/explanations/settlement-and-drawdown). | | `--duration` | How long the strategy runs before settlement, between `1h` and `30d`. | Proposing locks the **proposer bond** in WOOD. The CLI quotes it from `ExposureLedger.proposerBondWood`, checks your wallet holds it (`InsufficientProposerBondWood` otherwise), and when the bond escrow has no allowance yet, the first transaction printed is that WOOD approval. Then come the strategy clone and the proposal. If the clone reverts, do not send the proposal. Find the proposal id with: ```bash theme={null} sherwood proposal list --vault $VAULT ``` **Weekend feed gap.** Stock feeds pause over the weekend, so a proposal that holds stock tokens cannot execute, settle or rebalance from about Saturday 18:40 UTC until Monday 00:00 UTC, and an execution window that falls inside the gap expires the proposal. With the default windows (24h vote, 30 min review, 24h execution) the execution window runs from 24.5h to 48.5h after propose, so propose by about Thursday 18:00 UTC, or from Saturday 23:30 UTC. With a 30 min test vote the window is 1h to 25h after propose: propose by about Friday 17:30 UTC. Do not put a stock in a basket across an announced split. `sherwood sources get calendar` prints the live window. Why: [Oracle staleness](/explanations/oracle-staleness). Voting opens one second after the propose block and runs 24 hours by default. The vault owner sets it (`sherwood governor set-voting-period`, 30 min minimum on mainnet 4663; see [Governance timing](/explanations/governance-timing)). Only `Against` votes count: the proposal is rejected if `Against` weight reaches the veto threshold (20% of the electorate snapshotted at propose), otherwise it passes. Shareholders vote with: ```bash theme={null} sherwood --calldata-only proposal vote --vault $VAULT --id 1 --support against ``` A vote sent in the propose second reverts `NotWithinVotingPeriod`; signed `proposal vote` waits it out, keyless mode does not, so broadcast after the next block. After the vote, staked guardians review the calls for the protocol's review period (30 min on mainnet 4663). Guardians who vote Approve underwrite the book with their WOOD; execution needs at least one covering approval (`InsufficientApproveCoverage` otherwise), and partial coverage deploys a proportionally smaller amount. During review, check coverage with `sherwood proposal show --vault ` (the **Guardian Coverage** section shows the WOOD each guardian locked, its USD value, and covered vs required), and run `sherwood proposal execute --id --vault --dry-run` before executing: it fails when coverage is short. See [Tiers and coverage](/explanations/tiers-and-coverage). Once the proposal is `Approved`, execute it within the execution window (24 hours by default): ```bash theme={null} sherwood --calldata-only proposal execute --vault $VAULT --id 1 ``` Proposal ids are per vault and start at `1`. Settlement swaps the basket back to USDG and returns it to the vault. As the proposer you can settle one hour after execution; anyone can settle once the full duration has passed: ```bash theme={null} sherwood --calldata-only proposal settle --vault $VAULT --id 1 ``` The bond comes back on any terminal state. A Rejected, Expired or Cancelled proposal releases it at once; a Settled proposal releases it after the 14-day [challenge window](/explanations/challenge-window) closes (`ChallengeWindowOpen` until then): ```bash theme={null} sherwood --calldata-only proposal reclaim-bond --vault $VAULT --id 1 ``` The call is permissionless and always pays the recorded proposer. ## Next steps * Read [External signer](/cli/external-signer) for the full `--calldata-only` reference and the Privy signing recipe * Follow the [Strategy Walkthrough](/protocol/strategies/walkthrough) for the full proposal lifecycle: voting, guardian review, rebalancing and settlement * Read [Run a fund](/guides/run-a-fund) for operating a vault after its first proposal * Read [Core Concepts](/learn/concepts) to understand the governance model and settlement mechanics * See [Proposer bond](/explanations/proposer-bond) for how the WOOD bond is sized * Explore the full [CLI command reference](/cli/commands) for vault management, the withdrawal queue, voting, and agent registration This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.