Could you prove which terms and conditions a customer accepted two years ago?

To reconstruct an acceptance on solid ground, keeping a simple “yes” is not enough.

At the very least, you need to keep:

• when the acceptance happened;
• which user did it;
• which specific version of the terms was in force;
• which language they were shown in;
• and exactly what those terms said.

The problem appears when all of that lives only inside the company’s own systems.

If a dispute arises years later, a reasonable question follows:

how can anyone check that the record was not changed afterwards?

Is storing the acceptance in a database enough?

A database is necessary to run an application, but as evidence it has an obvious limitation: it is controlled by the same company that needs to prove what happened.

A record may say:

User X accepted terms v2.3 on 28 September 2026.

But that information, on its own, does not let a third party check whether the record really existed at that moment or was altered later.

That is why at Sellat we keep two things apart:

the application’s internal record, and the external proof of that record.

How do you know exactly which version of the terms a user accepted?

Storing “accepted version 2.3” is not enough either if, a few years from now, nobody can tell what version 2.3 actually said.

That is why every version of Sellat’s terms is kept as a separate document. When we publish a new version, the previous one does not disappear: it can still be downloaded exactly as it was.

That file holds the exact content that was in force at the time.

So an acceptance can be tied to a specific document, not just to a version number stored in a database.

How do you prove the terms were not changed afterwards?

This is where the document’s fingerprint comes in.

Every record and every version of the terms gets a SHA-256 hash.

A hash works like a fingerprint: change even a small fragment of the content and the result is different.

That fingerprint is registered through Sellat and tied to external proofs.

Today Sellat uses Polygon and Bitcoin, the latter through OpenTimestamps.

That makes it possible to check later that a given fingerprint already existed, and to compare it with the document kept today.

If the document changes, its hash changes.

What does Sellat keep when someone accepts its terms?

Every time a person accepts our terms we record what is needed to identify that acceptance, including:

• the version of the terms;
• the language;
• the moment of acceptance;
• and the reference to the user.

From that data we build a record, which is sealed through Sellat’s own API.

Its fingerprint is anchored on Polygon and Bitcoin.

In other words, for our own terms we use the same proof-of-existence system we offer our customers.

Can the user verify their own acceptance?

Yes.

We did not want the evidence to exist only on our servers.

From their account, every user can download a pack with the information about their own acceptance.

The ZIP contains:

• the sealed acceptance record;
• the exact document of the terms they accepted;
• what is needed to verify the proof;
• and the instructions to check it with open tools.

The aim is for the proof to be verifiable independently.

Nobody has to rely only on what our database says.

What does this system let you check?

If, years from now, we need to review an acceptance, we can reconstruct and cross-check several things:

• when it happened, from the acceptance record;
• which version was accepted, because the record identifies the specific version;
• exactly what that version said, because the document is kept;
• whether the document is still the same, by recomputing its SHA-256 and comparing it with the registered fingerprint;
• and whether an external proof existed, through the timestamping systems Sellat uses.

So the internal database stops being the only source of truth.

How to check an acceptance in three steps

The ZIP a user downloads contains record.json (the sealed record), terms.json (the exact document of the terms) and, once anchored, the public proof of each. Anyone can check it with tools that are not ours:

1. The record is what it says it is. Compute the fingerprint of record.json (sha256sum record.json, or certutil -hashfile record.json SHA256 on Windows). That is the fingerprint the public proof certifies.
2. The terms are the ones the record names. Inside record.json, the field terms.sha256 is the fingerprint of the terms. Compute the one for terms.json: it must be the same.
3. The record existed on that date and has not changed. npx sellat-verify record.json record-proof.json checks the proof against Polygon and Bitcoin with the open-source verifier (github.com/skanthemore/sellat-verify), with no account and without relying on Sellat.

What this proves is that this exact record, naming these exact terms, existed on that date and has not been altered. What that is worth as evidence is for a judge or an arbitrator to decide, not us.

Can other companies use this?

Yes.

A company can apply the same principle whenever it needs to keep verifiable proof of what happened at a specific moment.

For example, to record:

• terms and conditions;
• the conditions of a purchase;
• accepted quotes;
• consents;
• contracts;
• deliveries;
• document versions;
• internal policies;
• or any other content whose version and date matter later on.

In those cases, the company’s system produces the record, and Sellat creates a verifiable proof tied to that content.

Today, API integrations are done together with us.

Sellat is the first customer of its own API

We could simply explain that our API records evidence.

We prefer to use it ourselves.

Every time someone accepts our terms, we create a proof with the same system we offer our customers.

Because a good way to show that a tool solves a real problem is to use it to solve that problem in your own company.

If your business needs to prove what a customer accepted, which version was in force and when it happened, write to us: we will integrate it with you on Sellat’s API.

And if your shop runs on WooCommerce, we are preparing a plugin that does all this without writing code: write to us and we will let you know when it is available.