Crypto Payouts API (Proposed) — Solana USDC

Proposed v1 public API for explicit USDC payouts on Solana.

Status: Proposed (not yet shipped as a public /v1/crypto/* contract).

This page describes the proposed v1 API surface for USDC payouts on Solana. The goal is to provide a clean, explicit crypto contract without requiring integrators to infer behavior from mixed spend execution fields.

#Scope

  • Chain: solana
  • Asset: USDC
  • Mint: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
  • Decimals: 6

#Proposed endpoints

  • GET /v1/crypto/capabilities
  • GET /v1/crypto/balance
  • POST /v1/crypto/payout-intents
  • GET /v1/crypto/payout-intents
  • GET /v1/crypto/payout-intents/:id

#Proposed payout intent lifecycle

  • created
  • needs_approval
  • approved
  • execution_started
  • submitted
  • confirmed
  • failed
  • cancelled

#Example: create payout intent

curl -sS -X POST "https://api.dino.id/v1/crypto/payout-intents" \
  -H "Authorization: Bearer YOUR_DINO_SPEND_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "amount_atomic": "12500000",
    "chain": "solana",
    "asset_mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "recipient_address": "7xKXtg2CWJ1Axn7x2LQ5vF7oWQ8B8yrW5K8J2R6dJ1QH",
    "merchant_name": "Payout recipient",
    "reason": "Affiliate payout",
    "execution_mode": "workspace_custodial",
    "metadata": { "invoice_id": "inv_123" }
  }'

#Example: read payout status

curl -sS "https://api.dino.id/v1/crypto/payout-intents/cpi_123" \
  -H "Authorization: Bearer YOUR_DINO_SPEND_KEY"

Response should include explicit chain execution fields such as:

  • tx_signature
  • submitted_at
  • confirmed_at
  • failure_reason (when terminal failure occurs)

#Error model (proposed)

Expected error.code values include:

  • invalid_request
  • insufficient_wallet_balance
  • policy_declined
  • recipient_invalid
  • asset_not_supported
  • chain_unavailable
  • signer_unavailable
  • rate_limited
  • idempotency_conflict

#Proposed webhook family

  • crypto_payout.created
  • crypto_payout.needs_approval
  • crypto_payout.approved
  • crypto_payout.execution_started
  • crypto_payout.submitted
  • crypto_payout.confirmed
  • crypto_payout.failed
  • crypto_payout.cancelled

#Relationship to current API

Current shipped behavior remains:

  • /v1/spend-requests for governed spend decisions
  • /v1/transfers for fiat workspace-to-workspace transfers
  • crypto execution surfaced in spend detail fields

This proposed surface is additive and intended to make crypto integrations first-class and explicit.