Ethereum mainnet: deployed contracts and commissioning status

Updated 13 October 2026 UTC (12 October in Toronto). The contracts are deployed; the recorded operational state is paused. The public website remains a planning and demonstration experience. Deployment and explorer verification do not open live jobs or authorize payments.

At a glance

This is the AGIALPHA deployment of AGIJobsv0. AGIJobManager / ENSJobPages is a separate system using USDC. USDC amounts in commercial planning examples do not change this stack's contract token or settlement rules.

Download/read the machine-readable address and evidence record. It includes all constructor arguments, fully qualified source names, original artifact/build identities, runtime-template digests and dated explorer observations. It is an informational inventory, not an executable deployment configuration.

The explicit mainnet address book is reconciled to this inventory: thirteen protocol components and the coordinator at the top level, with ten fixed implementations under implementations. Its network: mainnet and chainId: 1 fields are understood by the environment generator. TaxPolicy and absent modules are explicitly zero; the separate legacy JobManager is not selected. Select this file explicitly for reviewed chain-1 read-only reports. Monitoring selects it only for mainnet and ignores zero placeholders.

The generic default book deliberately contains only zero addresses. Existing transaction-capable scripts, including transfer-ownership.ts and auditIdentityRegistry.ts --clear, do not enforce the book's chain ID; supplying live addresses there could target the wrong chain or ownership topology. Their source is preserved. Default ownership transfer skips these absent addresses, and default identity clearing rejects the missing registry before a contract lookup. Transaction use requires a separately reviewed chain guard, deployment selection and SystemPause topology; do not populate the generic file to bypass that review. Explicit CLI/configuration overrides remain the operator's responsibility.

For owner verification, use the existing OWNER_VERIFY_ADDRESS_BOOK override below. The protected verifier and its legacy default path are unchanged. Local and test-network reports require their own address book and network. This inventory records locations only; it does not approve ownership transfers or establish current ownership/pause state.

For a read-only mainnet owner report, after configuring the intended chain-1 provider and reviewed expected-owner settings:

OWNER_VERIFY_ADDRESS_BOOK=docs/deployment-addresses.mainnet.json OWNER_VERIFY_STRICT=1 \
  npm run owner:verify-control -- --network mainnet

Strict verification fails on missing addresses, missing expected owners, ownership mismatches or read errors. Disabled/absent modules and the SystemPause ownership topology must be reconciled in the reviewed owner configuration; this example does not claim that commissioning already passes. It sends no ownership transaction. Check the report’s chain ID and selected address-book path before using the result.

What happened

The existing coordinator 0xeF1Be4B8251a9C4a584140C113508B95fd8B2543 was completed through the operator's controlled recovery. The transcript records eleven confirmed recovery transactions at nonces 262–272 and a final deployPaused transaction. That final transaction is 0x982bb93de4d3922e3cdfd2886468b5d4943344c3b852e2741b3c6bdcfa1aeb5f. The earlier coordinator and ten fixed implementations were retained.

The final saved live verification run reports block 26172980, matches for all 24 runtime templates, Ledger control of SystemPause and three direct-owner modules, and all eight managed modules paused under SystemPause. These are operator-side observations recovered from the supplied transcript, not a new RPC verification performed for this release. Separate latest reads and compiler-immutable masking mean they do not establish a single atomic snapshot or independently prove immutable values.

The deployment source tree is 4c95939614f0b21681ac94915e5365623f5bee48. The recorded reviewed configuration SHA-256 is 5c16902d703dc8694c2f4b20deaaa98329ed2541d46f5051c6ca112d30ebe4be. The new rc.5 source publication records this existing rc.4 deployment; its tag must not be substituted for the deployed-source identity when reproducing contract bytecode. Solidity, compiler settings, dependencies, token configuration and economic behavior are unchanged by this update.

Contract address directory

Explorer observations were collected by read-only HTTPS requests from 2026-10-12T16:23:34.497469+00:00 through 2026-10-12T16:24:16.111647+00:00, with StakeManagerEscrow checked again at 2026-10-12T17:12:43.458780+00:00 after its successful source publication. For each successful entry, Etherscan displayed Source Code Verified — Exact Match and the matching contract name. These are dated source-publication results, not a smart-contract security audit. The JSON record retains each page's SHA-256 and observation time.

Governance and pause state

The mainnet parameter-change sentinel watches the deployed StakeManager, FeePool and JobRegistry. TaxPolicy is disabled and has no address to monitor; both TaxPolicyUpdated event conditions remain on those protocol emitters. All three checked-in sentinel templates resolve against this inventory without zero addresses. Rendering these files does not activate an external monitoring service; notification-channel mapping and operational commissioning remain required.

