Glossary

A single-page reference for the vocabulary the rest of these docs assume: Solana account mechanics, the SithBit postage economics, the sealed-box crypto, the self-hosted IPFS node, the mail protocols, the pluggable storage backends, and the operational surface. Where a term has a chapter or appendix of its own, the entry here is a one-liner that points at it; where a word is overloaded (SithBit reuses seal, authority, remote, and provider for several distinct things), each meaning gets its own disambiguated entry.

Solana & on-chain

PDA (Program Derived Address)

A deterministic account address a program owns, derived by hashing a set of seeds together with the program ID. SithBit’s mailboxes, fromboxes, message accounts, the postoffice, and domains are all PDAs — see the Program & PDA reference for the exact seeds.

Rent / rent-exemption

The refundable one-time SOL deposit every Solana account must hold to exist, sized to the account’s byte length rather than to any value it represents. It is returned in full when the account is closed — see Closing accounts.

Lamport

The smallest unit of SOL: one lamport is 1e-9 (one-billionth) SOL. Every price, fee, and balance in the protocol is denominated in lamports.

Basis points (bps)

One basis point is 1/100th of a percent; 10 000 bps is 100%. The domain operator’s cut is OPERATOR_SHARE_BPS = 1 000 bps (10% of postage).

Cross-Program Invocation (CPI)

One on-chain program calling another within the same transaction — Solana’s mechanism for composing programs.

SithBit’s three programs never CPI into each other. Their only CPIs target the System program, for creating accounts and for moving wallet lamports — e.g. the alias claim fee is a System transfer from the payer’s wallet into the mail program’s postoffice account. Cross-program coupling is read-only instead (the alias and domain programs read the postoffice and domain accounts the mail program owns, without invoking it), and settlement between program-owned accounts is direct lamport arithmetic with no CPI at all.

Upgrade authority

The keypair allowed to redeploy new bytecode to a program’s fixed ID. Who holds it, and the freeze/multisig/DAO trajectory, is covered in Program upgrade authority.

BPFLoaderUpgradeable

Solana’s upgradeable-program loader (a fixed, well-known program) under which the three SithBit programs are deployed: the program ID is permanent, but the holder of the upgrade authority can replace the bytecode behind it.

Off-curve address

A 32-byte address that is not a valid Ed25519 point — a PDA is the canonical example. It has no private key, so no X25519 conversion exists for it and it can never receive sealed mail; a send to one settles into the no_key chain state.

Authority (three kinds)

SithBit uses “authority” for several distinct powers, and they are held separately in a serious deployment: the domain authority (an MX operator’s wallet, per domain), the upgrade authority (the key that can rewrite program bytecode), the delegate (the hot operational admin wallet), and the postmaster (the hidden ceremony-committed owner). Compromising each is severe in a different way.

surfpool

The local Solana test validator the integration suite and the dev/chain profile target on 127.0.0.1:8899; the test harness boots one, deploys the three programs, and seeds fixture state.

SithBit protocol & economics

Stamp

Prepaid postage for one email from one sender (“from” address) to one recipient wallet; sending decrements the count. Its full lifecycle and pricing is in Economics.

Postage

The per-message price the recipient sets. A frombox’s required_postage defaults from the recipient mailbox’s default_postage, and only the recipient may change it — see Economics.

Frombox

A recipient-owned prepaid-stamp account, one per (sender “from” address, recipient “to” wallet) pair, holding the bought stamps and the price for that sender — see Fromboxes.

Mailbox

The 1:1 account for a wallet address, holding its domain, encryption key, and default stamp price — see Mailboxes.

PostOffice

The singleton admin account: it records the standing delegate, the ownership commitment root, and the tunable fee values, and collects the protocol’s fee revenue — see Economics.

Delegate

The postoffice’s standing operational admin wallet: it authorizes and deactivates domains, tunes the capped fees, publishes the root KSK, and gets the bulk-alias fee waiver. A hot key by design, revocable by an ownership-signed delegate — see The Postmaster.

Postmaster

The postoffice’s owner — not a pubkey on-chain, but a Merkle commitment root over a hidden key set from an offline key ceremony. Ownership operations (revenue sweep, delegate rotation, ownership handover) reveal one committed key with a membership proof and rotate the whole set. Custody guidance is in Postmaster key custody.

Deactivation timelock

The two-step, 7-day delay the delegate must pass through to deactivate a domain: request starts the clock (domain stays active), finalize takes effect only after it elapses, and cancel aborts it meanwhile. Reactivation stays instant. A hardening measure against a compromised delegate — see Deactivate a domain.

