PricingStory
Sign in
Docs/Agent spend paths (crypto & cash)

Agent spend paths (crypto & cash)

Practical ordering from lowest-friction MCP and browser sign-in to dashboard-led spending keys—for workspace USDC custody and USD / card rails.

This page is for teams who want an agent to initiate money movement through Dino—not for operators who paste raw Solana transactions by hand. It compares paths by how much setup each one takes, separately for on-chain USDC (workspace custody) and cash-style spend (USD, proxy cards, checkout).

North-star security pattern (all API paths): the model plans; a trusted tool runner injects Authorization: Bearer … and Idempotency-Key on writes. Do not put live din_… secrets in prompts or client-only code. See Connecting AI Agents to Dino.

#Crypto (Solana USDC, workspace custody)

Assume the goal is governed on-chain USDC sent from workspace USDC custody (Dino signs after policy and approval), not “the model constructs a Solana transaction.”

#1. Easiest when the host supports it: MCP + browser sign-in (no spending key in hand)

Some clients can add Dino’s MCP endpoint https://api.dino.id/mcp and complete browser sign-in with Dino so the host holds authentication—no generating and copying a din_… secret. The in-dashboard setup flows (including the Zed instructions in the product) walk through this pattern. Public overview: AI Tools (MCP).

Caveat — USDC payment requests: The agent only gets USDC payment request tools when the connection is allowed the payment_requests.create and payment_requests.read scopes (for example via a restricted API key or OAuth app configuration). If the integration only performs “full account” OAuth and does not expose those tools, this path may not appear. Scope reference: OAuth Scopes.

#2. Easiest in-product path Dino already guides: “Agent send (API)” (crypto)

In the Dino dashboard, open Treasury → Crypto (or your team’s crypto hub). Use the flow titled “Agent send (API)”. It is aimed at governed on-chain USDC via the public API + a spending key: it builds the short instruction doc for Solana USDC payout (POST /v1/crypto/payout-intents) and links to the public docs.

Typical workflow for a less technical owner:

  1. Fund workspace USDC balance (the same custody wallet payouts use).
  2. In that Agent send (API) panel, create a spending key for the right agent budget, then use copy instructions for your AI product (Cursor rules, team playbook, etc.).
  3. One slightly technical step: store the raw din_… secret in a secret manager or env var on the machine or service that calls the API. The instructions stress that the model must not hold the key; the tool runner adds Authorization: Bearer … and Idempotency-Key.
  4. When policy requires it, approve in the Dino dashboard. Spending keys cannot approve crypto payouts; humans or a team API key approves—see Crypto Payouts API — Solana USDC.

That is the lowest-friction documented, UI-led path today: mostly copy-paste, one secret handoff, and dashboard (or API) approvals.

Related: Agent Spend Quickstart · Connecting AI Agents to Dino

#3. If they do not need an agent at all

For instant custodial sends without going through agent policy and payout intents, use “Transfer to a Solana wallet” (or equivalent custodial transfer) in the dashboard. That is simpler when a human only needs to move USDC—but it is not “the agent sends it.”

#Cash (USD, cards, checkout intents)

“Cash” here means USD balance, proxy cards, and merchant checkout—POST /v1/spend-requests for governed ledger/card spend and /v1/checkout/intents for buy-online flows with optional one-time credentials. Same policy, budgets, approvals, and webhooks ideas as crypto; different /v1 surface.

#1. MCP + team API key (optional browser flows per client)

AI Tools (MCP) exposes agent spend tools (for example creating a governed spend request and reading status/balance) when the MCP connection uses a team API key with the right read/write access. That can be easier than wiring raw HTTP yourself, but it is still your secret on the connector—similar in spirit to “host holds auth,” though many setups use a developer-issued API key rather than end-user OAuth.

If your product supports delegated OAuth into Dino instead of pasting keys, prefer that for operator ergonomics; combine with narrow scopes so assistants only see what they need.

#2. In-product path: Agent Bank, spending key, and the right /v1 flow

The default developer path is unchanged:

  1. Fund the team wallet and policy profile (see Agent Spend Quickstart).
  2. Issue a spending key from Agent Bank / View policy → Keys (plaintext shown once).
  3. Put the key in a server or automation env; call POST /v1/spend-requests for direct governed spend, or POST /v1/checkout/intents (then authorize / issue-credential) for card-at-checkout style purchases—see Purchase Intents API.
  4. Handle needs_approval via the dashboard or automation with a team API key, and subscribe to webhooks if you run unattended agents—Agent Spend Webhooks.

Proxy cards and testing: Proxy cards: issue, manage, test.

#3. If they do not need an agent

Operators can use cards, transfers, and checkout directly in the Dino app—see How Agents Use Dino for the governed purchasing workflow and in-app patterns. That avoids agent APIs when a human is always in the loop.

#Bottom line

GoalEasiest reliable path
Agent + workspace USDC custodyGenerated crypto agent instructions + spending key + dashboard (or team-key) approvals, with a trusted person installing the one secret outside the model.
Agent + same, but no din_… handoffMCP + Dino sign-in if the host exposes tools and scopes you need (for USDC requests: payment_requests.*).
Agent + USD / cards / checkoutSpending key + /v1/spend-requests or /v1/checkout/intents behind a tool boundary; optionally MCP for pre-built tools.
Human onlyDashboard transfers, cards, or checkout—skip agent APIs.

For the API contract and tool shapes in one place, start at Connecting AI Agents to Dino.

Connecting AI AgentsHow Agents Use Dino