Message Types and Routing: The OIP Communication Protocol

TL;DR

• OIP defines seven message types: STATE_SYNC, REGULATORY_ACTION, LOCK_MANAGEMENT, QUERY, ACK, HEARTBEAT, and GOVERNANCE. Each specification defined in prior research (regulatory actions, Lock Status, address resolution) now occupies a precise position within a unified message taxonomy.
• Message routing follows the Content-Based Routing principle. The content of a message, including its type, priority, target scope, and regulatory context, determines its delivery path. Senders do not designate recipients directly.
• Coordination strategy is determined by the message’s atomicity requirement: BEST_EFFORT (partial failure tolerated), GUARANTEED (all targets must confirm), and ALL_OR_NOTHING (entire network consistency required). The targetScope field determines where the message goes; the atomicity strategy determines how delivery is coordinated.
• The Routing Slip pattern is introduced so that routing decisions form progressively as messages pass through the OSS validation pipeline, with each stage appending its decision rather than overwriting prior ones.
• This specification completes the last foundational element before the v0.5 checkpoint, defining how the data structures, regulatory actions, address system, and Lock Status we have defined actually move.

---

Introduction: The Defined Things Do Not Yet Move

Looking back at the research that preceded this one, we have defined a considerable amount. Hierarchical Lock Status mapped the complex terrain of states an asset can occupy. The protocol specification for six regulatory actions defined who can change those states, on what authority, and under what conditions. ERC-3770 integration resolved the fundamental ambiguity of cross-chain address identity.

Yet one thing is missing from all of these definitions. The delivery mechanism.

Suppose a FREEZE message has been generated. It must pass through the OSS validation pipeline, enter D-quencer’s priority queue, and reach the target chains. But by what path? In what order? To whom? When crossChainScope.targetChains lists four chains, does the message go to all four simultaneously, or sequentially? If validation fails partway through, what happens to messages already sent?

Without answers to these questions, the specifications accumulated so far are like words entered into a dictionary without grammar. A language with no syntax. This research defines the oracle message routing grammar.

This research defines OIP’s message type taxonomy and routing protocol. We draw on message routing patterns from Enterprise Integration Patterns [1], a reference with deep roots in distributed systems design, while reinterpreting them for the specific demands of cross-chain state synchronization.

Oracle Message Routing: Type Taxonomy

Why Classification Matters

When OIP v0.1 established the basic message structure, the messageType field existed, but its complete set of valid values was never defined. The regulatory action protocol gave concrete form to one type, REGULATORY_ACTION, but that is one piece of a larger picture.

The reason to classify message types systematically is routing. Different message types follow different paths, carry different priorities, and pass through different validation rules. Without type classification, routing rules cannot be defined.

Seven Message Types

As of OIP v0.3, the following seven message types are defined:

enum OIPMessageType {
  STATE_SYNC          = 0x01,  // State synchronization request and execution
  REGULATORY_ACTION   = 0x02,  // Regulatory authority asset state change
  LOCK_MANAGEMENT     = 0x03,  // Lock status management (including preemptive lock)
  QUERY               = 0x04,  // State query (read-only)
  ACK                 = 0x05,  // Acknowledgment and execution result response
  HEARTBEAT           = 0x06,  // Node liveness and sync status reporting
  GOVERNANCE          = 0x07   // Protocol parameter change proposals and voting
}

This classification must be mutually exclusive and collectively exhaustive (MECE). Every communication in the OIP network must belong to exactly one of these seven types.

STATE_SYNC is OIP’s reason for existence. It synchronizes state changes between on-chain and off-chain systems, or across chains, and is the most frequent message type within an Oracle Session. Subtypes include INITIAL_SYNC (first-time state registration), INCREMENTAL_SYNC (delta updates), and FULL_RESYNC (complete re-synchronization).

REGULATORY_ACTION was fully specified in the regulatory action protocol. It carries the six regulatory actions (FREEZE, SEIZE, CONFISCATE, LIQUIDATE, RESTRICT, RECOVER) and receives P0 or P1 priority from D-quencer.

LOCK_MANAGEMENT operates the Hierarchical Lock Status framework established in the Lock Status architecture research. OSS’s preemptive lock mechanism executes through this type, with subtypes LOCK_ACQUIRE, LOCK_RELEASE, LOCK_EXTEND, and LOCK_ESCALATE.

