How do I check that a signed agreement was not changed?

The one rule: compare against something nobody could edit later

A copy can only be checked against something that was fixed when you signed and that neither of you could change afterwards. Two copies in one person's hands prove little, because that person could have changed both. The useful question is always the same: what was fixed at signing, and who holds it?

There are three common answers: each side's own original, the record kept by the e-signature service you used, and a fingerprint written down on a known date somewhere neither of you controls. The sections below take them one at a time.

Paper: compare the two originals page by page

If you each kept a signed paper original, put the two side by side and go page by page: the wording, the numbers, the dates, any handwritten changes and the initials next to them, and the number of pages. Swapped pages and small edits to numbers are where a copy usually drifts.

If only one original exists, a scan or photo the other person received at signing, by email or text, is the next best thing, because the message carries its own date. Compare the paper with that.

A PDF from an e-signature service

Most e-signature services give you two things with the signed file. One is a completion certificate or audit trail: a page that lists the document, each signer's email, and when each person viewed and signed it. The other, on many services, is a digital seal on the PDF itself.

Open the signed PDF in a reader that supports digital signatures and look for its signature panel. When the file carries a seal, the panel says whether the document was changed after it was signed. Then compare your copy with the one the other person received, and with the copy the service still holds, if your account can download it.

Where to find the certificate and the panel differs from one service to the next, so look in your own service's help pages. Keep in mind what this check rests on: the dates and the audit trail come from the service, so anyone else takes them from the service's report.

A TrustChain agreement, step by step

On TrustChain this check is for an anchored record. Anchoring writes the record's fingerprint into a dated Polygon transaction, and only an anchored record is tamper-evident: change it and it stops matching. The public link works once both of you have signed, and it needs no account.

Steps 1 to 3 need only a browser. Step 4 needs Node.js on a computer. If you'd rather skip it, the Check a record page at trustchain.biz/verify-signature compares a fingerprint you paste with the one TrustChain's public record lists for that record ID, in your browser.

1. Open the public record. Open the record's public link, which ends in its 8-character record ID. It opens without an account, and an anchored record says it's anchored on Polygon.
2. Note the fingerprint and the transaction. Copy the fingerprint and the Anchored on date, then use View transaction on Polygonscan to open the Polygon transaction that dates it.
3. Find the same fingerprint on Polygon. On the explorer, check that the transaction succeeded and read its date. Its time can be a few seconds earlier than the record page's Anchored on time, which is when TrustChain saved the anchor. Then find the same 64 characters as the fingerprint in its input data.
4. Run the open checker. Run trustchain-verify from TrustChain's open repository on GitHub with the record ID. It reads the public record and Polygon, compares them, and prints every check it made and what the checks do not show.

Try it on the sample record

The record at trustchain.biz/verify/5c79fbb0 is a sample: TrustChain's own test record, made during development, not a customer's agreement. It is anchored on Polygon, so every step above works on it, and the open checker's own tests were recorded from it.

With Node.js 18 or newer, these three commands download the checker and run it on the sample:

1. git clone https://github.com/TRUSTCHAIN-creator-KK/trustchain-protocol.git
2. cd trustchain-protocol
3. node verify/bin/trustchain-verify.js 5c79fbb0

• trustchain-verify on GitHub: the source, every check it runs, and what a pass does not show

What the open checker checks

trustchain-verify is read-only. It makes one call to TrustChain, to the same public endpoint the record page uses, and reads everything else from public Polygon nodes. It never sends a transaction and needs no keys or account.

It ends with an exit code. 0 means every check passed and 1 means a check failed. 2 means the tool couldn't finish, for example because the network was down, and it is never a verdict on the record.

A pass means all of these held:

1. The public record lists an anchor: a fingerprint and a Polygon transaction.
2. The transaction succeeded on Polygon and went to TrustChain's anchor contract, whose code matches the source published in the repository.
3. It was sent by TrustChain's anchoring wallet. Anyone can write to the contract, so this check matters.
4. The fingerprint written in the transaction matches the one the record shows, and so does the contract's own log of it.
5. The contract still holds that fingerprint with the same time, and the block's time matches.

What a fingerprint is

A fingerprint is a short code computed from data. The same data always gives the same fingerprint, and changing one character gives a completely different one, so a match means the data behind it hasn't changed.

TrustChain's fingerprint covers the record's internal ID, its title, its terms, its amount and both account IDs. The account IDs aren't shown on any public page, so the fingerprint can't be recomputed from the agreement text alone. Putting the text into a fingerprint tool will never give you TrustChain's value.

The checker can also recompute a fingerprint from a record file that holds exactly those inputs. The TrustChain app has no button that exports that file yet, and a PDF or certificate isn't enough, because none of them contains the account IDs.

Anchoring writes more than a fingerprint: the Polygon transaction carries the fingerprint together with TrustChain's ID for the record, with two empty wallet slots. No agreement text, names or emails are written on-chain. How TrustChain stores and anchors records is described at trustchain.biz/security.

What these checks don't show

A match shows that this fingerprint was written to Polygon at that time by TrustChain's anchoring wallet, and that TrustChain's public record still reports the same one. The contract has no function to change or delete an entry. A match leaves these open, and the checker prints them every time:

1. Who the people are, or that anyone signed. Signing happens in TrustChain's app, and the signatures and their times come from TrustChain's own records.
2. That the 8-character record ID belongs to this anchor, beyond TrustChain's word. That record ID isn't written on-chain (the ID written there is TrustChain's internal one, a different code); the link between them is the transaction TrustChain's public endpoint returns.
3. What the fingerprint was made from, unless you have the record file, which the app can't export yet.
4. That the terms are fair, or what they mean where you live.
5. Anything about a record that was never anchored. Without an anchor there's no public fingerprint, and the record rests on TrustChain's own timestamped audit trail.

When the copies don't match

Don't throw either copy away, and don't edit one to match the other. Keep both exactly as they are, write down when and how you noticed the difference, and keep the messages each copy came with.

Then compare each copy with whatever was fixed at signing: the other original, the service's certificate, or the anchored fingerprint. A difference you can point to, with dates, is where the next conversation starts. If it turns into an argument about what was agreed, this guide covers the first reply to send:

• The client says that's not what we agreed. What now?