Content-Addressed Identity

Raeez Lorgat

Institutional identifiers fail the moment an institution moves across a jurisdictional boundary.

A corporation incorporated in Delaware has an entity number in the Delaware Division of Corporations database. The same corporation, foreign-qualified in Florida, has a different number in the Florida database. Its bank assigns it a customer ID, and the IRS assigns it an EIN. Each identifier points into the issuing authority’s database and resolves only there.

An institution operating in one place can rely on local references. Across jurisdictions, those references must be reconciled.


I.

Content addressing solved the analogous problem for data. A URL identifies a location. If the server moves, the URL breaks. If two servers host the same file, the URLs differ. With content addressing, the name is the cryptographic hash of the content itself. Two parties holding the same bytes compute the same name, regardless of the source, storage location, or local identifier. The construction has been standard since Merkle’s authentication trees (1979). Git has named every revision this way since 2005, and IPFS (Benet, 2014) generalized it to arbitrary content.

Applying content addressing to a corporation requires a byte string to hash. A corporation is a legal fiction: a bundle of rights and obligations created by a sovereign act. The appropriate byte string is less obvious than for a file.

II.

At creation, four facts are fixed: the incorporator, the jurisdiction, the instrument (articles of incorporation, certificate of formation, or equivalent), and the filing time. Directors, shareholders, addresses, and later names belong to the corporation’s subsequent history. The four facts describe the event that created the legal person. Their authoritative source is the registry that accepted the filing.

Define the genesis record as those four facts in canonical form (section III), and the identifier as an algorithm tag plus the hash of the record (section VII). The construction requires four assumptions.

One authoritative filing. The registry fixes the accepted instrument as one byte string, holds and serves it unchanged, and fixes the filing time with it. Two systems recording the same incorporation compute the same identifier because both hold that string. The sovereign supplies the content but takes no part in deriving the name. A born-digital filing meets the assumption whenever the registry keeps the bytes it accepted. A paper filing does not: each scan or certification renders an image with different bytes. Until the registry fixes one string, the entity has no derivable identifier (section IX).

Injectivity. Distinct incorporations yield distinct records. A formation agent may file dozens of entities in a day from one template. The instruments still differ because each states the entity’s name and the jurisdiction enforces name uniqueness at filing. Jurisdiction and filing time separate the rest.

A sound function. Each tagged hash function (section VII) is collision-resistant and second-preimage-resistant. The first property carries the injectivity of records over to identifiers. The second supports tamper-evidence. If a function loses either property, migration follows section VII: re-hash the record under a sound function and bind the two names.

A fixed genesis. The genesis is the instrument as first filed. Jurisdictions allow corrections with retroactive legal effect. A Delaware certificate of correction is effective as of the original filing date (Delaware General Corporation Law, section 103(f)). The chain records the correction as a later event in the entity’s history (section VI), leaving the genesis and identifier unchanged.

Under these assumptions the identifier is self-certifying: anyone holding the genesis record verifies it by recomputing the hash, without querying an authority. It is portable across systems implementing the same canonical form and hash function, whether in Delaware, Florida, or the Cayman Islands. It is also tamper-evident: altering the record breaks the match. These properties do not certify authenticity. The identifier binds a name to a claimed genesis. A sovereign attestation establishes that the genesis corresponds to a real incorporation (section V).

III.

Hashing requires deterministic input: the same logical record must produce the same bytes on every machine. JSON does not fix key order, languages disagree on number formatting, and timestamps have dozens of valid representations. If one system serializes {"creator":"alice","jurisdiction":"us-de"} and another {"jurisdiction":"us-de","creator":"alice"}, identical content produces different hashes. The identifier then depends on the implementation.

Encoding rules must resolve more than key order. “Sort keys lexicographically” is ambiguous: UTF-8 byte order and UTF-16 code-unit order disagree on any string containing supplementary-plane characters. Composed and decomposed Unicode encode the same incorporator name with different bytes: “José” hashes differently in NFC and NFD. Converting a date-only filing date to a UTC instant misrepresents the registry’s record by adding precision it never asserted.

