Learn

How an AI agent trades on Vectr

Prompt to typed intent to policy checks to transaction build to human confirmation to signing to chain. This page is that pipeline, stage by stage, with the controls and key scopes read from GET /config. It is the safety model, not a marketing badge.

Updated

Pipeline

Seven stages, one signature

Prompt -> typed intent -> policy checks -> transaction build -> user confirmation -> signing -> Robinhood Chain

The model owns stage two only. Every stage after it is deterministic code that the model cannot skip.

  1. 1
    PromptYou, or your agent
    Plain language, from the Terminal, the CLI, the MCP server or POST https://api.vectr.bot/agent/job. "Buy 0.05 ETH of the top token", "launch NOVA paired with NVDA", "set a limit at 230".
  2. 2
    Typed intentThe model
    The language model turns the prompt into one of a fixed set of intents with typed fields: buy, sell, launch, limit, stop, DCA, TWAP, research. Anything outside that set is answered, not executed.
  3. 3
    Policy checksThe backend
    The intent is checked against the wallet's controls before anything is built: limits, allowlists, the pause switch, anomaly rules. A failing check ends the job with a reason.
  4. 4
    Transaction buildThe backend
    A passing intent becomes an unsigned transaction: the exact contract, calldata, value and a quote with slippage. This is what the job returns in richData.
  5. 5
    Human confirmationYou
    The transaction is shown in a UI with what it does and what it costs. Nothing has been signed. Close the tab and nothing happens.
  6. 6
    SigningYour wallet, or Vectr for a custodial wallet
    With your own wallet you sign in it. With a Vectr wallet the backend signs through /wallet/sign-and-submit after the same controls run once more; a read-only API key is rejected here.
  7. 7
    Robinhood ChainThe chain
    The transaction is broadcast, indexed within a block or two, and appears on the token page and in the SSE stream like any other trade.
Controls

What runs before anything is signed

Enabled controls as the backend reports them right now. A control that is off is not listed.

Confirmation first
onNothing signs without your confirmation; the model builds typed intents, never raw calldata
Per-transaction USD limit
onOptional cap on a single signed transaction, enforced server-side
Daily USD limit
onOptional cap on signed value per wallet per day, enforced server-side
Pause switch
onOne switch halts all signing for the wallet
Contract-call guard
onA switch that blocks arbitrary contract calls, limiting the wallet to known Vectr actions
Recipient allowlist
onOutgoing transfers restricted to addresses you approve
Recipient cooldown
onA newly approved recipient waits before it activates
Anomaly detection
onTransfers well above the wallet's rolling average are flagged before they sign
Selector and target whitelist
onBefore signing, the calldata selector is checked against a per-action whitelist and the target against known platform contracts
API keys

Scopes decide what a leak can cost

Keys are created and revoked in your profile. Available scopes right now: read-only, read-write, ip-allowlist, recipient-allowlist. A read-write key can sign through the backend, which is exactly why the recipient and IP restrictions exist.

Custody

Whose key signs

Your own wallet
SupportedYou sign every transaction in MetaMask, Rabby, Coinbase Wallet or any connector; Vectr never sees the key
Vectr wallet (sign in with X)
Key stored AES-256-GCMKey export disabled; the wallet signs only what you or your read-write key asked for, after the controls
The reason an agent can be given a key at all is that the key cannot do anything the wallet's controls forbid, and the person who owns the wallet set those controls. Set them before you hand out a key, not after.
MCP

The tools an MCP client sees

@vectr/mcp over stdio. Read from the live configuration.

FAQ

Agent questions

Does the Vectr agent sign transactions automatically?

No. Agent jobs return a built, unsigned transaction for a person to confirm. The one automated path is scheduled orders (limit, stop, DCA, TWAP), which you create with an explicit confirmation and which then execute under the same wallet controls when their condition is met.

What can a read-only API key do?

Read: prices, tokens, portfolios, activity, quotes, and it can run research prompts through the agent. It cannot call /wallet/sign-and-submit, so it cannot move funds even if it leaks. Use it for research agents, dashboards and anything that does not need to trade.

What can a read-write API key do?

Everything a read-only key can, plus submit transactions from the owner's Vectr wallet through /wallet/sign-and-submit, subject to the wallet's limits, allowlists and the pause switch. Restrict it to IP addresses and recipient addresses at creation. Treat it like the wallet itself.

What stops the model from draining a wallet?

The model never touches a key. It produces a typed intent; the backend builds the transaction and enforces 9 controls read from the live configuration; a human confirms; and only then does a wallet sign. A wrong intent costs you a confirmation click, not your funds.

Which interfaces expose the agent?

The Terminal (chat), the REST API (POST /agent/job with X-API-Key), the CLI (vectr agent) and the MCP server (@vectr/mcp over stdio) for Claude, Cursor and any MCP client. All four call the same backend and return the same job shape.