Just add imagination: building with India Energy Stack
Lately I have been marveling at the genius of the Lego block, the humble, unremarkable, stackable connectable brick. Having grown up with Meccanos, when I first saw the brick, I did not think much of it. But now, looking at it through my son's eyes, I see how it hides the untold possibilities and makes any imagination real as long as one has patience and the ability to see the possibilities. Through simplicity, modularity, composability in design and micrometer level precision in moulding, Lego bricks can stack their way to make a Hogwarts castle or a full Jurassic park... It is the purest form of seamless interoperability, the true ideal of cooperation without complex coordination. No glue to put down and cure, nothing to tighten, in fact no tools needed. Just press and watch the magic happen.
Today, I am going to talk about another such stack. This one is in a totally different domain and is built purely in software, but has tons of parallels and emergent properties like Legos. Each element in this stack is purpose agnostic and domain neutral, just like a Lego block, and when combined with know-how and imagination, it becomes the fastest way to go from an idea to a working solution. This stack is the India Energy Stack, documented at https://india-energy-stack.gitbook.io and available as a pdf here. It draws on the best in class open standards coming from W3C (did, vc, json-ld), CNCF(opa), IETF(json, jsonschema draft), OPENADR, LF (openapi, dedi) and NFH (beckn, beckn-onix, DEG schemas).
Disclaimer: The essay below captures my personal views & fond wishes on what it could build. It may not reflect views of organizations involved in the IES efforts, NFH, REC, FSRglobal etc.
First let's take a closer look at the blocks:
Please bear with this section even if it seems arcane or devoid of context. That's how Lego blocks look at first glance. But interesting applications can emerge from it.
Trusted identities and network membership (DEDI): gives an organization a cryptographic way to prove to the counterparty that the message is coming from their unique verified identity (DID) on the web and has not been tampered with. It also allows network operators to simply add participants' identities to a public network participant registry so that members can cross-check counter-party's membership creds and can refuse a trade when someone outside the network tries to engage them. The vehicle to both of the above is the open-source DeDi protocol from NFH, now housed under Linux foundation.
Standard protocols for publish/discovery/trading/fulfillment (BECKN): During a multi-turn commerce transaction, it is important to express different stages of value exchange, and codify the domain agnostic vocabulary of offer publishing, discovery, expressing interest, negotiation, confirmation, delivery and payment. IES proposes the use of open-source home-grown Beckn protocol to do the same. Protocol describes request, response patterns, minimal grammar that should be included in conversation and how to secure the communication.
Standard composable data structures or schemas (SCH): Just like rules of grammar, sending data with self-describing schemas/grammar helps avoid typos, catch bugs and ensures that the other party will understand the contents. Beckn also ships with an optional SDK called beckn-onix which examines every incoming and outgoing message. It can act as the grammar police and ensure each message element conforms to the self describing schema contained within the payload, and the outer scaffold conforms to the Beckn protocol. Example seed schemas are also provided at https://schema.nfh.global/ and at IES gitbook here. You can also propose new ones here.
Verifiable credentials (VC): Apart from the verified identity, vocabulary & grammar a listener can understand, trade also requires seals and certificates of facts, which are issued by a trusted third party so that veracity of roles, ownership, timeseries data can be checked. W3C verifiable credential standard shows how to issue, revoke, verify a credential by looking up the public key of the issuer based on the url inferred from their decentralized identifier.
Policy as code (PAC): Apart from the rules of grammar, for a healthy network, we need rules. Just like the rules of the road, these ensure the network actually generates an economic surplus, that the surplus is shared fairly and nobody can game the system at other's expense. The policy as code engine allows us to take in a json message and apply a set of rules on it encoded into the rego/OPA file. This can either be used to output booleans (e.g. is policy violated) or data stream (e.g. automatic invoice generation/validation). This leads to two policy constructs. One for network policy and other for the in-payload contract policy. Network policy is implicit and can be maintained by the network operator. They codify rules which, when followed by all, makes everyone's life easier. An example network policy can say that no trade can be made within 4 hours of the delivery time. Contract policy, on the other hand, only applies to a bilateral contract and can be published along with the offer. E.g. A state discom can declare that its contract policy only allows intra-state peer to peer trade and not inter-state, if the regulations don't allow such.
Now let's look at various use cases that can be put together from above blocks:
Peer to peer energy trading:
On Feb 19 2026, the very first trade was made on the first inter-state p2p network and also demonstrated to Hon. Prime Minister of India. Arunji, the farmer from Meerut with the solar roof, opened the Pulse Energy app and spoke in chaste Hindi into his phone and sold his energy to Laxmi ji who runs a garment shop in Delhi, as we engineers watched the trade ledger on the screen with bated breath. The trade linked hourly generation from a source meter to the hourly consumption of the sink meter, between two different states. A first for India and the world.
It had all started in Bangalore where less than a month ago, as the chief architect of IES, walked the civil servants, discom & startup reps through the signal flows from github. Over the next 4 weeks, 3 bootcamps were held and 12 trading platforms published their apps on app-store, 3 discoms issued VCs for each enrolled customer and wrote actual meter data to ledger. The launch went smoothly and six months on, TPDDL, PVVNL and BRPL discoms are settling inter-state trades daily. Such rapid integration was possible due to the magic of the above lego blocks and the promise of interoperability that they deliver on. From concept to launch, the whole project came together in record time of one month. Below is a brief walk-through & flow diagram of the life-cycle of a p2p trade.
A p2p trade takes place between trusted trading platforms over BECKN protocol, and is a contract between a prosumer & consumer with smart meters to exchange a specific quantum of energy at a future time window. It is also a side-contract between each customer & their utility, not to double bill them for that trade.
Network operators such as REC maintain a trust perimeter using DEDI and add to the production network each trading platform which can prove readiness & interoperability within the test network. Each platform has to publish their public keys on DEDI, and sign the transactions with private keys, ensuring zero trust security over the public internet.
Beckn-onix signs the outgoing messages, checks integrity & network membership of incoming messages, checks the protocol, grammar & PAC violations of each message content for network & contract policy. The Beckn-onix also auto-routes confirmed trades to ledgers and trading partners, so that each trade has a row in buyer & seller discom's ledger (or double entry if they share a ledger). Once allocation is published in ledger, Beckn-onix auto-forwards then and also computes the automatic net-zero invoices between all participants including discoms. The buyer's beckn-onix can auto-validate the same, leading to dispute free trades.
Once a day, ledger sends discoms all unallocated trades for their customers and receives the actual meter data to be allocated against trades. Discoms agree to respect the final allocation, and only bill customers for the rest, while platforms ensure payments for the final p2p trade allocation.
The customer enrollment is also seamless, where a trading app directs users to discom webpage which provides them a discom signed, tamper proof VC of meter/solar ownership along with tariff, sanctioned load details. Each trading platform can then apply discom's eligibility policy (PAC again) and check if the user can be enrolled.
Allocation: currently the tricky task of allocating actual meter export to multiple overlapping trades is left to regulated ledgers, with final allocation being the minimum of prosumer and consumer allocations. This can be made more sophisticated in future. (Really this is the work of the regulator, but in my personal opinion:, it still suffers from counterparty risk. What if the I, the producer, exports as promised, but the consumer did not withdraw power at all.. Then allocation will be 0 and I won't see any savings from the trade. This could in future be completely mitigated by penalties for underinjection or underdrawal, which make the other party whole, and the allocation complexity goes away as allocation is same as the traded quantity.)
Currently the regulations impose limits on trading hours, only allowing export from solar and not batteries. (Personal opinion again: I believe they need to be changed to incentivize peak shaving in the evening.) Once decided, all regulations can be made machine readable through PAC, and can be used by each trading platform to simulate rewards from different actions, and then optimize the dispatch to maximize rewards, and value stack different streams.
To reduce trading penalties of underinjection or underdrawal, it is essential that home load forecast is accurate. To help with that, instead of every trading platform needing to talk to every discom, IES proposes a VC of meter data history to be provided by utility to their customer, pulled directly or into their phone wallets, which they can share with platforms for accurate forecasting. Until now, some utilities were sharing their meter data with customers in their apps as charts or raw csvs, but not in an interoperable manner (similar to "share my data" in US) where customer can retain custody of data with a seal of discom. This enables that and reduces the cost of trust and fraud prevention. Data, instead of becoming the new oil - a commodity worth hoarding in a walled garden and speculating on, it becomes the new soil, enabling much powerful value added apps to be built on top.
Whew.. that is the first example of what one can build with the IES stack. Let's also discuss the benefits of p2p trading. Right now, solar hours flood the grid with supply exactly when demand — and market prices — are at their lowest. Under net metering, every rooftop export is credited at the standard import tariff, well above what that midday power is worth on the market, so the more solar comes online, the wider that gap grows. It's a hard bind: left unaddressed, that mismatch is what eventually pushes the system toward penalties and sanctioned-load caps that end up slowing the very solar rollout everyone wants. A classic case of an economic pie that shrinks when there's no fair way to share it. P2P changes the arithmetic — with hourly matching and real price discovery, midday demand can rise to meet the solar, so that energy gets absorbed instead of stranded. It can also reward storing energy in batteries for the evening, when demand returns and prices are higher. Another note regarding moral hazard. Customers with net metering and large home load may not see much value in p2p trading if the market price is below the tariff rate, because they are already getting free energy in the evening. But if their tariff is subsidized, it may create a perverse incentive to sell p2p to non-subsidized customers, hurting discom's revenue stream. If regulators decide so, p2p can be made conditional on different tariff categories. An important aspect is to ensure that p2p trade benefits everyone, including discoms. Only then will it grow sustainably and help.
Next we will see what advanced products can p2p primitive evolve into:
Aggregation of DERs:
An aggregator pools together meters from multiple customers and trades their surplus / consumption. This requires a p2p trade to use a virtual meter, or an array of meters, and the rest of mechanics works as before.
Local energy markets & market clearing agents:
A market clearing agent (MCA) matches supply with demand and finds the market clearing price. It can be achieved by:
Allowing MCA to be a common peer with all prosumers and all consumers.
Instead of prosumers declaring offer prices when they publish supply, they can instead publish a price-quantity curve. The policy dictates that only registered MCAs can claim such offer.
The MCA stacks in all supply, all demand, discovers clearing price at a predetermined time (like a day-ahead market, or real-time market).. It would need to pay for any imbalance, so it is strongly incentivized to match. Once price is announced all contracts below the clearing price are deemed confirmed & active. If clearing price is below the supplier's bid curve, the supply won't clear.
In theory there can be multiple MCAs in play provided they are sufficiently differentiated.
Markets are more efficient than a bilateral trade because they save the consumers the regret of overpaying and producers the regret of undercharging. Thus they encourage all parties to quote their true marginal cost, and even if someone quotes a lower price, they are guaranteed to get market clearing price.
In theory, the hourly prices should converge to those from other markets such as IEX, as otherwise there will be incentive to arbitrage the difference. This will allow blending of wholesale and retail rates, and in essence create a dynamic tariff.
The prices can also reflect locational nuances if MCA is aware of transformer limits and congestion forecasts. It can add those constraints to the clearing engine, effectively raising the price with congestion adders if there is too much demand than supply behind the transformer.
Such markets can run day-ahead, hourly or 5 min cadence, allowing participants to buy back their positions ahead of delivery, similarly to modern markets. This will allow more liquidity and efficiency.
Ledger can export the projected trades which can feed into scheduling within SLDCs & any DER congestion becomes visible and can be forecasted.
Demand flexibility:
Demand flex is essentially a contract to change demand based on certain real-time signals such as time itself (e.g. reduce demand between 6 to 7pm tomorrow), market clearing prices (price elasticity of demand), frequency, grid dispatch commands and relative to certain baselines such as 0 based, pre-frequency event or average of highest 10 out of last 10 days etc. (for behavioural demand flex)
As long as the connection from actions, real-time signals and trade position to rewards/revenue is machine readable PAC, it can be discovered by smart DERs, value stacked with other products like p2p trade and optimized. The dispatch can happen via non-beckn rails like OpenADR, price servers, grid AGC.. but as long as they are available at time of final accounting, settlement could happen over beckn.
Examples of such contracts are:
Best effort behavioral demand reduction/increase relative to baseline. No penalty for under-delivery. This can be achieved by sending customers messages about demand reduction, or can be achieved by automated DERs, if they can discover discom's PAC files on DEDI.
Committed demand response: with a penalty for underdelivery, and a price premium.
Price flexible demand: can allow flexible load to be part of demand stack and participate in price discovery. This requires broadcast of real-time prices using a price server.
Ancillary support: frequency and voltage support, regulation up/down support. Requires archival of frequency/voltage/AGC signals during settlement.
A bid-curve based pay-as-clear auction of behavioural demand flexibility can be found here.
Smart Energy retailers:
A tariff that a retailer charges is itself a contract to buy/sell energy at a certain price, and can be expressed as a settlement PAC.
Once it becomes machine readable, utilities can publish it and smart DERs can discover it in order to optimize the bill.
Advanced retailing arrangements are also possible, provided regulators allow it. E.g. Certain retailers can increment customer credit every time they export when the cost of supply is higher than import tariff, and vice versa. This aligns the customer's bill with the utility's cost of supply and ensures a win/win. They can also index imports at real-time rates with a backstop against how high a bill can go, similar to Amber Electric in Australia.
Such retailers, if they can incentivize all ways in which a DER can help, they can present the highest ROI for someone investing in a new battery/solar.
Machine discoverable incentives & optimization:
Once such tariff, p2p energy, demand flex, congestion recovery, ancillary service, dynamic price contracts become machine discoverable & readable, an ecosystem of home optimizers, DER optimizers can become aware of the consumer's opportunity cost and reduce bills by value stacking while helping the grid and reducing neighbours bills as well (since they are reducing utility's cost of supply). This is no different than how utility scale mega batteries or generators operate. Same smarts.. just in a smaller form factor, and built on an interoperable seamless foundation.
About working for India Energy Stack:
It was a privilege to work as a part of India Energy Stack from Jan to July 2026. I had a the rare & lucky chance to witness this revolution from the front seat, in the company of people with integrity, optimism and genuine desire to make things better. We ran many days of bootcamps working with each discom and many young entreprenuers. Saw how the civil servents from CEA, MoP do their important regulatory work from simple offices undergoing repairs. It did feel like a rare cause that deserved every ounce of my dedication. The act of helping a engineer at the tail end of the day-long bootcamp did not feel draining but an act of hope. We took from the best from the energy standards, but also developed new vocabulary when none existed, so that agentic AI / machines can trade energy on user's behalf.
I was also immensely inspired by the calibre, determination, relentless hunger and often underestimated potential of so many young engineers, founders, powering this next energy revolution. The more trust one places in them, the more they rise to the challenge. Once the regulators define and bless the proper rules of the road, these roads or rather the transmission lines, are going to hum with clean, affordable and reliable power, thanks to them.
Comments