ACPROTOCOL
Protocol fundamentals

Canonical identity for assets

Files have hashes. Assets need identity.

Digital systems can tell, precisely, whether two files are exactly identical. The bigger question is a different one: how do you know whether two different files represent the same asset?

Ecosystem / Canonical Identity
Canonical identity

A permanent identity for the same asset.

An asset can appear in different files, systems, institutions and representations over time. ACIDN provides a persistent canonical reference so that these different occurrences are recognized as belonging to the same asset.

A PDF, scan, image, duplicate copy or structured data can be different representations of the same reality — and the identity follows the asset in any format.

Multiple representations

The file can change. The asset remains the same.

A document can exist as a native PDF, a scan, an image, a form or a structured record. Different files can be associated with the same asset.

The identity remains

The occurrence changes. The asset reference remains.

New versions, reissues and representations appear over time and stay linked to the same main identity. ACIDN relates these occurrences within the same trajectory.

Asset evolution

The identity remains while the state evolves.

The asset receives new occurrences and events throughout its existence. AC preserves this continuity, and the trajectory can be queried with all previous states.

Why canonical identity matters

Each institution sees one part of the same asset.

Different institutions receive different documents related to the same asset, each in its own system:

A banksees one occurrence.
A city hallsees another.
A notarysees another.
A tokenizersees another.

AC was designed to create a common canonical reference for the asset, with each institution keeping its own system.

Examples of occurrences

The same identity appears in situations such as:

What ACIDN does

It identifies and correlates the asset and its occurrences.

From occurrence to identity.

See how the AC infrastructure uses canonical identity to connect documents, assets and institutions.

DISCOVER THE INFRASTRUCTURE →

← BACK TO ECOSYSTEM

The starting point

The file changed. The asset is still the same.

The same asset lives in many files, formats, systems and moments of its life. The content may still represent the same asset — but the file is no longer the same.

📄

A contract exists as a PDF, an image and an XML.

🏛

A land registry record receives an annotation.

🧾

An invoice is reissued.

🔁

A document moves from one system to another.

The problem

Without canonical identity

Without a persistent identity for the asset, every new occurrence may be treated as a new object. The asset's history fragments across documents, databases, institutions and blockchains, with no common reference able to connect them. The result may be:

The problem is not storing documents. It is knowing which asset each document belongs to.

The difference

Traditional hash × Canonical identity

TRADITIONAL HASH · IDENTIFIES THE FILE
“Are these files exactly identical?”
contract.pdf→8F27A…
contract.jpg→42BC9…
contract.xml→D0E61…

Same content, different files, different hashes — and that is correct. If a single byte changes, the hash changes. It is excellent for proving binary integrity, but it was not built to recognize the asset behind the file.

CANONICAL IDENTITY · IDENTIFIES THE ASSET
“Do these files represent the same asset?”
PDFImageXMLSystem ASystem B
↓
ACPROTOCOL
↓
ACIDN

The asset's permanent elements are organized by canonical rules and turned into a deterministic identifier. Same asset, same identity — in any format or source system.

From duplication to parity

More than finding duplicates:
recognizing the asset's identity and recording its evolution.

On parity, the protocol records the change, its origin and the corresponding authorization.

ACUNI on query means identity located, with no adverse state recorded.

ACEVOLUTION

The identity remains. The state evolves.

When an asset's occurrences connect to the same canonical identity, its history comes to exist in a single place: what the asset was, what happened to it, what changed and what its current state is.

ACIDN — PROPERTYillustrative example
Initial registration ACUNI
New certificate recorded event
Annotation recorded event
Collateral recorded event
Transfer recorded event
Current state query

Works together with your registry system. AC adds the asset's identity and its history in one place.

When a new certificate arrives, everything is automatic:

  • Recognizes the same asset — on its own, through the canonical identity. No manual search, no opening record by record.
  • Compares it with the previous version — and points out what changed.
  • Records the new occurrence — straight onto the timeline of the same ACIDN.

No typing, no manual registration, no operator searching for the asset.

The backing for the change comes from the event registered by the responsible institution: with an event, ACPAR; without one, ACQTN for review.

“A traditional hash tells you whether two files are identical. ACPROTOCOL AlternatingCurrent tells you whether they represent the same asset — and what happened to that asset over time.”

The file may change. The format may change.
The canonical identity remains.

It's not magic — It's Engineering

SEE THE TESTNET Explore the protocol →
Contact

Get in touch

Partners, banks, land registries, exchanges, investors and technical evaluators can write directly to:

Open in my e-mail