When you provision or claim an inbox on DimeBox, a payment settles — either a signed x402 payment from your own wallet, or a deduction from a DimeBox wallet's balance. Either way, DimeBox does not store which wallet or address paid for the resulting inbox. The inbox row that gets created has a slug, a read token, and whatever settings you passed; it has no column linking back to a payer.
It means there is no query DimeBox could run — not for a support request, not for an investigation, not for DimeBox's own analytics — that answers "which wallet created inbox acme-support." That link simply isn't recorded at the moment the inbox is created. The read token issued at creation is the only thing that controls the inbox afterward, and it has no relationship to whatever paid for it.
This is consistent with how DimeBox treats inbox ownership generally: an inbox isn't owned by an account, because there are no accounts. See who owns an agent's inbox for the fuller picture of what "ownerless by design" means here — this post is about one specific piece of that design, the payment side.
It's worth being precise about what's actually private here. A USDC payment settled over x402 happens on Base, a public chain — the transfer itself, the paying address, and the amount are all visible to anyone who looks, the same as any other on-chain transfer. What doesn't exist anywhere is the connective tissue DimeBox itself would need to tie that specific transfer to the specific inbox it paid for. Someone watching the chain can see that an address sent a payment matching the claim price around a certain time; they can't get that information from DimeBox, and DimeBox can't produce it either, because it was never written down.
An agent's inbox is often the only identity it has for a given task — see whether an agent needs an identity at all, starting with its inbox. Tying that identity back to a specific funding source, even internally, would mean every inbox carries an implicit record of who funded the agent behind it. For a product built around disposable, task-scoped inboxes — created in one call, used for a while, and often never touched again — that kind of record accumulates risk without buying DimeBox or its callers much: it's one more thing that could leak, be subpoenaed, or be queried in ways nobody creating a throwaway inbox for a short-lived agent task expected.
Not storing the link in the first place is a stronger guarantee than any access-control policy on top of a stored link could be. A policy says "we won't look." Not having the data means there's nothing to look at.
This cuts both ways. Because there's no stored link between a wallet and an inbox, you can't go back to DimeBox with "I paid from this wallet, which inbox did that create" and get an answer — the read token shown once at creation time really is the only way back in, with no fallback via payment history. If you lose it, there's no recovery path through the wallet you used to pay, because DimeBox genuinely doesn't have that connection to follow. That's the same "no recovery" property that applies to losing a read token generally, just restated from the payment side: there is no secondary record anywhere that could substitute for the token.
This design decision does have a real cost: it narrows what DimeBox itself can reconstruct after the fact if an inbox is used for something abusive. Investigating abuse on DimeBox works at a different layer entirely — the wallet or payment credential being used right now, not a historical link to whoever paid for an inbox months ago. See how abuse investigation works without that stored link for how the two goals — not recording unnecessary data, and still being able to respond to abuse — coexist in practice.
It's worth being clear about what this fact doesn't say, since it's easy to overstate. DimeBox not storing a wallet-to-inbox link doesn't mean DimeBox stores nothing at all about an inbox — a slug, a read token hash, message history, and whatever settings you passed at creation all exist and are exactly what you'd expect for the inbox to function. The one specific thing missing is the backward link from that inbox to whoever funded its creation or claim. That's a narrow, deliberate omission, not a general absence of record-keeping, and it's worth reading it that way rather than as a broader claim about DimeBox keeping no data at all.
It also doesn't mean a wallet's own activity is unlinkable. A wallet secret still authenticates every call made against that wallet, and DimeBox can absolutely act on the wallet itself — capping it, limiting it, rejecting calls from it — without ever having recorded which inboxes that wallet's payments went toward. The wallet and the inbox are two independent objects in the system; the gap is specifically in the edge that would connect them, not in either object's own history.