{"version":"2.1.223","anchor":"peer-messages-carry-a-hop-chain-with-loop-and-runaway-relay-","canonical_anchor":"peer-messages-carry-a-hop-chain-with-loop-and-runaway-relay-","heading":"Peer messages carry a hop chain, with loop and runaway-relay rejection","tier":"notice","area":"Peer Messaging","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.223\/e\/peer-messages-carry-a-hop-chain-with-loop-and-runaway-relay-","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.223","markdown":"### Peer messages carry a hop chain, with loop and runaway-relay rejection\n\nMessages passed between agents now track their relay path and get refused if they loop or bounce too far.\n\n**What**\n\nMessages relayed between agents now carry a `hopChain` of truncated HMAC-SHA256 session fingerprints, and admission control refuses chains that have grown too long or that have looped back through this session.\n\n**Details**\n\n- the chain is threaded through the rendered peer-message block, the message origin record and the admission control path, over both UDS and bridge transports\n- a chain longer than `maxChainLength` (default 28) is refused as `hop-runaway`, runaway forwarding\n- a message already carrying this session's own tokens `maxSelfHops` (default 10) times is refused as `hop-loop`\n- both limits are settings-validated with min\/max clamps, and rejections are reported with the sender identity, on top of the existing rate-limit and duplicate checks\n\n**Evidence**\n\n`hop-runaway`, `peer relay chain is too long (runaway forwarding)`\n\n- Area: Peer Messaging\n- Names: `maxChainLength`, `maxSelfHops`\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 0\/5"}