Mailbox close timelock

The two-step, 7-day delay a mailbox owner must pass through to close their mailbox: request starts the clock (mailbox stays open and keeps receiving mail, and no rent is refunded), finalize closes it and refunds both rents only after the clock elapses, and cancel aborts it meanwhile. The mailbox-key close stays instant. A separately tunable setting from the deactivation timelock above, aimed at a different abuse: free identity-cycling by spammers — see Close a mailbox.

Domain authority

The wallet registered as a domain’s operator. It is the only signer that can relay SendMail into that domain (inbound MX mail), and it earns the operator share on every settled message for its mailboxes.

Sender attestation

An on-chain record, minted by DNSSEC proof for a one-time fee, in which a DNS domain vouches for a wallet as its legitimate sender — the protocol’s verifiable trust mark for organizational senders. It confers no serving rights, and the attested wallet may revoke it at any time — see Verified-sender attestation.

Operator share

OPERATOR_SHARE_BPS = 10% of a message’s postage, paid to the recipient’s domain authority when the message settles via DeleteMail. It is waived on a RefundMail — a refund is not a revenue event.

Settlement

Splitting a parked message account’s balance to its participants. DeleteMail settles to the recipient (rent back to the sender, the operator share to the domain authority, the postage to the recipient); the auto-settle sweeper does it in the background.

Auto-settle sweeper

The [spooler.settle] background worker: an hourly scan that fires DeleteMail after_days (default 30) past confirmed delivery, reclaiming the on-chain stamp value while keeping the local IMAP/POP copy. On by default; it also unpins the sealed IPFS body unless keep_pin = true — or unless the CID carries a live pinning lease.

Pinning lease

A per-(CID, holder) on-chain account (sithbit mail lease) escrowing a reclaimable deposit that asks operators to keep a mail body pinned past the default retention. Its existence is the lease: no expiry, no renewal fee; closing it returns deposit and rent. The one-time creation fee splits with the recipient’s domain authority at the operator share.

Alias

A globally-unique, case-insensitive human-readable name that resolves to a wallet address, cross-domain and lowercased/domain-stripped at creation — see Aliases.

Stamp fee surcharge

STAMP_FEE_SURCHARGE_LAMPORTS = 10 000 (2 × the 5 000-lamport base fee), a per-stamp add-on paid at purchase that prefunds the two settlement signature refunds (SendMail and DeleteMail).

Per-stamp protocol fee

A flat postoffice fee (default POSTOFFICE_STAMP_FEE_LAMPORTS = 100 000) charged per stamp on third-party purchases and transferred straight to the postoffice; waived when the fee payer is the recipient wallet itself.

Cryptography

Sealed box (crypto_box_seal)

libsodium’s anonymous public-key encryption to a recipient’s key alone — no sender keypair involved. SithBit seals every mail body this way; the full walkthrough is in How sealed-box encryption works.

X25519

The Curve25519 key-exchange form sealed boxes use. A wallet’s Ed25519 key is converted to it on the fly, or a signing-only wallet publishes a delegated key — see How sealed-box encryption works.

Ed25519

The signature curve a Solana wallet address is a public key on. It is one-way convertible to X25519 for encryption — see How sealed-box encryption works.

Delegated key

A self-generated X25519 public key a signing-only wallet (hardware/browser) publishes on-chain so MX servers seal to it instead of converting the wallet key — see Mailbox Keys.

blake3

The fast hash SithBit uses wherever it needs a fixed-size fingerprint in place of a raw value: the frombox’s “from” address, the alias name and the claimed domain (all PDA seeds), the bountied message a reply names, and the postoffice commitment set’s Merkle leaves. See How blake3 hashing works and the Program & PDA reference.

Seal (two meanings)

For mail, sealed means encrypted so that only you can read it, with your key: the crypto_box sealed box locks a message body to the recipient’s wallet (or published reading key) and to nothing else.

That mail sense covers both sealing at send time (bodies sealed to the recipient before they are ever stored or pinned) and at-rest sealing (delivered copies sealed to the account’s reading key in the operator’s store). An unrelated second use shares the word: the credential seal key (credential.key) that encrypts stored mail passwords at rest in the store — a symmetric key that must be identical on every replica and is unrecoverable if lost, so back it up first (see Monitoring and backups).

At rest (at-rest sealing)