The eight managed contracts are JobRegistry, StakeManager, ValidationModule, ReputationEngine, ArbitratorCommittee, DisputeModule, PlatformRegistry and FeePool. Their recorded owner is SystemPause, whose governance authority is the Ledger address above. The saved later verifier also reports Ledger control of CertificateNFT, IdentityRegistry and JobRouter. Do not transfer the managed contracts directly to a wallet: the SystemPause ownership topology is intentional.

The initial recovery report left IdentityRegistry acceptance and coordinator handoff outstanding. The later operator-supplied finalized-block report at 26,179,827 records the coordinator, all ten implementation owners, IdentityRegistry (with zero pending owner), and all other direct-owner components under the Ledger. The eight managed owners remain SystemPause. This supersedes the earlier handoff uncertainty for the enumerated contracts and views, without proving every historical role or external permission was removed.

Latest configuration and reward policy

The public configuration extract preserves the source report's SHA-256, snapshot block/hash, exact large integer values as decimal strings, all 24 recorded runtime checks and the timing of the later cap observation.

The cap screenshot records successful governance transaction 0xafe09f8a… at block 26,180,024, 2026-10-13 00:36:35 UTC, followed by the JobRegistry read-contract value. These later screenshots are not folded into the earlier finalized snapshot or claimed as fresh finality verification.

The requested 10% job stake is not implemented by this deployed contract. Its jobStake is an absolute token amount; setting it to 10 would not introduce percentage semantics. Percentage staking requires a separately reviewed contract/design change, compatibility tests and an explicitly authorized deployment or migration. This source release changes no on-chain economics.

The report also records EIP-7702 account code on the temporary deployer wallet. Clearing that delegation is separate wallet cleanup; it is not evidence of continuing ownership of these contracts. The selected deployer role mappings in the report are false/zero. No additional removal transaction is required by this release, and no global claim of zero remaining authority is made: the report explicitly leaves globalAuthorityTransferComplete and productionApproved false. External token/ENS permissions, full event/role history and off-chain credentials were outside its scope.

Explorer verification completed

The preserved API journal at 2026-10-12T02:47:18Z records 19 verified / 5 failed. Later operator-reported progress was 22/24. The initial page inspection at 16:23–16:24 UTC found 23/24, including StakeManager. The subsequent operator success screen and fresh StakeManagerEscrow page inspection at 17:12 UTC bring the current recorded total to 24/24 exact source matches. Earlier 19/24, 22/24 and 23/24 results are retained as history, not current failures.

StakeManagerEscrow is now source verified. The latest supplied browser result shows successful generation of matching bytecode and ABI for 0x97A17aAC4F6bD865d9e38d53411526B3291e88ae. The independent read-only page check displays Source Code Verified — Exact Match, contract name StakeManagerEscrow, and compiler v0.8.25+commit.b61c2a91. This supersedes the earlier 12:11 Toronto-time err_code_5 result, empty selected contract name and 0x compiled-bytecode display. Those earlier errors did not establish a Solidity defect. Source verification is complete for the recorded inventory; commissioning and current-state checks remain separate.

The original build uses Solidity 0.8.25+commit.b61c2a91, optimizer 200 runs, viaIR, and Cancun. Preserve the original compiler input and settings, exact fully qualified target, constructor arguments and local replay proof when investigating. Do not redeploy or alter token economics, Solidity, ABI/events or compilation settings merely to obtain an explorer badge. Verification troubleshooting and source publication send no Ethereum transaction and require no wallet key.

The Escrow verification retrospective and offline reproduction guide preserves the successful 39-source v5 solution, exact input and source hashes, portable replay tool, and regression evidence. It explains why the two additional original files must be retained for this input. The contract is already verified: use the tool for archival reproduction, not another submission.

What remains before opening

Use the current production readiness record for the complete gates. Remaining work includes a fresh pre-opening ownership/pause/configuration check, finalized confirmation of the later reward cap, validator-pool commissioning, authorized production signing; independent security review; and real provider, worker, reviewer, settlement, monitoring and recovery commissioning. The source release does not waive any of these requirements.

The source-v2.1.0-rc.5 tag publishes this source and evidence record. It does not trigger the signed production release workflow, which accepts v* tags. That workflow's generic full-stack manifest still requires TaxPolicy, RewardEngine and Thermostat addresses; those components are intentionally absent here. A future production release requires a reviewed deployment-specific inventory and its strict validation, in addition to signing and commissioning. This source update does not relax required-address or warning gates to make that production workflow pass.

You can use the English welcome guide, French guide, saved job drafts and local SUCCESSOR Ω experiences now within their documented limits. The previously merged garden-club example in PR #3923 is included in rc.5, alongside the rc.4 dependency and storage-credential repairs and the merged shared-token directory and SUCCESSOR Ω workshop (#3926 and #3927). Existing demos and flowcharts are retained.

For a new, separately approved deployment, use the Hardhat guide. To investigate this existing deployment, begin with its preserved evidence and addresses above; the checked-in generic configuration templates are not a command to deploy again.