Sellat
How it works Pricing Blog
Protect My account

Logs and records

How to prove your server’s records have not been tampered with

Your logs say what happened, but you control them. If every section is sealed as it happens, anyone can check later that it is still as it was.

See the API

Private. Only each section’s fingerprint leaves your server.

Your records, your word They say what happened, but they live on your systems and your team manages them. For whoever asks for them, that is not enough.
Sealed as they happen Each section is recorded when it closes, with a date anchored on public networks that does not depend on you.
Only the fingerprint leaves Your server computes the SHA-256 fingerprint of each section and sends it through the API. The records stay where they are.

The scene

“We need the access logs from 3 to 10 March.”

It is October and an audit is asking. You have the records: your server logs who comes in, what they do and what fails, and you keep them for months. But they are yours. Your system generates them, they live on your disks and your team manages them. When you hand them over, nobody has any reason to believe they are the same ones from March, and you have no way to prove it. Unless every section was sealed when it happened, before anyone asked.

The ritual: your server does it, every few minutes

  • Create an API key from your account. That is all you configure.
  • Every few minutes, your server closes a section of its records: the accesses, operations and errors of that interval.
  • It computes the section’s SHA-256 fingerprint and sends it to Sellat’s API. The records never leave your server.
  • Sellat groups the fingerprints in a Merkle tree and anchors them on Polygon and, through OpenTimestamps, on Bitcoin. With the free account, batches close every 4 hours.
  • You keep each section next to its proof, in your usual storage.
  • When you are asked for certain dates, you hand over those sections and their proofs. Whoever receives them checks them without an account and without trusting you or Sellat.

Want to see the call? The API documentation →

What Sellat proves before an audit

Sellat proves that each section of records existed on a specific date exactly as you hand it over: change a single line and the fingerprint no longer matches. It is technical evidence anyone can check with standard tools. It does not say whether what the server recorded is true, or who is right. It says those records have not changed since they were sealed. And if anyone, from outside or inside, later touches old records, it shows.

The whole circuit

From today’s logs to the audit a few months from now.

One concrete case: your server logs who comes in, what they do and what fails. Months later, an audit asks you for the logs of some specific dates. Your server seals it all by itself, every few minutes.

  1. Every few minutes

    Your server closes a section of its logs

    Sign-ins, operations and errors from those minutes. The section is closed and sealed.

  2. Straight away

    Only the fingerprint leaves

    The server computes the section’s fingerprint and sends it through the API. The logs never leave your server. If you ask for it, the qualified (eIDAS) timestamp is added.

  3. Months later

    You are asked for the logs

    An audit, an inspection or a customer with an incident wants to see what happened on your server on some specific dates.

  4. The problem

    The logs are yours

    They say what happened, but you control them. How do you show nobody has touched them since?

  5. That same day

    You hand over the sections and their proofs

    Each section was sealed when it happened, not when you were asked. Whoever receives it checks it has not changed, without having to trust you or Sellat.

Sellat does not say whether what the server logged is true, or who is right. What it adds is that those logs existed on that date exactly as you hand them over. And if someone, from outside or inside, later touches old logs, it shows.

See the API

What you keep, and what you hand over

For each section you keep the section itself and its proof. The API also gives you its evidence package: the proof, the certificate, the public references on Polygon and Bitcoin and the instructions to check it all. It is what you hand over with the records. Whoever receives it computes the section’s fingerprint with sha256sum and compares it with the proof using sellat-verify, Sellat’s open-source verifier.

A log on your server can be edited. A sealed one shows if it changes.

Rotating, compressing and archiving records is normal, and whoever has access to the server can edit them. That is why, before a third party, your logs are worth what your word is worth. A fingerprint anchored on public networks when the section closed is controlled by nobody: not you, not your team, not Sellat.

Inside the package

This is what you hand over when you are asked for the logs.

For every sealed section, Sellat prepares a ZIP that can be checked with tools that are not ours. It is the real list of files: the same module that builds the package produces it.

