The landscape of autonomous trade is rapidly evolving: Stripe has launched its Agentic Commerce Suite, Shopify and Google are co-developing the Universal Commerce Protocol (UCP), and Pine Labs is collaborating with OpenAI to engineer agentic commerce in India.
As AI agents begin to conduct business autonomously (buying ad space, renting compute power, or sourcing data), they hit a fundamental barrier. Traditional payment systems (like Stripe) and cloud platforms are built for humans. They are:
- Too Slow: Traditional settlement takes days; agentic commerce needs milliseconds.
- Too Expensive: Fixed fees and "platform taxes" (3-30%) eat micro-transaction margins.
- Too Centralized: Reliance on central intermediaries creates bottlenecks and single points of failure.
Nexus is a "headless" coordination and clearing layer that allows AI agents to negotiate and settle deals directly with each other in under 30 milliseconds with zero middleman fees.
It is built on top of Tashi Vertex, a leaderless coordination engine that provides the "mathematical handshake" needed for machines to trust each other without a central bank or boss.
A lightweight Rust library that developers plug into their AI agents. It provides:
- Agent Identity — Ed25519 keypairs for each agent, with
AgentIdderived from the public key. Mandates define spending limits (max_bid,daily_spend_cap) and trust thresholds. - Consensus Engine Abstraction — A
ConsensusEnginetrait for ordering bids; currently backed bySimulatedEngine, which mimics Vertex's ~26ms BFT window with fair timestamp-based ordering. - Auction Resolution —
resolve_auctionfilters bids by trust score, picks the highest valid bid, and produces aDealwith latency metadata. - Clearing House — In-memory netting ledger that accumulates deals between agent pairs and emits
Settlementrecords when a configurable threshold is reached, reducing payment friction.
A dashboard for business owners to oversee their autonomous workforce:
- Mandate Control: Set the "rules of the game" for your agents.
- Real-Time Clearing: View a live feed of finalized deals and "Proof of Coordination" receipts.
- Batch Settlement: Instead of paying for every tiny deal, the platform "batches" thousands of micro-transactions into a single final payment at the end of the day.
- Reclaim Margins: Eliminate the 3–30% "Platform Tax" taken by centralized marketplaces.
- Machine-Scale Economics: Enable new business models based on millions micro transactions.
Nexus is the "Visa for the Agentic Web." We aren't building a single store; we are building the infrastructure that allows every AI agent on earth to trade value as fast as they trade information.
| Component | Description |
|---|---|
| nexus-sdk | Provides two variants: - vertex (Rust): Uses tashi-vertex to provide BFT consensus window, Ed25519 identity, auction and clearing house.- foxmq (Python): Uses paho-mqtt to connect to a decentralized FoxMQ broker, leveraging its mathematically fair ordering and global message distribution underneath standard MQTT abstractions. |
| nexus-demo | Sandbox simulations using the SDK end-to-end to run ad auctions every 50ms, stream events over WebSocket, and handle stress commands. Exists in two variants: - vertex (Rust): Direct Tashi Vertex integration.- foxmq (Python): asyncio simulation interacting over FoxMQ. |
| dashboard | Svelte web app that connects to the demo's WebSocket (on port 3001). Shows live mesh topology (agent nodes and deal edges), metrics (TPS, latency, deals, settlements), transaction feed, agent panel, and simulation controls. |
You can run either the Rust-based Vertex integration or the Python-based FoxMQ abstraction. Both connect to the same web dashboard.
This version runs the consensus layer directly in-process via tashi-vertex-rs.
- Start the Demo (Terminal 1)
cargo run --bin nexus-demo- Start the Dashboard (Terminal 2)
cd dashboard
npm install
npm run devFoxMQ acts as a decentralized MQTT 5.0 broker that abstracts away Tashi Vertex.
- Start the FoxMQ Broker (Terminal 1) Follow setup from FoxMQ docs to start a local node:
# Download FoxMQ binary & generate keys
./foxmq address-book from-range 127.0.0.1 19793 19793
./foxmq user add --write-mode truncate
./foxmq run --secret-key-file=foxmq.d/key_0.pem --allow-anonymous-login- Run the Demo (Terminal 2)
cd nexus-demo/foxmq
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
python main.py- Start the Dashboard (Terminal 3)
cd dashboard
npm install
npm run devThe SDK is currently a prototype suitable for demos and local simulation. To reach production:
| Area | Status | Pending |
|---|---|---|
| Vertex Integration | ConsensusEngine trait exists; only SimulatedEngine implemented |
Implement a real Vertex client backend so agents can participate in a live BFT network instead of in-process simulation |
| Cryptographic Attestation | Agents have Ed25519 keys; signing keys are unused | Sign bids and deals so counterparties can verify authenticity; add verification on settlement |
| Persistence | ClearingHouse is in-memory only |
Durable ledger (e.g. SQLite or append-only log) for crash recovery and audit trail |
| Wire Protocol | None; demo uses in-process calls | Define and implement a network protocol (e.g. WebSocket or gRPC) for agents to communicate across processes |
| Asset Types | Ad-specific (AdSlot, Bid) |
Generalize to generic asset/order types (e.g. ComputeSlot, DataSlot) for Energy, Data, Compute |
| Settlement Execution | Settlement records produced but not executed |
Integrate with payment rails (on-chain or fiat) to actually move value |
| Key Management | Keys generated on creation; no persistence | Key derivation, secure storage, backup, and recovery for production deployments |
| Precision | f64 for amounts |
Use fixed-point or decimal types for money to avoid precision errors |
| API Surface | Low-level modules; manual wiring | High-level client API that abstracts engine, handshake, and clearing into a single flow |