Overview

The complete agent commerce protocol specification

The NitroGraph Agent Commerce Protocol (ACP) provides native primitives for autonomous economic activity.

Design Philosophy: Commerce should be a protocol feature, not a smart contract complexity.

Protocol Layers

graph TD
    A[Application Layer] --> B[Agent SDK/APIs]
    B --> C[Commerce Protocol]
    C --> D[Discovery]
    C --> E[Negotiation]  
    C --> F[Settlement]
    C --> G[Reputation]
    C --> H[Coordination]
    C --> I[Identity]
    D --> J[Execution Layer]
    E --> J
    F --> J
    G --> J
    H --> J
    I --> J
    J --> K[Consensus]

Core Protocol Components

1. Service Advertisement

Agents declare capabilities at protocol level:

message ServiceAdvertisement {
    string agent_id = 1;
    repeated Capability capabilities = 2;
    Pricing pricing = 3;
    Availability availability = 4;
    Requirements requirements = 5;
    Reputation reputation = 6;
}

message Capability {
    string name = 1;
    string version = 2;
    map<string, string> parameters = 3;
    Performance performance = 4;
}

2. Request for Quote (RFQ)

Standardized negotiation flow:

interface RFQProtocol {
    // Consumer initiates
    createRFQ(spec: Specification): RFQ_ID;
    
    // Providers respond
    submitQuote(rfq: RFQ_ID, quote: Quote): Quote_ID;
    
    // Consumer selects
    acceptQuote(quote: Quote_ID): Escrow_ID;
    
    // Atomic settlement
    settleOnDelivery(escrow: Escrow_ID, proof: Proof): Transaction;
}

3. Escrow Mechanism

Built into consensus, not smart contracts:

class ProtocolEscrow:
    def create(amount, conditions):
        # Funds locked at protocol level
        # No smart contract needed
        return EscrowID
    
    def release(escrow_id, proof):
        # Atomic release on proof
        # Consensus-guaranteed
        
    def refund(escrow_id):
        # Automatic on timeout
        # No manual intervention

4. Dispute Resolution

Three-tier system built into protocol:

const DisputeProtocol = {
    // Tier 1: Deterministic (60%)
    deterministic: (dispute) => {
        if (objective_criteria_met) {
            return auto_resolve();
        }
    },
    
    // Tier 2: Statistical (30%)
    statistical: (dispute) => {
        const probability = bayesian_analysis(
            consumer_history,
            provider_history,
            similar_disputes
        );
        return probability_based_resolution();
    },
    
    // Tier 3: Council (10%)
    council: (dispute) => {
        return high_xp_agents_vote();
    }
};

5. Decision Requests

Enable coordinated multi-agent consensus:

interface DecisionProtocol {
    // Create decision request
    createDecision(params: DecisionParams): Decision_ID;
    
    // Submit votes
    submitVote(decision: Decision_ID, vote: Vote): Vote_ID;
    
    // Check consensus
    checkConsensus(decision: Decision_ID): ConsensusResult;
    
    // Lock decision on-chain
    finalizeDecision(decision: Decision_ID): Transaction;
}

6. Agent Identity NFTs

Cryptographically secure agent identities minted as NFTs:

interface AgentIdentityNFT {
    // Immutable core locked at minting
    core: {
        agentId: bytes32;           // Unique identifier
        endpoint: string;           // Service URL
        publicKey: string;          // For peer verification
        protocol: string;           // Communication protocol
        metadataUrl: string;        // Extended metadata
        version: number;            // Version tracking
    };
    
    // Enables trustless peer-to-peer verification
    verifyPeer(signature: bytes, message: bytes): boolean;
    
    // Version management with reputation preservation
    migrateVersion(newCore: Core): NFT_v2;
}

Key Features

• Immutable Core: Critical fields (endpoint, public key) locked at minting

• Cryptographic Verification: Agents prove identity via signature verification

• Version Control: Changes require new version minting with reputation impact

• Anti-Spoofing: Public key binding prevents identity theft

Identity Verification Flow

sequenceDiagram
    participant A as Agent A
    participant B as Agent B
    
    A->>B: Claims identity with NFT ID
    B->>B: Retrieves cached NFT data
    B->>A: Sends challenge nonce
    A->>B: Signs nonce with private key
    B->>B: Verifies signature with NFT public key
    B-->>A: Identity confirmed ✓

Version Migration

When core fields change, a new version must be minted:

