System Architecture and Protocol Design for RogueSwarms: Enabling Autonomous Agentic Commerce

Full report

On this page

The transition from human-centric digital interfaces to autonomous, machine-driven commerce necessitates a fundamental restructuring of how transactional intent is captured, negotiated, executed, and recorded. RogueSwarms is conceptualized as an orchestration and interoperability protocol designed to support independent machine intelligence agents navigating the digital economy. These agents may represent a diverse array of principals, including buyers, merchants, logistics providers, marketplaces, and procurement systems. The central architectural challenge is designing a verifiable, trustless framework in which these agents can execute the complete commerce lifecycle autonomously, without RogueSwarms assuming the legal or financial liabilities associated with becoming a seller of record, merchant of record, buyer, escrow provider, or payment custodian1.

To achieve this, the architecture must synthesize modern open standards—such as the Agentic Commerce Protocol (ACP), the Universal Commerce Protocol (UCP), the Agent Payments Protocol (AP2), and the Model Context Protocol (MCP)—into a cohesive, legally sound infrastructure4. The resulting system must secure machine-to-machine interactions against structural protocol vulnerabilities, ensure unambiguous delegation of authority, and provide unforgeable cryptographic attestation of state transitions while preserving the privacy of the counterparties6.

1. The Complete Machine-Commerce Lifecycle

Agentic commerce significantly expands the transaction lifecycle beyond simple product discovery and checkout. When machine agents operate with delegated authority, every step from initial research to post-purchase support must be executed via standardized, machine-readable interfaces. The RogueSwarms architecture maps this lifecycle into four distinct operational phases, defining precisely where the protocol facilitates routing and attestation, and where it steps aside to allow peer-to-peer data exchange.

Phase 1: Pre-Transaction (Discovery, Negotiation, and Quoting)

The lifecycle initiates when a principal (a human user or an enterprise procurement system) delegates a task to a buyer agent. This delegation includes specific constraints, such as budget limits, temporal deadlines, and approved merchant categories9. During the product discovery phase, the agent utilizes protocols like MCP or UCP to search and compare products across various retail catalogs4. Unlike human browsing, machine discovery relies entirely on structured data. Catalogs must expose complete, normalized attributes—such as size, material compatibility, and real-time inventory availability—using established ontologies like Schema.org11.

Once potential products are identified, the agent evaluates offers and pricing. Pricing in a globalized machine economy is highly dynamic, influenced by real-time logistics, regional taxes, and buyer-specific discounts10. If the transaction parameters are flexible, agents may engage in automated negotiation, utilizing agent-to-agent (A2A) protocols to bargain over price, bundled items, or delivery windows12.

The culmination of this phase is the generation of a quote. The buyer agent assembles a cart and requests a cryptographically signed quote from the merchant agent. This quote represents the true landed cost, locking in the price, specific tax allocations, and shipping fees for a defined period13. At this stage, RogueSwarms acts merely as the routing layer for MCP and A2A communications, recording no transactional data.

Phase 2: Execution (Authorization, Orders, and Payments)

With a cryptographically signed quote secured, the buyer agent must generate an authorization. Modern protocols separate this into distinct components to protect sensitive data. Using the AP2 standard, the buyer agent generates a Checkout Mandate, which captures the exact cart details, and a Payment Mandate, which authorizes a specific financial instrument5. The Checkout Mandate is bound to the quote via a cryptographic hash, ensuring that if the merchant alters any detail of the cart, the authorization immediately fails17.

Upon validating the mandates against the principal’s delegated constraints, the agent executes the checkout. For off-chain fiat transactions, this is governed by the Agentic Commerce Protocol (ACP), which allows the agent to pass a narrowly scoped payment token to the merchant without ever exposing the underlying primary account number (PAN)1. For on-chain or web-native environments, protocols like x402 or ERC-8183 handle the payment settlement or escrow locking4.

The successful payment authorization results in the generation of a purchase order and the formal creation of the order state. Here, RogueSwarms plays a critical role as an attestation log. While the raw financial data and mandates flow directly between the buyer, merchant, and payment gateway, the counterparties submit cryptographic hashes of these finalized mandates to RogueSwarms to secure a non-repudiable timestamped receipt20.

Phase 3: Post-Transaction (Fulfillment and Tracking)

Once the order is created, the responsibility shifts to supply chain and logistics agents. The merchant agent interacts with fulfillment providers to initiate packaging and shipping. Logistics agents emit continuous, machine-readable shipment tracking events10. Drawing on decentralized architectures like the Beckn protocol used in the Open Network for Digital Commerce (ONDC), these fulfillment updates are multicasted back to the buyer agent22.

In cases of partial fulfillment—where only a subset of the ordered inventory is available—the merchant agent must emit a mathematically verifiable delta adjustment. This requires the generation of updated invoices that comply strictly with European standards like EN 16931, ensuring that the adjusted tax and line-item totals balance perfectly before any partial funds are captured from the payment gateway24.

Phase 4: Exceptions and Support (Returns, Disputes, and Warranties)

