Make the network more useful rather than competing to own it.
FromMarketplace→ToNeighbourhood commercial operating layer
ONDC already provides the rails. The opportunity is the intelligence and operating discipline above them. That layer only stays open if the business model doesn’t quietly turn it back into a marketplace, so this last shift decides whether the other eight survive.
Isn’t this what ONDC does?
Partly, yes, and that is good news: no new commerce rail is needed. What matters is separating what the rails provide from what still has to be built above them.
ONDC is a network rather than an app or marketplace. Its handbook calls it a non-platform digital commons and describes a stack of three layers: a protocol layer (the Beckn protocol and ONDC’s API specifications, contextualised to domains), a network layer and an app layer that participants build[1]. The same handbook describes operational infrastructure for search and discovery, including the registry and the gateways, and ecosystem participants such as reconciliation service providers and online dispute resolution providers, who help move funds between participants and resolve disputes[1]. ONDC’s FY 2025–26 report adds that it aims to enable verifiable financial identities[2]. The machinery to discover, transact and fulfil increasingly exists. The question changes from how do we build an open commerce network? to what should we build on top of it?
The evidence review lists what the network does not solve by itself. It doesn’t ensure that a merchant’s data is complete and current, or that a service capability is machine-readable. It doesn’t settle how ranking can work without recreating a gatekeeper, or whether a buyer will trust an unknown local provider. It doesn’t decide who owns service quality and grievances, or whether merchant economics survive fulfilment and support costs.
Don’t rebuild the rails. Build the intelligence above the rails.
The operating layer, assembled
The last arrow matters most: trust leads to more discovery. Every completed transaction can make the network better. The network doesn’t merely digitise supply; it manufactures evidence around supply that was previously invisible.
| Layer | Responsibility |
|---|---|
| Consumer interface | Understand the person’s mission |
| AI agent | Translate intent into constraints |
| Capability graph | Find relevant commercial capabilities |
| Trust layer | Establish whether those capabilities are credible |
| Narrative layer | Help the person understand the provider |
| ONDC / Beckn | Discover, contract and transact across participants |
| Logistics network | Move goods and support fulfilment |
| Merchant or node | Actually solve the customer’s problem |
The marketplace trap, and who pays
Listings plus search plus ranking plus commission plus delivery add up to a marketplace, even on open rails. The review notes that an app can run on open infrastructure and still become a dominant gatekeeper. The slide is familiar: first the providers get ranked, then listings get sponsored, then the top providers get guaranteed, then a 20% commission appears, and the result is another marketplace.
Who pays? This is the most important unresolved question in the series, because it decides whether the layer drifts. There are four candidate models, and each funds a different product and carries a different drift risk. The first is a transaction-linked fee from the merchant. On ONDC, a buyer app’s native income is the buyer finder fee, a share of order value that varies by app and category and can be passed to the buyer as a convenience fee[8, 9]. Structurally, it is a commission by another name. The second is a merchant subscription for workflow tools such as representation, quoting and scheduling. The third is a buyer-side fee for concierge service or assurance on high-ticket missions. The fourth is a brand-side fee for node enablement. The choice belongs in the pilot plan, stated in advance.
The thesis
The next layer of open commerce may not be another marketplace. It may be an intelligence and coordination layer that makes the distributed commercial capabilities of a locality discoverable, trustworthy and transactable. Instead of concentrating inventory to manufacture digital availability, the network can try to aggregate demand against distributed capability.
AI translates human intent. A capability graph finds who can solve it. Trust establishes why they deserve consideration. Narrative lets the consumer meet the people and businesses behind the capability. Open commerce provides the transaction fabric. Distributed fulfilment turns the transaction into a physical outcome. And every completed transaction creates new evidence for the network. The evidence review reached a closely matching formulation: open commerce becomes the transaction and interoperability layer for a digital neighbourhood economy, while agentic intent understanding and narrative interfaces become the discovery and trust-building layer.
That is where the series ends. Not with we have proved the future, but with a narrower claim: we have identified a new architecture and established the evidence that makes it plausible, separated what is already commoditised, isolated the genuine whitespace, and defined the tests that can prove or kill it.
The neighbourhood doesn’t need another warehouse. It needs an interface to the commercial capability that already exists there.
Go deeper
What the rails already provide
On the buyer side, ONDC’s own description gives buyer apps the job of parsing searches, matching them across the network, ranking results, aggregating catalogues, supporting multi-seller carts and completing checkout[3]. On the seller side, seller apps onboard merchants and digitise their catalogues[4]. Underneath sits Beckn’s core API, a domain-agnostic lifecycle of search, select, init, confirm, status, track, update, cancel, rating and support[5]. Beckn has been specified for mobility, health, and work-and-learning networks as well as retail[6, 7]. ONDC reports 218 million transactions enabled in FY 2025–26, a self-reported figure[2].
The whitespace, and how it could close
The review identifies the likely openings: capturing merchant capability through voice, photos and assisted workflows; an agent that asks useful clarifying questions instead of only matching keywords; trust filters that users choose, with explanations; narrative and video surfaces for local providers; a locality-level supply graph that includes services and specialists; measuring completeness rather than seller counts; and human escalation for ambiguous or high-risk tasks.
Two cautions belong here. First, this whitespace may close. ONDC is already building its own AI direction (Shift 3). If it or a large buyer app ships capability-level discovery for services, what remains is merchant representation, trust evidence and locality completeness. Those are operating moats rather than technology moats, so the plan should assume the technology commoditises and the operating discipline doesn’t. Second, it is untested whether ONDC’s current domain specifications and buyer apps handle quotes, appointments and custom work well enough (Shift 8).
Merchant and consumer economics
The CSEP 2026 report cites estimates in the industry that sellers’ commissions, including marketplace commission and transaction fee, comprise anywhere from 15% to 25% of the item value, rising further with sponsored listings and discounts. It also notes that small merchants without adequate access to formal finance face longer settlement periods and higher return rates[10]. These are broad estimates, not an ONDC fee schedule, but the implication is clear. A product that monetises through price competition, paid ranking and delivery charges would recreate the economics merchants already dislike.
Merchants won’t join to “digitise.” They’ll join for profitable demand they couldn’t reach efficiently themselves. The review’s merchant proposition combines qualified local demand, reusable identity and capability data, low-cost assisted content, repeat customer relationships, transparent reputation, access to several buyer apps, and workflow tools for quotes, appointments, inventory, payments and fulfilment. A merchant with fewer, better-fit jobs may be better off than one flooded with price shoppers.
Consumers need a reason too. For local services the real incumbents are WhatsApp and word of mouth, alongside Google Maps, Instagram, YouTube, marketplaces and quick-commerce apps. The proposition has to be something like tell us what you’re trying to accomplish, and we’ll assemble the relevant commercial world around you. Until repeat-usage and completion data say otherwise, that is a promise, not evidence.
Structural defences, and what not to build
The review names six structural defences against drift: capability-first representation, user-controlled fit, narrative evidence, portable trust, open fulfilment choices, and metrics measured at the node level rather than in orders and sellers. Four operating rules make them concrete: no paid placement in shortlists, a published shortlist rule, exportable merchant data, and presence on more than one buyer app.
The first product should not be another local marketplace, so no onboarding of 100,000 merchants. It should not be another catalogue app that asks merchants to maintain thousands of SKUs, or another delivery fleet. It should not be another social network, because video is discovery evidence, not the business model. It should not be another price-comparison engine. And it should not be a universal AI shopping assistant, since the first mission has to be narrow enough to measure.
Ten ways this breaks
This list merges the risks in the original outline, the problems in the section drafts and the evidence review’s falsifiable risks. Each is tested in the shift noted.
| Failure mode | How it breaks the thesis | Tested in |
|---|---|---|
| 1. Representation cost | Merchant data and content cost more than the demand is worth | Shift 2 |
| 2. Supply quality | Plenty of businesses, little verifiable capability | Shifts 2 and 7 |
| 3. Demand density | Discoverable specialists receive too few qualified requests | Shift 1 |
| 4. Trust transfer | Users trust the app but not unfamiliar providers | Shift 6 |
| 5. Price compression | Comparison trains users to chase the cheapest quote | Shift 5 |
| 6. Coordination | Multi-party jobs fail at handoffs, with no clear owner | Shift 8 |
| 7. Agent error | Misread local-language requests; overstated capability | Shift 3 |
| 8. Narrative bias and video fatigue | Better videos beat better providers, or users skip video | Shifts 4 and 6 |
| 9. Marketplace drift | Ranking, paid placement and commission creep back in | Shift 9 |
| 10. Unit economics | Coordination cost exceeds the value created | Shifts 1 and 9 |
The equation and the kill test
Incremental commercial value created − (representation + discovery + coordination + fulfilment + trust + support) = positive contribution
If that doesn’t hold, the architecture is intellectually interesting and commercially weak. If it holds without centralised inventory, it is consequential.
| Kill-test question | Answered in |
|---|---|
| Can we discover capability that catalogues cannot? | Shifts 2 and 3 |
| Can we represent that capability cheaply and accurately enough? | Shift 2 |
| Can consumers find and trust it better than existing alternatives? | Shifts 4, 5 and 6 |
| Can distributed fulfilment complete missions reliably? | Shift 8 |
| Does the whole system generate positive contribution? | Shifts 1 and 9 |
If all five answers become yes, this is not another local marketplace but a different architecture for open commerce. If they don’t, the review’s warning applies: the product collapses into a costly lead-generation marketplace with more content and more operational complexity.
What could go wrong
- Drift.Ranking, paid placement and commission creep back in once the business needs revenue.
- Whitespace closes.ONDC or a large buyer app ships capability-level discovery for services first.
- Unit economics.Coordination cost exceeds the value created.
How we’d test it
Revenue depends on placement, merchants can’t take their data elsewhere, or contribution stays negative across the pilot.
| The test | What we would measure | What would end the idea |
|---|---|---|
| Marketplace drift | Share of revenue from placement; ranking transparency; merchant data portability; number of buyer channels | Revenue depends on placement, or merchants can’t take their data elsewhere |
| Unit economics | Mission completion cost against contribution per mission, by revenue model | Contribution stays negative across the pilot |
How strong is the evidence?
- Established
- ONDC’s architecture and components exist (scale figures self-reported); Beckn’s lifecycle is domain-agnostic; ONDC buyer apps earn a buyer finder fee; sellers face high fees on existing platforms (industry estimates).
- Evidence-supported
- An app on open rails can still become a gatekeeper.
- Hypothesis
- An operating layer above the rails can reach positive contribution without drifting into a marketplace.
- Unknown
- Who pays, how quickly the whitespace closes, and whether contribution turns positive.
Sources
- [1]Aapti Institute and ONDC, Handbook on Building Open NetworksChecked
- [2]ONDC, FY 2025–26 in FocusChecked
- [3]ONDC, Buyer Network ParticipantsChecked
- [4]ONDC, Roles you can playChecked earlier; the page did not load on our second check
- [5]Beckn Protocol, Core transaction API specificationChecked
- [6]Beckn Protocol, Protocol specifications repositoryChecked; its version table links the mobility, food and beverage and healthcare specifications
- [7]ONEST Network, Beckn specification for work opportunitiesChecked
- [8]MediaNama, ONDC explained: commissions, search rankings and ratings (2022)Checked
- [9]Vikra, Buyer app fee on the ONDC NetworkChecked
- [10]CSEP, India E-Commerce Report 2026Checked (pp. 28 and 52)
Spotted a source we missed or a rule we misread? Tell us what we got wrong.