Open the package Close the package
  • original/<archivo> With custody

    The log section, byte for byte

    Only if you switch custody on: through the API only the fingerprint is sent. Without custody you keep the log yourself, and the proof works just the same with your copy.

  • certificado-<id>.pdf Always

    The readable certificate

    The PDF you show a person or attach to a filing. It is informative: what is really checked is the log, not the PDF.

  • proof.json Once the batch is anchored

    The portable proof

    The section’s fingerprint, its Merkle path, the batch root and the public transaction that records it. It is the piece that lets anyone check everything without Sellat.

  • sello-cualificado-<id>.tsr With a qualified seal

    The qualified seal

    The RFC 3161 response from the qualified timestamping authority, exactly as it was issued. This is the file that fixes the date under eIDAS.

  • autoridad-sellado.pem With a qualified seal

    Who signed the seal

    That authority signing certificate, with its SHA-256 written into the README. It travels inside so the check works offline and nobody has to go looking for it.

  • anclaje-bitcoin.ots Once the batch is anchored

    The Bitcoin anchor

    The OpenTimestamps proof of the batch root. It may still be waiting for a block: it is a valid file and whoever receives it can upgrade it themselves.

  • LEEME.txt / README.txt Always

    The instructions, in two languages

    What each file is, what it proves and what it does not, and the exact commands to check it. In Spanish and English, so an expert or a lawyer never has to ask you anything.

The seal is signed by FNMT-RCM, not by Sellat.

Sellat is not the party attesting the time. The qualified seal is issued by a qualified timestamping authority of the FNMT-RCM, and its signing certificate travels inside your package. We are the intermediary that joins your fingerprint to that seal and hands it to you in a tidy folder.

It is checked without us and without your system.

Whoever receives it checks the date and that the log has not changed with standard tools, on their own machine. It does not depend on your database or on Sellat still existing.

The package shows that this log existed on that date and has not been modified. It does not show that what it says is true, or that the server logged everything.

The section is sealed when it happens. Not the day you are asked for it.

Create your API key from your account and seal the first section today. The documentation has the full call.

See the API

Frequently asked questions

Before you ask.

Do my records leave my server?

No. Your system computes the SHA-256 fingerprint of each section and sends only that fingerprint. The records stay on your server, and the public networks only carry the batch root, which reveals nothing about their content.

How often should I seal?

You decide: every few minutes, every hour or every day. The shorter the section, the more precise the date of each line and the less you have to hand over when asked for specific dates.

How does whoever receives the records check them?

With two commands: sha256sum computes the section’s fingerprint, and sellat-verify, Sellat’s open-source verifier, compares it with the proof and the public references. No account needed, and no need to trust you or Sellat.

And the qualified eIDAS timestamp?

If you ask for it in the same API call, the section’s fingerprint also receives the qualified timestamp, from your account’s seals. It enjoys a legal presumption of the accuracy of the date and time and of the integrity of the data across the European Union (art. 41(2) of Regulation (EU) 910/2014).

Does Sellat say whether what my server recorded is true?

No. Sellat does not judge the content or who is right. It shows those records existed on that date exactly as you hand them over, and that they have not changed since.

How much does it cost?

The free account includes daily proofs through the API, anchored in batches every 4 hours. Each account’s limits are on the pricing page.

Log and audit-record integrity with timestamping

Proving the integrity of logs before an audit, an inspection or a customer means proving they have not been modified since they were written. The records are generated and kept by the system itself, so their value as evidence depends on something external: a date not controlled by whoever keeps them. Technical detail, in case you need it: your system computes the SHA-256 fingerprint of each section and sends it to Sellat’s API v2. Sellat groups it in a Merkle tree and anchors it on Polygon and, through OpenTimestamps, on Bitcoin. Each proof has its evidence package and is checked with sha256sum and sellat-verify, without an account and without trusting Sellat. The records never leave your server.