How it works

Private data, public proof.

EVstring combines an ordinary, access-controlled data platform with a permissioned blockchain that stores only fingerprints and events. The result: your data stays confidential, yet anyone can check it has not been altered.

1 · The integrity pipeline

From record to proof in four steps.

Every piece of passport data follows the same path. The data itself never leaves the access-controlled side; only its fingerprint is written to the chain.

Step 1
Record stays off-chain
Specs, certificates and readings live in an access-controlled database or encrypted IPFS storage.
```
{ "passportId": "EVS-ACME-…",
  "chemistry": "NMC 811",
  "capacityKWh": 75 }
```
Step 2
Fingerprint with SHA-256
A 256-bit hash is computed. Change one byte of the record and the fingerprint changes completely.
bdfd7596 8757e492 23efdea7 06537acc…
Step 3
Anchor it in a block
Only the fingerprint is written to the permissioned chain, signed by the acting organisation.
block #4,817 · DocumentRegistry
signer 0x7a1…e04 (Manufacturer)
Step 4
Anyone can verify
Re-hash the record you were given, compare it with the chain, and get a clear verified or tampered answer.
VERIFIED · hashes match

2 · Tamper detection, live

Change one character. Watch the proof fail.

This demo runs entirely in your browser. The document below was fingerprinted with SHA-256 and the result treated as anchored on-chain. Edit anything, even a single digit of the carbon figure, and the fingerprints no longer match.

Off-chain document (try editing it)

Fingerprint anchored on-chain

bdfd75968757e49223efdea706537acc17bade1c74b67754de834106787fe848

Fingerprint of the document you hold

bdfd75968757e49223efdea706537acc17bade1c74b67754de834106787fe848

VERIFIED

The document matches the fingerprint recorded on the chain.

In the product, the same check runs on the public passport page: drop a certificate onto it, the browser computes its fingerprint, and the platform compares it with the value recorded by the DocumentRegistry contract, returning verified, tampered or not found, with the block and timestamp of the original record.

3 · On-chain vs off-chain

What lives where, and why.

A blockchain is the wrong place for large files or personal data: everything written there is permanent and replicated. So EVstring keeps the data off-chain and puts only proofs on-chain.

Off-chain: the data

Battery specifications
chemistry, capacity, voltage, weight
Certificates & reports
carbon audit, composition, due diligence
Dismantling & safety docs
AES-256-GCM encrypted on IPFS
Telemetry readings
voltage, temperature, SoC, SoH
Personal data
VINs, owner details: never leave this side

PostgreSQL, TimescaleDB and IPFS. Access is checked per role and per tier; restricted files are encrypted.

On-chain: the proof

Passport token
ERC-721, one per battery, current holder
Metadata fingerprint
SHA-256 of the registered specs
Lifecycle events
state, acting organisation, timestamp
Document hashes
SHA-256 + IPFS content identifier
Telemetry Merkle roots
one root per time window

Permissioned EVM chain. Append-only: contracts enforce who may write what, and nothing is ever edited in place.

A fingerprint reveals nothing about the data behind it, yet proves that data has not changed since it was anchored.

4 · Lifecycle rules in code

The contract decides who can do what, and when.

Each product type has its own lifecycle; an EV battery moves through seven states. The AssetLifecycle contract allows only the transitions the type defines, and only for the role shown. A recycler cannot recycle a battery that is still in a vehicle; a fleet cannot mark one as recycled.

Every transition is recorded with the acting organisation, timestamp and a fingerprint of the supporting record.
Recycling also requires a valid licensed-recycler credential.
Custody (the passport token) moves with the product as the steps that hand it over are taken.

1
MANUFACTURED
Manufacturer registers the battery; passport token minted
2
INSTALLED
Vehicle OEM installs it (VIN kept off-chain, salted hash on-chain)
3
IN_USE
OEM or current owner puts it into service
4
UNDER_SERVICE ⇄ IN_USE
Service centre opens and closes service visits
5
RETIRED
Owner or service centre retires it, with the latest state-of-health reading
6
SECOND_LIFE ⇄ RETIRED
Second-life operator repurposes it, e.g. stationary storage
7
RECYCLED
Licensed recycler dismantles it and records recovered materials (terminal)
Any other transition is rejected by the contract.

5 · Telemetry anchoring