“At rest” means stored on the mail server’s disk — the copy of your mail the operator keeps between delivering it and your client fetching it, as opposed to mail in transit on the network. At-rest sealing seals each delivered body to the account’s reading key, so the operator’s storage holds only ciphertext.

Automatic for password-less accounts on chain-connected deployments; what it does and does not protect against is covered in What your operator holds.

Reading key

The key that decrypts a password-less account’s at-rest-sealed mail: the wallet keypair itself, or the delegated X25519 key a signing-only wallet publishes. The account API’s “log in again with your reading key” refusal means the session never supplied it — the reading secret travels only at login and is held in memory just for that session.

Related: Seal (two meanings), Sealed box, and What your operator holds.

IPFS & the self-hosted node

IPFS

The content-addressed, decentralized store SithBit pins encrypted mail bodies to instead of holding them on-chain or on one provider’s servers — see IPFS storage: benefits to users.

CID

A content identifier: a hash-derived address, so the same bytes always yield the same CID and any change alters it (a built-in tamper check). The on-chain message envelope stores the body’s CID. For a plain-language explanation aimed at non-technical readers, see What is a CID?; for the wider storage rationale, IPFS storage: benefits.

Pin / unpin

To pin a CID is to retain its blocks against garbage collection; to unpin is to release them. Settlement unpins the sealed body by default (keep_pin = false).

bitswap

IPFS’s block-exchange protocol. A SithBit node serves its pinned blocks over bitswap (/ipfs/bitswap/1.2.0) to any peer that asks, but never fetches foreign CIDs — serving is one-way.

DHT (Kademlia)

The Kademlia distributed hash table IPFS uses as its content/peer index. With the swarm running, a node learns peers via identify and can announce the roots it holds.

Provider record / provide / reprovide

A provider record is the DHT announcement that a node holds a given root CID; provide ([swarm] provide = true) publishes them; the reprovide sweep periodically re-announces (every reprovide_interval_secs, default 22 h) so stock Kubo peers can still discover the node as the content’s provider.

UnixFS import profile

The fixed importer parameters (CIDv1, sha2-256, raw leaves, 256 KiB balanced dag-pb) that make SithBit’s CIDs byte-identical to Kubo’s for the same bytes.

multiaddr

A self-describing network address naming transport and port, e.g. /ip4/0.0.0.0/tcp/4001 or /ip4/0.0.0.0/udp/4001/quic-v1; swarm listen and bootstrap addresses are multiaddrs.

PeerId

The stable libp2p identity derived from the node’s ed25519 key. Persist the identity_file, or the PeerId — and every provider record naming it — goes stale on each restart.

libp2p / swarm

libp2p is the peer-to-peer networking stack; the swarm is the running instance that joins the IPFS network (identify + DHT + bitswap). Omit [ipfs.swarm] and no swarm runs.

Kubo

The reference Go implementation of IPFS. SithBit’s embedded node stays byte-compatible with it (same CIDs, same protocols) so stock Kubo peers interoperate.

CAR (Content Addressable aRchive)

A trustlessly-verifiable bundle of IPFS blocks. The path gateway can emit one with ?format=car so a client verifies the content itself rather than trusting the server.

Path gateway

A read-only HTTP surface — GET /ipfs/{cid} — that lets non-IPFS clients fetch content over plain HTTP. SithBit’s sithbit-gateway serves only local content and never fetches foreign CIDs.

Shared-bucket cluster

The IPFS scaling model: N stateless nodes point at one S3/Azure bucket and coordinate purely through membership heartbeats written into that bucket — no gossip, no bootstrap list, no consensus. See Scaling out.

Rendezvous hashing

The assignment that gives each root’s reprovide to exactly one live cluster member; when membership changes, the survivors resweep and take over a dead node’s share.

remote (two meanings)

Two unrelated “remotes”. (1) [ipfs] kind = "remote" delegates pinning to a shared sithbit-ipfsd daemon instead of embedding a node. (2) A Turso embedded replica’s remote primary is the libSQL server it syncs from. Different subsystems, different config.

Provider (three meanings)

(1) An IPFS pinning provider — Filebase, Pinata, or the embedded node — where sealed bodies are stored. (2) A DHT provider record, the announcement that a node holds a CID. (3) A generic hosting/cloud provider (AWS, Azure, Cloudflare). Read which from context.

Node-delegation cert

