Program upgrade authority

SithBit’s pitch is that there is no token, no mint anyone controls, and nothing to “rug”. That claim rests on the on-chain programs behaving exactly as documented — postage settles directly to recipients, the fee is capped, rent returns to its payer. But a program on Solana is only as fixed as its upgrade authority lets it be. This page states, honestly, who holds that authority today and where it is meant to go, so a reader evaluating trust knows precisely what they are trusting.

It is a companion to the postmaster key custody runbook: that page covers the keys that administer the network; this one covers the key that can rewrite it.

What the upgrade authority is

The three SithBit programs are deployed as upgradeable programs under Solana’s BPFLoaderUpgradeable — the default for solana program deploy:

• mail_program — MaiLyqjRuHp8SSQHjiLMPmhBcuLitSta4YdoTiibXu4
• alias_program — ALiasg6qDnwcY8HfyeC1AjXRFjyqpXxW4omtwF1i125q
• domain_program — DmaiNcmXsPw2juV9JoZSC47V5epAysQi3DJVk3fiBuUv

An upgradeable program has a designated upgrade-authority keypair. The program ID is permanent, but whoever holds that key can deploy new bytecode to the same ID — silently, in a single transaction, with no notice to users and no on-chain vote. The address stays the same; the rules behind it change.

This is the sharpest trust question in the whole system, and it sits above everything the rest of these docs describe. The threat model enumerates what a compromised delegate key can do within the current rules; the upgrade authority can change the rules themselves. It could, in principle, deploy a version that removes the fee cap, redirects postage, disables a close path, or weakens the PDA checks that gate every lamport move. None of the on-chain guarantees documented elsewhere survive a malicious upgrade — they are guarantees of this bytecode, and the upgrade authority decides which bytecode is this bytecode.

Two things bound that power, and both are worth stating plainly:

• It cannot touch keys or sealed mail. The upgrade authority signs bytecode, not user transactions. It cannot spend a wallet’s SOL, forge a wallet signature, or decrypt a sealed body — those depend on private keys the program never holds. Its reach is the protocol rules, not user custody.
• An upgrade is public after the fact. Bytecode is on-chain and verifiable; a changed program hash is observable, and reproducible builds let anyone confirm the deployed bytecode matches this source. The authority can act without warning, but it cannot act invisibly.

The current posture

Be clear-eyed about today: the upgrade authority is an operator-held key. On a fresh deployment it is whichever keypair ran solana program deploy, held wherever the operator keeps it. There is no DAO, no governance program, and no on-chain vote gating an upgrade today — this document describes the honest current state and the intended trajectory, not a governance structure that already exists.

The upgrade authority and the postoffice admin keys are distinct powers, and a serious deployment custodies them separately (see below). On a single-operator pilot they may in practice be the same person’s keys; that is a custody choice, not a protocol requirement.

Which key holds the authority is not something this repository can pin down for a given live network — it is set at deploy time and can be transferred. A reader assessing a specific deployment should verify it directly against the chain:

solana program show MaiLyqjRuHp8SSQHjiLMPmhBcuLitSta4YdoTiibXu4
solana program show ALiasg6qDnwcY8HfyeC1AjXRFjyqpXxW4omtwF1i125q
solana program show DmaiNcmXsPw2juV9JoZSC47V5epAysQi3DJVk3fiBuUv

The Authority field is the current upgrade authority; the field reading none (immutable) is what a frozen program shows. Trust the chain, not a doc’s claim about who holds a key.

The freeze / DAO trajectory

An upgradeable program’s authority can go three directions, each a different point on the trustlessness-vs-maintainability trade-off:

• (a) Transfer to a multisig. Move the authority to a Squads-style vault so no single key can push an upgrade — N-of-M signers must approve. Upgrades remain possible (bugs can be fixed), but require collusion or compromise of a threshold of independent signers rather than one machine. This is the same split-custody instinct the postmaster’s key ceremony encodes, applied to a different power.
• (b) Transfer to a DAO / governance program. Hand the authority to an on-chain governance program so upgrades pass a token- or member-vote and a timelock. Maximally legible — every rule change is proposed, delayed, and voted in public — but it introduces a governance surface and, if a vote token exists, the very “token someone controls” that SithBit’s no-token pitch avoids. SithBit has no token, so a DAO here would be a membership/multisig governance program, not a token vote.
• (c) Set the authority to None — freeze. Make the program immutable (solana program set-upgrade-authority --final, or deploy --final). The bytecode can never change again by anyone. This is maximal trustlessness: the rules are fixed forever and no key, multisig, or vote can alter them. The cost is symmetric — there is no bug-fix path. A latent vulnerability in a frozen program can only be worked around by deploying a new program at a new ID and migrating, which is a hard fork of the network’s state.

How this qualifies “nothing to rug”

The no-token claim is about economics — there is no insider allocation to dump and no mint to inflate — and that part is true regardless of the upgrade authority. But “the rules can’t change on you” is a separate claim, and it is only as strong as the upgrade authority is constrained:

• Under freeze (c), the claim is strongest: the code you audited is the code that runs, permanently.
• Under a multisig (a) or DAO (b), it is qualified: the rules can change, but only through a process you can inspect and whose signers or voters you can weigh.
• While a single hot upgrade key exists (today’s default), it is weakest: one key can change the rules at any time. That does not make the economics a rug — there is still no token to dump — but it means the protocol’s behavior ultimately rests on trusting the authority holder not to deploy hostile bytecode.

SithBit’s intended direction is to constrain the upgrade authority as a deployment matures — a multisig at minimum, and freeze as the honest end-state for a protocol that markets immutability. Whether a given network has taken that step is, again, a solana program show away; do not take a doc’s word for it.

Open question for a specific deployment: whether SithBit’s canonical network intends to freeze the programs (immutable, no bug-fix path) or hold the authority in a multisig/DAO (upgradeable, trust the signers) is a governance decision, not a protocol fact this repository can settle. Evaluate the live authority, not this page’s aspiration.

Relationship to postmaster custody

The upgrade authority and the postoffice admin keys are different powers, and compromising any of them is severe in a different way (the postoffice side is itself split — a hot operational delegate and a hidden ceremony-committed owner, see The Postmaster):

Because they are distinct, a serious deployment should custody them separately — different keys and different custodians — so that one compromise is not all. A single operator holding one keypair for everything collapses that separation and should be treated as a pilot-only posture. The postmaster custody runbook covers the seed vaults and the delegate’s rotation cadence; the same discipline applies to the upgrade authority, with freeze as an additional option the postoffice roles do not have (you cannot make the postoffice “immutable” — the network must always be administrable).

See also

• Postmaster key custody — custody of the administering keys.
• Trust assumptions and threat model — where these powers sit among the network’s trust boundaries.
• Running a mail server — the solana program deploy step that sets the initial upgrade authority.