Contract Net Protocol (CNP)

• Contract Net Protocol is a decentralized negotiation framework where a manager issues CFP messages and contractors bid to execute sub-tasks.
• It integrates dynamic belief revision and reputation updates, using scoring heuristics like linear combination of capability and availability to select optimal bids.
• Extensions such as updated-CNP and blockchain integration enhance adaptability and reduce communication overhead in volatile, distributed environments.

The Contract Net Protocol (CNP) is a foundational interaction protocol for decentralized task allocation in multi-agent systems. CNP structures negotiation between a "manager"—which decomposes a complex mission into sub-tasks—and a set of "contractors," which bid for the opportunity to execute these tasks based on their dynamic capabilities and preferences. The protocol relies on explicit messages for task announcement, proposal submission, award/rejection, and contract completion. Originally developed to support cooperative problem solving and resource allocation, CNP has been refined to handle mutable environments, dynamic agent beliefs, and, more recently, distributed enforcement via smart contracts and blockchain. Its application domains include distributed AI planning, smart contract auditing, cyber-physical energy markets, and predator-prey agent simulations (Mallick et al., 4 Feb 2026, Kaur et al., 2013, Saxena et al., 2019).

1. Canonical Structure and Roles

CNP is based on a clear division of labor and message types. The manager (also called "leader" or "initiator" in some variants) issues a Call-for-Proposal (CFP), describing the task to be performed, to all available contractors (bidders) in the system. Upon receiving a CFP, contractors evaluate their local ability to perform the task, possibly considering capability, availability, resource cost, or prior reliability, and respond with a PROPOSE (bid) message containing their offer (e.g., cost, score, completion time). If unwilling or unable, they may respond with a REFUSE. The manager collects proposals until a timeout or sufficient responses, then ranks them via an objective function (e.g., maximal score, minimal cost), and sends an AWARD to the winning contractor and REJECT messages to the others. The awarded contractor executes the task, and upon completion, sends an INFORM-DONE message back to the manager (Mallick et al., 4 Feb 2026, Kaur et al., 2013).

Table: Canonical CNP Message Types and Flow

Message Type	Direction	Purpose
CFP	Manager → Contractors	Announce task (spec, constraints, deadline)
PROPOSE	Contractor → Manager	Submit bid/offer to fulfill the task
REFUSE	Contractor → Manager	Decline to bid (unwilling or incapable)
AWARD	Manager → Contractor	Select and confirm winner of the contract
REJECT	Manager → Contractor	Notify losing bidders
INFORM-DONE	Contractor → Manager	Report task completion and results

The protocol admits multiple instances in parallel, supporting concurrent and distributed resource use. The ASCII-art sequence diagrams in (Kaur et al., 2013) formalize the exact message cycles.

2. Bid Evaluation and Task Allocation Functions

CNP's selection of contractors depends critically on the bid evaluation function employed by the manager. In practice, this function ranges from simple cost minimization to complex heuristics integrating current resource state and historical performance.

SPEAR (Smart Contract Auditing)

In SPEAR, a task auction under CNP assigns each contractor $j$ a linear score:

$$\text{score}_{j} = 0.7 \cdot \text{capability}_{j} + 0.3 \cdot \text{availability}_{j}$$

with both attributes $\in [0, 1]$ as local estimates. The Execution Agent ($A_E$) collects all bids within a fixed timeout and awards the task to the highest-scoring contractor. The remaining proposals are explicitly rejected. Contractor agents submit a PROPOSE message if their score exceeds a personal threshold (Mallick et al., 4 Feb 2026).

Blockchain-Based Transactive Energy Systems

In the voltage regulation application, bids are scored by a manager as:

$\text{score}_R = G_R \times PR^{R}_{\text{BID}}$

where $G_R$ is the on-chain reputation rating of responder $R$ and $PR^{R}_{\text{BID}}$ is the bid price. Reputation is dynamically updated after contract settlement according to observed performance, with successful completion resulting in an increment and failure resulting in a penalty (Saxena et al., 2019).

Updated-CNP

A cost-minimization criterion is standard:

$$\text{winner} = \underset{c}{\operatorname{arg\,min}}\, \text{cost}_c$$

with extensions supporting in-flight specification changes (see below) (Kaur et al., 2013).

3. Dynamic Belief and Reputation Updates

Modern CNP deployments integrate belief revision and reputation mechanisms into both bidding and selection. In SPEAR, every agent manages a belief base $B_i$ over relevant atomic propositions, associating each with a confidence $$\text{score}_{j} = 0.7 \cdot \text{capability}_{j} + 0.3 \cdot \text{availability}_{j}$$0. Upon receiving events such as tool failures, discoveries of vulnerabilities, or contradictory reports, the agent applies AGM-compliant revision, discarding the lowest-confidence beliefs to restore consistency.

• For contractors, declining belief in "tool_available" after failures depresses bid scores and reduces future selection probability.
• For managers, diminished confidence in a contractor's reliability (tracked by $$\text{score}_{j} = 0.7 \cdot \text{capability}_{j} + 0.3 \cdot \text{availability}_{j}$$1) can override high raw bid scores, preventing award.

