Thoughts on building and scaling commerce networks (like ONDC) in the IndiaStack

The IndiaStack is working. Amazingly well. The image below outlines the base primitives of the IndiaStack.

I’m interested to explore the GoI’s vision of building commerce market protocols like ONDC on top of this stack. GoI posits that different markets, like education (eShiksha), healthcare, etc. can be built on top of these primitives. Perhaps more traditional markets B2B commodities trade too.

This would be amazing, but I believe that building marketplace protocols need to take a fundamentally design different approach from how the base primitives were created, for 3 reasons:

1. Primary stakeholders are are private sector businesses; control & censorship by any centralized party other than the regulator must be impossible.

2. Incentives for bad actors are strong because it could lead to direct monetary benefit. Protocol design must account for negative externalities.

3. Scale of compute & storage grows significantly faster due to the increased number of network participants personas, number of actions possible per participant and metadata per member/action.

Roadblocks to Scale

The existing ONDC architecture is a set of APIs created & hosted by a single centralized not-for-profit entity. Sellers and catalogs are public but order flow is private and hosted on the buyer & seller apps. This gives rise to some points of contention & potential scale issues:

1. Corruption With a centralized entity handling all order flow, bad actors can influence factors like reputation, transaction ordering, etc. in their favor either through sophisticated cyber attacks or social engineering. The centralized entity also has enforce-able power to interfere with the free-market according to their own ideologies even if supply/demand is operating under perfectly legal conditions.

2. Single point of failure Security vulnerabilities or network outages could disrupt commerce across the country. Since this is a protocol co-ordinating commerce, this could have a direct effect on people’s livelihood, unlike an attack on a bank can theoretically be reversed or lead to less direct effect like a data leak. 

3. Scalability Given that vision is to add multiple commerce markets, we’d need to minimize infra redundancy, economically feasible infra that scales infinitely, maintain composability so that these markets can talk to each other and manage data availability so that the large amount of metadata is indexable and accessible at acceptable speeds meeting great UX standards.

4. Pricing monopoly The protocol is a public good but transaction fees go to a centralized entity. The entity first collects fees to breakeven on its costs, but over time as it gains market share, it is incentivized increase fees and decrease transparency for insider benefit.

5. Opaque order flow Keeping order flow data on the buyer and seller apps doesn’t solve the problem of anti-competitive practices where large players build their own brands and undercut their suppliers. Order flow needs to be open-sourced so that market intelligence is available to all.

Re-Thinking Protocol Design

I believe that the protocol must be built on a PoS public & permissionless blockchain with INR CBDC as the native token. Our goal is high throughput & scalability with moderate decentralization and security.

Validator Network

• In typical PoS fashion, we have a set of validators who put up a stake of INR CBDC that’s subject to slashing should they make any malicious attempts against the network (or not maintain required up-time). Validators will be anonymous, spread throughout the country and run the consensus code on their own servers.

• Validators earn the transaction fees for securing the protocol.

• Individuals like you & me can delegate our own stake in INR CBDC via DVT as “solo stakers” and also earn a share of the network profits.

Settlement

• Here, we aim to track all actions undertaken by a general commerce market to keep a track of every action taken by every network participant.

• Every action is tracked by a transaction on the blockchain, which can be segmented into different types denoting various types actions taken by network participants. Like order creation, payment, refund, order dispatch, order collection etc. each having different data structures.

• This is permissionlessly readable by anyone via a block explorer.

• Every time a block is created, the transaction fees is earned by the validators in INR CBDC.

Commerce Protocols

• Here’s where custom architecture of different networks like ONDC, eShiksha begins.

• Membership registries of various network participants are maintained at this level.

• Since each protocol needs to be decentralized, and also accrues individual fees, validators can re-stake the same initial deposit to secure each individual network.

• Validators would need to run different software for each network and will be subject to potentially different slashing conditions, but as long as they do their job right, they can earn the transaction fees from each network they participate in.

Transaction

• As part of the transaction data, we allow all base primitives in the IndiaStack to post attestations of their own records.

• For eg: If a UPI payment has been completed from A → B, the transaction attestation can be posted to the block with a special hash the obscured the identity of A & B which can be decoded only by related parties (potentially the buyer and seller apps that facilitated this transaction)

• All transactions (and hence order flow) are visible to the public via the “mempool”. Although sensitive information would be hashed, market intelligence would be effectively open-sourced. Another alternative could be that the mempool is not public and market intelligence can be sold in the private market by validators.

• Transactions are rolled up and sent to the base settlement layer.

Smart Contracts

• An implementation of the APIs currently being developed for ONDC, etc. written in the language corresponding to the blockchain. This is what buyer and seller apps integrate to facilitate commerce.

• This also opens up a new layer of innovation where anyone can build applications that can enhance the overall value of the network.

• For eg: Someone might build an indexer that makes it super fast for buyer apps to dynamically search, sort and filter through millions of catalog items.

Applications

• The final buyer & seller apps and any other middleware.

How Does This Implementation Solve Our Problems?

1. Corruption With a decentralized validator network, the only way for a bad actor to influence the network for their own gain would be to take over >51% of the network which is highly unlikely if there are enough anonymous individual nodes.

2. Single point of failure As long as ≥1/n nodes are up, the network is online.

3. Scalability Innovations on data access & efficiency can be created permissionlessly and can be used by applications basis their own needs. The network scales with more nodes, who are incentivized to join because of the protocol fees to be earned.

4. Pricing monopoly Protocol fees go directly to the validators. Amount of fees is directly proportionate to the number of transactions processed by the network. Supply/demand dynamics at work here. If earnings are very low, validators will leave the network due to low capital efficiency. This increases the earnings for the remaining validators. This will continue to happen until equilibrium is reached, regardless of the actual GMV of the network.

5. Opaque order flow Order flow can be made public and observable by anyone. Large players cannot gate-keep order data even if it flows through their frontends. Market monitoring & intelligence tools can be built to extract valuable insights. Alternatively, order flow can be closed off to all parties and be sold in a private market (with selling rights awarded to validators).

In Closing

Open commerce networks are fundamentally different from the base primitives in the IndiaStack. If we’re hopeful for these digital networks to be the backbone of trillions of dollars of commerce throughout the country, there is merit in re-thinking protocol design to avoid centralization risks.