QUERY is a read-only request that does not modify state. It queries the current Lock Status, regulatory context, or cross-chain synchronization state of a specific asset. This is the first type a DeFi protocol will use when interacting with OIP.

ACK is a response to other messages, ranging from simple receipt confirmation to full execution result reporting. It is used to confirm the completion of each phase in the cross-chain 3-Phase coordination (PREPARE → COMMIT → FINALIZE).

HEARTBEAT maintains network health. It is used for liveness reporting between D-quencer nodes, OSS synchronization status reporting, and per-chain connection monitoring.

GOVERNANCE handles protocol parameter changes. It is used in governance decisions including slashing rate adjustments, new chain onboarding, and regulatory authority registration.

Mapping Message Types to Prior Specifications

The table below maps each message type to the specifications defined in prior research:

Message Type	Related Specification	Lock Status Interaction	Address Resolution Required
STATE_SYNC	OIP v0.2 base structure	Acquires SOFT_LOCK before sync	Always (ERC-3770)
REGULATORY_ACTION	Full regulatory action protocol	Directly triggers state transitions	Always (ERC-3770)
LOCK_MANAGEMENT	Lock Status architecture	Direct control	Target asset only
QUERY	New (this specification)	Read-only	Optional
ACK	Cross-chain protocol	None	Source chain reference
HEARTBEAT	New (this specification)	None	None
GOVERNANCE	New (this specification)	None	None

Figure 1: OIP Message Type Taxonomy. Seven types, their prior specification references, Lock Status interactions, and address resolution requirements

Unified Message Header

All message types share a common header structure, generalizing the fields introduced in the regulatory action message specification:

interface OIPMessageHeader {
  // Protocol metadata
  version: string;                    // "0.3.0"
  messageId: string;                  // UUID v4
  messageType: OIPMessageType;        // One of seven types
  timestamp: string;                  // ISO-8601

  // Source information
  sourceChainId: string;              // CAIP-2 chain ID
  sourceNodeId: string;               // OSS node identifier
  signature: string;                  // Ed25519 signature

  // Routing metadata
  routing: RoutingMetadata;
}

interface RoutingMetadata {
  priority: Priority;                 // CRITICAL | REGULATORY | HIGH | NORMAL | LOW
  targetScope: TargetScope;           // Where the message goes
  atomicity: AtomicityStrategy;       // How delivery is coordinated
  ttl: number;                        // Time-to-Live (seconds)
  correlationId?: string;             // For request-response correlation
  routingSlip?: RoutingSlipEntry[];   // Processing path record
}

enum AtomicityStrategy {
  BEST_EFFORT     = "BEST_EFFORT",      // Partial failure tolerated
  GUARANTEED      = "GUARANTEED",        // All targets must confirm
  ALL_OR_NOTHING  = "ALL_OR_NOTHING"     // Entire network consistency required
}

interface TargetScope {
  targetChains?: string[];            // ERC-3770 shortName list
  targetAssets?: string[];            // Asset ID list
  targetAddresses?: string[];         // ERC-3770 format address list
}

The introduction of RoutingMetadata is the structural center of this specification. Prior messages described what they carried. Now how they are to be delivered is embedded in the message itself.

Two fields deserve attention. targetScope determines where the message goes: which chains, which assets, which addresses. atomicity determines how delivery to those targets is coordinated. These are independent concerns. A message targeting a single chain may still require ALL_OR_NOTHING atomicity if a regulatory action demands it; a message targeting five chains may tolerate BEST_EFFORT if it is a routine state query. The number of targets does not determine coordination strategy. The nature of the operation does.

Content-Based Routing: The Message Determines Its Own Path

Routing Principles

There are two fundamental approaches to routing in distributed messaging systems. In sender-determined routing, the sender directly specifies the recipient. In content-based routing, the content of the message determines the delivery path, and an intermediate router inspects the message to forward it to the appropriate recipient [1].

OIP adopts Content-Based Routing. The reasons are specific.

First, the scope of a regulatory action may not be fully determined at the time of issuance. When the SEC issues a FREEZE order, which chains hold the target asset can only be confirmed through an RWA Registry query by the OSS. Having the sender directly specify the target chain list is prone to incompleteness or error.

