Optimization Flow
Proof & Verification
How proof records are created, stored, surfaced in the UI, and verified by a reviewer.
Primary verifier view
History + proof modal
Explorer base
https://chainscan-galileo.0g.ai
Registry mode
ProofRegistry can be written on the configured testnet path
What the proof package contains
The stored decision payload includes current APY, optimized APY, estimated gain, recommendation, confidence score, and reasoning text when available.
After a storage write succeeds, the app pairs that decision payload with transaction metadata such as storage tx hash, timestamp, block number when available, wallet address, and optional ProofRegistry metadata.
How to read tx hash, storage ID, and explorer links
How history and verification work
History is the proof ledger view for the current runtime store. It summarizes runs, shows the newest proof rows, and exposes a judge-friendly verification summary.
The proof modal prefers live stored proof data from `/api/0g/proof`; if no live record exists yet, it falls back to a generated placeholder so the UI remains explorable. That fallback is useful for layout testing, but it should not be presented as a real proof record.
- Use History to show how proof entries accumulate across runs.
- Use the proof modal when you want to focus on one record and copy tx hash or storage ID.
- Use explorer links when the reviewer wants an external source of truth.
How ProofRegistry works in this app
When a ProofRegistry address is configured for the active network, the storage route attempts a second write after the storage upload. That contract write records the proof reference and APY basis points into the registry contract.
The stored proof record is then enriched with registry address, registry tx hash, explorer link, and proof ID when the emitted event is available.
ProofRegistry write intent
textrecordProof(cid_or_rootHash, rootHash, storageTxHash, currentApyBps, optimizedApyBps)