These belief updates ensure CNP operates as a feedback-driven protocol with immediate coupling to agent experience (Mallick et al., 4 Feb 2026).

In blockchain-based CNP, reputation $$\text{score}_{j} = 0.7 \cdot \text{capability}_{j} + 0.3 \cdot \text{availability}_{j}$$2 is explicitly tracked on-chain, incrementing (or decrementing) with each successful (or failed) contract. All bids are evaluated by multiplying the bid price by reputation, ensuring that agents with better historical performance have an advantage in future auctions. The immutable ledger records bid histories, performance, and rewards, enforcing accountability and automating penalty/reward cycles (Saxena et al., 2019).

4. Protocol Extensions: Handling Dynamic Changes and Communication Overhead

A principal limitation of conventional CNP is rigidity: once a task has been awarded, the manager cannot amend the specification without restarting the protocol from the CFP stage, resulting in wasteful rebidding and increased communication. "Updated-CNP" introduces an additional message type ("task-update") to broadcast changes to the task specification to awarded contractors without causing a full protocol restart.

Let $$\text{score}_{j} = 0.7 \cdot \text{capability}_{j} + 0.3 \cdot \text{availability}_{j}$$3 be a task. When the manager modifies $$\text{score}_{j} = 0.7 \cdot \text{capability}_{j} + 0.3 \cdot \text{availability}_{j}$$4 before completion, it sends a task-update to active contractors, who then adjust their ongoing execution in-place. This lightweight update reduces messages and improves reactivity to environmental volatility:

• In the predator-prey case study: With $$\text{score}_{j} = 0.7 \cdot \text{capability}_{j} + 0.3 \cdot \text{availability}_{j}$$5 contractors and $$\text{score}_{j} = 0.7 \cdot \text{capability}_{j} + 0.3 \cdot \text{availability}_{j}$$6 mid-execution changes, conventional CNP uses 36 messages ($$\text{score}_{j} = 0.7 \cdot \text{capability}_{j} + 0.3 \cdot \text{availability}_{j}$$7 ms at $$\text{score}_{j} = 0.7 \cdot \text{capability}_{j} + 0.3 \cdot \text{availability}_{j}$$8 ms/message); updated-CNP uses 20 messages ($$\text{score}_{j} = 0.7 \cdot \text{capability}_{j} + 0.3 \cdot \text{availability}_{j}$$9 ms), achieving a $\in [0, 1]$0 reduction in message count and latency (Kaur et al., 2013).

Updated-CNP is backward-compatible: contractors incapable of handling updates simply complete existing contracts; those supporting specification mutation immediately reallocate effort. Communication overhead due to update floods is proportional to the frequency and scope of dynamic changes.

5. Applications in Smart Contract Auditing, Energy Markets, and Cyber-Physical Systems

CNP is widely deployed in domains requiring robust, distributed resource negotiation and allocation.

• SPEAR applies CNP to coordinate audit-analysis tool runs (e.g., static analyzers or fuzzers) among specialized agent subtypes. Explicit CFP/BID/AWARD cycles, linear bid scoring, and AGM-style belief revision yield faster failure recovery (2.3±0.8 min) and fewer resource conflicts (1.2±0.6 per audit) compared to direct agent invocation (4.1±1.2 min, 2.8±1.1 conflicts). Coordination overhead for CNP accounts for only 1.5% of audit run time. Use of CNP reduces LLM calls per repair by ~15% (Mallick et al., 4 Feb 2026).
• In transactive energy systems, CNP is implemented as a sequence of smart contract transactions on Hyperledger Fabric. CFPs, bid submissions, assignments, and enforcement are all ledger transactions, with agent incentives and penalties continuously enforced using wallet tokens and on-chain reputation. Auditability and non-repudiation are guaranteed, and reissuance of CFPs ensures resilience to contract execution failures (Saxena et al., 2019).
• Multi-agent task allocation in simulated environments (e.g., predator-prey) uses CNP and its update-enabled variant to manage dynamic, spatially coupled resource assignment with message-efficient negotiation (Kaur et al., 2013).

6. Critical Assessment: Advantages, Trade-Offs, and Limitations

CNP offers several operational benefits:

• Decentralized and scalable negotiation using simple, composable message cycles.
• Explicit, auditable task award logic, enabling resource contention and serializability.
• Flexibility for integrating custom, domain-specific scoring rules, belief updates, or reputation schemes.
• Extensions for dynamic task specification, improving adaptability and lowering communication load in volatile environments.

However, challenges remain:

• Conventional CNP incurs high overhead if tasks or environments are rapidly changing, as entire CFP-propose-accept cycles must restart for each alteration.
• Enhanced protocols like updated-CNP require mutable agent execution logic and more complex state tracking by managers, particularly of contract state and specification.
• In highly volatile settings, the benefit of in-place updates may diminish due to frequent update floods.

Empirical studies show that, in practical systems such as SPEAR and blockchain-based energy markets, explicit CNP-based coordination accelerates failure recovery, economizes resource use, and reduces conflict frequency compared to naive or central invocation methods (Mallick et al., 4 Feb 2026, Saxena et al., 2019, Kaur et al., 2013).