What’s public and private: the field reference
This is the precise companion to What’s public and private: a field-by-field inventory of what SithBit exposes. The plain-language overview lives there; this page is the exhaustive list for anyone who wants to verify exactly what a third party can read.
Ground rule: every on-chain account is a world-readable Solana account holding borsh-serialized plaintext. There is no on-chain confidentiality. Every field listed below is readable by anyone. The only on-chain privacy technique SithBit uses is hashing address strings so the string isn’t stored — the hash still confirms a guessed address (see message metadata is hashed, not hidden).
On-chain accounts (all fields world-readable)
| Account | Public fields | Notes |
|---|---|---|
| Mailbox | mail_count, default_postage, domain, no_ipfs | 1:1 with a wallet via its PDA, so the owning wallet is public too. no_ipfs reveals your storage preference. |
| Mailbox key | pub_key (base58 X25519) | Only present if you published a delegated key. It is a public key by nature. |
Message (Email) | sender (wallet), from_hash (blake3 of from), epoch (timestamp), cid (IPFS CID or a b3: local-only marker), bounty_lamports, expires_at, reply_to_hash | No address strings. Recipient = the wallet the PDA seeds on. Human From:/To:/Subject: live only in the sealed body. Survives DeleteMail. |
| Frombox | required_postage, stamps | Keyed by a PDA on (blake3(from), recipient wallet) — the from string is never stored, only its hash. |
| Alias | address (the target wallet) | The alias→wallet mapping is fully public. The human-readable alias name is the PDA seed, so it is effectively public too. |
| MailDomain | is_active, authority, rent_payer, domain (cleartext DNS name) | The domain name is stored in the clear. |
| Postoffice | fee fields, root_ksk, delegate_address, commitment_root | The postmaster (owner) key is not on-chain — only an opaque Merkle commitment_root. See the postoffice admin keys. |
| AliasListing | holder (seller), price_lamports, created_at, expires_at, mode, antisnipe_window_secs, high_bid_lamports, high_bidder | Marketplace state, including the winning bidder’s wallet — who is buying what, for how much. |
| DomainListing | holder (seller), price_lamports, created_at, expires_at | Same, for domains. |
| DomainAlias | address (the target wallet) | The domain-scoped alias→wallet mapping, as public as the global one. The alias name is the PDA seed, so it is effectively public too. |
| AliasEscrow | recipient, fee_lamports, offered_at, expires_at | A pending alias hand-off: who the alias is offered to, at what fee, and the offer’s window. |
| AliasBid | bidder, amount_lamports, bid_at | Auction state: every bidder’s wallet and bid amount are public while the auction runs. |
| ParticipantBeacon | tags (bitmap), detail_cid_len, detail_cid, created_at, updated_at, owner (wallet) | Marketplace opt-in is fully public by design: the wallet, its self-attested tags, and the CID of its rich-profile blob. The blob’s content is encrypted; its existence and update times are not. |
| SenderAttestation | domain (cleartext DNS name), wallet, attested_at | Publicly binds a sending wallet to a domain — that is its purpose (the client trust mark). One account per (domain, wallet). |
| SenderReputation | wallet, cumulative_spend_lamports | A sender wallet’s cumulative first-contact postage spend is public; the individual recipients behind it are not stored here. |
| PinLease | cid_hash (blake3 of the leased CID), holder (wallet), created_at | Publicly binds the holder wallet to a message CID — anyone who knows a CID can see who leased it (and its lamport balance reveals the deposit). The CID itself is stored only as a hash, but message CIDs are public on their Email accounts anyway. |
| PendingMailboxClose | requested_at | The PDA seeds on the closing wallet, so that a wallet is closing its mailbox — and when the timelock lapses — is public. |
| PendingDeactivation | requested_at | Same shape, for a domain sitting in its deactivation notice window. |
| PendingReclaim | requested_at, authority, payer | A DNSSEC-proof reclaim in flight: the incoming authority wallet is public before the handover finalizes. The recorded payer — the wallet that funded the request, and the one its rent refunds to — is public too, and need not be the incoming authority. |
What a send leaks on-chain
SendMail writes the Email account above. Concretely, one send exposes: the
recipient wallet (the PDA seed), the sender wallet, a timestamp, the
blake3 hash of the from address (not the string), and the storage
locator (an IPFS CID, or a b3: marker when the recipient set no_ipfs). The
frombox instructions (CreateFrombox/UpdateFrombox/AddStamps) likewise carry
only blake3(from), never the plaintext address; the two purchase variants
additionally carry the buyer’s optional max_price_lamports ceiling, a figure
about the buyer’s own tolerance rather than about either identity.
ReclaimFromboxStamps carries no payload at all — the program recomputes the
hash from the signer’s address bytes. SOL amounts and
account balances are visible as on any Solana transaction.
Off-chain surfaces
“Off-chain” means not on the public ledger — it does not always mean private.
- The sealed body (private plaintext, public ciphertext). The body and
subject are sealed with crypto_box_seal to the
recipient’s wallet or delegated key, so the plaintext is private. By
default the ciphertext is pinned to public IPFS, where
anyone with the CID can fetch it (ciphertext only) — a harvest-now,
decrypt-later surface.
no_ipfskeeps it in the operator’s store instead. - The operator’s store. Your mail server holds the sealed body and, for IMAP / POP delivery, serves it to you. A curious or compromised operator can read whatever their store holds in whatever form it holds it.
- Mail credentials and account settings. Your IMAP/POP password, and the
account service’s session token, timezone, and do-not-disturb schedule, live
in the operator’s account store, not on-chain. The schedule is never served
to anonymous callers — they get only the yes/no “away right now” answer —
unless the owner opts in via
expose_dnd_schedule; see What the refused sender sees. - The relaying MX operator. Mail relayed through a domain’s mail server
passes through that operator, who sees the SMTP envelope and headers in the
clear and whose
fromclaim the chain trusts. This is a trusted role — see the domain authority is fully trusted for relayed mail.
See also
- What’s public and private — the plain-language overview.
- Trust assumptions and threat model — the adversarial view, including message metadata is hashed, not hidden.
- How sealed-box encryption works and How blake3 hashing works.
- Program & PDA reference — the full account layouts.