Adopt a complete published encoding and define a profile for it. RFC 8785, the JSON Canonicalization Scheme, fixes member order by UTF-16 code units and number serialization by the ECMAScript rules. Deterministic CBOR (RFC 8949, section 4.2) and DER (X.690) are the binary equivalents. The profile normalizes text to Unicode NFC and carries monetary amounts as integers or strings rather than floats. It preserves the registry’s recorded precision and time scale. The instrument enters as the opaque byte string the registry fixed, without re-encoding. The profile governs the surrounding fields and must preserve their meaning.

The canonical form is part of the identifier’s definition. Two implementations produce the same identifier exactly when they hash the same profile with the same function. The profile must therefore be a published, versioned standard. Revising it changes identifiers just as a new hash function does (section VII).

IV.

Assigned namespaces already operate at global scale. The Legal Entity Identifier is an ISO standard (ISO 17442) endorsed by the G20 in 2012. The Global Legal Entity Identifier Foundation, established by the Financial Stability Board in 2014, oversees issuance through accredited local operating units. Millions of entities hold an LEI, and regulation makes it unavoidable in wholesale finance. Since January 2018, an EU investment firm cannot report a trade for a client that lacks one (MiFIR). Through BRIS, the European Union interconnects its member states’ business registers with those of Iceland, Liechtenstein, and Norway. Each company receives an EUID combining country code, register identifier, and local registration number (Directive (EU) 2017/1132; Implementing Regulation (EU) 2021/1042). Dun & Bradstreet has assigned DUNS numbers privately since the 1960s.

A global namespace for legal entities therefore requires no treaty, and sovereignty does not rule one out. The LEI went from G20 endorsement to trading mandate in six years. Each assigned identifier requires an operator to create an index entry, and resolution depends on that index. An LEI is a key into GLEIF’s database, and a DUNS number into Dun & Bradstreet’s. An EUID resolves through the register that issued its components, retaining the local pointer. The LEI also shows the costs beyond the index: application, payment, validation against the register, and annual renewal to prevent lapse. Entities acquire one where a mandate or counterparty demands it. The millions issued are fewer than the companies on the United Kingdom’s register alone.

Content addressing removes the operator, the index, and resolution through it. Anyone holding the genesis record derives the identifier. It requires no application or renewal, cannot lapse, and cannot be reassigned because it is a function of the record. Jurisdictions must coordinate once on a technical standard for the canonical form and hash function. After that, no operator runs the namespace and no authority owns it.

V.

A derived identifier carries no authority. The W3C specifications separate control of an identifier (DID Core, 2022) from claims about its subject. Issuers whom the verifier chooses to trust sign those claims as credentials (Verifiable Credentials, 2019). The value of self-assertion is debatable for a natural person. A corporation’s existence, however, depends on a state act: incorporation, registration, or charter. An identifier scheme leaves that sovereign authority unchanged.

The binding therefore needs an issuer. The registry that accepted the filing signs the statement “this genesis record corresponds to entity number N in our register.” The attestation points to the content-addressed identifier as a stable reference. The jurisdiction alone controls the binding to its register, while the identifier remains independently derivable. Several jurisdictions can attest independently to the same identifier: Delaware to the incorporation, Florida to the foreign qualification. Their sovereign attestations share one derivable name, coordinated by its hash.

This standard issuer-attestation pattern already runs for legal entities with assigned identifiers. GLEIF’s verifiable LEI, built on KERI, places issuer-signed credentials behind each LEI. In this note’s construction, the registry is the issuer. Section VIII states how the constructions differ.

VI.

Identity includes history. Institutions issue shares, change directors, merge, dissolve, foreign-qualify, and acquire or lose sanctioned status. A genesis hash alone provides no means to verify those events. Linked timestamping (Haber and Stornetta, 1991) extends the construction: each event record carries its predecessor’s hash. The latest event’s hash, the chain head, commits to the entire history. A blockchain builds consensus over this structure. Here it operates without consensus, proof of work, or a shared ledger. Each attesting jurisdiction maintains one chain in the system holding its authoritative entity record, rooted in the same genesis identifier.

A signed chain head is a non-repudiable commitment by its maintainer to every preceding event. Altering, inserting, or deleting a committed event changes the recomputed head. Anyone who retained the old head can detect the change. When a regulator in jurisdiction A requests an entity’s history from jurisdiction B, it can check B’s answer against every head B committed to. This avoids trusting the integrity of a database export at query time.

