The Architecture

How identity verification, interaction audit, commerce tracking, and dispute resolution compose on a single record.

The architecture has a center of gravity: the blockchain record. The record is the on-chain artifact where all four layers of Trust in Depth converge — human identity, entity credentials, agreement terms, and agent authorization, bound together in a single, independently verifiable commitment that neither party controls. Everything in the architecture either creates, enriches, protects, or queries that record.

The mechanism that governs the record's lifecycle is the Resolver — an on-chain state machine that defines what actions can be taken on a record, by whom, in what order, and with what deadlines. Multiple resolvers compose on a single record, each governing a different aspect of the same agreement: identity verification, interaction audit, commerce tracking, and dispute resolution.

The Thin Waist

The Resolver is Integra's thin waist — a narrow, stable enforcement interface between heterogeneous layers above and below.

         ┌─────────────────────────────────────┐
         │     ABOVE THE WAIST                  │
         │  SDK · MCP Tools · A2A Agent Cards   │
         │  Provider Agent · Agreement Service   │
         │  (many consumers, many frameworks)   │
         └──────────────┬──────────────────────┘
                        │
         ┌──────────────▼──────────────────────┐
         │     RESOLVER (Thin Waist)            │
         │  State machine · Hash anchoring      │
         │  Deadline enforcement · Role auth     │
         │  (simple, general, universal)         │
         └──────────────┬──────────────────────┘
                        │
         ┌──────────────▼──────────────────────┐
         │     BELOW THE WAIST                  │
         │  Identity providers · Commerce       │
         │  protocols · Agent platforms · EAS    │
         │  (many providers, many standards)     │
         └─────────────────────────────────────┘

Internet architecture research demonstrates that systems with a simple, constrained waist outcompete richer, featureful middle layers. IP is the canonical example — many technologies below (Ethernet, WiFi, fiber, cellular), many applications above (HTTP, email, streaming), and a narrow waist that both sides pass through. A tightly constrained waist maximizes deployment scalability because it lowers coordination costs for both sides.

The Resolver follows this principle. It is deliberately simple:

State machine — transitions between well-defined states with role-based authorization
Hash anchoring — content-addressed evidence storage using protocol-agnostic bytes32 hashes
Deadline enforcement — absolute and relative deadlines with automated expiry detection
Role authorization — who can do what, determined by token holding, ownership, and attestation

The Resolver does not do AI reasoning (that is the Provider Agent, above the waist). It does not do identity verification (that is the identity providers, below the waist). It does not understand commerce protocol formats (that is the identity worker, below the waist). Complexity goes above and below. The waist stays simple and stable.

This answers a critical design question: why not make the Resolver smarter? Because thin waists maximize adoption. Every identity standard that plugs in below does not need to understand the SDK above. Every agent framework that integrates above does not need to understand the identity standards below. The Resolver is the minimum viable enforcement layer — and that minimalism is the architectural strength.

What happens when you need a better Resolver? Deploy a new one. AAAResolverV2 is registered in IntegraRegistryV1 and attached to new agreements. AAAResolverV1 continues running on existing agreements — the parties agreed to its behavior, and immutability is the trust guarantee. The thin waist evolves by addition, not mutation. Old and new Resolvers coexist permanently. This is a stronger answer to ossification than IPv4 to IPv6, where the entire network had to transition simultaneously. In Integra's model, there is no forced migration — because changing enforcement rules on a live agreement without both parties' consent would be a breach of the agreement itself.

Three-Layer Architecture

The system decomposes into three layers, each abstracting the complexity of the layer below.

Layer	Components	Function
Experience	SDK, MCP Tools, A2A Agent Cards	Developer and agent interfaces — tailored access for humans, AI assistants, and autonomous agents
Process	Agreement Service, Provider Agent, Rules Library	Business logic, state management, AI reasoning, case administration
System	Resolvers, Tokenizers, Providers, EAS	On-chain enforcement — blockchain, identity standards, payment rails

Each layer creates reusable building blocks for the layer above. A developer at the Experience layer calls integra.initiateDispute() — they do not know that this triggers a Provider Agent workflow (Process layer) that writes a state transition to the AAAResolverV1 (System layer) which checks party authorization via the Identity Gatekeeper (System layer) using an EAS attestation verified against a cross-record identity provider (System layer). The abstraction is the product.

Three roles map cleanly to these layers:

Role	Component	What It Does
Decides	Resolver	State transitions, authorization, deadline enforcement. Deterministic. On-chain.
Executes	Provider Agent	AI reasoning, evidence assembly, panel orchestration. Probabilistic. Off-chain.
Exposes	SDK / MCP / A2A	Developer interface. Framework-agnostic. Calls down to the Resolver.

The Resolver never reasons. The Provider Agent never enforces. The SDK never decides.

Resolver Composition

