Documentation

Veyra is a non-custody permission layer. You connect wallets, set how much an agent may spend, and get one MCP URL. Agents call tools like create_payment — they never receive seed phrases or private keys.

• Sign up and verify your email.
• Connect at least one wallet (MetaMask, Base/Coinbase passkey, or WalletConnect for Base USDC).
• Create an MCP endpoint with per-tx / daily limits and auto / ask bands.
• Paste the URL + bearer token into Claude, Cursor, or Codex.

Remote endpoint: POST /api/mcp with header Authorization: Bearer veyra_…

Claude Code:

claude mcp add --transport http veyra https://veyra.money/api/mcp \
  --header "Authorization: Bearer veyra_…"

Cursor, Codex, and any host that takes a remote URL plus headers:

{
  "mcpServers": {
    "veyra": {
      "url": "https://veyra.money/api/mcp",
      "headers": {
        "Authorization": "Bearer veyra_…"
      }
    }
  }
}

Claude Desktop and other hosts that can't send a bearer header to a remote server: use the open-source stdio bridge, which holds the credential locally and relays every call here.

{
  "mcpServers": {
    "veyra": {
      "command": "npx",
      "args": ["-y", "veyra-mcp"],
      "env": { "VEYRA_TOKEN": "veyra_…" }
    }
  }
}

The bridge, a typed TypeScript client, and runnable agent examples live on GitHub: veyra-mcp and veyra-examples.

Rotate or revoke credentials anytime from the endpoint page in the dashboard.

• get_capabilities / get_budget — policy summary (read-only)
• list_payment_sources — masked sources only
• create_payment — amount, asset, recipient, network, reason, idempotency_key
• get_payment / list_payments / cancel_payment

Payment status is one of pending, awaiting_approval, submitted, confirmed, confirmed_simulated, failed, cancelled or expired. An approval that nobody acts on lapses after 24 hours.

Payments under auto-max can proceed without a human prompt (still subject to limits). Amounts in the ask band return awaiting_approval with a one-time link. Over the ask band or daily cap → blocked.

Approval links ask the bound wallet to send a real USDC transfer on Base. Rejecting in the wallet cancels the payment. No Veyra login is required on the approve page — auth is the secret token + matching wallet + on-chain receipt.

When approval is required, Veyra emails the account owner and (if enabled) sends a browser push that opens the approve URL. WalletConnect can also ping the mobile wallet when you open that link.

Veyra never takes custody of your funds — at no point does a payment pass through a Veyra-controlled balance. There are two paths, depending on your policy:

Above your auto-approve limit (or when no auto-pay allowance is set): the payment request is held, and you confirm it yourself, directly in your own wallet (MetaMask, Coinbase, or WalletConnect). Veyra verifies the resulting on-chain transaction matches what was requested — it never signs anything on your behalf.

Within your auto-approve limit, with auto-pay enabled: you grant a capped, on-chain USDC allowance (the standard ERC-20 approve mechanism — the same primitive every DeFi app uses) to a relayer Veyra operates. That relayer can then execute payments directly from your wallet to the recipient — never through Veyra — but strictly up to the allowance you set, enforced by the token contract itself, not by Veyra's say-so. Revoke it anytime from the endpoint page.

Worth being blunt about, because it is the one thing an allowance does not decide for you. An ERC-20 approve caps how much the relayer may move — the token contract enforces that, and nothing Veyra does can exceed it. It does not cap who it may move funds to. Within that cap, the only thing deciding the destination is Veyra's policy engine.

So an auto-pay allowance is a bet on two things: the cap you set, and Veyra's relayer key not being misused. Size the cap accordingly — treat it as a float you would be willing to lose, not as a credit limit — and use the recipient allowlist when you know in advance who your agent should be paying, which constrains the destination on top of the amount.

The wallet-approval path carries none of this: nothing is delegated, you sign each transfer yourself, and Veyra only verifies the receipt. Every payment above your auto-approve limit takes that path, and on the Free plan every payment does.

A mock source settles instantly and moves no money on any chain. It exists so you can wire up an agent and watch policy decisions land before pointing anything at real funds.

It is labelled everywhere rather than blending in: the agent sees status confirmed_simulated with simulated: true, and the dashboard shows Simulated instead of Confirmed. If you are reading plain confirmed, value moved.

Every policy decision, settlement, approval and permission change is recorded and readable at Dashboard → Audit log — including the ones nobody asked for directly, like an approval lapsing or a receipt being reconciled after the fact, which are attributed to Veyra rather than to you.

The changes worth watching for are the ones that widen what an agent may do: source.allowance_granted, agent.policy_updated (which records the limits before and after) and agent.credential_rotated.

History is kept for 7 days on Free, 90 on Pro and a year on Team, and Team can export the window as CSV.

Limits and the recipient allowlist are editable from the endpoint page at any time. Limits must stay consistent — auto-approve ≤ ask ≤ per-payment ≤ daily — and are rejected with a reason if they don't, rather than being stored and failing later at payment time.

An empty allowlist means any recipient within the limits. A populated one is exhaustive, and addresses are compared case-insensitively, so you can paste them in whatever form your wallet shows.

Veyra intentionally supports USDC on Base only — not because of a technical limitation, but because that's where the agent-payment ecosystem this product targets already operates, and because a single stablecoin keeps policy limits exact instead of needing a live price feed. Phantom (Solana) can be linked for identity, but on-chain transfers use MetaMask, Base / Coinbase, or WalletConnect.

Free, Pro, and Team plans govern how many agents, sources, and delegated auto-pay executions your account gets per month — see Pricing for current limits. Plan limits are separate from your policy's dollar limits: even on a paid plan, a single agent still can't exceed the per-transaction and daily caps you configure for it.