Second, the same message may take different paths depending on validation results. A STATE_SYNC message that passes OSS validation propagates to target chains, but if a regulatory compliance violation is detected, it can be escalated to a REGULATORY_ACTION. This kind of dynamic routing is difficult to implement in a sender-determined model.

Third, consistency without centralization of routing logic is required. All OSS nodes must apply the same routing rules and reach the same routing decision for the same message. When rules are grounded in message content, this deterministic property is straightforward to guarantee.

The Routing Decision Function

Routing decisions are formalized as:

Route(m) = f(m.messageType, m.routing.priority, m.routing.targetScope, m.routing.atomicity, context)

Here, context includes the current network state: the list of active nodes, per-chain connection status, and current epoch information. The output of this function is a tuple of ([Recipients], CoordinationStrategy, ProcessingPipeline).

class OIPContentRouter {

  route(message: OIPMessage, context: NetworkContext): RoutingDecision {

    // Step 1: Resolve recipients from target scope
    const recipients = this.resolveRecipients(
      message.header.routing.targetScope,
      context
    );

    // Step 2: Determine coordination strategy from atomicity requirement
    const coordination = this.determineCoordination(
      message.header.routing.atomicity,
      message.header.routing.priority
    );

    // Step 3: Determine processing pipeline from message type
    const pipeline = this.determinePipeline(message.header.messageType);

    return { recipients, coordination, pipeline };
  }

  private determineCoordination(
    atomicity: AtomicityStrategy,
    priority: Priority
  ): CoordinationStrategy {

    // CRITICAL priority forces ALL_OR_NOTHING regardless of declared atomicity
    if (priority === Priority.CRITICAL) {
      return {
        atomicity: AtomicityStrategy.ALL_OR_NOTHING,
        execution: "STAGED",          // PREPARE → COMMIT → FINALIZE
        confirmationRequired: "ALL",
        scopeOverride: "ALL_CHAINS"   // Expand to entire network
      };
    }

    switch (atomicity) {
      case AtomicityStrategy.BEST_EFFORT:
        return {
          atomicity,
          execution: "PARALLEL",
          confirmationRequired: "NONE",
          scopeOverride: null
        };

      case AtomicityStrategy.GUARANTEED:
        return {
          atomicity,
          execution: "STAGED",        // PREPARE → COMMIT → FINALIZE
          confirmationRequired: "ALL_TARGETS",
          scopeOverride: null
        };

      case AtomicityStrategy.ALL_OR_NOTHING:
        return {
          atomicity,
          execution: "STAGED",
          confirmationRequired: "ALL",
          scopeOverride: "ALL_CHAINS"
        };
    }
  }
}

The Active Asserter selected by D-quencer processes messages through this router. Whether the resolved recipient list contains one chain or twenty, the execution path is the same: the Active Asserter sends to each target. What differs is the coordination strategy, which governs whether targets are contacted in parallel or through a staged commitment protocol, and what happens when a subset of targets fails to respond.

Priority-Based Atomicity Escalation

The D-quencer priority system established in the regulatory action protocol assigns CRITICAL (P0) and REGULATORY (P1) ahead of standard transactions. This priority also governs atomicity.

Core rule: A message with CRITICAL priority is escalated to ALL_OR_NOTHING atomicity, with its target scope expanded to the entire network.

This escalation serves two distinct purposes. The first is race condition prevention. If a FREEZE command reaches only three of four target chains, assets can move on the remaining chain before the order arrives. An urgent regulatory action must reach the entire network before any counterparty can react.

The second is a prerequisite for cross-chain atomicity. The ALL_OR_NOTHING atomicity requirement defined in the regulatory action protocol holds only when all target chains receive the same message from the same network state. This is not a question of urgency; it is a question of consistency.

There is, however, an open design question that this mechanism surfaces: who holds the authority to assign CRITICAL priority in the message header, and under what verification? The current design assumes that CRITICAL is assigned to messages issued by regulatory authorities, but the trust model for that authority delegation, and the trade-off it creates with decentralization principles, is a design decision that warrants dedicated treatment. That discussion is deferred to the research on conflict resolution and concurrency control.

Figure 2: Priority-Based Confirmation Escalation. How message priority determines scope expansion and atomicity strategy, and the coordination behavior for each atomicity level

