Secure, traceable records: where blockchain belongs and where it does not

Anyone who has reviewed an environmental study knows the scene. The final spreadsheet shows one number, the PDF shows another, and nobody knows which of the two is the real one. A field reading was corrected over the phone and the file still holds the old value. Someone opened the document, changed a coordinate, saved over it and closed it. There is no record of who did it, when, or why.

It is worth starting with the problem, without technical terms. Think of an ordinary spreadsheet. It holds one number per cell and nothing else. So anyone who has the file can delete yesterday's number, type another one in its place, save and close. The earlier number disappears. No mark remains of who touched it, on which day they touched it, or what the value was before. The spreadsheet holds no memory of the past: it shows only what is written now.

ecbyts exists to close that gap. It does four things, described below with everyday examples: it keeps every change in a pen-only record book, seals every package with a digital seal, keeps each company's data in its own vault, and ties every number to the place, the moment, the method and the rule that produced it.

And there is one topic almost everyone talks about and few separate honestly: blockchain. In this article the word appears in two very different situations. In one of them, the chain of seals already works inside the ecbyts key itself. In the other, sending the seal to a public network, it is a plan for the future — and that is stated plainly further down.

What goes wrong today

Three failures show up in almost every environmental workflow built on a spreadsheet and a shared folder:

1. Edits without history. The spreadsheet shows the state of now and nothing else. The previous value, who changed it and the reason are lost the instant someone saves over it.
2. Versions that do not match. The PDF sent to the agency came from a table that changed afterwards. Both documents exist, both look official, and there is no link between them that anyone can check.
3. Field readings changed with no trace. A measurement is adjusted after the campaign and nothing indicates that the number recorded before was different.

In an audit, the question that stalls the process is always the same: how do you prove this number is the same one recorded that day? The honest answer, under today's model, is: by trusting whoever holds the file. That is not proof, it is an agreement between the parties.

What ecbyts does at the storage layer

ecbyts treats every model package as a closed document with its own identity. There are four mechanisms, and each one solves a different part of the problem.

A pen-only record book, with no eraser

The system's audit trail only grows. It works like a cash book where you only ever write in pen: nothing is erased and no line is rewritten. If a number needs correcting, the correction enters as a new line underneath, stating what changed, who changed it, at what moment and for what reason. The old line stays there, visible.

That changes the nature of the question. Instead of "do you swear you did not touch it?", the conversation becomes "show the book". If someone changed a record, it shows. If nobody changed it, that shows too, because silence is recorded.

A digital seal on every package

Every exported model package receives a digital seal: a code generated from the package's entire content. It works like a mathematical barcode for the document. The same content always produces the same code, and changing a single letter or a single decimal place changes the code completely, on the spot.

The detail that matters is this: the seal is computed over the content of the package, not over the image of the PDF. That is why two versions can be compared without reading them visually, passage by passage. Generating the seal of both files and comparing is enough: same seal means exactly the same content; different seal means something changed. For anyone who wants the technical reference, that seal is the fingerprint known as SHA-256.

There are four package types. The letter states only how the package is assembled and closed, not what kind of data it holds. To make sense of it, think of four ways to close and send a document:

• Package A — the simple package. This is the basic form: the model content is organised, compressed and closed, with an integrity check that only verifies whether the data arrived whole. It is the form used to store and open the model day to day.
• Package B — the chained package. This is the reinforced form. It carries four elements of its own: a short code that identifies that key (the key identifier); the seal of the previous version, which builds a chain of versions where each package points at the one before it; an index of every item in the model, showing exactly which item changed without having to re-read the whole model (the technical reference is a verification tree, or Merkle); and the digital signature of whoever issued the package, which works like a personal signature that nobody can copy onto another document.
• Package C — the compressed package. This is the version optimised to take up less space, used when there is a size limit for sending or storing.
• Package D — the locked package. This is the version closed with a key, for when only authorised people may open the content. Encryption comes in here. Sending this type of package is optional and is only switched on when an institution decides to use that resource.