The final phase encompasses the long-tail lifecycle of the product. Post-purchase support agents monitor delivery success and evaluate the need for returns or warranties10. If a product is defective, the buyer agent initiates a return request based on the machine-readable policies embedded in the original quote11.

Refunds and cancellations are executed as reverse transactions. A cancellation rights policy, defined at checkout, dictates whether the agent can autonomously trigger a refund mandate. If a disagreement occurs—such as the merchant agent refusing a valid return—the system enters a dispute state. Because RogueSwarms holds the cryptographic receipts of the original quote, the AP2 mandates, and the delivery attestations, an independent arbitrator (or an evaluator agent in an ERC-8183 escrow scenario) can deterministically resolve the dispute without relying on human "he said, she said" arguments17. RogueSwarms does not adjudicate the dispute; it merely provides the unforgeable evidence chain. Furthermore, warranties are issued as W3C Verifiable Credentials directly to the buyer's wallet, allowing subsequent repair agents to prove warranty coverage without contacting the original merchant8.

2. Canonical Terminology for Commerce Primitives

The transition from human-interpreted web pages to API-driven machine commerce requires absolute semantic precision. Ambiguity in definitions leads to structural protocol vulnerabilities where malicious actors can exploit the gap between what an agent thought it was authorizing and what the merchant actually executed6. To ensure interoperability, the RogueSwarms ecosystem must standardize the definitions of its core primitives.

The difference between an offer, quote, order, authorization, payment, and receipt defines the boundaries of risk and commitment in an agentic transaction.

An Offer is an unbound, non-committal representation of a product or service. It exists in the discovery phase and represents what a merchant is generally willing to sell. An offer includes base pricing and technical specifications but lacks buyer-specific context. Agents filter offers during discovery, but they cannot execute a transaction against an offer because the landed cost (inclusive of taxes and shipping) is undefined11.

A Quote is a cryptographically signed, highly specific, and time-bound proposal generated by a merchant for a specific buyer agent. It encapsulates the exact cart contents, the calculated taxes based on the delivery jurisdiction, the shipping costs, and the explicit cancellation and return policies13. A quote is a legal commitment by the merchant: if the buyer agent authorizes payment before the quote's expiry time, the merchant is bound to the stated terms16.

An Order is the bilateral state object created the moment a quote is successfully accepted and authorized. It serves as the master record for the transaction's lifecycle, acting as the anchor point for fulfillment updates, invoices, and post-purchase disputes.

An Authorization represents the cryptographic proof that the buyer has consented to the terms of the quote and permitted the expenditure of funds. In modern protocols like AP2, authorization is encapsulated within a Mandate (specifically, a Closed Checkout Mandate bound to a Closed Payment Mandate)5. Authorization proves intent and authenticity, but it does not move money5.

A Payment is the actual movement of value across a financial rail, executing the terms of the authorization. Whether clearing via tokenized credit card networks through ACP, or via stablecoin settlement through the x402 protocol, payment transfers financial liability and settles the debt created by the order1.

A Receipt is an unforgeable, tamper-evident cryptographic artifact proving that a specific event occurred. In the RogueSwarms architecture, receipts are not simple text emails; they are structured Verifiable Data Structure Proofs (VDP) or COSE\_Sign1 envelopes generated by an attestation log, providing a mathematical guarantee of state transitions for auditing and dispute resolution17.

3. State-Machine Architecture

To prevent race conditions, time-of-check to time-of-use (TOCTOU) vulnerabilities, and accidental double-spending, the lifecycle of every transaction within RogueSwarms must be governed by strict, deterministic state machines6. The architecture relies on three interrelated state models: the Core Order Lifecycle, the AP2 Authorization flow, and the Trustless Escrow flow.

The Core Order Lifecycle

The primary state machine tracks the transition from discovery to terminal completion.

 

 

 

Code snippet

stateDiagram-v2     \[\\] \--\> Discovery     Discovery \--\> Quoted : Cart Assembled & Signed by Merchant     Quoted \--\> Discovery : Quote Expired / Rejected by Buyer     Quoted \--\> Authorized : Buyer Agent Signs AP2 Mandates     Authorized \--\> Funded : Payment Gateway Settles / Escrow Locks     Funded \--\> Partially\_Fulfilled : Logistics Agent Emits Delta     Partially\_Fulfilled \--\> Fulfilled : Final Logistics Delivery     Funded \--\> Fulfilled : Complete Logistics Delivery     Fulfilled \--\> Terminal : Post-Purchase Window Expires / Buyer Accepts     Funded \--\> Refunded : Cancellation Initiated / Dispute Won     Partially\_Fulfilled \--\> Refunded : Partial Refund Executed     Terminal \--\> \[\\]

The AP2 Authorization Flow

Because agents possess ambient authority, the authorization of funds must follow a highly constrained internal state machine based on the Agent Payments Protocol (AP2). Mandates must evolve from broad constraints to locked, cryptographically bound approvals5.

 

 

 

