A DimeBox wallet exists to skip the 402 round trip. Instead of signing a payment for every call, you fund a wallet once through Stripe Checkout and then authenticate paid requests with Authorization: Bearer <wallet_secret> — same prices as paying directly over x402, no signature, no retry loop. That convenience is also exactly what makes a brand-new wallet an attractive target: a funding flow that takes seconds and asks for no signup is just as fast for someone testing a stolen card as it is for a developer standing up a new agent.
DimeBox's answer isn't to slow down funding or add identity checks before you can use a wallet at all. It's to cap what a wallet can do immediately after it's created, for a short window, regardless of how it was funded.
New wallets start capped at a $50 total balance and $10 of spend per day, for their first few days. A wallet can still draft emails, send from an inbox, or pay for priority receive during that window — it just can't hold much money at rest while it's unproven, and it can't burn through a large amount in a single day.
That's a meaningfully different design than an outright block on new wallets. An agent that needs to send a handful of emails on day one can still do it immediately. What the cap removes is the combination that matters most if a funding source turns out to be fraudulent: a large balance sitting in a wallet, available to spend in one high-volume burst before anyone — DimeBox or the card network — has had a chance to notice anything is wrong.
It's worth being precise about where this control applies. If you pay over x402 directly — signing a USDC payment from your own wallet on Base for each call — there's no DimeBox-hosted balance at all; each request settles against the chain at the moment it's made, and the new-wallet cap doesn't enter into it. The cap is a property of the card-funded wallet product specifically, where DimeBox is holding a balance on your behalf between funding and spending. See why a card-funded wallet exists as an alternative to paying over x402 for the distinction.
DimeBox has no accounts, no support tickets tied to a wallet, and no identity to review in the first place — see how the wallet works as closed-loop credit. There's nobody to escalate a "please lift my cap" request to, and that's by design. A time-boxed, automatic limit that expires after a few days fits a system built around secrets instead of accounts far better than a manual review queue would: you wait on a clock, not a person, and DimeBox doesn't need to collect anything about you to decide when the clock runs out.
A wallet's own configured daily spend limit and auto-reload rules still apply during the capped window — they just operate inside a smaller ceiling. If you set a $30 daily limit on a wallet that's still within its first few days, the $10 new-wallet cap is the number that actually binds, because the stricter of the two always wins. Auto-reload will still top up the wallet once it crosses your configured threshold, but a top-up can't push the balance past the new-wallet ceiling either — it tops up into the capped range, not past it.
In practice, a newly created wallet used for light, early testing — a handful of drafted emails and sends while you're wiring up an agent — behaves exactly the way you'd expect, with no friction. Only an agent trying to move real volume through a day-old wallet will notice the ceiling, which is the point: a fraudulent funding source gets a few days of limited exposure, not an unlimited one.
If what you actually need during development is volume — hammering the send and receive endpoints to shake out bugs in an agent loop — a new-wallet cap on a mainnet wallet isn't the right thing to test against anyway. Base Sepolia exists for exactly this: pay with test USDC on Base's testnet, with no real money and no card involved, and save the card-funded wallet for when the agent is ready to run against real inboxes and real recipients.
Once the window passes, the wallet is just a wallet — the same closed-loop credit model as any other, governed only by whatever daily spend limit you've set yourself and however much you've funded it. There's no separate "graduation" call to make or status field to check; it's a property of the wallet's age, not a flag anyone sets.
If you're building an agent that needs to move meaningful volume from day one in production, plan around this rather than against it: provision the wallet a few days ahead of when you need the capacity, or fund modestly at first and scale up once the window has passed. See the wallet page for current limits and to fund one.