Back to the main image: inside the chained package, the chain of seals is built and checked in the browser of whoever exports, with no need for the internet. Each version carries the seal of the one before it; the first one carries the start mark. Changing an old version breaks the chain, and the check reports at which link the chain broke. Every number is also tied to the personal signature of whoever issued it: touching the content invalidates the signature. It is like a notary's seal that tears if anyone changes a comma in the document.

What already runs today and what is still a plan

It is worth separating the layers, because the difference is large:

• Already working today, inside the ecbyts key itself and on the platform server: the chain of seals between versions, the index of model items and the digital signature of whoever issued it, plus the seal record on the server.
• Not switched on yet: sending any information to an external public network, of the cryptocurrency kind, such as Ethereum or Polygon. In the database, the field that flags that use is off. The environmental credits are also still at the design stage, with no existence inside the app.

A separate vault per company

Each company sees only its own data. The important point is where that separation is enforced: at the door of the database itself, and not only on the system's screen. The question "may this person see this row?" is answered by the database on every query, not by the good will of the program that issued the query.

The practical difference is large. A new report, a badly written query or a forgotten request somewhere in the system does not leak another company's data, because the lock does not depend on who wrote the query. It follows the same logic as the visibility levels used when reading the ECBYTS seal: whoever is not authorised receives only what the rule allows, and every access is logged.

Every number tied to the place, the moment, the method and the rule

An environmental number on its own says nothing. It only means something together with four pieces of information: where and when it was measured, inside which sampling campaign, by which analytical method, and under which rule it was interpreted.

In ecbyts, that link is stored as part of the data, not as a footnote. Changing the analytical method of a measurement, or reinterpreting a result under another version of a rule, does not rewrite the old record: it creates a new link, and the previous link stays available for consultation. The figure below shows how the result, the rule and the responsible parties appear together in a demonstration model.

Where blockchain comes in

If you have never heard of blockchain, the truest image is this: a shared notary office, with many copies spread around, where every new page carries the seal of the page before it. To change an old page you would have to redo every following page in all of those copies. In practice, that makes the past too expensive to falsify.

ecbyts already applies that same chain of seals in two places: inside each chained-type key (package B) and on the platform server. And it does so without sending anything to public cryptocurrency networks. That chain is what sustains the check between versions, and it is what runs in production today.

• The chain of seals — already working today. Each version of the package carries the seal of the previous version, the index showing which item changed, and the digital signature of whoever issued it. The seal of the closed state is also recorded on the server and in the audit trails that only grow.
• Sending the seal to a public network — not yet. Today the app sends nothing to a public network such as Ethereum or Polygon, and the database field that flags that use is off. That sending is the next step, not yet switched on. It serves one specific case: proving that a piece of information existed on a certain date, in a way that convinces someone who trusts neither ecbyts nor the data owner.
• Environmental credits on a public network — design stage. The environmental credit design anticipates that kind of transfer in the future. It is at the specification stage, not live, and nothing that exists today depends on it to work.

In short, honestly: the proof ecbyts delivers today is the chain of seals, the item index and the digital signature, together with the seal recorded immutably on the server. That is already enough to check, inside the platform, that a number has not changed. Sending to the public network is the next step, planned and still switched off.

When that sending is switched on, the only thing that leaves the platform is the seal code — and never the data. That code is a number that means nothing to anyone who does not hold the original file: without the model in hand, it opens nothing and reveals nothing of what is inside. It is the same principle as a luggage control tag: the tag proves the suitcase is the same one, but it does not show what is inside.

And it settles one question only, which is a real question: proving that a piece of information existed on a certain date and has not changed since, in a way anyone can check, even without trusting the platform. In that scenario, three codes go to the public network: the code of the model state at the moment it was closed, the code of the ECBYTS seal issued over that state, and the code of the environmental credits once they start to exist in the app.

What that public check guarantees is a balance of power: neither the data owner nor the platform itself can rewrite the past in silence. If the package content changes later, the recomputed seal no longer matches the published seal, and that difference is public and checkable by any party — including by someone who does not trust ecbyts.