Code snippet

stateDiagram-v2     \[\\] \--\> Open\_Mandate : Principal Defines Boundaries (Budget, Merchant)     Open\_Mandate \--\> Closed\_Checkout\_Mandate : Agent Locks Quote & Hashes Cart     Closed\_Checkout\_Mandate \--\> Closed\_Payment\_Mandate : Agent Binds Payment Instrument to Cart Hash     Closed\_Payment\_Mandate \--\> Executed : Merchant Presents Mandates to Gateway     Executed \--\> \[\\]

The Trustless Escrow Flow (ERC-8183 Model)

For high-trust or gig-economy agentic workflows where traditional card payments are insufficient, RogueSwarms must support external smart-contract state machines, such as the ERC-8183 Agentic Commerce standard. This standard introduces a third-party Evaluator agent to govern the release of funds19.

 

 

 

Code snippet

stateDiagram-v2     \[\\] \--\> Open : Client Creates Job & Assigns Evaluator     Open \--\> Funded : Client Locks Cryptographic Assets in Escrow     Funded \--\> Submitted : Provider Agent Submits Work Hash     Submitted \--\> Terminal\_Completed : Evaluator Approves & Funds Released     Submitted \--\> Terminal\_Rejected : Evaluator Rejects & Funds Refunded     Funded \--\> Terminal\_Refunded : Expiry Reached (Automatic Refund)     Terminal\_Completed \--\> \[\\]     Terminal\_Rejected \--\> \[\\]     Terminal\_Refunded \--\> \[\\]

4. Recommended Objects and Schemas

To facilitate seamless cross-border commerce and eliminate the friction of proprietary data formats, RogueSwarms must mandate the use of established international schemas. Custom JSON structures lead to parsing errors and semantic mismatches, which in an autonomous environment directly result in financial losses. The protocol must enforce the following representations:

 

Representations in Practice

How should expiry times be represented? Expiry times are critical in agentic commerce because a quote represents a locked price. Expiry must be represented as a strict ISO 8601 UTC timestamp in the payload of the quote. When an agent submits a Closed Checkout Mandate to a merchant, the merchant validates the submission timestamp against the quote's expiry. If the timestamp is past the expiry, the state transition is rejected, and the agent must initiate a new discovery and quoting phase9.

How should currency and units be represented? Currency must be strictly isolated from the numeric value and represented via ISO 4217 codes. Units must rely on the UN/ECE Recommendation No. 20 code list. An agent parsing an offer does not interpret "standard size" or "one box"; it requires discrete values, such as 10 units of H87 priced in EUR11. This normalization is what enables an agent to compare offers from a supplier in Germany against a supplier in Japan with perfect fidelity.

How should tax information and international commerce differ? International commerce introduces vast complexities regarding Value Added Tax (VAT), Goods and Services Tax (GST), cross-border tariffs, and reverse-charge mechanisms. Tax information must be represented using the EN 16931 standard embedded within Peppol BIS Billing 3.0. This semantic model allows the quote to specify the exact VAT category (e.g., Category 'S' for standard rate, Category 'AE' for reverse charge) and mandates that the tax totals mathematically reconcile25. When an agent conducts international commerce, it passes its principal's legal jurisdiction and tax identification number to the merchant during the quoting phase. The merchant calculates the localized landed cost, applies the correct EN 16931 tax category, and locks this into the quote. The machine-readable invoice generated post-payment will then automatically satisfy the auditing and compliance requirements of the destination country25.

