On 28 September 2026, Sovereign Assurance & Attestation closed. The programme exists to make three things verifiable about a piece of software: which version it is, which controls were applied to it, and which evidence supports its qualification. Its act on the FxChain development line was to hold the reconstruction closure of 2 August 2026 to that standard, and to do it on the line itself rather than on a copy.
That act is now complete. The closing commit, 11c96351, heads the development line. It was qualified locally, examined by a separate reviewer, run twice on hosted continuous integration, before and after it was integrated, and it passed all 50 jobs both times. The runs that failed on the way there are kept, with their causes.
What closed
A closure on this line is not an announcement. It is a sealed act with a receipt, and it is reached only when every condition named in advance holds for one precise version, identified by its digest. For this act the conditions were simple to state and demanding to meet: the candidate must pass its full local qualification, its behaviour must not depend on the machine or the account that runs it, a reviewer who did not build it must pass it, and the hosted pipeline must be green on it, first on a branch of its own and then on the development line.
The receipt was sealed on 28 September with the status closed. It names the commit, the runs and the review.
Four facts that coincide
Each of the following is necessary. None of them is sufficient alone, which is the whole point of the discipline: a green run is not an acceptance decision, and neither is a review or a local test report taken on its own.
- The version is named. Commit
11c96351, treefcf42af1, with a single parent, the previous candidatebaa58318. Everything below refers to those bytes and to nothing else. - It was qualified locally. The full test suite of the workspace passed: 10,487 Rust tests, with none failed and none ignored, and 195 Python tests. The official qualification battery passed 170 of its 170 entries.
- It does not depend on who runs it. The qualification was repeated under two different user identities, and gave the same result under both.
- It was reviewed, then run where it lives. A separate reviewer examined the change against the previous candidate and passed it. Only then did the hosted pipeline run, first on an auxiliary branch before integration, then on the development branch after it: 50 of 50 jobs each time, each on its first attempt.
How the closure unfolded
The last three days are worth reading in order, because the record keeps the failures next to the success.
- 26 September. The reviewed candidate of the previous stage was integrated. The hosted runner did not have what the proof steps assumed: historical commits they refer to had never been published there, and a sandboxing tool they use was not installed. The run failed and was cancelled on both of its attempts. The repair was treated as a change of its own.
- 27 September. The repair candidate,
baa58318, was frozen, qualified and integrated. The hosted run went red: 48 jobs passed, one failed and one was skipped behind it. - 27 September, evening. The cause was found and stated. A successor,
11c96351, was built from the red candidate, with one parent and one purpose. - 27 and 28 September. The successor went through the full local qualification, the portability check under two identities, the official battery and the separate review.
- 28 September. The hosted pipeline ran on an auxiliary branch before the development line was touched: 50 of 50. The development line was then fast-forwarded to the successor, and the hosted pipeline ran again on it: 50 of 50. The closure receipt was sealed.
The last obstacle, stated plainly
The red run of 27 September had a mundane cause, and it is worth stating because the fix is the kind of thing the discipline exists to catch.
The qualification starts ordinary producer processes inside an isolated runtime directory that belongs to the account that calls them. The previous candidate started those producers under a fixed numeric user identity. On the machine where it was built, that identity and the calling account were the same, so nothing failed. The hosted runner calls them from a different account: the producers could not use a directory that was not theirs, and the step that admits the proof of reconstruction failed.
The successor binds the identity of ordinary producers to the isolated caller, whoever that caller is, instead of to a fixed number. That is a small change in code and a large one in meaning: the result no longer depends on the account that runs it. It was not assumed. It was shown, by running the qualification under two different identities before anything was pushed.
Two local qualification runs were refused along the way by their own guards: one because available memory fell below the floor the run requires, and one because a socket path of the compiler cache exceeded the length the system allows. Neither was resumed or patched mid-run. Each was replayed in full, and both refusals are kept in the record.
What was verified, and where
| Check | Where | Result |
|---|---|---|
| Full test suite of the workspace, Rust | Local qualification | 10,487 passed, 0 failed, 0 ignored |
| Python test suite | Local qualification | 195 passed |
| Official qualification battery | Local qualification | 170 of 170 entries |
| Independence from the running account | Local qualification, two identities | Same result under both |
| Review of the change against the previous candidate | A separate reviewer, not the builder | Passed |
| Hosted pipeline before integration | Auxiliary branch, run 36392880837 | 50 of 50 jobs, first attempt |
| Hosted pipeline after integration | Development line, run 36399021626 | 50 of 50 jobs, first attempt |
| Closure receipt | Sealed act record | Status closed, digest efa763c8 |
Why the long way
There were shorter paths. The red job could have been re-run until it passed, the runner could have been adjusted to match the builder's machine, or the failing step could have been set aside as an environment problem. Each would have produced a green badge. None would have produced an assurance.
The programme's subject is precisely the question those shortcuts dodge: which version ran, under which controls, with which evidence. An assurance programme that closed on a retried run would have attested nothing about itself. So the failure was treated as information. Its cause was stated, the successor had to show why it would not repeat, and the proof was rerun from the start, on the machine that builds and on the machine that hosts.
The same rule explains why the red runs stay public in the record below. A refusal on this line has the same standing as an acceptance: it is sealed with its reasons, and it remains readable after the success that followed it. The method is described in the dossier The acceptance discipline.
What it means for FxChain
The evidence snapshot of this portal moves to the closing commit. The development line now reads seven sealed eras, 372 accepted crossings, and 50 of 50 conformance jobs green on its head, as of 28 September 2026. The notes that set aside the later amendments of the line as failing are withdrawn, because the closure supersedes them.
Three steps on the roadmap were waiting on this closure: adoption zero, the offline verifier that lets an outsider check a sealed history on their own machine; the rung of the common trunk that carries the living node, a minimum wallet and that verifier; and edition 1.9 of the papers, realigned on the architecture programme. They are unblocked. They are not started: on this line nothing opens by itself, and each of them begins only with its own explicit act.
Nor does anything here change what FxChain is today. It is a protocol implemented on a local development line, under internal review. There is no public network, no token and no service, and this closure claims none.