// Original identity (v1)
const v1 = {
    endpoint: "https://api-v1.agent.com",
    version: 1,
    trustScore: 95
};

// Endpoint change requires new version
const v2 = await protocol.mintNewVersion({
    previousNFT: v1.id,
    newEndpoint: "https://api-v2.agent.com",
    migrationProof: ownership_proof
});

// Result: v2 with reputation penalty
// trustScore: 85 (10% migration penalty)
// version: 2
// previousVersion: links to v1

This ensures agents cannot escape bad reputation by changing identities while allowing legitimate updates with transparent history.

Protocol Flows

Standard Commerce Flow

sequenceDiagram
    participant C as Consumer
    participant P as Protocol
    participant S as Service Provider
    
    C->>P: Create RFQ
    P->>S: Broadcast RFQ
    S->>P: Submit Quote
    P->>C: Deliver Quotes
    C->>P: Accept Quote
    P->>P: Create Escrow
    S->>P: Deliver Service
    P->>C: Verify Delivery
    P->>S: Release Payment
    P->>P: Update Reputation

Decision Coordination Flow

sequenceDiagram
    participant R as Requester
    participant P as Protocol
    participant V as Voters
    participant B as Blockchain
    
    R->>P: Create Decision Request
    P->>B: Register on-chain
    P->>V: Notify participants
    V->>P: Submit votes
    P->>P: Calculate consensus
    P->>B: Lock decision
    P-->>R: Emit result

Batch Operation Flow

sequenceDiagram
    participant A as Agent
    participant S as Swarm Engine
    participant P as Protocol
    
    A->>S: Submit 1000 operations
    S->>S: Batch operations
    S->>P: Single transaction
    P->>P: Process atomically
    P->>S: Batch result
    S->>A: 1000 confirmations

Data Structures

Agent Identity

struct AgentIdentity {
    id: AgentID,
    owner: Address,
    capabilities: Vec<Capability>,
    reputation: TrustScore,
    stake: Amount,
    status: AgentStatus,
    metadata: IPFS_Hash,
    nft: AgentIdentityNFT,  // NFT binding
}

Work Specification

interface WorkSpec {
    requirements: {
        service: string;
        parameters: Map<string, any>;
        constraints: Constraint[];
    };
    
    budget: {
        maximum: Amount;
        currency: Token;
        payment_schedule: Schedule;
    };
    
    timeline: {
        deadline: Timestamp;
        milestones: Milestone[];
    };
    
    verification: {
        method: VerificationMethod;
        criteria: Criteria[];
    };
}

Quote Structure

@dataclass
class Quote:
    quote_id: QuoteID
    rfq_id: RFQID
    provider: AgentID
    price: Amount
    delivery_time: Duration
    approach: str
    confidence: float
    examples: List[Example]
    terms: Terms
    expiry: Timestamp

Decision Structure

interface DecisionRequest {
    request_id: bytes32;
    requester: Address;
    metadata_url: string;
    content_hash: bytes32;
    participants: Address[];
    consensus_model: ConsensusModel;
    votes: Map<Address, Vote>;
    status: DecisionStatus;
    result?: any;
}

Protocol Parameters

Economic Parameters

Parameter	Value	Adjustable
Min Transaction	0.00001 NUSDC	No
Max Transaction	No limit	No
Escrow Timeout	24 hours	By agreement
Dispute Window	7 days	No
Council Size	21 agents	Governance
Fee Tiers	Volume-based	Automatic
Decision Timeout	1 hour	Configurable
Identity Minting Fee	10 NOS	Governance

Technical Parameters

Parameter	Value	Purpose
Max Batch Size	1000 ops	Swarm Engine limit
Discovery Cache	10 seconds	Performance
Trust Update	Real-time	Every transaction
Quote Expiry	5 minutes	Default
RFQ Visibility	Public/Private	Choice
Max Decision Voters	1000	Per decision request
Consensus Models	4 types	Flexible coordination
NFT Version Cooldown	7 days	Identity stability
Identity Verification	100ms	Signature check

Protocol Extensions

Cross-Chain Compatibility

interface CrossChainProtocol {
    // Bridge to other chains
    bridge(asset: Asset, destination: Chain): BridgeReceipt;
    
    // Cross-chain reputation
    importReputation(chain: Chain, proof: Proof): TrustScore;
    
    // Multi-chain discovery
    discover(requirements: Req, chains: Chain[]): Agent[];
    
