mesa-upgrade — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited mesa-upgrade (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
The mesa-mut network is a fork of mainnet state used to rehearse the Mesa hardfork upgrade. It is a preflight network — it will be reset or retired without notice; treat all data as ephemeral. This runbook sits on top of the mina-mcp-server get_upgrade_status tool: that tool is the source of truth for where in the upgrade we are right now; this file is what to do about it.
Authoritative schedule: <https://mesa-upgrade-tracker.minaprotocol.com/status.json>.
Run get_upgrade_status (live mode, --network mesa-mut) before reasoning about the upgrade or submitting any transaction. Do not infer the phase from wall-clock time or stale docs — the tool joins the tracker with the live daemon slot, so its livePhase / transactionsOpen reflect the actual chain, not the schedule.
Key fields:
transactionsOpen — the gate for any send. true → sends are accepted;false → sends are dropped, do not submit.
currentSlot — live global slot (this chain's genesis).stopTransactionSlot / stopNetworkSlot — thresholds from the tracker.slotsUntilStopTransaction / slotsUntilStopNetwork — remaining headroom.livePhase — the derived phase (below).mesaGenesisTimestamp — when the post-fork chain starts.hints[] — human-readable, already phrased for the current phase.livePhase | Meaning | Do | Don't |
|---|---|---|---|
pre-upgrade (transactions open) | currentSlot < stopTransactionSlot | Normal operation. If submitting a send, confirm slotsUntilStopTransaction leaves comfortable margin (each slot ≈ 3 min). | Don't start a multi-step flow you can't finish before stopTransactionSlot. |
transactions stopped (awaiting network halt) | stopTransactionSlot ≤ currentSlot < stopNetworkSlot | Read-only queries only. Tell the user transactions are frozen until the fork. | Don't submit sends — they are dropped. Don't retry "stuck" transactions. |
network halted (awaiting Mesa genesis) | currentSlot ≥ stopNetworkSlot | Wait for mesaGenesisTimestamp. After genesis, treat mesa-mut as a new chain. | Don't trust pre-fork mempool/tip as current. |
Once mesaGenesisTimestamp passes, the post-fork chain is a fresh genesis:
get_genesis_constants — constants may differ from the pre-fork chain.get_sync_status / describe_state before acting on chain state.get_upgrade_status still returns the live slot and ahint saying so; you lose the threshold context. Don't guess the phase; surface that the schedule couldn't be fetched and point the user at the tracker URL.
the planned thresholds but not whether transactions are open right now; treat transactionsOpen: null as "unknown — do not submit".
mesa-mut endpoints, slot thresholds, and the genesis timestamp all live in the tracker and the daemon — never hardcode them into automation. Call the tool each time; the network is preflight and the schedule can move.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.