GIWA Integrity Verification
No GIWA contract, schema UID, representative transaction, or Explorer link was found in the surveyed repositories.
Until a real contract, a real transaction, and Explorer verification exist, this is described as product vision only. Nothing on this page should be read as a working feature.
The problem it addresses
A report that can be edited after the fact, or replaced without a trace, cannot be relied on by anyone who did not produce it. A file hash alone is a weak answer: it proves that two byte sequences match, but not which revision is current, what a change was for, or whether a superseded version is still circulating.
Target design
The intent is to record, on GIWA, a non-identifying commitment to a published revision along with its state transitions — and nothing else.
Specifically, the design excludes from on-chain data:
- transaction source text
- wallet lists
- amounts
- personal information
An external consumer would then be able to check whether a given revision is the current one, without access to any of the underlying content.
The boundary of what GIWA would attest
The role of an on-chain commitment is to let an external consumer verify the integrity and current-use state of a specific revision. It does not, and could not, attest that a report's tax treatment is correct.
Conflating the two is the failure mode this page exists to prevent.
Why this fits the implemented foundation
The revision model this depends on already exists in the persistence layer — inclusion revisions, evidence bundle lineage, and supersedes relations with recorded correction reasons. See Persistence, Revision & Lineage.
What is missing is everything on the chain side: the contract, the schema, the submission path, and the verification client.
What has to be built
| Component | Needed for |
|---|---|
| Contract and schema | Recording commitments and state transitions |
| Commitment derivation | Producing a non-identifying commitment from a published revision |
| Submission path | Publishing a commitment atomically with a validated generation |
| Verification client | Letting an external consumer check current-revision state |
| Explorer evidence | A representative transaction a reviewer can inspect |
A challenge mechanism has been discussed as a later roadmap item. It is not claimed as part of V1.
Required evidence before any claim is made
- Deployed contract and schema UID
- A representative transaction with an Explorer link
- A successful verification of a valid report
- A failed verification of a tampered report
- A rejected verification of a superseded revision
- Confirmation of the boundary between personal data and on-chain payload
These are tracked in Current Limitations, and the corresponding test scenarios are in the Evaluation Plan.