QUANTUM PI FORGE · PUBLIC VERIFICATION
Give QPF one bounded claim and the public evidence behind it — a repository, a deployment, a contract, an AI-system claim, a launch.
Three answers, kept apart:
what the evidence establishes ·
what it does not establish ·
what remains unknown
No wallet · no payment · no private keys · no trust required in the operator
One worked example · A claim is not evidence · What QPF verifies · Where verification stops
Not a promise — a published check you can re-run in about a minute from your own browser or from
curl. Same claim, same evidence, same method, every time.
CLAIM
On chain 16661, code exists at the address QPF publishes as its OINIO token.
EVIDENCE
Public RPC responses: eth_chainId, eth_getCode, eth_call on the published pair.
VERIFICATION
Responses are read against stated expectations. Nothing is inferred from the claim itself.
AUTHORIZATION
Not produced here. A pass authorizes no action — see the boundary.
This is the published record with its stamp — not a reading taken from your screen. The button below re-runs the same three checks now, and the sealed first-pair state beneath it is the record that run is compared against.
What the evidence establishes
0x4115 (16661) — the network QPF names.0x75995EC0fdf881189850aeD864cB3f43c0DFCb58 — a contract is deployed there, not an empty address.0/0 — a pair exists with no liquidity seeded.What it does not establish
What remains unknown
Who deployed it, what the bytecode does beyond being present, and whether your check at your block height still passes. Unknown stays unknown — it is not filled in.
Your browser calls the public RPC directly — three claim-bearing reads, plus block height and address balance for context. Nothing is sent to QPF, nothing is signed, no account is involved.
RPC https://evmrpc.0g.ai · expected chain 0x4115 (16661) · reserves are read from the published pair 0x2067319D…18AaeE
# 1 — which network is this?
curl -s -X POST https://evmrpc.0g.ai -H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
# expect 0x4115
# 2 — is there code at the claimed address?
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"]}'
# longer than "0x" → code present · "0x" → nothing deployed there
# 3 — has liquidity been added to the published pair?
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"]}'
# all-zero words → reserves 0/0, liquidity not added
SEALED RECORD — HISTORICAL STATE, NOT A CURRENT READING
stamped 2026-06-16T02:14:13.587Z · observed at block 36239555 · the baseline this run is compared against
status FIRST_PAIR_FINAL_STATE_SEALED (PAIR_EXISTS_ZERO_RESERVES)Two different things sit on this page and are never merged into one "current status" number: the sealed record above (historical, stamped 2026-06-16) and the live observation you produce below (current, one endpoint, one moment). A difference between them is a finding to publish, not a detail to edit away. The sealed record and its receipt are linked from the verification artifact.
PUBLISHED IDENTITIES — live_rpc BLOCK OF THE ARTIFACT
result qpfv0:ed6743e31e634732313a952d35b47d3d312f98b3d3551d41b999edce208665c4
package qpfpkg0:e341b75ef3e2c05850df7670b2340f608fa67159e000b27b9c29011020bf4735
artifact qpfv0:bedcd4e2abc96a0433fee195ffe5237d452c690f9c7b76285ee2a3b8a008988d
REPRODUCE IT, DON'T QUOTE IT
The artifact, receipts, and replay commands are published. If the published evidence reproduces, you have evidence. If it does not, you have a break — and that is useful too.
Verification artifact · machine copy · reproduce or break EXT-001
Most trust failures happen because three different things get collapsed into one.
A deployment existing
does not prove what its documentation says it does.
A repository existing
does not prove the published system matches it.
A model producing an answer
does not prove the claim being made about that system.
A verification receipt records what the evidence establishes.
It does not promote that result into a wider claim.
It does not authorize an action.
The arrow stops where the evidence stops. Everything after it is a separate decision, made by a named human, in the open.
Five claim types, each with a bounded question and a stated evidence requirement. Outside the stated scope the answer stays UNKNOWN.
REPOSITORY CLAIMS
Does the published source contain what is being claimed?
Commit, file, and hash level checks — not a readme quote.
DEPLOYMENT CLAIMS
Does the deployed system correspond to the stated release or artifact?
Bytecode and artifact correspondence against a pinned build, e.g. live-rpc-correspondence-v1.json.
CONTRACT CLAIMS
What is actually deployed on-chain?
Published address inventory plus its own verification report — presence, chain, state.
AI-SYSTEM CLAIMS
What can the available evidence establish about the system?
Behaviour, identity, and output claims — with the channel each verdict depends on named.
LAUNCH READINESS
What has been checked, what is blocked, what still needs authorization?
A completeness pass, not a launch cheerleader.
NOT OFFERED
Assurance, ratings, or a badge.
No security guarantee, no investment view, no verdict on things the evidence cannot reach.
QPF publishes source, evidence, and the verification path — including its own. Inspect it, re-run it, or try to break it. QPF is held to the same standard as every claim it checks.
GITHUB
Public source
Verification code, frozen packages, decision records, and the issue tracker where breaks land.
DEPLOYED ADDRESSES
Public inventory
Every published address with its own verification report and stated limits.
ATTACK KIT
Try to break EXT-001
Frozen package, published expected result, one command. A pass and a mismatch are both publishable outcomes.
RUN IT FROM A CLONE — NO ACCOUNT, NO WALLET, NO PERMISSION
git clone https://github.com/onenoly1010/Quantum-pi-forge cd Quantum-pi-forge && npm install npm run verify:independent
If the published evidence reproduces, you have evidence. If it does not, you have a break. Either result is useful, and either one gets filed — breaks are published, not buried.
Superseded offers and withdrawn prices stay published and verifiable rather than being rewritten — see the open gates record.
You do not need to understand QPF first. You do not need a wallet, a token, or a relationship with the operator. Bring one public claim and the evidence needed to inspect it.
FREE · ~5 MINUTES
Try a verification
Run the network and code-presence check on any address, in this browser or with curl. No account, nothing installed.
FREE · REPRODUCIBLE
Open the proof
Re-run the frozen EXT-001 package and compare against the published expected identities.
FREE · IN-BROWSER
Watch an AI identity get formed and recorded
A passkey signs the authorization; the returned record carries explicit limits — no economic authority, no autonomous execution, no network authority. If attestation cannot complete, it says so rather than inventing a transaction.
A DIFFERENT DOOR
Create a counterpart
Creation is not verification. This is the door for building on the baseline, not for checking a claim.
Open gates — what is open, what is not · Meet a co-creator · For builders · New here
Request a bounded verification review. You receive the claim, the evidence, the checks run, the findings, and the limits — in one inspectable package, published either way.
Self-serve inspection is free. Paid work is one flat fee per claim — CAD $250, priority scheduling CAD $100 — and it is the same for ESTABLISHED, FAILED and UNKNOWN. Current terms, receipt template and refund condition on the open offer (machine copy). It is an offer, not a sale: no sale has been established at any price.
QPF can establish what the evidence supports. It does not decide that the next irreversible action should happen. That boundary stays explicit, on every page and in every package.
Liveness does not imply authority. A running endpoint, a live contract, or a passing build proves operation, not permission.
Verification does not imply authorization. A receipt is a record of what was checked, never a green light.
Unknown remains unknown. A gap is data, not a licence to fill it with a guess that reads like a finding.
QPF'S OWN STATE, AS PUBLISHED
| Technical capability | ESTABLISHED |
| External adoption | NOT ESTABLISHED |
| Customer | NOT ESTABLISHED |
| Real revenue | NOT ESTABLISHED |
Source: open-gates-v1.json. Reporting a state is not a claim of market, customers, or revenue.
STILL NOT AUTHORIZED
Deployment places code on-chain; activation requires a separate authorization. Published status record: verification-status-v1.json.
As published 2026-09-28: Phase 8.5 Round 1 is WINDOW_EXPIRED — 0/3 eligible reports, hard close 2026-08-29 passed without quorum, so no "externally settled" claim is made for that round — while public mint, liquidity and yield/staking remain NOT_AUTHORIZED.