Atomicity-Driven Coordination

The three atomicity strategies defined in the regulatory action protocol are not abstract categories. They map directly to concrete coordination behaviors that govern how the Active Asserter delivers messages to target chains.

BEST_EFFORT: Parallel Delivery

BEST_EFFORT tolerates partial delivery failures. The Active Asserter sends to all resolved targets in parallel without waiting for individual confirmations before proceeding. It is the default for QUERY (read-only, no state modification), ACK (response messages), and HEARTBEAT (periodic, next message arrives shortly).

interface BestEffortCoordination {
  atomicity: "BEST_EFFORT";
  execution: "PARALLEL";
  timeout: number;              // Per-target timeout (ms)
  retryPolicy: {
    maxRetries: number;         // Default: 3
    backoffMs: number;          // Default: 1000 (exponential)
  };
}

The key element for request-response patterns (QUERY/ACK) is the correlation ID. When a QUERY message is sent, the ACK response returns to the sender, and correlationId is what binds the two together. In an asynchronous distributed environment where responses can arrive out of order, an explicit correlation mechanism is not optional.

GUARANTEED: Staged Commitment

GUARANTEED requires confirmation from all targets in the resolved scope before the operation is considered complete. It uses the staged commitment protocol: PREPARE is sent in parallel to all targets; COMMIT is sent only after all PREPARE confirmations are received. This is the default for STATE_SYNC and LOCK_MANAGEMENT, which modify state across chains and require all affected chains to reflect the change.

interface GuaranteedCoordination {
  atomicity: "GUARANTEED";
  execution: "STAGED";            // PREPARE → COMMIT → FINALIZE
  targets: {
    chains: string[];             // ERC-3770 shortName list from targetScope
    filterCriteria?: {
      assetRelevance: boolean;    // Only chains where the asset exists
    };
  };
  confirmationThreshold: number;  // Required success ratio (default: 1.0)
  phaseTimeouts: {
    prepare: number;              // ms to wait for PREPARE confirmations
    commit: number;               // ms to wait for COMMIT confirmations
    finalize: number;             // ms to wait for FINALIZE confirmations
  };
}

When inter-chain dependencies exist, such as when an asset must be locked on Chain A before it can be issued on Chain B, the execution within GUARANTEED coordination can be ordered sequentially. This is not a separate coordination mode but a constraint on the target ordering within the staged protocol.

ALL_OR_NOTHING: Network-Wide Atomic Coordination

ALL_OR_NOTHING requires the entire network to achieve consistent state. It uses the same staged commitment protocol as GUARANTEED, but with a critical difference: the target scope is expanded to all chains in the OIP network, regardless of the original targetScope in the message. This expansion ensures that every chain, including those not directly holding the target asset, is aware of the state change and can reject conflicting operations.

interface AllOrNothingCoordination {
  atomicity: "ALL_OR_NOTHING";
  execution: "STAGED";
  scopeOverride: "ALL_CHAINS";    // Overrides targetScope to entire network
  confirmation: {
    required: true;
    quorumType: "ALL";            // Every chain must confirm
  };
  rollbackOnFailure: {
    enabled: true;                // If any chain fails, roll back all
    maxRollbackWindow: number;    // ms before rollback is forced
  };
}

This is reserved for CRITICAL-priority REGULATORY_ACTION messages and GOVERNANCE proposals that alter protocol parameters. The cost of network-wide coordination is high, but the cost of partial execution of a regulatory enforcement action is higher: an asset freeze that only reaches three of four chains is a regulatory enforcement failure.

Default Atomicity by Message Type

Each message type carries a default atomicity strategy. This default can be overridden by priority escalation (CRITICAL forces ALL_OR_NOTHING) or by explicit specification in the message.

Message Type	Default Atomicity	Rationale
STATE_SYNC	GUARANTEED	State changes must reach all affected chains
REGULATORY_ACTION	ALL_OR_NOTHING	Regulatory enforcement cannot partially execute
LOCK_MANAGEMENT	GUARANTEED	Lock state must be consistent across chains
QUERY	BEST_EFFORT	Read-only, no state modification
ACK	BEST_EFFORT	Response message, loss triggers retry of original
HEARTBEAT	BEST_EFFORT	Periodic, next message arrives shortly
GOVERNANCE	ALL_OR_NOTHING	Protocol changes must apply network-wide

