Interaction Model

The interaction model defines the logical communication protocol between participants. Operations are semantic protocol operations and are independent of transport technologies.

Purpose

Participants exchange protocol messages to advance state, manage channels, and coordinate operations. This page defines the structure and semantics of those messages.

Connection Assumptions

The protocol assumes the communication channel:

• delivers messages reliably, without silent loss.
• delivers messages in order between any two participants.
• supports bidirectional message exchange.

The protocol does not require a specific transport technology.

Message Envelope

All protocol messages share a common envelope:

Field	Description
Type	Message type: request, response, event, or error.
RequestId	Numeric identifier unique within the connection.
Method	Operation name identifying the requested action.
Payload	Type-specific message data.
Timestamp	Message creation time in milliseconds.

Messages are encoded as compact ordered arrays:

[Type, RequestId, Method, Payload, Timestamp]

Message Types

Type
Request
Successful response
Reserved event notification
Error response

:::note Events Asynchronous event notifications are reserved for a future protocol revision. They will be defined alongside the relevant operations once specced. :::

Core Operations

Operation	Direction	Description
RequestCreation	User -> Node	Request to create a new channel.
SubmitState	User -> Node	Submit a signed state transition.
GetLatestState	User -> Node	Retrieve the current state for a channel.
GetHomeChannel	User -> Node	Retrieve on-chain home channel data.
GetEscrowChannel	User -> Node	Retrieve on-chain escrow channel data.

RequestCreation

Creates a new channel with an initial state. The request MUST include channel definition parameters, initial state, and the User's signature. The Node validates the channel definition, computes the channel identifier, verifies the User signature, co-signs the state, and stores the channel record.

The response includes the Node's signature over the submitted state.

SubmitState

Submits a User-signed state transition for processing. The request MUST include the signed state with a valid transition. The Node validates the state against advancement rules, verifies the User signature, co-signs the state, and applies side effects such as scheduling blockchain operations for non-OPERATE intents or creating receiver states for transfers.

The response includes the Node's signature over the submitted state.

GetLatestState

Retrieves the current state for a given User and asset. The response includes the latest state. Implementations MAY support filtering to return only mutually signed states.

GetHomeChannel

Retrieves on-chain home channel data for a given User and asset.

GetEscrowChannel

Retrieves on-chain escrow channel data for a given escrow channel identifier.

Correlation and Identifiers

Responses are correlated with requests using RequestId.

Rules:

• Each request MUST include a RequestId unique within the connection.
• The corresponding response MUST include the same RequestId.

Error Handling

Errors are communicated through error response messages.

Rules:

• Every failed operation MUST return an error response.
• The error payload MUST contain a human-readable error message.
• Errors MUST NOT expose internal implementation details.

Message Ordering

Message ordering requirements MAY depend on implementation. These protocol-level constraints apply:

• RequestId values MUST NOT be reused within a single connection.
• Future event notifications, once specified, MUST NOT block request processing.

State update ordering is governed by channel state versioning and advancement rules, not by the message transport layer.