MoonPay PayBox Explained: How AI Agents Can Use Ethereum, Solana and Layer-2 Wallets

If you want an AI agent to actually push a transaction on-chain without handing over your keys, PayBox is the new piece everyone’s kicking the tires on. It slots in between your agent and your wallets, mediating what the agent can do and for how long.

MoonPay announced the product publicly on July 23, 2026, with a stated go-live for July 28 and a hook that non-technical users could connect it to assistants like Claude or ChatGPT to complete purchases (Fortune). That naturally raised the question: how does this work with Ethereum, Solana, and the L2s most of us use daily?

Let’s break down what PayBox actually is, what it isn’t, and a practical path to wire it into an agent without blowing past your risk limits.

PayBox, in plain English

Think of PayBox as a programmable keyring your agent can ask for a very specific key from, just for a moment, to do a narrowly defined job. It’s not a wallet that holds your assets. It’s the gatekeeper that says: you can spend up to X, only on chain Y, only to these addresses, and your pass expires in 10 minutes. Then it hands back a scoped token or signature and logs it.

MoonPay’s own docs call it an agents-first credential vault and stress it’s a control plane only. No custody. No raw keys blasted through a third party. Instead, it returns tightly scoped outputs such as scoped payment tokens, signatures, or transaction hashes (MoonPay — Terms of Use (Launchpad)).

On the privacy side, Launchpad’s policy says secrets are user-managed, and Launchpad doesn’t collect or present raw secrets or KYC on your behalf (MoonPay — Launchpad Privacy Policy). That aligns with a non-custodial, agent-mediation approach: you hold the sensitive bits, and PayBox helps you create short-lived, task-specific permission artifacts for your agent.

Also worth noting: MoonPay framed PayBox as something you can wire into assistants like Claude or ChatGPT so those agents can complete purchases on your command, with launch planned for July 28, 2026 (Fortune). That hints at consumer-friendly flows, but the guts matter most for builders.

Chains and tooling you can touch today

The developer surface is the make-or-break detail. The npm profile tied to the project lists @paybox-sh/sdk with a typed Node SDK and CLI, plus framework adapters for viem (which covers Ethereum mainnet, most EVM L2s like Base, Arbitrum, Optimism, etc.) and a Solana adapter. It also calls out in-process non-custodial signing, which is what you want in an agent loop (npm).

That translates to a pretty straightforward picture:

• EVM and L2: Use the viem adapter to build, simulate, and sign transactions your agent proposes, with your scopes enforced at the PayBox layer and in your own guardrails.
• Solana: Use the Solana adapter to create and sign instructions for transfers, mints, or program calls, again bound by scopes.

Pro tip: Scopes aren’t magic if your code ignores them. Mirror the same limits in your application code and logs, then treat PayBox as a second line of defense.

Wiring an AI agent to a wallet the safe way

1) Define the job, then the scope

Start with the smallest thing your agent needs to do. Example: “Send up to 25 USDC on Base to this allowlist of 3 addresses, valid for 15 minutes.” That becomes a scope.

2) Install and initialize the SDK

Set up @paybox-sh/sdk in your Node agent runtime, then attach the chain adapter you need (viem for EVM/L2s or Solana for SOL-land). From there, your agent requests a scoped credential when it reaches a transaction boundary.

// Pseudocode: EVM transfer via viem + PayBox import { createWalletClient, http } from 'viem'; import { base } from 'viem/chains'; import { PayBox } from '@paybox-sh/sdk'; const paybox = new PayBox({ projectId: process.env.PAYBOX_PROJECT }); // Scope request your operator approves out-of-band const scope = await paybox.createScope({ chain: 'base', token: 'USDC', maxAmount: '25', // units in token decimals toAllowlist: ['0xabc...', '0xdef...', '0x123...'], ttlSeconds: 900, purpose: 'agent-tip-jar', }); const client = createWalletClient({ chain: base, transport: http() }); // Agent proposes a transfer const { to, amount } = agentDecision(); // Ask PayBox for a scoped signer for this one action const signer = await paybox.getSigner({ scopeId: scope.id }); // Build + simulate before sending const hash = await client.sendTransaction({ account: signer, to, value: 0n, data: encodeUSDCTransfer(to, parseAmount(amount)), }); console.log('txHash', hash);

3) Simulate, then send

Never skip simulation. Agents hallucinate. Networks reorg. Contracts change. Simulate the exact calldata or instruction with current state before you sign and broadcast. Drop the transaction if results don’t match expectations or if gas spikes beyond your cap.