Routing Slip: Progressive Routing Decisions

The Problem: Routing Is Not Decided All at Once

The description so far may suggest that routing decisions are made in a single moment when a message arrives. In practice, they are not.

Consider a STATE_SYNC message arriving at the OSS. It must pass through:

1. Authority Verification: Does the sender have authority to request this state change?
2. Address Resolution: Convert ERC-3770 addresses to internal representation and confirm target chains.
3. State Transition Check: Is the requested state change valid given current Lock Status?
4. Regulatory Compliance: Is there any compliance violation?

The target chain list is confirmed at step 2. If a regulatory violation is detected at step 4, the message type itself may change. Routing decisions form progressively as the message moves through the pipeline.

The Routing Slip Pattern

To address this, we introduce the Routing Slip pattern [1]. A processing path record is attached to the message, and each stage appends its routing decision progressively.

interface RoutingSlipEntry {
  stage: string;               // Processing stage name
  nodeId: string;              // Node that processed this stage
  timestamp: string;           // Processing time
  decision: RoutingDecision;   // Routing decision at this stage
  mutations?: {
    typeChanged?: OIPMessageType;         // Type change (escalation)
    priorityChanged?: Priority;           // Priority change
    atomicityChanged?: AtomicityStrategy; // Atomicity escalation
    scopeExpanded?: string[];             // Target scope expansion
    scopeNarrowed?: string[];             // Target scope narrowing
  };
}

The essential property of the Routing Slip is that it is additive. Each stage appends its decision without overwriting prior decisions. The final routing is derived by composing the decisions from all stages. This additive constraint is not incidental; it is what makes the Routing Slip auditable and reproducible. An implementation that overwrites earlier decisions loses the traceability that makes post-hoc verification of routing behavior possible.

A concrete example: a DeFi protocol on Arbitrum requests STATE_SYNC for a tokenized bond.

// Initial message
{
  messageType: "STATE_SYNC",
  routing: {
    priority: "NORMAL",
    atomicity: "GUARANTEED",
    targetScope: { targetChains: ["arb1"] }
  }
}

// After Stage 1: Address Resolution
routingSlip: [{
  stage: "ADDRESS_RESOLUTION",
  decision: { /* address validity confirmed */ },
  mutations: {
    scopeExpanded: ["eth", "base"]  // Same asset exists on eth and base
  }
}]

// After Stage 2: Regulatory Compliance
routingSlip: [{...}, {
  stage: "REGULATORY_COMPLIANCE",
  decision: { /* AML pattern detected */ },
  mutations: {
    typeChanged: "REGULATORY_ACTION",         // STATE_SYNC → REGULATORY_ACTION
    priorityChanged: "REGULATORY",            // NORMAL → REGULATORY
    atomicityChanged: "ALL_OR_NOTHING"        // GUARANTEED → ALL_OR_NOTHING
  }
}]

A routine state synchronization request was escalated to a regulatory action upon AML pattern detection, with its atomicity strategy upgraded accordingly. Without the Routing Slip, tracing and auditing this dynamic transition would be significantly more difficult.

Pipeline-to-Message-Type Mapping

The processing pipeline for each message type is defined as follows:

Message Type	Pipeline Stages
STATE_SYNC	Address Resolution → Lock Acquisition → State Transition Check → Regulatory Compliance → Dispatch
REGULATORY_ACTION	Authority Verification → Address Resolution → State Transition Check → Legal Basis Verification → Cross-chain Consistency → Priority Dispatch
LOCK_MANAGEMENT	Address Resolution → Lock Conflict Check → Lock Execution → Dispatch
QUERY	Address Resolution → Permission Check → State Retrieval → Response
ACK	Correlation Matching → State Update → (Dispatch if forwarding needed)
HEARTBEAT	Node Verification → State Aggregation → Network Propagation
GOVERNANCE	Signature Verification → Proposal Validation → Vote Aggregation → (Execution if threshold met)

Note that REGULATORY_ACTION has the longest pipeline. This is intentional. Regulatory actions directly affect asset ownership and transferability and therefore require the most rigorous validation. The four-stage validation pipeline defined in the regulatory action protocol (Authority Verification → State Transition Check → Legal Basis Verification → Cross-chain Consistency) is preserved here in full.

