Internet-Draft AI/Agent WG Intended status: standards-track March 2026 Expires: September 08, 2026 Multi-Agent Consensus Protocol (MACP) for Distributed AI Agent Coordination draft-ai-consensus-protocol-00 Abstract This document defines the Multi-Agent Consensus Protocol (MACP), a standardized framework for enabling multiple AI agents to reach consensus on shared decisions and resolve conflicting objectives in distributed environments. MACP addresses critical coordination challenges in autonomous systems where agents must collaborate on resource allocation, policy enforcement, and decision-making across organizational and domain boundaries. The protocol incorporates Byzantine fault tolerance mechanisms, cryptographic verification, and hierarchical consensus structures to ensure reliable agreement even in the presence of malicious or malfunctioning agents. MACP defines message formats, consensus algorithms, conflict resolution procedures, and integration patterns with existing agent-to-agent communication protocols. The protocol supports various consensus models including proof-of- authority, weighted voting, and reputation-based systems, enabling deployment across diverse use cases from IoT device coordination to enterprise AI system orchestration. This specification aims to reduce fragmentation in multi-agent systems and provide a foundation for interoperable autonomous agent coordination at scale. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document is intended to have standards-track status. Distribution of this memo is unlimited. Table of Contents 1. Introduction ................................................ 3 2. Terminology ................................................. 4 3. Problem Statement ........................................... 5 4. MACP Architecture and Core Components ....................... 6 5. Consensus Algorithms and Message Formats .................... 7 6. Conflict Resolution and Decision Binding .................... 8 7. Integration with Existing Agent Protocols ................... 9 8. Security Considerations ..................................... 10 9. IANA Considerations ......................................... 11 1. Introduction The proliferation of autonomous AI agents across distributed computing environments has created an urgent need for standardized consensus mechanisms that enable coordinated decision-making without centralized control. As organizations deploy increasing numbers of intelligent agents for tasks ranging from resource allocation and policy enforcement to complex multi-party negotiations, the lack of interoperable consensus protocols has resulted in fragmented implementations that cannot effectively coordinate across organizational and domain boundaries. Current agent-to-agent communication protocols, while addressing basic message exchange and authentication, provide insufficient mechanisms for achieving reliable agreement among multiple agents with potentially conflicting objectives or incomplete information. Existing consensus approaches in multi-agent systems typically rely on proprietary coordination mechanisms or adapt consensus algorithms designed for blockchain and distributed database applications without addressing the unique requirements of AI agent coordination. These limitations become particularly acute in scenarios involving Byzantine fault tolerance, where agents may exhibit malicious behavior, experience partial failures, or operate under adversarial conditions. The heterogeneous nature of AI agent implementations, combined with varying trust relationships and organizational policies, further complicates the development of effective consensus mechanisms that can operate reliably at scale. The Multi-Agent Consensus Protocol (MACP) addresses these challenges by providing a standardized framework specifically designed for AI agent coordination that incorporates proven consensus algorithms while addressing the unique requirements of autonomous agent systems. MACP supports multiple consensus models including proof-of-authority, weighted voting based on agent reputation or capabilities, and hierarchical consensus structures that reflect organizational boundaries and trust relationships. The protocol integrates cryptographic verification mechanisms and Byzantine fault tolerance to ensure reliable consensus achievement even in the presence of malicious or malfunctioning agents, while maintaining compatibility with existing agent communication and attestation frameworks. The scope of MACP encompasses the definition of consensus algorithms optimized for AI agent coordination, standardized message formats for proposal submission and voting processes, conflict resolution mechanisms for handling competing objectives, and integration patterns with existing agent-to-agent protocols. This specification aims to reduce the current fragmentation in multi-agent coordination approaches by providing a foundation for interoperable consensus mechanisms that can scale from small IoT device clusters to enterprise-wide AI system orchestration. By establishing common protocols for multi-agent consensus, MACP enables the development of more robust and coordinated autonomous systems while maintaining the flexibility required for diverse deployment scenarios and organizational requirements. 2. Terminology 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. This section establishes terminology specific to multi-agent consensus operations and distributed AI agent coordination. These definitions build upon established concepts from distributed systems literature while introducing terminology specific to autonomous agent environments. Where applicable, references are made to related terminology from existing agent communication protocols such as those defined in [RFC8600] and distributed consensus literature. A "consensus agent" is an autonomous AI entity capable of participating in distributed decision-making processes by submitting proposals, evaluating options, and committing to agreed-upon outcomes. Consensus agents MUST maintain state consistency with other participants and possess cryptographic capabilities for message authentication and verification. An "observer agent" is a non-participating entity that monitors consensus processes without voting rights or decision authority. A "coordination domain" defines the scope and boundaries within which a group of agents operate under shared governance rules and consensus mechanisms. Each coordination domain establishes its own policies for membership, voting weights, and decision authority. A "decision quorum" represents the minimum number or weight threshold of participating agents required to reach a valid consensus decision within a coordination domain, expressed either as an absolute count or percentage of eligible participants. "Byzantine Fault Tolerance" (BFT) refers to the system's ability to achieve consensus despite the presence of agents that may exhibit arbitrary failures, including malicious behavior, message corruption, or incorrect state reporting. MACP implementations SHOULD support Byzantine fault tolerance for up to one-third of participating agents within any coordination domain. "Practical Byzantine Fault Tolerance" (pBFT) describes optimized algorithms that achieve Byzantine fault tolerance with reduced message complexity and improved performance characteristics. "Conflict resolution" encompasses the mechanisms and procedures used to address competing proposals, resolve deadlocks, and handle situations where multiple valid decisions could be reached. This includes tie-breaking algorithms, priority-based selection, and escalation procedures to higher-level coordination domains. "Decision binding" refers to the enforcement mechanisms that ensure participating agents comply with consensus outcomes and maintain consistency with agreed-upon decisions across the coordination domain. 3. Problem Statement The proliferation of autonomous AI agents across distributed systems has created an urgent need for standardized consensus mechanisms that can coordinate decision-making without centralized control. Current multi-agent deployments frequently encounter scenarios where agents must collectively agree on resource allocation, policy enforcement, task scheduling, or strategic decisions that affect multiple stakeholders. However, existing agent-to-agent communication protocols such as FIPA-ACL and emerging frameworks focus primarily on message exchange and basic coordination primitives, lacking robust consensus mechanisms necessary for reliable distributed decision-making. This gap becomes particularly problematic in cross-organizational deployments where agents operate under different governance models, trust assumptions, and operational constraints. Network partitions and communication failures present fundamental challenges to consensus achievement in distributed agent environments. Unlike traditional distributed systems where nodes typically operate within controlled network environments, AI agents often function across heterogeneous networks with varying reliability characteristics, from edge computing environments to cloud infrastructure spanning multiple providers. Agents may become temporarily or permanently unreachable, creating scenarios where consensus decisions must proceed with incomplete information or be safely aborted to prevent system-wide inconsistencies. Current agent protocols provide insufficient guidance for handling these partition scenarios, often resulting in ad-hoc implementations that cannot guarantee safety properties or liveness guarantees across different deployment contexts. Conflicting objectives among participating agents introduce additional complexity beyond traditional distributed consensus problems. AI agents frequently operate with competing utility functions, resource constraints, and optimization targets that may not align with collective decision requirements. For example, in a multi-cloud resource allocation scenario, individual agents may prioritize cost minimization for their respective organizations while the collective decision requires balancing performance, security, and availability across all participants. Existing consensus algorithms assume participants share common objectives or can reduce decisions to simple binary choices, failing to address the multi-dimensional optimization problems inherent in AI agent coordination. The presence of malicious or Byzantine actors poses significant threats to consensus integrity in open multi-agent environments. Unlike closed distributed systems where all participants operate under unified security models, AI agents may need to establish consensus across organizational boundaries where some participants cannot be fully trusted. Malicious agents may attempt to manipulate consensus outcomes through strategic voting, false information injection, or coordination attacks designed to prevent legitimate consensus achievement. Furthermore, compromised or malfunctioning agents may exhibit Byzantine behavior without malicious intent, requiring consensus mechanisms that can tolerate arbitrary failures while maintaining decision quality and system progress. Current limitations in existing agent-to-agent protocols create additional barriers to reliable consensus implementation. Most protocols focus on peer-to-peer communication abstractions without addressing the coordination complexity required for multi-party decision-making. Authentication and authorization mechanisms are typically designed for bilateral interactions rather than group consensus scenarios, lacking support for quorum-based verification or reputation systems that could improve consensus security. Additionally, existing protocols provide limited support for hierarchical consensus structures or delegation mechanisms that could enable scalable decision-making in large agent populations, forcing implementations toward flat consensus models that may not perform well beyond small agent groups. 4. MACP Architecture and Core Components The MACP architecture employs a distributed coordination model consisting of three primary components: Consensus Coordinators, Participating Agents, and Decision Domains. This architecture is designed to scale horizontally while maintaining fault tolerance and ensuring efficient consensus across diverse agent populations. The system operates on the principle of domain-partitioned consensus, where agents are organized into logical groupings based on their functional roles, trust relationships, or organizational boundaries. Each Decision Domain maintains its own consensus state and can interact with other domains through well-defined inter- domain protocols. Consensus Coordinators serve as the orchestration layer for MACP operations within each Decision Domain. A Consensus Coordinator MUST be capable of maintaining the current consensus state, managing proposal queues, and coordinating message distribution among Participating Agents. Coordinators are responsible for implementing the selected consensus algorithm, enforcing quorum requirements, and ensuring message ordering consistency. In deployments requiring high availability, multiple Consensus Coordinators MAY operate in a redundant configuration using leader election mechanisms similar to those defined in Raft consensus algorithms. Coordinators MUST implement Byzantine fault tolerance measures when operating in environments where malicious behavior is possible, maintaining consensus integrity even when up to one- third of coordinators exhibit arbitrary failures. Participating Agents represent the autonomous entities that contribute to consensus decisions within the MACP framework. Each Participating Agent MUST maintain a unique identity within its Decision Domain and possess the capability to generate, evaluate, and vote on consensus proposals. Agents are classified into one of three participation modes: Active Participants that can both propose and vote on decisions, Voting Participants that can vote but not propose, and Observer Participants that receive consensus results but do not participate in the decision process. Participating Agents MUST implement proposal validation logic appropriate to their domain context and SHOULD incorporate reputation tracking mechanisms to assess the trustworthiness of proposals from other agents. Decision Domains establish the scope and context for consensus operations, defining the set of agents authorized to participate in specific types of decisions. A Decision Domain MUST specify its consensus model (proof-of-authority, weighted voting, or reputation-based), quorum requirements, and decision binding policies. Domains operate independently but MAY establish inter- domain communication channels for coordinating decisions that span multiple domains. The domain configuration MUST include conflict resolution parameters, timeout specifications, and rollback procedures to handle consensus failures gracefully. The interaction patterns between these components follow a structured request-response model augmented with publish-subscribe mechanisms for state synchronization. When a Participating Agent initiates a consensus proposal, it MUST first submit the proposal to its designated Consensus Coordinator, which validates the proposal format and participant authorization. The Coordinator then distributes the proposal to all eligible Participating Agents within the Decision Domain, collecting votes according to the configured consensus algorithm. Upon reaching quorum and achieving consensus, the Coordinator publishes the binding decision to all participants and updates the domain's consensus state. Failed consensus attempts trigger the domain's configured rollback procedures, allowing the system to maintain consistency despite partial failures or network partitions. 5. Consensus Algorithms and Message Formats MACP implements multiple consensus algorithms to accommodate different operational requirements and network conditions. The base specification MUST support the Practical Byzantine Fault Tolerance (pBFT) algorithm adapted for multi-agent environments, while implementations MAY support additional algorithms including RAFT consensus for non-Byzantine scenarios and novel reputation- weighted consensus for environments with established agent trust relationships. The pBFT implementation assumes a maximum of f Byzantine agents out of 3f+1 total participating agents, providing safety and liveness guarantees under standard network assumptions. Each consensus algorithm is identified by a unique Algorithm Identifier (AID) registered with IANA as specified in Section 9. The MACP consensus process follows a four-phase protocol: Proposal, Pre-voting, Voting, and Commitment. During the Proposal phase, any authorized agent MAY submit decision proposals to the designated consensus coordinator for the relevant coordination domain. The Pre-voting phase allows agents to signal their preliminary position and identify potential conflicts or dependencies with other pending proposals. The Voting phase requires participating agents to submit cryptographically signed votes within a specified timeout window, with vote validity determined by the agent's authorization level and current reputation score. The Commitment phase broadcasts the final decision and requires acknowledgment from a quorum of agents before considering the consensus binding. MACP defines standardized message formats using JSON serialization with mandatory digital signatures following RFC 7515 (JSON Web Signature). All consensus messages MUST include a common header containing the message type, consensus session identifier, timestamp, originating agent identifier, and cryptographic signature. Proposal messages additionally contain the proposed decision payload, expected quorum size, voting timeout duration, and conflict resolution parameters. Vote messages include the proposal hash, agent's decision (ACCEPT, REJECT, ABSTAIN), voting weight, and optional reasoning metadata. Commitment messages broadcast the final consensus result, participating agent list, vote tally, and binding duration for the agreed decision. Message validation requires verification of agent authorization, signature authenticity, and temporal constraints before processing. Agents MUST reject messages with invalid signatures, expired timestamps beyond the configured clock skew tolerance, or originating from agents not authorized for the specific coordination domain. Vote aggregation follows the specified consensus algorithm with additional validation for vote weight consistency and duplicate vote detection. The consensus coordinator MUST broadcast commitment messages to all participating agents and maintain an audit log of the complete consensus session for accountability purposes as defined in existing agent attestation frameworks. Timeout handling and failure recovery mechanisms ensure liveness properties under adverse network conditions. If insufficient votes are received within the voting timeout window, the consensus coordinator MUST initiate a new consensus round with an exponentially increasing timeout duration, up to a maximum threshold defined in the coordination domain configuration. Network partition scenarios are addressed through coordinator election protocols that prevent split-brain consensus decisions. Failed consensus attempts trigger rollback procedures that notify all participating agents of the unsuccessful coordination attempt and release any provisionally allocated resources pending the consensus outcome. 6. Conflict Resolution and Decision Binding Conflict resolution in MACP occurs when multiple competing proposals are submitted simultaneously or when agents disagree on the validity or priority of proposed decisions. When conflicts are detected during the proposal phase, participating agents MUST invoke the conflict resolution mechanism before proceeding with the voting phase. The protocol defines three primary conflict types: proposal conflicts (multiple proposals for the same decision domain), timing conflicts (simultaneous submissions within the conflict detection window), and validity conflicts (disagreement on proposal prerequisites or constraints). Agents MUST maintain a conflict detection buffer with a configurable timeout period (default 30 seconds) to identify competing proposals before initiating consensus procedures. The tie-breaking procedure activates when voting results in equivalent support for multiple proposals or when no proposal achieves the required quorum threshold. MACP employs a hierarchical tie-breaking mechanism starting with proposal priority levels, followed by submitter reputation scores, and finally deterministic hash-based selection using the combined hash of conflicting proposal identifiers. Participating agents MUST apply tie-breaking rules in the specified order and MUST reach agreement on tie-breaking criteria during the initial coordination domain establishment. When tie-breaking fails to resolve conflicts, the consensus coordinator MUST initiate a cooling-off period of at least 60 seconds before allowing resubmission of conflicting proposals. Decision binding ensures that consensus outcomes are enforced across all participating agents through cryptographic commitment and distributed verification mechanisms. Once consensus is achieved, all participating agents MUST generate binding commitment messages containing the decision hash, their digital signature, and a commitment timestamp. The binding phase requires acknowledgment from at least the same quorum that approved the original proposal within a configurable binding timeout (default 120 seconds). Agents MUST store binding commitments in their local decision ledger and MUST reject future proposals that violate committed decisions unless explicitly superseded through the decision override mechanism. Timeout handling addresses scenarios where consensus cannot be achieved within specified time bounds or when participating agents become unresponsive during critical phases. MACP defines distinct timeout periods for each consensus phase: proposal timeout (default 60 seconds), voting timeout (default 180 seconds), and binding timeout (default 120 seconds). When timeouts occur, the consensus coordinator MUST broadcast a timeout notification and initiate graceful degradation procedures, which may include reducing quorum requirements, extending timeout periods, or aborting the consensus attempt. Agents that fail to respond within timeout periods MUST be temporarily excluded from the current consensus round but MAY rejoin subsequent rounds. Rollback mechanisms provide recovery capabilities when consensus failures occur after the voting phase or when binding commitments cannot be properly established. Rollback procedures MUST be initiated when binding acknowledgments fall below the required threshold, when Byzantine fault detection identifies compromised consensus results, or when critical participating agents report implementation failures. The rollback process requires the consensus coordinator to broadcast rollback notifications containing the failed consensus identifier, rollback reason code, and reversion instructions. All participating agents MUST acknowledge rollback notifications, remove associated decision commitments from their local ledgers, and reset their consensus state to allow for subsequent retry attempts with modified parameters or participant sets. 7. Integration with Existing Agent Protocols MACP is designed to operate as an overlay protocol that integrates seamlessly with existing agent-to-agent communication frameworks and infrastructure. Implementations MUST support integration with standard authentication protocols including OAuth 2.0 [RFC6749], OpenID Connect, and X.509 certificate-based authentication systems commonly deployed in enterprise environments. MACP consensus messages SHOULD leverage existing secure transport mechanisms such as TLS 1.3 [RFC8446] or DTLS for UDP-based communications, ensuring that consensus operations benefit from established security practices without requiring separate cryptographic implementations. Integration with agent accountability frameworks requires MACP implementations to maintain comprehensive audit trails of consensus participation and decision outcomes. Consensus coordinators MUST log all proposal submissions, voting records, and final decisions in formats compatible with existing audit and compliance systems. When operating alongside agent attestation protocols, MACP SHOULD verify agent identity and authorization status before allowing participation in consensus processes, utilizing existing identity providers and policy enforcement points where available. The protocol defines standard interfaces for querying agent reputation scores and authorization levels from external accountability systems. MACP consensus operations MUST be designed to coexist with workflow management and orchestration platforms commonly used in distributed AI deployments. Implementations SHOULD provide APIs and event notifications that allow workflow systems to trigger consensus processes when collective decisions are required, and to receive binding consensus outcomes for subsequent workflow execution. The protocol supports asynchronous integration patterns where consensus results can be delivered to workflow systems through message queues, webhooks, or polling interfaces, ensuring compatibility with diverse orchestration architectures. For environments utilizing existing agent-to-agent communication protocols such as FIPA-ACL or custom REST-based agent APIs, MACP provides adapter interfaces that translate consensus-specific messages into native communication formats. Protocol implementations MAY offer plugin architectures that allow custom integration modules for proprietary agent communication systems, while maintaining core consensus algorithm integrity. Standard message mapping templates are provided for common integration scenarios, reducing implementation complexity for organizations with established agent communication infrastructure. The protocol includes provisions for gradual deployment in mixed environments where only a subset of agents support MACP consensus mechanisms. Non-MACP agents MAY participate in consensus processes through proxy agents that translate between native agent protocols and MACP message formats, though such deployments SHOULD implement additional verification mechanisms to ensure proxy agent fidelity. Integration guidelines specify fallback procedures for scenarios where consensus mechanisms are unavailable, allowing graceful degradation to existing coordination approaches while maintaining system stability. 8. Security Considerations Security considerations for MACP deployment are paramount given the distributed nature of multi-agent systems and the potential for malicious actors to compromise consensus integrity. The protocol MUST implement comprehensive threat mitigation strategies to address attacks specific to distributed consensus mechanisms. Primary security concerns include Sybil attacks where malicious actors create multiple false agent identities to gain disproportionate voting power, coordination attacks where compromised agents collude to manipulate consensus outcomes, and consensus manipulation through message tampering or replay attacks. Additionally, MACP implementations MUST consider denial- of-service attacks targeting consensus coordinators, eclipse attacks isolating honest agents from the consensus network, and long-range attacks where compromised agents attempt to rewrite historical consensus decisions. Cryptographic requirements for MACP implementations MUST include strong identity verification mechanisms to prevent unauthorized participation in consensus processes. Each participating agent MUST possess a cryptographically verifiable identity backed by public-key infrastructure or distributed identity systems such as those defined in [RFC6960] and emerging decentralized identity standards. Digital signatures MUST be used for all consensus messages including proposals, votes, and commitments, with signature schemes providing at least 128-bit security strength as specified in [RFC3766]. Message integrity MUST be protected through cryptographic hash functions resistant to collision attacks, and implementations SHOULD employ hash-based message authentication codes (HMAC) for additional verification. Time- based replay attack prevention MUST be implemented through message timestamps and nonce mechanisms, with strict validation of message freshness windows. Identity verification mechanisms MUST prevent Sybil attacks through robust agent authentication and reputation tracking systems. MACP implementations SHOULD integrate with existing Public Key Infrastructure (PKI) systems or emerging decentralized identity frameworks to establish verifiable agent identities. Consensus coordinators MUST maintain authoritative lists of eligible participating agents and regularly validate agent credentials against trusted identity providers. Multi-factor authentication SHOULD be employed for high-stakes consensus decisions, potentially including hardware security module (HSM) attestation or trusted execution environment verification. Agent reputation systems MAY be implemented to track historical behavior and adjust voting weights based on demonstrated trustworthiness, though such systems MUST include mechanisms to prevent reputation manipulation attacks. Protection mechanisms for consensus integrity MUST address both technical and game-theoretic attack vectors inherent in distributed decision-making systems. Byzantine Fault Tolerant consensus algorithms MUST be configured to handle the maximum expected number of malicious agents according to theoretical bounds, typically supporting up to f faulty agents in a network of 3f+1 total agents. Network-level protections SHOULD include encrypted communication channels using protocols such as TLS 1.3 [RFC8446] and distributed denial-of-service (DDoS) mitigation strategies to ensure consensus availability. Implementations MUST implement consensus finality mechanisms that prevent retroactive modification of agreed-upon decisions and provide cryptographic proofs of consensus achievement. Regular security audits and penetration testing SHOULD be conducted on MACP implementations, with particular attention to consensus algorithm correctness and cryptographic implementation vulnerabilities. Economic and incentive-based security measures SHOULD be considered to discourage malicious behavior and ensure honest participation in consensus processes. Stake-based consensus mechanisms MAY be implemented where agents must commit resources or reputation to participate in decision-making, creating economic disincentives for malicious behavior. Slashing mechanisms SHOULD be employed to penalize agents that violate consensus rules or demonstrate Byzantine behavior. However, such economic measures MUST be carefully designed to prevent wealth concentration attacks and ensure broad participation accessibility. Monitoring and anomaly detection systems SHOULD continuously analyze consensus patterns to identify potential coordinated attacks or unusual voting behaviors that may indicate compromise. Emergency response procedures MUST be established to handle detected security incidents, including mechanisms for temporarily suspending consensus participation of suspected malicious agents and initiating incident response protocols. 9. IANA Considerations This document requests IANA to create and maintain several new registries to support the Multi-Agent Consensus Protocol (MACP) and ensure protocol extensibility and interoperability. The registries defined in this section will enable standardized identification of protocol elements while allowing for future enhancements and vendor-specific extensions without creating conflicts or ambiguity in multi-agent consensus implementations. IANA is requested to establish a "Multi-Agent Consensus Protocol (MACP) Parameters" registry group containing three distinct registries. The first registry, "MACP Message Types", SHALL contain identifiers for all MACP message types including consensus proposals, votes, commitments, and administrative messages. Message type identifiers MUST be allocated as 16-bit unsigned integers in the range 0x0000-0xFFFF, with values 0x0000-0x7FFF reserved for IETF-defined message types and values 0x8000-0xFFFF available for private use and experimental implementations. Registration of new message types in the IETF range requires Standards Action as defined in RFC 8126, and MUST include a complete message format specification and security considerations. The second registry, "MACP Consensus Algorithm Identifiers", SHALL contain unique identifiers for consensus algorithms supported by MACP implementations. Algorithm identifiers MUST be allocated as UTF-8 strings following the pattern "algorithm-name.version" with a maximum length of 64 characters. The registry MUST include algorithm names, version numbers, reference specifications, security properties, and applicable use case constraints for each entry. Initial registry entries SHALL include "pbft.1.0" for Practical Byzantine Fault Tolerance, "poa.1.0" for Proof of Authority, and "weighted-vote.1.0" for weighted voting consensus. New algorithm registrations require Expert Review with designated experts having demonstrated expertise in distributed consensus mechanisms and multi-agent systems. The third registry, "MACP Conflict Resolution Methods", SHALL contain identifiers for standardized conflict resolution procedures used when multiple competing proposals achieve similar consensus scores. Resolution method identifiers MUST follow the same UTF-8 string format as consensus algorithms and include detailed descriptions of resolution logic, fairness guarantees, and termination conditions. Registration requires Expert Review and MUST demonstrate deterministic behavior across all participating agents. Initial entries SHALL include "timestamp- priority.1.0", "hash-ordering.1.0", and "weighted-random.1.0" with complete algorithmic specifications. IANA is further requested to establish a "MACP Extension Parameters" registry for protocol extension identifiers used in MACP header fields and capability negotiation. Extension identifiers MUST be allocated as reverse DNS notation strings to prevent conflicts and enable vendor-specific extensions while maintaining global uniqueness. The registry SHALL operate under First Come First Served allocation policy as defined in RFC 8126, requiring only basic documentation of the extension purpose and format. All registry entries MUST include contact information for the registering organization and SHOULD reference publicly accessible specification documents for interoperability purposes. Author's Address Generated by IETF Draft Analyzer 2026-03-07