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 time by giving anyone a way to check the date for themselves, and it ties the content to a fingerprint fixed on that date.

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

The top rung answers time with a check a stranger can repeat, content with a fingerprint fixed at that time, and identity with a verification step that happens before anyone can sign. On TrustChain, both parties verify who they are with a photo ID and a selfie through Sumsub before signing, and a registered account does this once. Both sign the same final text, fixed when the agreement was created; once both have accounts they can also talk in an end-to-end encrypted chat. An unverified account cannot sign, so no signature exists without a verified identity behind it.

When each party signs, TrustChain writes a timestamped audit entry that browsers and apps can't edit. When the signed agreement is anchored, TrustChain computes a Keccak-256 fingerprint of the record: its internal ID, title, terms, amount and the two parties' account IDs. Change a single character and the fingerprint changes completely. Because it includes those internal IDs, the fingerprint cannot be recomputed from the agreement text alone. If the stored record changed after anchoring, it would no longer match the fingerprint on Polygon. That covers content.

For time, the record can optionally be anchored in a Polygon mainnet transaction. TrustChain's smart 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 audit entry, which browsers and apps can't edit and which a third party has to take from TrustChain. 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. Once anchored, the record is tamper-evident: it does not stop anyone from editing a copy, but a change to the anchored record would no longer match its fingerprint.

The public link opens without an account once both parties have signed. It shows the record's status and, if it was anchored, its fingerprint, never the parties' identities. The title is shown only on agreements created on the Elite plan. Someone else can check the record without learning anything private about the people behind it.

1. Content: the fingerprint on the public record page matches the one in the Polygon transaction, and any change to the record after anchoring would produce a different fingerprint.
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. These are TrustChain's own records, so a stranger takes them from TrustChain.

• How TrustChain records a signature: what each audit entry records, and who can and can't change it

Check a record yourself, right now

The record below is a sample: TrustChain's own test record, not a customer's agreement. It was created on the Elite plan, which is why its title is shown, and signed before identity checks became mandatory, so use it to check the fingerprint and the date. 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 record ID 5c79fbb0, the title 'Golf Clubs', and an 'Anchored on' date of July 26, 2026.
2. Read the fingerprint: 0x2730c80122af9f7073d5b486790e0016bb0b2bc582785f84ca2c965f07877128. This is the Keccak-256 fingerprint TrustChain computed from the signed record when it was anchored. 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 smart contract is 0x649Bc303d15E173D95B4d379e163868b03cf5Fec; compare it with the addresses the explorer shows for the transaction.
4. Look for the fingerprint in the transaction's input data. The same 64 hexadecimal characters shown on the public record page should be there, next to TrustChain's internal record ID. If they match, this fingerprint was written to Polygon on that date, and any later change to the record behind it would produce a different fingerprint.
5. One check you cannot run yourself: hashing the agreement text will not reproduce this fingerprint, because TrustChain hashes the title, terms and amount together with the record's internal ID and the parties' account IDs, and the account IDs are not public.

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 part, an anchored fingerprint and its date, can be checked 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. If the record is anchored, the fingerprint and an internal record ID go on-chain, with two empty wallet slots; never the text, names, emails or amounts. The negotiation chat is end-to-end encrypted, and TrustChain can't read the messages.

Your own record, certificate and PDF are free on every plan. The Free plan needs no card and includes 1 agreement and 3 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 Advisor requests; Elite is $49 a month for 100 agreements, 100 anchors and 300 AI Advisor 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, Kirill Korolyov, in Surrey, Metro Vancouver, and operated by his company, Kirillskiy Construction Ltd., incorporated in British Columbia.