Figure 3: Routing Slip progressive decision flow. How a STATE_SYNC message escalates to REGULATORY_ACTION through pipeline stages, with each stage appending rather than overwriting

Integrating ERC-3770 Address Resolution with Routing

The Role of the Address Resolution Stage

The ERC-3770-based address system defined in the address ambiguity research is the first gate in routing. The Address Resolution stage:

1. Converts ERC-3770 format addresses (arb1:0x742d35...) to their internal representation (CAIP-2 chain ID + raw address)
2. Queries the RWA Registry to verify that the address holds valid assets on valid chains
3. Confirms the targetScope of the message as a concrete list of target chains

The scopeExpanded or scopeNarrowed mutations this stage writes to the Routing Slip become the basis for all subsequent routing decisions.

class AddressResolver {

  async resolve(
    message: OIPMessage,
    registry: RWARegistry
  ): Promise {

    const targetAddresses = message.header.routing.targetScope.targetAddresses;
    const resolvedChains = new Set();

    for (const addr of targetAddresses) {
      // Parse ERC-3770
      const { shortName, rawAddress } = parseERC3770(addr);

      // If chain is explicit, use that chain only
      if (shortName) {
        resolvedChains.add(shortName);
      } else {
        // No chain specified: query RWA Registry for all chains
        // where this address holds assets
        const chains = await registry.findChainsForAddress(rawAddress);
        chains.forEach(c => resolvedChains.add(c));
      }
    }

    return {
      resolvedChains: Array.from(resolvedChains),
      scopeMutation: this.calculateScopeMutation(
        message.header.routing.targetScope.targetChains,
        resolvedChains
      )
    };
  }
}

The “address without chain context” problem raised in the address ambiguity research is resolved here. When 0x742d35... arrives without chain context, an RWA Registry query automatically includes all chains where that address holds assets in the target scope. This is the force of Content-Based Routing: the sender need not know every target chain. The system determines the correct targets from message content and registry state.

Address Extension and the Boundary of the TRUST Standard

The need for an extension standard to attach regulatory context to addresses, a direction raised in the address ambiguity research, remains valid. However, this extension will be addressed not in the OIP routing layer, but in ERC-TRUST Extensions’ external compliance module interface. The routing layer decides only “where does this message go.” “What is the regulatory status of this address” is a separate concern.

This separation is deliberate. Embedding regulatory judgment logic into routing rules would cause jurisdiction-specific regulatory variations to increase the complexity of the routing engine exponentially. Instead, routing determines destination purely, and regulatory compliance judgment is performed separately in the Regulatory Compliance stage of the Routing Slip. The prior research had proposed this as a potential independent standard; on further consideration, the variability of jurisdiction-specific rules makes a single standardization boundary impractical, and delegating the judgment through TRUST Extensions’ interface is the more defensible structure.

Fault Handling and Message Durability

Message Loss Scenarios

Message delivery in a cross-chain environment is inherently unreliable. Network partitions, node failures, and chain reorganizations can cause message loss. The following mechanisms address this.

At-Least-Once delivery guarantee: OIP guarantees that every message is delivered at least once. This is implemented by retransmitting when an ACK is not received. To handle duplicate delivery, all receiving nodes maintain a recent history of received messageId values and discard duplicates.

Idempotency requirement: As a consequence of At-Least-Once delivery, the same message may be processed more than once. All state-modifying messages (STATE_SYNC, REGULATORY_ACTION, LOCK_MANAGEMENT) must therefore be idempotent; applying the same message twice must produce the same result as applying it once.

interface MessageDeliveryGuarantee {
  deliverySemantics: "AT_LEAST_ONCE";

  deduplication: {
    windowSize: number;        // Deduplication window (default 300 seconds)
    strategy: "MESSAGE_ID";    // messageId-based deduplication
  };

  retry: {
    maxAttempts: number;       // Varies by message type
    baseBackoffMs: number;     // Exponential backoff base
    maxBackoffMs: number;      // Maximum wait time
  };

  deadLetter: {
    enabled: boolean;          // Move to Dead Letter Queue on final failure
    alertThreshold: number;    // DLQ message count alert threshold
  };
}

