Shard Services Overview (Group 10)

The live shard-switch surface for preparing destination serial numbers, switching value across shards, and picking up the resulting coins.

Overview Commands Two-step vs one-step How new ANs are set Reuse for suspect-server moves

Related new command groups

The shard-switch pattern documented here (reserve destination slots under a session id, then complete the operation) inspired a new family of account-mobility command groups that move a coin's authority from a trusted “root” RAIDA to a faster third-party “suspect” RAIDA. These are separate, brand-new groups — Mobility (Group 20) and Authority (Group 21), with extensions to Locker (Group 8) and Key Exchange (Group 4) — not changes to Group 10. See the Mobility Services overview and Authority Services overview, and the “Reuse for suspect-server moves” assessment below for why a move is modelled on the shard pattern rather than built into it.

Overview

Group 10 converts coins from one “shard” (coin version) to another — e.g. legacy CloudCoin v1 (SHARD_CLOUDCOIN) or SuperCoin v2 (SHARD_SUPERCOIN) into the current RAIDAX coins. The pattern is always the same: delete the old coins on the source shard, then create new coins of equal value on this RAIDA. Value is conserved and checked on every path.

Commands

Code	Name	Role
172	get_sns	Discover free destination serial numbers on this RAIDA.
170	switch_shard_sum	Delete old coins (XOR-sum AN) and reserve destination SNs under a session id.
171	pickup_coins	Create the reserved coins by setting each AN (md5 of a seed + DN + SN).
174	switch_shard_sum_with_sns	One-call delete + create (XOR-sum verified, PANG-derived ANs).
175	switch_shard_no_sum_with_sns	One-call delete + create with per-coin ANs and partial-success bitmap.

Two-step vs one-step

There are two ways to drive a switch:

Two-step (170 → 171): switch_shard_sum deletes the old coins and reserves destination pages under a client-chosen session id, returning their free SNs. The client then calls pickup_coins with the same session id to actually set the new ANs. get_sns (172) is the optional discovery step that lists free SNs first.
One-step (174 / 175): delete and create happen in a single request. 174 verifies the old batch with one XOR-sum AN; 175 verifies each old coin with its own AN and supports partial success (a result bitmap says which old coins passed).

How new ANs are set

Across all variants, the new coin's AN is derived deterministically from a client-supplied seed: AN = md5(seed || DN || SN) (the seed is called AU in pickup_coins and PANG in the one-call variants, with DN in byte 0 and SN in bytes 1–4). The session-id reservation (reserve_page / page_is_reserved) is what stops two clients claiming the same destination SN between the switch and the pickup.

Live surface note

Command 173 is intentionally absent here because it is not part of the current audited live dispatch table.

Reuse for suspect-server moves (assessment)

The account-mobility design (moving a coin's authority root ↔ suspect) asks whether these shard commands can be extended to do the move. They share real DNA — both are “delete here, recreate there, conserve value” — but there are three gaps to weigh.

What maps well

The session-id + reserve + pickup pattern is almost exactly the move-locker handshake: reserve destination slots, hand back a reference, complete later. pickup_coins is structurally the same operation as claim_move_locker (set ANs on reserved destination slots).
Deterministic AN derivation (md5 seed) is a ready-made way to set the destination secret without the user being present at the instant of creation.
Cross-domain delete-then-create is the core of a move: the source stops honoring the coin, the destination starts.

What does NOT map (the gaps)

Same SN vs new SN. A shard switch mints brand-new serial numbers on the destination (it allocates free SNs). A suspect move must keep the same (DN,SN) — only the authority changes. The shard flow has no notion of “same coin, different authoritative server.”
md5 is not quantum-safe and not the move's security model. Shard ANs are md5(seed||DN||SN); the move design mandates AES-only with AES-CMAC integrity (md5 is collision-broken and CRC/md5 give no AEAD). A move's destination AN should be a fresh user-chosen secret (re-POWN), not a deterministically derivable hash a third party could recompute from the seed.
No cross-RAIDA authority record. Shard switch talks to legacy/cc2 sources but does not write a signed/CMAC'd “authority now lives on server S” record, and has no MOVED_OUT tombstone to stop the source re-answering. That authority bookkeeping (Groups 20/21) is exactly what a move needs and a shard switch lacks.

Verdict

The shard commands are a strong structural template for the move — the reserve/session/pickup mechanics can be lifted almost directly into the Mobility + move-locker commands — but they should not be overloaded to carry moves. A move differs on the three points above (identity preservation, AES-only secrecy, and authority bookkeeping), so the cleaner path is to model the new Mobility/Locker commands on the shard pattern rather than extend Group 10 itself. See the Mobility and Authority service overviews.