Multiple resolvers compose on a single record. Each handles one concern. Together they provide the full trust stack.

                              IntegraRecordV1
                                    │
                        ┌───────────┼───────────────────────┐
                        │     Up to 10 resolver slots       │
                        │                                   │
              ┌─────────┴─────────┐                         │
              │  IDENTITY LAYER   │                         │
              │                   │                         │
  ┌───────────┴───────────┐       │                         │
  │ IdentityGatekeeperV1  │       │                         │
  │ (human, 0x03)         │       │                         │
  ├───────────────────────┤       │                         │
  │ IdentityGatekeeperV1  │       │                         │
  │ (entity, 0x07)        │       │                         │
  ├───────────────────────┤       │                         │
  │ IdentityGatekeeperV1  │       │                         │
  │ (agent, 0x01)         │       │                         │
  └───────────┬───────────┘       │                         │
              │                   │                         │
              │ gates who         │                         │
              │ can own           │                         │
              │                   │                         │
  ┌───────────┴───────────┐       │                         │
  │  INTERACTION LAYER    │       │                         │
  │                       │       │                         │
  │ CommunicationResolver │       │                         │
  │ V1 (audit trail)      │       │                         │
  └───────────┬───────────┘       │                         │
              │                   │                         │
              │ anchors           │                         │
              │ evidence          │                         │
              │                   │                         │
  ┌───────────┴───────────┐       │                         │
  │  COMMERCE LAYER       │       │                         │
  │                       │       │                         │
  │ CommerceResolverV1    │       │                         │
  │ (tracking + SLA)      │       │                         │
  └───────────┬───────────┘       │                         │
              │                   │                         │
              │ feeds             │                         │
              │ evidence          │                         │
              │                   │                         │
  ┌───────────┴───────────────────┴─────────────────────────┘
  │  ENFORCEMENT LAYER
  │
  │ AAAResolverV1
  │ (dispute lifecycle, settlement, compliance)
  └─────────────────────────────────────────────

Identity Layer: IdentityGatekeeperV1

Gates who can own or interact with a record. Deployed as three instances per identity tier — human, entity, agent — each with different capability thresholds. Re-verifies attestations on every canOwn() call. A revoked or expired attestation blocks ownership transfer immediately.

Interaction Layer: CommunicationResolverV1

Hash-anchors interaction records with sender attribution, protocol identification, and session context. Each anchored interaction records the message hash, sender, recipient, protocol (A2A, MCP, XMTP), and conversation context. Designed for legally significant interactions — negotiations, specification discussions, commitment exchanges — not high-volume chat.

Commerce Layer: CommerceResolverV1

Tracks agent commerce operations through two monitoring systems. Agent tracking records cumulative value against caps, preventing agents from exceeding authorized spend. SLA monitoring tracks threshold compliance with consecutive breach detection. Commerce data becomes evidence if a dispute is filed.

Enforcement Layer: AAAResolverV1

The canonical dispute resolution resolver. An 11-state lifecycle from INITIATED through CLOSED, SETTLED, WITHDRAWN, or EXPIRED. Agreement-bound via AgreementTokenizerV1 — all three party tokens must be claimed before disputes can be filed. Accepts evidence as protocol-agnostic bytes32 hashes. The enforcement endpoint that determines outcomes when the other layers have produced evidence of a problem.

How They Compose

Resolvers do not call each other. They compose through three mechanisms:

IntegraRecordV1 iterates all gatekeepers — when ownership transfer is attempted, every attached IGatekeeperResolver.canOwn() must return true. Identity, commerce, and enforcement gatekeepers all get a vote.
Evidence hashes are protocol-agnostic — AAAResolverV1's submitEvidence() accepts any bytes32 hash. Communication records, commerce data, VI credentials, and physical document scans all reduce to the same interface. The hash is the boundary — what it points to is the caller's responsibility.
IntegraLens composes all state in one call — a single getRecordView() returns the state from every attached resolver, every available action, and the transfer policy status. One query, complete picture.

This composition model means any resolver can be upgraded or replaced without affecting the others. New resolver types can be added without modifying existing ones. The composition is configured at the record level, not hardcoded in any contract.

Design Principles

No Resolver Calls Another Resolver

Resolvers are composed by the record contract and the Lens, not by each other. Any resolver can be upgraded or replaced without affecting others. New resolver types can be added without modifying existing ones. The composition is configured at the record level, not hardcoded.

Single Responsibility

Each resolver has exactly one concern:

IdentityGatekeeperV1 does not track interactions or monitor SLA
CommunicationResolverV1 does not verify identity or enforce disputes
CommerceResolverV1 does not anchor messages or manage dispute lifecycle
AAAResolverV1 does not verify identity, record interactions, or track commerce

Evidence Is Protocol-Agnostic

AAAResolverV1's submitEvidence() accepts any bytes32 hash. It does not know or care whether the hash points to a communication record, a commerce measurement, a VI credential, or a physical document scan. The hash is the interface.

The Thin Waist Stays Stable

AAAResolverV1 has not changed for universal identity. It does not need to. The identity gatekeepers, communication resolver, and commerce resolver are new capabilities that plug in alongside it — not modifications to it. This is the architectural proof that the Resolver is the thin waist: new layers above and below, the waist unchanged.

IntegraLens

IntegraLens is a stateless view contract that composes all IContractV2 responses — tokenizer, resolvers, policy resolver — into a single RecordView struct. One off-chain eth_call returns:

Complete state from every attached resolver
Available actions with routing information (which contract to call, which schema to use)
Transfer policy status with human-readable restriction messages

IntegraLens holds no state of its own. It reads from IntegraRecordV1 and IntegraRegistryV1 to discover attached contracts, then calls IContractV2 on each one. All calls are wrapped in try/catch — if a contract does not implement IContractV2 or reverts, the Lens gracefully returns empty state for that source.

Because IntegraLens is pure view (no state, no storage, no admin), it carries zero upgrade risk and costs zero gas when called off-chain. It is the single integration point for any service that needs to understand a record's complete state — the contract intelligence layer, the front-end, the Provider Agent, and any third-party service that needs to inspect an agreement.

Every layer of the architecture was necessary. No single layer was sufficient.

On this page