Closing accounts
Every SithBit account is a Solana account, and creating any Solana account requires a one-time SOL deposit — rent-exemption — that scales with how many bytes the account stores. It isn’t a fee: it’s a refundable deposit that sits in the account for as long as it exists, and it has nothing to do with any price or value the account might represent (a mailbox’s rent, for example, is the same regardless of how much postage it charges). Closing an account you no longer need reclaims that rent back to you. See Solana’s account model docs for the full mechanics of how the minimum balance is calculated.
| Command | Signer | What’s reclaimed |
|---|---|---|
mailbox close | Mailbox owner | The mailbox account’s rent — only at --finalize, 7 days after the request (see below) |
mailbox key close | Mailbox owner | The delegated encryption key account’s rent |
frombox close | Recipient (mailbox owner) | The frombox’s rent plus its remaining stamp value |
frombox reclaim | Wallet-literal sender | The sender’s own unspent prepaid postage — not the rent, which keeps the frombox alive |
alias close | Current alias holder | The alias account’s rent (refused while a transfer offer is pending — cancel the offer first) |
domain close | Delegate | The domain account’s rent, refunded to whoever paid it originally |
One row in that table is not a close at all: frombox reclaim leaves the
account standing. It exists because a frombox holds two different people’s
money — the rent, deposited by whoever opened it, and the prepaid postage,
deposited by the sender. frombox close hands the whole balance to the
recipient; frombox reclaim lets the sender take back only the postage it
prepaid and never spent, leaving the account alive on its rent so the
recipient keeps the price it set. See
Reclaiming unspent stamps.
Closing a mailbox is timelocked
Every command in the table above reclaims its rent in one transaction —
except mailbox close, which is a two-step, 7-day flow:
sithbit mailbox closerequests the close. It stamps a small transient PDA with the chain time and starts the clock. The mailbox stays open and keeps receiving mail, and no rent comes back yet — the request in fact costs the owner the transient account’s own rent until the flow resolves.sithbit mailbox close --finalize, run once at least 7 days have passed, actually closes the mailbox and refunds both rents — the mailbox’s and the transient account’s — to the owner.sithbit mailbox close --cancel, run any time before finalize, aborts the request: the transient account’s rent comes back and the mailbox is untouched.
The delay exists because an instant refund made discarding a burned
identity free, which is a spammer’s economics, not an honest owner’s. The
owner pays in time on a rare action, never in money — the rent is returned
in full. The retired one-step CloseMailbox instruction is refused
on-chain with error 94, InstantCloseDisabled. See
Close a mailbox.
mailbox key close is not timelocked and stays in the table above as
an instant close: it revokes a compromised delegated encryption key, and a
week-long window there would keep MX servers sealing to the compromised
key — protecting the attacker rather than the owner.
Note: closing drains an account’s lamports to zero, at which point Solana’s runtime deallocates it — so a closed account’s address can generally be recreated later with the matching
createcommand. The one caveat: recreating a mailbox restarts its message-id counter at zero, so any of its old, still-open message accounts (which persist independently of the mailbox itself, settled separately bymail delete) can collide with new sends until they’re cleared out. This is an availability nuisance, not a loss of funds — closing a mailbox that still has undelivered mail is worth avoiding rather than treating as harmless.