Millions of readings, one fingerprint per window.

Writing every battery reading to a blockchain would be slow and pointless. Instead, readings are grouped into time windows, hashed into a Merkle tree, and only the tree's root is anchored.

Any single reading can later be proven with a handful of sibling hashes.
Editing one historical reading breaks the proof, so state-of-health history becomes credible to second-life buyers.
On-chain footprint stays constant no matter how many batteries report.

Path being proven Proof: 3 sibling hashesProving reading 6 of 8

6 · Architecture

A conventional platform, with a ledger underneath.

Users never touch the blockchain directly. They use role-based web dashboards and a public passport page; the platform handles signing, queuing and indexing.

The write path

1
Request
A signed-in user submits an action, for example "install battery". The API checks their session, their organisation's role and whether the transition is allowed.
2
Store & fingerprint
Off-chain data is written to the database or encrypted document store, and its SHA-256 fingerprint is computed.
3
Queue & sign
A transaction is queued and signed with the organisation's own key. The API answers immediately with a tracking ID.
4
Contract enforces
The smart contract re-checks the role and the current state. A disallowed transition is rejected, whatever the application said.
5
Index & display
An indexer mirrors the confirmed on-chain event into the database, so dashboards and passport pages stay fast.

Seven focused smart contracts

ParticipantRegistry: Which organisations exist, which role each holds, and whether they are active.
AssetTypeRegistry: The product types: for each version, its states and which roles may take each step. Rules are data, so a new product type needs no new contract.
AssetPassport: One ERC-721 token per product: identity, product type and version, current state, holder and metadata fingerprint.
AssetLifecycle: The state machine. Every transition is checked against the product type's rules, the caller's role and the current state, then logged as an event.
DocumentRegistry: SHA-256 fingerprints and storage identifiers for certificates, reports and photos.
RecordRegistry: Fingerprints of records about a product: material recovered at recycling, repairs, refurbishment grades, tests.
TelemetryAnchor: One Merkle root per time window of telemetry readings.

Built on audited OpenZeppelin building blocks, with role-based access control and an emergency pause.

Permissioned EVM chain

Hyperledger Besu with QBFT consensus is the production target: a fixed set of known validators and immediate finality. Development runs on a local EVM network.

Fast reads

Dashboards and passport pages read from an indexed database mirror; the "verified on blockchain" checks read the chain directly.

Standards-friendly

Standard Solidity and ERC-721, QR payloads designed for later GS1 Digital Link compatibility, and a data model based on EU Annex XIII.

Why a ledger

Compared with the alternatives.

Battery passports could be built on a shared database or on a public blockchain. Here is why EVstring chose a permissioned ledger with off-chain data.

Comparison of architectures for a battery passport
Property	Central database	Public blockchain	EVstring
History cannot be rewritten by the operator
Confidential data stays private
Known, accountable participants
No cryptocurrency or gas price exposure
Anyone can verify a document

FAQ

Common questions.

More detail on controls is in the trust centre, and on obligations in regulations.

See a live public passport

Is this a cryptocurrency or a public blockchain?

No. EVstring runs on a permissioned EVM network whose validators are known organisations. There is no coin, no token with monetary value and no public mining. The passport "token" is simply a unique, transferable record of identity and custody.

Can someone change the database behind the dashboards?

The database is a fast, convenient copy. The chain is the source of truth: fingerprints and events can be re-checked against it at any time, and the indexer can rebuild the database from the chain from scratch. An edited record no longer matches its fingerprint.

What happens to personal data and the right to erasure?

Personal data never goes on-chain. VINs are stored as salted hashes, owner details stay in the off-chain database, and only fingerprints are anchored. Deleting the off-chain record leaves a fingerprint that reveals nothing about the person.

Do we need blockchain expertise or our own nodes?

No. Your team uses a normal web application with role-based dashboards. Organisations sign through keys managed by the platform. Running a validator node is optional for consortium members that want an independent copy of the ledger.

Why not just use a shared database with audit logs?

Because the operator of a shared database can rewrite its own logs. With an append-only ledger replicated across independent validators, no single participant, including the platform operator, can silently change history.

Get started

See the proof for yourself.

We will walk you through registration, lifecycle events, the public QR passport and tamper-evident verification, using your own battery categories as the example.

Book a demo Try the public passport