Deployed Addresses

System state (public summary)

Deployment ≠ Activation. Deployment places verified code on-chain. Activation requires separate governance authorization.

Purpose of this page

This page is the canonical reference for “What is deployed?” Each entry follows a claim → evidence → verification structure so that readers can independently validate deployed components.

The public site is intended to reflect the project’s documented verification model: the live site, this deployment inventory, and supporting evidence (explorers, registry digests, source repo, receipts) are aligned so reviewers can inspect what is deployed and follow the evidence without that being interpreted as an announcement of economic activation. Minting, liquidity, and related features remain subject to separate authorization—and are currently intentionally disabled.

What a reviewer can do here:

1. Understand the architecture — linked overview & docs
2. See what is actually deployed — inventory entries below
3. Inspect supporting evidence — explorers, registry, txs, receipts
4. Reproduce or verify findings — verification portal & builder path
5. Read operational & governance status — what is enabled vs what decisions remain

Keep these states separate:

State	Meaning
Technical	What exists and can be verified (addresses, bytecode, explorers)
Operational	What is currently enabled (mint/liquidity disabled by design)
Governance	What decisions remain before any economic functionality is authorized

Communication principles

• Process over conclusion. Show how results are obtained (claim → evidence → verification) instead of asking readers to accept them.
• Observables over narrative. Prefer deployed artifacts, repository history, transactions, and reproducible evidence over descriptive claims.
• Deployment inventory is not economic readiness. Publishing what is deployed is distinct from authorizing economic functionality. A deployment inventory is not an economic activation announcement.

Technical state (what exists) · operational state (what is enabled) · governance state (what is authorized) remain separate.

0G Aristotle Mainnet

OINIO Token Code live

OINIO Model Registry Code live

Heartbeat Monitor Code live

ForgeRegistry Code live

DEX Factory Code live

DEX Router Code live

DEX Pair W0G/USDC.e Empty pool

Safe Guardian Code live

OINIO Token (secondary listing) Code live

1. Confirm network

curl -s -X POST https://evmrpc.0g.ai \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
# expect: "result":"0x4115"  (decimal 16661)

2. Confirm code at primary token

curl -s -X POST https://evmrpc.0g.ai \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0x75995EC0fdf881189850aeD864cB3f43c0DFCb58","latest"]}'
# expect: result longer than "0x"

3. Confirm pair reserves empty

curl -s -X POST https://evmrpc.0g.ai \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x2067319DC61CCdCdCDc13ABe0c72Ea3D7318AaeE","data":"0x0902f1ac"},"latest"]}'
# expect: all-zero reserves (liquidity NOT AUTHORIZED)

4. File a report

Open a GitHub issue titled External verification: YYYY-MM-DD using the template. Honest drift (docs ≠ chain) is a successful verification event.

Optional (clone repo): npm run verify:public-portal · local ops cockpit (verify only): npm run ops:ai-cockpit · Full guide: BUILDER_QUICKSTART · mint path package (NO-GO checklist): PUBLIC_MINT_EXECUTION_PATH_PACKAGE_V1

Question this portal answers: Can a stranger verify QPF, understand what is disabled and why, and contribute without trust? It does not open mint, liquidity, staking, or yield.
Expected after verify: mint / liquidity / economic launch remain NOT AUTHORIZED. Multi-report consensus is evidence for later governance review — not an auto-unlock.