feat(genesis-writer): rebuild rewards from table state, not replayed transactions

[rickyrombo]

What changed

Reward pools and rewards were migrated by scanning ~66M rows of core_transactions for reward transactions by protobuf wire tag, so the original signed bytes could be replayed verbatim.

Once the transactions are signed fresh, those bytes have no role — and core_reward_pools and core_rewards already carry every field a new transaction needs:

needed by	fields	source
CreateRewardPool	rewards_manager_pubkey, authorities	core_reward_pools
CreateReward	reward_id, name, amount, rewards_manager_pubkey	core_rewards

Two SELECTs replace the scan, and with it the chunked block_id windows, the false-positive confirmation, the wire-tag constants and their tests, and the xmin-horizon care that reading a live production validator demanded. The legacy-to-modern conversion path goes too — there is nothing to convert when transactions are built from table state.

Columns deliberately not read: address, id, index, tx_hash, sender, raw_message, block_height, timestamps. The chain derives all of them. sender becomes whichever key signs here, which is intended.

Signatures are real

• envelope — secp256k1 by one of the pool's own authorities, satisfying validateCreateRewardPool's signer-membership check
• rm_owner_signature — ed25519 over the same body by the reward manager keypair

Both derive from operator-supplied launchpad secrets, read from the environment rather than flags because a flag reaches argv and is kept in shell history.

Why two secrets

The pool set spans a secret rotation. Reward managers are initialized once on Solana and cannot move, so they stay bound to the secret that created them, while current claim authorities derive from the replacement. Each pool is matched against both generations, and a pool that neither derives stops the run rather than being emitted with a key that controls nothing.

That generational split is also how a phantom pool is identified. A pool whose reward manager derives only from the rotated secret, for a mint that also has an original-generation pool, names a Solana account that was never created — reward creation re-derived the manager after the secret changed. Emitting a create for it would make that dangling reference canonical on the new chain, so it is dropped and its rewards move to the manager their mint actually has.

The qualifier is load-bearing: a mint launched after the rotation legitimately has a rotated-generation manager, it does exist on Solana, and dropping it would silently discard that mint's rewards.

Verification

Rewards are checked for functional equivalence, not row equality — this migration deliberately improves on the source state rather than reproducing it:

• the offer (reward_id, name, amount) is preserved exactly
• every reward names a reward manager some emitted pool covers
• rm_owner_signature verifies via ed25519.Verify against the reward manager pubkey itself
• the envelope signer, recovered via ProtoRecover, is a member of the pool's authorities
• a pool no mint derives, a pool with no held authority key, and a reward naming an uncovered pool each stop the run

Verified red against the previous behavior: disabling phantom detection fails with the phantom pool listed among those to create, and fails the remap assertion.

Operator-facing changes

• --core-cmt-home, --core-scan-chunk, --core-scan-dry-run removed. --core-dsn is the only reward source.
• New --launchpad-mints (file, one mint per line). Required for rewards: every launchpad key is a function of (secret, mint), so the secrets alone derive nothing.
• Secrets come from GENESIS_LAUNCHPAD_SECRET and GENESIS_LAUNCHPAD_SECRET_ROTATED.

🤖 Generated with Claude Code