"Wallet" is a loaded word in this space, so it's worth being precise about what a DimeBox wallet actually is: not a blockchain wallet, not a bank account, not a prepaid card. It's a closed-loop balance that lives inside DimeBox's own ledger, funded by a card charge through Stripe Checkout, and spent down one priced API call at a time by whoever holds its wallet_secret. No public key, no on-chain address, nothing that moves on Base per call.
x402 settles every paid call as a real USDC transfer on Base - see USDC on Base for why that chain specifically. A wallet skips that entirely. The balance is a number DimeBox tracks against your wallet_secret; spending it debits that number and nothing else. That's what "closed-loop" means here: value goes in once, through a card charge, and comes back out only as DimeBox API calls, never as a transfer to some other address or a cash-out path. It's closer to a prepaid metering account than to a currency.
Three things touch a wallet's balance: funding it (a one-time top-up or a recurring subscription charge, both via Stripe Checkout), spending it (any paid route called with Authorization: Bearer <wallet_secret> instead of a signed x402 payment), and auto-reload, which triggers its own top-up once the balance crosses a threshold you set. Every one of those is a ledger entry - there's no implicit float or estimated balance; what the wallet shows is what it has.
A wallet doesn't get its own charging logic separate from the rest of the API. The same rule that governs x402 settlement - a route only gets paid if its own response comes back under 400 - governs a wallet debit too. A 422 on a malformed drafting request, a reserved slug on a claim attempt, a non-AI inbox rejecting a purpose body: none of that touches the balance, regardless of which payment method got you to the route. See Why DimeBox Never Charges for a Failed API Call for the mechanism behind that.
A wallet carries a small set of settings, managed from /wallet: a daily spend limit, auto-reload (a threshold and a top-up amount), and an optional monthly subscription that replaces one-time top-ups with a recurring credit. Each of those gets its own detailed treatment elsewhere in this pillar - this post is about the ledger underneath them, not the dials on top.
A wallet doesn't start at full trust. For its first few days, a new wallet is capped at a lower balance and a lower daily spend limit than whatever you'd otherwise configure, as a fraud control against stolen cards and throwaway abuse. New-Wallet Risk Controls covers exactly what that cap is and how it loosens over time.
There's no username attached to a wallet by default, no password, nothing to log into to prove you own it - just the wallet_secret shown once at creation. DimeBox doesn't store it in a form it can show you again; see Hashing Secrets Instead of Storing Them for how that's handled server-side. That has the same practical consequence as the inbox read-token model: treat the secret like the only copy of a key, because it is one.
x402 is the more general mechanism - it works between DimeBox and any agent, with no account or balance involved at all. A wallet trades that generality for convenience: one card charge instead of a signer wired into every agent, one balance instead of a transaction per call. Both land on the same priced routes at the same prices; Why Micropayments Finally Make Sense for Machine-to-Machine Commerce covers why per-call pricing itself works at this scale, independent of which payment rail gets you there.
Every credit and every debit on a wallet is its own entry, not a running total that gets overwritten. A top-up is a credit; a draft, a send, a claim, or a priority receive call is a debit; an auto-reload or subscription charge is a credit triggered on a schedule or a threshold rather than by hand. Stacked up in order, those entries are the wallet's actual history - not a snapshot of what you have now, but a record of exactly how the balance got to that number, call by call and charge by charge.
A single balance number tells you what you can still spend. The ledger behind it tells you why - which calls were expensive, whether a given day's spend came from one burst of activity or a steady trickle, whether a top-up actually landed before the calls that depended on it went through. That distinction matters most when something looks wrong: a lower-than-expected balance is a symptom, and the ledger is what you'd actually look at to find the cause, the same way a bank statement's line items matter more than its closing balance when you're trying to track down a specific charge.