Activation notice — block 16,450,001
LIVE since block 16,450,001. Node 0.9.12 swapped in at block 16,450,000 on 2026-09-22, and every rule below turned on one block later. This page is the record of what changed at that boundary, because a client written against the older behaviour breaks on the rows below.
{"type":"account_state","address":"0x…"} carries the live height if you need to
check where the chain is.
Four behaviours move at ONE height, so the chain gains one boundary rather than four. All four are on the multi-sig lane. Anything else in the release changes no request, response, or rejection you can see.
Why one block above the swap. The outgoing node commits block 16,450,000 and only then halts, so that block still ran the old rules. The new rules apply from the first block after it.
Rejections that are NEW
Each is a commit verdict, so it arrives as a
200 carrying the rejection envelope.
| Action | Refusal | Before the height |
|---|---|---|
convert_to_multi_sig_user with more than 16 signers | PRECONDITION_FAILED — at most 16 signers | Accepted |
convert_to_multi_sig_user with an address repeated in signers | PRECONDITION_FAILED — signers must be distinct | Accepted. One such roster locks the account for good — see below |
multi_sig with more than 16 entries in signatures | PRECONDITION_FAILED — at most 16 signatures | Accepted |
The reference always published both roster rules. The chain did not enforce them until this height.
A repeated signer locked the account
Read this one if you registered a roster before the height. The quorum counts
DISTINCT signers, but threshold was checked against the raw array length. So a
[A, A] roster at threshold: 2 converted, and then no envelope could ever reach
quorum. A converted account refuses every single-sig path, including the re-key
that would repair it. That account cannot act again.
The refusal stops such a roster before it commits. It does not repair a roster
that committed before the height. Check each roster you registered: if its
distinct addresses number fewer than its threshold, that account is locked.
Why 16
Each entry in signatures costs one signature recovery on every validator, so an
uncapped list is work that the caller controls. A roster holds at most 16
signers, so no envelope needs more than 16 signatures. Extra entries never raise
the distinct count that the quorum reads.
A multi_sig envelope moves one nonce window, not two
| Surface | Before the height | Now |
|---|---|---|
The envelope's top-level nonce | Advanced the POSTING account's window before dispatch, even when the handler then refused the action | Advances no window |
params.nonce | Advanced user's window after the roster quorum verified | Unchanged |
| An envelope that the multi-sig account posts itself, with the two nonces equal | Refused at commit: the outer advance spent the nonce that the handler then checked | Accepted |
Why. Any account may post the envelope, and the roster quorum is its only
authority. So the envelope moves only the window of the account it acts for,
user.
Checklist
- Keep each roster at 16 distinct addresses or fewer.
- Send at most 16 entries in
signatures.
Nothing else moves
No /exchange action tag is added or removed. Every EIP-712 type string is
unchanged, so a signed action that verified below the height verifies above it.