Happened ≠ Confirmed. Only after completing the verification chain will the result enter the PoB ledger and become a long-term value input.
What the on-chain consensus confirms is the transaction sequence and state transition; what PoB confirms is “whether this thing happened as claimed in the business world.” The verification process compresses subjective narratives into auditable workflows: completeness of materials, time consistency, self-consistency of attribution, and comparison with exclusion rules (8.3).
What this page doesFive-Step Link and Proof Desk Functions
core themesBurden of proof, review, conclusion, non-repudiation filing
Reading highlightsSupplement/rejection/dispute; analogy and difference with PoW block production process
Five Steps to Verification (Workflow View)
① Event submission
Generate a unique event number for the final state, and bind Deal, Task, related nodes and statement types (financing/service/growth, etc.). Submission bears the burden of proof: any gaps in materials must be filled by the submitting party within the time limit.
② Upload evidence package
Submit contracts, on-chain references, bank/escrow paths (compliance desensitization), emails/minutes, acceptance forms, etc. according to the template. Analog to GIPS: The data should be sufficient to allow an independent party to use reasonable efforts to review the conclusion, rather than just "trust the applicant".
③ Review queue
The auditor checks: Authenticity (whether it is consistent with a third party or on the chain), Integrity (whether the final state is closed), Time Sequence (whether it is backdated), Attribution Boundary (whether it conflicts with 8.5), Exclusion Rules (whether it falls into 8.3). Can be combined with multi-signature, rotation or sampling audits.
④ Conclusion generation
Passed / Supplement / Rejected / Dispute Escalation. There should be a frequency and time limit for supplementary documents to prevent endless delays; objection records should be kept for disputes to avoid "passing by silence".
⑤ Filing into account
After passing, the PoB event ledger (including conclusion hash, key metadata and version) is written. This record is similar to an audited performance entry: it can serve as an anchor for subsequent settlement, reputation and revalidation.
Compared with PoW: what miners prove is computing power; what PoB audit proves is the consistency of materials and facts. Comparison with PoA: PoA trusts the certifier's identity; PoB still requires evidence package, and the reviewer's identity does not replace the material.
Proof Desk: Verification center, not network disk
Collect evidenceStructured field + attachment version; avoid losing files in the chat window and making it unauditable.
management reviewQueue priority, SLA, double review or random inspection rules can be managed.
Leave room for disputeThe reasons for objections and rulings are left behind to facilitate subsequent review and rule iteration.
Output conclusionClarify the final state: Whether to enter PoB; if it fails, it shall not enter the long-term value distribution semantics.
The place where anti-cheating lies at the process level
Cross-check: Are the on-chain time, third-party email domain name, and contract number consistent with public disclosures.
Mutually Exclusive Events: Only one Archived dominant chain is allowed for the same financing round and the same acceptance target, unless split by ruling.
Cooling and Frequency: Abnormally high frequency, templated materials trigger manual or algorithm-assisted review.
The verification process pushed WCN from "who has the loudest voice" to "who has the toughest materials." Without this step, PoB is no different from off-chain Excel recording credit, and is more susceptible to tampering.