4) Log everything and auto-revoke

Attach breadcrumbs: prompt hash, input URLs, decision tree summary, and the exact scope ID used. Then set your scopes to expire quickly. If something goes sideways, you have context and a short blast radius.

Designing scopes that actually protect you

Set tight monetary caps

Dollar or token-denominated caps save you from fat-fingered amounts and prompt-injection attempts. For volatile tokens, cap on token units and enforce a slippage ceiling in your swap helper.

Limit functions, not just addresses

Allow transfer and block approve by default. If you must approve, set a minimal allowance and auto-revoke after the job. Infinite approvals are where small experiments turn into big losses.

Constrain chain and program IDs

Scope to a single network (e.g., Base only) and, for Solana, the specific program IDs you trust. Wrong-chain sends are the easiest way to burn time and money.

Use allowlists and purpose strings

Allowlists catch obvious exfil attempts. Purpose strings help you audit what a scope was meant to do later, when you’re combing through logs.

Short TTLs and one-shot signers

Favor 1–15 minute expirations and single-use credentials. If your agent needs to do multiple steps, chain small scopes together instead of one big umbrella.

Strong scopes plus app-level checks beat clever model prompts. Don’t rely on the agent to police itself.

Operational hygiene: prompts, logs, and fallbacks

• Guardrails in the prompt are helpful, but never sufficient. Assume prompt injection is a given.
• Pull prices and ABI metadata from trusted, signed sources. Don’t let the agent paste ABIs from random links.
• Implement chain-aware sanity checks: reject transactions that don’t match scope chain ID or token addresses.
• Throttle and rate-limit. If the agent loops, you don’t want a burst of signed junk.
• Human-in-the-loop for larger sums. A mobile push to approve a scope is usually enough friction.
• Keep a circuit breaker: a single flag that freezes all scopes if monitoring detects anomalies.

Pro tip: On swaps, require simulation to return a minimum out and cross-check pool addresses against a local allowlist. Auto-abort if MEV risk or price impact exceeds your threshold.

Two quick walkthroughs

Example A: Send USDC on Base to an allowlisted address

1. Agent determines it owes 12.50 USDC to address X.
2. App requests a scope: Base, USDC, max 15, allowlist [X], TTL 10 minutes.
3. Agent builds a USDC transfer, simulates, then signs with the scoped signer from PayBox.
4. Broadcast and store tx hash with the scope ID.

// Pseudocode for the core send const scope = await paybox.createScope({ chain: 'base', token: 'USDC', maxAmount: '15', toAllowlist: [X], ttlSeconds: 600 }); const signer = await paybox.getSigner({ scopeId: scope.id }); const tx = await client.sendTransaction({ account: signer, to: USDC_ADDRESS, data: encodeUSDCTransfer(X, toUnits('12.5')) });

Example B: Solana SOL transfer with program constraints

1. Scope: Solana mainnet, SOL transfers only, cap 0.2 SOL, TTL 5 minutes.
2. Agent creates a system program transfer instruction.
3. Simulate with current blockhash, then sign using the scoped signer.

// Pseudocode: Solana transfer import { SystemProgram, Transaction, sendAndConfirmTransaction } from '@solana/web3.js'; const scope = await paybox.createScope({ chain: 'solana-mainnet', programAllowlist: ['11111111111111111111111111111111'], maxLamports: toLamports(0.2), ttlSeconds: 300 }); const signer = await paybox.getSigner({ scopeId: scope.id }); const ix = SystemProgram.transfer({ fromPubkey: signer.publicKey, toPubkey: recipient, lamports: toLamports(0.05) }); const tx = new Transaction().add(ix); const sig = await sendAndConfirmTransaction(connection, tx, [signer]);

These are toy flows on purpose. In production you’ll pair scopes with your own simulation, ABI/IDL checks, logging, and timeouts.

Where PayBox sits in your stack

PayBox is a coordinator. It isn’t your wallet, and it isn’t a custody layer. MoonPay’s Launchpad terms flag it as a control plane that returns scoped outputs rather than raw credentials (MoonPay — Terms of Use (Launchpad)). Its privacy doc says user-managed secrets stay with you, and Launchpad doesn’t collect or present raw secrets or KYC on your behalf (MoonPay — Launchpad Privacy Policy).

So your architecture likely ends up like this:

