Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Addresses

In the Solana blockchain, an “address” is the public key portion of a cryptographic key pair.1 The public key is typically represented as a case-sensitive string about 45 characters in length .2

For example: 85FZrun1Eb5bdkbFCDjaFSTLnBfnx6sUFHa5BiYH2Q03.

Every SithBit client can create a key pair (also known as a “wallet”) for you: the getting-started wizard in your browser creates or imports one on its first step, and each of the GUI clients offers the same on first run.3

Once you create a keypair, the public key can serve duel purposes: it can be the source or target of cryptocurrency coin transfers, but can also act as an RFC822-compliant internet email address.

By default, a public key is not associated with an email domain until you create a mailbox for it — the getting-started wizard claims one in a single signed transaction, and every GUI client embeds the same wizard — or update its existing mailbox from the client’s Mailbox pane.4 Once you associate the public key with a domain, it becomes the case-sensitive “local” portion of the RFC822-compliant email address (i.e., the part of the address before the ‘@’ symbol, which separates the domain portion of the address).

For example: [email protected]

A domain is only required when email is routed through SMTP, but without a domain, emails can only be sent directly through the program, where both the “from” and “to” addresses are public keys without a domain portion of the email.

Trusting a “from” address

The “to” side of an email is always an on-chain wallet address, but the “from” side doesn’t have to be — it’s an arbitrary off-chain RFC822-compliant string (e.g. [email protected]), which raises the obvious question: what stops anyone from sending mail claiming to be any “from” address they like?

  • Only a recipient’s own domain authority can deliver into their mailbox. Every SendMail instruction requires the transaction signer to be the active, registered authority for the recipient’s (“to”) domain — the same wallet named in that domain’s on-chain MailDomain account. The comparison is part of the instruction itself, not an operator policy anyone can relax: a signer that doesn’t match is rejected (IllegalAuthority) and the whole transaction fails. This is not a check on the “from” domain — it’s what stops a stranger from injecting mail directly into someone else’s mailbox at all, regardless of what “from” address they claim.
  • Domain authority is DNS-gated, not self-asserted. A domain’s authority is set either by the postoffice’s delegate directly, or (self-service) by the domain-sithbit service after it verifies a _solana.authority.<domain> DNS TXT record matches the claimed key — see Create a domain. Controlling a domain on-chain requires controlling that domain’s DNS, the same trust root traditional email anti-spoofing (SPF5/DKIM6) relies on.
  • A domain-less from address must match the signer’s own wallet. If the recipient address has no @domain at all (a direct, unrouted on-chain send), the program instead requires the signer to be the exact address named in the “from” field — so a bare public-key “from” can only ever be sent by its own keypair. There is no relaying at all in this case.
  • One MX relay signs as one set of domains. The gRPC gateway that submits SendMail on behalf of an MX server signs every transaction with a single configured keypair, so a given mail server deployment can only deliver into mailboxes on the domain(s) it actually holds the authority key for — it can’t inject mail into a domain’s mailboxes that it doesn’t operate.
  • The “from” domain itself is not independently re-checked on-chain. Once a signer clears the checks above, the “from” string it submits is otherwise free-form (format-validated for length only). The chain trusts that the recipient’s own domain operator already verified the claim — which is exactly what SPF/DKIM/DMARC7 do, off-chain, before that trusted operator ever submits SendMail. An operator who has misconfigured that off-chain authentication — or turned it off entirely — is the actual point of failure for “from”-domain spoofing, not the on-chain program.
  • Postage adds economic friction on top. Every send burns a stamp from a frombox keyed on (from string, recipient wallet), priced by the recipient — see Economics. This doesn’t block spoofing by itself, but it means even a fabricated “from” string costs the actual sender lamports, at a price the recipient controls.
  • Inbound SMTP mail is checked with SPF/DKIM/DMARC before it ever reaches the chain pipeline — see Configuration for the operator settings that govern how strictly it is applied. This is the layer that actually authenticates a “from” domain’s claim; the chain only enforces who may deliver to a given recipient.
  • Casing can’t be used to dodge any of the above. Domain names are lowercased both when a MailDomain account is created and every time one is looked up. Each operation that touches a domain — the delivery authority check, plus creating, transferring, deactivating and closing a domain — lowercases the name independently, so there is no path that skips the normalization and no caller who can opt out of it. SithBit.Com and sithbit.com are therefore the same account, and there’s no shadow-domain trick via casing. A frombox’s “from” key is normalized the same way — the domain half of a domain-qualified address is lowercased — so pricing set for [email protected] also applies to [email protected]. Bare wallet addresses are deliberately left case-sensitive, since a base58 pubkey’s case is part of its identity, not a stylistic variation.

What’s not enforced on-chain is the authenticity of the “from” domain itself, and the local part under any authorized recipient domain: a domain’s authority can write any “from” string it likes for mail delivered to its own mailboxes, the same trust a real domain’s mail server holds for traditional email — the protocol’s guarantee is that only a recipient’s own trusted operator can deliver to them, not that every “from” claim has been independently re-verified.

Since public key addresses usually appear as long random strings that are hard to remember, it is also possible to create one or more friendly aliases for an address via the alias program — the getting-started wizard claims your first handle as part of onboarding.8 Aliases are globally-unique identifiers for public key addresses. Once created, they represent public keys across all domains.

Instead of using [email protected], you might create the alias myalias, and use [email protected] as your public email address.

Unlike public key addresses, aliases are case-insensitive. So [email protected], [email protected], and [email protected] are all aliases for the same public key address.

  1. A keypair (or “wallet”) in the Solana blockchain is specifically a public key and its associated private key derived from the ED 25519 eliptical curve. ↩

  2. The 32 bytes of the key are base58 encoded to produce the string. ↩

  3. Power users can also create one from the terminal with the SithBit CLI — see Creating a wallet. And since ED25519 key pairs are created by a publically well-known algorithm used by multiple blockchains, there are actually many tools that can create them — including the Solana CLI’s own solana-keygen, if you already have it installed. ↩

  4. From the terminal: Create a mailbox and Update a mailbox. ↩

  5. For the formal specification, see RFC 7208 (Sender Policy Framework); dmarc.org’s overview explains how SPF, DKIM, and DMARC work together in practice. ↩

  6. For the formal specification, see RFC 6376 (DomainKeys Identified Mail). ↩

  7. For the formal specification, see RFC 7489 (Domain-based Message Authentication, Reporting, and Conformance); dmarc.org also has practical deployment guidance. ↩

  8. Registering additional aliases (and transferring them) is CLI territory today — see Create an alias. ↩