Open source · for the people an upgrade affects

Open-source tooling for Stellar protocol upgrades

Three small tools for the people affected by a Stellar upgrade: contract developers, validator operators, and anyone who has to explain an advisory to a team. The GitHub repositories are the product. This site shows what they actually do, using real recorded runs.

Start with the question you have

I write Soroban contracts

Will my Soroban contracts behave or cost differently after a protocol upgrade?

Upgrade PreflightExperimentalrelease v0.1.0

Runs your contract scenarios on two real local Stellar networks at different protocol versions and diffs the results. It reports behavior changes, breakage and cost changes, and states what it did not test.

For: Soroban contract developers. Needs Docker to run.

See it workAboutGitHub

I run a validator

What happens to a validator network during an upgrade vote?

Upgrade DrillExperimentalrelease v0.1.0

Boots real stellar-core containers on your machine, runs a scripted upgrade vote with scenarios such as a laggard or a lost quorum, and reports what each node did. Local only.

For: Validator and infrastructure operators. Needs Docker to run.

See it workAboutGitHub

I have to explain an advisory to a team

What does this advisory or release mean for us?

Advisory BriefExperimental

Turns Stellar release notes and advisories into plain-language briefs for non-engineers. Each claim cites a quote that code checks against the source text, or is marked unknown when the source does not say.

For: Operations, product and compliance readers.

See it workAboutGitHub

Why these exist

  • Contracts can change under you.A protocol upgrade can change what a contract costs or whether it runs. Developers get a short window to check, and no easy way to compare two protocol versions side by side.
  • A vote is hard to rehearse.Validator operators need to know how an upgrade vote behaves before it matters, including when one validator misses it. That is hard to rehearse without a real network.
  • A summary has to be checkable.Advisories are written for node operators. Everyone downstream has to translate them under time pressure, and a summary is only useful if you can check it against the source.

How the tools relate

They share no code and no data. They serve different people in the same upgrade cycle. Example A simplified timeline:

  1. An announcement is published

    Advisory Brief helps someone read it and decide who needs to act.

  2. Before the vote

    Contract developers use Upgrade Preflight to compare their contracts across the two protocol versions.

  3. Before the vote

    Validator operators use Upgrade Drill to rehearse how the vote behaves on a small local network.

What you can look at right now

Recorded The sample report and recording files in each repository, counted at its pinned commit · 2026-10-14

Honest status

All three are Experimental (reviewed 2026-10-06): Version 0.x, a single maintainer, and at least one central claim that is verified only in part. The interface and output formats can change. Each tool's page explains its own limits.

This page reflects commits upgrade-preflight@b0e179b, upgrade-drill@2110f98, advisory-brief@9dba194. GitHub data was fetched at build time on 2026-10-14, so it is a recording, not live.

Top