• Your non-custodial wallets hold assets and keys (hardware-backed if you can manage it).
• PayBox mediates what actions an agent can take with short-lived, scoped credentials.
• Your app enforces business rules, runs simulations, logs, and initiates human approvals for high-value scopes.
• Agents propose actions and only get the power they need, when they need it, nowhere else.

On the EVM and Solana side, the SDK surface provides the glue to make that experience less bespoke (npm). If you’re maintaining adapters yourself today, there’s a good chance you can simplify.

PayBox landing-page illustration (trading-swap.webp) showing an agent-initiated on‑chain swap (e.g., USDC → ETH), illustrating PayBox’s on‑chain signing and support for Ethereum/EVM workflows. — Source: PayBox (MoonPay) landing page

What to watch after launch

MoonPay’s public note pointed to July 28, 2026 for go-live and mentioned assistant integrations to help non-technical users complete purchases (Fortune). For teams evaluating PayBox, a few areas are worth tracking as usage ramps:

• Scope fidelity: Are scopes enforced exactly, especially around approvals and contract calls?
• Adapter maturity: viem and Solana adapters covering edge cases, from ERC-777 hooks to Solana CPI nuances.
• Latency and rate limits: Whether scoped signer acquisition adds noticeable lag in agent loops.
• Audit trails: How easy it is to correlate a signed action with a scope and a human approval.
• Ecosystem tooling: IDE plugins, policy templates, and dashboarding for non-technical operators.

Pro tip: Treat the first month as a guarded beta in your own environment. Caps low, scopes granular, and kill switches armed.

Pricing, limits, and compliance questions to ask

Pricing specifics and enterprise tiers weren’t detailed in the sources we reviewed. Still, procurement checklists tend to rhyme. Here’s a practical set of questions for a vendor call:

• How are scopes represented, logged, and revocable? Can we export logs to our SIEM in real time?
• What’s the signer format on EVM and Solana, and how are nonces/blockhashes handled for replay protection?
• Do you support pre-transaction simulation hooks and custom risk policies?
• What are the default rate limits, and how do bursts get handled?
• How do you segregate projects, operators, and environments (dev/stage/prod)?
• Where does any at-rest metadata live, and what’s the retention policy? The privacy notice says secrets are user-managed — confirm where boundaries sit (MoonPay — Launchpad Privacy Policy).
• For regulated teams: how do we pair this with our own KYC/AML without routing raw identity through Launchpad, given it doesn’t collect or present KYC on users’ behalf (MoonPay — Launchpad Privacy Policy)?

Bottom line: Get clarity on scope enforcement, auditability, and boundaries around secrets. Build your own policy layer on top regardless.

Frequently Asked Questions

Is PayBox a wallet or a custody service?

Neither. MoonPay describes PayBox as a control plane and agents-first credential vault. It doesn’t custody funds and returns scoped outputs like tokens, signatures, or transaction hashes instead of raw credentials (MoonPay — Terms of Use (Launchpad)).

Can I connect PayBox to assistants like ChatGPT or Claude?

Yes, that’s part of the pitch. MoonPay’s July 23 announcement said PayBox can plug into assistants such as Claude or ChatGPT so they can complete purchases, with go-live aimed at July 28, 2026 (Fortune).

Which chains does PayBox support?

The SDK surface lists adapters for viem (covering Ethereum and many EVM-compatible L2s) and for Solana, with in-process non-custodial signing. The npm profile shows a v0.5.0 release around July 13, 2026 (npm). Always check current docs before deploying.

Does MoonPay see my private keys or raw secrets?

Launchpad’s privacy notice says secrets are user-managed and that the service does not collect, verify, or present raw secrets or KYC on your behalf (MoonPay — Launchpad Privacy Policy). Architect your app so sensitive material never leaves your control.

What risks should I mitigate before letting an agent transact?

Start with prompt-injection defenses, strict scopes, allowlists, monetary caps, slippage ceilings, and mandatory simulation. Avoid blanket approvals and keep scopes time-limited. Add human approval for larger amounts.

How is PayBox different from a custodial wallet API?

A custodial API controls assets for you. PayBox acts as a coordinator for scoped credentials while assets and secrets stay under your control, per MoonPay’s description (MoonPay — Terms of Use (Launchpad)).

Can enterprises enforce compliance without routing identity through Launchpad?

Based on the privacy notice, Launchpad isn’t designed to collect or present KYC on your behalf. Enterprises typically layer their own KYC/AML and policy checks in their app, then use PayBox to constrain what agents can do within that framework (MoonPay — Launchpad Privacy Policy).