> For the complete documentation index, see [llms.txt](https://india-energy-stack.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://india-energy-stack.gitbook.io/docs/use-case-overviews/p2p-energy-trading.md). # P2P Energy Transaction *Two prosumers — consumers who can both inject and consume energy — on different DISCOMs execute a direct, signed energy trade over the same Beckn wire that carries IES dataset exchanges; the payload is a contract and its fulfilment, not a dataset. Each DISCOM is represented in the protocol by a regulated **Ledger Provider**, and settlement is computed by signed Rego policy, with no central exchange.* [**Implementation Guide →**](/docs/use-case-implementation-guides/p2p-energy-trading.md) | | | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Applicability** | Trading platforms, regulated Ledger Providers, DISCOMs | | **This version** | Built on the DEG `P2PTrade` / `DEGContract` / `BecknTimeSeries` family (canonical at [schema.nfh.global](https://schema.nfh.global)) over Beckn, with signed Rego policies governing the network and contract rules. Mirrored in [External Schemas — Energy Trading](/docs/schemas/external.md). | > **Initial topology.** The architecture supports one Ledger Provider per DISCOM, but the starting configuration connects **all trading platforms to a single Ledger Provider** at `ies-p2p-energy-ledger.beckn.io` — the two LPs in the diagrams below collapse into one (the intra-DISCOM topology; same protocol, fewer hops). The network namespaces are `indiaenergystack.in/test-ies-p2p-trading-network` (test) and `indiaenergystack.in/ies-p2p-trading-network` (production). *** ## 1. Scope and Purpose The **stakeholders** are two prosumers (buyer and seller) on potentially different DISCOMs, their respective trading platforms (TPs), and the regulated Ledger Provider (LP) contracted by each DISCOM. Today, peer-to-peer energy trade requires bespoke bilateral integrations, ad-hoc settlement spreadsheets, and a central exchange-style intermediary — none of which exist in the form Indian DISCOMs need. This document defines **P2P Energy Transaction** — a one-to-many discovery, contracting and settlement pattern carried over the same Beckn wire that carries dataset exchanges. The contract is a `DEGContract` with a `P2PTrade` body. Allocation and reconciliation flow as `BecknTimeSeries` inside the same envelope. Network rules are enforced by a **signed Rego network policy** in the adapter, and settlement terms by the seller-DISCOM's **contract policy** — a signed Rego bundle published on DeDi. Any participant evaluates locally; no central exchange. A trading platform integrates once. The same pattern works inter-DISCOM (two LPs, one peer leg) and intra-DISCOM (one LP, the two LPs collapse). ## 2. What It Records / Covers For one peer-to-peer trade the records carry: | Records | Detail | Source | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- | | The contract | Agreed quantity, price per kWh, delivery window, the four roles (buyer / seller / buyer's DISCOM / seller's DISCOM), and the `policyUrl` for the Rego bundle in force | `DEGContract` / `P2PTrade` (DEG) | | The offer | The seller's price, available quantity, validity window, source-type constraint (e.g. no GRID-sourced energy) | `EnergyTradeOffer` (DEG) | | Per-interval time series | `PRICE_PER_KWH`, `AVAILABLE_QTY`, `REQUESTED_QTY`, `BUYER_DISCOM_ALLOC`, `SELLER_DISCOM_ALLOC`, `FINAL_ALLOC` | `BecknTimeSeries` (DEG) | | LP↔DISCOM binding | Each LP's `utilityId` and ledger endpoint | `DiscomLedgerProvider` (DEG) | | Meter-data sub-transactions | Per-DISCOM actual injected / consumed quantities per interval, supplied during reconciliation by the DISCOM to its contracted LP as input to allocation — rides inside the same `message.contract` envelope as `BecknTimeSeries`, **not** a separate `MeterData` exchange | `BecknTimeSeries` (DEG) | | Revenue flows | Computed from the final allocation by the seller-DISCOM's **contract policy** Rego, recorded inside the contract (wire key `revenueFlows`, type `RevenueFlow`; injected by the `contractpolicyenforcer` ONIX step) | `RevenueFlow` (DEG) | Customer PII and raw meter data stay with the customer's own DISCOM and TP. Both LPs record the confirmed contract — including the agreed price — and the cascaded allocation and settled-quantity updates. ## 3. How Each Item is Identified Participants are identified by their plain **network subscriber IDs** — the `participantId` under which they are registered in the network registry (DeDi). No `did:web` (or any other DID scheme) is required for participants; the subscriber ID is a hostname-style string and is what appears in `context.bapId` / `context.bppId` and in the contract's `roles[]`. | Subject | Identifier method | Example | | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Trading platform (BAP / BPP) | Network subscriber ID | `buyerapp.example.com` | | Ledger Provider (LP) | Network subscriber ID | `seller-discom-ledger.example.com` | | DISCOM | Network subscriber ID; bound to its LP by `utilityId` in the `DiscomLedgerProvider` block | `buyerdiscom.example.com` (`utilityId: TEST_DISCOM_BUYER`) | | Buyer / Seller (prosumer) | Represented by their TP — the contract's `roles[buyer/seller]` carry the TP's subscriber ID; the prosumer is pinned by their meter reference | `roles[buyer].participantId = buyerapp.example.com` | | Meter / DT / feeder referenced in the trade | Existing utility asset ID wrapped as `did:web::meters:` (per [Register — Identifier patterns](/docs/concepts/setup-register/register.md#identifier-patterns)) | `did:web:buyerdiscom.example.com:meters:NM-44091234` | | Network policy | Rego file loaded by the adapter (`opapolicychecker` step) from `specification/policies/` | [`p2p-trading-ies-wave2-networkpolicy.rego`](https://github.com/beckn/DEG/blob/main/specification/policies/p2p-trading-ies-wave2-networkpolicy.rego) | | Contract policy | DeDi-published Rego record URL (`contractAttributes.policy.url`) | `https://api.dedi.global/dedi/lookup/indiaenergystack.in/ies-policies/ies-p2p-network-settlement-rego-policy-v1` | No new identifier scheme. The four-actor topology reuses the same subscriber-registry machinery as every other IES use case; public keys resolve from the same DeDi record the subscriber ID names. ## 4. Definitions * **Prosumer** — a consumer who can both inject (sell) and consume (buy) energy. * **TP** (Trading Platform) — the BAP or BPP that represents a prosumer on the network and runs the matching engine. * **LP** (Ledger Provider) — a regulated service that holds each DISCOM's slice of the trade record. Each DISCOM contracts exactly one LP; two DISCOMs may share an LP. * **Inter-DISCOM** — buyer and seller served by different DISCOMs; two LPs involved. * **Intra-DISCOM** — buyer and seller served by the same DISCOM; the two LPs collapse into one. * **Discovery service** — the network service that answers `discover` queries against catalogs that provider nodes have listed via `publish-catalog`. * **`BecknTimeSeries`** — the per-interval payload carrier; declares `payloadDescriptors` (each column's `payloadType` and `insertedBy`) and per-interval `payloads[]`. * **Cascade** — the auto-routing by which contract and settled-quantity messages reach both TPs and both LPs in the right order; implemented by the `degledgerrecorder` ONIX plugin (see [Auto-routing of contracts and allocations](/docs/use-case-implementation-guides/p2p-energy-trading.md#auto-routing-of-contracts-and-allocations) in the Implementation Guide). * **Policy-as-code** — the network and contract rules as signed Rego policies, evaluated locally with OPA. ## 5. Basis of Standards IES order of preference: **IS → CEA → IEC → IEEE**. Indian standards do not yet exist for peer-to-peer energy trade as a protocol. The IES choices: | Standard | Role here | | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Beckn Protocol v2** | The discovery / contracting / status lifecycle (`discover` → `select` → `init` → `confirm` → `status`); providers list offers to the Catalog service via `publish-catalog`, consumers query the Discovery service with `discover` | | **DEG schema family** | `P2PTrade`, `EnergyTradeOffer`, `EnergyTradeDelivery`, `DEGContract`, `DiscomLedgerProvider`, `BecknTimeSeries` — canonical at [schema.nfh.global](https://schema.nfh.global) | | **OPA / Rego** | The policy bundle format (standardised by CNCF) | | **W3C VC Data Model 2.0 / W3C DID Core** | Issuer key, signing | | **JSON-LD 1.1** | Wire format and semantic resolution | Meter data referenced by the trade conforms to **IS 16444** and **IS 15959** — the same standards as the [Smart Meter Data Exchange](/docs/use-case-overviews/smart-meter-data-exchange.md). ## 6. Where Indian Standards Do Not Yet Exist The whole protocol — the four-actor topology, the `BecknTimeSeries` payload vocabulary for trade negotiation, the cascaded routing, the policy-as-code framework — is an IES choice with no Indian standard predating it. The CERC Innovation Sandbox order (2023) is the regulatory umbrella; CEA / CERC standards specific to peer-to-peer trade are expected and will inform future versions. ## 7. The Records The P2P Energy Transaction flow produces three distinct kinds of signed artefact per trade: 1. The **contract** — `DEGContract` carrying a `P2PTrade` body. Recorded by both TPs and both LPs at confirm time (each LP receives it as a blocking `on_confirm` forward from its TP). 2. The **per-interval allocation series** — `BecknTimeSeries` carrying buyer-DISCOM allocation, seller-DISCOM allocation, final allocation. Recorded by both LPs and both TPs as Phase 5 cascades. 3. The **revenue-flow record** — computed from the final allocation by the seller-DISCOM's contract policy via the `contractpolicyenforcer` ONIX step; signed by the policy author and stored in `message.contract.consideration[id=auto-settlement-flows].considerationAttributes` (wire key `revenueFlows`, type `RevenueFlow`). Together they form a **complete, attributable audit trail** of the trade — from offer to settlement — with no central exchange. If the use case needs a holder-bound credential — e.g. a prosumer carrying a credit-worthiness attestation in a wallet — that uses the [Consumer Energy Passport](/docs/use-case-overviews/consumer-energy-passport.md) or [Consumer Meter Digest](/docs/use-case-overviews/consumer-meter-digest.md) separately. ## 8. Schedule I — Static Fields of the Exchange Schedule I is a use-case profile table over DEG's externally governed schema family, canonical at [schema.nfh.global](https://schema.nfh.global) and mirrored in [External Schemas — Energy Trading](/docs/schemas/external.md#energy-trading-p2p). Because these fields are not maintained in this repository, the schema-qualified names below identify the upstream contract rather than local JSON-Schema paths. **Upstream Requires** follows the mirrored v2.0 field tables; **P2P Guidance** is informative use-case guidance. ### 8.1 Contract Roles and Policy | **Upstream Field** | **Type / Allowed Value** | **Upstream Requires** | **P2P Guidance** *(informative)* | | --------------------------------------- | ---------------------------------------- | ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | `P2PTrade` | EnergyContract subclass | Inherits its fields; defines no additional fields in the mirrored table | Contract body identifying the P2P trade profile | | `DEGContract.roles[]` | array of role objects | Required | Carry the participant-binding roles used by the trade | | `DEGContract.roles[].role` | text | Required per role | Network policy expects buyer, seller, buyer-DISCOM and seller-DISCOM roles | | `DEGContract.roles[].participantId` | text or `null` | Key required per role; value may be null before binding | Bind to the registered subscriber/compound participant ID at select/init | | `DEGContract.policy` | policy object | Required | Points to the signed Rego contract policy in force | | `DEGContract.policy.url` / `.queryPath` | URI / text | Both required | Resolve only from the configured trusted DeDi policy prefixes | | `DEGContract.revenueFlows[]` | array of signed role/value/currency rows | Optional legacy shape | Wave-2 settlement uses the `RevenueFlow` consideration shape in §8.4 instead | | inherited `Contract.participants[]` | Beckn/DEG participant objects | Defined by the parent Contract schema | Carry participant attributes such as meter and utility identity; consult the canonical parent schema | ### 8.2 Offer, Customer and Order Item | **Upstream Field** | **Type** | **Upstream Requires** | **P2P Guidance** *(informative)* | | ------------------------------------------------- | ----------------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------- | | `EnergyTradeOffer.validityWindow` | time period | Optional | Expire the offer before its earliest delivery interval | | `EnergyTradeOffer.contractAttributes` | JSON-LD object | Optional | At catalog publication, declare known roles and the contract-policy terms | | `EnergyTradeOffer.contractAttributes.@type` | text | Required when the object is used | Normally `DEGContract` | | `EnergyTradeOffer.commitmentAttributes` | `BecknTimeSeries` JSON-LD object | Optional | Carries seller price/available-quantity columns and their descriptor contract | | `EnergyTradeOffer.commitmentAttributes.@type` | constant `TimeSeries` | Required when the object is used | Use the BecknTimeSeries v1.0 context | | `EnergyCustomer.meterId` | text (`der://meter/{id}` in the upstream description) | Required | Pins the represented buyer or seller to a meter | | `EnergyCustomer.sanctionedLoad` | number (kW) | Optional | Use only where network/contract policy evaluates the approved load | | `EnergyCustomer.utilityCustomerId` / `.utilityId` | text / text | Optional | Utility account and service-territory binding; minimise disclosure outside regulated participants | | `EnergyCustomer.platformUrl` | base URI | Optional | Base address for cascade sub-transactions | | `EnergyOrderItem.providerAttributes` | object | Required | Carries the `EnergyCustomer` identity for the order item | | `EnergyOrderItem.fulfillmentAttributes` | object | Optional | Populate only in status/update responses for delivery tracking | ## 9. Schedule II — Trade Actuals and Settlement (Live Record) Schedule II is the **live half** of a P2P trade — the per-interval values that keep arriving once the contract in Schedule I is agreed. Schedule I fixes who is trading, under which policy, on what terms; Schedule II carries what was actually offered, allocated, delivered and settled, slot by slot. The wire shape is `BecknTimeSeries`, not MeterData v0.6 — see §9.3. ### 9.1 Per-interval Negotiation and Allocation (`BecknTimeSeries`) | **Upstream Field / Payload Type** | **Type** | **Upstream Requires** | **Writer / Role in the Trade** *(informative)* | | ---------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | `intervalPeriod` | ISO 8601 start + duration | Required | Defines the delivery slots | | `payloadDescriptors[]` | event/report payload descriptors | Required | Declares every column's type, unit/currency and responsible writer | | `intervals[]` | interval rows | Required | Carries the typed values for each slot | | `resourceName` / `clientName` | text / text | Optional | Identifies the source resource and reporting participant | | `PRICE_PER_KWH` | event payload, INR | Profile-required at offer/confirm | Seller platform | | `AVAILABLE_QTY` | event payload, kWh | Profile-required in the published offer | Seller platform | | `REQUESTED_QTY` | event payload, kWh | Profile-required after buyer selection | Buyer platform | | `BUYER_DISCOM_ALLOC` / `BUYER_DISCOM_STATUS` | report payloads | Required by the reconciliation profile when buyer allocation is reported | Buyer DISCOM | | `SELLER_DISCOM_ALLOC` / `SELLER_DISCOM_STATUS` | report payloads | Required by the reconciliation profile when seller allocation is reported | Seller DISCOM | | `FINAL_ALLOC` | report payload, kWh | Required by the settled profile | Seller DISCOM; network policy enforces `FINAL_ALLOC ≤ min(buyer allocation, seller allocation)` | Every `payloadType` used in an interval must be declared by the profile's descriptor contract. The full schema uses OpenADR's open-string payload convention; the governed P2P names above are profile constraints enforced by the network/contract policies, not a closed enum in base `BecknTimeSeries`. ### 9.2 Settlement Revenue Flow | **Upstream Field** | **Type** | **Upstream Requires** | **P2P Guidance** *(informative)* | | ----------------------------------------------- | -------------------------------------- | -------------------------------------- | ---------------------------------------------------------------------- | | `consideration[].considerationAttributes.@type` | constant `RevenueFlow` in this profile | Required by the P2P settlement profile | Store policy output in the `auto-settlement-flows` consideration entry | | `RevenueFlow.revenueFlows[]` | array of role/value/currency objects | Required | Contract-policy output must balance to zero across rows | | `revenueFlows[].role` | text | Required | Names the buyer/seller platform or DISCOM role | | `revenueFlows[].value` | signed number | Required | Positive receives; negative pays | | `revenueFlows[].currency` | ISO 4217 code | Required | Use `INR` for this profile | | `revenueFlows[].description` | text | Optional | Explain energy, wheeling, platform or shortfall components | ### 9.3 Resource and Meter-actual Binding | **Record Surface** | **Shape** | **Contract Status** | **P2P Treatment** | | ------------------------------- | -------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | Offered energy resource | `EnergyResource` discriminated union | Upstream shared schema | Minimal P2P use is stable `id` + `type`; add attributes only when policy needs them | | Trade-side meter identity | `EnergyCustomer.meterId` | Required upstream field | Identifies the prosumer endpoint used by the trade | | Daily injected/consumed actuals | `BecknTimeSeries` report payload types | Governed by the P2P reconciliation profile | Supplied by each DISCOM to its LP inside the contract-status flow | | MeterData v0.6 | Separate IES telemetry schema | **Not embedded as a MeterData profile in this trade contract** | A DISCOM may derive actuals from its MeterData system, but the trade-side wire shape remains BecknTimeSeries | | Ledger-provider binding | `DiscomLedgerProvider` upstream schema | Defined only at schema.nfh.global | Associates a regulated ledger endpoint with its DISCOM/utility ID | ## 10. How It Fits Together Everything buyer-side mirrors everything seller-side: a buyer prosumer and their trading platform (BAP) on one side, a seller prosumer and their trading platform (BPP) on the other, the two platforms meeting over the `select / init / confirm / status` leg. Each DISCOM is represented by one regulated Ledger Provider, and each LP pulls metered actuals daily from its own DISCOM as the input to allocation. The two LPs — one per DISCOM — never speak to each other directly; the two TPs are the only liaison between them. No central exchange. Discovery goes through the network's Discovery service: the SellerTP lists offers via `publish-catalog`, the BuyerTP queries with `discover`. > **The block-topology diagram and the full six-phase sequence diagram** (with the automated ONIX legs shaded) live in the [**Implementation Guide → What each actor does, per phase**](/docs/use-case-implementation-guides/p2p-energy-trading.md#what-each-actor-does-per-phase) — placed there so a developer has the topology, the wire sequence and the per-actor build steps in one place. ### The six phases This is the inter-DISCOM flow. Intra-DISCOM (buyer and seller behind the same DISCOM) collapses Phase 2's optional limit check and Phase 5 into a single ledger. The wire sequence is drawn — with the automated (ONIX) legs shaded — in the [Implementation Guide](/docs/use-case-implementation-guides/p2p-energy-trading.md#what-each-actor-does-per-phase); in words: 1. **Discovery** — SellerTP lists an `EnergyTradeOffer` catalog (`publish-catalog`); BuyerTP queries the Discovery service with `discover` and a JSONPath intent filter. 2. **Select and init** — quantity and price refined; optional LP headroom pre-check. 3. **Confirm** — the buyer's `confirm` is answered by the seller's `on_confirm`; as that `on_confirm` travels, each TP's `degledgerrecorder` forwards a rewritten copy to its own LP and **blocks until the LP ACKs** — seller-side before the `on_confirm` leaves for the buyer, buyer-side before the buyer app receives it. The LPs do not emit an `on_confirm` of their own; their sync ACK is the record receipt. 4. **Delivery** — seller injects, buyer consumes. 5. **Allocation and reconciliation** — **daily**, each LP asks its own DISCOM (a `status` request on the LP's `/bap/caller`) for metered actuals covering the meters and intervals that still carry an **unallocated trade**; the DISCOM answers with an `on_status` bearing those actuals, and the LP allocates its side. Either TP may then **poll** for the peer's latest allocation with a `status` request — which the peer TP's adapter auto-cascades to its own ledger before that ledger answers with a fresh `on_status`. Every allocation and settled-quantity `on_status` then cascades **symmetrically** through the two TPs to the opposite LP (an automatic forward at one TP, an automatic record at the other): buyer-side updates run `BuyerLP → BuyerTP → SellerTP → SellerLP`, seller-side updates run the mirror chain, so all four parties converge on `FINAL_ALLOC`. The `contractpolicyenforcer` step computes the revenue flows as the settled `on_status` passes the seller TP. 6. **Billing and settlement** — buyer pays seller (off-ledger via TPs); DISCOM monthly bills are adjusted accordingly. The allocation logic on each LP can be as simple as **pro-rata across the customer's trades in the delivery window**. The same Phase-5 message flow supports multiple rounds — a provisional allocation, a final allocation after meter-data finalisation, a deviation true-up — by repeating the `/status` round-trip with a fresh `BecknTimeSeries` payload. Iteration is a payload concern, not a protocol concern. The cascade rules, the four ledger interfaces, and the payload snapshots that make this flow concrete are in the [**Implementation Guide**](/docs/use-case-implementation-guides/p2p-energy-trading.md). ## 11. Points for Confirmation 1. **Wheeling / penalty tariff values** — the rates in force are whatever the seller-DISCOM's published contract policy defines; each DISCOM sets production values per its tariff order by publishing its own policy version. 2. **`contractpolicyenforcer` ONIX step** — ships in the wave-2 seller-TP config (computes revenue flows on `on_status` from the DeDi-resolved contract policy); being aligned across LP implementations. 3. **TEST → PROD `utilityId` allow-list** — the network bundle's production rules check approved IDs only; the production allow-list is governance-pending. 4. **CERC sandbox graduation** — production-grade network policy bundle awaits CERC sign-off post-sandbox. 5. **Intra-DISCOM topology** — collapsing the two LPs into one is supported and lighter; the configuration convention is in the wave-2 devkit, being formalised. 6. **Daily meter-data pull cadence** — the LP→DISCOM actuals pull is modelled as a daily job over meters and intervals with unallocated trades; the exact cadence and the retry/true-up window are per-DISCOM and being formalised. *** ## Schemas Used in This Use Case | Schema | Role | | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- | | [**P2PTrade**](https://schema.nfh.global/P2PTrade/) | The contract `@type` — agreed quantity, price, delivery window, the four roles, the policy URL | | [**EnergyTradeOffer**](https://schema.nfh.global/EnergyTradeOffer/) | The seller's offer block | | [**EnergyTradeDelivery**](https://schema.nfh.global/EnergyTradeDelivery/) | The performance block populated during reconciliation | | [**DEGContract**](https://schema.nfh.global/DEGContract/) | The envelope — roles, the rego policy URL, computed revenue flows | | [**DiscomLedgerProvider**](https://schema.nfh.global/DiscomLedgerProvider/) | The LP↔DISCOM binding (`utilityId`, `ledgerUrl`) | | [**BecknTimeSeries**](https://schema.nfh.global/BecknTimeSeries/) | Per-interval payload carrier — declares `payloadDescriptors` and `payloads[]` | | [**ElectricityCredential v1.2**](/docs/schemas/electricitycredential/v1.2.md) *(optional)* | Seller's attestation of meter / sanctioned-load / DER details backing the offer | A consolidated field reference is in [**External Schemas — Energy Trading**](/docs/schemas/external.md#energy-trading-p2p). ## Value Unlock **For prosumers** — a direct, signed channel for selling distributed energy, with no central exchange. **For trading platforms** — one integration; the same protocol intra- and inter-DISCOM; allocation and settlement computed by signed Rego, not custom code. **For DISCOMs** — wheeling charges and deviation penalties are the output of a signed function over a signed contract, not a bilateral spreadsheet. Visibility into peer-to-peer trade is a by-product, not a separate reporting effort. **For regulators** — the network rules are the policy bundle itself. A policy change is a new signed bundle on DeDi, picked up by every participant on the next contract. *** ## Annexure A — Standards Referenced | Standard | Scope | | --------------------------------------------------------- | ---------------------------------------------------------------- | | CERC Innovation Sandbox Order, 2023 | Regulatory umbrella for peer-to-peer trade pilots | | Beckn Protocol v2 | Discovery, contracting, payload delivery, status, signed audit | | DEG `P2PTrade` / `DEGContract` / `BecknTimeSeries` family | The payload schema family on the wire | | OPA / Rego (CNCF) | Policy-as-code format for network and settlement bundles | | IS 16444 (Parts 1, 2) | AC smart meter — specification (for trade-side meter quantities) | | IS 15959 (Parts 1–3) | DLMS/COSEM data-exchange companion specification; OBIS codes | | W3C VC Data Model 2.0; W3C DID Core | Issuer keys; signing | | JSON-LD 1.1 | Wire format and semantic resolution | ## Annexure B — Example Payloads The wave-2 devkit ships example payloads for every phase, per role: → [**`devkits/p2p-trading-ies-wave2/uc1/`**](https://github.com/beckn/DEG/tree/main/devkits/p2p-trading-ies-wave2/uc1) ## Annexure C — JSON Schema Canonical references at [**schema.nfh.global**](https://schema.nfh.global): * [**P2PTrade/v2.0**](https://schema.nfh.global/P2PTrade/v2.0) * [**DEGContract/v2.0**](https://schema.nfh.global/DEGContract/v2.0) * [**EnergyTradeOffer/v2.0**](https://schema.nfh.global/EnergyTradeOffer/v2.0) * [**EnergyTradeDelivery/v2.0**](https://schema.nfh.global/EnergyTradeDelivery/v2.0) * [**DiscomLedgerProvider/v2.0**](https://schema.nfh.global/DiscomLedgerProvider/v2.0) * [**BecknTimeSeries/v1.0**](https://schema.nfh.global/BecknTimeSeries/v1.0) A consolidated field reference for the trade schemas (except `DiscomLedgerProvider` and `EnergyTradeDelivery`, defined only at schema.nfh.global) is in [**External Schemas — Energy Trading**](/docs/schemas/external.md#energy-trading-p2p). ## Annexure D — Derived Views Computed downstream from the Schedules above. None is exchanged, and none is a separate populated IES schema. | **Derived View** | **Sources** | **Schema Status** | **Treatment** | | ------------------------------------- | ------------------------------------------------------------------ | ------------------------ | -------------------------------------------------------------------------------------------- | | Per-DISCOM monthly bill adjustment | settled `FINAL_ALLOC`, revenue-flow rows and the applicable policy | Derived | Exclude traded volume/include charges according to the signed policy and local billing rules | | Trading-platform book of trades | confirmed contracts plus allocation/status history | Derived | Preserve contract and interval identifiers so every row traces to signed evidence | | Ledger reconciliation statement | both LP copies, DISCOM allocation series and final allocation | Derived | Differences are exceptions; do not overwrite either signed source | | Prosumer statement | price, requested/final quantity and applicable charges | Presentation only | May be rendered for the consumer; the signed contract and revenue flow remain authoritative | | Network performance report | trade counts, delivery ratios and policy failures | Derived aggregate | Must not expose raw customer identifiers or meter data | | Holder-bound credit/energy credential | Consumer Energy Passport or Consumer Meter Digest | Separate schema/use case | Do not repurpose the P2P contract as a wallet credential | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://india-energy-stack.gitbook.io/docs/use-case-overviews/p2p-energy-trading.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.