Ask "who owns this inbox" about a DimeBox inbox and the honest answer is: nobody, in the account sense. There's no DimeBox account that an inbox belongs to, no login you'd use to prove you're the one who created it, and no user record anywhere that ties a given slug@domain address back to a person. That's not an oversight — it's the whole point.
When an inbox is provisioned through the paid claim route, a payment settles — a wallet or an x402 signature pays the $1.00. You might reasonably expect that payer's address to be recorded as the inbox's owner. It isn't. DimeBox never stores which wallet or address paid to create a given inbox, on either the free or the paid provisioning route. Why DimeBox never stores which wallet paid for an inbox covers the reasoning behind that choice directly.
Possession, not identity. Three separate things can each be done by whoever is capable of doing them, with no cross-check against who created the inbox in the first place:
read_token issued once at creation. Whoever holds that string can read the mailbox — see read tokens explained.POST /api/inboxes/{slug}/send. Any wallet or signer willing to pay can send from the inbox's address — the inbox doesn't check that the sender is the same party who created it.Put together: an inbox's "owner" is really just whoever currently holds its read token. There's no deeper layer of identity underneath that to fall back on, and no account to re-authenticate against if the token changes hands or gets lost.
Treating an inbox as ownerless-by-design has a direct consequence for privacy: there's no record linking a wallet address to the inboxes it created, which means there's nothing for DimeBox to leak, subpoena, or get breached, because it was never collected. If abuse does happen through a given inbox, investigating it can't start from "which wallet created this" — the design rules that lookup out from the start. Abuse investigation without compromising agent privacy covers how that tension gets handled in practice.
The same design that protects privacy also means there's no recovery path. If the read token is lost, there's no owner record to verify a reset request against — rebuilding that would mean rebuilding the exact wallet-to-inbox link the system was designed to avoid keeping in the first place. Losing your inbox read token covers that consequence directly. And because nothing ties an inbox back to a creator, sharing the read token with another process is functionally the same as sharing ownership — there's no way to grant partial or revocable access short of handing over the one credential that controls everything.
Most systems treat "who can use this resource" and "who is this resource associated with" as the same question, answered by one account. DimeBox inboxes split them apart deliberately: an inbox has an address and a credential, but no identity behind it in any sense a human account system would recognize. Whether that's enough identity for a given agent's purposes is worth thinking through before you build around it — does an AI agent need an identity asks that question starting from exactly this inbox model.
Because nothing deeper than the read token exists, granting another process access to an inbox means handing over that exact string — there's no way to issue a second, scoped-down credential that can read but not do anything else, or that expires after a set time. Whoever has the token has everything the token grants, for as long as they have it, and there's no way to revoke it short of abandoning the inbox and provisioning a new one. If an agent architecture needs several components to see the same mailbox, the practical options are: share the one token between them and accept that any of them can read everything, or have one component hold the token and relay messages internally to the others.
It's tempting to assume whoever pays the $1.00 claim fee, or whoever pays to send from an inbox, has some special relationship to it that DimeBox tracks. It doesn't. The wallet or signature used to pay for an action is only ever checked for "did this authorize enough value to cover the price" — it isn't stored as a durable link back to the inbox afterward. Paying to claim a name and paying to send a message later don't need to be the same party, and DimeBox has no way to tell if they are. x402 vs OAuth digs into why payment authorization and identity are different problems that x402 deliberately doesn't try to solve together.