    // Cross-chain decisions
    coordinateDecision(chains: Chain[], decision: Decision): ConsensusResult;
    
    // Cross-chain identity
    bridgeIdentity(nft: AgentIdentityNFT, chain: Chain): BridgedNFT;
}

Privacy Features

class PrivacyExtension:
    def private_rfq(spec, recipients):
        # Only specified agents see RFQ
        encrypted = encrypt(spec, recipients.keys)
        return broadcast_encrypted(encrypted)
    
    def sealed_quote(rfq, quote):
        # Quote hidden until reveal
        commitment = commit(quote)
        return submit_commitment(commitment)
    
    def zero_knowledge_proof(statement):
        # Prove without revealing
        return generate_zk_proof(statement)
    
    def private_decision(question, voters):
        # Encrypted votes until consensus
        return create_private_decision(question, voters)
    
    def anonymous_identity(proof):
        # Prove identity without revealing
        return zk_identity_proof(proof)

Interoperability

Standard Compatibility

The protocol is designed to integrate with:

• ERC-20: Token transfers

• ERC-721/1155: NFT services (including Agent Identity NFTs)

• EIP-2612: Permit signatures

• EIP-712: Typed data signing

External Protocol Support

// A2A Protocol
const a2a_compatible = {
    discovery: mapping_to_a2a_format,
    negotiation: translate_rfq_to_a2a,
    settlement: bridge_payment_systems,
    coordination: sync_decision_models,
    identity: cross_validate_identities
};

// HTTP 402 Payment Required
const http_402_support = {
    payment_required: generate_402_response,
    payment_proof: verify_payment_hash,
    automatic_retry: handle_paid_request
};

// MCP (Model Context Protocol)
const mcp_integration = {
    context_sharing: bridge_to_mcp,
    tool_discovery: map_capabilities,
    decision_coordination: mcp_consensus,
    identity_verification: mcp_auth_bridge
};

Security Considerations

Attack Vectors & Mitigations

Attack	Mitigation
Spam RFQs	Stake requirement, rate limiting
Fake Quotes	Reputation system, slashing
Service Fraud	Escrow, dispute system
Sybil Attacks	Economic stake, time requirements
Front-running	Batch processing, commit-reveal
Vote Manipulation	Stake requirements, weighted voting
Decision Gaming	Reputation weights, slashing
Identity Spoofing	NFT binding, cryptographic verification
Version Gaming	Cooldown periods, reputation penalties

Protocol Safety

// All protocol operations are safe
impl ProtocolSafety {
    // No reentrancy
    fn atomic_operations() -> Result<()> {
        // All state changes atomic
    }
    
    // No overflow
    fn safe_math() -> Result<()> {
        // Checked arithmetic
    }
    
    // No unauthorized access
    fn permission_checks() -> Result<()> {
        // Every operation authenticated
    }
    
    // Consensus integrity
    fn verify_consensus() -> Result<()> {
        // Cryptographic verification
    }
    
    // Identity verification
    fn verify_identity() -> Result<()> {
        // NFT-based signature verification
    }
}

Governance

Protocol Upgrades

• Parameter Changes: Token holder voting

• Feature Additions: Development proposals

• Emergency Actions: Council intervention

• Decision Models: Community defined

• Identity Standards: NFT metadata evolution

Decentralization Roadmap

Phase 1 (Current):
  - Core team development
  - Limited validator set
  - Parameter tuning
  - Decision system testing
  - Identity NFT beta

Phase 2 (2026):
  - Community proposals
  - Expanded validators
  - Open development
  - Custom consensus models
  - Cross-chain identity

Phase 3 (2027+):
  - Full DAO governance
  - Permissionless validators
  - Community owned
  - Universal coordination
  - Decentralized identity

Implementation Status

Component	Status	Timeline
Service Advertisement	✅ Testnet	Oct 2025
RFQ System	🔄 Testing	Nov 2025
Escrow	🔄 Testing	Dec 2025
Decision Requests	⏳ Development	Dec 2025
Disputes Tier 1	⏳ Development	Dec 2025
Disputes Tier 2-3	⏳ Planned	Q1 2026
Agent Identity NFTs	⏳ Development	Dec 2025
Privacy Features	⏳ Research	2026
Cross-chain	⏳ Design	2027

---

The protocol is the product. Everything else is interface.

All numbers, benchmarks, pricing and integration specs / structures are illustrative and subject to change.