Resolves the networks this deployment reads, at each use.
StaticinstanceThe process default: this stage's network (MINTFX_ENV) on the Helius client, read at each use.
Loader buffers authority can close, and the rent they are holding.
Listed by buffer authority rather than by deploy payer. The deploy payer the handoff calls for does not exist yet, and the buffers stranded today were written by the local deploy path, which signs with the upgrade authority — so passing a row's on-chain authority is what finds them. Once a dedicated payer exists, that is the address to pass instead.
Paginated, and not optionally: the owner here is the upgradeable loader,
which owns a loader account for every program on the cluster. The memcmp
filters narrow what comes back but not what the node scans, so the
single-shot V1 call ran the account index out of budget and Helius
answered -32603 instead of a list.
A pair's releases as GitHub lists them, newest first, unhashed.
A release belongs to the pair only if it carries the network's executable, since one release may ship one network alone. Assets still uploading are dropped first: the release job creates the release, then attaches files.
Every release for a pair, newest first, each with its executable's hash.
The hash comes from the .so asset rather than from the manifest, which
only the releases since 3d18c189 carry — a register keyed on it would
have no State column for anything older, including what mainnet runs.
Hashing the binary is the same measurement one step earlier in the chain of
custody. The manifest is read separately, for the one fact the binary
cannot give up: see SolanaProgramDeployQueryService.readDeployedAdminAuthority.
Optionallimit?: numberNewest N releases to hash and return. See DEFAULT_RELEASE_LIMIT.
The next limit accounts program owns that hold rent surplus, in address
order after after, and the cursor to resume from.
Surplus is lamports above the live rent-exempt minimum for the account's size. The rent line is probed uncached, unlike readRentParameters: surplus exists because rent constants get cut, so a day-old line would miss exactly what this is for. Accounts at or below their minimum are left out. Each page re-lists the program, so a page reflects current chain state.
The last address a previous page returned; null starts at the beginning.
What is deployed for a pair, or null when the program account does not
exist on that network.
Two round trips, and the second one is unavoidable: a Program account
holds only a pointer, so the executable and the authority both live in a
ProgramData account whose address it names.
The ADMIN_AUTHORITY the currently deployed program was compiled with.
Unlike the upgrade authority there is no account to read it from — it is a compiled-in constant — so it is resolved the way the register already resolves everything else about a deployment: hash the executable off chain, match that hash to the release it came from, and read the manifest that release was built with.
The answer is cached against (programId, lastDeploySlot), which is
immutable for what it describes, so a warm caller pays two account reads
and nothing else. The GitHub half — one listing plus up to 25 artifact
hashes — is only ever paid once per deploy, and shares
PROGRAM_HASH_CACHE_NAMESPACE with the register that already warms it.
Who pays for a deploy, what they can spend, and whether the platform holds the authority the upgrade will be signed by.
A separate read from readChainFacts rather than more fields on it, for the reason § 4.5 separates chain from GitHub: this one also depends on the database, so folding it in would let a wallet row nobody seeded blank the program id and the deployed hash — facts that resolved fine.
get rather than search: a missing wallet row is a deployment that was
never seeded, and the throw names which key is absent. search would hand
back an undefined address and send it to the node as a balance query.
What readChainFacts read, or null when it read none.
A cluster's rent line, in two probes.
The confirmation dialog states the buffer rent for every deployable
release it offers, which is up to 25 sizes on one render. Asking the node
for each would be 25 round trips to answer a question that has two
unknowns: rent exemption is affine in the data length, so rent(0) and
rent(1) pin the line and every size after that is arithmetic. See
RentParameters for why two points are exact rather than fitted.
Reads the deployed state of the mintfx program, and the releases it could be running.
Read-only by construction. It holds no signer and starts no workflow — the dashboard's entire write capability against these programs is a workflow start, and that workflow does not exist yet (PROGRAM_DEPLOYS.md § 2.4).
Chain reads and GitHub reads are separate methods rather than one combined call, because § 4.5 requires them to fail independently: GitHub being down must not blank the program ids and hashes that resolved fine.