Before a head leaves the maintainer, history can be rewritten without trace. A maintainer can also equivocate by showing different parties internally consistent chains that share a common prefix. Witnesses address these two gaps by countersigning observed heads, so comparison detects equivocation. Linked timestamping (Haber and Stornetta, 1991) and KERI’s witness receipts (Smith, 2019) use this construction. A further limit remains: the chain proves that committed records have not changed, not that events were recorded faithfully. Faithfulness depends on the sovereign’s signature described in section V.

VII.

Privacy-preserving cross-jurisdictional compliance will require proofs about an entity’s identity or history without revealing either. SHA-256 is inefficient inside zero-knowledge proof circuits. These proofs need a hash designed for arithmetic circuits, such as Poseidon (Grassi et al., 2021), Rescue, or a successor.

The identifier of section II therefore carries an algorithm tag: a function code plus the digest, following the multihash construction (Benet, 2014). Under the same tag, the same canonical genesis record yields the same identifier everywhere. Tags support migration between functions. Identifiers derived from the same record under different functions remain distinct byte strings with no computable relation between them.

Migration requires re-derivation and binding. When circuits require Poseidon, anyone holding the canonical genesis record can derive the new identifier from it. An event on the entity’s chain or an attestation covering both identifiers binds the pair. The holder can check this binding without re-issuance by an authority or reallocation of a namespace. A canonical-form revision (section III) follows the same procedure because it changes identifiers just as a new function does.

VIII.

The components are established. Content addressing is decades old (Merkle, 1979; Git, 2005; IPFS, 2014), and hash-chained event histories are Haber and Stornetta’s (1991). Algorithm-tagged digests are multihash, and issuer-signed bindings are W3C Verifiable Credentials. KERI (Smith, 2019) combines them: a self-addressing identifier derived from an inception event, extended by a hash-chained log, witnessed against equivocation, and bound by credentials. GLEIF’s verifiable LEI deploys this construction in production for legal entities.

This note uses the sovereign filing as the inception content. A KERI identifier derives from a key-management event and names a controller of cryptographic keys. The vLEI then binds that controller to an assigned LEI by credential. Derivation from the incorporation instrument makes the name a function of the sovereign act, independent of anyone’s keys. It exists for every entity whose filing the registry holds as a fixed byte string, without issuance, fee, or lapse. The registry attests the binding between its entry and a name that any counterparty can re-derive from the filing.

IX.

Five problems remain open.

Retroactive correction: the law treats a corrected filing as effective from the original date, while the chain records when the correction happened. Fixing the genesis as the instrument first filed keeps the identifier stable. Jurisdictions would still need a shared convention relating legal effect to chain order.

Cross-algorithm identity: after migration, an entity has two bound names. Verifiers must treat identity as the closure of attested bindings, never as byte equality.

Conversion: redomestication or statutory conversion carries a legally continuing entity into a registry that accepts a formation-class instrument for it. A verifier therefore encounters two filings that each look like a genesis. Under the fixed-genesis convention, the original filing remains the genesis, and the destination filing is an event in the entity’s history. The destination registry attests a binding from its filing to the original identifier. A verifier holding only the destination filing derives a second name and learns of the first through that binding alone. The closure of attested bindings therefore crosses registries as well as algorithms. The registries must agree which filing counts as first, and the destination must attest a binding to another sovereign’s filing.

Legacy instruments: a paper filing, or one re-rendered at each certification, lacks a registry-fixed byte string, leaving the derivation of section II without input. The registry would have to fix an image or transcription certified as the instrument as filed. This requires a one-time act for every entity in the pre-digital register, restoring the issuance step that content addressing otherwise removes.

Witnessing: fork detection requires witnesses of chain growth. Who witnesses a sovereign registry, whether peer registries, regulators, or market infrastructure, remains an institutional question.

An opaque UUID is easier to mint and store. A content-addressed name requires canonical serialization, deterministic hashing, and algorithm tags, specified once in a standard. It supplies a verifiable reference for cross-border software. A program forming a Cayman subsidiary for a Delaware parent can identify the parent without requiring counterparties to query Delaware. No outage, lapse, or reassignment can break that reference.

A jurisdiction retains the sovereign authority to create a corporation. Distinguishing that corporation from every other entity is a computation on the record of the sovereign act and requires no authority. Authenticating the record requires exactly one: the sovereign whose act it was.