The Postmaster

The postmaster is a singleton on-chain account (the PostOffice) that administers the whole SithBit deployment: it authorizes and deactivates domains, sets the protocol’s per-stamp fee, and collects that fee’s revenue. There is exactly one postmaster per deployment, held by whichever wallet the network operator designates. (The postmaster is the only singleton: domains are many, and one authority key may hold several — see Create a domain.)

Note: almost everything in this topic is an operator/administrator action, not something an everyday mailbox owner does. If you’re just sending and receiving mail, you can skip this page — it’s here because understanding who administers your domain is part of understanding the system.

Checking status

Anyone can check the current protocol fee and the postmaster account without signing anything:

sithbit postoffice fee
sithbit postmaster get

Initializing the postoffice

sithbit postmaster init [--keypair <keypair>] [--skip-preflight]

Note: this is a one-time step run once per network deployment — right after the on-chain programs are first deployed — not something an end user or even a domain operator ever runs.

Transferring postmaster authority

sithbit postmaster transfer <new_address> \
  [--keypair <keypair>] \
  [--skip-preflight]

Hands the entire postoffice — and with it, the ability to authorize domains and collect protocol fees — to a new wallet. This is different from transferring a single domain, which only changes who administers one domain.

Withdrawing protocol fees

sithbit postmaster withdraw [destination] \
  [--keypair <keypair>] \
  [--skip-preflight]

Sweeps the postoffice’s accumulated fee revenue to destination (defaults to the postmaster’s own address).

Tuning the per-stamp protocol fee

sithbit postmaster set-stamp-fee <lamports> \
  [--keypair <keypair>] \
  [--skip-preflight]

See Economics for what this fee is and when it’s charged. The on-chain program enforces a hard cap on this value, so a compromised or malicious postmaster key can’t set it arbitrarily high — the CLI checks the same cap client-side and refuses to submit an over-limit value before spending a transaction on it.

Note: every postmaster subcommand is gated behind the CLI’s postmaster feature (enabled by default). A build with that feature disabled won’t have this command group at all.