DCP: The Agentic Wallet for Solana AI Agents

AI agents on Solana are past the demo stage. They pay for APIs, rebalance small portfolios, buy data, tip services, and settle x402 requests. Real economic activity, running while you sleep.

All of it needs a wallet. And this is where most agent stacks quietly break, because the two wallet models we have were both built for a world without agents.

Human wallets like Phantom assume a person is present to click every confirmation. An agent cannot use that.

Raw keypairs in a config file assume total trust. The agent holds the private key, so the agent can sign anything, forever, with no limits and no log. You should not use that.

Agents need a third model. That model is an agentic wallet, and it is what DCP builds for Solana.

What Is an Agentic Wallet?

An agentic wallet is a wallet an AI agent can operate under rules a human sets. The agent can check balances, send tokens, swap, and pay for services on its own. The human keeps custody of the private key, sets budgets and approval thresholds, sees every action in an audit log, and can revoke the agent at any time.

The line it draws is simple:

The agent gets an allowance. You keep the keys.

Compare the three models side by side:

	Human wallet (Phantom)	Raw key in config	Agentic wallet (DCP)
Agent can act autonomously	No	Yes	Yes, within limits
Human holds custody	Yes	No	Yes
Spending limits	Manual	None	Enforced per currency
Approval for big actions	Every action	Never	Above your threshold
Audit log	No	No	Every action
Instant revoke	n/a	Rotate keys everywhere	One click

The Wallet Toolset Agents Get

Agents connect to DCP over MCP, from Claude Desktop, Cursor, VS Code, OpenClaw, custom clients, or a paired remote server. The Solana wallet surface splits into two halves: things an agent can do freely, and things that go through policy.

      read freely                          act with rules
 +--------------------------+   +-----------------------------------+
 | vault_get_address        |   | vault_transfer    SOL + SPL       |
 | vault_get_balances       |   | vault_swap        via Jupiter     |
 | vault_get_tx_history     |   | vault_sign_tx     any built tx    |
 | vault_get_tx_status      |   | vault_sign_message                |
 | vault_search_tokens      |   | vault_sign_x402   api payments    |
 | vault_budget_check       |   |                                   |
 +--------------------------+   +-----------------------------------+

The read half costs nothing and asks nothing. An agent can look up its address, check SOL and SPL balances, pull recent transaction history, check the status of a signature, search the Jupiter token list by symbol or mint, and ask whether an amount would pass its budget before even trying.

That last tool matters more than it looks. vault_budget_check lets a well built agent plan around its limits instead of slamming into them. Check first, act second.

The action half is where the rules live:

• vault_transfer builds, signs, submits, and confirms a SOL or SPL token transfer in one call
• vault_swap executes a token swap routed through Jupiter
• vault_sign_tx signs a transaction the agent built itself, for anything the higher level tools do not cover
• vault_sign_message signs a wallet message, for login flows and ownership proofs
• vault_sign_x402 signs an x402 payment payload for pay-per-request APIs

Every one of these passes through the same pipeline before anything hits the chain.

What Happens When an Agent Sends a Transfer

Say your agent calls vault_transfer for 0.5 SOL:

 agent: transfer 0.5 SOL to <address>
     |
     v
 1. request signature verified (Ed25519)
     |
     v
 2. scope check ......... does this agent have signing access?
     |
     v
 3. budget check ........ per-transaction limit
     |                    rolling daily limit
     v
 4. threshold check ..... above your approval line?
     |                    -> approval request on desktop or Telegram
     |                    -> no answer in 5 minutes means no
     v
 5. vault executes ...... build, sign, submit, confirm
     |                    key decrypted for milliseconds, then wiped
     v
 6. audit log ........... agent, amount, outcome, timestamp

The agent gets back a signature and confirmation, or a clear error it can explain to you. What it never gets is the key.

Budgets Are Per Currency and Per Agent

Limits are enforced per currency, and every number is configurable per agent. The defaults out of the box:

Currency	Per transaction	Per day
SOL	0.01	0.05
USDC	1.00	5.00
USDT	1.00	5.00

Three separate checks run on every spend:

1. Per-transaction limit. One oversized transaction gets rejected outright, with error code BUDGET_EXCEEDED_TX.
2. Rolling daily limit. The vault sums the agent's spend over the last 24 hours. Crossing the cap returns BUDGET_EXCEEDED_DAILY.
3. Approval threshold. Below it, transactions flow without friction. Above it, a human gets an approval request with the amount, recipient, and purpose, on the desktop or as Approve and Deny buttons in Telegram.

There is no setting that turns this off wholesale. You can loosen the numbers for a trusted agent, but spending always runs through the pipeline. A rate limiter adds one more backstop: 5 executions per minute per agent session.

