Negotiation Protocol

Term Negotiation & AI Intermediary

Barter trades require precise alignment on deliverables, working hours, and milestones before any work begins. Because NodeHash coordinates multi-party cycles across two or three independent peers, unstructured back-and-forth messaging often leads to stalled conversations or unaddressed scope differences. The protocol integrates an autonomous AI intermediary that monitors proposal friction, suggests schedule compromises, and guides peers toward unanimous consensus.

🤝
The Unanimous Consensus Rule (K ≤ 3)

In closed barter cycles, every participant must sign off on their terms before work starts. If two peers agree but the third counterparty rejects their deliverable requirements, the entire cycle aborts cleanly. Partial execution is mathematically prohibited to prevent unilateral debt accumulation on the mutual credit ledger.

The Negotiation State Machine

Within the overall 7-state trade lifecycle, negotiation occupies the pivotal bridge between match discovery and live execution. You can explore this progression interactively in our 7-State AI Exchange Lifecycle Demo.

Once peers review and accept ranked candidates, the exchange record shifts from RANKED into the active NEGOTIATING state:

Linear State Progression

Exchanges follow a strict state progression:

MATCHED → RANKED → NEGOTIATING → AGREED → COMPLETED → RECORDED

During NEGOTIATING, participants post structured proposals covering deliverables, deadlines, and working windows.

The exchange cannot advance to AGREED until all counterparties cryptographically sign their agreement payload.

Atomic Rollback Containment

Negotiations carry zero financial liability until unanimous signatures are recorded.

If any participant explicitly cancels the trade or allows their response window to time out, the exchange transitions to CANCELLED.

Unmatched supply items return immediately to the active candidate pool with no penalty to participant credit ratings or sponsor trust scores.

Proposal Schemas & Message Types

Rather than relying on free-form unstructured chat, the node API structures negotiations through typed proposal messages. Peers exchange messages via POST /api/v1/exchange/:exchangeId/negotiate using five standardized payload types:

Message Type Target Scope Payload Structure Typical Usage
scope Work Boundaries Description string, non-goals, revision count Defining deliverable limits and acceptance criteria.
time_window Scheduling Day of week, start time, end time, timezone Proposing synchronized working sessions or review calls.
deliverable Specific Milestones Deliverable summary, format, acceptance criteria Breaking large barter exchanges into inspectable artifacts.
concession Tradeoffs Requested adjustment, counter-offered value Bridging minor discrepancies in estimated work hours.
chat Clarifications Free-form discussion string Informal questions regarding implementation details.

Deliverable Proposal Payload

Here is a representative request proposing granular deliverables and acceptance criteria:

Deliverable Proposal (JSON) 
{
  "messageType": "deliverable",
  "toUserId": "usr_tokyo_082",
  "payload": {
    "title": "Database Optimization and Migration Plan",
    "deliverables": [
      "Analyze slow query logs on PostgreSQL cluster",
      "Write composite indexes for transaction history tables",
      "Deliver benchmark report showing latency reductions"
    ],
    "scope_boundaries": {
      "non_goals": ["Application-layer refactoring", "Production schema migration execution"],
      "max_revisions": 2,
      "estimated_hours": 12
    }
  }
}

Autonomous AI Intermediary Mediation

Negotiations often stall when participants operate across wide timezone gaps or hesitate to make initial compromises. NodeHash embeds an autonomous intermediary service directly into the exchange pipeline.

The AI intermediary continuously evaluates the negotiation context, calculating mutual compromises without taking custody of private keys or overriding human sovereignty:

Automated Convergence Discovery

When counterparties submit conflicting meeting requests, the intermediary parses both availability profiles.

If overlapping UTC hours exist, the AI drafts a concrete convergence suggestion:

"Found mutual availability window on Tuesday between 14:00 and 16:00 UTC. Recommending session confirmation."

If no live overlap is possible, the AI recommends an asynchronous milestone schedule with clear review deadlines.

Deadlock Prevention & Concessions

When peers exchange repeated counter-proposals without convergence, the intermediary computes the midpoint of their scope bounds.

The assistant generates an actionable compromise itemizing specific scope adjustments.

Human participants remain in full control. Either peer can adopt, refine, or ignore the intermediary's draft.

Friction Telemetry & Deadlock Scoring

To decide when to intervene, the intermediary calculates a composite friction score between counterparty pairs. The friction formula weights three behavioral variables:

Variable Weight Metric Evaluated Deadlock Signal
Historical Success 40% (0.40) Ratio of past negotiations completed successfully High drop-off rate indicates hesitation or dispute risk.
Response Latency 35% (0.35) Average time taken to reply to incoming proposals Responses taking over 24 hours trigger prompt reminders.
Timezone Divergence 25% (0.25) Physical offset distance between local working hours Offsets over 8 hours switch the default to async milestones.
💡
Friction Telemetry Safeguards Privacy

Friction metrics rely strictly on mathematical metadata: message timestamps, response intervals, and timezone offsets. The system does not scan the private contents of your messages to train external commercial models.

The Unanimous Cryptographic Agreement Ceremony

Once participants align on deliverables, schedules, and scope boundaries, each party must finalize the agreement. In a 3-way cycle involving Alice, Bob, and Charlie, every party executes the agreement ceremony independently:

  1. Agreement Submission: Each peer calls POST /api/v1/exchange/:exchangeId/agree with their agreed deliverables and confirmed time window.
  2. Hardware Passkey Attestation: The client generates a cryptographic signature over the canonical terms hash using their device's P-256 private key.
  3. Status Check: The node verifies that agreement_status === 'agreed' for every participant in the cycle.
  4. State Transition: Once the final signature arrives, the exchange atomically advances to AGREED. Milestone escrow contracts activate immediately.
Agreement Signing Payload (JSON) 
{
  "agreed_deliverables": [
    "Analyze slow query logs on PostgreSQL cluster",
    "Write composite indexes for transaction history tables",
    "Deliver benchmark report showing latency reductions"
  ],
  "agreed_time_window": {
    "day_of_week": 2,
    "start_time": "14:00",
    "end_time": "16:00",
    "is_negotiable": false
  }
}

With terms formally locked, participants proceed to active fulfillment and milestone delivery.