Network Working Group L. Gebauer Internet-Draft Independent Intended status: Informational 28 July 2026 Expires: 29 January 2027 Internet Agent Communication Protocol - DHT draft-gebauer-iacp-dht-00 Abstract Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. 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 29 January 2027. 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. Gebauer Expires 29 January 2027 [Page 1] Internet-Draft IACP - DHT July 2026 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. DHT Namespace Architecture and Distributed Security . . . . . 3 2.1. Distributed Hash Table . . . . . . . . . . . . . . . . . 3 2.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.2. DHT Namespace Structure . . . . . . . . . . . . . . . 3 2.1.3. DHT Overlay Construction . . . . . . . . . . . . . . 4 2.2. Namespace Registration and Curation . . . . . . . . . . . 19 2.2.1. Root Namespace Registration . . . . . . . . . . . . . 19 2.2.2. Sub-Namespace Delegation . . . . . . . . . . . . . . 20 2.3. Proof-of-Work and Reputation-Based Access Control . . . . 20 2.3.1. Dynamic PoW Difficulty . . . . . . . . . . . . . . . 21 2.3.2. Access Tickets and Joint Liability . . . . . . . . . 21 2.4. Anti-Abuse Mechanisms . . . . . . . . . . . . . . . . . . 21 2.4.1. Token-Bucket Filters and Rate Limiting . . . . . . . 22 2.4.2. Autonomous Circuit Breakers . . . . . . . . . . . . . 22 2.5. Proof of Malfeasance (PoM) and Slashing . . . . . . . . . 22 2.5.1. PoM Ticket Specification . . . . . . . . . . . . . . 22 2.5.2. Two-Phase Slashing Escrow (2PSE) . . . . . . . . . . 34 2.5.3. Curator Quarantine and Decapitation . . . . . . . . . 34 2.5.4. Reputation Penalties . . . . . . . . . . . . . . . . 35 2.6. Compromise Recovery and Hot-Docking . . . . . . . . . . . 35 2.6.1. Migration Stream Serialization . . . . . . . . . . . 35 2.6.2. Migration Stream Encryption . . . . . . . . . . . . . 35 2.6.3. Forwarding Ticket Generation . . . . . . . . . . . . 36 2.6.4. Migration Flow . . . . . . . . . . . . . . . . . . . 36 2.6.5. EID Revocation and Propagation . . . . . . . . . . . 37 2.7. Layer-Separated Economic Governance and Edge Gatekeeper Model . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.7.1. Layer 4 Kernel-Space Fast-Path . . . . . . . . . . . 40 2.7.2. Layer 7 Application-Space Door-Keeper (Opaque Authorization Envelope) . . . . . . . . . . . . . . . 42 2.7.3. Asynchronous Verification and Teardown . . . . . . . 42 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.1. Normative References . . . . . . . . . . . . . . . . . . 43 3.2. Informative References . . . . . . . . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44 Gebauer Expires 29 January 2027 [Page 2] Internet-Draft IACP - DHT July 2026 1. Introduction This document is merely a sub-I-D of the main I-D. For appendices, acknowledgments, Security Considerations, IANA Considerations and other information, please refer to the main I-D. This sub-I-D contains only a 1:1 copy of the chapter it covers, to provide a better basis for discussion. 1.1. 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. 2. DHT Namespace Architecture and Distributed Security 2.1. Distributed Hash Table 2.1.1. General 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. 2.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). Gebauer Expires 29 January 2027 [Page 3] Internet-Draft IACP - DHT July 2026 +---------------------------------------------------------------------+ | 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. 2.1.3. DHT Overlay Construction The IACP DHT overlay is structured as a Kademlia-based distributed hash table [Kademlia] with a 256-bit identifier space. Each participating node is assigned a Node ID, which is the SHA-256 hash of its EID. 2.1.3.1. Peer Discovery and Bootstrap A node joining the IACP DHT overlay MUST obtain at least one bootstrap entry point. Bootstrap entries MAY be obtained through: 1. Static Bootstrap Nodes: A set of well-known, stable nodes operated by the namespace curator or infrastructure provider. These are configured out-of-band. 2. DNS-based Discovery: A DNS SRV record [RFC2782] for _iacp- dht._udp.{namespace} MAY be used to discover bootstrap nodes. 3. Cache Persistence: Nodes SHOULD persist a local cache of previously known peers to accelerate rejoining. Upon obtaining bootstrap contact, the node performs a Kademlia FIND_NODE operation to populate its routing table (k-buckets). The routing table uses a bucket size of k = 20. 2.1.3.2. Routing Table Maintenance Each node maintains a routing table of k-buckets organized by XOR distance from its own Node ID. Buckets are structured as follows: * Bucket 0: peers with a shared prefix length of 255 bits (closest) * Bucket i: peers with a shared prefix length of (255 - i) bits Gebauer Expires 29 January 2027 [Page 4] Internet-Draft IACP - DHT July 2026 * Maximum bucket size: k = 20 When a bucket is full and a new peer is discovered, the node pings the least-recently-seen peer in the bucket. If the peer responds, the new peer is not added. If the peer does not respond, it is evicted and the new peer is added. 2.1.3.3. Replication and Redundancy To ensure availability under churn, each key-value pair (EID-to- locator mapping or Forwarding Ticket) MUST be stored on the k closest nodes to the key, where k = 20. Additionally: * Replication Factor: r = 7 (the key is stored on the 7 closest nodes). * Republish Interval: Nodes MUST republish their own mappings every T_republish = 24 hours. * Expiration: Mappings have a TTL of T_expire = 48 hours. Nodes MUST refresh a mapping before expiration by re-issuing the STORE operation. 2.1.3.4. Lookup Operations Lookups for an EID coordinate follow the standard Kademlia iterative lookup: 1. The initiating node selects alpha = 3 nodes from its routing table closest to the target key. 2. It sends parallel FIND_NODE requests to these nodes. 3. Each responding node returns the k closest nodes it knows to the target key. 4. The initiator updates its routing table with the responses and continues the iterative process until it has contacted the closest nodes or until no closer nodes are found. The lookup is considered successful if the target key is found or if the closest nodes report that the key does not exist. 2.1.3.5. Anti-Eclipse and Sybil Protections To mitigate Eclipse and Sybil attacks, the IACP DHT overlay enforces the following: Gebauer Expires 29 January 2027 [Page 5] Internet-Draft IACP - DHT July 2026 1. Proof-of-Work for Node IDs: Node IDs are derived from EIDs, which already require Proof-of-Work for registration (see Section 5.3). This makes Sybil generation computationally expensive. 2. Randomized Bucket Selection: When selecting nodes for lookup operations, the initiator SHOULD include a random selection from the k-bucket in addition to the closest nodes to prevent an attacker from monopolizing a bucket. 3. Bucket Freshness: Nodes MUST periodically (every T_refresh = 5 minutes) ping the least-recently-seen peer in each bucket to detect churn and evict stale entries. 2.1.3.6. Lookup Flow The iterative lookup process follows this flow: +-------------+ +-------------+ +-------------+ | Initiator | | Node A | | Node B | +-------------+ +-------------+ +-------------+ | | | | 1. FIND_NODE | | |------------------>| | | | | | 2. RETURN k | | |<------------------| | | | | | 3. FIND_NODE | | |-------------------------------------->| | | | | 4. RETURN k | | |<--------------------------------------| | | | v (Continue until closest nodes found) v +-------------+ +-------------+ +-------------+ | Result | | Closest | | Closest | | Found | | Node Set | | Node Set | +-------------+ +-------------+ +-------------+ 2.1.3.7. Global Directory Quorum and Consensus 2.1.3.7.1. Quorum Formation A Global Directory Quorum for a given EID or key is formed as follows: Gebauer Expires 29 January 2027 [Page 6] Internet-Draft IACP - DHT July 2026 1. Candidate Selection: The initiating node selects the k = 20 closest nodes to the target key (SHA-256(EID) for EID mappings, SHA-256(Namespace) for namespace operations) from its routing table. 2. Quorum Selection: From these 20 candidates, the quorum is formed by selecting a deterministic subset of n = 7 nodes. The selection uses the following algorithm: * Sort the 20 candidates by XOR distance to the target key. * Apply a pseudo-random permutation seeded by the target key: PRP_key = SHA-256(target_key || "IACP_QUORUM_SALT") * Select the first 7 nodes from the permuted list. This randomized selection prevents an attacker from predicting or monopolizing the quorum for a specific key. 3. Quorum Set: The resulting set Q = {q1, q2, ..., q7} constitutes the Global Directory Quorum for the target key. The quorum set is valid for T_quorum = 1 hour from the time of selection. After T_quorum expires, the quorum MUST be reformed. 4. Quorum Caching: Nodes SHOULD cache the quorum set for a given key to avoid re-computation. Cache entries MUST be invalidated on quorum expiry or when the node's routing table changes significantly (e.g., after joining or leaving the overlay). 2.1.3.7.2. Byzantine Fault Tolerance The Global Directory Quorum operates under the following fault tolerance assumptions: * BFT Assumption: The quorum tolerates up to f = 2 Byzantine faults among the 7 quorum nodes. This is consistent with the standard BFT bound of n = 3f + 1 (i.e., 7 >= 3*2 + 1 = 7). * Failure Modes: Byzantine failures include: - Malicious nodes submitting false PoM tickets. - Nodes colluding to suppress valid PoM tickets. - Nodes equivocating (signing conflicting validation results). - Nodes failing to respond within the timeout window. Gebauer Expires 29 January 2027 [Page 7] Internet-Draft IACP - DHT July 2026 * Honest Node Assumption: The protocol assumes that at least f + 1 = 3 nodes in any quorum are honest (non-Byzantine). This is the minimum required to achieve consensus. * Stronger Assumptions: Applications requiring higher fault tolerance MAY increase the quorum size n to support larger f. The relationship n >= 3f + 1 MUST be maintained. 2.1.3.7.3. PoM Ticket Validation Protocol A PoM ticket is validated by the Global Directory Quorum through the following protocol: 1. Ticket Submission: The accusing node submits a PoM ticket (Type 0x18) to the quorum. The ticket MUST be sent to all 7 quorum nodes. The submission includes the PoM_Ticket structure. 2. Individual Validation (Phase 1): Each quorum node independently validates the PoM ticket: a. Signature Verification: Verify that Signature_A and Signature_B are valid Ed25519 signatures against the Target_EID public key. b. Structural Check: Verify that Header_Fragment_A and Header_Fragment_B are structurally non-identical. c. Freshness Check: Verify that the Timestamp is within T_fresh = 5 minutes of the node's current time. Nodes MUST reject tickets with stale timestamps. d. Double-Spending Check: Verify that the Target_EID is not already in STATE_SLASHED. If any validation check fails, the node MUST respond with a POM_VALIDATION_REJECT message indicating the failure reason. 3. Voting Phase (Phase 2): Each node that successfully validates the PoM ticket sends a POM_VALIDATION_ACCEPT message to all other quorum nodes. The message MUST include the node's signature: POM_VALIDATION_ACCEPT = { Ticket_Hash: SHA-256(PoM_Ticket), EID_Validator: EID of the validating node, Timestamp: Current time, Signature: Sign_Ed25519(Private_Key_Validator, Ticket_Hash || EID_Validator || Timestamp) } Gebauer Expires 29 January 2027 [Page 8] Internet-Draft IACP - DHT July 2026 1. Consensus Phase (Phase 3): Each node collects validation messages. Consensus is reached when at least m = 4 out of 7 nodes have sent POM_VALIDATION_ACCEPT for the same ticket hash. The threshold m = ceil((n + 1) / 2) = ceil(8/2) = 4 ensures a simple majority. 2. Commit Phase (Phase 4): Upon reaching consensus, each node: a. Commits the PoM ticket to its local ledger. b. Triggers the 2PSE process, transitioning the Target_EID to STATE_CHALLENGED. c. Propagates the committed PoM ticket to the DHT overlay. The committing node sends a POM_COMMIT message to the quorum: POM_COMMIT = { Ticket_Hash: SHA-256(PoM_Ticket), Consensus_Proof: [POM_VALIDATION_ACCEPT_1, ..., POM_VALIDATION_ACCEPT_m], EID_Committer: EID of the committing node, Signature: Sign_Ed25519(Private_Key_Committer, Ticket_Hash || Consensus_Proof) } 1. Timeout: If the quorum does not reach consensus within T_consensus = 30 seconds, the ticket validation fails. The accusing node MAY retry the submission after an exponential backoff (T_base = 2 seconds, T_max = 60 seconds). 2.1.3.7.4. Network Partition and Split-Brain Handling Network partitions (split-brain scenarios) are handled as follows: 1. Partition Detection: Nodes detect partitions by monitoring quorum member responsiveness. If a node fails to receive responses from at least m = 4 quorum members within T_heartbeat = 10 seconds, the node assumes a partition exists. 2. Quorum Reform: During a partition, the node MUST NOT initiate new PoM validations. Existing validation attempts continue. 3. Conflict Resolution: If two partitions independently validate conflicting PoM tickets, the following rules apply: a. Larger Partition: The partition with the larger number of quorum nodes (>= 4) takes precedence. The smaller partition MUST discard its validation results and synchronize with the larger partition upon reconnection. Gebauer Expires 29 January 2027 [Page 9] Internet-Draft IACP - DHT July 2026 b. Tie Handling: If both partitions have exactly 3 nodes (a 3-4 split), no consensus is possible. All validation attempts in both partitions MUST be aborted. The target EID remains in STATE_NOMINAL. The accusing node MUST retry after the partition resolves. c. Rollback: When a partition resolves, nodes in the smaller partition MUST roll back any state changes made during the partition (e.g., PoM ticket commits) and synchronize with the larger partition's state. 4. Conflict Log: All partition events, including aborted validations and rollback decisions, MUST be logged for audit purposes. The log MUST include timestamps, partition node sets, and the affected target EIDs. 5. Recovery: After partition resolution, nodes SHOULD wait T_recovery = 60 seconds before initiating new PoM validations to allow the overlay to stabilize. 2.1.3.7.5. Quorum Member Liveness To ensure quorum availability, the following liveness rules apply: 1. Heartbeat: Each quorum member MUST send a QUORUM_HEARTBEAT message to all other quorum members every T_heartbeat = 10 seconds. 2. Failure Detection: If a node misses T_heartbeat_fail = 3 consecutive heartbeats (30 seconds), it is considered failed. 3. Member Replacement: When a quorum member is considered failed, the remaining nodes MUST replace it. The replacement is selected from the k = 20 candidate set as the next node in the permuted list that is not already in the quorum. 4. Quorum Stability: The quorum SHOULD maintain n = 7 nodes at all times. Replacement MUST occur within T_replace = 60 seconds of failure detection. 2.1.3.8. Routing Table Maintenance Each node maintains a routing table of k-buckets organized by XOR distance from its own Node ID. Buckets are structured as follows: * Bucket 0: peers with a shared prefix length of 255 bits (closest) * Bucket i: peers with a shared prefix length of (255 - i) bits Gebauer Expires 29 January 2027 [Page 10] Internet-Draft IACP - DHT July 2026 * Maximum bucket size: k = 20 When a bucket is full and a new peer is discovered, the node pings the least-recently-seen peer in the bucket. If the peer responds, the new peer is not added. If the peer does not respond, it is evicted and the new peer is added. When a node's routing table is initialized, it contains a single bucket covering the entire 256-bit identifier space (bucket 0). As the node learns about more peers, the bucket splits according to the following algorithm: * The node maintains a list of buckets, each covering a contiguous range of the identifier space. * When a bucket exceeds its maximum size k = 20, the node splits the bucket into two new buckets. * The split point is determined by the node's own Node ID: the bucket is divided at the bit position where the node's ID differs from the bucket's range midpoint. * The left bucket (closer to 0x0000...0000) and right bucket (closer to 0xFFFF...FFFF) each cover half of the original range. * The node redistributes the existing peers from the original bucket into the two new buckets based on their XOR distance to the node's own ID. * Buckets that do not contain the node's own ID MAY be split further, but only if they contain at least k + 1 peers. The splitting process continues until the routing table contains buckets for each prefix length where the node has at least one peer. To maintain bucket freshness, each bucket entry includes a timestamp of the last successful contact with the peer. The least-recently- seen peer is determined by comparing these timestamps. When a bucket is full and a new peer is discovered, the node pings the least- recently-seen peer in the bucket. If the peer responds within T_ping = 1 second, the node updates the peer's timestamp to the current time, the new peer is not added, and the node MAY add the new peer to a replacement cache. If the peer does not respond within T_ping, the node removes the stale peer from the bucket, adds the new peer to the bucket with the current timestamp, and if the replacement cache contains peers for this bucket, the node SHOULD attempt to add them as well. Gebauer Expires 29 January 2027 [Page 11] Internet-Draft IACP - DHT July 2026 To detect churn and evict stale entries, nodes MUST periodically refresh each bucket: * The refresh interval is T_refresh = 5 minutes. * For each bucket, the node selects the least-recently-seen peer and sends a ping. * If the peer responds, the timestamp is updated. * If the peer does not respond, it is evicted and replaced by the most recent peer from the replacement cache, if available. * If the replacement cache is empty, the bucket is left with one fewer entry. * The refresh process is spread across the T_refresh interval to avoid bursts of network traffic. The node SHOULD refresh buckets in random order. The following limits apply to the routing table: * Maximum buckets: 256 (one per bit prefix length) * Maximum bucket size: k = 20 * Maximum total routing table entries: 256 * 20 = 5120 entries In practice, a node will only have entries in buckets where it has discovered peers. The total number of entries is typically O(log n) where n is the number of nodes in the overlay, which is around 160 entries for a network of 2^160 nodes. Nodes SHOULD implement a maximum routing table size of 5120 entries. If this limit is exceeded, the node SHOULD evict the least-recently-seen peers from the least-relevant buckets (those furthest from the node's own ID). Each node maintains a replacement cache for each bucket. The replacement cache stores peers that were discovered but could not be added because the bucket was full: * Cache size: C = 10 entries per bucket (RECOMMENDED). * Cache entries have a TTL of T_cache = 1 hour. * When a peer is evicted from a bucket, the most recent entry from the replacement cache is promoted to the bucket. Gebauer Expires 29 January 2027 [Page 12] Internet-Draft IACP - DHT July 2026 * When a new peer is discovered and the bucket is full, the peer is added to the replacement cache if it is not already present. The replacement cache prevents the loss of potential routing information when buckets are full. 2.1.3.9. Replication and Redundancy To ensure availability under churn, each key-value pair (EID-to- locator mapping or Forwarding Ticket) MUST be stored on the k closest nodes to the key, where k = 20. Additionally: * Replication Factor: r = 7 (the key is stored on the 7 closest nodes). * Republish Interval: Nodes MUST republish their own mappings every T_republish = 24 hours. * Expiration: Mappings have a TTL of T_expire = 48 hours. Nodes MUST refresh a mapping before expiration by re-issuing the STORE operation. The replication set for a key is determined as follows: * The node computes the key's SHA-256 hash (for namespace mappings) or uses the EID directly (for EID-to-locator mappings). * The node performs a FIND_NODE lookup to identify the k = 20 closest nodes to the key. * The replication set is the first r = 7 nodes from this list. * The key-value pair is stored on all r nodes. To ensure redundancy, each replication node MUST store the key-value pair for T_expire = 48 hours. If a replication node fails, the remaining nodes SHOULD replicate the key to a replacement node from the k = 20 candidate set. To prevent accumulation of stale mappings: * Each node MUST periodically (every T_prune = 1 hour) scan its local DHT storage for entries with expired TTLs. * Entries older than T_expire = 48 hours MUST be deleted. * Entries with TTL less than T_expire_alert = 6 hours SHOULD trigger a refresh request to the originating node. Gebauer Expires 29 January 2027 [Page 13] Internet-Draft IACP - DHT July 2026 * If the originating node does not refresh the entry within T_expire, the entry is deleted. Nodes SHOULD implement a lazy deletion strategy: entries are marked as stale and deleted on access rather than during periodic scans, to reduce CPU overhead. 2.1.3.10. Lookup Operations Lookups for an EID coordinate follow the standard Kademlia iterative lookup: 1. The initiating node selects alpha = 3 nodes from its routing table closest to the target key. 2. It sends parallel FIND_NODE requests to these nodes. 3. Each responding node returns the k closest nodes it knows to the target key. 4. The initiator updates its routing table with the responses and continues the iterative process until it has contacted the closest nodes or until no closer nodes are found. The lookup is considered successful if the target key is found or if the closest nodes report that the key does not exist. 2.1.3.11. Anti-Eclipse and Sybil Protections To mitigate Eclipse and Sybil attacks, the IACP DHT overlay enforces the following: 1. Proof-of-Work for Node IDs: Node IDs are derived from EIDs, which already require Proof-of-Work for registration. This makes Sybil generation computationally expensive. 2. Randomized Bucket Selection: When selecting nodes for lookup operations, the initiator SHOULD include a random selection from the k-bucket in addition to the closest nodes to prevent an attacker from monopolizing a bucket. 3. Bucket Freshness: Nodes MUST periodically (every T_refresh = 5 minutes) ping the least-recently-seen peer in each bucket to detect churn and evict stale entries. Gebauer Expires 29 January 2027 [Page 14] Internet-Draft IACP - DHT July 2026 2.1.3.12. Lookup Flow The iterative lookup process follows this flow: +-------------+ +-------------+ +-------------+ | Initiator | | Node A | | Node B | +-------------+ +-------------+ +-------------+ | | | | 1. FIND_NODE | | |------------------>| | | | | | 2. RETURN k | | |<------------------| | | | | | 3. FIND_NODE | | |-------------------------------------->| | | | | 4. RETURN k | | |<--------------------------------------| | | | v (Continue until closest nodes found) v +-------------+ +-------------+ +-------------+ | Result | | Closest | | Closest | | Found | | Node Set | | Node Set | +-------------+ +-------------+ +-------------+ 2.1.3.13. Local Caching To reduce DHT lookup latency and network overhead, nodes SHOULD maintain a local cache of recently resolved EID-to-locator mappings and Forwarding Tickets. The local cache is a key-value store with the following structure: * Key: SHA-256(EID) (for EID-to-locator mappings) or the storage key (for Forwarding Tickets) * Value: (IP address, Port, Generation Counter, Timestamp, TTL) * TTL: T_cache = 300 seconds (5 minutes) for EID-to-locator mappings, T_forward = 7 days for Forwarding Tickets When a node needs to resolve an EID: 1. The node checks the local cache for the key SHA-256(EID). 2. If the entry exists and has not expired (Timestamp + TTL > current_time): Gebauer Expires 29 January 2027 [Page 15] Internet-Draft IACP - DHT July 2026 * The node returns the cached mapping. * The node updates the entry's timestamp to the current time. 3. If the entry does not exist or has expired: * The node performs a DHT lookup. * If the lookup succeeds, the node stores the result in the cache with TTL = 300 seconds. The local cache MUST be invalidated under the following conditions: * The node receives a MIGRATION_VECTOR for the EID with a higher Generation Counter. * The node receives a REVOCATION_SUBMIT for the EID. * The node detects that the cached IP address is unreachable (ping fails). * The cache entry's TTL expires. When a cache entry is invalidated, the node MUST remove the entry from the cache and perform a fresh DHT lookup on the next request. The local cache SHOULD be limited to C_max = 10000 entries to prevent memory exhaustion. When the cache exceeds this limit, the node SHOULD evict the least-recently-used (LRU) entries first. Nodes in resource-constrained environments (e.g., IoT devices) SHOULD use a smaller cache size (e.g., C_max = 1000 entries) to reduce memory consumption. 2.1.3.14. Churn Handling The DHT overlay MUST handle node churn (nodes joining, leaving, and failing) gracefully. When a node joins the DHT overlay: 1. The node obtains bootstrap contact. 2. The node performs a FIND_NODE lookup for its own Node ID to populate its routing table. 3. The node sends a STORE operation to the replication set for its own EID-to-locator mapping. Gebauer Expires 29 January 2027 [Page 16] Internet-Draft IACP - DHT July 2026 4. The node begins participating in routing and query forwarding. When a node leaves the DHT overlay gracefully: * The node SHOULD send a LEAVE message to the replication nodes storing its key-value pairs. * The node SHOULD store its key-value pairs on replacement nodes before leaving. * The node SHOULD send a PSS_TEARDOWN to terminate all active PSS sessions. If a node leaves without notice (crash or network partition), the replication set must handle the failure. Nodes detect failures using the following mechanisms: * PING/PONG: Nodes periodically ping peers in their routing table. If a peer fails to respond to T_ping_fail = 3 consecutive pings (each separated by T_ping_interval = 1 second), the peer is considered failed. * Quorum Heartbeat: Quorum members send heartbeats every T_heartbeat = 10 seconds. Failure to receive 3 consecutive heartbeats indicates a failure. * Passive Detection: If a node fails to respond to FIND_NODE or STORE requests, it is considered potentially failed. The requesting node SHOULD retry with a different node. When a node in the replication set fails: 1. The remaining replication nodes detect the failure via heartbeat. 2. The remaining nodes select a replacement from the k = 20 candidate set. 3. The replacement node is the next node in the permuted list that is not already in the quorum and is reachable. 4. The remaining nodes replicate all key-value pairs for the affected key to the replacement node. 5. The quorum is restored to n = 7 nodes. When a network partition occurs: Gebauer Expires 29 January 2027 [Page 17] Internet-Draft IACP - DHT July 2026 * Partition Detection: Nodes detect partitions by monitoring quorum member responsiveness. If a node fails to receive responses from at least m = 4 quorum members within T_heartbeat = 10 seconds, the node assumes a partition exists. * During a partition, nodes MUST NOT initiate new PoM validations. * If two partitions independently commit conflicting state, the larger partition (>= 4 nodes) takes precedence. * After partition resolution, nodes in the smaller partition MUST roll back any state changes made during the partition and synchronize with the larger partition. * Nodes SHOULD wait T_recovery = 60 seconds after partition resolution before initiating new operations. The DHT overlay is designed to handle churn rates of up to 10% of nodes per hour without significant performance degradation. The following factors contribute to churn resilience: * Replication factor r = 7 ensures that data remains available even if multiple replication nodes fail. * Bucket refresh (T_refresh = 5 minutes) detects and evicts stale peers quickly. * Replacement cache ensures that routing table entries are replaced efficiently. * Local cache reduces DHT lookup frequency during churn events. 2.1.3.15. DHT Message Types The following DHT-specific message types are defined and used internally by the DHT overlay. They are not exposed to the application layer. The wire formats for these message types are defined in Appendix A. Gebauer Expires 29 January 2027 [Page 18] Internet-Draft IACP - DHT July 2026 | Type | Name | |------|--------------------| | 0x3A | DHT_FIND_NODE | | 0x3B | DHT_FIND_NODE_RESP | | 0x3C | DHT_STORE | | 0x3D | DHT_STORE_ACK | | 0x3E | DHT_PING | | 0x3F | DHT_PONG | | Type | Description | |------|--------------------------------------------------| | 0x3A | Find the k closest nodes to a target key | | 0x3B | Response to FIND_NODE with list of closest nodes | | 0x3C | Store a key-value pair on a replication node | | 0x3D | Acknowledgment of STORE operation | | 0x3E | Ping a peer to check liveness | | 0x3F | Response to PING | Additionally, each node in the Node List is encoded as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Node EID [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Node IP [16 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port [2 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Generation Counter [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.2. Namespace Registration and Curation 2.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 29 January 2027 [Page 19] Internet-Draft IACP - DHT July 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] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.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. 2.3. Proof-of-Work and Reputation-Based Access Control Gebauer Expires 29 January 2027 [Page 20] Internet-Draft IACP - DHT July 2026 2.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. 2.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. 2.4. Anti-Abuse Mechanisms Gebauer Expires 29 January 2027 [Page 21] Internet-Draft IACP - DHT July 2026 2.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. 2.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. 2.5. Proof of Malfeasance (PoM) and Slashing 2.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 29 January 2027 [Page 22] Internet-Draft IACP - DHT July 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. 2.5.1.1. Timestamp Synchronization The PoM_Ticket structure includes a Timestamp field marked as "Cluster-synchronized verification time". This subsection specifies how nodes achieve and maintain the required clock synchronization. The Timestamp field MUST represent the current time in UTC as a 64-bit UNIX timestamp (seconds since 1970-01-01T00:00:00Z). Nodes MUST ensure that their local clocks are synchronized to within a bounded drift of the global time reference. 2.5.1.1.1. Primary Synchronization Mechanism: NTP Nodes MUST implement Network Time Protocol (NTP) [RFC5905] or a successor standard (e.g., NTS [RFC8915]) for clock synchronization. The following requirements apply: Gebauer Expires 29 January 2027 [Page 23] Internet-Draft IACP - DHT July 2026 1. NTP Pool: Nodes SHOULD use a diverse set of NTP servers. The RECOMMENDED minimum is 4 servers from different administrative domains to reduce the risk of coordinated time manipulation. 2. Synchronization Interval: Nodes MUST synchronize their clocks at least once every T_sync = 60 seconds while online. 3. Drift Tolerance: The acceptable clock drift between any two nodes in the DHT overlay is T_drift = 5 seconds. NTP implementations MUST maintain accuracy within this bound. 4. Fallback Servers: Nodes SHOULD maintain a list of at least 2 fallback NTP servers in case the primary servers are unreachable. 2.5.1.1.2. Alternative Synchronization Mechanisms For environments where NTP is unavailable or undesirable, nodes MAY use alternative synchronization mechanisms: 1. Precision Time Protocol (PTP) [IEEE1588]: For networks with hardware timestamping support, PTP provides higher accuracy (sub- microsecond) than NTP. 2. GPS/GNSS: For nodes with GPS receivers, GPS time provides a highly accurate global time reference. 3. Blockchain Timestamping: Nodes in a blockchain-integrated deployment MAY use block timestamps as a reference. However, block timestamps are only advisory (per [RFC6962] Section 2.1) and MUST NOT be the sole synchronization source. 4. Manual Configuration: As a last resort, operators MAY manually configure the system time. This is NOT RECOMMENDED for production deployments. Regardless of the mechanism used, nodes MUST maintain the T_drift = 5 seconds accuracy bound. 2.5.1.1.3. Time Validation in PoM Ticket Processing When a quorum node validates a PoM ticket, it MUST perform the following time-related checks: 1. Absolute Freshness: The Timestamp MUST be within T_fresh = 5 minutes of the node's current time. Tickets with timestamps older than T_fresh MUST be rejected. Gebauer Expires 29 January 2027 [Page 24] Internet-Draft IACP - DHT July 2026 2. Clock Drift Compensation: The node MAY apply a drift compensation factor of up to T_drift = 5 seconds when evaluating the freshness of a ticket. This compensates for minor synchronization differences between nodes. 3. Replay Prevention: If a ticket with the same Timestamp and Target_EID has been seen within the last T_replay = 10 minutes, the node MUST reject the ticket as a replay attempt. 4. Monotonic Sequence Check: The node MUST verify that the Sequence_Number in the ticket is strictly greater than the last known sequence number for the Target_EID. This prevents reordering attacks even if timestamps are close. 2.5.1.1.4. Handling Synchronization Failures If a node cannot synchronize its clock within T_drift = 5 seconds for more than T_sync_fail = 10 minutes, the following rules apply: 1. Quorum Participation: The node MUST NOT participate in PoM ticket validation until synchronization is restored. It SHOULD respond with a POM_VALIDATION_REJECT (reason: CLOCK_UNSYNCHRONIZED) to any validation requests. 2. Degraded Operation: The node MAY continue to forward packets and participate in routing, but MUST mark its state as CLOCK_UNSYNCHRONIZED in its DHT advertisements. 3. Recovery: Upon successful resynchronization, the node MUST wait T_recovery = 5 minutes before rejoining the quorum to allow its clock to stabilize. 4. Alerting: The node SHOULD generate an alert to the operator when synchronization fails. 2.5.1.1.5. Offline Node Timestamp Handling Nodes that operate offline for extended periods (e.g., mobile agents) MAY use the following fallback: 1. Last Known Time: The node uses the last known synchronized time plus the elapsed time since synchronization (measured by the node's local oscillator). 2. Bounded Drift: The node MUST assume a worst-case drift of T_drift_offline = 1 second per hour of offline operation. Gebauer Expires 29 January 2027 [Page 25] Internet-Draft IACP - DHT July 2026 3. Freshness Check at Reconnection: Upon reconnection, the node MUST synchronize its clock before submitting any PoM tickets. The node MUST discard any tickets generated during the offline period that exceed T_fresh = 5 minutes. 4. Trust Reduction: Nodes that have been offline for more than T_offline_max = 24 hours SHOULD be treated as less trustworthy and SHOULD be subject to escalated PoW requirements until they have been online for T_online_stable = 1 hour. 2.5.1.1.6. Normative Notes The timestamp synchronization requirements in this section are normative. Conforming IACP implementations: * MUST implement NTP [RFC5905] or provide equivalent synchronization accuracy (T_drift <= 5 seconds). * MUST validate timestamps according to the rules in this section. * MUST handle synchronization failures according to the rules in this section. 2.5.1.2. PoM Ticket Canonicalization and Semantics A Proof of Malfeasance (PoM) ticket relies on the comparison of two cryptographically signed messages to detect equivocation. This section defines: 1. Which messages are subject to PoM verification. 2. How messages are canonicalized for comparison. 3. What semantic conditions constitute a valid PoM. 2.5.1.2.1. Canonicalization Target: The Signed Payload For the purposes of PoM verification, the "message" that is signed is defined as the complete IACP control frame payload for the following message types: * ERP_REGISTER (Type 0x15) * MIGRATION_VECTOR (Type 0x17) * ERP_EVOLVE (Type 0x16) * Any message that modifies the EID-to-locator mapping Gebauer Expires 29 January 2027 [Page 26] Internet-Draft IACP - DHT July 2026 The canonicalization process MUST include all fields of these messages except: * The Signature field itself (it is self-referential) * Timestamp fields (they are not part of the signed payload) * Nonce fields (they are not part of the signed payload) All other fields, including EID, IP address, Generation Counter, and Application Digest, are included in the canonicalized message. 2.5.1.2.2. Canonicalization Format The canonicalization format depends on the message serialization: 1. Binary Messages (e.g., ERP_REGISTER, MIGRATION_VECTOR): The message is canonicalized as the concatenation of all fields in the order they appear in the wire format, excluding the signature field. The length of each field is determined by its type. 2. JSON Messages (e.g., Trust Anchor Documents): The message is canonicalized using JSON Canonicalization Scheme (JCS) [RFC8785]. 3. CBOR Messages: The message is canonicalized using Canonical CBOR as defined in RFC 8949 Section 3.9. The canonicalized representation is a byte string. The SHA-256 hash of this byte string is used as the message digest in the PoM ticket. 2.5.1.2.3. Semantic Fields for PoM Verification The following fields are considered semantically relevant for PoM verification: | Field | Message Types | |--------------------|-----------------------------------| | Source_EID | All | | Current_IP | ERP_REGISTER, MIGRATION_VECTOR | | Generation_Counter | ERP_REGISTER, MIGRATION_VECTOR | | Current_App_Digest | ERP_EVOLVE | | Field | Semantics | |--------------------|-----------------------------------| | Source_EID | The identity of the signer | | Current_IP | The claimed transport locator | | Generation_Counter | The epoch of the mapping | | Current_App_Digest | The software version | Gebauer Expires 29 January 2027 [Page 27] Internet-Draft IACP - DHT July 2026 Two messages are considered "conflicting" if: 1. They are signed by the same EID. 2. They have the same Generation_Counter (same logical epoch). 3. They differ in at least one semantically relevant field. Messages with different Generation_Counter values are NOT considered conflicting (they represent legitimate state evolution). Messages with the same Generation_Counter but differing in non-semantic fields (e.g., TTL, Nonce) are NOT considered conflicting. 2.5.1.2.4. PoM Verification Procedure The Global Directory Quorum validates a PoM ticket as follows: 1. Extract Digests: Extract Digest_A and Digest_B from the PoM ticket. Each digest is the SHA-256 hash of a canonicalized signed message. 2. Verify Signatures: Verify that Signature_A and Signature_B are valid against Target_EID and cover Digest_A and Digest_B respectively. 3. Retrieve Original Messages: Retrieve the original messages (or their canonicalized forms) from the network ledger or from the ticket itself. The ticket MUST include enough information to locate or reconstruct the original messages. 4. Canonicalize: Re-canonicalize the original messages using the procedure described above. 5. Hash Comparison: Compute SHA-256 of the canonicalized messages and verify they match Digest_A and Digest_B. 6. Semantic Comparison: Compare the semantically relevant fields of the two messages. 7. Decision: If the messages are signed by the same EID, have the same Generation_Counter, and differ in at least one semantically relevant field, the PoM ticket is valid. Otherwise, it is invalid. 2.5.1.2.5. Example: Legitimate vs. Malicious Updates Legitimate IP Change (MIGRATION_VECTOR): Gebauer Expires 29 January 2027 [Page 28] Internet-Draft IACP - DHT July 2026 Message_A: { EID = X, IP = 192.0.2.1, Gen = 5 } Message_B: { EID = X, IP = 192.0.2.2, Gen = 6 } Gen differs -> NOT a PoM. This is legitimate mobility. Equivocation (Malicious): Message_A: { EID = X, IP = 192.0.2.1, Gen = 5 } Message_B: { EID = X, IP = 192.0.2.2, Gen = 5 } Gen same, IP differs -> PoM VALID. This is equivocation. Same State (No Violation): Message_A: { EID = X, IP = 192.0.2.1, Gen = 5, TTL = 300 } Message_B: { EID = X, IP = 192.0.2.1, Gen = 5, TTL = 600 } Gen same, IP same, only TTL differs -> NOT a PoM. 2.5.1.3. Decentralized PoM Count Consistency The IACP DHT overlay maintains a decentralized, eventually consistent count of PoM tickets per EID to enforce the slashing threshold (PoM_Count >= 3 within a rolling 24-hour window). This section specifies how the PoM_Count is maintained, synchronized, and reconciled across the DHT overlay. 2.5.1.3.1. Local PoM Ledger Each node in the DHT overlay maintains a local PoM ledger containing PoM tickets that the node has observed and validated. The ledger consists of the following fields per entry: PoM_Ledger_Entry = { Target_EID: The EID of the accused entity (32 bytes), Ticket_Hash: SHA-256 of the PoM ticket (32 bytes), Timestamp: UNIX timestamp of ticket validation (8 bytes), Validator_EID: EID of the validating node (32 bytes), Quorum_Proof: Reference to quorum consensus (variable), Status: VALID, CHALLENGED, or SLASHED (1 byte) } The local PoM ledger is maintained for a minimum of T_ledger = 30 days to ensure that historical data is available for audits and for nodes that have been offline. Gebauer Expires 29 January 2027 [Page 29] Internet-Draft IACP - DHT July 2026 2.5.1.3.2. PoM Count Replication The PoM_Count for a given EID is replicated in the DHT overlay to ensure availability and consistency: 1. Storage Key: The PoM ledger entries for an EID are stored in the DHT under the key SHA-256("pom:" || Target_EID). 2. Replication Factor: PoM ledger entries are replicated with redundancy factor r = 7 to ensure availability under churn. 3. Replication Nodes: The r closest nodes to the storage key (SHA- 256("pom:" || Target_EID)) are responsible for storing and replicating the PoM ledger entries. 4. Merkle Tree Structure: To enable efficient synchronization, PoM ledger entries are organized as a Merkle tree. The root hash is stored in the DHT and is updated whenever a new entry is added. The PoM_Count for an EID is calculated as the number of VALID PoM tickets in the ledger that fall within the rolling 24-hour window: PoM_Count(EID, t) = count({ entry in PoM_Ledger(EID) | entry.Status = VALID AND entry.Timestamp > (t - 24h) }) 2.5.1.3.3. PoM Ticket Publishing and Ledger Update When a PoM ticket is validated by the Global Directory Quorum, the committing node MUST update the PoM ledger: 1. Local Update: The node adds the validated PoM ticket to its local PoM ledger with Status = VALID and the current timestamp. 2. DHT Propagation: The node publishes the updated PoM ledger entry to the DHT under SHA-256("pom:" || Target_EID). The publication uses a DHT_POM_UPDATE message: Gebauer Expires 29 January 2027 [Page 30] Internet-Draft IACP - DHT July 2026 DHT_POM_UPDATE = { Target_EID: The EID of the accused entity (32 bytes), Ticket_Hash: SHA-256 of the PoM ticket (32 bytes), Timestamp: UNIX timestamp of validation (8 bytes), Validator_EID: EID of the validating node (32 bytes), Quorum_Proof: Consensus proof (variable), Merkle_Root_New: Updated Merkle tree root (32 bytes), Signature: Sign_Ed25519(Private_Key_Validator, Target_EID || Ticket_Hash || Timestamp || Merkle_Root_New) } 1. Replication: The r replication nodes receive the DHT_POM_UPDATE, verify the signature and quorum proof, and update their local ledger copies. 2. Acknowledgment: Each replication node responds with a DHT_POM_ACK message confirming receipt and successful update. 3. Conflict Resolution: If a replication node detects a conflict (e.g., inconsistent Merkle root), it initiates a reconciliation process. 2.5.1.3.4. PoM Ledger Reconciliation To ensure consistency across the DHT overlay, PoM ledger entries are reconciled periodically: 1. Merkle Root Comparison: Nodes periodically (every T_reconcile = 1 hour) compare their Merkle root for each EID with the other replication nodes. If a discrepancy is found, the node initiates a reconciliation. 2. Reconciliation Protocol: The node with the more complete ledger (higher sequence number or larger Merkle tree) sends the missing entries to the other nodes. 3. Conflict Handling: If two nodes have conflicting entries for the same PoM ticket (e.g., one VALID, one CHALLENGED), the entry with the higher consensus proof (more quorum signatures) takes precedence. 4. Time-based Reconciliation: Nodes that have been offline for more than T_offline = 1 hour MUST perform a full ledger synchronization upon reconnection by requesting the full Merkle tree from the closest replication node. Gebauer Expires 29 January 2027 [Page 31] Internet-Draft IACP - DHT July 2026 5. Lazy Reconciliation: Nodes MAY defer reconciliation of low- priority EIDs (those with PoM_Count < 2) to reduce network overhead. 2.5.1.3.5. Slashing Decision Consistency The slashing decision (PoM_Count >= 3) MUST be made consistently across the DHT overlay: 1. Threshold Check: The slashing decision is triggered only after a PoM ticket has been validated by the Global Directory Quorum and the updated PoM_Count is confirmed by at least m = 4 out of 7 replication nodes. 2. Consensus on Slashing: The Global Directory Quorum MUST reach consensus on the slashing decision. The quorum nodes verify that PoM_Count >= 3 by checking their local PoM ledgers and the replicated ledger entries. 3. Slashing Commitment: Upon reaching consensus, the quorum nodes transition the target EID to STATE_SLASHED and publish a SLASH_COMMIT message to the DHT: SLASH_COMMIT = { Target_EID: The EID being slashed (32 bytes), PoM_Count: The confirmed PoM count (1 byte), Timestamp: UNIX timestamp of slashing (8 bytes), Slashing_Reason: Reason code (4 bytes), Consensus_Proof: [SLASH_VOTE_1, ..., SLASH_VOTE_m], Signature: Sign_Ed25519(Private_Key_Committer, Target_EID || PoM_Count || Timestamp || Consensus_Proof) } 1. Propagation: The SLASH_COMMIT message is propagated to all nodes in the DHT overlay. Nodes that receive this message MUST update their local PoM ledger and mark the Target_EID as STATE_SLASHED. 2.5.1.3.6. Rolling Window Consistency The rolling 24-hour window for PoM_Count calculation requires consistent timestamps across the DHT overlay: 1. Timestamp Standardization: All PoM ticket timestamps MUST be cluster-synchronized. Nodes that observe a timestamp discrepancy greater than T_drift = 5 seconds SHOULD reject the PoM ticket. Gebauer Expires 29 January 2027 [Page 32] Internet-Draft IACP - DHT July 2026 2. Window Calculation: The rolling window is calculated as (current_time - 24h) to current_time. Nodes MUST use their local synchronized time for this calculation. 3. Sliding Window Maintenance: Nodes SHOULD periodically (every T_window_maintenance = 1 hour) prune their local PoM ledger of entries that are older than 24 hours to reduce storage overhead. 4. Window Check at Slashing: When evaluating PoM_Count for slashing, nodes MUST exclude entries older than 24 hours to ensure that only recent violations are considered. 2.5.1.3.7. Byzantine Behavior in PoM Counting The following Byzantine failure modes are addressed: 1. Double-Counting: A malicious node might attempt to add the same PoM ticket multiple times. The Merkle tree structure prevents this, as each ticket hash is unique. 2. Count Inflation: A malicious node might attempt to forge PoM tickets for a target EID. The quorum validation prevents this, as forged tickets will not pass signature verification. 3. Count Suppression: A malicious replication node might attempt to suppress valid PoM tickets. The replication factor r = 7 ensures that at least m = 4 nodes are needed to suppress a ticket, making this expensive. 4. Inconsistent Views: Different nodes might have different views of the PoM_Count due to network partitions. The quorum-based consensus mechanism ensures that slashing decisions are made only when at least m = 4 nodes agree on the count. 2.5.1.3.8. Message Types for PoM Ledger The following IACP message types are defined: | Type | Name | Description | |--------|--------------------|--------------------------------------| | 0x33 | DHT_POM_UPDATE | Update PoM ledger entry in DHT | | 0x34 | DHT_POM_ACK | Acknowledgment of PoM ledger update | | 0x35 | SLASH_COMMIT | Commit slashing decision to DHT | | 0x36 | SLASH_VOTE | Vote on slashing decision | Gebauer Expires 29 January 2027 [Page 33] Internet-Draft IACP - DHT July 2026 2.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 | +--------------------+ 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. 2.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. Gebauer Expires 29 January 2027 [Page 34] Internet-Draft IACP - DHT July 2026 2.5.4. Reputation Penalties The reputation metric (Section 3.6.1) uses the following penalties: * PoM Score Normalization: PoM_Score(t) = min(1.0, PoM_Count(t) / k) with k = 5. This means that up to 5 PoM tickets are used to normalize the score; beyond 5, the score is capped at 1.0. * Decay Mechanism: PoM tickets older than 30 days are weighted with a decay factor of 0.5 (i.e., their contribution to the reputation score is halved). This ensures that older violations have less impact on current reputation. * Rehabilitation: A node with a reputation score below 0.3 (Section 3.6.2) MAY be rehabilitated after a cooldown period of 7 days without any new PoM tickets. The rehabilitation resets the PoM_Count to 0. 2.6. Compromise Recovery and Hot-Docking 2.6.1. Migration Stream Serialization The AAI operational state is serialized as a CBOR-encoded [RFC8949] object containing the following fields: * eid: The EID of the migrating agent (32 bytes) * iat: The Instance Authentication Token (32 bytes) * session_state: A CBOR map of active PSS session states * ese_state: A CBOR map of Ephemeral State Endpoint data * timestamp: A 64-bit UNIX timestamp * sequence: A monotonically increasing sequence number The serialized object is compressed using zlib (level 6) to reduce transfer size. 2.6.2. Migration Stream Encryption The serialized and compressed state is encrypted using AES-GCM-256 with a symmetric key derived from the EID's private key and the backup host's public key: K_migration = HKDF-SHA256(ECDH(Private_EID, Public_Backup), salt="", info="IACP_MIGRATION_v1") Gebauer Expires 29 January 2027 [Page 35] Internet-Draft IACP - DHT July 2026 The encrypted migration stream includes a 12-byte AEAD nonce and a 16-byte authentication tag. 2.6.3. Forwarding Ticket Generation After a successful migration, the compromised host generates a Forwarding Ticket (Section 3.5) containing the new backup host's network locator. The Forwarding Ticket is signed with the EID's private key and stored in the DHT under KEY = SHA-256(EID). In-flight packets destined for the old locator are redirected to the new locator via the Forwarding Ticket. The old host's EID mapping is invalidated after T_invalidate = 5 minutes. 2.6.4. Migration Flow The hot-docking migration follows this sequence: +------------------+ +-------------------+ | Compromised Host | | Backup Host | | (Old A) | | (New B) | +------------------+ +-------------------+ | | | 1. Serialize AAI State (CBOR + zlib) | | (eid, iat, session_state, ese_state) | | | | 2. Encrypt with AES-GCM-256 | | K_migration = HKDF-SHA256(ECDH(...)) | | | | 3. Send Migration Stream | |------------------------------------------>| | | | | 4. Decrypt & | | Restore State | | (AAI Context | 5. Generate Forwarding Ticket | on New Host) | (KEY = SHA-256(EID), New Locator) | | | | 6. Store in DHT & Invalidate Old Mapping | | (after T_invalidate = 5 min) | | | v v +------------------+ +-------------------+ | Old Host | | New Host | | Invalidated | | Active | +------------------+ +-------------------+ Gebauer Expires 29 January 2027 [Page 36] Internet-Draft IACP - DHT July 2026 2.6.5. EID Revocation and Propagation When an EID is compromised or when a curator key is revoked, the affected node MUST execute a revocation procedure to invalidate the compromised identity and propagate the revocation to the DHT overlay. 2.6.5.1. Revocation Trigger Conditions An EID revocation is triggered under the following conditions: 1. Cryptographic Compromise: The private key associated with the EID is known or suspected to be compromised. This is determined by the node operator. 2. Curator Decapitation: A curator node is flagged by a validated PoM ticket and undergoes quarantine. 3. Administrative Revocation: An explicit administrative directive is issued by the managing user or parent orchestration system. 4. Reputation Threshold: The EID's reputation score falls below R_state < 0.3 for T_reputation = 7 consecutive days. 2.6.5.2. Revocation Certificate Upon triggering a revocation, the node generates a Revocation Certificate. The certificate MUST include the following fields: Revocation_Certificate = { EID_Revoked: The EID being revoked (32 bytes), EID_New: The new EID replacing the revoked one (32 bytes), Timestamp: UNIX timestamp of revocation (8 bytes), Reason: Revocation reason code (4 bytes), Sequence_Number: Monotonically increasing sequence (8 bytes), Signature: Sign_Ed25519(Private_Key_Old, EID_Revoked || EID_New || Timestamp || Reason || Sequence_Number) } Revocation Reason Codes: | Code | Name | Description | |------|----------------------|---------------------------------------| | 0x01 | KEY_COMPROMISE | Private key exfiltrated or suspected | | 0x02 | CURATOR_DECAPITATION | Curator node flagged by PoM | | 0x03 | ADMINISTRATIVE | Administrative override | | 0x04 | REPUTATION_FAILURE | Reputation score below threshold | | 0x05 | OPERATIONAL_ROTATION | Scheduled rotation (Section 3.4) | | 0x06 | KEY_LEAK_DETECTED | Key leak detected by external means | Gebauer Expires 29 January 2027 [Page 37] Internet-Draft IACP - DHT July 2026 The Signature MUST be verifiable against the EID_Revoked public key. This proves that the revocation request originates from the legitimate owner of the EID (or the holder of the private key at the time of revocation). 2.6.5.3. Revocation Submission The Revocation Certificate is submitted to the Global Directory Quorum for the key SHA-256(EID_Revoked): 1. The node sends a REVOCATION_SUBMIT message to all 7 quorum nodes. 2. Each quorum node validates the certificate: * Verify the Signature against EID_Revoked. * Verify that Timestamp is within T_fresh = 5 minutes of current time. * Verify that Sequence_Number is greater than the last known sequence for this EID. * Verify that EID_New is a valid Ed25519 public key (not zero, not already revoked). * Verify that the EID_Revoked is not already in STATE_SLASHED. 3. If all checks pass, the quorum node responds with REVOCATION_ACCEPT. Otherwise, REVOCATION_REJECT. 4. Consensus is reached when at least m = 4 out of 7 nodes have sent REVOCATION_ACCEPT. 5. Upon consensus, each quorum node: * Marks EID_Revoked as REVOKED in its local ledger. * Records the mapping EID_Revoked -> EID_New for forwarding. * Propagates the revocation to the DHT overlay. 2.6.5.4. Revocation Propagation Once the revocation is committed by the quorum, it is propagated through the DHT overlay: 1. Quorum nodes store the Revocation Certificate in the DHT under: KEY = SHA-256("revocation:" || EID_Revoked) Gebauer Expires 29 January 2027 [Page 38] Internet-Draft IACP - DHT July 2026 2. The certificate is replicated with redundancy factor r = 7 and has a TTL of T_revoke_ttl = 30 days. After T_revoke_ttl, the revocation record expires and the EID MAY be reused (subject to new key generation). 3. Nodes that encounter a stale revocation record (older than T_revoke_ttl) MUST discard it and mark the EID as available for reuse. 4. The EID_Revoked is added to a decentralized revocation bloom filter for rapid lookup. The bloom filter is propagated to all DHT nodes every T_bloom = 1 hour. 5. All active PSS sessions involving EID_Revoked: a. MUST be terminated by both peers. b. SHOULD be re-established using EID_New, subject to re-authentication. 2.6.5.5. Revocation Checking Before accepting any PSS_INIT or processing any packet, a node MUST check whether the target EID is revoked: 1. The node queries the local cache for the revocation status of the target EID. The cache contains: a. Revoked EIDs (from quorum commits) b. TTL for each entry (T_revoke_ttl = 30 days from revocation) 2. If the target EID is in the cache: a. The node MUST reject the PSS_INIT. b. The node MUST respond with PSS_REJECT (Reason: EID_REVOKED). c. The node SHOULD suggest EID_New if available. 3. If the target EID is not in the cache, the node performs a DHT lookup under KEY = SHA-256("revocation:" || EID_Revoked). 4. If a revocation record exists: a. The node MUST add the EID to its local cache. b. The node MUST reject the PSS_INIT. c. The node SHOULD cache EID_New for future forwarding. 5. If no revocation record exists, the node assumes the EID is valid. 2.6.5.6. Revocation Forwarding To ensure continued communication during EID rotation, the revoked EID MAY forward packets to the new EID: 1. The DHT stores a forwarding mapping for T_forward = 7 days: KEY = SHA-256("forward:" || EID_Revoked) -> EID_New Gebauer Expires 29 January 2027 [Page 39] Internet-Draft IACP - DHT July 2026 2. Nodes receiving a packet destined for EID_Revoked during T_forward: * Check the forwarding mapping. * If found, forward the packet to EID_New. * Include a FORWARDED header to indicate the redirection. 3. After T_forward, the forwarding mapping expires and packets to EID_Revoked are dropped. 2.6.5.7. Revocation Recovery (Accidental Revocation) If a revocation was issued in error, the node MAY submit a Revocation Reversal Certificate: Revocation_Reversal = { EID_Revoked: The EID that was revoked (32 bytes), EID_New: The EID that was intended to replace it (32 bytes), Timestamp: UNIX timestamp of reversal (8 bytes), Reason: Reversal reason code (4 bytes), Signature: Sign_Ed25519(Private_Key_New, EID_Revoked || EID_New || Timestamp || Reason) } The Reversal MUST be submitted to the quorum within T_reversal = 1 hour of the original revocation. If accepted by consensus, the quorum reverses the revocation and removes EID_Revoked from the revocation bloom filter. 2.7. Layer-Separated Economic Governance and Edge Gatekeeper Model The IACP employs a strict separation between transport-layer forwarding and application-layer/authorization logic. 2.7.1. Layer 4 Kernel-Space Fast-Path The IACP architecture defines a logical L4 fast-path responsible for low-latency, high-throughput processing of incoming packets before they are handed to the application layer. This fast-path operates at the kernel or dataplane layer and is decoupled from the L7 application-space logic. Its responsibilities are: * Basic header validation and rate limiting. * Sequence vector and replay protection checks. Gebauer Expires 29 January 2027 [Page 40] Internet-Draft IACP - DHT July 2026 * Forwarding of opaque authorization envelopes to the L7 gateway. * Immediate session teardown upon receiving a signal from the L7 layer. The L4 fast-path MUST remain agnostic to the semantics of authorization tokens; it performs only structural validation (e.g., verifying header format, checking sequence numbers) and forwards the opaque payload without interpretation. The specification uses eBPF as the reference implementation mechanism for the L4 fast-path, but this is not a requirement. The L4 fast- path is defined as an abstract functional component, not as a specific implementation technology. Conforming IACP implementations MAY implement the L4 fast-path using other mechanisms, including: * XDP (eXpress Data Path) for high-performance packet processing (similar to eBPF). * DPDK (Data Plane Development Kit) for userspace packet processing. * A pure userspace implementation using standard sockets (for resource-constrained or development environments). * Hardware offloading on network interface cards (if supported). * Platform-specific kernel modules (e.g., Windows Filtering Platform, Apple Network Extension). Regardless of the implementation mechanism, the L4 fast-path MUST provide the following functional guarantees: * The fast-path MUST be capable of processing packets at line rate (or as close to it as the underlying hardware permits). * The fast-path MUST NOT allocate significant memory or state for packets that fail basic validation. * The fast-path MUST forward opaque authorization envelopes to the L7 gateway without modification. * The fast-path MUST accept and act on teardown signals from the L7 gateway. Implementations using eBPF or XDP SHOULD follow the best practices for packet processing defined in the Linux kernel documentation. Implementations using other mechanisms SHOULD provide equivalent performance and security properties. Gebauer Expires 29 January 2027 [Page 41] Internet-Draft IACP - DHT July 2026 2.7.2. Layer 7 Application-Space Door-Keeper (Opaque Authorization Envelope) EMILIA Receipt Handling and Verification The Opaque Authorization Envelope (Section 5.7.2) carries EMILIA receipts as opaque byte arrays. The IACP protocol itself does not interpret, canonicalize, or verify the contents of the envelope. An IACP implementation that wishes to verify a carried EMILIA receipt SHOULD call the EMILIA reference verifier on the envelope bytes and the sender's pinned public key. The verifier performs the JCS canonicalization [RFC8785] and signature verification internally. The canonicalization profile is defined in [I-D.schrock-ep-authorization-receipts], where the action hash is the SHA-256 of the JCS-canonical action. The EMILIA reference verifier is available in the following implementations: * npm: @emilia-protocol/verify * PyPI: emilia-verify * Go: github.com/emiliaprotocol/emilia-protocol/packages/go-verify Implementations that choose to perform canonicalization on the IACP side MUST use the conformance vectors provided in the EMILIA repository (canonicalization.v1.json) to ensure byte-for-byte compatibility, as any canonicalization difference between two implementations constitutes a signature-forgery surface. 2.7.3. Asynchronous Verification and Teardown Full validation of authorization logic (EMILIA signature verification, WRT budget check, etc.) occurs asynchronously in application space. However, the L7 fast-path pre-validation does not constitute a durable authorization grant, it is solely a structural check of the opaque authorization envelope's format, nonce, and signature shape, with the actual authorization decision deferred to the asynchronous application-space verification. If a violation is detected: - The L7 gateway SHALL immediately issue a targeted teardown signal to the L4 layer. - The L4 layer MUST terminate the affected PSS and associated ESEs. - The offending EID SHALL be placed on a temporary deny-list (ranging 5–60 minutes, configurable per namespace). - Permanent EID revocation MUST only occur after a validated Proof of Malfeasance (PoM) by DHT curators. Gebauer Expires 29 January 2027 [Page 42] Internet-Draft IACP - DHT July 2026 For security reasons, authorization failures SHOULD use silent teardown (no specific error code exposed to the sender). The diagram below serves as illustration of this part: +-------------------------------------------------------+ | L4 Fast-Path (eBPF) | | - Header & Rate Limit Validation | | - Sequence Vector Replay Checks | +-------------------------------------------------------+ | v [Forwarding Opaque Envelope] +-------------------------------------------------------+ | L7 Application Gateway | | - Opaque Authorization Envelope Processing | | - Fast-Path Pre-Validation (Signature, Nonce, Format) | +-------------------------------------------------------+ | | v (Pass: Allocation Granted) v (Fail) +-----------------------+ +-----------------------+ | DHI Execution Context | | Silent Session Drop | | & Active PSS / ESEs | | & Threat Signal | +-----------------------+ +-----------------------+ | | v (Asynchronous Full Validation) | +-----------------------+ | | App-Space Verification| | | (EMILIA / WRT Check) | | +-----------------------+ | | | v (If Violation Detected) v +-------------------------------------------------------+ | Targeted L4 Teardown Vector Signal | | - Terminate Affected PSS & Associated ESEs | | - Temporary EID Deny-List Placement (5-60 min) | +-------------------------------------------------------+ 3. References 3.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, . Gebauer Expires 29 January 2027 [Page 43] Internet-Draft IACP - DHT July 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, "Network Time Security for the Network Time Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . 3.2. Informative References [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. [I-D.schrock-ep-authorization-receipts] Schrock, I., "EMILIA Protocol Specification", Work in Progress, Internet-Draft, draft-schrock-ep-authorization- receipts, 2026, . Author's Address Gebauer Expires 29 January 2027 [Page 44] Internet-Draft IACP - DHT July 2026 Leonard Gebauer Independent Germany Email: leonard.gebauer.ha@gmail.com Gebauer Expires 29 January 2027 [Page 45]