EPOCH_MOVE_EXECUTE — Group 8, Code 93
Internal: at the epoch, root transfers the coin records to the suspect over the inter-RAIDA channel and installs them into the reserved destination locker in INBOUND state. Not client-dispatchable.
Design-stage — parameters are a first draft
Field sizes are drafted from raidax/ideas_for_suspect_raida_servers.txt (Addenda 5–7) and are not final or implementation-verified. The body is encrypted per the header ENC_CODE; see below.
Phase II — later
This command is Phase II: convenience, recovery, or optimization that is not required for the first working move. Internal step of the Phase II move-locker feature.
How it works
This is the internal, server-to-server action that actually carries coins from the root to a suspect at the epoch boundary. It is not something a client calls. When the scheduled epoch arrives, the root takes every pending move locker and transfers its coins to the destination suspect over the secure inter-server channel.
The suspect installs the coins into the reserved destination locker in an inbound state — present but not yet claimed — and the root records that it has handed them off (a “moved-out” marker) so it will no longer answer for them. The transfer is authenticated with the shared server key (AES-CMAC). After this runs, the user can come back and claim their coins whenever they like.
Direction & encryption
- Direction: root → suspect
- ENC_CODE: 7 (K_rs)
Request Body parameters
| Field | Bytes | Description |
|---|---|---|
| dest_locker_id | 16 | Reserved destination locker. |
| count | 2 | Number of coins. |
| coins | var | Repeating: DN(1) + SN(4) + AN-fragment handling per move protocol. |
| CMAC | 16 | AES-CMAC under K_rs. |
Response Body parameters
| Field | Bytes | Description |
|---|---|---|
| installed | 2 | Number of coins installed into the destination locker. |