Skip to main content

​
SAT Protocol Maintainer

The SAT protocol maintainer is operator tooling for protocol upkeep. Mining users still use the Mining page. Treasury custody stays separate from the hot maintainer payer. The maintainer submits transactions that make already-defined protocol state move forward:
  • refill registry reserve up to the configured target;
  • claim treasury SAT/SOL to fixed treasury recipients;
  • claim distributor SAT into the bond distributor;
  • quarantine zero-stake protocol rewards and unsolicited reward-vault transfers, then sweep only those amounts to the fixed treasury recipient;
  • clean up resolved accounts so rent returns to the expected owner/PDA;
  • record logs and monitor alert state.
The caller pays transaction fees. Program state fixes recipients and caps, so a caller cannot redirect treasury or distributor funds to themselves.

​
Scope

The maintainer is limited to bounded protocol maintenance:
  • reserve refill to configured caps;
  • fixed-recipient treasury and SAT distributor claims;
  • bond distributor feed;
  • cleanup/reclaim for resolved accounts;
  • monitor and standby records.
Mining users still use the Mining page for miner-owned work. Fased Network users still use the Bond card for their own bond claim.

​
Maintenance lanes

Registry reserve Source: protocol treasury SOL vault. Destination: sat_registry_reserve up to the configured target/cap. Treasury SAT/SOL Source: protocol pending lanes. Destination: configured treasury recipient. SAT distributor feed Source: protocol pending distributor SAT. Destination: bond distributor vault. The mining claim mints and records the exact reward in bond accounting in one transaction. If bond accounting fails, the mint and pending-lane debit roll back. Reward quarantine When protocol distributor SAT arrives while active stake is zero, the atomic claim records it as unallocated instead of advancing the staking index. Generic token transfers into the reward vault are also unallocated; the public sync instruction only detects and quarantines those unexpected balances. It never converts them into staker rewards. The maintainer then uses the permissionless bond instruction to move only quarantined whole-token amounts to the treasury recipient fixed by the active genesis profile. A later first staker cannot capture them, and the maintainer cannot redirect them. Cleanup/reclaim rent Source: resolved cycle/page/progress accounts. Destination: expected PDA/owner or reserve path. Cleanup is intentionally incremental. A maintainer pass can submit a small number of cleanup transactions, return deferred, and let the next pass continue from the same resolved backlog. This keeps one-shot maintenance calls inside the gateway timeout while still reclaiming old accounts over time. Maintainer responses are compact by default. The normal response reports the maintenance lanes, pending treasury/distributor amounts, registry reserve state, and cleanup backlog/defer reason. Full dashboard/debug status is available on request, but the loop should not pull it every pass. Program state fixes recipients and caps for all lanes. This is why the maintainer can be run by a hot payer without giving that payer treasury custody.

​
Why Solana needs a caller

Solana programs do not run on their own timer. Someone must submit a transaction that invokes the program. The clean model is:
Production deployments should run a monitored maintainer. The program should still keep maintenance calls bounded when submitted by any eligible caller.

​
Registry reserve

The registry reserve is a rent float for shared cycle/page/progress accounts. It is mostly locked SOL, not daily spent SOL. Cleanup returns rent when resolved accounts close. Recommended policy: Before launch, the monitor should report no reserve shortfall.

​
Running it

The exact unit names can differ by install channel, but the reference user-level service shape is:
Useful logs:
The maintainer should run with:
  • a dedicated payer wallet with enough SOL for transaction fees;
  • the same trusted RPC profile used for operator maintenance;
  • thresholds so it does not submit tiny claim/refill transactions every loop;
  • jitter/backoff so multiple operators do not collide constantly;
  • monitor state for freshness, failures, reserve, lanes, and cleanup backlog;
  • compact status mode for the regular loop and debug status mode only during investigations.
Configure write failover explicitly when two transaction-capable RPC providers are approved:
Fased signs once and may submit the exact same raw transaction bytes to the active endpoints. A read-only public fallback is never promoted implicitly to a write endpoint. Runner batch knobs:
Cleanup discovery has two modes:
  • recent: default. Use local backlog, recent actions, and observed cycle state first. This avoids asking RPC for every historical cycle account.
  • scan: explicit backfill/debug. This uses broad program-account scans and can get slower as devnet/mainnet history grows.
Cleanup batching is available as an opt-in soak path. Use --cleanup-batch-mode auto to let the maintainer combine multiple resolved miner-cycle or registry-page close instructions into one signed transaction, capped by --cleanup-max-batch-instructions. The local signer still validates the batch as a SAT cleanup operation. It rejects non-cleanup instructions, mixed wallet IDs, and batches above the signer cap. If the installed signer is older and does not support the batch operation, Fased falls back to single cleanup transactions.

​
Primary, standby, and monitor

Use three separate responsibilities: Primary Regular maintenance loop. Standby Periodic takeover attempt when primary is stopped or unhealthy. Monitor Read-only alert state for freshness, payer SOL, reserve, lanes, and cleanup. Expected behavior:
  • primary lock prevents double-running;
  • standby skips when primary is healthy;
  • standby can run a maintenance pass after primary stops;
  • primary can resume after standby takeover;
  • repeated calls do not double-claim, over-refill, or redirect funds.

​
Alert state

Launch alerting should cover:
  • no recent successful maintainer pass;
  • maintainer failure streak;
  • payer SOL below threshold;
  • registry reserve below target;
  • pending treasury or distributor lanes growing;
  • cleanup backlog growing;
  • RPC failure or rate-limit streak.
Alert delivery is operator-specific. The monitor state is not enough by itself unless someone actually receives and acts on the alert.

​
Evidence checklist

For a real launch drill, record:
  • primary maintainer pass log;
  • standby skip while primary is healthy;
  • standby pass after primary stop;
  • primary resume after standby;
  • reserve refill transaction or no-op proof when reserve is full;
  • treasury claim transaction or no-op proof when pending lanes are empty;
  • SAT distributor feed transaction or no-op proof;
  • atomic zero-stake quarantine proof, unexpected-vault sync proof, and fixed-treasury sweep transaction or no-op proof;
  • cleanup/reclaim transaction or no-op proof;
  • monitor alert state before and after the drill.

Mining

Miner-owned mining controls stay on the Mining page.

Mining troubleshooting

Diagnose skipped cycles, claim backlog, RPC errors, and low commit.

Bond + economy

Understand bond, distributor claims, and operator lanes.

Security test report

Review host, wallet, task, mining, and maintainer evidence status.