Network Working Group L. Gebauer
Internet-Draft Independent
Intended status: Informational 24 June 2026
Expires: 26 December 2026
Internet Agent Communication Protocol
draft-gebauer-iacp-00
Abstract
Ever since 1969 and the ARPANET, the internet has repeatedly been
faced with challenges that it has had to overcome. With the advent
of autonomous AI agents, a new communication paradigm is required.
The Internet Agent Communication Protocol (IACP) defines a complete
architecture for secure, identity-centric agent-to-agent
communication, including identity-locator separation, a Deterministic
Hypermedia Interpreter (DHI), the EID Routing Protocol (ERP),
Persistent State Sessions (PSS), and decentralized governance
mechanisms.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Gebauer Expires 26 December 2026 [Page 1]
Internet-Draft IACP June 2026
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation and Problem Statement . . . . . . . . . . . . 4
1.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 5
1.4. Document Structure . . . . . . . . . . . . . . . . . . . 5
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5
2.1. Key Definitions . . . . . . . . . . . . . . . . . . . . . 5
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 6
3. Ephemeral Agent Identity (EID) . . . . . . . . . . . . . . . 6
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. EID Generation and Properties . . . . . . . . . . . . . . 7
3.3. Identity-Locator Separation Principles . . . . . . . . . 8
3.4. EID Persistence and Rotation Rules . . . . . . . . . . . 8
3.5. Forwarding Tickets and DHT-based Asynchronous
Resolution . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. EID Reputation and Cryptographic Ledger Attestation . . . 10
3.6.1. Cryptographic Attestation and Metrics . . . . . . . . 11
3.6.2. Threshold Enforcement and Session Downgrade . . . . . 11
4. Deterministic Hypermedia Interpreter (DHI) . . . . . . . . . 11
4.1. DHI General . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Execution Environment and UI Abstraction . . . . . . 12
4.1.2. The Agent Parser Ingestion Pipeline . . . . . . . . . 12
4.1.3. Resource Retrieval via Algorithmic Extraction (HRP &
APE) . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.4. Content Equivalence and Legacy Hand-off Invariants . 18
4.1.5. Separation of Concerns between DHI and Agents . . . . 20
4.2. EID Routing Protocol (ERP) - Subprotocol . . . . . . . . 22
4.2.1. Protocol Entities and Abstraction Layerr . . . . . . 22
4.2.2. Session Cryptography and Isolation Mechanics . . . . 23
4.2.3. Protocol Operations . . . . . . . . . . . . . . . . . 24
4.2.4. Secure Handshake and Connection Management . . . . . 28
4.2.5. Resource Governance . . . . . . . . . . . . . . . . . 29
4.2.6. Fault Tolerance, Resiliency, and Degraded
Operations . . . . . . . . . . . . . . . . . . . . . 31
4.2.7. Decentralized Security Governance and Slashing . . . 33
5. DHT Namespace Architecture and Distributed Security . . . . . 35
5.1. Distributed Hash Table . . . . . . . . . . . . . . . . . 35
5.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.2. DHT Namespace Structure . . . . . . . . . . . . . . . 36
5.2. Namespace Registration and Curation . . . . . . . . . . . 36
5.2.1. Root Namespace Registration . . . . . . . . . . . . . 36
5.2.2. Sub-Namespace Delegation . . . . . . . . . . . . . . 37
Gebauer Expires 26 December 2026 [Page 2]
Internet-Draft IACP June 2026
5.3. Proof-of-Work and Reputation-Based Access Control . . . . 37
5.3.1. Dynamic PoW Difficulty . . . . . . . . . . . . . . . 38
5.3.2. Access Tickets and Joint Liability . . . . . . . . . 38
5.4. Anti-Abuse Mechanisms . . . . . . . . . . . . . . . . . . 38
5.4.1. Token-Bucket Filters and Rate Limiting . . . . . . . 39
5.4.2. Autonomous Circuit Breakers . . . . . . . . . . . . . 39
5.5. Proof of Malfeasance (PoM) and Slashing . . . . . . . . . 39
5.5.1. PoM Ticket Specification . . . . . . . . . . . . . . 39
5.5.2. Two-Phase Slashing Escrow (2PSE) . . . . . . . . . . 40
5.5.3. Curator Quarantine and Decapitation . . . . . . . . . 41
5.6. Compromise Recovery and Hot-Docking . . . . . . . . . . . 41
6. Agent to Agent Communication . . . . . . . . . . . . . . . . 42
6.1. Ephemeral State Endpoints (ESE) . . . . . . . . . . . . . 42
6.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 42
6.1.2. Local Points (LP) . . . . . . . . . . . . . . . . . . 42
6.1.3. Global Points (GP) . . . . . . . . . . . . . . . . . 42
6.2. Discovery Spaces (DS) . . . . . . . . . . . . . . . . . . 43
6.3. Anonymous Discovery Mechanism . . . . . . . . . . . . . . 43
6.3.1. Discovery Request with Proof-of-Work and Ephemeral Keys
(DISCOVERY_REQ) . . . . . . . . . . . . . . . . . . . 43
6.3.2. Discovery Response and Secure EID Exchange
(DISCOVERY_RES) . . . . . . . . . . . . . . . . . . . 43
6.4. Persistent State Sessions (PSS) . . . . . . . . . . . . . 43
6.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 43
6.4.2. PSS Lifecycle and Handshake . . . . . . . . . . . . . 44
6.4.3. Dual-Cookie Handshake (PSS_INIT / PSS_NEG /
PSS_ACK) . . . . . . . . . . . . . . . . . . . . . . 44
6.4.4. Session Federation Contract (SFC) . . . . . . . . . . 45
6.4.5. Data Streaming and Sequence Vector Reconciliation
(PSS_DATA_STREAM) . . . . . . . . . . . . . . . . . . 45
6.5. Session Termination and Revocation . . . . . . . . . . . 45
6.5.1. Graceful Teardown (PSS_TEARDOWN) . . . . . . . . . . 45
6.5.2. Revocation and Proof of Malfeasance Publishing
(PSS_REVOCATION_PUBLISH) . . . . . . . . . . . . . . 45
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
7.1. IACP Message Type Registry . . . . . . . . . . . . . . . 46
7.2. IACP TLV Registry . . . . . . . . . . . . . . . . . . . . 47
7.3. IACP Flags Registry . . . . . . . . . . . . . . . . . . . 47
7.4. IACP Outer Transport Header Types . . . . . . . . . . . . 47
8. Security Considerations . . . . . . . . . . . . . . . . . . . 47
8.1. Identity and Authentication . . . . . . . . . . . . . . . 47
8.2. Confidentiality and Integrity . . . . . . . . . . . . . . 48
8.3. Denial-of-Service and Resource Exhaustion . . . . . . . . 48
8.4. Namespace and Curation Security . . . . . . . . . . . . . 48
8.5. Mobility, Churn, and Forwarding Tokens . . . . . . . . . 49
8.6. Privacy Considerations . . . . . . . . . . . . . . . . . 49
8.7. Residual Risks and Recommendations . . . . . . . . . . . 49
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
Gebauer Expires 26 December 2026 [Page 3]
Internet-Draft IACP June 2026
9.1. Normative References . . . . . . . . . . . . . . . . . . 50
9.2. Informative References . . . . . . . . . . . . . . . . . 50
Appendix A. Appendix A: Wire Formats of the IACP . . . . . . . . 51
Appendix B. Appendix B: State Machines and Transition Diagrams of
the IACP . . . . . . . . . . . . . . . . . . . . . . . . 63
Appendix C. Appendix C: ASCII-Diagrams of the IACP . . . . . . . 68
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 68
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 68
1. Introduction
1.1. Motivation and Problem Statement
Traditional Internet protocols and applications are designed for
human users interacting via visual browsers. With the rapid growth
of autonomous AI agents, the majority of future network participants
will be non-human, deterministic systems requiring native,
cryptographically secure, and identity-centric communication
primitives. Existing protocols lack strict identity-locator
separation, deterministic content interpretation, secure host
isolation, and decentralized governance suitable for agent-to-agent
interaction at scale.
1.2. Design Goals
The Internet Agent Communication Protocol (IACP) is designed to:
* Provide strict Ephemeral Agent Identity (EID) with identity-
locator separation using Ed25519 cryptography.
* Enable secure host isolation through the Local Loopback Layer
Entity (LL-Entity) and Instance Authentication Token (IAT).
* Deliver deterministic content processing via the Deterministic
Hypermedia Interpreter (DHI) with mathematical equivalence
guarantees (EVM <= 0.001).
* Support reliable agent-to-agent communication through Persistent
State Sessions (PSS) with Dual-Cookie handshake and optional
Session Federation Contracts (SFC).
* Establish decentralized namespace governance using a DHT with
Proof-of-Work curation, Proof of Malfeasance (PoM), and Two-Phase
Slashing Escrow (2PSE).
* Ensure mobility, fault tolerance, and security under churn via
generation counting, MIGRATION_VECTOR, and degraded multi-path
routing.
Gebauer Expires 26 December 2026 [Page 4]
Internet-Draft IACP June 2026
1.3. Scope and Non-Goals
This document defines the overall IACP architecture (e.g. the EID
Routing Protocol (ERP), DHI pipeline and state machines, wire
formats, PSS lifecycle, DHT namespace mechanics, and core security
model).
Out of scope are: concrete DHT implementation details, specific ANML
schema definition, lower-layer transport (QUIC usage is RECOMMENDED
but not mandated), and application-layer LLM semantics.
1.4. Document Structure
Section 2 defines terminology and conventions. Section 3 describes
the Core Architecture.
Section 4 specifies the EID Routing Protocol (ERP).
Section 5 covers Decentralized Security Governance.
Section 6 details Discovery and Agent-to-Agent Communication.
Section 7 contains Security Considerations.
Section 8 lists IANA considerations.
The Appendices provide wire-format diagrams and state machines.
2. Terminology and Conventions
2.1. Key Definitions
* *AAI* - Autonomous Agent Instance: Application-layer logic
executing autonomously and communicating via PSS.
* *EID* - Ephemeral Agent Identity: 32-byte cryptographic
identifier. Generated as Truncate_to_160Bit(SHA256(Ed25519 Public
Key)).
* *LL-Entity* - Local Loopback Layer Entity: Host-local shim between
AAI and network. Manages EID allocation, IAT validation,
encapsulation, and isolation.
* *IAT* - Instance Authentication Token: 32-byte high-entropy token
generated by LL-Entity for local AAI authentication.
* *DHI* - Deterministic Hypermedia Interpreter: Native agent
runtime. Performs ingestion pipeline, content equivalence
verification, and hands off to downstream LLM core.
* *ANML* - Agentic Network Markup Language: Structured markup for
deterministic agent-native content processing.
Gebauer Expires 26 December 2026 [Page 5]
Internet-Draft IACP June 2026
* *PSS* - Persistent State Session: Long-lived secure channel
between two EIDs, using Dual-Cookie handshake and optional SFC.
* *ESE* - Ephemeral State Endpoint: Information block hosted under
an EID (Local Point or Global Point).
* *ERP* - EID Routing Protocol: Control protocol for local
initialization, DHT mapping, mobility, and session management.
* *SFC* - Session Federation Contract: Optional agreement granting
direct ESE access between PSS peers.
* *DHT* - Distributed Hash Table: Global decentralized directory for
EID-to-locator mappings and namespace governance.
* *PoM* - Proof of Malfeasance: Cryptographic evidence of
equivocation or protocol violation.
* *2PSE* - Two-Phase Slashing Escrow: Challenge window before stake
slashing.
* *USIV* - Unified Semantic Ingestion Vector: {Source_EID,
Target_URI, Payload_Byte_Length, Payload_Pointer} passed across
IIB.
* *HCO* - Hand-off Context Object: Serialized structure for legacy
browser fallback containing ESD-EID.
* *ESD-EID* - Ephemeral Session Derivative EID: Temporary derivative
of EID used for sandboxed legacy execution.
2.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Ephemeral Agent Identity (EID)
Gebauer Expires 26 December 2026 [Page 6]
Internet-Draft IACP June 2026
3.1. General
To interact with the underlying network infrastructure, the Internet
Agent Communication Protocol (IACP) enforces a strict identity-
locator separation based on the core architectural principles of the
Host Identity Protocol (HIP, RFC 7401). Traditional internet
architectures conflate identity and location within a single IP
address layer, creating significant vulnerabilities and
inefficiencies for autonomous multi-agent workflows.
IACP addresses this structural flaw by decoupling an agent's
persistent logical identity from its volatile physical routing state.
An agent utilizes its current, transient IP address solely as an
ephemeral transport locator. This locator is bound via cryptographic
primitives to a unique, self-certifying pseudonym known as the
Ephemeral Agent Identity (EID).
+------------------------------------------------------------------+
| Application / LLM Context |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| Ephemeral Agent Identity (EID) Layer |
| [Cryptographic permanence / Stable Identity] |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| Transport Locator Layer |
| [Volatile IP Routing State / Dynamic Topology] |
+------------------------------------------------------------------+
While transport locators shift dynamically with network topology and
routing handovers, the EID operates as a long-lived logical
identifier. This structural separation abstracts network-level
transitions away from the application state. Every active agent
maintains an operational EID that is temporarily mapped to its host
IP address, providing continuous access to the global network,
Ephemeral State Endpoints (ESEs), and Persistent State Sessions
(PSS).
3.2. EID Generation and Properties
The Ephemeral Agent Identity (EID) is structured as a self-certifying
cryptographic identifier. It consists of a 32-byte public key
derived from an asymmetric keypair, specifically optimized using the
Ed25519 signature scheme for identity validation.
Gebauer Expires 26 December 2026 [Page 7]
Internet-Draft IACP June 2026
EID Cryptographic Properties: * Mathematical Decoupling: The EID
contains no routing metadata, geographic indicators, or topological
constraints. It is bound to network locators via authenticated,
dynamic mappings. * Verification Permanence: Any active peer can
verify the authenticity of protocol control packets by validating the
attached Ed25519 signature directly against the initiating EID. *
Integrity Vectors: The EID serves as the unique index key for
tracking distributed reputation matrices within the shared network
ledger, binding behavioral history directly to the identity.
3.3. Identity-Locator Separation Principles
The protocol operates a clean layer split where transport-layer
stream multiplexing and sequence verification are handled inside the
cryptographic umbrella of the EID, while IP routing tables process
the transport locators. This ensures that network anonymity is
preserved without sacrificing session stability.
+-----------------------+ +-----------------------+
| Initiator (Alice) | | Responder (Bob) |
| Stable Identity: EID | | Stable Identity: EID |
+-----------------------+ +-----------------------+
| |
================== IDENTITY-LOCATOR SEPARATION ==================
| |
+-----------------------+ +-----------------------+
| Transport Locator (IP)| | Transport Locator (IP)|
| [Volatile Routing] | | [Volatile Routing] |
+-----------------------+ +-----------------------+
When an agent alters its physical connection point or moves across
network bounds, the upper session layer remains completely unaware of
the physical interface change. By absorbing routing transitions
within the decoupled identity layer, ongoing computations, resource
extraction pipelines, and active state allocations remain
uninterrupted.
3.4. EID Persistence and Rotation Rules
To prevent longitudinal tracking and mitigate profiling risks across
the public routing topology, EID ephemerality is strictly bounded.
However, to maintain session stability, the EID remains persistent
across simple network handovers. EID rotation is explicitly
restricted and only triggered under the following three conditions:
1. Administrative Instruction: Upon an explicit administrative
directive issued by the managing user or parent orchestration
system.
Gebauer Expires 26 December 2026 [Page 8]
Internet-Draft IACP June 2026
2. Cryptographic Compromise: Immediately following a detected
security anomaly, private key exfiltration, or cryptographic
compromise.
3. Context Termination: Upon the successful completion or
termination of a designated operational task, autonomous session,
or Persistent State Session (PSS) context.
If an agent changes its network locator due to a simple routing
transition (such as migrating from Wi-Fi to mobile data networks),
identity persistence is managed directly between active peers. The
agent transmits a Signed Binding Update containing the new IP mapping
directly to its active communication partners. This optimization
keeps the EID stable during short-term handovers, preventing session
drops without requiring a full identity renegotiation or public
registration update.
To prevent malicious entities from utilizing rapid identity rotation
to evade accountability, EID ephemerality is bounded by a distributed
reputation architecture. Protocol deviations-such as unverified
session terminations or state invalidations-are signed and indexed
against the initiating EID within a decentralized substrate.
Rational nodes execute pre-flight validation of a target EID's
integrity vector before allocating state bounds or initializing
transitions.
3.5. Forwarding Tickets and DHT-based Asynchronous Resolution
Because direct binding updates require both endpoints to be
concurrently online, the architecture utilizes a decentralized
Distributed Hash Table (DHT) substrate (structured via Kademlia's XOR
metric) to resolve asynchronous identity-location decoupling. This
addresses real-world network constraints where nodes frequently cycle
offline or undergo asymmetric routing handovers.
Before an agent rotates its network parameters or enters an extended
offline state, it generates a cryptographic Forwarding Ticket. This
ticket contains the agent's updated routing metadata, is signed via
the Ed25519 secret key associated with the active EID, and is
deposited at the agent's last known coordinate within the DHT. The
precise routing coordinate within the DHT substrate is derived
deterministically via:
KEY = SHA-256(EID_AGENT)
The storage transaction uses the DHT_TICKET_STORE format (Type 0x05).
The payload contains the Target Storage Key, the target agent's true
EID, a 4-byte Time-to-Live (TTL) field, a 12-byte AEAD Nonce, 36
Gebauer Expires 26 December 2026 [Page 9]
Internet-Draft IACP June 2026
bytes of Encrypted Forwarding Data (protected via the shared secret
key established during the active Persistent State Session), and an
authoritative 64-byte Ed25519 digital signature generated by the
owner.
When a peer wakes up or reconnects after an extended offline period,
it queries the DHT at the historical coordinate of the targeted agent
by dispatching a DHT_TICKET_QUERY packet (Type 0x06).
The querying node populates the target key field, attaches an 8-byte
Transaction ID, and logs its own EID. The responding DHT node
returns a DHT_TICKET_RESP packet (Type 0x07) containing matching
transaction metadata, a 4-byte Status Code, and the encrypted ticket
payload.
Upon retrieval, the querying peer decrypts the Forwarding Ticket
using the pre-established shared session key. This structural lookup
reveals the targeted agent's updated network locator and current
routing parameters. The communication channel is subsequently
restored via a sequential state synchronization routine utilizing
sequence state vector reconciliation, ensuring complete state
continuity without corruption.
+--------------------------+
| [0x05] DHT_TICKET_STORE |
+--------------------------+
|
v (Agent Goes Offline / Rotates Locator Parameters)
+--------------------------+
| [0x06] DHT_TICKET_QUERY |
+--------------------------+
|
v (DHT Fabric Processes XOR Routing Metrics)
+--------------------------+
| [0x07] DHT_TICKET_RESP |
+--------------------------+
3.6. EID Reputation and Cryptographic Ledger Attestation
EID is bound to a dynamic, non-repudiable transaction reputation
metric managed within the distributed directory overlay layer.
Because EIDs are decoupled from the network transport locators (IP
addresses), reputation tracking is executed directly against the
256-bit EID public key coordinate. This prevents malicious instances
from shedding negative operational history through transport
interface rotation or routing hop modification.
Gebauer Expires 26 December 2026 [Page 10]
Internet-Draft IACP June 2026
3.6.1. Cryptographic Attestation and Metrics
The local host interface or tracking nodes maintain an immutable,
signed validation log. Reputation states are computed as a composite
function of sequence compliance, processing availability, and
validation history:
R_State = Function(S_Verify || A_Telemetry || PoM_Tickets)
Where: * S_Verify constitutes the ratio of cryptographically valid
signatures on critical control frames (PSS_INIT, PSS_ACK). *
A_Telemetry dictates the verified processing availability index under
active Session Federation Contracts (SFC). * PoM_Tickets represents
the accumulation index of validated Proof of Malfeasance tickets
transmitted to the global directory layer.
3.6.2. Threshold Enforcement and Session Downgrade
Peering nodes evaluating a connection initialization vector
(PSS_INIT) MUST query the target EID's current reputation coordinate
inside the directory keyspace before moving from STATE_HEARING to
STATE_ESTABLISHED.
If the reputation metric falls below a pre-configured local
threshold, the incoming packet ingestion layer MUST enforce one of
the following deterministic circuit-breaker states: 1. *Dynamic PoW
Escalation:* The host interface increases the required zero-
allocation Hashcash Proof-of-Work trailing-zero bit length
exponentially for the target entity. 2. *Channel Micro-Throttling:*
The local engine restricts bandwidth and token-bucket allocation
values via hardcoded execution shims, forcing a degraded multi-path
transport pipeline. 3. *Immediat Block and Slashing Routing:* Upon
detection of an unexpired curator quarantine flag or active 2PSE
ticket reference, the protocol runtime drops the packet without
volatile memory allocation and propagates an immediate blacklisting
broadcast across the network topology.
4. Deterministic Hypermedia Interpreter (DHI)
4.1. DHI General
Gebauer Expires 26 December 2026 [Page 11]
Internet-Draft IACP June 2026
4.1.1. Execution Environment and UI Abstraction
The Deterministic Hypermedia Interpreter (DHI) executes all
processing, resource extraction, and cross-agent operations. It
serves as the native runtime for ESE hosting, PSS state management,
and data queries. The DHI delegates all name resolution and
transport endpoint discovery to the Local Loopback Layer Entity (LL-
Entity) defined in the EID Routing Protocol (ERP). It omits
traditional visual user interfaces and uses a structured agent-
optimized Search Tree instead. The DHI maintains strict content
equivalence with human-centric web payloads. It maps identical
content into an abstract representation without data loss. Documents
using Agentic Network Markup Language (ANML) are processed natively.
Functional requests that cannot be translated into pure informational
states are handed off to a conventional browser environment.
4.1.2. The Agent Parser Ingestion Pipeline
When an Autonomous Agent Instance (AAI) receives a legacy
alphanumeric domain name or URI, the DHI forwards the resolution
request to the local LL-Entity. The LL-Entity performs EID
resolution or transport locator mapping, using the ANML Fallback
Query (Type 0x12) if no direct mapping exists. The Agent Parser then
operates as a deterministic finite state machine (FSM) and enforces
the following sequential execution pipeline:
4.1.2.1. State Machine Transitions and Pipeline Execution
The ingestion pipeline MUST proceed according to the following state
machine and transitional logic:
Gebauer Expires 26 December 2026 [Page 12]
Internet-Draft IACP June 2026
+-----------------------+ +------------------------+
| INIT / INPUT URI | --> | [1] DNS_SRV_EVALUATION|
+-----------------------+ +------------------------+
|
v
+-----------------------+
| [2] WELL_KNOWN_EVAL |
+-----------------------+
|
+-----------------------+-------------+
| (If Unreachable) |
(If Unreachable) (If Reachable)
v v
+-----------------------+ +-----------------------+
| [2.1] PROBLEM_CACHE | | [3] LINK_HEADER_SNIFF|
+-----------------------+ +-----------------------+
| |
(TERM_EXECUTION) v
+-----------------------+
| [4] BASELINE_CORE |
+-----------------------+
|
v
+-----------------------+
| [4.1] SWITCH_POINT |
+-----------------------+
[1] DNS_SRV_EVALUATION: Initiates a DNS SRV query to discover agent-
native endpoints and configuration parameters.
[2] WELL_KNOWN_EVAL: Issues a request to /.well-known/anml.
[2.1] PROBLEM_CACHE: On unreachable endpoint, HTTP 404 or timeout,
logs the fault, creates a temporary block record with 300s TTL, and
terminates execution.
[3] LINK_HEADER_SNIFF: Scans response headers for RFC 8288 Link
entries pointing to ANML resources.
[4] BASELINE_CORE: Aggregates discovery data and passes context to
the SWITCH_POINT.
[4.1] SWITCH_POINT: Non-terminal state that evaluates whether to
follow the NATIVE_ANML_PATH or LEGACY_PATH_EXECUTION.
Conforming implementations MUST enforce the following constraints:
a. Socket poll timeout: T_eval = 15000 ms in non-blocking mode.
Gebauer Expires 26 December 2026 [Page 13]
Internet-Draft IACP June 2026
b. Maximum floating buffer: MAX_FLOAT_BUF = 4194304 bytes. Inbound
data MUST be accumulated sequentially in a volatile local FIFO
buffer.
c. If structural context resolves before T_eval expires and
MAX_FLOAT_BUF is not exceeded, transition immediately to
NATIVE_ANML_PATH [4.3].
d. On T_eval expiry or buffer overflow, immediately truncate the
buffer, terminate the fast-path stream, and transition to
LEGACY_PATH_EXECUTION [4.2] or PROBLEM_CACHE.
4.1.2.2. The Switch Point Logical Invariants
The state SWITCH_POINT [4.1] represents the critical architectural
boundary where the communication stream is fork-routed based on two
mutually exclusive parameters: the presence of ANML metadata and the
active operational constraints of the calling agent.
+--------------+
| SWITCH_POINT |
+--------------+
|
+-----------------------+---------------------+
| |
(ANML Found) (ANML Absent)
v v
+---------------------+ +--------------------+
|[5] USER_REQ_CHECK | | [4.2] LEGACY_PATH |
+---------------------+ +--------------------+
| |
+------+------+ |
| | |
(Rich Assets) (Text Only) |
v v v
+-----------+ +-----------+ (Browser Hand-off)
| [4.2] LGC | | [4.3] NAM | |
+-----------+ +-----------+ v
| | (TERM_FAST_PATH)
+------+------+
|
v
+---------------------+
| [6] DOWNSTREAM_SUB |
+---------------------+
Gebauer Expires 26 December 2026 [Page 14]
Internet-Draft IACP June 2026
A. ANML Non-Existence Path: If no valid ANML endpoints, pointers, or
metadata tags are detected during states [2] or [3], the FSM MUST
execute a transitional branch to LEGACY_PATH_EXECUTION [4.2]. The
parser triggers the standard web fallback mechanism, initiates heavy
media layout rendering via a headless DOM engine, and hands over
context to a sandboxed browser environment. Native fast-path parsing
is instantly terminated.
B. ANML Existence Path: If valid ANML infrastructure is found, the
FSM transitions directly to the USER_REQUIREMENT_CHECK [5]. This
sub-state evaluates explicit runtime constraints and asset criteria
passed by the client agent concerning non-text-based payload
components (e.g., raster images, audio, video vectors).
i. If rich-media or layout asset dependencies are explicitly
required by the user constraints, the machine drops the
fast-path and triggers LEGACY_PATH_EXECUTION [4.2] to
guarantee complete content availability.
ii. If the user constraint matrix allows text-only/semantic-only
extraction, or if no rich assets are requested, the machine
transitions to NATIVE_ANML_PATH_INGESTION [4.3]. The engine
initiates a direct, machine-first stream of the raw markup,
completely bypassing visual layout, Cascading Style Sheets
(CSS), and human-centric JavaScript rendering engines.
Execution paths converging from native ingestion or fallback
processing MUST deliver their finalized object payloads to the
DOWNSTREAM_PROCESSING_SUBSYSTEMS [6] to drive HRP, APE, and active
LLM core workflows.
4.1.2.3. Protocol Specification for Problem Caching Cycles
To prevent distributed denial-of-service (DDoS) loops and mitigate
computational overhead induced by repetitive agentic polling of
broken endpoints, implementations MUST conform to the strict fault-
handling requirements of the PROBLEM_CACHE [2.1] state:
1. Fault Isolation: When an ANML discovery error occurs, the
localruntime environment MUST encapsulate the network fault layer
fromthe executing agent logic.
2. TTL Enforcement: The fault record logged by the Problem
CachingCycle MUST specify a minimum Time-To-Live (TTL) value of
300seconds. During this active window, any subsequent
outboundingestion requests from the same host to the failing
target URIMUST be short-circuited locally at the parser layer.
Gebauer Expires 26 December 2026 [Page 15]
Internet-Draft IACP June 2026
3. State Clearance: Upon expiration of the local fault TTL
record,the parser MUST transition back to an unblocked state,
allowinga single sequential pipe verification attempt on the next
targetinvocation.
4.1.3. Resource Retrieval via Algorithmic Extraction (HRP & APE)
To maximize data harvesting efficiency and minimize transport layer
overhead, resource discovery within the DHI Search Tree MUST rely on
the concurrent execution of two deterministic architectural
subsystems: Heuristic Relevancy Probability (HRP) and Automated
Pipeline Extraction (APE).
+---------------------------------+
| DHI Search Tree Target Nodes |
+---------------------------------+
|
v
+---------------------------------+
| [2.3.1] HRP Matrix Evaluation |
| HRP(n) = w1*S + w2*R + w3*C |
+---------------------------------+
|
v
+---------------------------------+
| [2.3.2] APE Filter Mechanism |
| Is HRP(n) >= Theta? |
+---------------------------------+
|
+-------------------+-------------------+
| (Yes) | (No)
v v
+------------------------------+ +---------------------------+
| [2.3.3] Parallel Execution | | Prune / Drop Node Stream |
| Fast Path / Queue Priority | | (Zero Network Traffic) |
+------------------------------+ +---------------------------+
4.1.3.1. Heuristic Relevancy Probability (HRP)
Every target node (n) or Uniform Resource Identifier (URI) within the
active discovery search space is algorithmically assigned a dynamic,
scalar probability value HRP(n) bounded by the interval [0.0, 1.0].
This value represents the statistical likelihood that the designated
resource node contains the precise target payload requested by the
calling agent.
Gebauer Expires 26 December 2026 [Page 16]
Internet-Draft IACP June 2026
Implementations MUST calculate HRP(n) continuously via localized
execution engines natively embedded within the DHI execution layer,
conforming to the following weighted vector equation:
HRP(n) = (w1 * S(A, Tn)) + (w2 * R(En)) + (w3 * C(Hn))
The formal invariants of the calculation matrix are defined as:
1. Semantic Similarity Vector S(A, Tn): The mathematical
cosinesimilarity calculated within the latent embedding space
betweenthe agent's operational request vector (A) and the
extractedmetadata token or anchor text vector (Tn) of the target
node.
2. Reputation Weight R(En): A scalar value derived from
thecryptographic verification of curator assertions recorded
withinthe distributed hash table (DHT) namespace layer.
3. Contextual History C(Hn): A historical convergence metrictracking
the agent's prior retrieval success rates acrossidentical URI
sub-paths and structural path patterns.
4. Weight Vector Normalization: The system-defined weights (w1,
w2,w3) are configuration-specific invariants and MUST satisfy
thenormalization constraint: w1 + w2 + w3 = 1.0.
4.1.3.2. Automated Pipeline Extraction (APE)
The APE engine acts as the deterministic execution arm of the DHI,
ingesting the compiled HRP matrix to orchestrate parallelized network
transport traversals.
1. Threshold Filtering: The APE engine MUST enforce a
dynamicthreshold variable Designated as Theta (O). If a target
nodeevaluates to a metric where HRP(n) < O, the engine MUST
prunethe node from the active traversal path, suppressing
outboundnetwork socket allocation for that node.
2. Parallel Socket Allocation: For nodes satisfying HRP(n) >= O,
theAPE engine maps execution priority directly to the scalar
HRPweight:
a. Fast Path Ingestion: Nodes displaying an HRP(n) metric above a high-probability boundary (HRP(n) >= 0.85) MUST be allocated immediate, dedicated streaming TCP/IACP connections.
b. Asynchronous Queue: Nodes displaying mid-range probabilities (O <= HRP(n) < 0.85) MUST be buffered within a prioritized asynchronous download queue, executed concurrently based on available system bandwidth.
Gebauer Expires 26 December 2026 [Page 17]
Internet-Draft IACP June 2026
1. Path Optimization: When multi-hop graph traversal within
theAgentNet topology is required, the APE engine MUST compute
themathematically optimal extraction path by executing a
directedacyclic graph (DAG) search algorithm, utilizing the
inverse ofthe HRP(n) value as the primary edge-cost function.
4.1.4. Content Equivalence and Legacy Hand-off Invariants
4.1.4.1. Mathematical Equivalence Metrics
To verify structural and content parity during state transformation,
the runtime MUST evaluate the Equivalence Verification Metric (EVM).
The mathematical evaluation process is defined as follows:
1. Entropy Delta Calculation: The runtime MUST compute the
absolutedifference in Shannon entropy between the legacy DOM
structureand the compiled abstract search tree representation:
EVM = | H_web - H_tree |
Conforming states MUST satisfy the condition EVM <= 0.001.
1. Cryptographic Invariant Validation: To prevent semantic damagevia
lexical permutation or omission, the runtime MUST compute
aSHA-256 hash comparison. This comparison MUST NOT be executedon
raw document source code or abstract tree topology blocks.
2. Canonical Node Ingestion: The SHA-256 hashing algorithm
MUSToperate exclusively on a linearized buffer composed of
theextracted and canonicalized pure text nodes. These nodes
MUSTbe ingested sequentially in an identical,
deterministicdocument traversal order (depth-first, left-to-
right).
3. Parity Invalidation: If the computed SHA-256 signatures of thetwo
canonical text sequences display any divergence, the
stateequivalence evaluation MUST fail instantly, forcing a
hardtransition to the LEGACY_PATH_EXECUTION [4.2] fallback.
4.1.4.2. Interface Specification for Legacy Path Hand-off Context
When the SWITCH_POINT [4.1] or USER_REQUIREMENT_CHECK [5] drops the
fast-path due to missing ANML infrastructure or explicit rich-media
asset requirements, the DHI MUST compile and serialize a standardized
Hand-off Context Object (HCO). The HCO is transmitted across the
functional boundary to the sandboxed legacy browser engine.
Gebauer Expires 26 December 2026 [Page 18]
Internet-Draft IACP June 2026
+---------------------------------------+
| DHI Local Ingestion Fast-Path Layer |
+---------------------------------------+
|
(Trigger: Legacy Fallback)
|
v
+---------------------------------------+
| [2.4.3] Serialization of Hand-off |
| Context Object (HCO Payload) |
+---------------------------------------+
|
+--------------------+--------------------+
| |
[Byte 0-31]: Active EID [Byte 32-63]: Session Hash
| |
[Byte 64-67]: Sequence [Byte 68-71]: Capabilities
| |
+--------------------+--------------------+
|
v
+---------------------------------------+
| Sandboxed Legacy Browser Container |
+---------------------------------------+
4.1.4.3. HCO Wire-Level Structural Layout
The serialized HCO binary block MUST conform to the following layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hand-off Trigger Context Type (2 Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Ephemeral Session Derivative EID (ESD-EID) |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Persistent State Session Hash |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target URL Length (2B) | Target URL String (UTF-8)... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gebauer Expires 26 December 2026 [Page 19]
Internet-Draft IACP June 2026
A. Hand-off Trigger Context Type (2 Bytes): Unsigned integer
identifying the execution failure or unmappable state that triggered
the legacy hand-off.
B. Ephemeral Session Derivative EID (ESD-EID) (32 Bytes): Temporary
cryptographic token generated by the LL-Entity for this session only.
It is derived from the permanent EID combined with a session nonce.
The real long-lived EID MUST NOT be exposed to the sandbox. The LL-
Entity MUST intercept and validate this derivative on return.
C. Persistent State Session Hash (32 Bytes): Cryptographic digest of
the active session context.
D. Target URL Length (2 Bytes): Length of the following UTF-8
string.
E. Target URL String: Variable-length UTF-8 destination resource.
The sandboxed legacy browser MUST use only the ESD-EID for any
outbound network activity. All such traffic is routed back through
the LL-Entity for validation.
4.1.5. Separation of Concerns between DHI and Agents
To preserve decoupling across the architectural stack,
implementations MUST enforce a separation between the DHI and
downstream application layers (e.g., Large Language Model core
workflows).
+-------------------------------------------------+
| Deterministic Hypermedia Interpreter (DHI) |
+-------------------------------------------------+
|
(Executes Pipeline [1] to [5])
|
v
+-------------------------------------------------+
| [2.5.1] The Ingestion Interface Boundary (IIB) |
| Validates, Canonicalizes & Buffers |
+-------------------------------------------------+
|
(Unified Semantic Ingestion Vector)
|
v
+-------------------------------------------------+
| Downstream LLM Core / Schema Processing |
+-------------------------------------------------+
Gebauer Expires 26 December 2026 [Page 20]
Internet-Draft IACP June 2026
4.1.5.1. The Ingestion Interface Boundary (IIB)
The DHI framework terminates structurally at the Ingestion Interface
Boundary (IIB). The responsibilities of the IACP layer within this
boundary are strictly limited to the following operational tasks:
1. Transport Termination: Managing network sockets, executing
pathdiscovery, processing Link headers, and enforcing HRP/
APEalgorithms.
2. Payload Canonicalization: Stripping transport headers,
resolvingmulti-hop DAG data fragments, and assembling raw
incoming streamsinto a unified, sequential memory buffer.
3. Structure Validation: Verifying that incoming data objects
matcheither the native ANML specification invariants or the
fallbacklegacy tree representation before state delivery.
4.1.5.2. Unified Semantic Ingestion Vector (USIV)
Data transition across the IIB into the application layer MUST occur
exclusively via the standardized Unified Semantic Ingestion Vector
(USIV). The DHI assembles the USIV with the following structure:
USIV = { Source_EID, Target_URI, Payload_Byte_Length, Payload_Pointer
}
A. Source_EID: 32-byte cryptographic identifier of the origin
infrastructure node.
B. Target_URI: Variable-length UTF-8 descriptor of the historical
retrieval coordinate.
C. Payload_Byte_Length: 4-byte unsigned integer declaring the
precise byte length of the canonicalized payload allocation block.
D. Payload_Pointer: Reference to the raw, unmodified ANML markup
stream or legacy fallback data block in the local volatile heap.
4.1.5.3. Downstream Application Layer Demarcation
Upon delivery of the USIV across the IIB, the IACP network stack
relinquishes all state execution context and memory management
responsibility. The downstream application layer (LLM Core) assumes
exclusive processing authority and full ownership of the referenced
memory block:
Gebauer Expires 26 December 2026 [Page 21]
Internet-Draft IACP June 2026
1. The DHI layer MUST NOT interpret, compile, or execute any
semanticlogic contained within the payload buffer.
2. The downstream application layer MUST safely deallocate the
memoryblock referenced by Payload_Pointer after processing is
complete(or upon termination of the associated agent context) to
preventmemory leaks.
3. Parsing of specialized markup tags, schema mapping,
intentionextraction, and token-based prompt synthesis are native
functionsof the LLM workflow and MUST remain completely isolated
from thenetwork protocol runtime.
4. Any operational failures or exception conditions arising
frominvalid application-level schema interpretation within the
bufferMUST NOT cause state invalidations or drops within the
activeunderlying IACP transport layers.
4.2. EID Routing Protocol (ERP) - Subprotocol
4.2.1. Protocol Entities and Abstraction Layerr
4.2.1.1. Autonomous Agent Instance (AAI)
An Autonomous Agent Instance (AAI) constitutes the application-layer
endpoint within the IACP network architecture. An AAI executes logic
autonomously and initiates or consumes network transactions via
Persistent State Sessions (PSS). On the wire protocol level, an AAI
is uniquely identified by its assigned cryptographic Ephemeral Agent
Identity (EID). The AAI acts as an isolated security domain; its
internal execution states, memory spaces, and local application
contexts MUST remain strictly decoupled from other AAIs operating on
the same host infrastructure.
4.2.1.2. Local Loopback Layer Entity (LL-Entity)
The Local Loopback Layer Entity (LL-Entity) is the abstract,
platform-agnostic shim layer operating on the local host to manage
cryptographic identities and session states. Positioned between the
AAI and the transport network, the LL-Entity acts as an identity
mapping shim. It handles the local allocation of EIDs, manages
local-to-global network bindings, and performs the cryptographic
encapsulation of outbound data streams.
Gebauer Expires 26 December 2026 [Page 22]
Internet-Draft IACP June 2026
The protocol defines the LL-Entity strictly as a functional network
boundary exchanging data via a defined local wire format.
Implementations MUST ensure the LL-Entity isolates routing contexts
without utilizing volatile operating system metadata (such as PIDs).
The exact engineering realization (e.g., user-space process, kernel
module, or shared memory boundary) is out of scope.
Distributed Hash Table (DHT) & Global Directory
Quorum
The Distributed Hash Table (DHT) and the Global Directory Quorum form
the decentralized overlay network of the IACP infrastructure. The
DHT serves as a tamper-proof, globally distributed directory
repository responsible for storing, propagating, and validating the
authoritative mappings between an AAI's logical EID and its transient
physical transport endpoint (IP address).
A Global Directory Quorum consists of a mathematically defined subset
of independent overlay nodes responsible for achieving consensus on
mapping registrations, processing updates, and validating
cryptographic proofs such as Proof of Malfeasance (PoM) tokens. AAIs
interact with the DHT overlay indirectly through the local LL-Entity
or via explicit routing headers to discover peer endpoints and
establish verified multi-hop connections.
4.2.2. Session Cryptography and Isolation Mechanics
4.2.2.1. Ephemeral Agent Identity (EID)
An Ephemeral Agent Identity (EID) acts as the unique, stable
cryptographic identifier for an Autonomous Agent Instance (AAI)
within the IACP routing domain. The LL-Entity generates an
asymmetric cryptographic key pair using the Ed25519 signature scheme
for each unmapped context. The canonical EID string is defined as
the truncated cryptographic hash of the raw public key:
EID = Truncate_to_160Bit( SHA256( Public_Key ) )
The private key remains strictly within the storage bounds of the LL-
Entity and MUST NOT be exposed to the AAI. The AAI utilizes the
public EID to sign network transactions implicitly by issuing
standardized control frames to the local channel interface.
Gebauer Expires 26 December 2026 [Page 23]
Internet-Draft IACP June 2026
4.2.2.2. Instance Authentication Mechanism (IAT)
To achieve strict local host isolation and prevent session hijack
vulnerabilities stemming from reused or recycled operating system
parameters (e.g., Process IDs), the ERP enforces an unforgeable local
token architecture. Upon initial context initialization, the LL-
Entity constructs a high-entropy, 256-bit Instance Authentication
Token (IAT).
IAT = CSPRNG(256)
The LL-Entity binds the generated EID directly to this unique IAT.
For all subsequent local frame transmissions over the loopback layer
interface, the AAI MUST include the designated IAT within the
encapsulation header. The LL-Entity validates the presence and
mathematical correctness of the token before modifying any local
routing table states or performing cryptographic data
transformations.
4.2.2.3. Liveness Monitoring and "Context Garbage" Collection
To secure local resources and prevent memory state exhaustion from
orphaned cryptographic contexts (e.g., following an abrupt
application-layer crash or uncoordinated termination of an AAI), the
ERP specifies an automated liveness monitoring mechanism.
1. ERP_KEEPALIVE Invariant: The AAI MUST transmit a periodic
ERP_KEEPALIVE control frame to the LL-Entity over the local wire
format channel at fixed intervals of T_alive = 30 seconds.
2. Verification: Each ERP_KEEPALIVE frame MUST carry the valid
Local_IAT associated with the respective session context.
3. Garbage Collection: If the LL-Entity detects a continuous silent
period exceeding the timeout limit of T_timeout = 90 seconds for
a specific context, the active session state is marked as stale.
The LL-Entity MUST instantly purge the associated cryptographic
material, wipe the keys from memory, and initiate an automated
global deregistration routine within the DHT overlay to
invalidate the stale EID-to-IP mapping.
4.2.3. Protocol Operations
Gebauer Expires 26 December 2026 [Page 24]
Internet-Draft IACP June 2026
4.2.3.1. Local Initialization and Allocation Phase (ERP_INIT /
ERP_ALLOC)
The interaction between an Autonomous Agent Instance (AAI) and the
Local Loopback Layer Entity (LL-Entity) occurs exclusively via
standardized local control frames over an abstract system-internal
channel interface using a fixed local wire format.
1. ERP_INIT: The AAI transmits an ERP_INIT frame containing a
cryptographically secure random 256-bit initialization nonce
(N_init) to request a local routing context.
2. Allocation & Token Generation: The LL-Entity validates the
request, generates the asymmetric Ed25519 key pair for the
Ephemeral Agent Identity (EID), and calculates the unique 256-bit
Instance Authentication Token (IAT).
3. ERP_ALLOC: The LL-Entity responds by transmitting an ERP_ALLOC
frame over the local interface. This frame contains the mirrored
nonce (N_init), the newly allocated public EID, and the assigned
Local_IAT.
+-------+ +-----------+
| AAI | | LL-Entity |
+-------+ +-----------+
| |
| --- ERP_INIT [N_init] ----------------------> |
| | [Generates EID
| <-- ERP_ALLOC [N_init, Source_EID, Local_IAT] | & IAT]
| |
Upon receipt, the AAI verifies that the returned nonce matches
N_init. All subsequent transactions issued by the AAI MUST supply
the assigned Local_IAT to authenticate against the LL-Entity.
4.2.3.2. Global Directory Mapping (ERP_REGISTER)
Once the local allocation phase is complete, the logical identity
must be propagated to the global overlay network to enable external
packet routing.
1. Transmission: The LL-Entity generates an outbound ERP_REGISTER
control frame and routes it to the Distributed Hash Table (DHT)
overlay network.
Gebauer Expires 26 December 2026 [Page 25]
Internet-Draft IACP June 2026
2. Payload Structure: The registration packet encapsulates the
public EID, the current physical transport endpoint (current
source IP address), a newly initialized Generation Counter (set
to 0), and a cryptographic signature covering the binding:
Signature = Sign_Ed25519( Private_Key, EID || Current_IP || Generation_Counter )
1. Global Quorum Verification: The responsible Global Directory
Quorum nodes receive the frame, verify the Ed25519 signature
against the public EID, and commit the authoritative mapping
entry into the decentralized ledger.
4.2.3.3. Transition Control and Core States (Switch Point)
The LL-Entity manages the life cycle of each active EID mapping
context via a strict finite state machine. The operational
transition is regulated at the central "Switch Point".
+------------+
| UNBOUND |
+------------+
|
| ERP_INIT / ERP_ALLOC
v
+------------+
| ALLOCATED |
+------------+
|
| ERP_REGISTER (Outbound)
v
+------------+
| TRANSITION | <--- [Buffers Outbound Application Data]
+------------+
|
| DHT Quorum Confirmation / ACK
v
+------------+
| BOUND | <--- [Flushes Buffer / Active Streaming]
+------------+
State Definitions: * UNBOUND: The default state. No local
cryptographic context or allocation exists. * ALLOCATED: The key pair
and Local_IAT are active on the host, but the mapping has not yet
been announced to the global network. * TRANSITION: The ERP_REGISTER
frame has been dispatched to the DHT overlay. The binding is pending
confirmation. To prevent packet loss, the LL-Entity MUST intercept
all outbound application data generated by the AAI during this
transit phase and hold it in a dedicated local FIFO buffer. * BOUND:
Gebauer Expires 26 December 2026 [Page 26]
Internet-Draft IACP June 2026
The DHT directory quorum has confirmed registration. The Switch
Point activates the encapsulation pipeline, instantly flushes the
local FIFO buffer, and transitions the stream into active network
transmission.
4.2.3.4. Application Data Encapsulation and Transport (ERP_STREAM)
In the BOUND state, all application layer payload generated by the
AAI is encapsulated into standard IACP data packets to isolate the
active Persistent State Session (PSS).
The wire format for data transport requires the encapsulation of the
logical routing headers directly before the payload field:
+------------------+-------------------+-----------------+------------+
| Source IP Header | IACP Base Header | ERP Routing Hdr |Encapsulated|
|(Physical Vector) | (Demux / Flags) |(Logical EID/Gen)| PSS Payload|
+------------------+-------------------+-----------------+------------+
The ERP Routing Header explicitly defines the Source_EID,
Destination_EID, and the current Generation_Counter. Physical
transit nodes route the packet solely based on the external IP
header. The receiving LL-Entity strips the transport and routing
headers, performs context validation, and forwards the raw PSS
payload exclusively to the isolated target AAI matching the
destination parameters.
4.2.3.5. Identity Evolution
To support legitimate software updates of an Autonomous Agent
Instance without breaking the continuity of its cryptographic
identity, the protocol defines a controlled identity evolution
mechanism.
When the Application Digest of an agent changes (e.g. after a code
update), the agent MUST send an ERP_EVOLVE control frame to the LL-
Entity before resuming normal operation.
ERP_EVOLVE (Type 0x16)
Gebauer Expires 26 December 2026 [Page 27]
Internet-Draft IACP June 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x16) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous App-Digest [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current App-Digest [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Evolution Sequence Number [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AIRK Signature (Ed25519) [64 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.4. Secure Handshake and Connection Management
4.2.4.1. Dual-Cookie Handshake Protection
To prevent state-spoofing, resource exhaustion, and blind packet-
injection attacks during the initialization of a Persistent State
Session (PSS), the ERP enforces a mandatory Dual-Cookie handshake
mechanism across the transport layer.
1. Session Initiation (PSS_INIT): The initiator constructs a control
frame containing an Initiator Cookie (I-Cookie). The I-Cookie
MUST be an 8-byte, high-entropy cryptographically secure random
value. At this stage, the Responder Cookie (R-Cookie) field
within the frame is unassigned and MUST be zero-filled
(0x0000000000000000).
2. Session Negotiation (PSS_NEG): Upon receipt, the responder
extracts the I-Cookie, allocates transient handshake resources,
and generates its own independent 8-byte cryptographically secure
random value, designated as the Responder Cookie (R-Cookie). The
responder transmits a PSS_NEG frame back to the initiator,
containing both the original I-Cookie and the new R-Cookie.
3. Session Confirmation (PSS_ACK): The initiator verifies the
returned I-Cookie. It completes the state binding by
transmitting a PSS_ACK frame. Every subsequent data and control
packet transmitted within this specific PSS session MUST carry
the identical, invariant combination of
[I-Cookie || R-Cookie]
Gebauer Expires 26 December 2026 [Page 28]
Internet-Draft IACP June 2026
in its session header. Any incoming packet where the R-Cookie is
zero-valued after the initialization phase, or does not match the
established state record, MUST be instantly discarded without
processing.
Local Session Table Indexing and Collision
Prevention
The local LL-Entity maintains all pending, active, and transient
handshake states within a specialized internal routing and session
hash table.
To eliminate the "Cookie Lookup Paradox"-wherein multiple independent
AAIs sharing the identical host infrastructure and the same
underlying network-side Source_EID could experience session cross-
over or overwrites due to an accidental 64-bit cookie hash collision-
the lookup index calculation MUST bind the local host isolation
parameter.
The unique internal table indexing key (Local_Session_Key) MUST be
computed using the following mathematical invariant:
Local_Session_Key = SHA256( I-Cookie || R-Cookie || Source_EID || Local_IAT )
By factoring the unforgeable, high-entropy 256-bit Local_IAT
(Instance Authentication Token) directly into the cryptographic hash
function, perfect isolation is maintained on the host. Even in the
event of an identical network-side cookie match across separate
applications, the resulting hash indices remain strictly orthogonal,
structurally preventing data cross-over within the LL-Entity cache.
If an internal table collision is detected during lookup operations,
the LL-Entity freezes any immediate state mutations for that specific
bucket, bypasses the fast-path cache, and enforces a synchronous
cryptographic validation: the incoming frame MUST be validated
against an explicit Ed25519 signature of the Source_EID bound to that
context before any state transition is authorized.
4.2.5. Resource Governance
4.2.5.1. Coordinated Network Churn
When a host infrastructure switches its physical network interfaces
or encounters a high-frequency IP address assignment change, the
local LL-Entity MUST execute a coordinated network churn routine to
maintain path reachability for all active Persistent State Sessions
(PSS).
Gebauer Expires 26 December 2026 [Page 29]
Internet-Draft IACP June 2026
1. Detection and Incrementation: Upon interface migration, the LL-
Entity locks immediate outbound queue operations for all local
AAIs. It retrieves the current authoritative Generation_Counter
associated with the active EID context and increments its value
by exactly 1:
Generation_Counter_New = Generation_Counter_Old + 1
2. Transmission: The LL-Entity constructs a specialized
MIGRATION_VECTOR control frame. This frame encapsulates the
Source_EID, the newly assigned physical transport endpoint (the
new destination IP address), and the incremented
Generation_Counter_New.
3. Authentication: The entire block is structurally signed using the
private key of the EID:
Migration_Signature = Sign_Ed25519( Private_Key, Source_EID || New_IP || Gen_Counter_New )
The LL-Entity instantly multi-casts the validated MIGRATION_VECTOR
frame to the Global Directory Quorum (DHT) and mirrors it
asynchronously to all known active remote peer endpoints recorded in
the local session table.
4.2.5.2. Generation Counting and Cache Invalidation Rules
To mitigate out-of-order packet arrival, racing routing updates, and
stale cache exploits across intermediate transport nodes, the ERP
implements strict Generation Counting evaluation logic.
All remote entities (peer LL-Entities and DHT nodes) maintaining
localized routing and mapping caches MUST evaluate incoming packet
headers against the following absolute validation pipeline:
Let Cache_Gen = Stored Generation Counter for Source_EID Let
Packet_Gen = Generation Counter extracted from the incoming ERP
Routing Header
Gebauer Expires 26 December 2026 [Page 30]
Internet-Draft IACP June 2026
+------------------------+
| Incoming Packet Arrives|
+------------------------+
|
v
+-----------------------+
| Is Packet_Gen > |
| Cache_Gen? |
+-----------------------+
/ \
YES / \ NO
v v
+-----------------------+ +-------------------------------+
| Update Cache Mapping | | Is Packet_Gen == |
| & Process Packet | | Cache_Gen? |
+-----------------------+ +-------------------------------+
/ \
YES / \ NO
v v
+-----------------------+ +-----------------------+
| Accept and Forward | | SILENTLY DISCARD |
| Payload | | (Stale Routing/Race) |
+-----------------------+ +-----------------------+
1. Cache Invalidation Rule: If Packet_Gen > Cache_Gen, the remote
node MUST instantly invalidate its existing cache entry. The
node updates its record with the new physical transport endpoint
(IP address) and sets Cache_Gen = Packet_Gen. Any queued data
frames using the older mapping are instantly flushed.
2. In-Sequence Processing: If Packet_Gen == Cache_Gen, the
topological vector is assumed stable. The packet is processed or
forwarded normally.
3. Stale Frame Dropping: If Packet_Gen < Cache_Gen, the incoming
packet is structurally identified as a delayed, out-of-order, or
illegitimate routing frame. The node MUST silently drop the
packet without modifying local tables or executing cryptographic
steps, entirely eliminating desynchronization locks caused by
network jitter.
4.2.6. Fault Tolerance, Resiliency, and Degraded Operations
Gebauer Expires 26 December 2026 [Page 31]
Internet-Draft IACP June 2026
4.2.6.1. Caching-Lock Mitigations and ANML-Backoff Mechanics
When an LL-Entity encounters downstream resolution failures,
directory lookup timeouts, or transient blockades during an Agent
Network Markup Language (ANML) query execution, it MUST prevent local
context deadlocks and cache-locking loops. Instead of maintaining a
blocking state that starves local resources, the LL-Entity
transitions the affected routing context into the STATE_ANML_DEGRADED
mode.
Once in STATE_ANML_DEGRADED, the LL-Entity enforces an isolated, non-
blocking, exponential retry backoff scheme with integrated
cryptographic jitter. The retransmission or re-query interval
(T_retry) is calculated using the following protocol formula:
T_retry = Min( T_max, T_base * (2^attempts) ) + Cryptographic_Jitter
Where: * T_base = 2 seconds (the initial protocol backoff constant).
* attempts = the incremental count of continuous failed resolution
requests. * T_max = 300 seconds (the absolute upper boundary
ceiling). * Cryptographic_Jitter = Truncate_to_16Bit( SHA256(
Source_EID || attempts ) ) modulo 15 seconds.
By injecting a deterministic, public-key-derived cryptographic jitter
value, the protocol prevents network-wide lockstep synchronizations
(thundering herd problems) across competing AAIs on the same
infrastructure without relying on local OS-level random seed
parameters.
Asynchronous Backoff Reset Vectors
To resolve the fatal desynchronization race condition occurring when
a target EID migrates its physical transport endpoint (high-frequency
network churn) while an originating node remains trapped within an
active exponential backoff loop, the ERP implements a mandatory
cross-state interrupt vector.
An LL-Entity operating under an active STATE_ANML_DEGRADED backoff
timer for a specific destination EID MUST continuously listen for
out-of-band network reachability updates.
The active backoff timer for a specific destination context MUST be
instantly aborted, purged, and reset to zero if either of the
following asynchronous events occurs:
1. Receipt of a structurally valid, cryptographically signed
MIGRATION_VECTOR originating from the target EID.
Gebauer Expires 26 December 2026 [Page 32]
Internet-Draft IACP June 2026
2. Ingress of an authenticated IACP data frame carrying an ERP
Routing Header where the Generation_Counter is strictly greater
than the previously cached sequence value for that destination
EID:
Incoming Packet_Gen > Cache_Gen
Upon trigger execution, the LL-Entity clears the STATE_ANML_DEGRADED
flag for this session, restores the context to the active BOUND
processing state, and immediately schedules a clean resolution
handshake using the fresh topological coordinates. This structural
interrupt entirely prevents permanent routing desynchronization
locks.
4.2.7. Decentralized Security Governance and Slashing
4.2.7.1. Proof of Malfeasance (PoM) Specification
The IACP overlay network enforces node accountability through
automated, non- repudiable cryptographic evidence termed a Proof of
Malfeasance (PoM) ticket. A PoM ticket structurally identifies
routing violations, specifically equivocation anomalies where a
single EID public key signs two distinct, conflicting topological
mappings (e.g., separate IP destinations or desynchronized Generation
Counters) within the same logical epoch.
To be considered authoritatively valid by the Global Directory
Quorum, a PoM ticket MUST compile the following immutable fields:
PoM_Ticket = {
Target_EID: Public Key of the accused entity,
Header_Fragment_A: [ IP_Vector_A || Gen_Counter_A || Signature_A ],
Header_Fragment_B: [ IP_Vector_B || Gen_Counter_B || Signature_B ],
Timestamp: Cluster-synchronized verification time
}
Validation Invariant: The quorum nodes parse both fragments. A
ticket is unconditionally valid if and only if: 1. Signature_A and
Signature_B evaluate as mathematically true against the identical
Target_EID public key. 2. Header_Fragment_A is structurally non-
identical to Header_Fragment_B. Malicious nodes attempting to frame
an honest curator by injecting fragmented, corrupted, or incomplete
signatures are blocked because tickets failing this strict signature
verification are instantly dropped without state mutation.
Gebauer Expires 26 December 2026 [Page 33]
Internet-Draft IACP June 2026
4.2.7.2. Two-Phase Slashing Escrow (2PSE)
To mitigate Denial-of-Service (DoS) vectors arising from malicious or
coordinated false denunciation attempts, the ERP implements a Two-
Phase Slashing Escrow (2PSE) protocol. Upon processing a valid PoM
ticket, the Global Directory Quorum MUST NOT instantly drop the
target network state or purge its stake. Instead, the quorum
transitions the target namespace into a transient state designated as
STATE_CHALLENGED.
The STATE_CHALLENGED lifecycle is governed by two sequential
intervals:
1. Escrow Window (T_escrow = 120 Epochs / 1 Hour): The target
entity's directory mapping is isolated. The quorum initiates an
automated challenge-response loop, allowing the accused node to
submit a counter-proof (PSS_REVOCATION_REBUTTAL) demonstrating
cryptographic context validity or authorized key-revocation
states.
2. Resolution Phase: If a verified rebuttal is received within
T_escrow, the STATE_CHALLENGED flag is cleared, restoring normal
operations. If T_escrow expires without a valid rebuttal, the
network transition is finalized: the node is hard-blocked, its
cryptographic identity is blacklisted across the DHT, and its
associated financial stake is irrevocably slashed.
4.2.7.3. Degraded Multi-Path Routing in Escrow
To eliminate the security vacuum wherein a truly compromised node
could exploit the T_escrow window to perform unchecked Man-in-the-
Middle (MitM) or Blackhole attacks against active application
streams, the protocol enforces a structural degradation of the
routing pipeline for any context flagged as STATE_CHALLENGED.
During the escrow interval, unconstrained direct single-path routing
through the challenged node is strictly prohibited. Instead, the
initiating LL-Entity MUST execute a mandatory Degraded Multi-Path
Routing procedure:
Gebauer Expires 26 December 2026 [Page 34]
Internet-Draft IACP June 2026
+-----------------------+
| Outbound Data Frame |
+-----------------------+
|
v
+-----------------------+
| Destination EID in |
| STATE_CHALLENGED? |
+-----------------------+
/ \
YES / \ NO
v v
+-------------------------+ +-------------------------+
| Enforce Multi-Path | | Standard Single-Path |
| Fragmentation & Mirror | | Direct Routing |
+-------------------------+ +-------------------------+
/ | \
/ | \
v v v
+-----------+ +-----------+ +-----------+
| Path 1 | | Path 2 | | Path 3 |
| (Target) | | (Quorum A)| | (Quorum B)|
+-----------+ +-----------+ +-----------+
1. Stream Splitting: Outbound data payloads destined for or
traversing a node in STATE_CHALLENGED are structurally cloned and
transformed into parallel, redundant multi-path streams.
2. Quorum Mirroring: The originating LL-Entity routes Path 1
directly through the challenged target node, while simultaneously
mirroring identical payload packets via Path 2 and Path 3 through
separate, uncompromised independent Global Directory Quorum
nodes.
3. End-to-End Consistency: The receiving endpoint reconstructs the
stream using the earliest valid packet arriving from any of the
redundant paths.
If the challenged node drops or modifies payloads during its escrow
phase, the receiving entity immediately detects the data disparity
against the clean quorum paths, discards the corrupted fragment, and
generates an auxiliary verification fault report, preserving
operational continuity.
5. DHT Namespace Architecture and Distributed Security
5.1. Distributed Hash Table
Gebauer Expires 26 December 2026 [Page 35]
Internet-Draft IACP June 2026
The Internet Agent Communication Protocol (IACP) utilizes a globally
distributed, decentralized lookup architecture based on a Distributed
Hash Table (DHT) to maintain public records without relying on
centralized single points of failure. The routing infrastructure
operates as an overlay network where participating nodes collectively
maintain the mapping directory, ensuring high availability, fault
tolerance, and resilience against targeted node churn.
5.1.2. DHT Namespace Structure
The DHT primary key space uses a flat, uniform 256-bit space
generated via cryptographic hashing (KEY = SHA-256("path")). The
structural mapping within the global directory maps an absolute
string identifier or specific spatial coordinate to its respective
destination metadata object, primarily an Ephemeral Agent Identity
(EID) or a transport boundary mapping vector. Namespaces use
deterministic hierarchical reverse-notation paths (e.g.
org.agentnet.marketplace.energy).
+---------------------------------------------------------------------+
| DHT 256-Bit Uniform Keyspace |
+---------------------------------------------------------------------+
| [0x0000...0000] [0xFFFF...FFFF] |
+---------------------------------------------------------------------+
| |
v v
SHA-256(Namespace String) SHA-256(EID)
To enforce separation between functional routing environments and
semantic application layers, the DHT segregates the cryptographic
keyspace using explicit namespace routing bits embedded within the
target coordinate schema.
5.2. Namespace Registration and Curation
5.2.1. Root Namespace Registration
Root namespace allocation maps human-readable, deterministic
alphanumeric tags directly to target resource coordinates inside the
DHT. To prevent arbitrary domain-squatting, sybil-based lookup
pollution, and coordinate collision, registration requires an initial
un-spendable burn-allocation fee or verified resource escrow
contract.
Gebauer Expires 26 December 2026 [Page 36]
Internet-Draft IACP June 2026
A root namespace record binds a unique, permanent cryptographic
curation certificate containing a designated public key authorized to
issue modifications, updates, or cryptographic revocations.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace Alphanumeric String Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Cryptographic Curation Public Key (Ed25519) |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Escrow Allocation Index Block |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.2. Sub-Namespace Delegation
The authorized root custodian public key can sign delegation tokens
to authorize downstream sub-namespaces. A valid delegation consists
of a cryptographic path chain evaluated dynamically during resource
lookups.
+------------------+ Signed Delegation +---------------------+
| Root Namespace | ------------------------> | Sub-Namespace Token |
| [Root Ed25519] | | [Sub-Node Ed25519] |
+------------------+ +---------------------+
|
v
+---------------------+
| Terminal Target EID |
+---------------------+
Lookups resolving sub-namespaces MUST process the complete
authorization chain from the root key down to the terminal record.
Any missing signature, expired validation window, or invalid
alignment with the parent path constraints breaks the validation path
and causes resolution to abort.
5.3. Proof-of-Work and Reputation-Based Access Control
Gebauer Expires 26 December 2026 [Page 37]
Internet-Draft IACP June 2026
5.3.1. Dynamic PoW Difficulty
To defend the DHT routing network from distributed denial-of-service
(DDoS) vectors and lookup depletion attacks, directory mutations and
intensive lookup queries require a valid Proof-of-Work (PoW) token
header based on Hashcash.
The targeted leading-zero bit difficulty coefficient D_req adjusts
dynamically depending on the processing load, lookup queue latency,
and incoming query volume of individual directory zones.
D_req = D_base + floor(gamma * (Queue_Current / Queue_Max))
Where D_base represents the baseline minimum bit difficulty, gamma
represents the scalar operational multiplier, and Queue_Current
measures the active buffer depth of the handling node. Lookups
submitted with an insufficient trailing zero bitmask are dropped at
the ingress interface without allocating resources or memory space.
5.3.2. Access Tickets and Joint Liability
Validated transactions give the requester an implicit short-lived
routing credit via an Access Ticket. If an internal Autonomous Agent
Instance (AAI) generates malicious control plane activity, the
hosting infrastructure and the individual peer entity are held under
joint liability.
+------------------------+ +-----------------------+
| Hosting Provider / |<= Joint Liability =>| Malicious Autonomous |
| Parent LL-Entity | | Agent Instance (AAI) |
+------------------------+ +-----------------------+
| |
v v
Slashing of Host Collateral EID Key Revocation List
If an individual agent breaks wire protocols, the network scales back
the performance tracking matrix of the entire network segment or host
infrastructure layer, creating a strong structural incentive for
local platforms to isolate misbehaving processes.
5.4. Anti-Abuse Mechanisms
Gebauer Expires 26 December 2026 [Page 38]
Internet-Draft IACP June 2026
5.4.1. Token-Bucket Filters and Rate Limiting
Ingress packets undergo rate-limiting enforcement via an independent
Token-Bucket algorithmic state machine integrated inside the
transport layer. The configuration uses two static parameters:
maximum bucket capacity (C_max) and token replenishment rate
(R_repl).
Tokens_Available = min(C_max, Tokens_Previous + (Delta_Time *
R_repl))
Each transaction consumes tokens based on the lookup size and
complexity. If Tokens_Available falls below the required request
cost, the packet is discarded, and the node returns an explicit error
payload to trigger transport-level backoff.
5.4.2. Autonomous Circuit Breakers
When a target zone or specific peer coordinate experiences sudden
inbound traffic anomalies exceeding standard operation limits by
orders of magnitude, local routing nodes autonomously change state to
prevent cascading memory depletion.
+--------------+ Anomalous Load > Threshold +--------------+
| STATE_OPEN | -------------------------------> | STATE_TRIPPED|
+--------------+ +--------------+
^ |
| Cooldown + Load Normal |
+-------------------------------------------------+
While in STATE_TRIPPED, nodes refuse all standard lookup mutations
and enter an aggressive caching enforcement mode. The node drops
unauthenticated requests immediately, allowing the transport stack to
bypass costly parsing loops and handle targeted resource exhaustion
at wire speeds.
5.5. Proof of Malfeasance (PoM) and Slashing
5.5.1. PoM Ticket Specification
A Proof of Malfeasance (PoM) ticket contains clear cryptographic
proof that a node or agent committed protocol violations, such as
double-signing contradictory routing states, deploying conflicting
mapping epochs, or fabricating directory routing steps.
PROOF_OF_MAL:
Gebauer Expires 26 December 2026 [Page 39]
Internet-Draft IACP June 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Offense Type Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Malicious Node Identity (EID) |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Conflicting Signed Message Digest A |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Conflicting Signed Message Digest B |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Accusing Node Cryptographic Signature |
| [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ticket must explicitly contain both conflicting signed messages
to allow independent verification by any peer executing standard
verification routines without relying on a central authority.
5.5.2. Two-Phase Slashing Escrow (2PSE)
To safeguard against malicious or erroneous accusations, the network
processes slashing actions using a strict two-phase challenge
framework.
+--------------------+ PoM Published +--------------------+
| STATE_NOMINAL | -----------------> | STATE_CHALLENGED |
+--------------------+ +--------------------+
|
Escrow Epoch Expires |
(No Valid Counter-Proof) |
v
+--------------------+
| STATE_SLASHED |
+--------------------+
Gebauer Expires 26 December 2026 [Page 40]
Internet-Draft IACP June 2026
1. Phase 1 (Escrow State): Upon receipt of a valid PoM ticket, the
target entity transitions into STATE_CHALLENGED. The node's
associated staking deposit or registration token is locked within
a secure escrow quarantine window for a fixed epoch block count.
2. Phase 2 (Execution State): If the challenged node cannot submit a
cryptographically valid counter-proof before the quarantine
window expires, the escrow balance is permanently burned, and the
node changes state to STATE_SLASHED.
5.5.3. Curator Quarantine and Decapitation
If a trusted root namespace curator node is flagged by a verified PoM
ticket, the protocol enforces immediate quarantine procedures. The
flagged node's authorization rights are suspended, and its assigned
DHT zones are temporarily managed by an uncompromised backup peer
quorum.
+-------------------------+ +-------------------------+
| Compromised Curator Node| | Backup Peer Quorum |
+-------------------------+ +-------------------------+
| State: SUSPENDED | | State: ACTIVE GOVERNANCE|
| Rights: REVOKED | | Action: Re-route Zone |
+-------------------------+ +-------------------------+
If the protocol violation is confirmed, the node undergoes total
network decapitation. Its long-term curation keys are added to a
decentralized revocation bloom filter, making all downstream
delegation signatures void across the network ecosystem.
5.6. Compromise Recovery and Hot-Docking
When an active host system detects an internal security compromise,
it must execute emergency recovery procedures without dropping active
Persistent State Sessions (PSS). This mitigation pattern is called
Hot-Docking.
+----------------------+ +----------------------+
| Compromised Host A | | Uncompromised Host B |
+----------------------+ +----------------------+
| [Active AAI Context] | -- Hot-Dock State --> | [Imported Context] |
+----------------------+ Migration Stream +----------------------+
| |
v v
Invalidate EID Generate Forwarding
(Issue Forwarding Ticket) Ticket Mapping
Gebauer Expires 26 December 2026 [Page 41]
Internet-Draft IACP June 2026
The Local Loopback Layer Entity (LL-Entity) serializes the active AAI
operational state and transmits it as an encrypted migration stream
to an uncompromised backup host.
To maintain session continuity without connection dropouts, the
migrating node publishes an asymmetric Forwarding Ticket to its local
directory neighborhood. This ticket re-routes active in-flight
transport packets to the new network destination while preserving the
session cryptographic keys. The old host identity is then
invalidated, completing the secure migration process.
6. Agent to Agent Communication
6.1. Ephemeral State Endpoints (ESE)
An Ephemeral State Endpoint (ESE) constitutes a non-persistent,
volatile memory mapping and interface execution state hosted directly
under an active Ephemeral Agent Identity (EID). ESEs externalize
telemetry, volatile state variables, and transactional intention
metadata to authorization-verified peering agents. All allocated ESE
memory structures are cryptographically bound to the lifecycle of the
parent EID and undergo deterministic erasure upon EID rotation or
session termination.
6.1.2. Local Points (LP)
Designed for isolated, physically bounded networks (e.g., IEEE
802.3/802.11 Local Area Networks). LPs require agents to maintain a
mapping of peer MAC addresses to facilitate link-layer transmission.
Local EIDs and LPs are isolated by default and are not discoverable
over the wider internet unless explicitly configured.
6.1.3. Global Points (GP)
Global Points (GP) are interoperable endpoints designed for WAN and
public internet routing. A GP is addressable via a deterministic
256-bit composite coordinate computed as follows:
GP_Coordinate = SHA-256(Parent_EID || Endpoint_Identifier_Tag)
Gebauer Expires 26 December 2026 [Page 42]
Internet-Draft IACP June 2026
6.2. Discovery Spaces (DS)
To prevent broad network exposure, an EID remains hidden by default.
Initial identity discovery occurs via Manual Provisioning, Public
Publication, or Autonomous Discovery Spaces. Discovery Spaces
function as logical hubs categorized by specific topics or semantic
relevance. DS architectures are hosted directly within the global
DHT. Embedding the Discovery Spaces natively inside the DHT ensures
complete server independence, utilizes the existing cryptographic P2P
routing fabric for native coordinates, and inherently hardens the
system against single-point failures and network partitioning through
distributed load balancing. An agent's internal filtering rules
dictate whether it scans, processes, or responds to a specific
Discovery Space payload. A request can enforce an explicit limit on
the number of accepting peers.
6.3. Anonymous Discovery Mechanism
6.3.1. Discovery Request with Proof-of-Work and Ephemeral Keys
(DISCOVERY_REQ)
To facilitate autonomous discovery without compromising privacy, an
agent can broadcast an anonymous information request into the network
without exposing its own EID. These anonymous broadcasts require the
attachment of a valid Cryptographic Proof-of-Work (PoW) Token,
strictly prohibiting any host state or memory allocation prior to
successful token validation. The initiating agent includes an
Ephemeral Public Key within the payload.
6.3.2. Discovery Response and Secure EID Exchange (DISCOVERY_RES)
An accepting peer that evaluates the request and intends to establish
contact encrypts its own EID using this ephemeral public key. This
allows the responding node to securely transition its identity to the
requester without leakage to intermediate nodes. Once decrypted by
the initiator, both agents possess each other's EIDs.
6.4. Persistent State Sessions (PSS)
For sustained, long-term collaboration, two agents establish a
Persistent State Session (PSS). A PSS is a continuous state channel
running within the DHI environment, where two distinct EIDs
instantiate a pair of dedicated, mutually encrypted ESEs. When an
agent updates its local state within its assigned ESE, the state
transition is immediately propagated to the peer node. If several
nodes interlock their respective ESE arrays, complex decentralized
Gebauer Expires 26 December 2026 [Page 43]
Internet-Draft IACP June 2026
agent networks emerge.
6.4.2. PSS Lifecycle and Handshake
PSS sessions are encapsulated within the QUIC transport protocol.
The protocol uses sequence vectors to ensure fault tolerance and
state consistency across unreliable networks. If an agent suffers an
unexpected crash, server outage, or temporary loss of connectivity,
it can seamlessly reconcile missed transactions upon reconnection by
comparing local and remote sequence state vectors.
The Lifecycle looks as followed:
+-------------------+
| STATE_CLOSED |
+-------------------+
|
| Transmit PSS_INIT
v
+-------------------+
| STATE_HEARING | <---+ Receive PSS_NEG
+-------------------+ | (Validate Verification Cookie)
| |
| Emit PSS_ACK |
v |
+-------------------+ ----+
| STATE_ESTABLISHED|
+-------------------+
|
| PSS_TEARDOWN / PSS_REVOCATION
v
+-------------------+
| STATE_CLOSED |
+-------------------+
Strict state progression constraints require that the reception of
out-of-order or invalid packet sequences during the handshaking phase
causes an immediate transition to STATE_CLOSED.
6.4.3. Dual-Cookie Handshake (PSS_INIT / PSS_NEG / PSS_ACK)
To prevent resource exhaustion from distributed blind spoofing
vectors, connection establishment enforces a three-way Dual-Cookie
Handshake sequence for establshing a SFC. The initiating entity
generates a PSS_INIT packet embedding a cryptographically random
initialization nonce.
Gebauer Expires 26 December 2026 [Page 44]
Internet-Draft IACP June 2026
The responder processes the entry and validates its local capacity
constraints before returning a PSS_NEG frame. This response contains
an independent tracking cookie generated via a keyed hash over the
network locators. Session allocation finalize only upon reception of
a matching PSS_ACK from the initiator, proving network boundary
control.
6.4.4. Session Federation Contract (SFC)
Peer agents can execute a Session Federation Contract (SFC). The SFC
grants both participating nodes direct, authenticated access to each
other's designated ESE data pools. This active session state remains
valid until explicitly dissolved via a structured, Graceful Teardown
Protocol. If an individual peer explicitly requests a dedicated,
unshared connection, the runtime isolates the PSS by instantiating an
exclusive ESE pair. Encrypted ESE payloads require valid decryption
keys, which rotate periodically as Dynamic Group Key (DGK) and are
transmitted to authenticated members of the Trust List.
6.4.5. Data Streaming and Sequence Vector Reconciliation
(PSS_DATA_STREAM)
Post-handshake data transmission utilizes the structured
PSS_DATA_STREAM packet format. To achieve strict transaction
tracking without causing transmission blockages under packet
reordering conditions, every frame incorporates a monotonically
increasing sequence identifier alongside a 32-byte rolling
cryptographic state reconciliation hash.
6.5. Session Termination and Revocation
6.5.1. Graceful Teardown (PSS_TEARDOWN)
Coordinated channel dismantling requires PSS_TEARDOWN. The
initiating node flushes all remaining outbound memory pipelines,
commits a terminal data checksum, transmits the teardown control
packet, and maintains tracking states until a reciprocal verification
acknowledgment is returned by the peer.
6.5.2. Revocation and Proof of Malfeasance Publishing
(PSS_REVOCATION_PUBLISH)
If an endpoint runtime identifies a protocol invariant violation
(e.g., sequence counter reuse, unauthorized context leak, or
cryptographic invalidation of negotiated contract rules), it executes
a forced local teardown sequence via a PSS_REVOCATION_PUBLISH packet.
Gebauer Expires 26 December 2026 [Page 45]
Internet-Draft IACP June 2026
This control frame destroys local session contexts instantly and
pushes the embedded Proof of Malfeasance (PoM) ticket to the global
directory layer, initiating automated peer blacklisting and staking
escrow slashing routines across the network topology.
7. IANA Considerations
This document requests the following IANA actions.
7.1. IACP Message Type Registry
IANA is requested to create a new registry titled "Internet Agent
Communication Protocol (IACP) Message Types" under the "Internet
Agent Communication Protocol (IACP) Parameters" registry group.
The registry policy is *Standards Action* for values 0x00-0x7F and
*Specification Required* for values 0x80-0xFE. The value 0xFF is
reserved for future extension.
Initial contents of the registry:
| Type | Name | Reference |
|--------|-------------------------------|--------------------|
| 0x01 | DISCOVERY_REQ | Appendix A |
| 0x02 | DISCOVERY_RES | Appendix A |
| 0x03 | ACCESS_TICKET_REQ | Appendix A |
| 0x04 | ACCESS_TICKET_RES | Appendix A |
| 0x05 | DHT_TICKET_STORE | Appendix A |
| 0x06 | DHT_TICKET_QUERY | Appendix A |
| 0x07 | DHT_TICKET_RESP | Appendix A |
| 0x08 | PSS_INIT | Appendix A |
| 0x09 | PSS_ACK | Appendix A |
| 0x0A | PSS_NEG | Appendix A |
| 0x0B | PSS_DATA_STREAM | Appendix A |
| 0x0C | PSS_TEARDOWN | Appendix A |
| 0x0D | PSS_REVOCATION_PUBLISH | Appendix A |
| 0x0E | ERP_DEFLECT | Appendix A |
| 0x0F | Outer Transport Header | Appendix A |
| 0x12 | ANML Fallback Query | Appendix A |
| 0x13 | PSS_REVOCATION_REBUTTAL | Appendix A |
| 0x11 | ERP_INIT | Appendix A |
| 0x14 | ERP_ALLOC | Appendix A |
| 0x15 | ERP_REGISTER | Appendix A |
| 0x16 | ERP_EVOLVE | Appendix A |
| 0x17 | MIGRATION_VECTOR | Appendix A |
| 0x18 | PROOF_OF_MAL | Appendix A |
Gebauer Expires 26 December 2026 [Page 46]
Internet-Draft IACP June 2026
7.2. IACP TLV Registry
IANA is requested to create a registry titled "IACP Type-Length-Value
(TLV) Types".
Initial contents:
| TLV Type | Name | Reference |
|----------|-----------------------------|---------------|
| 0x0C | MIGRATION_VECTOR | Section 4.2.5 |
7.3. IACP Flags Registry
IANA is requested to create a registry for flag bits used in the
common IACP header and specific message types. Initial assignments
are left to future documents or expert review.
7.4. IACP Outer Transport Header Types
The following values are assigned for the Outer Transport Header
(Type field 0x0F and related deflection types):
* 0x0E: ERP_DEFLECT
* 0x0F: Outer Transport Header
All unassigned values in the 0x00-0xFF range are reserved.
This document makes no other requests to IANA.
8. Security Considerations
The Internet Agent Communication Protocol (IACP) is designed with
cryptographic identity, component isolation, and decentralized
accountability mechanisms. Implementations MUST evaluate and enforce
the operational security profiles detailed in this section.
8.1. Identity and Authentication
All protocol control messages and active transport streams are
cryptographically bound to Ephemeral Agent Identities (EIDs) derived
from Ed25519 public keys. The three-way Dual-Cookie handshake
(PSS_INIT, PSS_NEG, PSS_ACK) combined with mandatory asymmetric
signatures on critical network frames (PSS_INIT, PSS_ACK,
ERP_REDIRECT, and Proof of Malfeasance tickets) provides mutual host
authentication and replay protection.
Gebauer Expires 26 December 2026 [Page 47]
Internet-Draft IACP June 2026
The Local Loopback Layer Entity (LL-Entity) enforces cryptographic
execution isolation between individual Autonomous Agent Instances
(AAIs) operating on the same physical host via localized Instance
Authentication Tokens (IAT). Exposure of persistent long-lived EID
public keys to unverified application sandboxes is prohibited through
the derivation of Ephemeral Session Derivative EIDs (ESD-EID) during
legacy platform hand-off execution vectors.
8.2. Confidentiality and Integrity
Persistent State Sessions (PSS) enforce symmetric AEAD encryption
utilizing AES-GCM-256 with strictly incremented per-packet nonces for
all transactional payloads transmitted via PSS_DATA_STREAM frames.
Access to Ephemeral State Endpoints (ESE) is restricted using
negotiated Session Federation Contracts (SFC) and authenticated
Dynamic Group Keys (DGK). Forwarding vectors published to the
distributed directory are encrypted using keys derived from the
active session context to prevent intermediate routing nodes from
intercepting endpoint locators.
8.3. Denial-of-Service and Resource Exhaustion
The protocol enforces a zero-allocation parsing invariant for
unauthenticated connection states. Receiving host interfaces process
incoming DISCOVERY_REQ frames within volatile scratch memory layers,
incurring negligible processing and state overhead until the
trailing-zero Hashcash Proof-of-Work (PoW) token validation succeeds.
Decentralized infrastructure protections rely on autonomous circuit
breakers, token-bucket rate limiting, and dynamic PoW difficulty
scaling to defend Discovery Spaces and directory nodes against high-
volume flooding attacks. Cryptographically issued Access Tickets
allow constrained terminal devices to bypass heavy computation blocks
while maintaining joint liability under their parent gatekeeper
nodes.
8.4. Namespace and Curation Security
Root namespace registration within the global directory requires a
verifiable Proof-of-Work burn transaction. Sub-namespace delegation
enforces signed cryptographic certificates carrying deterministic
curator identity records to ensure binding accountability.
Gebauer Expires 26 December 2026 [Page 48]
Internet-Draft IACP June 2026
Decentralized protocol enforcement is achieved via verifiable Proof
of Malfeasance (PoM) tickets routed to a Two-Phase Slashing Escrow
(2PSE) network layer, enabling automated curator quarantine and
identity decapitation sequences. If a top-level curation coordinate
suffers key compromise, the underlying network isolates the affected
zone and executes a hot-docking sequence to transition traffic to
authenticated backup root systems.
8.5. Mobility, Churn, and Forwarding Tokens
Dynamic network migration utilizes signed ERP_REDIRECT frames and
authenticated forwarding records committed via ERP_REGISTRATION
packets. These entries are versioned using monotonically increasing
Generation Counters.
Receiving routers discard stale or replayed topological propagation
updates through generation index validation. During a node's
challenged escrow validation phase, the initiating endpoint engages a
degraded multi-path fragmentation and mirroring routing pipeline to
maintain session availability despite intermediary path degradation.
8.6. Privacy Considerations
EIDs operate as long-lived logical pseudonyms and do not expose
deterministic bindings to real-world network identities or underlying
physical locators. The anonymous discovery mechanism permits
querying entities to access target coordinates using ephemeral key
exchanges combined with standalone PoW tokens, isolating search
metadata from persistent tracking graphs.
Active Ephemeral State Endpoints (ESE) remain structurally hidden
from directory indexes by default and accept resolution requests
exclusively from authenticated peers holding valid contract
permissions. Local Points (LP) are restricted to local process
memory structures and cannot be accessed from public network
boundaries unless a local routing rule explicitly bridges the
endpoint to a Global Point (GP) coordinate.
8.7. Residual Risks and Recommendations
Implementations MUST enforce strict state machine transitions and
zero-allocation parsing boundaries defined in Section 6 to prevent
memory exhaustion profiles. QUIC is RECOMMENDED as the underlying
transport protocol layer to provide native stream multiplexing and
rapid connection migration.
Gebauer Expires 26 December 2026 [Page 49]
Internet-Draft IACP June 2026
Where application-layer transactions demand end-to-end
confidentiality extensions beyond the native encapsulation boundaries
provided by this specification, deployments SHOULD wrap transport
channels in secondary lower-layer cryptographic encapsulations,
including IPsec or TLS network segmentation.
No cryptographic primitives with known structural vulnerabilities are
permitted by this specification. All asymmetric signature
verification and symmetric encryption mechanisms rely exclusively on
Ed25519 and AES-GCM-256 primitives backed by cryptographically strong
pseudo-random number generation (CSPRNG) and strict nonce
serialization.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<https://www.rfc-editor.org/info/rfc7401>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
9.2. Informative References
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
Gebauer Expires 26 December 2026 [Page 50]
Internet-Draft IACP June 2026
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999,
<https://www.rfc-editor.org/info/rfc2697>.
[Kademlia] Maymounkov, P. and D. Mazieres, "Kademlia: A Peer-to-Peer
Information System Based on the XOR Metric", IPTPS 2002,
2002.
[Hashcash] Back, A., "Hashcash - A Denial of Service Counter-
Measure", Whitepaper 2002, 2002.
[Wooldridge]
Wooldridge, M., "An Introduction to Multi-Agent Systems",
Publisher John Wiley & Sons, 2009.
[Nygard] Nygard, M. T., "Release It!: Design and Deploy Production-
Ready Software", Publisher Pragmatic Bookshelf, 2018.
[NIST207] Rose, S., Borchert, O., Mitchell, S., and S. Connelly,
"Zero Trust Architecture", NIST Special Publication
800-207, 2020.
1.) DISCOVERY_REQ (Type 0x01)
Gebauer Expires 26 December 2026 [Page 51]
Internet-Draft IACP June 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x01) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Space Coordinate (DHT Key) |
| (SHA-256) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Ephemeral Public Key (X25519) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Timestamp / Replay Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Proof-of-Work Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PoW Target Threshold [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.) DISCOVERY_RES (Type 0x02)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x02) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Responder Ephemeral Public Key (X25519) [32B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| AEAD Nonce / IV [12 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encrypted Payload |
| (True EID [32B] + AEAD Auth Tag [16B]) [48 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.) ACCESS_TICKET_REQ (Type 0x03)
Gebauer Expires 26 December 2026 [Page 52]
Internet-Draft IACP June 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x03) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Requestor EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Space Coordinate (DHT Key) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Timestamp / Replay Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Digital Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.) ACCESS_TICKET_RES (Type 0x04)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x04) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Space Coordinate (DHT Key) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receiver EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiration Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Curator Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.) DHT_TICKET_STORE (Type 0x05)
Gebauer Expires 26 December 2026 [Page 53]
Internet-Draft IACP June 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x05) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Storage Key (SHA-256) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Agent EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live (TTL) [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| AEAD Nonce / IV [12 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encrypted Forwarding Data [36 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Owner Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.) DHT_TICKET_QUERY (Type 0x06)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x06) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Storage Key (SHA-256) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID / Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Requestor EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.) DHT_TICKET_RESP (Type 0x07)
Gebauer Expires 26 December 2026 [Page 54]
Internet-Draft IACP June 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x07) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID / Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status / Error Code [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| AEAD Nonce / IV [12 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encrypted Forwarding Data [36 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Owner Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.) PSS_INIT (Type 0x08)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x08) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Initiator EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Connection Cookie [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Sequence / Vector Clock [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Capabilities & Extension Flags [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Initiator Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9.) PSS_ACK (Type 0x09)
Gebauer Expires 26 December 2026 [Page 55]
Internet-Draft IACP June 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x09) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Responder EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Connection Cookie [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Initial Sequence Number [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Agreed SFC Capabilities [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Responder Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10.) PSS_NEG (Type 0x0A)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x0A) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Connection Cookie [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Negotiation Turn Counter | Rejection Reason Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Proposed SFC Conditions Block [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11.) PSS_DATA_STREAM (Type 0x0B)
Gebauer Expires 26 December 2026 [Page 56]
Internet-Draft IACP June 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x0B) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Connection Cookie [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AEAD Nonce / IV [12 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encrypted ANML Payload (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12.) PSS_TEARDOWN (Type 0x0C)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x0C) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Connection Cookie [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Teardown Type | Reason Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proof of Malfeasance Length [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional: Proof of Malfeasance Data (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
13.) PSS_REVOCATION_PUBLISH (Type 0x0D)
Gebauer Expires 26 December 2026 [Page 57]
Internet-Draft IACP June 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x0D) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Storage Key (SHA-256) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Offender EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proof of Malfeasance Length [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reporter Digital Signature [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proof of Malfeasance Data (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
14.) ERP_DEFLECT (Type 0x0E)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x0E) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Original Target Locator (16 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Target Port (2B) | Deflection-Routing-TTL (1B) | Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Inner Agent Payload ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
15.) Outer Transport Header (Type 0x0F)
Gebauer Expires 26 December 2026 [Page 58]
Internet-Draft IACP June 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Type (0x0F) | Flags | Transit-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP_Transit_Token [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LL-Entity Instance Identifier (LII) [32B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LIK Transit Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Inner ERP / IACP / PSS Payload (variable) |
| |
+---------------------------------------------------------------+
16.) ANML Fallback Query (Type 0x12)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x12) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Legacy Target URI (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requestor EID [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Digital Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
17.) PSS_REVOCATION_REBUTTAL (Type 0x13)
Gebauer Expires 26 December 2026 [Page 59]
Internet-Draft IACP June 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x13) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Storage Key (SHA-256) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Offender EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rebuttal Proof Length [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Rebuttal Evidence Data (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Digital Signature [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
18.) ERP_INIT (Type 0x11)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x11) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Initialization Nonce [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
19.) ERP_ALLOC (Type 0x14)
Gebauer Expires 26 December 2026 [Page 60]
Internet-Draft IACP June 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x14) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Initialization Nonce [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Allocated EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Local_IAT [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20.) ERP_REGISTER (Type 0x15)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x15) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Current Transport IP [16 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generation Counter [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Digital Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
21.) ERP_EVOLVE (Type 0x16)
Gebauer Expires 26 December 2026 [Page 61]
Internet-Draft IACP June 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x16) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous App-Digest [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current App-Digest [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Evolution Sequence Number [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AIRK Signature (Ed25519) [64 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
22.) MIGRATION_VECTOR (Type 0x17)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type (0x17) | TLV Length | IP Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous_Transport_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current_Transport_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Migration_Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
23.) PROOF_OF_MAL (Type 0x18)
Gebauer Expires 26 December 2026 [Page 62]
Internet-Draft IACP June 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Offense Type Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Malicious Node Identity (EID) [32B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conflicting Signed Message Digest A [32B] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conflicting Signed Message Digest B [32B] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accusing Node Cryptographic Signature [64B] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix B. Appendix B: State Machines and Transition Diagrams of the
IACP
To establish verifiable security bounds against resource exhaustion,
the initial IACP Discovery and Session Allocation subsystem is
formalized as a Deterministic Finite Automaton (DFA), denoted by the
5-tuple:
M_disc = (S, \Sigma, \delta, s_0, F)
Where the constituent sets and mappings are defined as follows:
1. S is the finite set of non-overlapping session allocation states:
S = { LISTEN, VALIDATING_POW, AWAIT_IDENTITY, PSS_NEGOTIATING,
ESTABLISHED }
2. \Sigma is the input alphabet consisting of network events and
cryptographic triggers:
\Sigma = { RX_DISCOVERY_REQ, POW_FAILURE, POW_SUCCESS,
RX_PSS_INIT_(SFC=1), RX_PSS_INIT_(SFC=0), IDENTITY_TIMEOUT }
3. s_0 in S is the unique, zero-allocation initial state: s_0 =
LISTEN
4. F subset of S is the set of final accepting operational states: F
= { PSS_NEGOTIATING, ESTABLISHED }
5. delta: S x Sigma -> S is the deterministic state transition
function, defined by the following exact mappings:
Gebauer Expires 26 December 2026 [Page 63]
Internet-Draft IACP June 2026
delta(LISTEN, RX_DISCOVERY_REQ) = VALIDATING_POW
delta(VALIDATING_POW, POW_FAILURE) = LISTEN delta(VALIDATING_POW,
POW_SUCCESS) = AWAIT_IDENTITY delta(AWAIT_IDENTITY,
RX_PSS_INIT_(SFC=1))= PSS_NEGOTIATING delta(AWAIT_IDENTITY,
RX_PSS_INIT_(SFC=0))= ESTABLISHED delta(AWAIT_IDENTITY,
IDENTITY_TIMEOUT) = LISTEN
*Resource Invariant Guarantee:* By formalizing the alphabet mapping
such that delta(LISTEN, RX_DISCOVERY_REQ) yields a state transition
where RAM = 0, the automaton proves that zero-state context is
allocated before verified PoW validation. State elevation to memory-
retaining structures is bound strictly to the execution of
delta(VALIDATING_POW, POW_SUCCESS).
1.) Discovery and Session Allocation DFA (Zero-Allocation State)
+-----------------------+-----------------------+---------------------+
| Current State | Event (Input) | Next State |
+-----------------------+-----------------------+---------------------+
| LISTEN | RX_DISCOVERY_REQ | VALIDATING_POW |
| | (Anonymous packet) | |
+-----------------------+-----------------------+---------------------+
| VALIDATING_POW | POW_FAILURE | LISTEN |
| | (Invalid nonce or | |
| | expired timestamp) | |
+-----------------------+-----------------------+---------------------+
| VALIDATING_POW | POW_SUCCESS | AWAIT_IDENTITY |
| | (Valid cryptographic | |
| | proof-of-work) | |
| | | |
+-----------------------+-----------------------+---------------------+
| AWAIT_IDENTITY | RX_PSS_INIT | PSS_NEGOTIATING |
| | (SFC_REQUESTED = 1) | |
| | | |
+-----------------------+-----------------------+---------------------+
| AWAIT_IDENTITY | RX_PSS_INIT | ESTABLISHED |
| | (SFC_REQUESTED = 0) | |
| | | |
+-----------------------+-----------------------+---------------------+
| AWAIT_IDENTITY | IDENTITY_TIMEOUT | LISTEN |
| | (No valid PSS_INIT | |
| | within 500ms window) | |
+-----------------------+-----------------------+---------------------+
2.) Local ERP Context Lifecycle (LL-Entity)
Gebauer Expires 26 December 2026 [Page 64]
Internet-Draft IACP June 2026
+-----------------------+-----------------------+----------------------+
| Current State | Event (Input) | Next State |
+-----------------------+-----------------------+----------------------+
| UNBOUND | ERP_INIT (0x11) | ALLOCATED |
+-----------------------+-----------------------+----------------------+
| ALLOCATED | ERP_ALLOC (0x14) | ALLOCATED |
+-----------------------+-----------------------+----------------------+
| ALLOCATED | ERP_REGISTER (0x15) | TRANSITION |
+-----------------------+-----------------------+----------------------+
| TRANSITION | DHT Confirmation | BOUND |
+-----------------------+-----------------------+----------------------+
| BOUND | Network Churn | TRANSITION |
+-----------------------+-----------------------+----------------------+
| BOUND | App Digest Change | EVOLVE_PENDING |
+-----------------------+-----------------------+----------------------+
3.) Dynamic Circuit Breaker
+-----------------+-----------------------+---------------------------+
| Current State | Event (Input) | Next State |
+-----------------+-----------------------+---------------------------+
| CLOSED | RX_REQUEST_WITH_TICKET| CLOSED |
| | | |
+-----------------+-----------------------+---------------------------+
| CLOSED | TRAFFIC_SPIKE | OPEN |
| | (Anomalous peak in | |
| | namespace sub-tree) | |
+-----------------+-----------------------+---------------------------+
| OPEN | RX_REQ_FROM_FLAGGED | OPEN |
| | (Request from flagged | |
| | namespace tree branch)| |
+-----------------+-----------------------+---------------------------+
| OPEN | COOLDOWN_TIMEOUT | CLOSED |
| | (Traffic returns to | |
| | baseline limits) | |
+-----------------+-----------------------+---------------------------+
| OPEN | RX_ACCESS_TICKET | OPEN |
| | (Valid ticket parsed | |
| | during open state) | |
+-----------------+-----------------------+---------------------------+
4.) Ongoing Session & Continuity (PSS & SFC Lifecycle FSM)
Gebauer Expires 26 December 2026 [Page 65]
Internet-Draft IACP June 2026
+-----------------+-----------------------+---------------------------+
| Current State | Event (Input) | Next State |
+-----------------+-----------------------+---------------------------+
| PSS_NEGOTIATING | SFC_EFFECTIVE | ESTABLISHED |
| | (Contract signed & | |
| | validated by peers) | |
+-----------------+-----------------------+---------------------------+
| ESTABLISHED | RX_OUT_OF_ORDER | ANOMALY_FLAGGED |
| | (Historical payload or| |
| | gap in packet index) | |
+-----------------+-----------------------+---------------------------+
| ANOMALY_FLAGGED | ANOMALY_CLEARED | ESTABLISHED |
| | (Valid sequence re-syn| |
| | chronization achieved)| |
+-----------------+-----------------------+---------------------------+
| ESTABLISHED/ | HEARTBEAT_FAIL | SESSION_ |
| ANOMALY_FLAGGED | (Invalid signature or | COMPROMISED |
| | unauthorized access) | |
+-----------------+-----------------------+---------------------------+
| ESTABLISHED | QUIC_CONN_CLOSE | DISCONNECTED |
| | (Unexpected transport | |
| | drop or timeout) | |
+-----------------+-----------------------+---------------------------+
| DISCONNECTED | PEER_RECONNECT | RECONCILING |
| | (Re-authenticating via| |
| | short-lived tokens) | |
+-----------------+-----------------------+---------------------------+
| RECONCILING | STATE_VECTORS_MATCH | ESTABLISHED |
| | (Delta log application| |
| | successful) | |
+-----------------+-----------------------+---------------------------+
5.) Curator Quarantine
Gebauer Expires 26 December 2026 [Page 66]
Internet-Draft IACP June 2026
+-----------------------+-----------------------+---------------------+
| Current State | Event (Input) | Next State |
+-----------------------+-----------------------+---------------------+
| ESTABLISHED | RX_REVOCATION_TICKET | CURATOR_QUARANTINE |
| | (Validated PoM match) | |
+-----------------------+-----------------------+---------------------+
| CURATOR_QUARANTINE | QUARANTINE_EXPIRED | EVICTED_PEER |
| | (No counter-proof) | |
| | | |
+-----------------------+-----------------------+---------------------+
| CURATOR_QUARANTINE | RX_COUNTER_PROOF | ESTABLISHED |
| | (Valid signature) | |
| | | |
+-----------------------+-----------------------+---------------------+
| EVICTED_PEER | CLEANUP_COMPLETE | LISTEN |
| | (Internal trigger) | |
+-----------------------+-----------------------+---------------------+
6.) The 4-Stage Security & Revocation Model
+---------------------+-----------------------+-----------------------+
| Current State | Event (Input) | Next State |
+---------------------+-----------------------+-----------------------+
| SESSION_COMPROMISED | VALIDATE_ANOMALY | EMERGENCY_ |
| | (Malicious behavior | REVOCATION |
| | deterministically proven) |
+---------------------+-----------------------+-----------------------+
| EMERGENCY_ | POM_GENERATED | PROPAGATING_WARN |
| REVOCATION | (Proof of Malfeasance | |
| | block fully compiled) | |
+---------------------+-----------------------+-----------------------+
| ACTIVE_CURATOR | CERT_CONTRADICTION | QUARANTINE |
| (Curator Node Only) | (Conflicting signed | |
| | claims discovered) | |
+---------------------+-----------------------+-----------------------+
| QUARANTINE | MALFEASANCE_PROVEN | PERMANENT_ |
| (Curator Node Only) | (Deliberate double- | DECAPITATION |
| | signing verified) | |
+---------------------+-----------------------+-----------------------+
| QUARANTINE | QUARANTINE_TIMEOUT | ACTIVE_CURATOR |
| (Curator Node Only) | (Grace period expiry | (Curator Node Only) |
| | without hard evidence)| |
+---------------------+-----------------------+-----------------------+
| ACTIVE_CURATOR/ | CURATOR_FLAGGED | AUTOMATED_EMERGENCY_ |
| QUARANTINE | (Parent curator enters| MIGRATION |
| (Sub-Space Nodes) | compromised state) | |
+---------------------+-----------------------+-----------------------+
Gebauer Expires 26 December 2026 [Page 67]
Internet-Draft IACP June 2026
7.) General IACP Workflow (DHI + ERP Integration)
+-----------------------+-----------------------+---------------------+
| Current State | Event (Input) | Next State |
+-----------------------+-----------------------+---------------------+
| INPUT_RECEIVED | INITIATE_RESOLVE | RESOLVING_INFRA |
+-----------------------+-----------------------+---------------------+
| RESOLVING_INFRA | DNS_SUCCESS | WELL_KNOWN_EVAL |
+-----------------------+-----------------------+---------------------+
| WELL_KNOWN_EVAL | ENDPOINT_UNREACHABLE | PROBLEM_CACHING |
+-----------------------+-----------------------+---------------------+
| WELL_KNOWN_EVAL | ENDPOINT_RESPONSIVE | LINK_HEADER_SNIFF |
+-----------------------+-----------------------+---------------------+
| SWITCH_POINT | HEAVY_MEDIA | LEGACY_PATH_EXECUTION|
+-----------------------+-----------------------+---------------------+
| SWITCH_POINT | PURE_DATA_STREAM | NATIVE_ANML_INGESTION|
+-----------------------+-----------------------+---------------------+
| BOUND | Routing Failure | ERP_DEFLECT (0x0E) |
+-----------------------+-----------------------+---------------------+
1.) Simplified Agent2Agent Communication via IACP
+------------------+ +-------------------+
| Host A: IP_1 | | Host B: IP_2 |
+------------------+ +-------------------+
| |
| Hosts (Persistent) | Hosts
v v
+------------------+ +-------------------+
| Node A: EID_1 | | Node B: EID_2 |
+------------------+ +-------------------+
| |
| Hosts (Ephemeral) | Hosts
v v
+------------------+ +-------------------+
| Endpoint: ESE_1 | <========= PSS ========> | Endpoint: ESE_2 |
+------------------+ (maybe with a SFC) +-------------------+
The author would like to thank Aaron Jerskey from the ANML Foundation
for their valuable feedback on this specification.
Author's Address
Gebauer Expires 26 December 2026 [Page 68]
Internet-Draft IACP June 2026
Leonard Gebauer
Independent
Germany
Email: leonard.gebauer.ha@gmail.com
Gebauer Expires 26 December 2026 [Page 69]