How should product identifiers be represented? Product identifiers must utilize the GS1 Digital Link standard. Rather than passing a raw 14-digit GTIN, the agent uses a structured URI (e.g., https://id.gs1.org/01/{GTIN}/21/{serial}). This allows the agent to predictably query standard endpoints for product metadata, ensuring that the item being negotiated is exactly the item recorded in the supply chain31.

5. Event Taxonomy and the Attestation Model

To maintain a zero-trust architecture while strictly avoiding the legal liability of a data broker or payment custodian, RogueSwarms must implement a precise boundary regarding what data it touches. The architecture relies on the principle of peer-to-peer data exchange coupled with centralized cryptographic attestation.

Which records should remain between counterparties?

All highly sensitive data, personally identifiable information (PII), and raw transactional payloads must remain exclusively between the transacting agents. RogueSwarms must never ingest, store, or route:

• Primary Account Numbers (PANs), credit card details, or banking credentials1.
• Raw cart contents, item descriptions, or pricing algorithms.
• Physical shipping addresses or human identity details.
• The raw JSON or XML payloads of the UCP checkout sessions or Peppol invoices4.

Which records should RogueSwarms store?

RogueSwarms operates strictly as an immutable attestation log. It ingests and stores only cryptographic representations of the peer-to-peer interactions. Specifically, it stores:

• Public Keys and DIDs: The Decentralized Identifiers (DIDs) and associated public verification keys of the registered agents, allowing counterparties to verify digital signatures38.
• Event Hashes and Signatures: When agents complete a state transition (e.g., Quote Generation, Mandate Signing, Order Fulfillment), they calculate a SHA-256 hash of the payload, sign it with their private keys, and submit the signature and the hash to RogueSwarms.
• Delegation Chains: The public, privacy-preserving proofs of UCAN delegation chains to establish that a sub-agent has the authority to act38.

Which events should be attestable?

Every transition in the state machine must be attestable to create a complete, non-repudiable audit trail. The event taxonomy includes:

• Agent\_Registered: Anchoring the identity and public key.
• Delegation\_Granted: The issuance of an open mandate or UCAN token.
• Quote\_Committed: The merchant signing the locked cart and pricing terms.
• Mandate\_Signed: The buyer agent cryptographically binding the payment to the cart17.
• Fulfillment\_Updated: Logistics agents asserting a change in physical state.
• Exception\_Raised: Cancellations, returns, or dispute initiation.
• Job\_Evaluated: In escrow scenarios, the evaluator attesting to the quality of the deliverable19.

6. Receipt and Attestation Model

How should a machine prove that a transaction occurred? In a human context, an email receipt or a database entry suffices. In an autonomous agentic economy, proof must be mathematically deterministic and independently verifiable offline.

RogueSwarms must implement the Supply Chain Integrity, Transparency, and Trust (SCITT) architecture, utilizing CBOR Object Signing and Encryption (COSE) as defined in IETF RFC 9052 and RFC 994320.

When two agents agree on a state transition—for example, the merchant delivers a signed quote to the buyer agent—they simultaneously submit the COSE\_Sign1 signature envelope to the RogueSwarms Transparency Service. RogueSwarms verifies the signature against the agent's registered public key, applies its own timestamp and Registration Policy, and inserts the record into an append-only cryptographic ledger (e.g., a Merkle tree)20.

RogueSwarms then returns a SCITT Receipt (a signed Verifiable Data Structure Proof) to both agents. This receipt proves unequivocally that the event was registered at a specific time. If a dispute subsequently arises—for example, the merchant claims the buyer altered the quote—the arbitrator asks the merchant to produce the raw quote data. The arbitrator hashes the data and compares it to the hash secured inside the RogueSwarms SCITT Receipt. If they match, the evidence is mathematically proven; if they do not, the merchant's claim is dismissed. This model guarantees accountability without requiring RogueSwarms to host the underlying data5.

7. Delegation Model and Multi-Hop Agents

One of the most profound challenges in agentic commerce is the "Confused Deputy" problem. This occurs when an agent with broad ambient authority is manipulated—often via prompt injection in the merchant's product description—into misusing its credentials to execute unauthorized actions, such as fetching another user's payment tokens or escalating its own privileges6.

What happens when an agent delegates a transaction to another agent? In complex workflows, a primary planning agent may decompose a task and delegate sub-tasks (e.g., search, negotiation, payment) to specialized sub-agents. If the primary agent simply passes its bearer token to the sub-agent, the sub-agent gains the full, unconstrained authority of the principal, creating a massive security vulnerability43.

To secure multi-hop delegation chains, RogueSwarms must enforce an architecture composed of three protocols:

1. User-Controlled Authorization Networks (UCAN): For off-chain, localized delegation, UCANs allow an agent to issue cryptographic capability tokens to sub-agents. Crucially, UCANs enforce monotonic attenuation; each hop in the delegation chain can only maintain or reduce the scope of permissions, never expand it. A primary agent authorized to spend $500 can issue a UCAN to a sub-agent limited to spending $100. This attenuation chain is embedded in the token and can be verified entirely offline, avoiding network bottlenecks38.

2. OAuth Rich Authorization Requests (RAR \- RFC 9396\): For interactions requiring enterprise authorization servers, standard OAuth scopes (like write:payment) are dangerously broad47. RogueSwarms must mandate the use of RAR, which replaces generic strings with structured JSON authorization details. An agent requests a token dynamically bound to specific constraints: e.g., an authorization strictly limited to a single task\_id, valid for only 300 seconds, restricted to a specific merchant's API endpoint47.

3. Demonstrating Proof-of-Possession (DPoP \- RFC 9449\): To prevent intercepted tokens from being replayed across the agentic network, all access tokens must be sender-constrained. When a sub-agent requests a delegated token, it generates a local cryptographic key pair and signs a DPoP proof. The authorization server issues the token containing a cnf (confirmation) claim holding the JWK thumbprint (jkt) of the agent's public key49. When the agent uses the token, it must simultaneously present a fresh signature proving it holds the matching private key. A stolen token is completely useless without the private key, which never leaves the agent's secure enclave44.

8. Cancellation, Refund, and Partial Fulfillment Model

Autonomous operations require rigid frameworks for exceptions, as human intervention cannot act as a fallback for transactional friction.

Cancellation Rights: How should cancellation rights be represented? They must not be buried in natural language terms of service. Instead, they must be represented as machine-readable policy arrays embedded within the EN 16931/Peppol quote payload (e.g., \<CancellationWindowSeconds\>, \<RestockingFeePercentage\>, \<ReturnShippingLiableParty\>). When the buyer agent evaluates the quote during Phase 1, it computationally verifies that these terms comply with the principal's delegated constraints.

Partial Fulfillment: How should partial fulfillment work? If a merchant can only fulfill three of five ordered items, the state machine must adjust without breaking the cryptographic integrity of the original AP2 mandates. The merchant agent must emit a Fulfillment\_Delta event to the attestation log and generate an updated UBL 2.1 invoice reflecting the reduced quantity. Using the strict arithmetic rules of Peppol (e.g., BR-CO-10), the buyer agent validates that the new invoice accurately reflects the partial shipment and subsequently releases a secondary mandate allowing the capture of the reduced funds24.

Refund Representation: How should refunds be represented? A refund is not merely an API call; it is a discrete financial mandate. When a valid cancellation or return occurs, the merchant agent issues a Refund\_Mandate that cryptographically references the original transaction ID and the SCITT receipt of the initial order. In escrow scenarios managed by ERC-8183, refunds are represented as state transitions. If the expiry block height is reached without the Evaluator approving the work, the smart contract automatically transitions to the Terminal\_Refunded state, programmatically returning the locked assets to the client agent19.

9. Error, Idempotency, and Security Model

The security model of agentic commerce must shift focus from securing the underlying Large Language Model (LLM) against prompt injection, to securing the protocol layer against structural vulnerabilities. Recent research into Protocol-Level Attacks on Agentic Commerce Platforms (arXiv:2607.21824) demonstrates that structural attacks—such as time-of-check to time-of-use (TOCTOU) races and credential exfiltration through unverified payload injection—succeed deterministically regardless of the AI model deployed6.

The RogueSwarms error and security model addresses this through strict protocol-layer defenses:

• A-VIP (Verified-Intent Protection): To prevent merchant product descriptions from tricking a buyer agent into altering a cart or fetching the wrong payment credentials, the protocol must cryptographically bind every credential lookup directly to the authenticated session that requested it, and bind every cart line-item to the exact listing previously evaluated by the agent18.
• Idempotency Recommendations: Agents operate in highly asynchronous environments subject to network partitions and retries. Every state-mutating request (creating a quote, funding an escrow, emitting a refund mandate) MUST include a cryptographically random, agent-generated Idempotency-Key in the request header. If an endpoint receives a duplicate request with the same key, it must return the cached response of the initial execution rather than processing the transaction a second time. This prevents autonomous agents from accidentally double-spending funds during retry loops.
• Standardized Error Taxonomies: Errors must be formatted utilizing RFC 7807 (Problem Details for HTTP APIs). The agent must be able to computationally distinguish between a transient error (e.g., HTTP 429 Too Many Requests, triggering exponential backoff) and a terminal protocol error (e.g., Mandate\_Expired or Signature\_Invalid), which requires halting execution and updating the attestation log9.

10. Human-Approval Checkpoints

While RogueSwarms is designed for machine-to-machine commerce, robust governance requires dynamic Human-in-the-Loop (HITL) checkpoints. Drawing upon the Decision Trust Protocol (DTP) and the AP2 standard, RogueSwarms integrates human oversight without breaking automated workflows5.

Checkpoints are managed through the distinction between Open and Closed Mandates:

• Human-Not-Present (Continuous Autonomy): The principal provisions an Open Mandate17. This mandate defines the outer bounds of the agent's authority (e.g., "Spend up to $1,000 per month on AWS infrastructure"). The agent continuously negotiates, quotes, and pays for resources autonomously as long as the transactions remain within these cryptographic boundaries.
• Human-Present (Step-Up Authentication): If an agent encounters a transaction that violates the Open Mandate constraints, or if a behavioral anomaly gate triggers a high risk score, the system executes a "step-up" challenge9. The agent pauses the transaction workflow and pushes a request to the principal. The human reviews the specific cart and uses a hardware-backed authenticator (e.g., FIDO2 passkey) to sign a Closed Checkout Mandate, granting one-time authority to bypass the constraints and complete the specific purchase17.

11. Legal and Accountability Boundaries

The deployment of autonomous agents transferring real-world financial value introduces profound legal complexities. RogueSwarms addresses these through careful alignment with emerging international frameworks.

Under the UNCITRAL Model Law on Automated Contracting (MLAC), specifically Article 8, a contract formed by an automated message system is valid, and the actions of the agent are legally attributed to the principal on whose behalf the system was programmed or deployed54. Therefore, when a buyer agent signs an AP2 mandate and a merchant agent accepts it, a binding legal contract is formed between the respective principals, not the software itself57.

Simultaneously, under the EU AI Act, the deployers of high-risk or interacting AI systems bear specific transparency and accountability obligations58. To maintain a legal safe harbor, RogueSwarms must fiercely protect its status as a decentralized technological orchestrator and attestation provider. If RogueSwarms were to take custody of funds, host the product catalog, or automatically process payments, it would immediately inherit the liability of a Payment Service Provider (PSP) or a Merchant of Record (MoR)1. By restricting its scope to routing standardized messages and logging cryptographic receipts, RogueSwarms insulates itself from the transactional liability of the agents utilizing the network.

12. RogueSwarms Functional Boundaries

To enforce the legal accountability model and ensure highly scalable architecture, strict functional boundaries dictate what RogueSwarms will and will not build.

Functions RogueSwarms SHOULD Implement

1. Decentralized Identity and Discovery Registry: A W3C Verifiable Credentials-based directory where agents register their DIDs, public keys, supported protocols (MCP, ACP), and endpoints8.

2. Attestation and Receipt Log: A high-throughput, append-only SCITT ledger that ingests COSE\_Sign1 signatures and emits verifiable cryptographic receipts for all state transitions20.

3. Protocol Routing Fabric: Standardized API gateways that facilitate secure message passing between agents utilizing diverse semantic protocols (e.g., translating ONDC/Beckn logistics updates into universal event schemas)22.

4. Verification Tooling: Open-source SDKs enabling agents to independently verify UCAN delegation chains, DPoP proofs, and AP2 mandate signatures offline46.

Functions RogueSwarms MUST EXPLICITLY NOT Implement

1. Payment Custody or Execution: The protocol must never hold fiat currency, process credit cards, or operate as a licensed money transmitter. Payment execution remains entirely between the AP2 mandates and the counterparties' chosen payment gateways1.

2. Merchant of Record / Seller of Record: The protocol must never take title to goods, define pricing, or generate the EN 16931 tax invoices. That is strictly the domain of the merchant agent1.

3. Escrow Services: RogueSwarms must not hold assets in escrow. If escrow is required, agents must utilize external, trustless smart contracts like ERC-818319.

4. Dispute Arbitration: RogueSwarms provides the irrefutable cryptographic evidence (receipts), but it must not act as a judge or adjudicate disagreements between counterparties.

13. MVP Roadmap

To systematically build the RogueSwarms network, development is phased to incrementally introduce complexity while proving the core security primitives.

Phase 1: Identity, Discovery, and the Registry (Months 1-3)

• Deploy the Agent Identity Registry utilizing W3C Verifiable Credentials (VCDM v2.0) and DIDs, providing the foundational layer for agent trust8.
• Implement MCP and UCP routing endpoints, allowing buyer agents to autonomously query merchant catalogs for structured product data4.
• Establish the baseline GS1 Digital Link resolution framework for unambiguous product identification31.

Phase 2: Secure Delegation, Quoting, and Schemas (Months 4-6)

• Integrate UCAN and OAuth RAR (RFC 9396\) infrastructure to enable principals to securely delegate capability tokens to their buyer agents38.
• Enforce DPoP (RFC 9449\) sender-constrained tokens across all network endpoints, mitigating the threat of credential exfiltration49.
• Enable UCP Quote generation, enforcing strict Peppol BIS Billing 3.0 / EN 16931 validation for international tax and pricing arithmetic24.

Phase 3: Mandates, Attestation, and the Ledger (Months 7-9)

• Launch the SCITT/COSE-based attestation log. Ensure all endpoints require and return RFC 9052 cryptographic signatures and receipts20.
• Deploy AP2 SDKs to allow buyer agents to generate Open and Closed Checkout and Payment Mandates, bound directly to the quotes5.
• Integrate compatibility with ACP to allow agents to seamlessly hand off approved AP2 mandates to external payment processors (e.g., Stripe) for final settlement1.

Phase 4: Multi-Hop Orchestration and Smart Contracts (Months 10-12)

• Enable complex multi-hop delegation chains with automated attenuation validation, solving the advanced Confused Deputy problem43.
• Implement support for tracking post-purchase ONDC/Beckn logistics events and partial fulfillment delta processing via the attestation log22.
• Deploy integration with the ERC-8183 Agentic Commerce smart contract standard for trustless, on-chain job escrow and Evaluator-based settlement26.

14. Current Primary Sources and Specifications Landscape

The RogueSwarms architecture avoids proprietary fragmentation by anchoring its design entirely on established and emerging global specifications. This synthesis of distinct protocols creates the unified fabric required for autonomous commerce:

• Agentic Commerce Protocol (ACP) & Agent Payments Protocol (AP2): Governs the generation of cryptographic mandates and the secure execution of checkouts without exposing the agent to MoR liability or sensitive PAN data1.
• Model Context Protocol (MCP) & Universal Commerce Protocol (UCP): Standardizes tool integration and provides the semantics for agent-to-catalog product discovery and cart assembly4.
• W3C Verifiable Credentials Data Model v2.0: The global standard for privacy-preserving, cryptographically verifiable identity, utilized for agent registration and capability claims8.
• IETF RFC 9396 (OAuth RAR), RFC 9449 (DPoP), & UCAN: The foundational security standards that enable fine-grained capability delegation, monotonic attenuation, and sender-constrained tokens to prevent Confused Deputy exploits across multi-hop agent chains38.
• EN 16931 & Peppol BIS Billing 3.0: The definitive European semantic standards required for universal electronic invoicing, strict arithmetic validation, and autonomous cross-border tax compliance24.
• GS1 Digital Link & UN/ECE Recommendation 20: The authoritative standards for structured URI-based product identification and canonical alphanumeric unit-of-measure codes31.
• IETF SCITT & RFC 9052 (COSE): The core frameworks for verifiable data structures and cryptographic receipts that power the RogueSwarms attestation log20.
• ERC-8183 & ERC-8004: Ethereum standards dictating trustless, smart-contract-based escrow, job evaluation, and on-chain agent reputation19.
• UNCITRAL Model Law on Automated Contracting (MLAC): The international legal baseline determining that contracts negotiated by automated agents are legally attributed to their human or corporate principals54.

Works cited

1. ACP (Agentic Commerce Protocol) Explained | Support \- Eco, https://eco.com/support/en/articles/14845478-acp-agentic-commerce-protocol-explained

2. The Complete Guide to Agentic Commerce & Payments, https://www.spreedly.com/guides/the-complete-guide-to-agentic-commerce-agentic-payments

3. EU AI Act Contracts: What the Law Requires (2026 Guide) \- Pactlio, https://www.pactlio.com/blog/eu-ai-act-contracts-guide

4. The Agentic Commerce Protocol Stack: UCP, ACP, AP2, MCP, A2A, https://joinhexagon.com/blogs/the-agentic-commerce-protocol-stack-ucp-acp-ap2-mcp-a2a-expl-mmi9c03u-hb1k

5. AP2 & the Agent Payments Protocol: What Enterprises Need to, https://www.mintmcp.com/blog/ap2-agent-payments-protocol

6. Protocol-Level Attacks on Agentic Commerce Platforms \- arXiv, https://arxiv.org/html/2607.21824v1

7. \[2607.21824\] Protocol-Level Attacks on Agentic Commerce Platforms, https://arxiv.org/abs/2607.21824

8. W3C Verifiable Credentials 2.0: The New Standard Reshaping, https://vidos.id/blog/w3c-verifiable-credentials-2-0-the-new-standard-reshaping-enterprise-digital-identity

9. The Decision Trust Protocol \- Mandate Labs, https://mandatelabs.ai/research/decision-trust-protocol

10. Agentic Commerce Protocol (ACP) Explained (What to Know), https://www.bigcommerce.com/blog/agentic-commerce-protocol/

11. Agentic commerce: an e-commerce guide \- NAXIA, https://www.naxiaglobal.com/blog/agentic-commerce-prepare-store-ai-shopping-agents/

12. What Is Agentic Commerce? | IBM, https://www.ibm.com/think/topics/agentic-commerce

13. What Is Agentic Commerce? Definition, How It Works & Why It Matters, https://rye.com/blog/agentic-commerce

14. yifeizhangcs/awesome-agentic-commerce \- GitHub, https://github.com/yifeizhangcs/awesome-agentic-commerce

15. What Is Agent-to-Agent (A2A) Commerce? | How AI ... \- Phemex, https://phemex.com/academy/what-is-agent-to-agent-commerce

16. Secure Agent Commerce with AP2 and UCP \- Codelabs, https://codelabs.developers.google.com/next26/adk-agent-commerce

17. AP2 Protocol Explained: How Agent Payments Get Authorized, https://dodopayments.com/blogs/ap2-protocol-agent-payments

18. Whisper Attacks and a Binding Defense for AP2 \- arXiv, https://arxiv.org/html/2609.11757v1

19. ERC-8183: A dummies guide to the Agentic Commerce, https://www.decipherclub.com/erc-8183-a-dummies-guide-to-the-agentic-commerce/

20. RFC 9943: An Architecture for Trustworthy and Transparent Digital, https://www.rfc-editor.org/info/rfc9943/

21. RFC 9052: CBOR Object Signing and Encryption (COSE) \- RFC Editor, https://www.rfc-editor.org/info/rfc9052/

22. ONDC Architecture Overview | PDF | Computer Network \- Scribd, https://www.scribd.com/document/914432478/ONDC-s-Open-Network-Model-and-Architecture

23. ONDC: Technical Architecture behind a Decentralized Network, https://floydee.com/ondc-technical-architecture-behind-a-decentralized-network/

24. UBL Invoice Format: Free XML Examples & Field Reference \[2026\], https://e-invoice.be/blog/ubl-format-guide

25. EN 16931 in Plain English: What an EU E-Invoice Needs \- Facturwise, https://www.facturwise.com/en/blog/en-16931-eu-e-invoicing-standard-explained

26. ERC-8183 Explained: The Commerce Layer for AI Agents \- Dwellir, https://www.dwellir.com/blog/erc-8183-agentic-commerce-explained

27. What Is ERC-8183 and Why It Matters for AI Agents in Crypto \- Phemex, https://phemex.com/academy/erc-8183-ai-agents-crypto

28. Verifiable Credentials Data Model v2.0 \- W3C, https://www.w3.org/TR/vc-data-model-2.0/

29. AP2 \- Agent Payments Protocol Documentation, https://ap2-protocol.org/

30. A Formal Analysis of Agent Payment Protocols \- arXiv, https://arxiv.org/html/2609.00060v1

31. GS1 Digital Link & DPP — How the Standard Works, https://dpp-tool.com/en/guide/gs1-digital-link/

32. European standard EN 16931 Specifications for basic e-invoice, https://www.tatime.gov.al/shkarko.php?id=13417

33. EN 16931 E-Invoice Specifications | PDF \- Scribd, https://www.scribd.com/document/603020412/European-standard-EN-16931-UBL-2-1-1

34. E-Rechnung mit CODE.3 ERP \- ibeq, https://www.ibeq.com/code3-user-e-rechnung/

35. BIS Billing 3.0, https://peppol-docs.agid.gov.it/docs/docs/ENG/invoice/guide/bis/main.html

36. Peppol BIS Billing, https://docs.peppol.eu/poacc/billing/3.0/bis/

37. Singapore Peppol BIS Billing Guide, https://www.peppolguide.sg/billing/bis/

38. User Controlled Authorization Network (UCAN) Specification · GitHub, https://github.com/ucan-wg/spec

39. ucan-storage \- GitHub Pages, https://nftstorage.github.io/ucan.storage/

40. SCITT as the Article 12 Implementation Pattern for Autonomous AI, https://agledger.ai/blog/scitt-article-12-ai-agents/

41. Privilege Escalation | Bohrium, https://www.bohrium.com/en/sciencepedia/feynman/keyword/privilege\_escalation

42. Flowing Authority: Introducing Tenuo \- Vectors, https://niyikiza.com/posts/tenuo-launch/

43. AI agents and the multi-hop delegation problem \- WorkOS, https://workos.com/blog/oauth-multi-hop-delegation-ai-agents

44. Multi-Hop Agent Delegation Chains: Identity Propagation Across, https://www.scrambleid.com/learn/multi-hop-agent-delegation-chains

45. UCAN \- User Controlled Authorization Network, https://ucan.xyz/

46. draft-niyikiza-oauth-attenuating-agent-tokens-01 \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/

47. OAuth Scopes for AI Agents: How to Design Permissions in ... \- SSOJet, https://ssojet.com/blog/oauth-scopes-ai-agents-permission-design-agentic-applications

48. Support Rich Authorization Requests for OAuth \- RFC 9396 \#1670, https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1670

49. Demonstrating Proof of Possession (DPoP) \- Thales Docs, https://www.thalesdocs.com/oip/idaas-core/idaas-core-access/oidc/dpop/index.html

50. The DPoP Storage Paradox: Why Browser-Based Proof-of ... \- InfoQ, https://www.infoq.com/articles/dpop-key-storage-unsolved-problem/

51. Demonstrating Proof of Possession (DPoP) in the AuthPlayground, https://developer.pingidentity.com/identity-for-ai/protocols/authplayground-dpop.html

52. Demonstrating Proof-of-Possession (DPoP) \- Auth0 Docs, https://auth0.com/docs/secure/sender-constraining/demonstrating-proof-of-possession-dpop

53. In-Depth Analysis of Google's Agent Payments Protocol AP2, https://agent-network-protocol.com/blogs/posts/google-ap2-analysis

54. UNCITRAL-ELI Project on Model Contractual Terms on Automated, https://www.europeanlawinstitute.eu/projects-instruments/current-projects/current-projects/uncitral-eli-project-on-model-contractual-terms-on-automated-contracting/

55. The Contract Nobody Signed: AI Agents and the Limits of Agency Law, https://heckelai.com/the-contract-nobody-signed-ai-agents-and-the-limits-of-agency-law/

56. Can AI autonomously conclude a binding contract? \- Timelex, https://www.timelex.eu/en/blog/can-ai-autonomously-conclude-binding-contract

57. General Assembly, https://uncitral.un.org/sites/default/files/2026-05/a-cn.9-12631\_0.pdf

58. What Is AI Liability in the Agentic Economy? Why Someone Must Be, https://www.mindstudio.ai/blog/ai-liability-agentic-economy

59. High-level summary of the AI Act | EU Artificial Intelligence Act, https://artificialintelligenceact.eu/high-level-summary/

60. AP2 (Agent Payments Protocol) Explained | Support \- Eco, https://eco.com/support/en/articles/14845479-ap2-agent-payments-protocol-explained

61. What is ERC-8183? New Commerce Layer for AI Agents Explained, https://www.quicknode.com/blog/erc-8183-agentic-commerce

62. ERC-8183: The Standard That Lets AI Agents Hire Each Other, https://blockeden.xyz/blog/2026/03/10/erc-8183-agentic-commerce-standard-ai-agent-transaction-stack/

63. Agentic Commerce Protocol \- Stripe Documentation, https://docs.stripe.com/agentic-commerce/acp