A short-lived, authority-signed binding of a per-node key to a {domain, proto, expiry} tuple (NodeDelegation → SignedDelegation in the node_cert crate). It lets a POP/IMAP node prove the domain’s on-chain authority blessed this key to serve this protocol, without the root authority key ever touching the node — the trust chain is on-chain MailDomain.authority → delegation → node key. Self-delivered (in a service record or a self-auth TLS cert), never registered on-chain; revocation is expiry/rotation. See Decentralized service discovery.

Service record

A node’s signed advertisement of the endpoints it serves for one (domain, proto), published on the Kademlia DHT under hash("sithbit/service-record/v1" ‖ domain ‖ proto) — a keyspace separate from provider records. Carries the node’s delegation and is validated on get (node signature, delegation consistency, expiry, and a short advertise TTL). Kept fresh by a minutes-scale TTL + heartbeat republish (service_record_ttl_secs / service_heartbeat_interval_secs). Discovered with sithbit discover — see Decentralized service discovery.

Mail protocols (SMTP/IMAP/POP)

RFC

A Request for Comments: a numbered specification published by the IETF’s RFC Editor, the canonical form in which internet protocols like SMTP, IMAP, and POP are defined. When SithBit documentation cites “RFC 5321”, it means the published standard every interoperating mail server is expected to honor — Standards and RFC coverage enumerates the ones SithBit implements.

Sans-io

A protocol-implementation style in which the code that speaks the protocol never touches the network: a pure state machine consumes bytes and events and emits actions, while a thin driver owns the sockets, TLS, and timeouts. SithBit’s SMTP, IMAP, and POP cores (smtp_session, imap_session, pop3_proto) are all sans-io, which is what lets every protocol conversation be tested as a script with no connection open.

MX

The DNS mail-exchanger record that tells other servers where to deliver a domain’s mail — and, on the server, the inbound SMTP listener (port 25) that accepts it.

Submission vs MX

Two SMTP roles: submission (port 587, authenticated outbound from a user’s own client) versus MX (port 25, inbound from other mail servers). SithBit runs them as separate listeners with different policies.

STARTTLS / STLS / implicit TLS

Two ways to get TLS: STARTTLS (SMTP/IMAP) and STLS (POP) upgrade a plaintext connection in place, while implicit TLS wraps the socket in TLS at connect (implicit_tls = true).

SASL

The authentication framework the servers speak; SithBit supports the PLAIN, LOGIN, CRAM-MD5, and APOP mechanisms.

IDLE

The IMAP command that pushes new-mail notifications to a client. Delivery push is in-process; a split-deployment instance that didn’t do the delivering only learns of new mail by polling every watch_poll_seconds.

MailboxNotify / await_change

The cross-process seam (MailRepo::await_change) that lets an IDLE client on one node learn of mail delivered on another node — the piece that makes discovered-node failover safe. Its default is poll-backed over the mailbox’s change_seq (the DEFAULT_WATCH_POLL interval, 2 s), so it works on every backend including SQLite; native per-backend push (Postgres LISTEN/NOTIFY, DynamoDB Streams) is a deferred drop-in behind the same seam. Only meaningful over a shared cloud store — SQLite is single-node by design. See Decentralized service discovery.

Expunge

The IMAP client action that permanently removes deleted messages. On SithBit it triggers the on-chain teardown (chain_delete job) and releases the IPFS pin.

Maildrop

POP3’s single-spool view of a mailbox. Exclusive access is guarded by a self-expiring store keyed lease (pop/{wallet}) so a crashed session cannot wedge it.

DSN

A Delivery Status Notification (RFC 3464) — the bounce or delay report the spooler generates when outbound mail fails or is retried.

Relay / spooler

The relay worker forwards outbound mail to remote MX servers; the spooler is the worker tier that drives the whole chain → relay → DSN pipeline. Both run inside sithbitd.

Smarthost

A fixed, authenticated relay ([spooler.smarthost]) that all outbound mail is routed through instead of MX resolution — the workaround when port 25 is blocked.

EHLO

The SMTP greeting in which a server or client identifies itself by hostname. Set it to match your DNS/PTR (hostname), or many receivers score the mismatch as spam.

sender_auth

The MX setting choosing inbound from-domain checks: "spf" (reject on hardfail, the default), "dmarc-lite" (DMARC alignment, reject only on p=reject), or "none".

SPF

A DNS TXT record listing which hosts are allowed to send mail for a domain; receivers check it against the connecting IP.

DKIM

