A foundational paper introducing IAEX as the base layer for multi-party economic state. Eight chapters, written for institutions, operators, and the systems that connect them.
Every meaningful economic event today — a purchase, a shipment, a payment, a regulatory filing — exists in many places at once, in many incompatible forms.
Each system tells its own version of the same story. The buyer's ERP says one thing; the supplier's accounting platform says another; the bank, the customs broker, the auditor, the regulator each maintain a partial, untrusting copy. Reconciliation is the silent tax on every cross-organisation transaction in the global economy.
IAEX proposes a base layer that resolves this fragmentation without flattening it. It does not prescribe a universal data model. It does not impose a vocabulary. It does not require participants to share infrastructure or surrender custody of their internal systems.
Instead, IAEX guarantees five primitives over any economic event: who caused it, when it occurred, in what context, that it has not been altered since, and why — meaning the prior event that it cryptographically depends on. Five guarantees, sealed by hash, sovereign by region, addressable by any participating system.
This paper introduces the Economic State Protocol — the thesis, the architecture at a conceptual level, the comparison to existing systems, and the path to a living, multi-party network.
An event has one state. That state is the same regardless of which party observes it, which system records it, or which jurisdiction holds it. IAEX is the layer where that single state becomes provable — without forcing convergence on schema, vendor, or vocabulary.
It is not a technical specification, an API reference, or a governance charter. It is a positioning document — written for institutions, operators, and standards bodies who must understand IAEX before they engage with it.
A single transaction generates dozens of records, none of which agree.
Consider a routine purchase order between two firms in different jurisdictions. The buyer raises the order in their ERP. The supplier acknowledges it in theirs. A logistics provider issues a despatch advisory. The bank logs an outbound payment. Customs records an import declaration. A regulator receives an aggregate filing. An auditor, months later, reconstructs the entire chain by hand.
Seven systems. Seven private records. Seven attempts to describe a single economic reality. Each correct in isolation, each incompatible at the join.
The instinct, repeatedly, has been to solve fragmentation by enforcing a single format. SWIFT did this for cross-border payments. EDI did this for B2B documents. Healthcare standards bodies have spent four decades trying to do this for patient records. Each succeeded narrowly and failed broadly.
The reason is simple: the world's economic vocabulary is irreducibly plural. An invoice in retail is not an invoice in pharmaceuticals. A purchase order under Indian GST is not the same instrument as a purchase order under EU VAT. Forcing convergence at the data-model layer means either an ever-growing standard nobody implements completely, or a lowest common denominator nobody finds useful.
Fragmentation is not a defect to be eliminated. It is a property of a heterogeneous economy. The protocol layer's task is not to remove plurality — it is to make plurality provable, addressable, and causally linked across systems that will never share a schema.
Two pictures of the same transaction — before a protocol layer exists, and after.
Coordination moves from bilateral document exchange to participation in a shared protocol. Each party retains its own systems, its own vocabulary, its own data sovereignty. What changes is that every economic event becomes addressable, sealed, and causally linked — by reference, not by replication.
IAEX is infrastructure. It is a network protocol for economic events — not an application, not a database, not a marketplace.
IAEX is the base layer over which independent systems — operated by humans, organisations, or machines — record economic events into a shared, sovereign, tamper-evident network. Every participant retains custody of its own systems. Every event recorded into IAEX carries five guarantees that survive the boundary between systems and the boundary between jurisdictions.
The network is structured as a multi-party, multi-tier graph. It accommodates horizontal relationships — buyer to supplier, peer to peer — and vertical ones — principal to delegate, parent to subsidiary, system to sub-system. A single economic event may belong simultaneously to several such relationships; IAEX models this without duplication.
IAEX sits below the application layer of every participating system, and above the transport layer of the public internet. It is the layer at which an event becomes a fact — independently verifiable, causally linked, and resistant to the partiality of any single observer.
Every record submitted to IAEX is an event. An event is a small, opaque, sealed object. It carries a payload that the protocol does not interpret, surrounded by a small set of attributes that the protocol does guarantee.
The exact field names and the on-the-wire encoding are intentionally omitted from this paper. What follows is illustrative — the conceptual shape, not the specification.
// conceptual — illustrative only { actor: "iaex:actor:0x…", // who timestamp: "2026-05-01T10:14:32Z", // when context: "iaex:ledger:0x…", // what context caused_by: "sha256:a91f…", // why — prior event payload: { /* opaque to IAEX */ }, seal: "sha256:c4e2…" // tamper-proof }
The protocol reads around the payload, never into it. The payload may carry an invoice, a sensor reading, a regulatory filing, a custom industry document — IAEX makes no claim about its meaning. What IAEX does claim is that the event was submitted by the named actor, at the named time, in the named context, immediately following the named prior event, and has not been altered since.
The most distinctive of the five guarantees is causal linking. Each event may declare a prior event whose hash it depends on. The declaration is folded into the event's own seal, so the causal claim itself becomes tamper-evident. The result is a directed acyclic graph of economic events — across organisations, across systems, across borders — in which any node can prove, without trusting any single party, the sequence of causes that led to it.
This is the property that allows two systems with no shared schema to nonetheless interoperate meaningfully. They do not need to agree on what an "invoice" is. They need only agree that this payment event references that invoice event by hash — and the network attests to the rest.
Six properties define IAEX as a class of infrastructure. They follow from the design; none is configurable.
Notably absent: a property called "consensus". IAEX does not require global agreement on order. It requires only local, cryptographically anchored agreement between the parties who chose to share a context. This is what makes the network scale without a coin, a chain, or a clearing house.
Whatever an event says, the protocol attests to five things about it. Together they are sufficient to make the event a fact.
These five guarantees, and only these five, are what IAEX promises. They are deliberately fewer than competing approaches — fewer than a settlement system, fewer than a blockchain, fewer than a vocabulary standard. The discipline is the point.
Five events from three independent parties, sharing one context, linked by hash. No shared schema is required.
Any reader of the network — counterparty, auditor, regulator — can verify, without trusting any participant, that the payment was made because goods were received, that goods were received because they were despatched, and so on back to the original order. The proof is mathematical, not contractual.
A traditional database stores a record. The record is true insofar as the database operator says it is. If the operator is compromised, dishonest, or simply mistaken, the record is unreliable.
An IAEX event is different. The five guarantees do not depend on the integrity of any single operator. The seal is verifiable by the recipient. The actor is verifiable by any holder of the public key. The causal chain is verifiable by anyone with a copy of the prior events.
The result is that an IAEX event functions as a fact — an artefact whose truth is independently checkable, whose authorship is provable, and whose place in the sequence of economic causation is sealed.
None of this requires participants to abandon their existing systems. A firm continues to operate its ERP, its accounting system, its bespoke tooling. What changes is that the economic events emitted by those systems become first-class objects in a network where they can be referenced, verified, and built upon by other parties.
Interoperability is not a single problem. It is four problems stacked on top of each other. IAEX solves three of them, and deliberately leaves the fourth open.
Two systems can address each other and exchange bytes. Solved long ago by the public internet. IAEX inherits this layer.
The bytes resolve to a structured object whose envelope both sides understand. IAEX provides a sealed, canonical event envelope; payloads remain free.
One event is provably the consequence of another, across systems and parties, without trusting any single operator. This is IAEX's distinctive contribution.
Two parties agree that "invoice", "buyer", "consignment" carry the same meaning. IAEX deliberately does not enforce this. See next page.
The history of cross-organisation standards is the history of attempts to solve the semantic layer. SWIFT, EDI, FHIR, ebXML, UBL, OAGIS — each is a vocabulary, each is a committee, each is a multi-decade project. Each succeeds within a single industry and fails to generalise.
This is not because the standards are poorly designed. It is because the world's economic vocabulary is plural by construction. An invoice in pharmaceutical distribution carries different obligations from an invoice in agricultural commodities. A purchase order under one tax regime is not the same instrument as a purchase order under another. Forcing semantic convergence at the protocol layer means choosing one industry's worldview as canonical — and excluding the rest.
Semantic agreement is real, necessary, and valuable — but it is the work of industries, consortia, and counterparties, not of a base layer. IAEX provides the substrate on which any number of parallel semantic agreements can exist. A pair of firms can agree privately. A trade association can publish a standard. A regulator can mandate a vocabulary within its jurisdiction. None of these need to be coordinated through IAEX, and IAEX does not adjudicate between them.
What IAEX does provide — through causal linking — is something stronger than vocabulary agreement. It provides referential agreement. Two parties do not need to call an event by the same name to agree that this payment is the consequence of that invoice. Hash references survive the absence of shared vocabulary.
The protocol's discipline is to provide the smallest set of guarantees that make plural economic vocabularies provably interoperable. Anything more is overreach. Anything less is insufficient.
IAEX hosts none of these. It carries them. The distinction is the entire architecture.
A reference visualisation, in the manner of the OSI model — for reasoning, not for implementation.
Vocabulary agreement. Not in IAEX. Carried over IAEX.
Five guarantees. Causal graph. Sovereign routing. Append-only.
Canonical, sealed event object. Opaque payload.
Inherited. Not redesigned.
The diagram emphasises that IAEX occupies exactly two layers — the syntactic envelope and the trio of identity, time, and causality. It does not extend upward into vocabulary, nor downward into transport. This narrowness is what allows it to carry every industry without being captured by any single one.
IAEX is not a single graph. It is a graph of graphs — horizontal between peers, vertical between principals and delegates, partitioned by region.
Two organisations in a commercial relationship — buyer and supplier, payer and payee, sender and recipient — share contexts in which both write events. Neither is privileged. Neither operates the substrate. Both refer to the same sealed history.
An organisation may delegate authority to act on its behalf — to a subsidiary, an agent, an internal department, or an autonomous machine process. IAEX models delegation as a first-class relationship: the delegate writes events, the principal's authority is preserved, and the chain of authorisation is itself a sealed, auditable trail.
Events are routed to substrates anchored within their issuing region. An actor in India writes to the India substrate; an actor in the European Union writes to the EU substrate. Cross-region references are by hash, not by replication. Data residency is not a configuration option layered over the network — it is the routing model itself.
A schematic of three regions, several organisations, several tiers — and the references that span them.
Solid lines are shared contexts within a region. Dashed lines are cross-region references — never replication, only sealed hash references that any party can resolve against its own region's substrate.
Most platforms treat data residency as a configuration parameter — a deployment toggle layered over an architecture that was designed to be global. IAEX inverts this. Region is encoded in the actor's identity itself, and the routing of every event derives from that identity in a single, deterministic step. There is no query to a routing service; there is no possibility of misrouting; there is no central operator who could, in principle, see across regions.
A regulator with jurisdiction over a region holds full audit visibility into events sealed within that region — without needing access to events sealed elsewhere, and without any single counter-party being in a position to obstruct that visibility. The architecture is friendly to sovereign supervision.
When a participant in one region must demonstrate to a participant in another that an event occurred — for example, when a customs authority must verify a despatch sealed in the exporter's home region — the disclosure is itself an event. It is sealed, it is auditable, and it leaves a trail in both regions. There is no quiet copy.
The IAEX network is open to three classes of participant. The protocol does not distinguish between them in its guarantees; it distinguishes between them only in how they enrol and how they delegate.
The same five guarantees apply to all three. A human signing an event, an ERP emitting an event, and an autonomous agent acting on a delegated mandate are, from the protocol's perspective, the same kind of object — and that uniformity is what allows IAEX to function as a base layer for an economy that increasingly mixes the three.
No piece of infrastructure exists in isolation. This chapter places IAEX against five existing classes of system — to clarify what it inherits, what it discards, and what it is uniquely positioned to provide.
The five chosen comparison classes are: SWIFT (closed industry messaging), public blockchains (open consensus systems), GS1 / EDI (vocabulary standards), ERP-to-ERP integrations (the dominant status quo), and traditional notarial / audit services. Each has succeeded inside its own boundary; each fails differently when asked to serve as a universal base layer for economic state.
The comparison is made along seven dimensions selected for their relevance to institutional adopters: industry scope, governance, tamper-proof guarantees, data residency, onboarding effort, causal traceability, and commercial model. The dimensions are explained on the next page; the matrix follows.
IAEX does not seek to displace any of the systems compared in this chapter. SWIFT will continue to clear payments. Blockchains will continue to settle digital assets. EDI will continue to carry retail documents. IAEX provides the layer beneath them — the layer at which an economic event becomes a fact, regardless of which application captures it.
The lens through which the comparison matrix on the following pages is to be read.
Whether the system is bound to a single industry or generalises across all economic activity.
Centralised, federated, or decentralised — and the implications for sovereignty and accountability.
Whether records, once written, are independently verifiable as unaltered — and by whom.
The extent to which the system respects sovereign jurisdiction over the data it carries.
What a new participant must do to begin emitting and receiving verifiable events.
Whether one event can be cryptographically demonstrated to be a consequence of another, across organisations.
How the system is funded, who pays, and what economic incentives shape its evolution.
First four dimensions. The position attributed to comparison systems is generalised; specific deployments may differ.
| IAEX | SWIFT | Public blockchain | GS1 / EDI | ERP-to-ERP | Audit / Notary | |
|---|---|---|---|---|---|---|
| Industry scope | Universal — agnostic to industry vocabulary | Banking only | Universal but token-centric | Retail, supply chain, healthcare in narrow profiles | Bilateral — per integration | Document-class specific |
| Governance | Federated by region; protocol open | Cooperative, single operator | Decentralised; coin-aligned | Standards bodies | Bilateral contracts | Sovereign (notary) / private (audit) |
| Tamper-proof | YES Per-event seal, verifiable by any reader | PARTIAL Operator-attested | YES Consensus-bound | NO Document-level only | NO Bilateral trust | PARTIAL Document-level seal |
| Data residency | BUILT-IN Identity-derived routing | CONFIG Layered over global | NO Public ledger | CONFIG | CONFIG Per integration | YES By instrument jurisdiction |
Remaining three dimensions.
| IAEX | SWIFT | Public blockchain | GS1 / EDI | ERP-to-ERP | Audit / Notary | |
|---|---|---|---|---|---|---|
| Onboarding effort | Minimal — identity enrolment + emit events; no shared schema | Heavy — membership, BIC, message standards | Light technically, heavy operationally | Heavy — vocabulary mapping per partner | Very heavy — bespoke per pair | Per-document, manual |
| Causal traceability | YES Hash-linked across parties & regions | NO Message-level only | PARTIAL Within chain | NO | NO Manual reconciliation | NO Document-level |
| Commercial model | Infrastructure pricing; no token; per-event & per-actor | Cooperative fees | Token / gas | Membership + implementation | Capex per integration | Per-document fee |
SWIFT is excellent inside banking and irrelevant outside it. Public blockchains provide tamper-proof state but at the cost of sovereignty and at a commercial model many institutions cannot adopt. GS1 and EDI succeed at vocabulary within narrow industries but cannot generalise. ERP-to-ERP integration is the dominant status quo and is precisely the fragmentation problem this paper opens with. Notarial and audit services seal individual documents but do not link them. IAEX is the smallest base layer that provides cross-system, cross-party, cross-region tamper-proof causal state — without imposing a vocabulary on any industry.
A protocol for economic events is only as good as the identities that issue them.
A participant joins IAEX by enrolling an identity. The identity is anchored by a cryptographic key the participant holds; it is bound to a region of residence; it carries an entry-level trust grade. Enrolment is administrative, not promotional — there is no marketplace, no application directory.
An organisation may grant another identity — a human, a department, a machine process — the authority to emit events on its behalf, scoped to a specific context and a specific class of action. The delegation itself is an event, sealed under the principal's identity, revocable, and auditable.
Delegation is the mechanism by which the network accommodates the structure of real organisations. A signing officer acts under the firm's authority. An ERP integration acts under the firm's authority. A subsidiary acts under the parent's authority within agreed bounds. The protocol does not need to model corporate law; it needs only to record who delegated what to whom, and from when until when.
Identities enter the network at a baseline trust level. From that baseline, trust is elevated through verifiable acts — and the acts themselves are sealed events on the network.
The protocol does not assign trust. It records the artefacts on which trust is judged. A regulator's attestation that an identity is licensed; a counterparty's history of fulfilled commitments; an auditor's confirmation of registered credentials — each of these is an event, each of these accumulates against an identity, each of these is independently inspectable.
Enrolled identity, key bound, region anchored. No external attestations.
Identity confirmed against registered records — corporate registries, tax authorities, equivalent.
Sealed attestations from independent third parties — auditors, regulators, accredited bodies — recorded against the identity.
Long-running, reconciled history of fulfilled commitments across multiple counterparties and contexts.
Trust grades are a reading lens, not an entitlement. The protocol does not gate participation on trust grade; participants and integrating systems decide independently what grade they require for a given interaction. This separation — recording the artefacts centrally, deciding policy locally — is intentional.
Three notional steps — enrol an identity, share a context, seal an event — to convey the texture of integration. The names and fields are illustrative.
// notional POST /identities { name: "Acme Trading Ltd", region: "in", key: "ed25519:…" } → iaex:actor:0x9f1e…
// notional POST /contexts { parties: [ "iaex:actor:0x9f1e…", "iaex:actor:0xb302…" ], scope: "trade" } → iaex:context:0x44a8…
// notional POST /events { context: "iaex:context:0x44a8…", caused_by: "sha256:a91f…", // optional payload: { /* anything */ } } → sha256:c4e2… // sealed event hash
The actual surface area is small. A participating system that already emits structured events to its own database adds, in effect, a single outbound call per event. The substantive engineering is in deciding which events are economically meaningful — which is a question only the participating organisation can answer.
A protocol succeeds when it disappears — when the institutions, integrations, and applications built on top stop having to think about it.
Five guarantees implemented; sovereign region routing; identity, delegation, causal seal. Bilateral and multi-party contexts. The substrate this paper describes.
Public discovery layer for identities and contexts. Regional operators in additional jurisdictions. Attestation framework matured. Live multi-party deployments across at least three industries.
Wider integration with adjacent infrastructures — payment systems, customs authorities, regulatory portals — by reference, never replacement. Sectoral semantic agreements built and hosted by industry bodies, carried over IAEX.
IAEX recedes from view. Applications, regulators, and audit functions assume the substrate. The protocol becomes infrastructure in the sense that the public internet is infrastructure — taken for granted.
The economy is multi-party. It is multi-tier. It is plural in vocabulary, sovereign in jurisdiction, and increasingly written by machines as well as by humans. None of this is going away. None of it should.
What is missing is not another database, another vocabulary, another marketplace. What is missing is a base layer — narrow, disciplined, infrastructural — at which an economic event becomes a fact. A layer that records who acted, when, in what shared context, that the record has not been altered, and which prior event it depends on. A layer that does this regardless of industry, regardless of vendor, regardless of border.
IAEX is that layer. It does not seek to be more. The discipline of doing only this — and doing it with five guarantees, a sovereign routing model, and a causal graph — is what allows it to serve as a substrate for everything else.
One event. One state. Across every party, system, and border.
© 2026 IAEX. All rights reserved. "IAEX", the IAEX mark and "Economic State Protocol" are trademarks of IAEX. The architecture, methods and protocol described herein are proprietary. No licence, express or implied, is granted by this document. Unauthorised reproduction, redistribution, reverse engineering or commercial use is prohibited.
This document is a commercial publication of IAEX. It does not constitute an offer, solicitation, contract, or any form of legal, financial, taxation or regulatory advice. Statements concerning architecture, capabilities, roadmap and positioning are forward-looking and may change without notice. Commercial terms, service levels and integration arrangements are governed solely by separately executed agreements between IAEX and its counterparties.
IAEX operates the protocol on a federated, region-anchored basis and maintains alignment, in each jurisdiction of operation, with applicable laws on data residency, electronic records, audit-trail integrity, identity assurance, and lawful access. No warranty, express or implied, is provided by this document. All other names and marks are the property of their respective owners.