scripts/deploy_reputation_registry_v2.md

Deploy ReputationRegistry v2 — Procedure

Status: code ready, not yet deployed. Awaiting user approval.

What this deploys

A new ReputationRegistry contract with two corrections to the deployed v1 (REPUTATION_REGISTRY_ADDRESS):

Fix	Symbol	Before	After
β	_fillSignal fee scaling	x = cumFees / 100 (treats USDC 6-dec as 1e18 fp — off by 1e12)	x = (cumFees * 1e12) / 100 (rescale USDC → 1e18 first)
α	initial score on first touch	ONE = 1e18 (1.0)	HALF = 5e17 (0.5)

See outputs/reputation_v2_fix.patch for the diff.

Pre-deploy checklist

1. Compile artifacts are fresh. cd contracts && ~/.foundry/bin/forge build must finish cleanly. The deploy script reads bytecode from contracts/out/ReputationRegistry.sol/ReputationRegistry.json.

2. Tests pass. cd contracts && ~/.foundry/bin/forge test must report all 30 tests passing.

3. Wallet funded. Check HACKATHON_WALLET_PRIVATE_KEY's Arc-testnet balance covers ~5 USDC-equivalent of gas (the constructor + 3 authorization calls together used ~1.5M gas on v1 deploy).

4. Simulation reviewed. Run .venv/bin/python scripts/simulate_ema.py and confirm v1-vs-v2 deltas match expectations (see README §11.4 for the reference table).

Dry-run (recommended first)

# Source the env so the script picks up HACKATHON_WALLET_PRIVATE_KEY etc.
source .env

.venv/bin/python scripts/deploy_reputation_registry_v2.py

This prints what would happen without broadcasting any transaction. Expect output like:

DRY-RUN — would do the following (re-run with --confirm to broadcast):
  1. deploy ReputationRegistry (constructor takes no args)
  2. setAuthorized(<deployer>, true)  # operator EOA
  3. setAuthorized(0xE046...07a, true)  # TranslationAuction
  3. setAuthorized(0xcE75...0e5, true)  # BuilderFeeRouter
  3. setAuthorized(0x1eE7...d9a, true)  # JudgePanel

Actual deploy

source .env
.venv/bin/python scripts/deploy_reputation_registry_v2.py --confirm

The script will:

1. Deploy a new ReputationRegistry contract (operator is auto-authorized by the constructor).
2. Authorize each downstream contract address that was supplied via env vars (TRANSLATION_AUCTION_ADDRESS, BUILDER_FEE_ROUTER_ADDRESS, JUDGE_PANEL_ADDRESS) so they can push state.
3. Write a JSON artifact to outputs/deployment_reputation_v2.json.
4. Print the new address.

Post-deploy

1. Record the address in .env:

   echo "REPUTATION_REGISTRY_V2_ADDRESS=0x..." >> .env
   

2. Re-run the chain consistency verifier against the new address to confirm it accepts updates:

   REPUTATION_REGISTRY_ADDRESS=$REPUTATION_REGISTRY_V2_ADDRESS \
       .venv/bin/python scripts/verify_chain_consistency.py
   

3. Cutover. Once the v2 contract has been smoke-tested in isolation, point REPUTATION_REGISTRY_ADDRESS at the new address and restart the orchestrator. The v1 contract remains on-chain as a historical record — leave the existing REPUTATION_REGISTRY_ADDRESS_OLD_* pattern in .env for provenance.

4. No backfill required. Reputation state is per-address EWMA; the v2 contract starts every agent fresh at HALF on first touch. Historical BuilderFeeRouter.cumulativeFees is still readable on-chain as the audit trail of past activity.

Idempotency

If REPUTATION_REGISTRY_V2_ADDRESS is already set in the environment and the address has bytecode on-chain, the script exits early — re-running it is safe and is a no-op.

Rollback

If post-deploy verification fails, simply do not update REPUTATION_REGISTRY_ADDRESS. The deployed v1 contract continues operating unaffected; the v2 contract is dormant until something points at it.