[schronck]

Summary

Kick, add-party and change-threshold now publish their topology proposals only at submit. Before, the coordinator built each proposal with Authorize against the synchronizer store. Authorize distributes the proposal, and it authorizes outright when this node alone holds enough keys. At namespace threshold 1 the namespace change took effect at once, while the paired participant change still waited for the members.

The coordinator now signs both proposals in a temporary topology store. Canton keeps that store in memory and distributes nothing from it. Submit checks both serials against the synchronizer before it publishes anything. Add-party still publishes its P2P proposal before the signing round, because the new member needs it (#469). That proposal cannot take effect without the new member's signature.

Related issues

Closes #448

Type of change

• Bug fix
• New feature
• Refactor
• Documentation
• Build / CI / chore

Checklist

• cargo fmt -- --check passes
• cargo clippy --workspace --all-targets --all-features -- -D warnings is clean
• cargo test --workspace passes (1,155 passed; 3 ignored)
• Added/updated tests where appropriate
• Updated documentation where appropriate
• Commits follow the <type>(<scope>): <subject> convention

All CI checks pass on 833e818. The full Canton integration run ran the new no_early_publish phase and the extended G1 phase. The first run on 9fbb03f failed in add-party, see "Add-party's P2P" below.

Notes for reviewers

Root cause

create_proposals called Authorize with the synchronizer store as the target. The proto says Authorize proposes and distributes. A threshold-1 namespace needs only one owner, so the coordinator's own signature applied the DNS during CreateProposals. The applied DNS carried the new threshold. A migration from 1 to 3 then needed three signatures to repair.

Signing without publishing

The new workflow::proposal_store module signs a run's DNS and P2P in one temporary store. The flow is create, seed, sign at head + 1, then drop.

Canton accepts an explicit serial only as the successor of the store's own head. An empty store therefore accepts serial 1 and nothing else. The ported change seeded the store with the synchronizer's head transactions. Canton judges a transaction without a predecessor as a creation. A creation needs every DNS owner, or every P2P host's namespace, and a head usually carries only a quorum. So the seed is refused.

The seed now replays the party's full DNS and P2P history in effective-time order. It also replays the namespace delegations of every owner and host that ever signed. Each transaction is then judged against the state it was signed for. Signing starts only when the store's head serials equal the synchronizer's.

The replay passes four force flags. Canton reruns its dangerous-change checks relative to this node and its current ledger state. A past unhosting of this node would otherwise fail the active-contracts check.

Add-party's P2P

The new member waits until the P2P proposal that hosts it reaches its own synchronizer store. It then disconnects and signs (#469). Its ACS import refuses to run without that mapping in its store. A synchronizer store holds only sequenced transactions, so the first integration run timed out there.

The coordinator therefore publishes the add-party P2P proposal, signed by itself alone, right after signing. Canton requires an added host's own signature on the mapping that adds it. The proposal stays pending until the new member signs. The create step refuses to publish a P2P that does not add the new member. The add-party DNS still waits for submit. This was the old timing for the P2P, and it is the one exception to "nothing before submit".

Fallback above threshold 1

The temporary store stays the first choice for every party. A replay can still fail to rebuild the heads, for example on a history with revoked delegations. The coordinator then decides by the party's current namespace threshold:

• At threshold 1 the run stops with nothing signed or published. Only at threshold 1 can the coordinator's signature alone put the DNS in force.
• At threshold 2 or more the coordinator signs with Authorize against the synchronizer store, as before Topology proposals are published when they are created, so a threshold-1 party can half-apply a migration #448. It logs one warning that names the party and the replay failure. Its signature alone cannot meet the threshold, so the proposals stay pending until the members sign. The serials stay pinned to head + 1.

A participant that cannot be reached is not a failed replay. Transport errors such as gRPC Unavailable or an exceeded deadline propagate on both paths, and the step's retry handles them. The pure function signing_route in workflow/proposal_store.rs makes the decision, and unit tests cover each case.

Submit's serial check needs no change for the fallback. A proposal published while pending is not a head, so it still reads as head + 1 and goes out again with the peers' signatures. Add-party keeps its early P2P publish on both paths; Canton ignores the repeat.

Serials

The create steps read both head serials together with the mappings they build on. A create step refuses to build when the namespace differs from what ExportState read. Peers keep pinning head + 1, unchanged.

Submit reads both heads before it publishes anything:

• A proposal at head + 1 is published.
• A proposal equal to the head is in force from an earlier attempt and is skipped. This covers a coordinator restart between the DNS and the P2P.
• Any other serial stops the run with nothing published.

Canton also refuses a stale explicit serial with SERIAL_MISMATCH, so a moved serial never overwrites. The pre-submit check matters because the DNS goes first. Without it, a moved P2P serial leaves the DNS applied and the P2P refused.

Temporary store lifecycle

• A store name is decman-proposals-<instance>~<attempt>.
• close drops the store after success and after an error.
• A drop guard spawns the drop when a cancel aborts the task.
• Opening a store first drops every store of the same instance. A run that resumes after a crash cleans up its own earlier attempt.
• Boot drops every decman-proposals-* store before any run resumes. The sweep has a 15-second bound.
• A participant restart clears temporary stores as well, because Canton keeps them in memory.

Resume does not need a store. The signed proposals are persisted as artefacts before the step advances.

The boot sweep assumes one decman per participant.

Mixed-version peers

The wire format does not change. Peers still decode the proposal, check head + 1 and sign with SignTransactions.

A coordinator from before this change still publishes early. New peers keep accepting a proposal that equals the head at the head serial for that reason. The comment and the architecture guide now say why.

Other paths checked

• fix: pinned contract deployments, retired legacy keys, and renamed tenant execute API #521's legacy PartyToKeyMapping Remove still goes through Authorize against the synchronizer store. A threshold-1 party applies it with the coordinator's signature alone. It runs only after the inline keys are in force and validated, and it pairs with no other mapping. The failure mode here does not apply, so this PR leaves it unchanged.
• The add-party onboarding-flag clearing still uses Authorize. Only the joining participant can authorize it, so it cannot take effect early.
• check_added_signing_keys_signed (Adopt a legacy party's signing keys when adding a member #443) still runs before submit.

Tests

Unit tests cover the store lifecycle against a recording stand-in for the admin API: success, error, abort, resume and the boot sweep. They also cover the replay order, store names, the protocol-version parse, the submit-time serial check, the add-party host guard and the fallback decision.

The new no_early_publish Canton phase runs while the shared party is at threshold 1:

• Signing directly pins head + 1 and changes nothing on the synchronizer for 10 seconds.
• After the P2P serial moves twice, submit refuses the stale pair. The namespace stays at threshold 1.
• A real change-threshold run from 1 to 2 pauses P2 with SIGSTOP after it joins. P3 signs, P2 never does. Both mappings stay unchanged before and after the cancel.

Each step checks that no temporary store is left on P1's participant. The coordinator-restart phase (G1) plants a leftover store and asserts that the boot sweep drops it.

Not tested

• Devnet and mainnet histories. The replay is exercised only on the localnet party. A long history with rotated or revoked delegations is the likeliest place for a replay to fail. Such a party falls back above threshold 1 and stops at threshold 1. No integration test drives the fallback; unit tests cover the decision.
• Kick and add-party at threshold 1. The suite runs them at threshold 2. Their create and submit paths share the code the threshold-1 phase exercises.
• A task aborted during the CreateProposals window itself. The unit test covers the drop guard.

[scolear]

Reviewed 833e818.

The change is sound. The coordinator signs the DNS and the P2P in a temporary store, and Canton distributes nothing from that store. Submit reads both heads before it publishes anything. proposal_standing refuses a moved serial, and it compares the full transaction before it treats a proposal as in force. The signed transaction bytes do not change between the temporary store and the synchronizer, so the peer signatures stay valid.

Store lifecycle: in_store drops the store after success and after an error. The Drop guard spawns the drop when a cancel aborts the task. Each attempt gets its own name, so a late drop never lands on the next attempt. open drops the earlier attempt of the same instance, and the boot sweep drops the rest. The G1 phase plants a leftover store and asserts the sweep removes it.

Add-party: adds_host refuses to publish a P2P that does not add the new member. The add-party DNS waits for submit. Kick keeps the DNS first and the P2P second, which is the safe order: the kicked member loses namespace authority before it loses hosting.

Crash paths: a run that persisted the signed pair resumes at submit and re-checks the serials. It does not sign again. A run that crashed after the DNS went out finds the DNS at the head and sends only the P2P.

Tests: unit tests cover the serial check, the store lifecycle, the replay order and the fallback decision. The no_early_publish phase covers the threshold-1 scenario, and the following restore the threshold to 2 round drives a real threshold-1 run through submit.

Two points I could not verify from the code alone. First, that Canton requires an added host's own signature on the P2P that adds it. The CI add-party run supports it, and it matches the Canton docs I know. Second, that a devnet or mainnet history replays into the store. The fallback and the threshold-1 refusal bound the damage if it does not.

One residual window remains, and the PR names it: a P2P serial can still move between the pre-check and the P2P publish. The DNS is then in force and the P2P is refused with SERIAL_MISMATCH. That window is seconds wide and the old code had no check at all, so this is not a blocker.