> ## Documentation Index
> Fetch the complete documentation index at: https://docs.caminotreasury.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Platform Overview

> Understand how Camino Treasury is organized

## Organizations

An organization is the top-level entity in Camino Treasury. It represents your company, DAO, or team and contains all your wallets, bank accounts, transfers, and team members. Each API key is scoped to a single organization, so all data is fully isolated.

## Wallets

Wallets are server-managed Ethereum addresses owned by your organization. Each wallet has an auto-generated address, an optional human-readable label (auto-assigned as `Wallet N` if you don't provide one), and creation/update timestamps. You can create, list, and rename them through the dashboard or API.

## Bank Accounts

Bank accounts link your organization to traditional rails via Bridge.xyz for fiat on/off-ramps. Each row captures the bank metadata (bank name, routing number, last-4) and is referenced by id from the transfer feed when funds move between a bank and a wallet.

## Recipients

Saved destination addresses for outbound transfers — an org-scoped address book. Each entry has a `label` (human-readable name) and an `address` that's unique per organization. CRUD via `GET / POST / PATCH / DELETE /v1/recipients`.

## Transfers

All money movements live under one feed: `GET /v1/transfers`. Each row has a symmetric `from` and `to` side; either side can be a wallet (`address`, `chainId`) or a bank account (`bankAccount` embed). This covers wallet→wallet on-chain transfers, bank→wallet onramps, wallet→bank offramps, and the USDC↔C0 deposit/withdraw pair under a single shape. Cursor-paginated newest-first; lifecycle is a single `status`: `pending | submitted | completed | failed`.

To deposit, send USDC to any wallet address; the platform converts the balance to C0 and the conversion shows up in `/v1/transfers` as a `usdc/ethereum → c0/ethereum` row. You can also drive the conversion explicitly via `POST /v1/transfers`.

## Yield

Yield is distributed periodically via the on-chain `YieldDistributor` contract. For each period, the operator publishes a merkle root that commits to every holder's allocation; holders submit a proof to `claim()` and receive their funds directly to the address baked into the leaf. The API serves the off-chain data callers need to construct that claim — both the list of claimable / already-claimed periods for a holder and the full per-period artifact for independent verification.