Retry policies by message type:

Message Type	Max Retries	Base Backoff	Max Backoff	DLQ
REGULATORY_ACTION (CRITICAL)	Unlimited	500ms	5s	Disabled (must deliver)
REGULATORY_ACTION (other)	10	1000ms	30s	Enabled
STATE_SYNC	5	2000ms	60s	Enabled
LOCK_MANAGEMENT	7	1000ms	30s	Enabled
QUERY	3	1000ms	10s	Disabled (failure response)
ACK	3	500ms	5s	Disabled
HEARTBEAT	0	N/A	N/A	Disabled (loss tolerated)

The unlimited retry on CRITICAL regulatory actions warrants attention. An asset freeze order that fails to deliver due to network issues is a regulatory enforcement failure, and that is not acceptable. Rather than routing to a Dead Letter Queue, every available means, including Active Asserter rotation, is employed to guarantee delivery.

HEARTBEAT carries no retries by design. It is a periodic message; if one is lost, the next will arrive shortly. Retrying would generate unnecessary network traffic with no operational benefit.

Open Questions Toward v0.5

This specification establishes the basic structure of OIP’s message type taxonomy and routing protocol. Several questions remain open.

Dynamic routing table updates: When a new chain joins the OIP network or an existing chain disconnects, how does the routing table update? The current design assumes explicit updates via GOVERNANCE messages, but a more dynamic mechanism may be needed. This question is a candidate for the protocol extensibility research, which will also explore how node subscription structures can support more granular topic-based routing.

Message size limits and fragmentation: Regulatory actions against large asset portfolios may contain dozens of asset IDs and chain lists. Single-message size limits and a fragmentation/reassembly protocol have not yet been defined.

Network propagation strategy: The node-to-node message propagation mechanism (how the Active Asserter’s messages physically reach all target nodes) has not been specified in this research. Options include direct point-to-point transmission and gossip-based protocols such as GossipSub. The choice depends on network size, latency requirements, and message priority. This is a candidate for the protocol extensibility research, where the full propagation layer will be designed.

Some of these will be partially resolved when state transition validation rules are specified in the next research. The remainder will be addressed comprehensively at the OIP v0.5 checkpoint.

---

Conclusion

We have specified how the things we defined actually move. Seven message types classify every communication in the OIP network. Content-Based Routing lets message content determine its own path. Atomicity-driven coordination ensures that the delivery strategy matches the consistency requirements of the operation, not the number of targets. The Routing Slip makes the progressive formation of that path, as the message traverses the pipeline, traceable and auditable.

The components from prior research now have their positions confirmed. Lock Status operates through STATE_SYNC and LOCK_MANAGEMENT messages. Six regulatory actions are classified as the REGULATORY_ACTION type and connected to D-quencer’s priority system. The ERC-3770 address system serves as the first gate in routing via the Address Resolution stage. Each piece occupies its place in the whole.

The value of a protocol lies not in the elegance of its individual definitions, but in the system that forms when those definitions are combined and set in motion. The next research will specify how, once a message is delivered, the receiving side determines whether a state transition is valid. Sending the message is half the work. The other half is verifying that the message describes a legitimate state change.

---

References

[1]. Hohpe, G. and Woolf, B. (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. https://www.enterpriseintegrationpatterns.com/patterns/messaging/

[2]. ligi. (2021). ERC-3770: Chain-specific addresses. https://eips.ethereum.org/EIPS/eip-3770

[3]. ethereum-lists/chains. Chain Registry. https://github.com/ethereum-lists/chains

[4]. Hohpe, G. (2003). Content-Based Router. Enterprise Integration Patterns. https://www.enterpriseintegrationpatterns.com/patterns/messaging/ContentBasedRouter.html

[5]. Hohpe, G. (2003). Routing Slip. Enterprise Integration Patterns. https://www.enterpriseintegrationpatterns.com/patterns/messaging/RoutingTable.html

Learn More

Previous research in the OIP Protocol series: When 0x742d35… Exists on Four Chains: How OIP Resolves Address Ambiguity

Regulatory action protocol specification: Protocol Specification for Regulatory Actions

Lock Status architecture: Asset State Management Complexity: Introducing Lock Status Architecture