Problem
The architectural direction (per the 2026-05-25 + 2026-06-01 strategy docs) is to ship AgentEscrow as a regular Solidity contract deployed to a fixed, well-known address in genesis state — not as a system contract with upgrade-via-fork semantics. This sidesteps the governance-capture optics ("any chain that ships kcolbchain's contract as system-contract genesis is a chain kcolbchain controls") and keeps the contract redeployable via Council vote.
We need a written migration plan that:
- Documents which address gets the genesis deploy
- Specifies what state transitions are valid during the testnet -> mainnet cutover
- Defines smoke tests that prove the genesis deploy is functionally identical to a fresh
forge create
- Defines the upgrade path (Council vote -> redeploy at a new address -> chain proxy redirect, NOT system-contract fork)
Proposed Approach
docs/agent-escrow-genesis-migration.md covering:
- Target address: TBD with Lux subnet config (likely
0x000...A002 per architecture RFC)
- Genesis state: zero balance, owner = Council multisig, no in-flight payments
- Constructor invariants verified post-genesis (owner, version, no unintended state)
- Smoke test corpus (
test/genesis_cutover.t.sol):
- Fresh genesis state matches
forge create deployment byte-for-byte
createPayment{value: 0.01 ether} round-trips against happy-path + timeout + challenge paths
- Council ownership transfer works (not just owner-key transfer)
- Out-of-band tx replay protection: pre-genesis testnet tx hashes do not collide with post-genesis tx hashes
- Upgrade path doc:
- Future upgrades = Council vote -> deploy
AgentEscrow_v2 at a new address -> deprecation notice on v1 -> migration period for in-flight payments
- Explicitly not a system-contract upgrade-via-fork
- Testnet cutover dry run at least 2 weeks before mainnet
Acceptance Criteria
References
Problem
The architectural direction (per the 2026-05-25 + 2026-06-01 strategy docs) is to ship
AgentEscrowas a regular Solidity contract deployed to a fixed, well-known address in genesis state — not as a system contract with upgrade-via-fork semantics. This sidesteps the governance-capture optics ("any chain that ships kcolbchain's contract as system-contract genesis is a chain kcolbchain controls") and keeps the contract redeployable via Council vote.We need a written migration plan that:
forge createProposed Approach
docs/agent-escrow-genesis-migration.mdcovering:0x000...A002per architecture RFC)test/genesis_cutover.t.sol):forge createdeployment byte-for-bytecreatePayment{value: 0.01 ether}round-trips against happy-path + timeout + challenge pathsAgentEscrow_v2at a new address -> deprecation notice on v1 -> migration period for in-flight paymentsAcceptance Criteria
test/genesis_cutover.t.soland CIReferences