How to Verify a Report Onchain

A tax report is only useful if the people who rely on it can trust that it is the report you meant to give them. PONSUM reports carry an ID that is built from their contents, and that ID can be anchored on Robinhood Chain. This guide explains what the ID is, what anchoring records, how to check a report and what a check does and does not prove.

The report ID

When PONSUM builds a report, it first turns the report's data into a canonical form: every field in a fixed order, amounts written out as exact decimal numbers, and no generation date. It then takes the keccak256 hash of that data. The result, a long hexadecimal string that starts with 0x, is the report ID, and it is printed in the footer of every page of the report.

Two properties make the ID useful. The same report always produces the same ID, so anyone with the report file can recompute it. And any change, even a single cent in one disposal, produces a completely different ID. Leaving the generation date out is deliberate: a report rebuilt tomorrow from the same data has the same ID as the one built today.

The report's JSON export carries the same data the ID was built from. That is why dropping the file on the verify page lets anyone recompute the ID for themselves, without having to trust a PDF or a number copied from one.

What anchoring records

Anchoring writes the report ID to the PONSUM registry contract on Robinhood Chain in a transaction. Along with the ID, the registry stores:

• the workspace the report belongs to;
• the time it was anchored;
• the tax year, the country and the cost basis method;
• the number of transactions the report covers;
• a hash of the report's wallet addresses;
• the ID of an earlier report it replaces, if there is one.

The anchoring event also records which wallet sent the transaction: the workspace itself, or an accountant the workspace granted access to. A few rules apply. The workspace needs an active plan, the report's transaction count has to fit within that plan, and each ID can be anchored only once.

Anchoring is a public, permanent record. It does not put your report's figures onchain, but it does link the report ID, its tax year and country to your workspace address, so anchor the reports you are happy to connect with that address.

Corrected reports

Mistakes happen: a missing transaction turns up, or a price needs fixing. When you anchor a corrected report, you can mark it as replacing an earlier report from the same workspace. The earlier ID stays onchain, and anyone who checks it sees that it has been superseded and which report replaced it.

A report can only be replaced once, so corrections form a simple chain from the first report to the current one. If you find another problem later, you replace the latest report, not the original.

How to check a report

1. Open Verify a report. You do not need a wallet or an account.
2. Paste the report ID from the report's footer, or drop the report's JSON export onto the page. With the file, the ID is recomputed in your browser, so you are checking the contents rather than a number someone typed.
3. Read the result: whether the ID is anchored, when, for which tax year, country and method, and whether a later report replaced it, with a link to the anchoring transaction on the Robinhood Chain explorer.

If a report has been replaced, the page links straight to the replacement so you can check that one as well.

What a check proves, and what it does not

A matching anchor proves that a report with exactly these contents existed when it was anchored, and that it has not changed since. That is valuable when a report passes between a client, an accountant and anyone else who relies on it.

It does not prove that the numbers are correct. A report is only as good as the data and the choices behind it: a missing wallet, a wrong category or a bad manual price all flow into the result, and the anchor faithfully records that result too.

An ID on its own also does not prove who produced a report. Anyone with a plan could anchor an ID they have seen before its owner does. That is why the verify page treats a dropped report file differently from a bare ID. With the file, a report only counts as a match when the anchor carries the same workspace, the same wallet list, and the same tax year, country, method and transaction count as the file. With the ID alone, the page shows the workspace that anchored it and tells you it cannot tie that anchor to a particular report's wallets.

Good habits

• Anchor when the report is final. Clear Review and check prices first, so the first anchor is the one you mean to keep.
• Share the file with the ID. Give the JSON export along with the printable report, so the person checking it can run the full comparison.
• Replace rather than start over. When you correct a report, mark it as replacing the earlier one, so anyone holding the old ID is pointed to the new report.
• Keep the transaction link. The anchoring transaction is the simplest proof of when a report was fixed in place.
• Remember what it is for. An anchor shows that a report is unchanged. Whether the report is right is still a question for its author and, where it matters, an accountant.

PONSUM is software, not tax advice. Check your local rules or ask an accountant.