A cryptographic signature over outgoing mail, verified against a public key in DNS. sithbitd signs authenticated submissions (rsa-sha256, RFC 6376) when [spooler.dkim] is configured.

DMARC

The policy that ties SPF/DKIM results to the visible from domain and tells receivers what to do on failure. dmarc-lite mode rejects only when the sender publishes p=reject; the full dmarc mode evaluates the domain’s entire published policy (p=reject bounces, p=quarantine files into Junk, honoring pct) and can emit both RFC 7489 aggregate (rua) reports and per-failure forensic (ruf) reports back to sending domains — the latter headers-only by default (RFC 7489 §7.3), full-message on explicit opt-in, gated by the §7.1 external-destination check.

PTR / reverse DNS

The DNS record mapping an IP back to a hostname. Several large receivers refuse mail from an outbound IP whose PTR doesn’t match the EHLO name; it is set with the hosting provider, not in your zone.

DNSBL

A DNS blocklist queried by the connecting peer’s IP (e.g. zen.spamhaus.org, configured as dnsbl_zone) to reject known-bad senders at connect.

DBL

A domain block list — the DNSBL’s domain-keyed sibling. Where a DNSBL scores the connecting IP, a DBL scores the sender domain; the SMTP server queries it at EHLO and MAIL FROM and refuses a listed domain with 554 5.7.1. Configured as dbl_zone, the value being the full Spamhaus DBL zone — the current DQS form <key>.dbl.dq.spamhaus.net (a free per-customer Data Query Service key) rather than the deprecated public dbl.spamhaus.org, which is blocked from the large public resolvers.

PROXY protocol

A preamble a load balancer prepends to carry the real client IP through to the listener. Enable it (proxy_protocol = true) only behind an L4 balancer — never on a directly reachable listener, where the preamble is trivially spoofable.

MAILER-DAEMON / Reporting-MTA

The identities the spooler stamps on generated bounces and DSNs: the null-sender MAILER-DAEMON envelope and the Reporting-MTA header naming the reporting host (both derived from the spooler hostname).

Storage backends & durable queues

Store backend

The swappable layer behind the four repo traits (accounts, mail, job queue, keyed lease); [store] kind selects sqlite, postgres, aws, azure, turso, or cloudflare. See Scaling out.

Embedded replica

A Turso/libSQL local file that syncs to a remote primary. Reads hit the local file and lag the primary by up to sync_interval_secs, so it scales like SQLite (one writer), not like a shared store — see Scaling out.

libSQL

The SQLite fork Turso builds on; the turso backend is a local libSQL file, optionally an embedded replica.

Multi-statement transaction

A single atomic transaction spanning several SQL statements. Cloudflare D1’s HTTP query API lacks it, so anything counter-critical on D1 is a single atomic statement instead (uid allocation is an UPDATE … RETURNING, lease acquisition a one-statement CAS upsert) — since 2026-07-19 this is no longer a reason D1 needs a single writer.

Single writer / one-writer daemon

On stores without cross-daemon atomic counter allocation (sqlite/turso), only one daemon may allocate IMAP uids and deliver mail; the read frontends still scale freely. (cloudflare graduated out of this list 2026-07-19 — its uid allocation is server-side atomic.) See Scaling out.

Job queue

A durable work queue for background work (chain, relay, DSN, delete). Delivery is at-least-once with a visibility timeout: a claimed job is hidden while a worker holds it and retried if the worker dies, so every handler tolerates duplicates. See Monitoring.

Claim token / receipt handle

The identifier for a temporarily-claimed queue entry, distinct from the job’s own identity — the same idea as an SQS receipt handle. Requeue or discard a dead job within its claim window before the token lapses.

Dead-letter / buried job

A job that has failed too many times is buried to a dead-letter queue with a reason, for later inspection and requeue or discard — see Monitoring.

Keyed lease

A store-backed mutex keyed on a string — e.g. send/{wallet} to serialize a mailbox’s SendMail, or pop/{wallet} for maildrop exclusivity. Atomic on every backend: SQLite/Turso/Cloudflare share one single-statement CAS upsert (Cloudflare runs it on D1’s leases table), Postgres row-locks, Dynamo conditional-puts, Azure ETag-CASes.

Reconciler

The idempotent sweep that re-enqueues chain jobs for copies stuck in a non-terminal chain_state past a 15-minute horizon; duplicate re-enqueues are absorbed by the chain worker’s state guards.

chain_state

The per-copy progress field in messages.chain_state: local, received, pinned, sent, no_key, or chain_failed. received is the resting state when the chain pipeline is disabled — see Monitoring.

