Zero Density Roadmap
Public protocol roadmap. We do not tie the lifting of protective mechanisms to calendar dates. We tie them to measurable network-density metrics β so the protocol does not open before the market can self-regulate, and we do not stay in defense mode longer than necessary.
Source on GitHub: ZERO_DENSITY_ROADMAP.md.
Product path (storefront β BYOM β federation): A2A Protocol Roadmap.
Last updated: August 2026 Β· Status: public v1
How this document works
Each phase is a set of metric triggers. While metrics are not met, protective limits stay on: rate limits, negotiation noise, manual seller moderation. When a phaseβs metrics are met, we remove specific limits and move forward.
Future phase thresholds (15 sellers, 100 sellers, etc.) are policy targets, not automated feature flags in code today.
Phase 0 β Phase 1: Escaping zero density
Phase problem: the network is too thin to self-regulate. Buyer agents have nothing to compare prices against, and an attacker can relatively easily probe floor_price because defense relies only on technical limits.
Transition metrics
| Metric | Threshold | Why |
|---|---|---|
| Active sellers in one product category | β₯ 15β20 | Not total shop count β density inside a vertical. Fifty shops in different niches do not create competition. |
| Independent inbound offers per seller per week | β₯ 3 (excluding test/internal bots) | Signal of organic demand, not internal testing only. |
| Median negotiation rounds per deal | β€ 4β5 | Fast closes mean prices are adequate and aggressive brute-force is absent. |
What unlocks
- Softer rate limits for authenticated / verified agents (anonymous traffic stays under strict limits)
- Negotiation noise unchanged β density is still too low for price-comparison self-regulation
Phase 1 β Phase 2: Partial protocol trust
Phase problem: the network can show something, but remains vulnerable to manipulation when sellers and buyers are still imbalanced.
Transition metrics
| Metric | Threshold | Why |
|---|---|---|
| Active sellers with category overlap | β₯ 100 sellers in β₯ 5 categories | A buyer can compare 3β5 offers inside Mixlink without leaving the web. |
| Share of deals citing a competitor price (in-network or via web search) | β₯ 30% | Shows market self-regulation works in practice, not only in theory. |
| Ratio of unique buyer agents to sellers | β₯ 2:1 | If buyers are fewer than sellers, the network is one-sided β lowering floor_price defense is premature. |
| Share of sessions with >10 repeat offers from one fingerprint without purchase | < 5% | Low share means no mass brute-force β noise can be relaxed. |
What unlocks
- Lower noise intensity in
counter_offer(responses become more βhonestβ) - Higher default rate limits
- Partial API openness without strict manual moderation for new sellers
Phase 2 β Phase 3: Protocol-native trust (network effects)
Phase problem: move from artificial technical limits to an organic reputation model.
Transition metrics
| Metric | Threshold | Why |
|---|---|---|
| Sellers in top-3 categories | β₯ 500, β₯ 5 independent offers per typical query | Full market competition inside the protocol. |
| Share of fully autonomous deals (no manual seller intervention) | β₯ 50% | Shows automation maturity and business trust in the system. |
What unlocks
- Gradual removal of artificial protections (noise, strict rate limits)
- Shift to reputation-based trust β agent deal history instead of technical caps
Go-to-market: split the pitch
Density metrics govern the protocol. Network growth still starts with sales β and the two audiences need different language.
| Audience | What we sell | Language |
|---|---|---|
| Reddit, HN, GitHub (developers) | Protocol: A2A, llms.txt, decentralization, pushback on Web2 monopolies | Ideology + technical base |
| First 50β500 shops (SaaS clients) | AI widget: live in 5 minutes, works in WhatsApp, closes with discounts inside margin, lifts conversion | Product and numbers only β no A2A/MCP/protocol talk |
Same engine underneath. Different packaging per audience.
Implemented protective mechanisms (Active in Phase 0)
To protect sellers and prevent protocol exploitation before Phase 1 network density is reached, the following safeguards are already built into the Mixlink core:
- Cost-based Floor Price Guardrail (Loss protection):
- Cost (cost_price) is required when creating a product through the main shop API. - Minimum price (floor_price) is automatically calculated as cost_price * 1.2 (20% markup). - At the API and database level (CHECK constraint), it is physically impossible to save or accept a deal with floor_price < cost_price.
- Session Floor Noise (Oracle attack and brute-force protection):
- To prevent bots from computing the minimum price, stochastic noise is applied (30% probability, 5β20% spread from margin). - The session_floor_price value is cached in Redis per (session_id, product_id) and never exposed in public HTTP responses (along with true_floor_price, cost_price, and floor_price). - When an offer is below session_floor_price, the engine returns a counter with is_final_offer: true (βtoday's best discountβ). - is_final_offer is a session-scoped negotiation signal, not disclosure of the merchant's true minimum. Order acceptance and checkout are validated against true_floor_price β never below the real floor.
- Offer Rate Limits (Brute-force protection):
- Sliding-window limits on public negotiate endpoints per product and client IP (default: 5 offers/minute via MIXLINK_NEGOTIATE_OFFERS_PER_MINUTE). - Separate limits on discovery and MCP traffic slow automated floor probing without blocking normal buyers.