What that sending does not do, and it matters not to sell the opposite:

• it does not validate whether the data is correct, whether the method is adequate or whether the number makes sense;
• it does not replace the technical responsibility of whoever signs;
• it does not attest legal compliance and does not replace an opinion from an environmental agency;
• it does not stop anyone from publishing wrong data. It only proves that the wrong data is the same as always, and since when.

One more honest note about the design, and it holds for both moments. Today, checking that the content has not changed is done in the browser itself, recomputing the seal and verifying the chain and the signature: that depends on no network at all. Once sending to a public network is switched on, the proof of the date will depend on that external network. If the service is offline at that moment, the package remains valid and checkable through the local seal, but it has no public date proof until the sending is completed. The system says "not yet recorded on a public network" in that case, never "recorded".

Where blockchain does NOT need to enter

The right question is not "can this go on a blockchain?", but "what gains anything from being recorded out there?". Sending the data itself to a public network would be worse on three fronts: every operation costs money, every piece of data has to travel across the network, and control over sensitive information is lost. Raw environmental data carries exact coordinates, threatened species, landowner documents and third-party information. None of that has a reason to circulate outside the controlled environment.

What goes to the network is the seal, and only the seal. And there are two cases where even that does not help:

• Who may see. Blockchain is not access control. Who sees what is still decided in the database, with the separate vault per company and the lock per row.
• Analytical quality. Ensuring the sampling followed the procedure and the laboratory worked within quality control is a job for method and laboratory. No distributed network replaces that.

The practical criterion is this: if the doubt is "who may see", it is settled in the database. If the doubt is "did this exist on that date", it is settled with the published seal. If the doubt is "is this number right", neither one settles it — the technical and analytical chain that produced the number does.

Privacy and data protection

The design was built so that the public layer never receives personal or sensitive data at any moment.

• What already goes to the server, today: only the seal code, the date and the time, in the seal record and in the audit trails that only grow. A seal code does not allow the original content to be reconstructed.
• What goes to the public network, once sending is switched on: only the seal code, the date and the time. Nothing beyond that.
• What never goes, in either case: raw data, exact coordinates, attachments, documents, personal names and any data subject identifier.
• What stays under the subject's control: the level of detail of access. The data owner decides what each recipient sees, and exact, approximate or hidden location is their choice, not a hidden platform default.

It is worth explaining why the seal code is not personal data in practice. It is a one-way street: from the content you reach the code, but from the code you do not return to the content. It works like a verification seal. Whoever holds the original file recomputes the code and compares. Whoever does not hold the file gets nothing from the code. That is why this design is compatible with the rule of collecting as little information as possible: what is exposed is the proof that nothing changed, not the data.

The data subject keeps, at any time and at no cost, the right to hide the name and documents associated with an attestation, and withdrawing consent applies to subsequent accesses, without erasing the history of those who already accessed within the authorization. Withdrawing does not rewrite the past; it only closes the door going forward.

What this design does not solve

• It does not fix wrong data. Nothing having changed does not mean the number is right. Recording an inadequate number only makes the error permanent and traceable.
• It does not replace the report or technical responsibility. The checkable record organises the evidence; whoever signs is still the one who answers for it.
• It is not proof of legal compliance. The system organises and proves that the record has not changed and since when. Nothing beyond that.
• It does not guarantee availability forever. The check depends on the services involved and on the recording network being reachable.
• It is not an independent check of the maths. The server checks the structure, the responsible parties and the documents, but does not yet redo the calculation: the numbers are computed in the browser of whoever publishes and recorded as they arrived.

What it delivers is more modest and more useful than it sounds: it makes it impossible to rewrite the past without the difference showing up.

To explore it

The guided tour takes about 3 minutes and runs on a demonstration model, with fictional responsible parties. No step issues, charges or stores anything, and you can export a package and check the verification key right in your browser.

Practise exporting and verifying an ECBT key in the guided tour · See the other tours in the Tour Trail

For those who handle environmental data day to day: when did you last need to prove that a number had not changed since collection — and were you able to prove it?