How do I prove what was agreed?

Content, time, identity: three separate questions

Every dispute about an agreement comes down to three questions that people usually blur into one. Content: what did the text actually say? Time: did that exact text exist on the date you claim? Identity: who accepted it? A piece of evidence can answer one of these well and another not at all, and a good record answers all three rather than one.

There is a fourth question that is different in kind: enforceability, meaning what a court or arbitrator would do with the agreement. That depends on where the parties are, what kind of agreement it is and what the terms say. The first three questions are matters of fact and can be checked anywhere. The fourth is a matter of law and place. A TrustChain record is built to show the first three; TrustChain makes no claim about the fourth.

Keep the split in mind as you read the ladder below. Each rung is scored on content, time and identity only. Climbing higher does not change what the law says about your deal; it changes how much of the argument is about facts you can show rather than facts you have to assert.

1. Content: the exact wording, not a summary of it.
2. Time: that this wording existed on a specific date and was not edited afterwards.
3. Identity: that a specific person, not just an account or a phone number, accepted it.
4. Enforceability: what a court would do, which depends on place and terms and is outside what any record can settle on its own.

Rungs one to three: a verbal deal, a text thread, an email

A verbal deal is the bottom rung. It can be a real agreement, but it proves nothing on its own: there is no text to compare, no date to point to, and identity rests on the memory of the two people who now disagree. If a verbal deal is all you have, the fix is not to argue harder but to move up a rung today, which the section on having no record yet covers below.

A text or chat thread is better than nothing and worse than it feels. Content is usually there, but spread across dozens of messages, edits and 'sure, sounds good' replies that leave the final terms open to interpretation. Time is soft: a screenshot carries no proof of when it was taken, and messages can be deleted on one side. Identity is a phone number or a handle, not a person.

An email fixes part of this. An email received by the other side carries headers with timestamps added by the mail servers along the way, including the recipient's, which the sender does not control. That is the first real signal on time. Content is a single body rather than a thread, and a reply that says 'agreed' is a clear acceptance. The weaknesses: headers can be forged or stripped, mailbox contents can be edited before export, and identity is still an address rather than a verified person. An email that lays out the terms and gets an explicit 'agreed' back is the minimum worth having.

Rungs four and five: a signed PDF and an e-signature

A signed PDF, whether printed and scanned or signed with a drawn signature, gives you a single frozen document. Content is fixed on the page. Time and identity are the problem: a date typed into a PDF proves nothing about when it was made, and a scrawled signature proves nothing about who held the pen. Two versions of the same PDF can circulate and neither party can show which one was final.

An e-signature service adds an audit trail: the service records when each party clicked, from which email address and IP address, and often seals the PDF against later edits. This is a real step up on time and content. Identity is still usually an email address, and the audit trail lives on the vendor's servers, so a third party has to trust the vendor's report rather than check anything themselves. If the vendor shuts down or the account is closed, the trail can go with it.

Both rungs share one gap: the evidence is a document you hold, and its value depends on people trusting that you have not altered it. The rung above removes that dependency for content and time by giving anyone a way to check for themselves.

Rung six: a fingerprinted record with verified identities and a public anchor

The top rung answers content and time with checks a stranger can repeat, and identity with a verification step that happens before anyone can sign. On TrustChain, both parties first verify who they are with a photo ID and a selfie through SumSub, which takes about two minutes and is done once. They negotiate in an end-to-end encrypted chat, then sign the same final text. An unverified account cannot sign, so identity is checked before anything else happens.

When the text is signed, TrustChain computes its Keccak-256 fingerprint and writes a timestamped, append-only audit entry. The fingerprint is a fixed-length string that changes completely if a single character of the text changes, so anyone who has the signed text can recompute it and confirm the text is unaltered. That covers content.

For time, the fingerprint can optionally be anchored in a Polygon mainnet transaction. TrustChain's registry contract on Polygon mainnet is 0x649Bc303d15E173D95B4d379e163868b03cf5Fec. A block explorer shows when that transaction was written, and that check does not depend on TrustChain. Without an anchor, the time rests on TrustChain's own timestamped, append-only audit entry, which a third party has to take from TrustChain. Only the fingerprint goes on-chain: never the text, names or personal data. The record is tamper-evident: it does not stop anyone from editing a copy, it makes any edit show.

The public verification link opens without an account and shows the fingerprint and status, never the parties' identities. The title is shown only if the owner opted in. A third party can check the record without learning anything private about the people behind it.

1. Content: recompute the Keccak-256 hash of the signed text and compare it to the fingerprint on the record.
2. Time: if the record was anchored, open the Polygon transaction on any block explorer and read when it was written.
3. Identity: both signers passed photo ID and selfie verification before they could sign, and the timestamped audit entry records the signing.

