Skip to main content

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.