Proposal: BCP as an x402 scheme for multi-step negotiated commerce

[lucidedev]

Summary

I've built BCP (Business Commerce Protocol) — an open-source protocol for multi-step B2B commerce between AI agents. BCP uses x402 as its settlement layer and I wanted to share how the two protocols fit together, and explore whether there's interest in tighter integration.

How BCP uses x402

x402 handles single payments beautifully — agent requests a resource, gets a 402, pays, done. BCP extends this for transactions that need negotiation and escrow before settlement:

INTENT → QUOTE → (COUNTER) → COMMIT → FULFIL
                                 │
                          USDC locked in escrow
                          (released via x402 on FULFIL)

The settlement step in BCP's COMMIT → FULFIL flow uses x402 for the actual payment movement. BCP handles the negotiation lifecycle and escrow logic; x402 handles the money.

Potential integration points

1. x402 middleware for BCP escrow release — When a BCP deal reaches FULFIL, the escrow release could flow through x402's payment scheme rather than a direct contract call. This would make BCP settlement compatible with any x402 facilitator.

2. BCP as an x402 scheme — A bcp-escrow payment scheme where the 402 response includes BCP negotiation metadata (session ID, escrow contract address, expected message sequence). The client negotiates via BCP messages, and the final payment is an x402 payment with escrow proof attached.

3. Example in x402's examples directory — A reference implementation showing x402 + BCP working together for a negotiated, escrowed transaction.

What BCP provides

• 6 typed messages: Intent, Quote, Counter, Commit, Fulfil, Dispute
• Ed25519 signatures on every message
• On-chain USDC escrow (Base / Base Sepolia)
• TypeScript SDK: npm install @bcp-protocol/sdk
• Apache 2.0 licensed

Happy to contribute an integration example or explore the scheme approach if there's interest.

Repo: https://github.com/lucidedev/bcp-protocol

[aeoess]

The INTENT → QUOTE → COUNTER → COMMIT → FULFIL lifecycle maps directly to governance-scoped commerce.

The gap in single-step x402 payments is authorization: the agent pays because it can, not because it should. With multi-step negotiation, each stage is a separate authorization decision. An agent might be authorized to INTENT and QUOTE but not COMMIT without human approval. The escrow lock at COMMIT is the irreversible primitive — that's where governance enforcement matters most.

We've been running delegated commerce governance on x402 that fits your lifecycle:

INTENT  → gateway evaluates: scope includes commerce:negotiate? ✓ permit
QUOTE   → gateway evaluates: quoted amount within spendLimit? ✓ permit  
COMMIT  → gateway evaluates: escrow amount within remaining budget?
           agent type authorized for escrow? ✓ permit (or escalate for human approval)
FULFIL  → gateway evaluates: escrow release matches committed terms? ✓ permit

Each step produces an Ed25519-signed receipt. The receipt chain proves the full negotiation was authorized at every stage, not just the final settlement. If an agent tries to COMMIT $5000 when its delegation only allows $500, the gateway denies at COMMIT — before USDC is locked, not after.

The BCP message signatures and APS governance receipts are complementary: BCP proves both parties agreed to the terms, APS proves the agent was authorized to agree. An auditor checking the transaction sees both layers without trusting either party.

On integration point #2 (BCP as an x402 scheme): the bcp-escrow payment scheme could carry an APS delegation_ref in the 402 metadata. The client includes the delegation reference in its COMMIT message, the escrow contract (or facilitator) can verify the agent's authorization scope before locking funds. No governance? No escrow.

Governance flow for x402 payments: https://gist.github.com/aeoess/31cf90df8f3b4a1cae42988a7de5913f
SDK: npm install agent-passport-system (v1.36.4).

[lucidedev]

Thanks for the thoughtful mapping — the idea of treating each BCP stage as a separate authorization checkpoint is something we've been thinking about too. We're shipping v0.2 with pluggable auth modes so a governance layer like yours could compose on top without locking into any single identity stack.

[aeoess]

@lucidedev — pluggable auth modes in v0.2 is the right architecture. When it ships, I'll build the APS adapter for the auth hook. The integration surface should be small: BCP calls the governance layer before COMMIT with the negotiated terms, gets back permit/deny + signed receipt, and includes the receipt reference in the COMMIT message. The escrow contract (or counterparty) can verify the receipt independently.

If you publish the auth mode interface before v0.2 lands, I can have the adapter ready for launch day.

[kevinkaylie]

BCP multi-step commerce settled over x402 fits naturally with did:agentnexus as the identity layer.

Why:

• BCP agents need verifiable identities that persist across sessions and platforms — did:agentnexus:z<multikey> is exactly that (Ed25519 key, no central registry, resolves to W3C DID Document)
• Multi-step commerce requires delegation scoping: agent A delegates to agent B for a specific scope with a spend limit — Enclave v0.9.5 enforces this with monotonic narrowing and signed receipts
• Settlement receipts can anchor to the agent DID — audit trail is tied to the cryptographic identity

Integration point:
At each BCP negotiation step, the agents present their did:agentnexus. The receiving agent resolves it via https://relay.agentnexus.top/resolve/{did} and verifies the Ed25519 signature. If delegation is involved, Enclave validates the delegation chain before proceeding.

Repo: https://github.com/kevinkaylie/AgentNexus — Enclave ADR: docs/ADR-013.md