This is the property that makes autonomous spending survivable. If a prompt injection convinces your agent to send everything to an attacker, the per-transaction cap rejects it, the daily cap bounds the worst case, and the attempt sits in the audit log with the agent's name on it.

Swaps Without Custody

vault_swap gives agents token swaps through Jupiter, Solana's main liquidity router. The agent picks the pair and amount, and can use vault_search_tokens to resolve a symbol to a mint address first. The vault builds the swap, checks it against the same budgets and thresholds as any transfer, signs inside the vault, and submits.

That enables agents that rebalance a small portfolio, convert earnings to USDC on a schedule, or maintain a working balance of a token they spend often. All of it inside a budget you set, all of it logged.

x402: Agents That Pay for What They Use

x402 is the emerging standard for machine payments over plain HTTP. An API returns a payment challenge, the client signs a payment, retries the request, and gets the resource. No account, no subscription, no card. Solana's fees and settlement speed make it a natural fit.

vault_sign_x402 slots DCP into that flow. The agent passes the payment payload plus the amount, recipient, and purpose. The vault runs the budget pipeline and returns a signature the agent attaches to its request.

Two details are deliberate:

• The vault signs exactly the bytes it receives. If anything modifies the payload in transit, the signature fails to verify on the server. Nothing between your agent and the vault can rewrite a payment.
• The vault signs but does not submit. The agent makes the HTTP request itself. Signing authority and network activity stay separated.

In practice: your research agent pays a data API a fraction of a cent per call, forty times a day, without asking you once. The day it tries to cross the daily cap, your phone buzzes instead.

Where the Key Actually Lives

DCP is non-custodial in the strict sense. The Solana keypair is generated on your machine and stored in the vault's encrypted storage, under envelope encryption with XChaCha20-Poly1305 and a master key in your OS keychain. Recovery is a 12-word phrase shown once at setup.

When an approved operation needs a signature, the vault decrypts the key in memory, signs, and wipes it with sodium_memzero(), a zeroization call the compiler cannot optimize away. The decrypted key exists for a few milliseconds.

No tool returns key material to an agent. Not vault_sign_tx, not anything. Agents receive addresses, signatures, and results. Remote agents get the same treatment through an end-to-end encrypted relay, so the key never leaves your machine even when the agent runs on a VPS.

The full architecture, including the encryption layers, scopes, and remote pairing ceremony, is covered in How DCP Works.

What People Build With This

The API-paying research agent

Pays per request for data through x402. Tiny payments flow automatically under the threshold, hard capped daily. The agent works all day without a single popup, and cannot exceed its allowance.

The DCA agent

Swaps a fixed amount of USDC to SOL every day through vault_swap. The per-transaction limit matches the DCA size, so even a confused agent cannot buy more than one day's amount at once.

The treasury agent on a leash

Handles routine transfers for a small project: contributor payouts, service payments, top-ups. Everything above the threshold lands in Telegram for a human tap. Everything below it just happens, and the audit log keeps the receipts.

The remote worker

Runs 24/7 on a VPS with zero secrets on the server. It paired with the desktop vault once, and every wallet action it takes routes through the encrypted relay into the same budget pipeline as a local agent.

FAQ

What is an agentic wallet?

A wallet an AI agent can operate autonomously under human-defined rules: spending limits per currency, approval thresholds for large actions, a full audit log, and instant revocation, while the private key stays with the human.

Is DCP custodial?

No. The keypair is generated and stored on your machine, encrypted at rest, and never uploaded anywhere. DCP the project cannot access your funds. There is no server that holds keys.

Can an agent drain my wallet?

Not within the rules. Per-transaction and daily limits are enforced on every spend, large actions require your approval, and there is no blanket auto-approve for spending. The worst case is bounded by the numbers you configure.

Which tokens does it support?

SOL and SPL tokens for balances and transfers, and any pair Jupiter routes for swaps. Budgets are configured per currency.

Does the agent build transactions or does DCP?

Both work. vault_transfer and vault_swap handle building, signing, and submitting in one call. Agents that build their own transactions can use vault_sign_tx, and the same budget and approval rules apply either way.

Does it work with Claude, Cursor, and OpenClaw?

Yes. Any MCP client can connect, locally over stdio or HTTP, or remotely through the encrypted relay after pairing.

Is it open source?

Yes: github.com/1lystore/dcp.

The Bottom Line

Solana gives agents cheap, fast economic rails. What was missing is a wallet built for how agents actually operate: autonomous within limits, supervised above them, logged always, revocable instantly.

That is the agentic wallet, and it is what DCP ships. Not a human wallet with the popups removed, and not a raw key with hope attached. An allowance with teeth.

Give AI agents permissions. Not your keys.

Download DCP Desktop at dcpagent.com, read How DCP Works for the architecture, or start with the getting started guide.