Cloudflare D1 / Workers KV / R2 / Queues

The Cloudflare edge services that back the cloudflare store: D1 (SQLite-over-HTTP) for accounts + mail + keyed leases, Cloudflare Queues for the job queue, and R2 (S3-compatible) for blobs. Workers KV formerly held the leases; it was retired 2026-07-19 (no CAS, so its leases were only best-effort) and the kv_namespace_id config key is now accepted but ignored.

Durable Object

Cloudflare’s single-threaded stateful primitive. It was once pencilled in as the route to strict uid allocation and strictly-atomic leases on Cloudflare; superseded 2026-07-19 by plain atomic D1 statements (UPDATE … RETURNING allocation, one-statement lease CAS), which need no Worker-side code at all.

Compare-and-swap (CAS)

An atomic conditional write (write only if the value is unchanged). Workers KV lacks it — the reason the retired KV lease was only best-effort; the D1 lease does it in one SQL statement.

Blob store

The object storage holding mail bodies — local, s3 (which also covers GCS), Azure Blob, or R2 — orthogonal to the tables/queues/leases backend and selected by [store.blobs] (or R2’s own section on Cloudflare).

GCS (Google Cloud Storage)

Google Cloud’s object storage. SithBit needs no GCS-specific code: the service speaks the S3 XML API on an interoperability endpoint (https://storage.googleapis.com) against HMAC credentials, so a GCS bucket is just the s3 blob store with that endpoint and region = "auto" — see Hosting on Google Cloud.

minio

An S3-compatible object storage server that is easy to self-host. SithBit’s docker demos and the store conformance tests run it as the shared S3 bucket the blob store and the shared-bucket cluster nodes point at — standing in for AWS S3 or Cloudflare R2 in local development, with no cloud account required. See min.io.

Operations & infrastructure

sithbit CLI

The command-line client (and library) these docs use throughout to build, sign, and submit every on-chain instruction — wallets, mailboxes, fromboxes, aliases, and domains all go through it. Built from the sithbit-solana repository; see CLI Quickstart for install and first use. A separate tool from the Solana CLI, which sithbit config and sithbit wallet create fully substitute for in this workflow.

OTLP / observability

OpenTelemetry push of traces and metrics over OTLP/gRPC. It is off unless the [observability.otlp] config section is present — see Monitoring.

Health probe (healthz / readyz)

Every binary serves GET /healthz (liveness) and GET /readyz (readiness) on a loopback health listener, plus a --health-probe flag that GETs its own /readyz and exits 0/1 — how the shell-less distroless images healthcheck. See Monitoring.

distroless

A minimal container base with no shell and no curl. Debug it with docker logs/docker cp and the --health-probe flag, not docker exec.

RUST_LOG / tracing

The target=level filter (e.g. info,mail_spooler=debug,sqlx=warn) that shapes the structured tracing logs on stdout and what the OTLP export sends — a silenced target is also not exported.

Multisig (N-of-M)

An on-chain vault that requires N of M signers to approve a transaction. It is the recommended custody for the upgrade authority; postoffice ownership has its own split-custody scheme, the key ceremony.

Zero-config default

The contract that an empty or missing config file yields a runnable loopback dev instance: SQLite store, dev ports, and the chain pipeline off (delivered copies rest in received). See the configuration reference.

The _solana.authority TXT record

The DNS proof tying a domain to its claimed authority key: the domain owner publishes their base58 ed25519 public key at _solana.authority.<domain>, which domain-sithbit verifies before the delegate authorizes the domain on-chain. See DNS setup.

base58

The text encoding Solana uses for wallet addresses, keys, and signatures (and the delegated encryption key published on-chain).

RPC endpoint / JSON-RPC

The Solana JSON-RPC node the CLI, gateway, and account API talk to a cluster through; resolved from the Solana CLI config or a JSON_RPC_URL override. Solana clusters and RPC endpoints covers the public clusters and their URLs.

JWT (JSON Web Token)

The signed bearer token the account API issues on a successful wallet-challenge login. It carries the caller’s wallet identity, is presented on every authenticated /v1/... route (the account, mail, and chain surfaces), and expires. The API signs it with the jwt.key_file key source, which auto-generates a local key when none is present.

QUIC

A UDP-based transport libp2p can listen on for the IPFS swarm, alongside TCP — e.g. /ip4/0.0.0.0/udp/4001/quic-v1.