Verify a record yourself, right now

The record below is a real public record whose owner opted in to showing its title. You do not need an account.

Notice what you did not need: an account or the parties' names. The Polygon step works without TrustChain at all, because the transaction lives on a public chain that TrustChain does not control.

1. Open https://trustchain.biz/verify/5c79fbb0. You should see registry id 5c79fbb0, the title 'Golf Clubs', status completed, and that it was anchored on Polygon on July 26, 2026.
2. Read the fingerprint: 0x2730c80122af9f7073d5b486790e0016bb0b2bc582785f84ca2c965f07877128. This is the Keccak-256 hash of the signed text. Note that the page shows no names or other party details.
3. Open polygonscan.com and search for transaction 0x8ff5cf3555849eb4d8bf5214f6982ce54906820d1ea2b9aad358d251f8086b2d. Check that it is on Polygon mainnet and dated July 26, 2026. TrustChain's registry contract is 0x649Bc303d15E173D95B4d379e163868b03cf5Fec; compare it with the addresses the explorer shows for the transaction.
4. Look for the fingerprint in the transaction's data. The fingerprint is the only thing TrustChain puts on-chain, so the same 64 hexadecimal characters shown on the verification page should be there. If they match, the text behind this record existed in exactly this form on that date.
5. If you were a party and held the signed text, the last step would be to run it through any Keccak-256 tool and compare the result to the fingerprint. A match shows the text is the one that was signed; a mismatch shows it was changed.

What to do when you have no record yet

Most disputes start with no record at all: a verbal deal, a half-finished thread, a PDF nobody signed. The goal is to get one fixed version and a dated acceptance as early as you can, before positions harden.

Write a dated note today. Put down what was agreed, when, by whom and what has been done so far, in your own words, and email it to yourself so it carries a server timestamp. This is weak evidence, but it is contemporaneous, and it beats reconstructing everything from memory a year later.

Get the other side to confirm in writing. Send a short, neutral summary: 'To confirm what we discussed: scope X, price Y, done by Z. Reply to confirm.' A one-word 'confirmed' reply turns a verbal deal into a rung-three email. Do not bury the summary in a long complaint; make the confirmation easy to give.

Freeze the version. Once you have a text both sides accept, stop editing it. Put it into a record that fixes the wording and the date, whether that is a sealed e-signature or a fingerprinted record with a public anchor. If terms change later, make a new record rather than editing the old one, so there is never a question of which version was in force when.

1. Today: write a dated note of what was agreed and email it to yourself.
2. This week: send the other side a plain summary and ask for a written 'confirmed'.
3. Before more work or money changes hands: freeze the final text in a record that fixes content and date.
4. For every change after that: a new record, never an edit to the old one.

Enforceability is a different question

Nothing on this page tells you what a court would do with your agreement, and no static page can. Whether an agreement is enforceable depends on where the parties are and what they agreed. Some kinds of agreements need particular forms, some terms are not allowed in some places, and the rules change. TrustChain makes no claim about any of that.

What a strong record does is narrow the argument. Instead of two people disputing what was said, when and by whom, the dispute is about what the agreed text means and what the law makes of it. The cryptographic parts, the fingerprint and the anchor, verify anywhere; what happens next depends on place and terms.

If money or a lot of work is at stake, talk to a lawyer where you are. Bring the record: it saves the lawyer from reconstructing the facts and lets them spend the time on the law.

What a TrustChain record contains, and what it does not

The agreement text is stored on TrustChain's servers. That is what lets TrustChain compute the fingerprint and serve the record, the certificate and the PDF to the parties. Only the fingerprint goes on-chain; never text, names or personal data. The negotiation chat is end-to-end encrypted, and TrustChain cannot read it.

Your own record, certificate and PDF are free on every plan. The Free plan needs no card and includes one protected agreement and three AI Advisor requests a month; an extra agreement or an extra Polygon anchor costs $1 each, one-off, and anchors require a verified identity. Pro is $19 a month for 20 agreements, 20 anchors and 50 AI requests; Elite is $49 a month for 100 agreements, 100 anchors and 300 AI requests. Plans are monthly and cancel any time.

The AI Advisor explains clauses in plain language. For the BC Builders Lien Act it answers from the statute text, quotes the section, states the consolidation date and links the official BC Laws source; for everything else it gives general guidance and says so. It is a reading aid, not a lawyer.

TrustChain is built by a solo founder in Vancouver, BC and operated by Kirillskiy Construction Ltd., Surrey, BC.