M3.10b: the version-six execution model and its recorded transition trace

[kaikisegfault]

Rebound from economy-transition-v5 to economy-transition-v6, which merged in #170. The contract the direction does not supersede now exists, so this is unblocked against a settled target.

Why this comes before the C++ codec

The repository's own lesson rather than a preference. M3.9a implemented a version-four codec and M3.9b found that two implementations agreed perfectly about a message neither could construct, because a codec never asks where a transaction gets its arguments. The execution model is the first step that runs a transition, and version six has more transitions with more state behind them than any predecessor.

What it must exercise

1. The recovery path end to end. A person with an identity, no signer, and an escrow that holds value assigns a new signer under scheme 2, pays the fee from that escrow, and then transacts with the new key. That is the path version four disabled and version five could not fund.
2. Registration as one atomic execution. Identity, escrow zero, first signer, and the entry airdrop, with a fee-exempt envelope and a zero nonce — and the same registration past the millionth identity, which must still succeed with a zero balance.
3. A transfer refused for its recipient, immediately after the accepted version-one bytes are admitted, so the byte identity and the execution divergence appear in one trace.
4. Both directions of a posture change, including a mixed change that tightens one field and relaxes another and therefore needs the HUB signature.
5. A block that commits a root. Everything recorded so far establishes that values encode, not that a block executes, charges a fee, and commits.

Then

M3.10c: the C++20 kernel codec for version six, which is requirement 10. Replace src/v4/ rather than adding src/v6/ beside it, and record the decision either way — the codec is the only place in the repository where a superseded contract would still be compiled.

[kaikisegfault]

Reordered by the defect #154 surfaced.

This work is unchanged in substance and now comes third: the execution model
targets economy-transition-v5, not version four, because version four's kind 11
has no conforming implementation. The two slices before it are the version-five
model and vectors, then the C++ codec updated to version five.

One addition to the scope when it starts: the trace must exercise the recovery
path specifically — a person with an identity, no linked addresses, and a fresh
funded account adding one. That is the path version four disabled, and a trace
that does not walk it would not have caught the defect either.

[kaikisegfault]

Renumbered and rebound to version five.

This issue was opened as M3.9b against economy-transition-v4. Writing it is
what found the defect in version four's kind 11 — the transaction names an
identity it does not carry — so the slice was interrupted and three slices
landed in front of it: M3.9b accepted economy-transition-v5 (#154), M3.9c gave
version five its model, vectors, and verifier (#157), and M3.9d updates the C++
codec. This slice is now M3.9e and targets version five.

Two things change in its scope as a result.

The model is version five's, not version four's, and version four's kind 11
has no conforming implementation, so it could not have been written against it.

The trace must walk the recovery path specifically: a person with a HUB
identity, no linked addresses, and a fresh funded account adding one. That is
the path version four disabled, and a trace that skips it would not have caught
the defect either.

The body's reference to "the C++ transitions are M3.9c" is superseded: the codec
update is M3.9d and precedes this slice.

[kaikisegfault]

Version binding removed from the title, because the target moved again.

The owner directed a pivot at the close of M3.9c on 2026-08-15, recorded in
ADR 0039:
HUB verification becomes mandatory for anyone who registers and for interacting
with any part of the ecosystem, an address becomes an operational tool rather
than an identity root, and biometric confirmation becomes the default on every
financial transaction and every mint.

So this slice targets whatever contract encodes that direction, not
economy-transition-v5. It is blocked behind that contract, which is itself
blocked on one founder-reserved question: how a person who holds nothing pays
for their first transaction.

Two things in the recorded scope survive the change and are worth keeping:

The trace must walk the recovery path. Under the new direction that path is
different and simpler — register, verify, the chain recognises the existing
identity, attach a new address — but it is still the path a trace that skips it
would fail to check.

Conservation stays the load-bearing property: every channel's
issued + outstanding + carry equal to assigned permissions times that
channel's leg, and account balances plus fee pool plus typed custody equal to
total supply.

[kaikisegfault]

Unblocked in principle, still sequenced behind the contract.

The four ADRs of 2026-08-15 (0039 through 0042) settled the account architecture
end to end, and no founder-reserved question remains open for this milestone.
This slice is therefore no longer blocked on a decision — it is sequenced behind
economy-transition-v6, which is the recorded next action (M3.10a).

Its scope survives the pivot with one substitution: the trace should walk the
entry path as well as the recovery path. A brand-new person completes HUB
verification, receives the first-day airdrop of 171,000,000 atomic from the
hub_verified_user_incentives channel, and transacts from it. That path is what
makes a chain with zero genesis allocation reachable at all, and a trace that
skips it would not check the thing the architecture was rebuilt to provide.

Conservation remains the load-bearing property, and it now has one more term:
the entry airdrops are issuance from a capped channel like any other, so
issued + outstanding + carry must still close against that channel's cap.