QUANTUM PI FORGE · EVIDENCE RECEIPT
The evidence receipt model: one claim plus public evidence — a repository, a deployment, a contract, an AI-system claim — evaluated into one of three outcomes: ESTABLISHED, NOT ESTABLISHED, or UNKNOWN. No account, no wallet, no payment.
Not currently open: everyday/private claims cannot be submitted today. No homeowner, buyer, seller, or other everyday user can file a claim on this site right now. This page explains the receipt model and shows a sample; everyday submission may come later.
NOT A GUESS. A RECEIPT.
ESTABLISHED · NOT ESTABLISHED · UNKNOWN
No wallet · no payment · no private keys · no trust required in the operator
How a receipt works · The three outcomes · A claim is not evidence · Where verification stops
A receipt pairs one claim with the public evidence behind it. QPF checks what is actually inspectable and returns a receipt you can audit — not a verdict about you.
This section describes the model. Everyday claim submission is not currently open — see the notice at the top of this page.
1 · A CLAIM
One bounded claim plus its public evidence — a link, an address, a file.
2 · THE CHECK
QPF checks the evidence — not your character.
3 · THE RECEIPT
One of three outcomes: ESTABLISHED, NOT ESTABLISHED, UNKNOWN.
NO WALLET
Free to inspect. Nothing is signed, nothing to install.
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.
CHECK
Responses are read against stated expectations. Nothing is inferred from the claim itself.
RESULT
ESTABLISHED — with stated limits: bytecode presence only, no value, no authorization.
Same claim, same evidence, same method, every time — re-runnable from your own browser or with curl. The published record, the machine copy, and the replay commands are linked from the verification artifact.
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.
Try a free check · Reproduce or break EXT-001 · Verification artifact
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 and returns exactly one of three outcomes: ESTABLISHED, NOT ESTABLISHED, UNKNOWN.
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.
What the evidence establishes. What it does not establish. What remains unknown. No fourth outcome, no silent default.
OUTCOME 1 · ESTABLISHED
The evidence supports the claim.
The checks ran against public evidence and matched the stated expectations — with the limits of those checks written on the receipt.
OUTCOME 2 · NOT ESTABLISHED
The evidence does not support the claim.
The checks ran and the claim failed them — or the published record contradicts it. This is about the claim, never about the person who made it.
OUTCOME 3 · UNKNOWN
The evidence cannot say.
UNKNOWN is a legitimate result, not a failure and not a gap to be filled with a guess. A receipt that says UNKNOWN keeps its boundary; one that invents certainty does not.
Claimed ≠ evidence ≠ verified ≠ authorized. The receipt records what the evidence establishes — nothing more, and it never authorizes an action.
Free to check yourself: self-serve check · machine copy of a published receipt · reproduce or break EXT-001 · open gates
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 receipt.
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.