Soft-fork upgrades

After mainnet, Arrekta changes consensus through soft forks: changes that only restrict what was allowed, so old nodes keep following the chain (§15).

Upgrade room

Room	Today	A soft fork can
Lock kinds 16–127	valid to create, spendable by any non-empty witness, non-standard to relay	give a kind its spending rules (Bitcoin's model of undefined witness versions)
Transaction versions above 2	follow version-2 rules, non-standard (version 3 is the TRUC policy)	add rules for a new version
Existing rules	—	tighten them
Signature schemes	scheme schedules	sunset or retire a weakened scheme

Defining a lock kind outside 16–127, or loosening any rule, is a hard fork and needs every node to upgrade by a flag height.

Activation: version bits

Each network lists deployments (name, bit, start_height, timeout_height, period, threshold, min_activation_height, lock_in_on_timeout) (§9.4). Blocks signal by setting a bit in a header version of the form 0x20000000 | bits.

DEFINED ──start_height──▶ STARTED ──threshold reached──▶ LOCKED_IN ──min_activation_height──▶ ACTIVE
                             │
                             └──timeout_height──▶ FAILED (or LOCKED_IN if lock_in_on_timeout)

The state is fixed per period and computed from the block's own ancestry. GET /v1/deployments shows every deployment's state at the next height.

Current deployments: none on mainnet or testnet. Regtest has testdummy (bit 28, period 20, threshold 15) to exercise the mechanism.

Off-chain interfaces

P2P messages and the REST API are versioned separately: VERSION.protocol (currently 3) and the /v1 path prefix. The PST format has its own version byte.