PoV is the gate-check
Proof-of-Verification turns physical-world evidence into a binding on-chain event. For each milestone gate, the protocol specifies which attestors are authorised, what evidence schema applies, and what quorum is required. The attestors inspect the actual goods, the actual documents, the actual movement, and sign the hash of the canonical evidence package. The PoV gate PASSes when the configured quorum of valid signatures is reached.
The settlement smart contract reads the PoV gate state and either mints the EMT or doesn’t. There is no override path. Governance cannot vote a gate open. A buyer cannot pressure a release through customer support. The seller cannot have the funds advanced as a favour. If the PoV gate has not cleared quorum, the contract reverts. No PoV, no EMT. No EMT, no funds.
This is the protocol’s answer to the trust question. In the paper-document world, a clerk decides whether a stack of paperwork matches and releases funds on that human judgement. The error rate is high (~85% of LC document presentations have first-time discrepancies). In the PoV world, machine verification reads cryptographic signatures from independent inspectors; the error rate collapses to the rate of attestor collusion, which is structurally bounded by the registry design.
What is settlement-specific about PoV
PoV runs across the EDMA protocol: settlement, energy attestations, carbon credits, RWA token minting. It is the same primitive in each case. What differs is the evidence schema and the attestor registry per use case. Energy uses meter readings signed by metering DSOs; carbon uses field reports signed by accredited verifiers; settlement uses milestone-specific evidence packages signed by inspection bodies, carriers, customs brokers, and quality assurance labs depending on the gate.
Settlement-specific behaviour: the PoV hash from each gate gets carried into the EMT that mints on PASS. This means every EMT is cryptographically bound to the specific evidence the gate cleared on. An auditor reading the chain can verify the EMT against the published evidence hash, the attestor signatures, and the contract’s acceptance of the PoV result. The trade is not just settled; it is settled against verifiable proof.
Architecture detail
PoV overview
The cross-protocol PoV consensus primitive: how it differs from Proof-of-Work and Proof-of-Stake, what it consumes (real-world evidence), what it produces (verifiable claim hashes), and where it sits in the EDMA L2 stack.
PoV Gate
The settlement-specific PoV gate implementation: how the gate evaluates attestor signatures, how quorum is configured, what happens on PASS, FAIL, or NEED_MORE, and how the gate communicates with the EMT mint function.
Attestor registry
Who can sign as an attestor. The registry per evidence type (Bureau Veritas, SGS, Intertek for inspection; Maersk, MSC, CMA CGM for shipping; customs authorities; quality-assurance labs). Slashing conditions and how attestors join, get audited, or get removed.
PoV revocation
What happens when an attestor signs incorrectly: revocation mechanics, slashing, downstream impact on already-settled EMTs (none: settlement is final), and the corrective path through dispute and variance math.
