From a6fab242a4b4c77b5ba1ae81f25b5f65cdc75967 Mon Sep 17 00:00:00 2001 From: Ameet Deshpande Date: Sun, 18 Jan 2026 01:00:25 +0530 Subject: [PATCH 1/8] added alternate sequence diagrams --- ...tral_vs_Decentralized_Ledger_Comparison.md | 326 ++++++++++++ ...r_energy_retailer_P2P_trading_alt_draft.md | 465 ++++++++++++++++++ 2 files changed, 791 insertions(+) create mode 100644 docs/implementation-guides/v2/P2P_Trading/Central_vs_Decentralized_Ledger_Comparison.md create mode 100644 docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md diff --git a/docs/implementation-guides/v2/P2P_Trading/Central_vs_Decentralized_Ledger_Comparison.md b/docs/implementation-guides/v2/P2P_Trading/Central_vs_Decentralized_Ledger_Comparison.md new file mode 100644 index 00000000..7be9dbfb --- /dev/null +++ b/docs/implementation-guides/v2/P2P_Trading/Central_vs_Decentralized_Ledger_Comparison.md @@ -0,0 +1,326 @@ +# Central Ledger vs Decentralized Approach: A Comparison + +This document compares two approaches to inter-energy retailer P2P trading: + +1. **Central Ledger Approach** - [Inter_energy_retailer_P2P_trading_draft.md](./Inter_energy_retailer_P2P_trading_draft.md) +2. **Decentralized Approach** - [Inter_energy_retailer_P2P_trading_alt_draft.md](./Inter_energy_retailer_P2P_trading_alt_draft.md) + +--- + +## Why We Originally Chose a Central Ledger + +The original design uses a central Trade Exchange/Ledger for these reasons: + +### 1. Single Source of Truth + +When buyer and seller are with different utilities, multiple parties need access to the same trade information: + +- **Both utilities** need to know about the trade for billing adjustments +- **Both trading platforms** need confirmation of trade status +- **Distribution utilities** need visibility for grid planning + +A central ledger provides one authoritative record that all parties can query. + +### 2. Anti-Double-Dipping + +When a prosumer has multiple trades in the same delivery window, actual meter readings must be allocated carefully. Consider: + +| Trade | Contracted | Delivery Window | +|-------|------------|-----------------| +| T1 | 5 kWh | 2-4 PM | +| T2 | 4 kWh | 2-4 PM | + +If the prosumer only injects 7 kWh, who gets what? + +With a central ledger, there's a single authoritative allocation (e.g., FIFO: T1 gets 5 kWh, T2 gets 2 kWh). Without it, different parties might calculate different allocations. + +### 3. Cross-Retailer Reconciliation + +Without a central ledger: +- How does Retailer A know about trades its customer made with Retailer B's customers? +- How do both retailers ensure they're using the same trade data for billing? + +A central ledger solves this by being the shared record both retailers query. + +### 4. Trust and Dispute Resolution + +If buyer claims they never agreed to a trade, or seller claims they delivered when they didn't, who arbitrates? + +A central ledger with digital signatures provides a trusted record for dispute resolution. + +### 5. Familiar Model + +This mirrors how stock exchanges work: a central exchange records all trades, and participants trust the exchange's records. It's a proven model at scale. + +--- + +## Why Consider a Decentralized Alternative? + +Despite the advantages of central ledgers, there are compelling reasons to explore alternatives: + +### 1. Privacy Concerns + +A central ledger sees **every trade** across all utilities: +- Trade amounts, timing, pricing +- Who is trading with whom +- Consumption and production patterns + +This raises privacy concerns: +- Do all trades need to be visible to a central entity? +- Could this data be misused or leaked? + +### 2. Single Point of Failure + +If the central ledger is unavailable: +- No new trades can be confirmed +- No existing trades can be verified +- No billing adjustments can be made + +This creates systemic risk. + +### 3. Regulatory Complexity + +A central trade exchange requires: +- Regulatory approval and oversight +- New institution or infrastructure +- Cross-jurisdiction agreements (if utilities span regions) + +This adds complexity and delays market launch. + +### 4. Centralization Concerns + +Energy markets have historically been decentralized (utility by utility). A central trade exchange concentrates power and could: +- Become a bottleneck for market growth +- Extract monopoly rents +- Resist innovation that threatens its position + +### 5. Implementation Burden + +Every utility must integrate with the central ledger. If a new utility wants to join, they must: +- Meet the exchange's technical requirements +- Pass certification +- Pay integration costs + +This creates barriers to market entry. + +--- + +## How the Decentralized Approach Works + +The decentralized approach eliminates the central ledger by having: + +1. **Each utility maintain its own ledger** for its own customers only +2. **Multi-party signatures** create a distributed audit trail +3. **Cascading Beckn protocol calls** coordinate across utilities + +### Key Insight: Each Utility Already Has the Data + +Each utility already knows: +- Its own customers' meter readings +- Its own customers' billing history +- What limits it wants to impose on its customers + +The central ledger duplicates this information. Instead, we can have each utility: +- Track trades involving its own customers +- Perform allocation for its own customers +- Adjust billing based on its own ledger + +### Trust Without Centralization + +Instead of trusting a central ledger, trust is established through **multi-party signatures**: + +``` +Trade confirmation chain: +1. BuyerTP signs → "Buyer wants this trade" +2. SellerTP signs → "Seller agrees to this trade" +3. SellerUtility signs → "Logged in our ledger, seller has capacity" +4. BuyerUtility signs → "Logged in our ledger, buyer has capacity" +``` + +By the end, all four parties have signed the same order. Any party can prove: +- The trade was agreed to by all parties +- Each utility logged it in their ledger +- Trading limits were checked + +--- + +## Detailed Comparison + +### Trust Model + +| Aspect | Central Ledger | Decentralized | +|--------|---------------|---------------| +| **Who do you trust?** | The central exchange | Each utility trusts the signature chain | +| **What if trust is violated?** | Exchange's reputation at stake | Multi-party signatures provide evidence | +| **Dispute resolution** | Exchange is arbiter | Signatures + utility ledgers provide evidence | + +**Analysis:** The decentralized approach shifts from institutional trust (trust the exchange) to cryptographic trust (trust the signatures). This is arguably stronger since signatures are mathematically verifiable, but requires all parties to properly implement signature verification. + +### Privacy + +| Aspect | Central Ledger | Decentralized | +|--------|---------------|---------------| +| **Who sees all trades?** | Central exchange | No single entity | +| **What does each utility see?** | Potentially all trades (via the ledger) | Only trades involving its customers | +| **Data minimization** | No - exchange has everything | Yes - each party sees only what's needed | + +**Analysis:** The decentralized approach is significantly more privacy-friendly. Each utility only sees: +- Its own customers' trades +- The counterparty utility (for cross-utility trades) + +The central exchange in the original approach sees *every trade across all utilities*, which is a substantial privacy concern. + +### Single Point of Failure + +| Aspect | Central Ledger | Decentralized | +|--------|---------------|---------------| +| **If exchange is down** | All trades blocked | Only affected utilities impacted | +| **If one utility is down** | Other utilities continue | Only that utility's trades blocked | +| **Cascading failures** | Possible (all depend on exchange) | Limited (utilities are independent) | + +**Analysis:** The decentralized approach is more resilient. A utility outage only affects trades involving that utility's customers. In the central ledger approach, an exchange outage blocks all trades across all utilities. + +### Anti-Double-Dipping + +| Aspect | Central Ledger | Decentralized | +|--------|---------------|---------------| +| **Allocation authority** | Single (exchange) | Distributed (each utility for its customers) | +| **Consistency guarantee** | Strong (one allocator) | Weaker (utilities may differ) | +| **Cross-utility double-dipping** | Exchange prevents | Requires utility coordination | + +**Analysis:** This is where the decentralized approach is weaker. Consider: + +- Seller has trades with buyers from Utility A and Utility B +- SellerUtility allocates actual injection to these trades +- BuyerUtility-A and BuyerUtility-B each independently allocate for their customers + +If allocation methods or timing differ, the numbers might not match. The optional cross-utility `/on_status` calls help, but don't guarantee consistency. + +**Mitigation:** Standardize allocation algorithm (e.g., FIFO by trade confirmation time) and make cross-utility status sharing mandatory rather than optional. + +### Regulatory Complexity + +| Aspect | Central Ledger | Decentralized | +|--------|---------------|---------------| +| **New infrastructure needed** | Yes (central exchange) | No (utilities extend existing systems) | +| **Cross-jurisdiction** | Exchange must be approved everywhere | Each utility handles its own jurisdiction | +| **Market entry barriers** | Higher (exchange certification) | Lower (utility-to-utility integration) | + +**Analysis:** The decentralized approach aligns better with how energy markets currently work (utility by utility) and doesn't require creating new central institutions. + +### Implementation Complexity + +| Aspect | Central Ledger | Decentralized | +|--------|---------------|---------------| +| **Integration points** | All parties → Exchange | Utility ↔ Trading Platforms | +| **Protocol complexity** | Simpler (query central ledger) | More complex (cascading calls) | +| **Signature handling** | Optional (ledger is source of truth) | Mandatory (signatures are trust basis) | + +**Analysis:** The decentralized approach requires more sophisticated protocol handling: +- Cascading `/confirm` calls through multiple parties +- Multi-party signature verification +- Handling partial failures in the cascade + +However, it builds on the existing Beckn protocol structure rather than requiring a separate ledger integration. + +--- + +## Does the Decentralized Approach Achieve the Goals? + +### Goal: Privacy-Friendly + +**Assessment: Largely Achieved** + +- Each utility only sees trades involving its own customers +- No central entity has visibility into all trades +- Trade counterparties are visible to both utilities involved, but not to unrelated utilities + +**Remaining Concern:** The utilities involved in a trade do see each other's customer information (buyer ID, seller ID). Full privacy would require zero-knowledge proofs, which adds significant complexity. + +### Goal: Decentralized Proof of Performance + +**Assessment: Partially Achieved** + +The multi-party signature chain provides: +- Proof that all parties agreed to the trade +- Proof that each utility logged the trade +- A tamper-proof record that any party can present + +However, **proof of actual delivery** still depends on: +- Each utility's meter readings (centralized per utility) +- Each utility's allocation calculation +- Trust that utilities report accurately + +**What's Different:** In the central ledger approach, the exchange receives and validates meter data from both utilities. In the decentralized approach, each utility is trusted to report its own meter data. There's no cross-validation of meter readings. + +**Mitigation Options:** +1. **Cross-utility meter attestation:** Utilities share signed meter data with each other +2. **Third-party meter certification:** Smart meters sign data directly, removing utility as intermediary +3. **Periodic reconciliation:** Utilities cross-check allocations after the fact + +### Goal: Fewer Actors / Faster Adoption + +**Assessment: Achieved** + +- No need to create and regulate a central exchange +- Each utility can adopt at its own pace +- Same-utility trades work immediately; cross-utility trades require bilateral agreements + +--- + +## Recommendations + +### When to Use Central Ledger Approach + +1. **Regulatory requirement:** If regulators require a central market operator +2. **High trade volumes:** If allocation consistency is critical and disputes are frequent +3. **Existing exchange infrastructure:** If a suitable exchange already exists + +### When to Use Decentralized Approach + +1. **Privacy is paramount:** If utilities or regulators are concerned about data centralization +2. **Gradual rollout:** If you want utilities to adopt incrementally +3. **No central authority:** If cross-jurisdiction or no regulator mandate + +### Hybrid Approaches + +A hybrid is possible: + +1. **Decentralized by default:** Most trades use cascading calls +2. **Optional central reconciliation:** A central service periodically reconciles utility ledgers to catch discrepancies +3. **Central arbitration only:** Central exchange only involved for disputes, not routine trades + +--- + +## Summary + +| Dimension | Central Ledger | Decentralized | Winner | +|-----------|---------------|---------------|--------| +| **Privacy** | Low | High | Decentralized | +| **Resilience** | Lower | Higher | Decentralized | +| **Consistency** | Strong | Weaker | Central | +| **Regulatory simplicity** | More complex | Simpler | Decentralized | +| **Implementation effort** | Moderate | Higher | Central | +| **Proof of performance** | Strong (central verification) | Partial (signature chain) | Central | +| **Market entry barriers** | Higher | Lower | Decentralized | + +**Bottom Line:** The decentralized approach trades some consistency and proof-of-delivery guarantees for significant gains in privacy, resilience, and regulatory simplicity. It's a reasonable choice when privacy concerns outweigh the need for strong centralized verification, or when creating a central exchange is impractical. + +--- + +## Open Questions for Both Approaches + +1. **Financial settlement:** Neither approach fully addresses how money moves from buyer to seller. Both documents discuss options (clearing house, escrow, bill presentation) but don't mandate one. + +2. **Cross-border trades:** If utilities span national borders, which approach handles regulatory differences better? + +3. **Smart meter trust:** Both approaches trust meter readings. If a meter is tampered with, both fail. Should smart meters sign their own data? + +4. **Scaling:** How do both approaches handle millions of daily trades? Central ledger has scaling concerns; decentralized has coordination overhead. + +--- + +## References + +- [Original Central Ledger Approach](./Inter_energy_retailer_P2P_trading_draft.md) +- [Alternative Decentralized Approach](./Inter_energy_retailer_P2P_trading_alt_draft.md) diff --git a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md new file mode 100644 index 00000000..39255fdf --- /dev/null +++ b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md @@ -0,0 +1,465 @@ +# Inter-Energy Retailer P2P Energy Trading (Decentralized Approach) + +## Overview + +This document describes an alternative approach to inter-energy retailer P2P trading that **eliminates the need for a central trade exchange/ledger**. Instead, each utility maintains its own ledger for its customers, and trust is established through cascading Beckn protocol calls with multi-party digital signatures. + +For the original approach using a central ledger, see [Inter_energy_retailer_P2P_trading_draft.md](./Inter_energy_retailer_P2P_trading_draft.md). + +For a detailed comparison of both approaches, see [Central_vs_Decentralized_Ledger_Comparison.md](./Central_vs_Decentralized_Ledger_Comparison.md). + +--- + +## Scenario + +P2P trading between prosumers belonging to different energy retailers/distribution utilities (discoms). Each discom handles routine activities: providing electricity connections, certifying meters, billing, maintaining grid infrastructure, and ensuring grid resilience within their jurisdiction. + +**Example:** Prosumer P1 (Meter ID: M1, Utility A) sells electricity to Prosumer P7 (Meter ID: M7, Utility B). + +--- + +## Key Architectural Difference + +| Aspect | Central Ledger Approach | Decentralized Approach | +|--------|------------------------|------------------------| +| Trade records | Single central ledger (Trade Exchange) | Each utility maintains its own ledger | +| Trust model | All parties trust the central ledger | Multi-party signatures create distributed proof | +| Trading limits | Central ledger tracks all limits | Each utility tracks only its own customers' limits | +| Reconciliation | Central ledger allocates actual energy | Each utility allocates for its own customers | +| Privacy | Central entity sees all trade details | Each utility only sees trades involving its customers | + +--- + +## Actors + +| # | Actor | Role | Beckn Role | +|---|-------|------|------------| +| 1 | **BuyerTP** | Consumer's trading platform | BAP (Beckn Application Platform) | +| 2 | **SellerTP** | Producer's trading platform | BPP (Beckn Provider Platform) | +| 3 | **BuyerUtility** | Buyer's energy retailer/distribution company | BPP (for limit checks and settlement) | +| 4 | **SellerUtility** | Seller's energy retailer/distribution company | BPP (for limit checks and settlement) | +| 5 | **Buyer** | Energy consumer in P2P trade | End user | +| 6 | **Seller** | Energy producer in P2P trade | End user | + +> **Note:** When buyer and seller are with the **same utility**, the flow simplifies naturally - BuyerUtility and SellerUtility collapse into a single entity, reducing the number of hops while maintaining the same protocol structure. + +--- + +## Core Design Principles + +1. **BAP-initiated flows**: All transactions start from BuyerTP (BAP), maintaining Beckn protocol symmetry +2. **Cascading calls**: Multi-party flows cascade through SellerTP to both utilities +3. **Optional utility involvement**: Utility participation in init/confirm is optional but recommended for trading limit enforcement +4. **Distributed ledgers**: Each utility maintains its own ledger for its customers only +5. **Multi-party signatures**: Tamper-proof audit trail through sequential signing +6. **Natural collapse**: Same-utility trades collapse to single-discom flow automatically + +--- + +## Overall Process Flow + +```mermaid +sequenceDiagram + autonumber + participant B as Buyer (P7) + participant BuyerTP as BuyerTP (BAP) + participant SellerTP as SellerTP (BPP) + participant S as Seller (P1) + participant BuyerUtility as BuyerUtility + participant SellerUtility as SellerUtility + + rect rgb(230, 245, 255) + note over BuyerTP,SellerTP: Phase 1: Trade Discovery & Selection + B->>BuyerTP: Search for energy offers + BuyerTP->>SellerTP: /select (choose offer) + SellerTP-->>BuyerTP: /on_select (offer details) + end + + rect rgb(255, 250, 230) + note over BuyerTP,SellerUtility: Phase 2: Trade Initialization (Optional Utility Check) + BuyerTP->>SellerTP: /init (trade details) + BuyerTP-->>BuyerUtility: /init (optional) + SellerTP-->>SellerUtility: /init (optional, cascaded) + SellerUtility-->>SellerTP: /on_init (seller's remaining limit) + BuyerUtility-->>BuyerTP: /on_init (buyer's remaining limit) + SellerTP-->>BuyerTP: /on_init + end + + rect rgb(230, 255, 230) + note over BuyerTP,SellerUtility: Phase 3: Trade Confirmation (Multi-Party Signing) + BuyerTP->>SellerTP: /confirm (trade contract) + SellerTP->>SellerUtility: /confirm (cascaded) + SellerUtility->>BuyerUtility: /confirm (cross-utility) + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility-->>SellerUtility: /on_confirm (signed sealed order) + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility-->>SellerTP: /on_confirm (signed sealed order) + SellerTP->>SellerTP: Sign sealed order + SellerTP-->>BuyerTP: /on_confirm (signed sealed order) + end + + rect rgb(255, 230, 230) + note over S,BuyerUtility: Phase 4: Energy Delivery + S->>SellerUtility: Inject energy + B->>B: Consume energy + end + + rect rgb(245, 230, 255) + note over SellerTP,BuyerUtility: Phase 5: Post-Delivery Allocation + SellerUtility->>SellerUtility: Allocate actual pushed to trades + SellerUtility-->>SellerTP: /on_status (allocated quantity) + BuyerUtility->>BuyerUtility: Allocate actual pulled to trades + BuyerUtility-->>BuyerTP: /on_status (allocated quantity) + end +``` + +--- + +## Phase 1: Trade Discovery and Selection + +This phase follows standard Beckn discovery flow. Buyer searches for energy offers and selects one. + +```mermaid +sequenceDiagram + autonumber + participant B as Buyer + participant BuyerTP as BuyerTP (BAP) + participant SellerTP as SellerTP (BPP) + participant S as Seller + + B->>BuyerTP: Search for energy offers
(delivery window, quantity, location) + BuyerTP->>SellerTP: /select + Note right of SellerTP: Offer: 5 kWh, 2-4 PM,
$0.50/kWh + SellerTP-->>BuyerTP: /on_select
(offer details, seller info) + BuyerTP-->>B: Display offer details +``` + +--- + +## Phase 2: Trade Initialization + +The initialization phase optionally checks trading limits with both utilities. This is optional but recommended to prevent trade failures at confirmation time. + +### Why Check Limits? + +Each utility may impose trading limits on its customers to: +- Manage grid capacity +- Control financial exposure +- Comply with regulatory requirements + +### Initialization Flow + +```mermaid +sequenceDiagram + autonumber + participant BuyerTP as BuyerTP (BAP) + participant BuyerUtility as BuyerUtility + participant SellerTP as SellerTP (BPP) + participant SellerUtility as SellerUtility + + Note over BuyerTP,SellerUtility: Trade: 5 kWh, 2-4 PM, $0.50/kWh + + BuyerTP->>SellerTP: /init (trade details) + + par Optional Utility Limit Checks + BuyerTP->>BuyerUtility: /init (buyer limit check) + BuyerUtility->>BuyerUtility: Look up buyer's
remaining trading limit + BuyerUtility-->>BuyerTP: /on_init
(remaining limit: 20 kWh) + and + SellerTP->>SellerUtility: /init (seller limit check) + SellerUtility->>SellerUtility: Look up seller's
remaining trading limit + SellerUtility-->>SellerTP: /on_init
(remaining limit: 15 kWh) + end + + SellerTP-->>BuyerTP: /on_init
(trade initialized, limits OK) +``` + +### What Each Utility Tracks in Its Own Ledger + +| Data Element | Owner | Description | +|--------------|-------|-------------| +| Customer's trading limit | Customer's utility | Max energy that customer can trade in a period | +| Customer's confirmed trades | Customer's utility | All confirmed trades for the customer | +| Customer's actual delivery/consumption | Customer's utility | Metered data for the customer | +| Customer's allocated trade quantities | Customer's utility | Post-delivery allocation of actuals to trades | + +--- + +## Phase 3: Trade Confirmation (Multi-Party Signing) + +This is the critical phase that establishes trust without a central ledger. The confirmation cascades through all parties, with each adding their signature to create a tamper-proof audit trail. + +### Confirmation Flow + +```mermaid +sequenceDiagram + autonumber + participant BuyerTP as BuyerTP (BAP) + participant SellerTP as SellerTP (BPP) + participant SellerUtility as SellerUtility + participant BuyerUtility as BuyerUtility + + Note over BuyerTP,BuyerUtility: Trade: 5 kWh, 2-4 PM, $0.50/kWh + + BuyerTP->>SellerTP: /confirm (trade contract) + Note right of SellerTP: Contract signed by Buyer + + SellerTP->>SellerUtility: /confirm (cascaded) + Note right of SellerUtility: Contract signed by Buyer + SellerTP + + SellerUtility->>BuyerUtility: /confirm (cross-utility) + Note right of BuyerUtility: Contract signed by Buyer + SellerTP + SellerUtility + + rect rgb(230, 255, 230) + Note over BuyerUtility: BuyerUtility Actions: + BuyerUtility->>BuyerUtility: 1. Verify buyer identity + BuyerUtility->>BuyerUtility: 2. Check buyer's remaining limit + BuyerUtility->>BuyerUtility: 3. Deduct trade qty from limit + BuyerUtility->>BuyerUtility: 4. Log trade in own ledger + BuyerUtility->>BuyerUtility: 5. Sign and seal order + end + + BuyerUtility-->>SellerUtility: /on_confirm
(sealed order with BuyerUtility signature) + + rect rgb(255, 245, 230) + Note over SellerUtility: SellerUtility Actions: + SellerUtility->>SellerUtility: 1. Verify seller identity + SellerUtility->>SellerUtility: 2. Check seller's remaining limit + SellerUtility->>SellerUtility: 3. Deduct trade qty from limit + SellerUtility->>SellerUtility: 4. Log trade in own ledger + SellerUtility->>SellerUtility: 5. Add signature to sealed order + end + + SellerUtility-->>SellerTP: /on_confirm
(sealed order with both utility signatures) + + SellerTP->>SellerTP: Sign sealed order + SellerTP-->>BuyerTP: /on_confirm
(sealed order with all signatures) + + opt Final Acknowledgment + BuyerTP->>BuyerTP: Sign the order + BuyerTP->>SellerTP: /update (accept_on_confirm) + Note over BuyerTP,SellerTP: Order now has 4 signatures:
BuyerTP, SellerTP, BuyerUtility, SellerUtility + end +``` + +### Multi-Party Signature Chain + +By the end of confirmation, the sealed trade order contains: + +| Signature | Attests To | +|-----------|-----------| +| BuyerTP | Buyer's intent to purchase | +| SellerTP | Seller's agreement to supply | +| BuyerUtility | Trade is within buyer's limits, logged in buyer's utility ledger | +| SellerUtility | Trade is within seller's limits, logged in seller's utility ledger | + +This creates a **tamper-proof, distributed proof of trade commitment** without requiring a central ledger. + +--- + +## Phase 4: Energy Delivery + +Energy delivery follows the same physical process as the central ledger approach. The key difference is that each utility records meter data in its own ledger. + +```mermaid +sequenceDiagram + autonumber + participant S as Seller (P1) + participant SM_S as Seller's
Smart Meter + participant SellerUtility as SellerUtility + participant BuyerUtility as BuyerUtility + participant SM_B as Buyer's
Smart Meter + participant B as Buyer (P7) + + Note over S,B: Scheduled Delivery Window Begins + + S->>SM_S: Generate/inject energy + SM_S->>SellerUtility: Report injection + + SellerUtility->>SellerUtility: Grid security check + alt Grid stable + SellerUtility->>SellerUtility: Permit injection + SM_S->>SM_S: Record injection (kWh, timestamp) + + SM_B->>BuyerUtility: Report consumption + SM_B->>SM_B: Record consumption (kWh, timestamp) + else Grid unstable + SellerUtility-->>SM_S: Reject/limit injection + end + + Note over S,B: Scheduled Delivery Window Ends +``` + +--- + +## Phase 5: Post-Delivery Allocation and Status + +After the delivery window, each utility performs allocation independently for its own customers and notifies the relevant trading platforms. + +### Why Allocation Matters + +A prosumer may have multiple trades in the same delivery window but inject/consume less than the total contracted amount. Each utility must allocate actual meter readings to specific trades to determine: +- What quantity was actually delivered/received for each trade +- What to include in billing adjustments +- Whether penalties apply for under-delivery + +### Allocation Flow + +```mermaid +sequenceDiagram + autonumber + participant SellerTP as SellerTP (BPP) + participant SellerUtility as SellerUtility + participant BuyerUtility as BuyerUtility + participant BuyerTP as BuyerTP (BAP) + + Note over SellerUtility: Verification Cycle (e.g., every X hours) + + rect rgb(255, 245, 230) + Note over SellerUtility: Seller-Side Allocation + SellerUtility->>SellerUtility: Get all confirmed trades for
seller in delivery period + SellerUtility->>SellerUtility: Get actual meter injection data + SellerUtility->>SellerUtility: Allocate actuals to trades
(FIFO or pro-rata) + SellerUtility-->>SellerTP: /on_status
(allocated qty per trade) + Note right of SellerTP: Seller knows what to expect
in discom bill adjustment + end + + opt Cross-Utility Visibility + SellerUtility-->>BuyerUtility: /on_status
(seller's allocated quantities) + end + + rect rgb(230, 245, 255) + Note over BuyerUtility: Buyer-Side Allocation + BuyerUtility->>BuyerUtility: Get all confirmed trades for
buyer in delivery period + BuyerUtility->>BuyerUtility: Get actual meter consumption data + BuyerUtility->>BuyerUtility: Allocate actuals to trades
(FIFO or pro-rata) + BuyerUtility-->>BuyerTP: /on_status
(allocated qty per trade) + Note right of BuyerTP: Buyer knows what to expect
in discom bill adjustment + end + + opt Cross-Utility Visibility + BuyerUtility-->>SellerUtility: /on_status
(buyer's allocated quantities) + end +``` + +### Allocation Example (FIFO) + +**Seller P1's trades for delivery window 2-4 PM:** + +| Trade | Trade Time | Contracted Qty | Priority | +|-------|------------|----------------|----------| +| T1 (with P7) | 9:00 AM | 5 kWh | 1st | +| T2 (with P8) | 9:30 AM | 4 kWh | 2nd | +| **Total** | | **9 kWh** | | + +**Actual injection: 7 kWh** + +**SellerUtility allocation (FIFO):** + +| Trade | Contracted | Allocated | Status | +|-------|------------|-----------|--------| +| T1 | 5 kWh | 5 kWh | Full delivery | +| T2 | 4 kWh | 2 kWh | Partial delivery | + +SellerUtility sends `/on_status` to SellerTP with these allocated quantities. + +--- + +## Phase 6: Billing and Settlement + +Each utility handles billing for its own customers, using only its own ledger data. + +```mermaid +sequenceDiagram + autonumber + participant S as Seller (P1) + participant SellerUtility as SellerUtility + participant BuyerUtility as BuyerUtility + participant B as Buyer (P7) + + Note over SellerUtility,BuyerUtility: Monthly Billing Cycle + + rect rgb(255, 245, 230) + Note over SellerUtility: Seller's Bill + SellerUtility->>SellerUtility: Look up P2P trades from own ledger + SellerUtility->>SellerUtility: Calculate: Regular bill
- P2P sold energy credit
+ Wheeling charges + SellerUtility->>S: Monthly bill + S->>SellerUtility: Pay bill + end + + rect rgb(230, 245, 255) + Note over BuyerUtility: Buyer's Bill + BuyerUtility->>BuyerUtility: Look up P2P trades from own ledger + BuyerUtility->>BuyerUtility: Calculate: Regular bill
- P2P purchased energy
+ Wheeling charges + BuyerUtility->>B: Monthly bill + B->>BuyerUtility: Pay bill + end +``` + +### Anti-Double-Billing + +- **Buyer (P7):** BuyerUtility excludes P2P energy from regular charges (buyer already paid seller directly) +- **Seller (P1):** SellerUtility excludes P2P energy from injection credit (seller already received payment from buyer) + +--- + +## Same-Utility Collapse + +When buyer and seller are with the **same utility**, the flow simplifies naturally: + +```mermaid +sequenceDiagram + autonumber + participant BuyerTP as BuyerTP (BAP) + participant SellerTP as SellerTP (BPP) + participant Utility as Utility
(same for both) + + BuyerTP->>SellerTP: /confirm (trade contract) + SellerTP->>Utility: /confirm (single utility call) + + Utility->>Utility: Check both limits + Utility->>Utility: Log single trade entry + Utility->>Utility: Sign and seal order + + Utility-->>SellerTP: /on_confirm + SellerTP-->>BuyerTP: /on_confirm + + Note over BuyerTP,Utility: Same protocol, fewer hops +``` + +The protocol structure remains identical, but: +- Only one utility is involved +- No cross-utility confirm/on_confirm +- Single ledger entry (but from same utility's perspective for both parties) + +--- + +## Comparison with Central Ledger Approach + +| Aspect | Central Ledger | Decentralized (This Approach) | +|--------|---------------|------------------------------| +| **Trust model** | All trust central exchange | Multi-party signatures | +| **Privacy** | Central entity sees all trades | Each utility sees only its customers' trades | +| **Single point of failure** | Yes (central ledger) | No | +| **Cross-utility coordination** | Via central ledger queries | Via cascading Beckn calls | +| **Regulatory complexity** | Central exchange needs regulation | Each utility self-regulates | +| **Deployment** | Requires new central infrastructure | Builds on existing utility systems | +| **Dispute resolution** | Central ledger is arbiter | Multi-party signatures provide evidence | + +--- + +## Open Questions + +1. **Signature Format:** What cryptographic format for multi-party signatures? (JWS, EdDSA, etc.) + +2. **Allocation Consistency:** If FIFO allocation differs between utilities for the same trade (due to data timing), how to reconcile? + +3. **Cross-Utility Trust:** What compels SellerUtility to forward `/confirm` to BuyerUtility honestly? + +4. **Offline Handling:** If a utility is temporarily unavailable during confirmation cascade, how to handle? + +5. **Audit Trail Access:** How do trading platforms access the full signature chain for disputes? + +--- + +[^1]: Non-exhaustive From b385363dabedf057b6def6d280aec292a707932c Mon Sep 17 00:00:00 2001 From: Ameet Deshpande Date: Sun, 18 Jan 2026 08:45:37 +0530 Subject: [PATCH 2/8] fixed some optional flows to required --- .../Inter_energy_retailer_P2P_trading_alt_draft.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md index 39255fdf..8a7bf13f 100644 --- a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md +++ b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md @@ -82,7 +82,7 @@ sequenceDiagram SellerTP-->>SellerUtility: /init (optional, cascaded) SellerUtility-->>SellerTP: /on_init (seller's remaining limit) BuyerUtility-->>BuyerTP: /on_init (buyer's remaining limit) - SellerTP-->>BuyerTP: /on_init + SellerTP->>BuyerTP: /on_init end rect rgb(230, 255, 230) @@ -95,7 +95,7 @@ sequenceDiagram SellerUtility->>SellerUtility: Deduct from seller limit, log trade SellerUtility-->>SellerTP: /on_confirm (signed sealed order) SellerTP->>SellerTP: Sign sealed order - SellerTP-->>BuyerTP: /on_confirm (signed sealed order) + SellerTP->>BuyerTP: /on_confirm (signed sealed order) end rect rgb(255, 230, 230) @@ -130,8 +130,8 @@ sequenceDiagram B->>BuyerTP: Search for energy offers
(delivery window, quantity, location) BuyerTP->>SellerTP: /select Note right of SellerTP: Offer: 5 kWh, 2-4 PM,
$0.50/kWh - SellerTP-->>BuyerTP: /on_select
(offer details, seller info) - BuyerTP-->>B: Display offer details + SellerTP->>BuyerTP: /on_select
(offer details, seller info) + BuyerTP->>B: Display offer details ``` --- @@ -171,7 +171,7 @@ sequenceDiagram SellerUtility-->>SellerTP: /on_init
(remaining limit: 15 kWh) end - SellerTP-->>BuyerTP: /on_init
(trade initialized, limits OK) + SellerTP->>BuyerTP: /on_init
(trade initialized, limits OK) ``` ### What Each Utility Tracks in Its Own Ledger From a6261f4467f85623837b7dacdde14c79bfaf7e60 Mon Sep 17 00:00:00 2001 From: Ameet Deshpande Date: Sun, 18 Jan 2026 14:15:36 +0530 Subject: [PATCH 3/8] refined flows in sequence diagram in decentralized ledger --- ...r_energy_retailer_P2P_trading_alt_draft.md | 281 +++++++++++++----- 1 file changed, 214 insertions(+), 67 deletions(-) diff --git a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md index 8a7bf13f..8765fa7a 100644 --- a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md +++ b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md @@ -72,36 +72,75 @@ sequenceDiagram note over BuyerTP,SellerTP: Phase 1: Trade Discovery & Selection B->>BuyerTP: Search for energy offers BuyerTP->>SellerTP: /select (choose offer) - SellerTP-->>BuyerTP: /on_select (offer details) + SellerTP->>BuyerTP: /on_select (offer details) end rect rgb(255, 250, 230) - note over BuyerTP,SellerUtility: Phase 2: Trade Initialization (Optional Utility Check) + note over BuyerTP,SellerUtility: Phase 2: Trade Initialization BuyerTP->>SellerTP: /init (trade details) - BuyerTP-->>BuyerUtility: /init (optional) - SellerTP-->>SellerUtility: /init (optional, cascaded) - SellerUtility-->>SellerTP: /on_init (seller's remaining limit) - BuyerUtility-->>BuyerTP: /on_init (buyer's remaining limit) + opt Optional Utility Limit Checks + BuyerTP-->>BuyerUtility: /init (if trading limits unknown OR multi-platform onboarding) + SellerTP-->>SellerUtility: /init (cascaded) + SellerUtility-->>SellerTP: /on_init (seller's remaining limit) + BuyerUtility-->>BuyerTP: /on_init (buyer's remaining limit) + end SellerTP->>BuyerTP: /on_init end rect rgb(230, 255, 230) - note over BuyerTP,SellerUtility: Phase 3: Trade Confirmation (Multi-Party Signing) + note over BuyerTP,SellerUtility: Phase 3: Trade Confirmation BuyerTP->>SellerTP: /confirm (trade contract) - SellerTP->>SellerUtility: /confirm (cascaded) - SellerUtility->>BuyerUtility: /confirm (cross-utility) - BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade - BuyerUtility-->>SellerUtility: /on_confirm (signed sealed order) - SellerUtility->>SellerUtility: Deduct from seller limit, log trade - SellerUtility-->>SellerTP: /on_confirm (signed sealed order) - SellerTP->>SellerTP: Sign sealed order - SellerTP->>BuyerTP: /on_confirm (signed sealed order) + alt Non-blocking (Recommended) + SellerTP->>BuyerTP: /on_confirm (trade confirmed) + par Inform utilities + SellerTP->>SellerUtility: /confirm (inform utility) + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility-->>SellerTP: /on_confirm (acknowledged) + and + SellerTP->>BuyerUtility: /confirm (inform utility) + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility-->>SellerTP: /on_confirm (acknowledged) + end + else Blocking + par Utility confirmations + SellerTP->>SellerUtility: /confirm + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility->>SellerTP: /on_confirm (signed) + and + SellerTP->>BuyerUtility: /confirm + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility->>SellerTP: /on_confirm (signed) + end + SellerTP->>BuyerTP: /on_confirm (signed sealed order) + end + end + + opt Phase 3b: Trade Update (e.g., scheduled outage) + BuyerUtility->>SellerTP: /update (cancel/curtail trade) + par Cascade update + SellerTP->>SellerUtility: /update (notify of change) + SellerUtility->>SellerUtility: Update trade in ledger + SellerUtility-->>SellerTP: /on_update (acknowledged) + and + SellerTP->>BuyerTP: /update (notify of change) + BuyerTP->>BuyerTP: Update trade status + BuyerTP-->>SellerTP: /on_update (acknowledged) + end + SellerTP->>BuyerUtility: /on_update (update confirmed) + BuyerUtility->>BuyerUtility: Update trade in ledger end rect rgb(255, 230, 230) note over S,BuyerUtility: Phase 4: Energy Delivery - S->>SellerUtility: Inject energy - B->>B: Consume energy + S->>SellerUtility: Request to inject energy + SellerUtility->>SellerUtility: Grid security check + alt Grid stable + SellerUtility->>S: Permit injection + S->>S: Inject energy into grid + B->>B: Consume energy + else Grid unstable + SellerUtility-->>S: Reject/limit injection + end end rect rgb(245, 230, 255) @@ -111,6 +150,14 @@ sequenceDiagram BuyerUtility->>BuyerUtility: Allocate actual pulled to trades BuyerUtility-->>BuyerTP: /on_status (allocated quantity) end + + rect rgb(255, 240, 245) + note over S,B: Phase 6: Billing & Settlement + SellerUtility->>S: Monthly bill (excl. P2P sold + wheeling) + S->>SellerUtility: Pay bill + BuyerUtility->>B: Monthly bill (excl. P2P bought + wheeling) + B->>BuyerUtility: Pay bill + end ``` --- @@ -161,14 +208,16 @@ sequenceDiagram BuyerTP->>SellerTP: /init (trade details) - par Optional Utility Limit Checks - BuyerTP->>BuyerUtility: /init (buyer limit check) - BuyerUtility->>BuyerUtility: Look up buyer's
remaining trading limit - BuyerUtility-->>BuyerTP: /on_init
(remaining limit: 20 kWh) - and - SellerTP->>SellerUtility: /init (seller limit check) - SellerUtility->>SellerUtility: Look up seller's
remaining trading limit - SellerUtility-->>SellerTP: /on_init
(remaining limit: 15 kWh) + opt Optional Utility Limit Checks + par Parallel limit checks + BuyerTP->>BuyerUtility: /init (buyer limit check) + BuyerUtility->>BuyerUtility: Look up buyer's
remaining trading limit + BuyerUtility-->>BuyerTP: /on_init
(remaining limit: 20 kWh) + and + SellerTP->>SellerUtility: /init (seller limit check) + SellerUtility->>SellerUtility: Look up seller's
remaining trading limit + SellerUtility-->>SellerTP: /on_init
(remaining limit: 15 kWh) + end end SellerTP->>BuyerTP: /on_init
(trade initialized, limits OK) @@ -185,9 +234,16 @@ sequenceDiagram --- -## Phase 3: Trade Confirmation (Multi-Party Signing) +## Phase 3: Trade Confirmation -This is the critical phase that establishes trust without a central ledger. The confirmation cascades through all parties, with each adding their signature to create a tamper-proof audit trail. +This is the critical phase that establishes trust without a central ledger. SellerTP coordinates with both utilities in parallel, and each utility logs the trade and (optionally) signs the order. + +Two modes are supported: + +| Mode | When to Use | Trade Confirmed | +|------|-------------|-----------------| +| **Non-blocking (Recommended)** | Utilities cannot block trades; they are informed for record-keeping | Immediately after SellerTP receives `/confirm` | +| **Blocking** | Utilities must approve before trade is confirmed | After both utilities respond with `/on_confirm` | ### Confirmation Flow @@ -202,49 +258,43 @@ sequenceDiagram Note over BuyerTP,BuyerUtility: Trade: 5 kWh, 2-4 PM, $0.50/kWh BuyerTP->>SellerTP: /confirm (trade contract) - Note right of SellerTP: Contract signed by Buyer - - SellerTP->>SellerUtility: /confirm (cascaded) - Note right of SellerUtility: Contract signed by Buyer + SellerTP - - SellerUtility->>BuyerUtility: /confirm (cross-utility) - Note right of BuyerUtility: Contract signed by Buyer + SellerTP + SellerUtility - rect rgb(230, 255, 230) - Note over BuyerUtility: BuyerUtility Actions: - BuyerUtility->>BuyerUtility: 1. Verify buyer identity - BuyerUtility->>BuyerUtility: 2. Check buyer's remaining limit - BuyerUtility->>BuyerUtility: 3. Deduct trade qty from limit - BuyerUtility->>BuyerUtility: 4. Log trade in own ledger - BuyerUtility->>BuyerUtility: 5. Sign and seal order - end - - BuyerUtility-->>SellerUtility: /on_confirm
(sealed order with BuyerUtility signature) - - rect rgb(255, 245, 230) - Note over SellerUtility: SellerUtility Actions: - SellerUtility->>SellerUtility: 1. Verify seller identity - SellerUtility->>SellerUtility: 2. Check seller's remaining limit - SellerUtility->>SellerUtility: 3. Deduct trade qty from limit - SellerUtility->>SellerUtility: 4. Log trade in own ledger - SellerUtility->>SellerUtility: 5. Add signature to sealed order + alt Non-blocking (Recommended) + SellerTP->>BuyerTP: /on_confirm (trade confirmed) + par Inform utilities + SellerTP->>SellerUtility: /confirm (inform utility) + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility-->>SellerTP: /on_confirm (acknowledged) + and + SellerTP->>BuyerUtility: /confirm (inform utility) + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility-->>SellerTP: /on_confirm (acknowledged) + end + else Blocking + par Utility confirmations + SellerTP->>SellerUtility: /confirm + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility->>SellerTP: /on_confirm (signed) + and + SellerTP->>BuyerUtility: /confirm + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility->>SellerTP: /on_confirm (signed) + end + SellerTP->>BuyerTP: /on_confirm (signed sealed order) end +``` - SellerUtility-->>SellerTP: /on_confirm
(sealed order with both utility signatures) - - SellerTP->>SellerTP: Sign sealed order - SellerTP-->>BuyerTP: /on_confirm
(sealed order with all signatures) +### What Each Utility Does on `/confirm` - opt Final Acknowledgment - BuyerTP->>BuyerTP: Sign the order - BuyerTP->>SellerTP: /update (accept_on_confirm) - Note over BuyerTP,SellerTP: Order now has 4 signatures:
BuyerTP, SellerTP, BuyerUtility, SellerUtility - end -``` +1. Verify customer identity +2. Check customer's remaining trading limit +3. Deduct trade quantity from limit +4. Log trade in own ledger +5. (Blocking mode only) Sign the order -### Multi-Party Signature Chain +### Multi-Party Signature Chain (Blocking Mode) -By the end of confirmation, the sealed trade order contains: +In blocking mode, the sealed trade order contains signatures from all parties: | Signature | Attests To | |-----------|-----------| @@ -255,12 +305,106 @@ By the end of confirmation, the sealed trade order contains: This creates a **tamper-proof, distributed proof of trade commitment** without requiring a central ledger. +### Non-blocking vs Blocking Trade-offs + +| Aspect | Non-blocking | Blocking | +|--------|--------------|----------| +| **Latency** | Lower (immediate confirmation) | Higher (waits for utilities) | +| **Utility control** | Utilities informed, cannot block | Utilities can reject trades | +| **Trust model** | Trust SellerTP to inform utilities | Full multi-party consensus | +| **Use case** | High-frequency trading, trusted platforms | Regulatory requirement for utility approval | + +--- + +## Phase 3b: Trade Update (Optional) + +After a trade is confirmed but before energy delivery, a utility may need to modify or cancel the trade due to operational reasons (e.g., scheduled outage, grid constraints, regulatory intervention). + +### Why Trade Updates? + +- **Scheduled outages:** Utility plans maintenance that affects the delivery window +- **Grid constraints:** Forecasted congestion or stability issues +- **Regulatory intervention:** Compliance requirements or emergency orders +- **Meter issues:** Problems detected with buyer's or seller's metering equipment + +### Update Flow + +The initiating utility (in this example, BuyerUtility) sends `/update` to SellerTP, which coordinates the update across all parties. + +```mermaid +sequenceDiagram + autonumber + participant BuyerUtility as BuyerUtility + participant SellerTP as SellerTP (BPP) + participant SellerUtility as SellerUtility + participant BuyerTP as BuyerTP (BAP) + + Note over BuyerUtility,BuyerTP: Trade update triggered (e.g., scheduled outage) + + BuyerUtility->>SellerTP: /update (cancel/curtail trade) + Note right of SellerTP: Update reason: scheduled outage
Action: cancel OR curtail to X kWh + + par Cascade update to all parties + SellerTP->>SellerUtility: /update (notify of change) + SellerUtility->>SellerUtility: Update trade in ledger + SellerUtility-->>SellerTP: /on_update (acknowledged) + and + SellerTP->>BuyerTP: /update (notify of change) + BuyerTP->>BuyerTP: Update trade status + BuyerTP-->>SellerTP: /on_update (acknowledged) + end + + SellerTP->>BuyerUtility: /on_update (update confirmed) + BuyerUtility->>BuyerUtility: Update trade in ledger + + Note over BuyerUtility,BuyerTP: All parties now have consistent view of modified trade +``` + +### Update Types + +| Update Type | Description | Effect on Trade | +|-------------|-------------|-----------------| +| **Cancel** | Full cancellation of the trade | Trade marked as cancelled; limits restored | +| **Curtail** | Reduce contracted quantity | Trade quantity reduced; partial limits restored | +| **Reschedule** | Change delivery window | New delivery window; same quantity | + +### What Each Party Does on `/update` + +| Party | Actions | +|-------|---------| +| **SellerUtility** | Update trade in ledger; adjust seller's trading limit if cancelled/curtailed | +| **BuyerTP** | Notify buyer of change; update local trade status | +| **BuyerUtility** | Update trade in ledger; adjust buyer's trading limit if cancelled/curtailed | + +### Update Initiation + +While this example shows BuyerUtility initiating, updates can also be initiated by: + +| Initiator | Route | Use Case | +|-----------|-------|----------| +| **BuyerUtility** | BuyerUtility → SellerTP → (SellerUtility, BuyerTP) | Outage on buyer's side | +| **SellerUtility** | SellerUtility → SellerTP → (BuyerUtility, BuyerTP) | Outage on seller's side | +| **BuyerTP** | BuyerTP → SellerTP → (SellerUtility, BuyerUtility) | Buyer requests cancellation | + +In all cases, SellerTP acts as the coordination hub, ensuring all parties receive the update and acknowledge it. + --- ## Phase 4: Energy Delivery +*(Could be anywhere from a few hours to a few days later)* + Energy delivery follows the same physical process as the central ledger approach. The key difference is that each utility records meter data in its own ledger. +### Energy Injection + +- At scheduled time, seller injects energy into the grid +- Seller's utility performs grid security checks and permits injection only if grid stability is maintained + +### Energy Consumption + +- Buyer consumes energy as usual during the delivery window + ```mermaid sequenceDiagram autonumber @@ -274,17 +418,20 @@ sequenceDiagram Note over S,B: Scheduled Delivery Window Begins S->>SM_S: Generate/inject energy - SM_S->>SellerUtility: Report injection + SM_S->>SellerUtility: Report injection request SellerUtility->>SellerUtility: Grid security check alt Grid stable SellerUtility->>SellerUtility: Permit injection - SM_S->>SM_S: Record injection (kWh, timestamp) + SM_S->>SM_S: Energy injected into grid - SM_B->>BuyerUtility: Report consumption + SM_B->>B: Energy consumed + + SM_S->>SM_S: Record injection (kWh, timestamp) SM_B->>SM_B: Record consumption (kWh, timestamp) else Grid unstable SellerUtility-->>SM_S: Reject/limit injection + Note over SellerUtility: Grid stability
takes priority end Note over S,B: Scheduled Delivery Window Ends From e1bb27a3af4e1c6eb5ac32d75fc2bdf1b746ffb8 Mon Sep 17 00:00:00 2001 From: Ameet Deshpande Date: Sun, 18 Jan 2026 14:26:44 +0530 Subject: [PATCH 4/8] more refinements to seq diagram --- ...r_energy_retailer_P2P_trading_alt_draft.md | 55 ++++++++++++------- 1 file changed, 36 insertions(+), 19 deletions(-) diff --git a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md index 8765fa7a..b413f61c 100644 --- a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md +++ b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md @@ -14,7 +14,7 @@ For a detailed comparison of both approaches, see [Central_vs_Decentralized_Ledg P2P trading between prosumers belonging to different energy retailers/distribution utilities (discoms). Each discom handles routine activities: providing electricity connections, certifying meters, billing, maintaining grid infrastructure, and ensuring grid resilience within their jurisdiction. -**Example:** Prosumer P1 (Meter ID: M1, Utility A) sells electricity to Prosumer P7 (Meter ID: M7, Utility B). +**Example:** A seller (Meter ID: M1, Utility A) sells electricity to a buyer (Meter ID: M7, Utility B). --- @@ -61,10 +61,10 @@ P2P trading between prosumers belonging to different energy retailers/distributi ```mermaid sequenceDiagram autonumber - participant B as Buyer (P7) + participant B as Buyer participant BuyerTP as BuyerTP (BAP) participant SellerTP as SellerTP (BPP) - participant S as Seller (P1) + participant S as Seller participant BuyerUtility as BuyerUtility participant SellerUtility as SellerUtility @@ -79,7 +79,7 @@ sequenceDiagram note over BuyerTP,SellerUtility: Phase 2: Trade Initialization BuyerTP->>SellerTP: /init (trade details) opt Optional Utility Limit Checks - BuyerTP-->>BuyerUtility: /init (if trading limits unknown OR multi-platform onboarding) + BuyerTP-->>BuyerUtility: /init (if trading limits unknown OR multi-platform onboarding is allowed) SellerTP-->>SellerUtility: /init (cascaded) SellerUtility-->>SellerTP: /on_init (seller's remaining limit) BuyerUtility-->>BuyerTP: /on_init (buyer's remaining limit) @@ -95,11 +95,11 @@ sequenceDiagram par Inform utilities SellerTP->>SellerUtility: /confirm (inform utility) SellerUtility->>SellerUtility: Deduct from seller limit, log trade - SellerUtility-->>SellerTP: /on_confirm (acknowledged) + SellerUtility->>SellerTP: /on_confirm (acknowledged) and SellerTP->>BuyerUtility: /confirm (inform utility) BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade - BuyerUtility-->>SellerTP: /on_confirm (acknowledged) + BuyerUtility->>SellerTP: /on_confirm (acknowledged) end else Blocking par Utility confirmations @@ -115,7 +115,7 @@ sequenceDiagram end end - opt Phase 3b: Trade Update (e.g., scheduled outage) + opt Phase 3b: Trade Update (e.g., scheduled outage/congestion/trading limit violation) BuyerUtility->>SellerTP: /update (cancel/curtail trade) par Cascade update SellerTP->>SellerUtility: /update (notify of change) @@ -153,9 +153,10 @@ sequenceDiagram rect rgb(255, 240, 245) note over S,B: Phase 6: Billing & Settlement - SellerUtility->>S: Monthly bill (excl. P2P sold + wheeling) + B->>S: Pay for P2P trade (post-delivery) + SellerUtility->>S: Monthly bill (excl. P2P sold, incl. wheeling) S->>SellerUtility: Pay bill - BuyerUtility->>B: Monthly bill (excl. P2P bought + wheeling) + BuyerUtility->>B: Monthly bill (excl. P2P bought, incl. wheeling) B->>BuyerUtility: Pay bill end ``` @@ -408,12 +409,12 @@ Energy delivery follows the same physical process as the central ledger approach ```mermaid sequenceDiagram autonumber - participant S as Seller (P1) + participant S as Seller participant SM_S as Seller's
Smart Meter participant SellerUtility as SellerUtility participant BuyerUtility as BuyerUtility participant SM_B as Buyer's
Smart Meter - participant B as Buyer (P7) + participant B as Buyer Note over S,B: Scheduled Delivery Window Begins @@ -491,12 +492,12 @@ sequenceDiagram ### Allocation Example (FIFO) -**Seller P1's trades for delivery window 2-4 PM:** +**Seller's trades for delivery window 2-4 PM:** | Trade | Trade Time | Contracted Qty | Priority | |-------|------------|----------------|----------| -| T1 (with P7) | 9:00 AM | 5 kWh | 1st | -| T2 (with P8) | 9:30 AM | 4 kWh | 2nd | +| T1 (with Buyer A) | 9:00 AM | 5 kWh | 1st | +| T2 (with Buyer B) | 9:30 AM | 4 kWh | 2nd | | **Total** | | **9 kWh** | | **Actual injection: 7 kWh** @@ -514,15 +515,23 @@ SellerUtility sends `/on_status` to SellerTP with these allocated quantities. ## Phase 6: Billing and Settlement -Each utility handles billing for its own customers, using only its own ledger data. +Settlement involves two separate payment flows: +1. **P2P payment:** Buyer pays Seller directly for the traded energy (post-delivery) +2. **Utility billing:** Each utility bills its customer, excluding P2P energy but including wheeling charges ```mermaid sequenceDiagram autonumber - participant S as Seller (P1) + participant S as Seller participant SellerUtility as SellerUtility participant BuyerUtility as BuyerUtility - participant B as Buyer (P7) + participant B as Buyer + + rect rgb(240, 255, 240) + Note over S,B: P2P Settlement (Post-Delivery) + B->>S: Pay for P2P trade
(allocated qty × agreed price) + S-->>B: Payment confirmed + end Note over SellerUtility,BuyerUtility: Monthly Billing Cycle @@ -543,10 +552,18 @@ sequenceDiagram end ``` +### P2P Payment + +The buyer pays the seller directly for the P2P trade after delivery is confirmed (via `/on_status`). Payment amount is based on: +- **Allocated quantity** (from Phase 5, may be less than contracted if under-delivery) +- **Agreed price** (from the confirmed trade contract) + +Payment mechanism options include direct bank transfer, UPI, or platform-mediated escrow (see original document for detailed settlement options). + ### Anti-Double-Billing -- **Buyer (P7):** BuyerUtility excludes P2P energy from regular charges (buyer already paid seller directly) -- **Seller (P1):** SellerUtility excludes P2P energy from injection credit (seller already received payment from buyer) +- **Buyer:** BuyerUtility excludes P2P energy from regular charges (buyer already paid seller directly) +- **Seller:** SellerUtility excludes P2P energy from injection credit (seller already received payment from buyer) --- From 370721a6bc7930e5786fc1099b753f06f59eae87 Mon Sep 17 00:00:00 2001 From: Ameet Deshpande Date: Sun, 18 Jan 2026 15:00:10 +0530 Subject: [PATCH 5/8] update core principles --- .../Inter_energy_retailer_P2P_trading_alt_draft.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md index b413f61c..20573a53 100644 --- a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md +++ b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md @@ -47,12 +47,11 @@ P2P trading between prosumers belonging to different energy retailers/distributi ## Core Design Principles -1. **BAP-initiated flows**: All transactions start from BuyerTP (BAP), maintaining Beckn protocol symmetry +1. **BuyerTP-initiated, SellerTP-orchestrated flows**: All transactions start from BuyerTP (BAP), and are orchestrated by SellerTP, including informing multiple utilities if needed. Utilities do not need to ordinate directly with eachother. 2. **Cascading calls**: Multi-party flows cascade through SellerTP to both utilities -3. **Optional utility involvement**: Utility participation in init/confirm is optional but recommended for trading limit enforcement +3. **Utility involvement patterns**: Utility participation within init is optional, and only needed in case customers or trading platforms don't have the trading limits imposed by the utility. After the trade is confirmed, a non-blocking intimation is required to sent to utility informing them of trade, so they can avoid double-billing and compute wheeling and deviation charges, post delivery. 4. **Distributed ledgers**: Each utility maintains its own ledger for its customers only -5. **Multi-party signatures**: Tamper-proof audit trail through sequential signing -6. **Natural collapse**: Same-utility trades collapse to single-discom flow automatically +5. **Natural collapse**: Same-utility trades collapse to single-discom flow automatically --- From e577043540898df7300cf95655248e6231e02583 Mon Sep 17 00:00:00 2001 From: Ameet Deshpande Date: Mon, 19 Jan 2026 00:26:56 +0530 Subject: [PATCH 6/8] added new implementation guide for inter-utility p2p trade --- ...tral_vs_Decentralized_Ledger_Comparison.md | 326 ------- ...r_energy_retailer_P2P_trading_alt_draft.md | 628 ------------ ...Inter_energy_retailer_P2P_trading_draft.md | 894 +++++++++--------- 3 files changed, 444 insertions(+), 1404 deletions(-) delete mode 100644 docs/implementation-guides/v2/P2P_Trading/Central_vs_Decentralized_Ledger_Comparison.md delete mode 100644 docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md diff --git a/docs/implementation-guides/v2/P2P_Trading/Central_vs_Decentralized_Ledger_Comparison.md b/docs/implementation-guides/v2/P2P_Trading/Central_vs_Decentralized_Ledger_Comparison.md deleted file mode 100644 index 7be9dbfb..00000000 --- a/docs/implementation-guides/v2/P2P_Trading/Central_vs_Decentralized_Ledger_Comparison.md +++ /dev/null @@ -1,326 +0,0 @@ -# Central Ledger vs Decentralized Approach: A Comparison - -This document compares two approaches to inter-energy retailer P2P trading: - -1. **Central Ledger Approach** - [Inter_energy_retailer_P2P_trading_draft.md](./Inter_energy_retailer_P2P_trading_draft.md) -2. **Decentralized Approach** - [Inter_energy_retailer_P2P_trading_alt_draft.md](./Inter_energy_retailer_P2P_trading_alt_draft.md) - ---- - -## Why We Originally Chose a Central Ledger - -The original design uses a central Trade Exchange/Ledger for these reasons: - -### 1. Single Source of Truth - -When buyer and seller are with different utilities, multiple parties need access to the same trade information: - -- **Both utilities** need to know about the trade for billing adjustments -- **Both trading platforms** need confirmation of trade status -- **Distribution utilities** need visibility for grid planning - -A central ledger provides one authoritative record that all parties can query. - -### 2. Anti-Double-Dipping - -When a prosumer has multiple trades in the same delivery window, actual meter readings must be allocated carefully. Consider: - -| Trade | Contracted | Delivery Window | -|-------|------------|-----------------| -| T1 | 5 kWh | 2-4 PM | -| T2 | 4 kWh | 2-4 PM | - -If the prosumer only injects 7 kWh, who gets what? - -With a central ledger, there's a single authoritative allocation (e.g., FIFO: T1 gets 5 kWh, T2 gets 2 kWh). Without it, different parties might calculate different allocations. - -### 3. Cross-Retailer Reconciliation - -Without a central ledger: -- How does Retailer A know about trades its customer made with Retailer B's customers? -- How do both retailers ensure they're using the same trade data for billing? - -A central ledger solves this by being the shared record both retailers query. - -### 4. Trust and Dispute Resolution - -If buyer claims they never agreed to a trade, or seller claims they delivered when they didn't, who arbitrates? - -A central ledger with digital signatures provides a trusted record for dispute resolution. - -### 5. Familiar Model - -This mirrors how stock exchanges work: a central exchange records all trades, and participants trust the exchange's records. It's a proven model at scale. - ---- - -## Why Consider a Decentralized Alternative? - -Despite the advantages of central ledgers, there are compelling reasons to explore alternatives: - -### 1. Privacy Concerns - -A central ledger sees **every trade** across all utilities: -- Trade amounts, timing, pricing -- Who is trading with whom -- Consumption and production patterns - -This raises privacy concerns: -- Do all trades need to be visible to a central entity? -- Could this data be misused or leaked? - -### 2. Single Point of Failure - -If the central ledger is unavailable: -- No new trades can be confirmed -- No existing trades can be verified -- No billing adjustments can be made - -This creates systemic risk. - -### 3. Regulatory Complexity - -A central trade exchange requires: -- Regulatory approval and oversight -- New institution or infrastructure -- Cross-jurisdiction agreements (if utilities span regions) - -This adds complexity and delays market launch. - -### 4. Centralization Concerns - -Energy markets have historically been decentralized (utility by utility). A central trade exchange concentrates power and could: -- Become a bottleneck for market growth -- Extract monopoly rents -- Resist innovation that threatens its position - -### 5. Implementation Burden - -Every utility must integrate with the central ledger. If a new utility wants to join, they must: -- Meet the exchange's technical requirements -- Pass certification -- Pay integration costs - -This creates barriers to market entry. - ---- - -## How the Decentralized Approach Works - -The decentralized approach eliminates the central ledger by having: - -1. **Each utility maintain its own ledger** for its own customers only -2. **Multi-party signatures** create a distributed audit trail -3. **Cascading Beckn protocol calls** coordinate across utilities - -### Key Insight: Each Utility Already Has the Data - -Each utility already knows: -- Its own customers' meter readings -- Its own customers' billing history -- What limits it wants to impose on its customers - -The central ledger duplicates this information. Instead, we can have each utility: -- Track trades involving its own customers -- Perform allocation for its own customers -- Adjust billing based on its own ledger - -### Trust Without Centralization - -Instead of trusting a central ledger, trust is established through **multi-party signatures**: - -``` -Trade confirmation chain: -1. BuyerTP signs → "Buyer wants this trade" -2. SellerTP signs → "Seller agrees to this trade" -3. SellerUtility signs → "Logged in our ledger, seller has capacity" -4. BuyerUtility signs → "Logged in our ledger, buyer has capacity" -``` - -By the end, all four parties have signed the same order. Any party can prove: -- The trade was agreed to by all parties -- Each utility logged it in their ledger -- Trading limits were checked - ---- - -## Detailed Comparison - -### Trust Model - -| Aspect | Central Ledger | Decentralized | -|--------|---------------|---------------| -| **Who do you trust?** | The central exchange | Each utility trusts the signature chain | -| **What if trust is violated?** | Exchange's reputation at stake | Multi-party signatures provide evidence | -| **Dispute resolution** | Exchange is arbiter | Signatures + utility ledgers provide evidence | - -**Analysis:** The decentralized approach shifts from institutional trust (trust the exchange) to cryptographic trust (trust the signatures). This is arguably stronger since signatures are mathematically verifiable, but requires all parties to properly implement signature verification. - -### Privacy - -| Aspect | Central Ledger | Decentralized | -|--------|---------------|---------------| -| **Who sees all trades?** | Central exchange | No single entity | -| **What does each utility see?** | Potentially all trades (via the ledger) | Only trades involving its customers | -| **Data minimization** | No - exchange has everything | Yes - each party sees only what's needed | - -**Analysis:** The decentralized approach is significantly more privacy-friendly. Each utility only sees: -- Its own customers' trades -- The counterparty utility (for cross-utility trades) - -The central exchange in the original approach sees *every trade across all utilities*, which is a substantial privacy concern. - -### Single Point of Failure - -| Aspect | Central Ledger | Decentralized | -|--------|---------------|---------------| -| **If exchange is down** | All trades blocked | Only affected utilities impacted | -| **If one utility is down** | Other utilities continue | Only that utility's trades blocked | -| **Cascading failures** | Possible (all depend on exchange) | Limited (utilities are independent) | - -**Analysis:** The decentralized approach is more resilient. A utility outage only affects trades involving that utility's customers. In the central ledger approach, an exchange outage blocks all trades across all utilities. - -### Anti-Double-Dipping - -| Aspect | Central Ledger | Decentralized | -|--------|---------------|---------------| -| **Allocation authority** | Single (exchange) | Distributed (each utility for its customers) | -| **Consistency guarantee** | Strong (one allocator) | Weaker (utilities may differ) | -| **Cross-utility double-dipping** | Exchange prevents | Requires utility coordination | - -**Analysis:** This is where the decentralized approach is weaker. Consider: - -- Seller has trades with buyers from Utility A and Utility B -- SellerUtility allocates actual injection to these trades -- BuyerUtility-A and BuyerUtility-B each independently allocate for their customers - -If allocation methods or timing differ, the numbers might not match. The optional cross-utility `/on_status` calls help, but don't guarantee consistency. - -**Mitigation:** Standardize allocation algorithm (e.g., FIFO by trade confirmation time) and make cross-utility status sharing mandatory rather than optional. - -### Regulatory Complexity - -| Aspect | Central Ledger | Decentralized | -|--------|---------------|---------------| -| **New infrastructure needed** | Yes (central exchange) | No (utilities extend existing systems) | -| **Cross-jurisdiction** | Exchange must be approved everywhere | Each utility handles its own jurisdiction | -| **Market entry barriers** | Higher (exchange certification) | Lower (utility-to-utility integration) | - -**Analysis:** The decentralized approach aligns better with how energy markets currently work (utility by utility) and doesn't require creating new central institutions. - -### Implementation Complexity - -| Aspect | Central Ledger | Decentralized | -|--------|---------------|---------------| -| **Integration points** | All parties → Exchange | Utility ↔ Trading Platforms | -| **Protocol complexity** | Simpler (query central ledger) | More complex (cascading calls) | -| **Signature handling** | Optional (ledger is source of truth) | Mandatory (signatures are trust basis) | - -**Analysis:** The decentralized approach requires more sophisticated protocol handling: -- Cascading `/confirm` calls through multiple parties -- Multi-party signature verification -- Handling partial failures in the cascade - -However, it builds on the existing Beckn protocol structure rather than requiring a separate ledger integration. - ---- - -## Does the Decentralized Approach Achieve the Goals? - -### Goal: Privacy-Friendly - -**Assessment: Largely Achieved** - -- Each utility only sees trades involving its own customers -- No central entity has visibility into all trades -- Trade counterparties are visible to both utilities involved, but not to unrelated utilities - -**Remaining Concern:** The utilities involved in a trade do see each other's customer information (buyer ID, seller ID). Full privacy would require zero-knowledge proofs, which adds significant complexity. - -### Goal: Decentralized Proof of Performance - -**Assessment: Partially Achieved** - -The multi-party signature chain provides: -- Proof that all parties agreed to the trade -- Proof that each utility logged the trade -- A tamper-proof record that any party can present - -However, **proof of actual delivery** still depends on: -- Each utility's meter readings (centralized per utility) -- Each utility's allocation calculation -- Trust that utilities report accurately - -**What's Different:** In the central ledger approach, the exchange receives and validates meter data from both utilities. In the decentralized approach, each utility is trusted to report its own meter data. There's no cross-validation of meter readings. - -**Mitigation Options:** -1. **Cross-utility meter attestation:** Utilities share signed meter data with each other -2. **Third-party meter certification:** Smart meters sign data directly, removing utility as intermediary -3. **Periodic reconciliation:** Utilities cross-check allocations after the fact - -### Goal: Fewer Actors / Faster Adoption - -**Assessment: Achieved** - -- No need to create and regulate a central exchange -- Each utility can adopt at its own pace -- Same-utility trades work immediately; cross-utility trades require bilateral agreements - ---- - -## Recommendations - -### When to Use Central Ledger Approach - -1. **Regulatory requirement:** If regulators require a central market operator -2. **High trade volumes:** If allocation consistency is critical and disputes are frequent -3. **Existing exchange infrastructure:** If a suitable exchange already exists - -### When to Use Decentralized Approach - -1. **Privacy is paramount:** If utilities or regulators are concerned about data centralization -2. **Gradual rollout:** If you want utilities to adopt incrementally -3. **No central authority:** If cross-jurisdiction or no regulator mandate - -### Hybrid Approaches - -A hybrid is possible: - -1. **Decentralized by default:** Most trades use cascading calls -2. **Optional central reconciliation:** A central service periodically reconciles utility ledgers to catch discrepancies -3. **Central arbitration only:** Central exchange only involved for disputes, not routine trades - ---- - -## Summary - -| Dimension | Central Ledger | Decentralized | Winner | -|-----------|---------------|---------------|--------| -| **Privacy** | Low | High | Decentralized | -| **Resilience** | Lower | Higher | Decentralized | -| **Consistency** | Strong | Weaker | Central | -| **Regulatory simplicity** | More complex | Simpler | Decentralized | -| **Implementation effort** | Moderate | Higher | Central | -| **Proof of performance** | Strong (central verification) | Partial (signature chain) | Central | -| **Market entry barriers** | Higher | Lower | Decentralized | - -**Bottom Line:** The decentralized approach trades some consistency and proof-of-delivery guarantees for significant gains in privacy, resilience, and regulatory simplicity. It's a reasonable choice when privacy concerns outweigh the need for strong centralized verification, or when creating a central exchange is impractical. - ---- - -## Open Questions for Both Approaches - -1. **Financial settlement:** Neither approach fully addresses how money moves from buyer to seller. Both documents discuss options (clearing house, escrow, bill presentation) but don't mandate one. - -2. **Cross-border trades:** If utilities span national borders, which approach handles regulatory differences better? - -3. **Smart meter trust:** Both approaches trust meter readings. If a meter is tampered with, both fail. Should smart meters sign their own data? - -4. **Scaling:** How do both approaches handle millions of daily trades? Central ledger has scaling concerns; decentralized has coordination overhead. - ---- - -## References - -- [Original Central Ledger Approach](./Inter_energy_retailer_P2P_trading_draft.md) -- [Alternative Decentralized Approach](./Inter_energy_retailer_P2P_trading_alt_draft.md) diff --git a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md deleted file mode 100644 index 20573a53..00000000 --- a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_alt_draft.md +++ /dev/null @@ -1,628 +0,0 @@ -# Inter-Energy Retailer P2P Energy Trading (Decentralized Approach) - -## Overview - -This document describes an alternative approach to inter-energy retailer P2P trading that **eliminates the need for a central trade exchange/ledger**. Instead, each utility maintains its own ledger for its customers, and trust is established through cascading Beckn protocol calls with multi-party digital signatures. - -For the original approach using a central ledger, see [Inter_energy_retailer_P2P_trading_draft.md](./Inter_energy_retailer_P2P_trading_draft.md). - -For a detailed comparison of both approaches, see [Central_vs_Decentralized_Ledger_Comparison.md](./Central_vs_Decentralized_Ledger_Comparison.md). - ---- - -## Scenario - -P2P trading between prosumers belonging to different energy retailers/distribution utilities (discoms). Each discom handles routine activities: providing electricity connections, certifying meters, billing, maintaining grid infrastructure, and ensuring grid resilience within their jurisdiction. - -**Example:** A seller (Meter ID: M1, Utility A) sells electricity to a buyer (Meter ID: M7, Utility B). - ---- - -## Key Architectural Difference - -| Aspect | Central Ledger Approach | Decentralized Approach | -|--------|------------------------|------------------------| -| Trade records | Single central ledger (Trade Exchange) | Each utility maintains its own ledger | -| Trust model | All parties trust the central ledger | Multi-party signatures create distributed proof | -| Trading limits | Central ledger tracks all limits | Each utility tracks only its own customers' limits | -| Reconciliation | Central ledger allocates actual energy | Each utility allocates for its own customers | -| Privacy | Central entity sees all trade details | Each utility only sees trades involving its customers | - ---- - -## Actors - -| # | Actor | Role | Beckn Role | -|---|-------|------|------------| -| 1 | **BuyerTP** | Consumer's trading platform | BAP (Beckn Application Platform) | -| 2 | **SellerTP** | Producer's trading platform | BPP (Beckn Provider Platform) | -| 3 | **BuyerUtility** | Buyer's energy retailer/distribution company | BPP (for limit checks and settlement) | -| 4 | **SellerUtility** | Seller's energy retailer/distribution company | BPP (for limit checks and settlement) | -| 5 | **Buyer** | Energy consumer in P2P trade | End user | -| 6 | **Seller** | Energy producer in P2P trade | End user | - -> **Note:** When buyer and seller are with the **same utility**, the flow simplifies naturally - BuyerUtility and SellerUtility collapse into a single entity, reducing the number of hops while maintaining the same protocol structure. - ---- - -## Core Design Principles - -1. **BuyerTP-initiated, SellerTP-orchestrated flows**: All transactions start from BuyerTP (BAP), and are orchestrated by SellerTP, including informing multiple utilities if needed. Utilities do not need to ordinate directly with eachother. -2. **Cascading calls**: Multi-party flows cascade through SellerTP to both utilities -3. **Utility involvement patterns**: Utility participation within init is optional, and only needed in case customers or trading platforms don't have the trading limits imposed by the utility. After the trade is confirmed, a non-blocking intimation is required to sent to utility informing them of trade, so they can avoid double-billing and compute wheeling and deviation charges, post delivery. -4. **Distributed ledgers**: Each utility maintains its own ledger for its customers only -5. **Natural collapse**: Same-utility trades collapse to single-discom flow automatically - ---- - -## Overall Process Flow - -```mermaid -sequenceDiagram - autonumber - participant B as Buyer - participant BuyerTP as BuyerTP (BAP) - participant SellerTP as SellerTP (BPP) - participant S as Seller - participant BuyerUtility as BuyerUtility - participant SellerUtility as SellerUtility - - rect rgb(230, 245, 255) - note over BuyerTP,SellerTP: Phase 1: Trade Discovery & Selection - B->>BuyerTP: Search for energy offers - BuyerTP->>SellerTP: /select (choose offer) - SellerTP->>BuyerTP: /on_select (offer details) - end - - rect rgb(255, 250, 230) - note over BuyerTP,SellerUtility: Phase 2: Trade Initialization - BuyerTP->>SellerTP: /init (trade details) - opt Optional Utility Limit Checks - BuyerTP-->>BuyerUtility: /init (if trading limits unknown OR multi-platform onboarding is allowed) - SellerTP-->>SellerUtility: /init (cascaded) - SellerUtility-->>SellerTP: /on_init (seller's remaining limit) - BuyerUtility-->>BuyerTP: /on_init (buyer's remaining limit) - end - SellerTP->>BuyerTP: /on_init - end - - rect rgb(230, 255, 230) - note over BuyerTP,SellerUtility: Phase 3: Trade Confirmation - BuyerTP->>SellerTP: /confirm (trade contract) - alt Non-blocking (Recommended) - SellerTP->>BuyerTP: /on_confirm (trade confirmed) - par Inform utilities - SellerTP->>SellerUtility: /confirm (inform utility) - SellerUtility->>SellerUtility: Deduct from seller limit, log trade - SellerUtility->>SellerTP: /on_confirm (acknowledged) - and - SellerTP->>BuyerUtility: /confirm (inform utility) - BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade - BuyerUtility->>SellerTP: /on_confirm (acknowledged) - end - else Blocking - par Utility confirmations - SellerTP->>SellerUtility: /confirm - SellerUtility->>SellerUtility: Deduct from seller limit, log trade - SellerUtility->>SellerTP: /on_confirm (signed) - and - SellerTP->>BuyerUtility: /confirm - BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade - BuyerUtility->>SellerTP: /on_confirm (signed) - end - SellerTP->>BuyerTP: /on_confirm (signed sealed order) - end - end - - opt Phase 3b: Trade Update (e.g., scheduled outage/congestion/trading limit violation) - BuyerUtility->>SellerTP: /update (cancel/curtail trade) - par Cascade update - SellerTP->>SellerUtility: /update (notify of change) - SellerUtility->>SellerUtility: Update trade in ledger - SellerUtility-->>SellerTP: /on_update (acknowledged) - and - SellerTP->>BuyerTP: /update (notify of change) - BuyerTP->>BuyerTP: Update trade status - BuyerTP-->>SellerTP: /on_update (acknowledged) - end - SellerTP->>BuyerUtility: /on_update (update confirmed) - BuyerUtility->>BuyerUtility: Update trade in ledger - end - - rect rgb(255, 230, 230) - note over S,BuyerUtility: Phase 4: Energy Delivery - S->>SellerUtility: Request to inject energy - SellerUtility->>SellerUtility: Grid security check - alt Grid stable - SellerUtility->>S: Permit injection - S->>S: Inject energy into grid - B->>B: Consume energy - else Grid unstable - SellerUtility-->>S: Reject/limit injection - end - end - - rect rgb(245, 230, 255) - note over SellerTP,BuyerUtility: Phase 5: Post-Delivery Allocation - SellerUtility->>SellerUtility: Allocate actual pushed to trades - SellerUtility-->>SellerTP: /on_status (allocated quantity) - BuyerUtility->>BuyerUtility: Allocate actual pulled to trades - BuyerUtility-->>BuyerTP: /on_status (allocated quantity) - end - - rect rgb(255, 240, 245) - note over S,B: Phase 6: Billing & Settlement - B->>S: Pay for P2P trade (post-delivery) - SellerUtility->>S: Monthly bill (excl. P2P sold, incl. wheeling) - S->>SellerUtility: Pay bill - BuyerUtility->>B: Monthly bill (excl. P2P bought, incl. wheeling) - B->>BuyerUtility: Pay bill - end -``` - ---- - -## Phase 1: Trade Discovery and Selection - -This phase follows standard Beckn discovery flow. Buyer searches for energy offers and selects one. - -```mermaid -sequenceDiagram - autonumber - participant B as Buyer - participant BuyerTP as BuyerTP (BAP) - participant SellerTP as SellerTP (BPP) - participant S as Seller - - B->>BuyerTP: Search for energy offers
(delivery window, quantity, location) - BuyerTP->>SellerTP: /select - Note right of SellerTP: Offer: 5 kWh, 2-4 PM,
$0.50/kWh - SellerTP->>BuyerTP: /on_select
(offer details, seller info) - BuyerTP->>B: Display offer details -``` - ---- - -## Phase 2: Trade Initialization - -The initialization phase optionally checks trading limits with both utilities. This is optional but recommended to prevent trade failures at confirmation time. - -### Why Check Limits? - -Each utility may impose trading limits on its customers to: -- Manage grid capacity -- Control financial exposure -- Comply with regulatory requirements - -### Initialization Flow - -```mermaid -sequenceDiagram - autonumber - participant BuyerTP as BuyerTP (BAP) - participant BuyerUtility as BuyerUtility - participant SellerTP as SellerTP (BPP) - participant SellerUtility as SellerUtility - - Note over BuyerTP,SellerUtility: Trade: 5 kWh, 2-4 PM, $0.50/kWh - - BuyerTP->>SellerTP: /init (trade details) - - opt Optional Utility Limit Checks - par Parallel limit checks - BuyerTP->>BuyerUtility: /init (buyer limit check) - BuyerUtility->>BuyerUtility: Look up buyer's
remaining trading limit - BuyerUtility-->>BuyerTP: /on_init
(remaining limit: 20 kWh) - and - SellerTP->>SellerUtility: /init (seller limit check) - SellerUtility->>SellerUtility: Look up seller's
remaining trading limit - SellerUtility-->>SellerTP: /on_init
(remaining limit: 15 kWh) - end - end - - SellerTP->>BuyerTP: /on_init
(trade initialized, limits OK) -``` - -### What Each Utility Tracks in Its Own Ledger - -| Data Element | Owner | Description | -|--------------|-------|-------------| -| Customer's trading limit | Customer's utility | Max energy that customer can trade in a period | -| Customer's confirmed trades | Customer's utility | All confirmed trades for the customer | -| Customer's actual delivery/consumption | Customer's utility | Metered data for the customer | -| Customer's allocated trade quantities | Customer's utility | Post-delivery allocation of actuals to trades | - ---- - -## Phase 3: Trade Confirmation - -This is the critical phase that establishes trust without a central ledger. SellerTP coordinates with both utilities in parallel, and each utility logs the trade and (optionally) signs the order. - -Two modes are supported: - -| Mode | When to Use | Trade Confirmed | -|------|-------------|-----------------| -| **Non-blocking (Recommended)** | Utilities cannot block trades; they are informed for record-keeping | Immediately after SellerTP receives `/confirm` | -| **Blocking** | Utilities must approve before trade is confirmed | After both utilities respond with `/on_confirm` | - -### Confirmation Flow - -```mermaid -sequenceDiagram - autonumber - participant BuyerTP as BuyerTP (BAP) - participant SellerTP as SellerTP (BPP) - participant SellerUtility as SellerUtility - participant BuyerUtility as BuyerUtility - - Note over BuyerTP,BuyerUtility: Trade: 5 kWh, 2-4 PM, $0.50/kWh - - BuyerTP->>SellerTP: /confirm (trade contract) - - alt Non-blocking (Recommended) - SellerTP->>BuyerTP: /on_confirm (trade confirmed) - par Inform utilities - SellerTP->>SellerUtility: /confirm (inform utility) - SellerUtility->>SellerUtility: Deduct from seller limit, log trade - SellerUtility-->>SellerTP: /on_confirm (acknowledged) - and - SellerTP->>BuyerUtility: /confirm (inform utility) - BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade - BuyerUtility-->>SellerTP: /on_confirm (acknowledged) - end - else Blocking - par Utility confirmations - SellerTP->>SellerUtility: /confirm - SellerUtility->>SellerUtility: Deduct from seller limit, log trade - SellerUtility->>SellerTP: /on_confirm (signed) - and - SellerTP->>BuyerUtility: /confirm - BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade - BuyerUtility->>SellerTP: /on_confirm (signed) - end - SellerTP->>BuyerTP: /on_confirm (signed sealed order) - end -``` - -### What Each Utility Does on `/confirm` - -1. Verify customer identity -2. Check customer's remaining trading limit -3. Deduct trade quantity from limit -4. Log trade in own ledger -5. (Blocking mode only) Sign the order - -### Multi-Party Signature Chain (Blocking Mode) - -In blocking mode, the sealed trade order contains signatures from all parties: - -| Signature | Attests To | -|-----------|-----------| -| BuyerTP | Buyer's intent to purchase | -| SellerTP | Seller's agreement to supply | -| BuyerUtility | Trade is within buyer's limits, logged in buyer's utility ledger | -| SellerUtility | Trade is within seller's limits, logged in seller's utility ledger | - -This creates a **tamper-proof, distributed proof of trade commitment** without requiring a central ledger. - -### Non-blocking vs Blocking Trade-offs - -| Aspect | Non-blocking | Blocking | -|--------|--------------|----------| -| **Latency** | Lower (immediate confirmation) | Higher (waits for utilities) | -| **Utility control** | Utilities informed, cannot block | Utilities can reject trades | -| **Trust model** | Trust SellerTP to inform utilities | Full multi-party consensus | -| **Use case** | High-frequency trading, trusted platforms | Regulatory requirement for utility approval | - ---- - -## Phase 3b: Trade Update (Optional) - -After a trade is confirmed but before energy delivery, a utility may need to modify or cancel the trade due to operational reasons (e.g., scheduled outage, grid constraints, regulatory intervention). - -### Why Trade Updates? - -- **Scheduled outages:** Utility plans maintenance that affects the delivery window -- **Grid constraints:** Forecasted congestion or stability issues -- **Regulatory intervention:** Compliance requirements or emergency orders -- **Meter issues:** Problems detected with buyer's or seller's metering equipment - -### Update Flow - -The initiating utility (in this example, BuyerUtility) sends `/update` to SellerTP, which coordinates the update across all parties. - -```mermaid -sequenceDiagram - autonumber - participant BuyerUtility as BuyerUtility - participant SellerTP as SellerTP (BPP) - participant SellerUtility as SellerUtility - participant BuyerTP as BuyerTP (BAP) - - Note over BuyerUtility,BuyerTP: Trade update triggered (e.g., scheduled outage) - - BuyerUtility->>SellerTP: /update (cancel/curtail trade) - Note right of SellerTP: Update reason: scheduled outage
Action: cancel OR curtail to X kWh - - par Cascade update to all parties - SellerTP->>SellerUtility: /update (notify of change) - SellerUtility->>SellerUtility: Update trade in ledger - SellerUtility-->>SellerTP: /on_update (acknowledged) - and - SellerTP->>BuyerTP: /update (notify of change) - BuyerTP->>BuyerTP: Update trade status - BuyerTP-->>SellerTP: /on_update (acknowledged) - end - - SellerTP->>BuyerUtility: /on_update (update confirmed) - BuyerUtility->>BuyerUtility: Update trade in ledger - - Note over BuyerUtility,BuyerTP: All parties now have consistent view of modified trade -``` - -### Update Types - -| Update Type | Description | Effect on Trade | -|-------------|-------------|-----------------| -| **Cancel** | Full cancellation of the trade | Trade marked as cancelled; limits restored | -| **Curtail** | Reduce contracted quantity | Trade quantity reduced; partial limits restored | -| **Reschedule** | Change delivery window | New delivery window; same quantity | - -### What Each Party Does on `/update` - -| Party | Actions | -|-------|---------| -| **SellerUtility** | Update trade in ledger; adjust seller's trading limit if cancelled/curtailed | -| **BuyerTP** | Notify buyer of change; update local trade status | -| **BuyerUtility** | Update trade in ledger; adjust buyer's trading limit if cancelled/curtailed | - -### Update Initiation - -While this example shows BuyerUtility initiating, updates can also be initiated by: - -| Initiator | Route | Use Case | -|-----------|-------|----------| -| **BuyerUtility** | BuyerUtility → SellerTP → (SellerUtility, BuyerTP) | Outage on buyer's side | -| **SellerUtility** | SellerUtility → SellerTP → (BuyerUtility, BuyerTP) | Outage on seller's side | -| **BuyerTP** | BuyerTP → SellerTP → (SellerUtility, BuyerUtility) | Buyer requests cancellation | - -In all cases, SellerTP acts as the coordination hub, ensuring all parties receive the update and acknowledge it. - ---- - -## Phase 4: Energy Delivery - -*(Could be anywhere from a few hours to a few days later)* - -Energy delivery follows the same physical process as the central ledger approach. The key difference is that each utility records meter data in its own ledger. - -### Energy Injection - -- At scheduled time, seller injects energy into the grid -- Seller's utility performs grid security checks and permits injection only if grid stability is maintained - -### Energy Consumption - -- Buyer consumes energy as usual during the delivery window - -```mermaid -sequenceDiagram - autonumber - participant S as Seller - participant SM_S as Seller's
Smart Meter - participant SellerUtility as SellerUtility - participant BuyerUtility as BuyerUtility - participant SM_B as Buyer's
Smart Meter - participant B as Buyer - - Note over S,B: Scheduled Delivery Window Begins - - S->>SM_S: Generate/inject energy - SM_S->>SellerUtility: Report injection request - - SellerUtility->>SellerUtility: Grid security check - alt Grid stable - SellerUtility->>SellerUtility: Permit injection - SM_S->>SM_S: Energy injected into grid - - SM_B->>B: Energy consumed - - SM_S->>SM_S: Record injection (kWh, timestamp) - SM_B->>SM_B: Record consumption (kWh, timestamp) - else Grid unstable - SellerUtility-->>SM_S: Reject/limit injection - Note over SellerUtility: Grid stability
takes priority - end - - Note over S,B: Scheduled Delivery Window Ends -``` - ---- - -## Phase 5: Post-Delivery Allocation and Status - -After the delivery window, each utility performs allocation independently for its own customers and notifies the relevant trading platforms. - -### Why Allocation Matters - -A prosumer may have multiple trades in the same delivery window but inject/consume less than the total contracted amount. Each utility must allocate actual meter readings to specific trades to determine: -- What quantity was actually delivered/received for each trade -- What to include in billing adjustments -- Whether penalties apply for under-delivery - -### Allocation Flow - -```mermaid -sequenceDiagram - autonumber - participant SellerTP as SellerTP (BPP) - participant SellerUtility as SellerUtility - participant BuyerUtility as BuyerUtility - participant BuyerTP as BuyerTP (BAP) - - Note over SellerUtility: Verification Cycle (e.g., every X hours) - - rect rgb(255, 245, 230) - Note over SellerUtility: Seller-Side Allocation - SellerUtility->>SellerUtility: Get all confirmed trades for
seller in delivery period - SellerUtility->>SellerUtility: Get actual meter injection data - SellerUtility->>SellerUtility: Allocate actuals to trades
(FIFO or pro-rata) - SellerUtility-->>SellerTP: /on_status
(allocated qty per trade) - Note right of SellerTP: Seller knows what to expect
in discom bill adjustment - end - - opt Cross-Utility Visibility - SellerUtility-->>BuyerUtility: /on_status
(seller's allocated quantities) - end - - rect rgb(230, 245, 255) - Note over BuyerUtility: Buyer-Side Allocation - BuyerUtility->>BuyerUtility: Get all confirmed trades for
buyer in delivery period - BuyerUtility->>BuyerUtility: Get actual meter consumption data - BuyerUtility->>BuyerUtility: Allocate actuals to trades
(FIFO or pro-rata) - BuyerUtility-->>BuyerTP: /on_status
(allocated qty per trade) - Note right of BuyerTP: Buyer knows what to expect
in discom bill adjustment - end - - opt Cross-Utility Visibility - BuyerUtility-->>SellerUtility: /on_status
(buyer's allocated quantities) - end -``` - -### Allocation Example (FIFO) - -**Seller's trades for delivery window 2-4 PM:** - -| Trade | Trade Time | Contracted Qty | Priority | -|-------|------------|----------------|----------| -| T1 (with Buyer A) | 9:00 AM | 5 kWh | 1st | -| T2 (with Buyer B) | 9:30 AM | 4 kWh | 2nd | -| **Total** | | **9 kWh** | | - -**Actual injection: 7 kWh** - -**SellerUtility allocation (FIFO):** - -| Trade | Contracted | Allocated | Status | -|-------|------------|-----------|--------| -| T1 | 5 kWh | 5 kWh | Full delivery | -| T2 | 4 kWh | 2 kWh | Partial delivery | - -SellerUtility sends `/on_status` to SellerTP with these allocated quantities. - ---- - -## Phase 6: Billing and Settlement - -Settlement involves two separate payment flows: -1. **P2P payment:** Buyer pays Seller directly for the traded energy (post-delivery) -2. **Utility billing:** Each utility bills its customer, excluding P2P energy but including wheeling charges - -```mermaid -sequenceDiagram - autonumber - participant S as Seller - participant SellerUtility as SellerUtility - participant BuyerUtility as BuyerUtility - participant B as Buyer - - rect rgb(240, 255, 240) - Note over S,B: P2P Settlement (Post-Delivery) - B->>S: Pay for P2P trade
(allocated qty × agreed price) - S-->>B: Payment confirmed - end - - Note over SellerUtility,BuyerUtility: Monthly Billing Cycle - - rect rgb(255, 245, 230) - Note over SellerUtility: Seller's Bill - SellerUtility->>SellerUtility: Look up P2P trades from own ledger - SellerUtility->>SellerUtility: Calculate: Regular bill
- P2P sold energy credit
+ Wheeling charges - SellerUtility->>S: Monthly bill - S->>SellerUtility: Pay bill - end - - rect rgb(230, 245, 255) - Note over BuyerUtility: Buyer's Bill - BuyerUtility->>BuyerUtility: Look up P2P trades from own ledger - BuyerUtility->>BuyerUtility: Calculate: Regular bill
- P2P purchased energy
+ Wheeling charges - BuyerUtility->>B: Monthly bill - B->>BuyerUtility: Pay bill - end -``` - -### P2P Payment - -The buyer pays the seller directly for the P2P trade after delivery is confirmed (via `/on_status`). Payment amount is based on: -- **Allocated quantity** (from Phase 5, may be less than contracted if under-delivery) -- **Agreed price** (from the confirmed trade contract) - -Payment mechanism options include direct bank transfer, UPI, or platform-mediated escrow (see original document for detailed settlement options). - -### Anti-Double-Billing - -- **Buyer:** BuyerUtility excludes P2P energy from regular charges (buyer already paid seller directly) -- **Seller:** SellerUtility excludes P2P energy from injection credit (seller already received payment from buyer) - ---- - -## Same-Utility Collapse - -When buyer and seller are with the **same utility**, the flow simplifies naturally: - -```mermaid -sequenceDiagram - autonumber - participant BuyerTP as BuyerTP (BAP) - participant SellerTP as SellerTP (BPP) - participant Utility as Utility
(same for both) - - BuyerTP->>SellerTP: /confirm (trade contract) - SellerTP->>Utility: /confirm (single utility call) - - Utility->>Utility: Check both limits - Utility->>Utility: Log single trade entry - Utility->>Utility: Sign and seal order - - Utility-->>SellerTP: /on_confirm - SellerTP-->>BuyerTP: /on_confirm - - Note over BuyerTP,Utility: Same protocol, fewer hops -``` - -The protocol structure remains identical, but: -- Only one utility is involved -- No cross-utility confirm/on_confirm -- Single ledger entry (but from same utility's perspective for both parties) - ---- - -## Comparison with Central Ledger Approach - -| Aspect | Central Ledger | Decentralized (This Approach) | -|--------|---------------|------------------------------| -| **Trust model** | All trust central exchange | Multi-party signatures | -| **Privacy** | Central entity sees all trades | Each utility sees only its customers' trades | -| **Single point of failure** | Yes (central ledger) | No | -| **Cross-utility coordination** | Via central ledger queries | Via cascading Beckn calls | -| **Regulatory complexity** | Central exchange needs regulation | Each utility self-regulates | -| **Deployment** | Requires new central infrastructure | Builds on existing utility systems | -| **Dispute resolution** | Central ledger is arbiter | Multi-party signatures provide evidence | - ---- - -## Open Questions - -1. **Signature Format:** What cryptographic format for multi-party signatures? (JWS, EdDSA, etc.) - -2. **Allocation Consistency:** If FIFO allocation differs between utilities for the same trade (due to data timing), how to reconcile? - -3. **Cross-Utility Trust:** What compels SellerUtility to forward `/confirm` to BuyerUtility honestly? - -4. **Offline Handling:** If a utility is temporarily unavailable during confirmation cascade, how to handle? - -5. **Audit Trail Access:** How do trading platforms access the full signature chain for disputes? - ---- - -[^1]: Non-exhaustive diff --git a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_draft.md b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_draft.md index 0ab7e945..c343eb2f 100644 --- a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_draft.md +++ b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_draft.md @@ -1,50 +1,57 @@ -# Inter-Energy Retailer P2P Energy Trading +# Inter-Energy Retailer P2P Energy Trading (Decentralized Approach) -## Scenario +## Overview + +This document describes an alternative approach to inter-energy retailer P2P trading that **eliminates the need for a central trade exchange/ledger**. Instead, each utility maintains its own ledger for its customers, and trust is established through cascading Beckn protocol calls with multi-party digital signatures. -P2P trading between prosumers belonging to different energy retailers. Each energy retailer and energy distribution utility handles routine activities: providing electricity connections, certifying meters, billing, maintaining grid infrastructure, and ensuring grid resilience within their jurisdiction. +For the original approach using a central ledger, see [Inter_energy_retailer_P2P_trading_draft.md](./Inter_energy_retailer_P2P_trading_draft.md). -**Example:** Prosumer P1 (Meter ID: M1, Retailer A) sells electricity to Prosumer P7 (Meter ID: M7, Retailer B). +For a detailed comparison of both approaches, see [Central_vs_Decentralized_Ledger_Comparison.md](./Central_vs_Decentralized_Ledger_Comparison.md). --- -## Present World Reality / Constraints[^1] +## Scenario + +P2P trading between prosumers belonging to different energy retailers/distribution utilities (discoms). Each discom handles routine activities: providing electricity connections, certifying meters, billing, maintaining grid infrastructure, and ensuring grid resilience within their jurisdiction. -1. **Physical delivery is guaranteed by the grid.** Unlike other commodity exchanges, electrons flow based on physics. If P1 produces 10 kWh and P7 consumes 10 kWh on connected grids, energy "settles" physically regardless of any contract. The settlement problem is therefore purely financial: who owes whom, based on metered production and consumption. +**Example:** A seller (Meter ID: M1, Utility A) sells electricity to a buyer (Meter ID: M7, Utility B). -2. **Energy Retailers face bill collection challenges.** Inter-energy retailer P2P trading must not worsen this problem. +--- + +## Key Architectural Difference -3. **Fewer actors is better.** Requiring many systems or institutions to participate will slow market innovation and adoption. +| Aspect | Central Ledger Approach | Decentralized Approach | +|--------|------------------------|------------------------| +| Trade records | Single central ledger (Trade Exchange) | Each utility maintains its own ledger | +| Trust model | All parties trust the central ledger | Multi-party signatures create distributed proof | +| Trading limits | Central ledger tracks all limits | Each utility tracks only its own customers' limits | +| Reconciliation | Central ledger allocates actual energy | Each utility allocates for its own customers | +| Privacy | Central entity sees all trade details | Each utility only sees trades involving its customers | --- -## User Journey +## Actors -### Model I - Direct Settlement and Contracting +| # | Actor | Role | Beckn Role | +|---|-------|------|------------| +| 1 | **BuyerTP** | Consumer's trading platform | BAP (Beckn Application Platform) | +| 2 | **SellerTP** | Producer's trading platform | BPP (Beckn Provider Platform) | +| 3 | **BuyerUtility** | Buyer's energy retailer/distribution company | BPP (for limit checks and settlement) | +| 4 | **SellerUtility** | Seller's energy retailer/distribution company | BPP (for limit checks and settlement) | +| 5 | **Buyer** | Energy consumer in P2P trade | End user | +| 6 | **Seller** | Energy producer in P2P trade | End user | -*Energy distribution companies/Energy retailers provide infrastructure and have visibility but are not in the payment flow.* +> **Note:** When buyer and seller are with the **same utility**, the flow simplifies naturally - BuyerUtility and SellerUtility collapse into a single entity, reducing the number of hops while maintaining the same protocol structure. --- -## Actors +## Core Design Principles -| # | Actor | Role | -|---|-------|------| -| 1 | **Energy retailers** | Consumer facing role | -| 2 | **Energy distribution companies** | Wire role / physical infra operator | -| 3 | **Buyer** | Energy consumer in P2P trade | -| 4 | **Seller** | Energy producer in P2P trade | -| 5 | **Trade platform(s)** | Consumer-facing applications that: | -| | | - Allow prosumers to interact with the trade exchange | -| | | - Handle user interfaces for trade placement and management (Energy retailer may also have a consumer interface) | -| | | - Are a separate entity from the trade exchange itself | -| 6 | **Trade exchange(s)** | A logical entity (like NYSE/NSE/LSE in stock markets) that: | -| | | - Runs the permissioned transaction ledger | -| | | - Establishes relationships with Energy distribution companies/Energy retailers (and is trusted by them) | -| | | - Provides regulatory backing and trust assurance | -| | | - May be implemented using various technologies (blockchain, database, etc.) | - -> **Assumption:** Whoever is running the permissioned ledger IS the trade exchange. This is a necessary logical construct. Whoever (regulators or other operators) runs this, that entity becomes the trade exchange. +1. **BuyerTP-initiated, SellerTP-orchestrated flows**: All transactions start from BuyerTP (BAP), and are orchestrated by SellerTP, including informing multiple utilities if needed. Utilities do not need to ordinate directly with eachother. +2. **Cascading calls**: Multi-party flows cascade through SellerTP to both utilities +3. **Utility involvement patterns**: Utility participation within init is optional, and only needed in case customers or trading platforms don't have the trading limits imposed by the utility. After the trade is confirmed, a non-blocking intimation is required to sent to utility informing them of trade, so they can avoid double-billing and compute wheeling and deviation charges, post delivery. +4. **Distributed ledgers**: Each utility maintains its own ledger for its customers only +5. **Natural collapse**: Same-utility trades collapse to single-discom flow automatically --- @@ -53,582 +60,569 @@ P2P trading between prosumers belonging to different energy retailers. Each ener ```mermaid sequenceDiagram autonumber - participant S as Seller (P1) - participant B as Buyer (P7) - participant TP as Trade Platform - participant TE as Trade Exchange/Ledger - participant RA as Retailer A - participant RB as Retailer B - participant DU_A as Distribution Utility A - participant DU_B as Distribution Utility B + participant B as Buyer + participant BuyerTP as BuyerTP (BAP) + participant SellerTP as SellerTP (BPP) + participant S as Seller + participant BuyerUtility as BuyerUtility + participant SellerUtility as SellerUtility rect rgb(230, 245, 255) - note over S,TE: Phase 1: Trade Placement - S->>TP: Initiate trade - B->>TP: Accept trade - TP->>TE: Submit signed contract - TE->>TE: Record on ledger - Note right of TE: Ledger: Discom A, Discom B, seller, buyer,
Trade Time, Delivery Start/End,
Trade Qty, Actual pushed, Actual pulled Qty - DU_A-->>TE: Visibility into upcoming trades - DU_B-->>TE: Visibility into upcoming trades + note over BuyerTP,SellerTP: Phase 1: Trade Discovery & Selection + B->>BuyerTP: Search for energy offers + BuyerTP->>SellerTP: /select (choose offer) + SellerTP->>BuyerTP: /on_select (offer details) + end + + rect rgb(255, 250, 230) + note over BuyerTP,SellerUtility: Phase 2: Trade Initialization + BuyerTP->>SellerTP: /init (trade details) + opt Optional Utility Limit Checks + BuyerTP-->>BuyerUtility: /init (if trading limits unknown OR multi-platform onboarding is allowed) + SellerTP-->>SellerUtility: /init (cascaded) + SellerUtility-->>SellerTP: /on_init (seller's remaining limit) + BuyerUtility-->>BuyerTP: /on_init (buyer's remaining limit) + end + SellerTP->>BuyerTP: /on_init end rect rgb(230, 255, 230) - note over S,DU_B: Phase 2: Trade Delivery - S->>DU_A: Inject energy at scheduled time - DU_A->>DU_A: Grid security check - B->>B: Consume energy + note over BuyerTP,SellerUtility: Phase 3: Trade Confirmation + BuyerTP->>SellerTP: /confirm (trade contract) + alt Non-blocking (Recommended) + SellerTP->>BuyerTP: /on_confirm (trade confirmed) + par Inform utilities + SellerTP->>SellerUtility: /confirm (inform utility) + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility->>SellerTP: /on_confirm (acknowledged) + and + SellerTP->>BuyerUtility: /confirm (inform utility) + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility->>SellerTP: /on_confirm (acknowledged) + end + else Blocking + par Utility confirmations + SellerTP->>SellerUtility: /confirm + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility->>SellerTP: /on_confirm (signed) + and + SellerTP->>BuyerUtility: /confirm + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility->>SellerTP: /on_confirm (signed) + end + SellerTP->>BuyerTP: /on_confirm (signed sealed order) + end end - rect rgb(255, 245, 230) - note over TE,RB: Phase 3: Trade Verification - DU_A->>TE: Add/allocate actual pushed signed meter data to ledger (P1) - DU_B->>TE: Add/allocate actual pulled signed meter data to ledger (P7) + opt Phase 3b: Trade Update (e.g., scheduled outage/congestion/trading limit violation) + BuyerUtility->>SellerTP: /update (cancel/curtail trade) + par Cascade update + SellerTP->>SellerUtility: /update (notify of change) + SellerUtility->>SellerUtility: Update trade in ledger + SellerUtility-->>SellerTP: /on_update (acknowledged) + and + SellerTP->>BuyerTP: /update (notify of change) + BuyerTP->>BuyerTP: Update trade status + BuyerTP-->>SellerTP: /on_update (acknowledged) + end + SellerTP->>BuyerUtility: /on_update (update confirmed) + BuyerUtility->>BuyerUtility: Update trade in ledger end rect rgb(255, 230, 230) - note over S,B: Phase 4: Financial Settlement - Note right of TE: Settlement via chosen
mechanism (Options A-D) - B->>S: Payment (via settlement mechanism) + note over S,BuyerUtility: Phase 4: Energy Delivery + S->>SellerUtility: Request to inject energy + SellerUtility->>SellerUtility: Grid security check + alt Grid stable + SellerUtility->>S: Permit injection + S->>S: Inject energy into grid + B->>B: Consume energy + else Grid unstable + SellerUtility-->>S: Reject/limit injection + end end rect rgb(245, 230, 255) - note over RA,RB: Phase 5: Wheeling & Billing - RA->>TE: Look up P2P trades (P1) - RB->>TE: Look up P2P trades (P7) - RA->>S: Bill (excl. P2P + incl. wheeling) - RB->>B: Bill (excl. P2P + incl. wheeling) - S->>RA: Pay bill - B->>RB: Pay bill - RA->>DU_A: Remit wheeling charges - RB->>DU_B: Remit wheeling charges + note over SellerTP,BuyerUtility: Phase 5: Post-Delivery Allocation + SellerUtility->>SellerUtility: Allocate actual pushed to trades + BuyerUtility->>BuyerUtility: Allocate actual pulled to trades + par Utilities report to SellerTP + SellerUtility-->>SellerTP: /on_status (seller allocated qty) + and + BuyerUtility-->>SellerTP: /on_status (buyer allocated qty) + end + SellerTP->>BuyerTP: /on_status (trade settlement summary) + end + + rect rgb(255, 240, 245) + note over S,B: Phase 6: Billing & Settlement + B->>S: Pay for P2P trade (post-delivery) + SellerUtility->>S: Monthly bill (excl. P2P sold, incl. wheeling) + S->>SellerUtility: Pay bill + BuyerUtility->>B: Monthly bill (excl. P2P bought, incl. wheeling) + B->>BuyerUtility: Pay bill end ``` --- -## Phase 1: Trade Placement - -### 1. Trade Placement +## Phase 1: Trade Discovery and Selection -- P1 (Energy Retailer A) logs into a trading app and initiates a trade with P7 (Energy Retailer B) -- Trade contract specifies: fulfillment terms (delivery window, energy quantity), agreed price, meter IDs for both parties, destination energy retailer details -- Contract is digitally signed by P1 and P7 using certificates issued by the trade exchange -- **Example:** P1-A agrees to deliver 5 kWh between 2–4 PM at USD 5/kWh to P7-B - -> **Note:** As trading volumes grow, matching individual buyers to individual sellers might become impractical. A stock-exchange-style approach, where supply and demand are aggregated and matched algorithmically, may be more viable at scale. - -### 2. Ledger Recording - -- The trade is recorded on the trade exchange -- Energy distribution utilities gain visibility into scheduled trades for grid security management, capacity planning and financial reconciliation +This phase follows standard Beckn discovery flow. Buyer searches for energy offers and selects one. ```mermaid sequenceDiagram autonumber - participant S as Seller (P1)
Retailer A - participant B as Buyer (P7)
Retailer B - participant TP as Trade Platform - participant TE as Trade Exchange/Ledger - participant DU as Distribution Utility - - S->>TP: Login & initiate trade - TP->>S: Request trade details - S->>TP: Submit trade details
(delivery window, quantity,
price, meter IDs) - TP->>B: Trade invitation - B->>TP: Accept trade terms - - TP->>TE: Request signing certificates - TE-->>TP: Issue certificates - - S->>TP: Digital signature - B->>TP: Digital signature - TP->>TE: Submit signed contract - - TE->>TE: Validate signatures - TE->>TE: Record on permissioned ledger - TE-->>TP: Confirmation - TP-->>S: Trade confirmed - TP-->>B: Trade confirmed - - DU-->>TE: Visibility into scheduled trades
(for grid planning) + participant B as Buyer + participant BuyerTP as BuyerTP (BAP) + participant SellerTP as SellerTP (BPP) + participant S as Seller + + B->>BuyerTP: Search for energy offers
(delivery window, quantity, location) + BuyerTP->>SellerTP: /select + Note right of SellerTP: Offer: 5 kWh, 2-4 PM,
$0.50/kWh + SellerTP->>BuyerTP: /on_select
(offer details, seller info) + BuyerTP->>B: Display offer details ``` --- -## Phase 2: Trade Delivery - -*(Could be anywhere from a few hours to a few days later)* +## Phase 2: Trade Initialization -### 3. Energy Injection +The initialization phase optionally checks trading limits with both utilities. This is optional but recommended to prevent trade failures at confirmation time. -- At scheduled time, seller injects energy into the grid -- Corresponding energy distribution utility performs grid security checks and permits injection only if grid stability is maintained +### Why Check Limits? -### 4. Energy Consumption +Each utility may impose trading limits on its customers to: +- Manage grid capacity +- Control financial exposure +- Comply with regulatory requirements -- Buyer consumes energy as usual during the delivery window +### Initialization Flow ```mermaid sequenceDiagram autonumber - participant S as Seller (P1) - participant SM_S as Seller's
Smart Meter - participant DU_A as Distribution
Utility A - participant DU_B as Distribution
Utility B - participant SM_B as Buyer's
Smart Meter - participant B as Buyer (P7) - - Note over S,B: Scheduled Delivery Window Begins - - S->>SM_S: Generate/inject energy - SM_S->>DU_A: Report injection request - - DU_A->>DU_A: Grid security check - alt Grid stable - DU_A->>DU_A: Permit injection - SM_S->>SM_S: Energy injected into grid - - SM_B->>B: Energy consumed - - SM_S->>SM_S: Record injection (kWh, timestamp) - SM_B->>SM_B: Record consumption (kWh, timestamp) - else Grid unstable - DU_A-->>SM_S: Reject/limit injection - Note over DU_A: Grid stability
takes priority + participant BuyerTP as BuyerTP (BAP) + participant BuyerUtility as BuyerUtility + participant SellerTP as SellerTP (BPP) + participant SellerUtility as SellerUtility + + Note over BuyerTP,SellerUtility: Trade: 5 kWh, 2-4 PM, $0.50/kWh + + BuyerTP->>SellerTP: /init (trade details) + + opt Optional Utility Limit Checks + par Parallel limit checks + BuyerTP->>BuyerUtility: /init (buyer limit check) + BuyerUtility->>BuyerUtility: Look up buyer's
remaining trading limit + BuyerUtility-->>BuyerTP: /on_init
(remaining limit: 20 kWh) + and + SellerTP->>SellerUtility: /init (seller limit check) + SellerUtility->>SellerUtility: Look up seller's
remaining trading limit + SellerUtility-->>SellerTP: /on_init
(remaining limit: 15 kWh) + end end - Note over S,B: Scheduled Delivery Window Ends + SellerTP->>BuyerTP: /on_init
(trade initialized, limits OK) ``` +### What Each Utility Tracks in Its Own Ledger + +| Data Element | Owner | Description | +|--------------|-------|-------------| +| Customer's trading limit | Customer's utility | Max energy that customer can trade in a period | +| Customer's confirmed trades | Customer's utility | All confirmed trades for the customer | +| Customer's actual delivery/consumption | Customer's utility | Metered data for the customer | +| Customer's allocated trade quantities | Customer's utility | Post-delivery allocation of actuals to trades | + --- -## Phase 3: Trade Verification +## Phase 3: Trade Confirmation + +This is the critical phase that establishes trust without a central ledger. SellerTP coordinates with both utilities in parallel, and each utility logs the trade and (optionally) signs the order. -*(Will happen at a time gap from execution - verification frequency can be pre-determined, like every x hours)* +Two modes are supported: -### 5. Trade Verification +| Mode | When to Use | Trade Confirmed | +|------|-------------|-----------------| +| **Non-blocking (Recommended)** | Utilities cannot block trades; they are informed for record-keeping | Immediately after SellerTP receives `/confirm` | +| **Blocking** | Utilities must approve before trade is confirmed | After both utilities respond with `/on_confirm` | -- Distribution utilities update the ledger with digitally signed meter data for both parties -- For overlapping trades (same delivery window), actual energy is allocated FIFO by trade time; reconciled quantity = min(trade qty, actual pushed) -- Trade exchange/ledger marks trade as complete +### Confirmation Flow ```mermaid sequenceDiagram autonumber - participant TE as Trade Exchange/Ledger - participant DU_A as Distribution Utility A - participant DU_B as Distribution Utility B + participant BuyerTP as BuyerTP (BAP) + participant SellerTP as SellerTP (BPP) + participant SellerUtility as SellerUtility + participant BuyerUtility as BuyerUtility + + Note over BuyerTP,BuyerUtility: Trade: 5 kWh, 2-4 PM, $0.50/kWh + + BuyerTP->>SellerTP: /confirm (trade contract) + + alt Non-blocking (Recommended) + SellerTP->>BuyerTP: /on_confirm (trade confirmed) + par Inform utilities + SellerTP->>SellerUtility: /confirm (inform utility) + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility-->>SellerTP: /on_confirm (acknowledged) + and + SellerTP->>BuyerUtility: /confirm (inform utility) + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility-->>SellerTP: /on_confirm (acknowledged) + end + else Blocking + par Utility confirmations + SellerTP->>SellerUtility: /confirm + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility->>SellerTP: /on_confirm (signed) + and + SellerTP->>BuyerUtility: /confirm + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility->>SellerTP: /on_confirm (signed) + end + SellerTP->>BuyerTP: /on_confirm (signed sealed order) + end +``` - Note over TE: Verification cycle triggered
(e.g., every X hours) +### What Each Utility Does on `/confirm` - DU_A->>TE: Update ledger with signed meter data
(Meter M1, P1 injection: X kWh) - DU_B->>TE: Update ledger with signed meter data
(Meter M7, P7 consumption: Y kWh) +1. Verify customer identity +2. Check customer's remaining trading limit +3. Deduct trade quantity from limit +4. Log trade in own ledger +5. (Blocking mode only) Sign the order - Note over TE: Anti-double-dipping: For overlapping trades,
actual kWh allocated FIFO by trade time.
Recon Qty = min(Trade Qty, Actual Pushed).
(See Overlapping Trade Reconciliation) +### Multi-Party Signature Chain (Blocking Mode) - TE->>TE: Validate digital signatures - TE->>TE: Compare actuals vs contract +In blocking mode, the sealed trade order contains signatures from all parties: - alt Delivery matches contract - TE->>TE: Mark trade COMPLETE - Note over TE: Proceed to settlement - else Partial delivery - TE->>TE: Record actual delivery - Note over TE: Apply settlement rules
(see Contract Modification) - else No delivery - TE->>TE: Mark trade FAILED - Note over TE: Trigger penalty/
enforcement - end -``` +| Signature | Attests To | +|-----------|-----------| +| BuyerTP | Buyer's intent to purchase | +| SellerTP | Seller's agreement to supply | +| BuyerUtility | Trade is within buyer's limits, logged in buyer's utility ledger | +| SellerUtility | Trade is within seller's limits, logged in seller's utility ledger | ---- +This creates a **tamper-proof, distributed proof of trade commitment** without requiring a central ledger. -## Phase 4: Financial Settlement +### Non-blocking vs Blocking Trade-offs -### Settlement Options (Open for Group Discussion) +| Aspect | Non-blocking | Blocking | +|--------|--------------|----------| +| **Latency** | Lower (immediate confirmation) | Higher (waits for utilities) | +| **Utility control** | Utilities informed, cannot block | Utilities can reject trades | +| **Trust model** | Trust SellerTP to inform utilities | Full multi-party consensus | +| **Use case** | High-frequency trading, trusted platforms | Regulatory requirement for utility approval | --- -### Option A: Clearing House Model +## Phase 3b: Trade Update (Optional) -- Central clearing house holds funds from the buyer (at the time of trade placement or at a later date for trades happening much later) -- Releases to seller upon delivery confirmation -- Similar to stock exchange settlement +After a trade is confirmed but before energy delivery, a utility may need to modify or cancel the trade due to operational reasons (e.g., scheduled outage, grid constraints, regulatory intervention). -| Pros | Cons | -|------|------| -| Familiar pattern, trusted intermediary, proven at scale | Requires new infrastructure; problematic for long-horizon trades (when does money go to the clearing house for a T+60 trade - day 1 or day 59?) | +### Why Trade Updates? -```mermaid -sequenceDiagram - autonumber - participant B as Buyer (P7) - participant CH as Clearing House - participant TE as Trade Exchange - participant S as Seller (P1) - - Note over B,S: At Trade Placement (or later for future trades) - B->>CH: Deposit funds - CH->>CH: Hold funds in escrow - CH-->>B: Deposit confirmed - - Note over B,S: After Trade Verification - TE->>CH: Trade verified
(delivery confirmed) - CH->>CH: Release funds - CH->>S: Transfer payment - S-->>CH: Payment received - - CH->>TE: Settlement complete -``` +- **Scheduled outages:** Utility plans maintenance that affects the delivery window +- **Grid constraints:** Forecasted congestion or stability issues +- **Regulatory intervention:** Compliance requirements or emergency orders +- **Meter issues:** Problems detected with buyer's or seller's metering equipment ---- +### Update Flow -### Option B: Money Block / Escrow Model - -- Funds blocked at trade placement -- Released on delivery confirmation -- Many payment rails like credit cards already support blocking - -| Pros | Cons | -|------|------| -| Real-time assurance, works for immediate trades | Complex for future trades - how will we block money for 15, 30, 60 days? | +The initiating utility (in this example, BuyerUtility) sends `/update` to SellerTP, which coordinates the update across all parties. ```mermaid sequenceDiagram autonumber - participant B as Buyer (P7) - participant Bank as Buyer's Bank/
Payment Rail - participant TE as Trade Exchange - participant S as Seller (P1) - - Note over B,S: At Trade Placement - TE->>Bank: Request fund block
(amount, duration) - Bank->>Bank: Block funds in
buyer's account - Bank-->>TE: Block confirmed - Bank-->>B: Funds blocked notification - - Note over B,S: After Trade Verification - TE->>Bank: Release blocked funds
to seller - Bank->>Bank: Unblock & transfer - Bank->>S: Payment credited - Bank-->>B: Funds released notification - - Note over Bank: Challenge: How to maintain
block for 15-60 days? -``` + participant BuyerUtility as BuyerUtility + participant SellerTP as SellerTP (BPP) + participant SellerUtility as SellerUtility + participant BuyerTP as BuyerTP (BAP) + + Note over BuyerUtility,BuyerTP: Trade update triggered (e.g., scheduled outage) + + BuyerUtility->>SellerTP: /update (cancel/curtail trade) + Note right of SellerTP: Update reason: scheduled outage
Action: cancel OR curtail to X kWh + + par Cascade update to all parties + SellerTP->>SellerUtility: /update (notify of change) + SellerUtility->>SellerUtility: Update trade in ledger + SellerUtility-->>SellerTP: /on_update (acknowledged) + and + SellerTP->>BuyerTP: /update (notify of change) + BuyerTP->>BuyerTP: Update trade status + BuyerTP-->>SellerTP: /on_update (acknowledged) + end ---- + SellerTP->>BuyerUtility: /on_update (update confirmed) + BuyerUtility->>BuyerUtility: Update trade in ledger -### Option C: Prepaid Model + Note over BuyerUtility,BuyerTP: All parties now have consistent view of modified trade +``` -- Every consumer/prosumer pre-pays their smart meter with x amount -- All purchases are directly addressed by respective retailers' bill collection and payments infra against the bill using the data from trade exchange +### Update Types -```mermaid -sequenceDiagram - autonumber - participant S as Seller (P1) - participant B as Buyer (P7) - participant SM_B as Buyer's
Smart Meter - participant RA as Retailer A - participant RB as Retailer B - participant TE as Trade Exchange +| Update Type | Description | Effect on Trade | +|-------------|-------------|-----------------| +| **Cancel** | Full cancellation of the trade | Trade marked as cancelled; limits restored | +| **Curtail** | Reduce contracted quantity | Trade quantity reduced; partial limits restored | +| **Reschedule** | Change delivery window | New delivery window; same quantity | - Note over B: Pre-funding Phase - B->>SM_B: Pre-pay smart meter
(top-up balance) - SM_B-->>B: Balance: $X +### What Each Party Does on `/update` - Note over S,B: After Trade Verification - TE->>RB: P2P trade data
(P7 owes P1 $Y) +| Party | Actions | +|-------|---------| +| **SellerUtility** | Update trade in ledger; adjust seller's trading limit if cancelled/curtailed | +| **BuyerTP** | Notify buyer of change; update local trade status | +| **BuyerUtility** | Update trade in ledger; adjust buyer's trading limit if cancelled/curtailed | - RB->>SM_B: Debit P2P purchase - SM_B->>SM_B: Deduct from balance +### Update Initiation - RB->>RA: Inter-retailer settlement
(P7's payment for P1) - RA->>S: Credit to seller
(via regular bill credit) +While this example shows BuyerUtility initiating, updates can also be initiated by: - Note over B: Next bill cycle - RB->>B: Regular bill
(reflects P2P debits) -``` +| Initiator | Route | Use Case | +|-----------|-------|----------| +| **BuyerUtility** | BuyerUtility → SellerTP → (SellerUtility, BuyerTP) | Outage on buyer's side | +| **SellerUtility** | SellerUtility → SellerTP → (BuyerUtility, BuyerTP) | Outage on seller's side | +| **BuyerTP** | BuyerTP → SellerTP → (SellerUtility, BuyerUtility) | Buyer requests cancellation | + +In all cases, SellerTP acts as the coordination hub, ensuring all parties receive the update and acknowledge it. --- -### Option D: Country Specific Bill Presentation Rails +## Phase 4: Energy Delivery + +*(Could be anywhere from a few hours to a few days later)* -**Example: BBPS in India** +Energy delivery follows the same physical process as the central ledger approach. The key difference is that each utility records meter data in its own ledger. -Settlement via BBPS with either seller or seller's platform as registered biller. +### Energy Injection ---- +- At scheduled time, seller injects energy into the grid +- Seller's utility performs grid security checks and permits injection only if grid stability is maintained -#### Sub-option C1: Seller as Bill Presenter +### Energy Consumption -- Seller (with platform support for KYC/registration) registers as biller on BBPS -- Trade verified → Seller raises invoice to buyer via BBPS -- Buyer pays within stipulated window -- Payment flows directly to seller -- If buyer defaults → Seller's discom notified → Buyer's discom notified for enforcement +- Buyer consumes energy as usual during the delivery window ```mermaid sequenceDiagram autonumber - participant S as Seller (P1) - participant TP as Trade Platform - participant BBPS as BBPS - participant B as Buyer (P7) - participant RA as Retailer A
(Seller's Discom) - participant RB as Retailer B
(Buyer's Discom) - - Note over S: One-time Registration - S->>TP: Request BBPS registration - TP->>TP: KYC verification - TP->>BBPS: Register seller as biller - BBPS-->>S: Biller ID assigned - - Note over S,B: After Trade Verification - S->>BBPS: Raise invoice to P7
(amount, due date) - BBPS->>B: Bill notification - - alt Buyer pays - B->>BBPS: Pay invoice - BBPS->>S: Direct payment - BBPS-->>B: Payment confirmed - else Buyer defaults - BBPS->>S: Payment overdue - S->>RA: Notify default - RA->>RB: Cross-retailer notification - RB->>B: Enforcement action - end -``` + participant S as Seller + participant SM_S as Seller's
Smart Meter + participant SellerUtility as SellerUtility + participant BuyerUtility as BuyerUtility + participant SM_B as Buyer's
Smart Meter + participant B as Buyer ---- + Note over S,B: Scheduled Delivery Window Begins -#### Sub-option C2: Platform as Bill Presenter + S->>SM_S: Generate/inject energy + SM_S->>SellerUtility: Report injection request -- Platform registers as BBPS biller -- Trade verified → Platform presents invoice to buyer -- Buyer pays via BBPS -- Platform credits seller (minus platform fee, if any) -- If buyer defaults → Platform notifies buyer's discom for enforcement + SellerUtility->>SellerUtility: Grid security check + alt Grid stable + SellerUtility->>SellerUtility: Permit injection + SM_S->>SM_S: Energy injected into grid -```mermaid -sequenceDiagram - autonumber - participant S as Seller (P1) - participant TP as Trade Platform
(BBPS Biller) - participant BBPS as BBPS - participant B as Buyer (P7) - participant RB as Retailer B
(Buyer's Discom) - - Note over TP: Platform is registered
BBPS biller - - Note over S,B: After Trade Verification - TP->>BBPS: Present invoice to P7
(amount, due date) - BBPS->>B: Bill notification - - alt Buyer pays - B->>BBPS: Pay invoice - BBPS->>TP: Payment received - TP->>TP: Deduct platform fee
(if any) - TP->>S: Credit seller - else Buyer defaults - BBPS->>TP: Payment overdue - TP->>RB: Notify default - RB->>B: Enforcement action + SM_B->>B: Energy consumed + + SM_S->>SM_S: Record injection (kWh, timestamp) + SM_B->>SM_B: Record consumption (kWh, timestamp) + else Grid unstable + SellerUtility-->>SM_S: Reject/limit injection + Note over SellerUtility: Grid stability
takes priority end -``` -| Pros | Cons | -|------|------| -| Existing infrastructure, no new rails needed, familiar UX for consumers, handles small ticket sizes well, enforcement can piggyback on discom relationship | "Bill" framing may not fit P2P trade semantics, settlement timing tied to buyer action (not automatic), need to verify BBPS allows this use case | + Note over S,B: Scheduled Delivery Window Ends +``` --- -## Phase 5: Wheeling Charges and Declaration - -This phase ensures accurate billing by preventing double-counting and collecting grid usage (wheeling) fees for P2P energy transfers. +## Phase 5: Post-Delivery Allocation and Status -### Step-by-Step Flow +After the delivery window, each utility performs allocation independently for its own customers and reports to SellerTP, which then notifies BuyerTP. -| Step | Action | Purpose | -|------|--------|---------| -| 1 | Retailers look up P2P trades from ledger | Retailers learn which energy was traded peer-to-peer | -| 2 | Retailers prepare bills (excl. P2P energy, incl. wheeling charges) | Customers only pay retailer for non-P2P energy; wheeling fees added | -| 3 | Customers pay Retailers | Single consolidated bill payment | -| 4 | Retailers remit wheeling charges to Distribution Utility | Grid usage fees flow to infrastructure operator | +### Why Allocation Matters -### Anti-Double-Billing Rules +A prosumer may have multiple trades in the same delivery window but inject/consume less than the total contracted amount. Each utility must allocate actual meter readings to specific trades to determine: +- What quantity was actually delivered/received for each trade +- What to include in billing adjustments +- Whether penalties apply for under-delivery -- **Buyer (P7):** Not charged by retailer for energy already purchased via P2P -- **Seller (P1):** Not credited by retailer for energy already sold via P2P +### Allocation Flow ```mermaid sequenceDiagram autonumber - participant TE as Trade Exchange/Ledger - participant RA as Retailer A - participant RB as Retailer B - participant S as Seller (P1) - participant B as Buyer (P7) - participant DU as Distribution Utility + participant BuyerTP as BuyerTP (BAP) + participant SellerTP as SellerTP (BPP) + participant SellerUtility as SellerUtility + participant BuyerUtility as BuyerUtility - rect rgb(230, 245, 255) - Note over TE,RB: Step 1: Ledger Lookup - RA->>TE: Look up P2P trades
(P1, billing period) - TE-->>RA: P1 sold X kWh, time slot T - RB->>TE: Look up P2P trades
(P7, billing period) - TE-->>RB: P7 bought X kWh, time slot T - end + Note over SellerUtility,BuyerUtility: Verification Cycle (e.g., every X hours) rect rgb(255, 245, 230) - Note over RA,RB: Step 2: Retailer Billing - RA->>RA: Verify: Exclude P2P energy
from retailer settlement - RA->>RA: Add wheeling charges
for P2P transfers - RA->>S: Bill (non-P2P energy +
wheeling charges) - - RB->>RB: Verify: Exclude P2P energy
from retailer charges - RB->>RB: Add wheeling charges
for P2P transfers - RB->>B: Bill (non-P2P energy +
wheeling charges) + Note over SellerUtility: Seller-Side Allocation + SellerUtility->>SellerUtility: Get all confirmed trades for
seller in delivery period + SellerUtility->>SellerUtility: Get actual meter injection data + SellerUtility->>SellerUtility: Allocate actuals to trades
(FIFO or pro-rata) end - rect rgb(230, 255, 230) - Note over S,B: Step 3: Customer Payment - S->>RA: Pay bill - B->>RB: Pay bill + rect rgb(230, 245, 255) + Note over BuyerUtility: Buyer-Side Allocation + BuyerUtility->>BuyerUtility: Get all confirmed trades for
buyer in delivery period + BuyerUtility->>BuyerUtility: Get actual meter consumption data + BuyerUtility->>BuyerUtility: Allocate actuals to trades
(FIFO or pro-rata) end - rect rgb(245, 230, 255) - Note over RA,DU: Step 4: Wheeling Remittance - RA->>DU: Remit wheeling charges (P1) - RB->>DU: Remit wheeling charges (P7) + par Utilities report to SellerTP + SellerUtility-->>SellerTP: /on_status
(seller allocated qty per trade) + and + BuyerUtility-->>SellerTP: /on_status
(buyer allocated qty per trade) end -``` - ---- -## Phase 6: Enforcement - -*(Open for Group Discussion)* + SellerTP->>BuyerTP: /on_status
(trade settlement summary) + Note right of BuyerTP: Buyer knows what to expect
in P2P payment and bill adjustment +``` -When a prosumer registers for P2P trading, they sign an agreement consenting to energy retailer/distribution utility enforcement in case of payment default. +### Allocation Example (FIFO) -### Enforcement Triggers +**Seller's trades for delivery window 2-4 PM:** -- **Payment default:** Buyer fails to pay within stipulated window -- **Non-delivery:** Seller fails to inject contracted energy -- **Repeated violations:** Pattern of defaults or contract breaches +| Trade | Trade Time | Contracted Qty | Priority | +|-------|------------|----------------|----------| +| T1 (with Buyer A) | 9:00 AM | 5 kWh | 1st | +| T2 (with Buyer B) | 9:30 AM | 4 kWh | 2nd | +| **Total** | | **9 kWh** | | -### Escalation Levels +**Actual injection: 7 kWh** -| Level | Action | When Applied | -|-------|--------|--------------| -| 1 | Warning notice | First-time minor default | -| 2 | Fine added to bill | Repeated defaults or moderate amounts | -| 3 | P2P trading privileges suspended | Persistent non-compliance | -| 4 | Service disconnection | Severe cases only | +**SellerUtility allocation (FIFO):** -### Seller Compensation +| Trade | Contracted | Allocated | Status | +|-------|------------|-----------|--------| +| T1 | 5 kWh | 5 kWh | Full delivery | +| T2 | 4 kWh | 2 kWh | Partial delivery | -If enforcement recovery succeeds (e.g., fine collected from defaulting buyer), the affected seller may receive credit through their retailer. +SellerUtility sends `/on_status` to SellerTP with these allocated quantities. --- -## Contract Modification and Partial Fulfillment +## Phase 6: Billing and Settlement -### Pre-delivery Modification +Settlement involves two separate payment flows: +1. **P2P payment:** Buyer pays Seller directly for the traded energy (post-delivery) +2. **Utility billing:** Each utility bills its customer, excluding P2P energy but including wheeling charges -Either party can request changes (quantity, time, cancellation) via trading platform. The other party accepts/rejects. Trade exchange records modified contract with a small penalty to the requester. Energy retailers verify against modified contract. - -### Settlement on Actuals +```mermaid +sequenceDiagram + autonumber + participant S as Seller + participant SellerUtility as SellerUtility + participant BuyerUtility as BuyerUtility + participant B as Buyer + + rect rgb(240, 255, 240) + Note over S,B: P2P Settlement (Post-Delivery) + B->>S: Pay for P2P trade
(allocated qty × agreed price) + S-->>B: Payment confirmed + end -Regardless of contract, settlement = actual verified delivery × agreed price. Deviations handled as: + Note over SellerUtility,BuyerUtility: Monthly Billing Cycle -| Scenario | Settlement | -|----------|------------| -| **Seller under-delivers** | Buyer pays for actual; seller penalized | -| **Buyer under-consumes** | Open question: Pay for actual or contracted? | -| **Over-delivery/consumption** | Excess settles with respective energy retailer at standard rates | + rect rgb(255, 245, 230) + Note over SellerUtility: Seller's Bill + SellerUtility->>SellerUtility: Look up P2P trades from own ledger + SellerUtility->>SellerUtility: Calculate: Regular bill
- P2P sold energy credit
+ Wheeling charges + SellerUtility->>S: Monthly bill + S->>SellerUtility: Pay bill + end -**Example - Tolerance band:** Minor deviations (±10%?) settle at actuals without penalty. + rect rgb(230, 245, 255) + Note over BuyerUtility: Buyer's Bill + BuyerUtility->>BuyerUtility: Look up P2P trades from own ledger + BuyerUtility->>BuyerUtility: Calculate: Regular bill
- P2P purchased energy
+ Wheeling charges + BuyerUtility->>B: Monthly bill + B->>BuyerUtility: Pay bill + end +``` -### Overlapping Trade Reconciliation (Anti-Double-Dipping) +### P2P Payment -When a prosumer has multiple trades within the same delivery window, actual meter readings must be allocated carefully to prevent double-counting: +The buyer pays the seller directly for the P2P trade after delivery is confirmed (via `/on_status`). Payment amount is based on: +- **Allocated quantity** (from Phase 5, may be less than contracted if under-delivery) +- **Agreed price** (from the confirmed trade contract) -1. **FIFO Allocation:** Actual energy is allocated to trades in order of trade placement time (earliest first) -2. **Per-Trade Cap:** Each trade receives at most its contracted quantity -3. **Reconciled Qty:** `Recon Qty = min(Trade Qty, Remaining Actual)` +Payment mechanism options include direct bank transfer, UPI, or platform-mediated escrow (see original document for detailed settlement options). -**Example:** +### Anti-Double-Billing -| Trade | Trade Time | Delivery Window | Trade Qty | Actual Injected | Recon Qty | -|-------|------------|-----------------|-----------|-----------------|-----------| -| T1 | 9:00 AM | 2–4 PM | 5 kWh | — | 5 kWh | -| T2 | 9:30 AM | 2–4 PM | 4 kWh | — | 3 kWh | -| **Total** | — | — | 9 kWh | **8 kWh** | 8 kWh | +- **Buyer:** BuyerUtility excludes P2P energy from regular charges (buyer already paid seller directly) +- **Seller:** SellerUtility excludes P2P energy from injection credit (seller already received payment from buyer) -*P1 contracted 9 kWh across two trades but only injected 8 kWh. T1 (earlier trade) gets full 5 kWh; T2 gets remaining 3 kWh.* +--- -A more detailed multi-party, multi-epoch example is worked out in a table [here](https://docs.google.com/spreadsheets/d/1ZXdvUnLshdOmiaqJJQuONigPK_KnTZ3Pq8aiLWYClaA/edit?usp=sharing). +## Same-Utility Collapse ---- +When buyer and seller are with the **same utility**, the flow simplifies naturally: ```mermaid sequenceDiagram autonumber - participant P as Requesting Party - participant TP as Trade Platform - participant TE as Trade Exchange - participant O as Other Party - participant L as Ledger - - Note over P,O: Pre-Delivery Modification - - P->>TP: Request modification
(quantity/time/cancel) - TP->>TE: Submit modification request - TE->>O: Notify: Modification requested - - alt Other party accepts - O->>TE: Accept modification - TE->>L: Record modified contract - TE->>L: Apply penalty to requester - TE-->>P: Modification confirmed
(penalty applied) - TE-->>O: Modification confirmed - else Other party rejects - O->>TE: Reject modification - TE-->>P: Modification rejected
(original contract stands) - end + participant BuyerTP as BuyerTP (BAP) + participant SellerTP as SellerTP (BPP) + participant Utility as Utility
(same for both) - Note over TE: Settlement Phase + BuyerTP->>SellerTP: /confirm (trade contract) + SellerTP->>Utility: /confirm (single utility call) - TE->>TE: Compare actuals vs contract + Utility->>Utility: Check both limits + Utility->>Utility: Log single trade entry + Utility->>Utility: Sign and seal order - alt Within tolerance (±10%) - TE->>L: Settle at actuals
(no penalty) - else Seller under-delivers - TE->>L: Buyer pays actuals - TE->>L: Seller penalized - else Over-delivery/consumption - TE->>L: Contract amount via P2P - Note over TE: Excess settles with
retailer at standard rates - end + Utility-->>SellerTP: /on_confirm + SellerTP-->>BuyerTP: /on_confirm + + Note over BuyerTP,Utility: Same protocol, fewer hops ``` +The protocol structure remains identical, but: +- Only one utility is involved +- No cross-utility confirm/on_confirm +- Single ledger entry (but from same utility's perspective for both parties) + --- -## Open Questions +## Comparison with Central Ledger Approach + +| Aspect | Central Ledger | Decentralized (This Approach) | +|--------|---------------|------------------------------| +| **Trust model** | All trust central exchange | Multi-party signatures | +| **Privacy** | Central entity sees all trades | Each utility sees only its customers' trades | +| **Single point of failure** | Yes (central ledger) | No | +| **Cross-utility coordination** | Via central ledger queries | Via cascading Beckn calls | +| **Regulatory complexity** | Central exchange needs regulation | Each utility self-regulates | +| **Deployment** | Requires new central infrastructure | Builds on existing utility systems | +| **Dispute resolution** | Central ledger is arbiter | Multi-party signatures provide evidence | -1. **Settlement Mechanism:** Which approach (clearing house, money block, hybrid, prepaid) and why? +--- + +## Open Questions -2. **Smart Meter Data Latency:** How quickly can energy retailers release meter data to trade exchanges? This is the binding constraint on settlement timelines. +1. **Signature Format:** What cryptographic format for multi-party signatures? (JWS, EdDSA, etc.) -3. **Inter-institution Enforcement:** If buyer defaults and buyer's energy retailer needs to act, what compels retailer B to enforce on behalf of a seller in retailer A's territory? What's the contractual or regulatory mechanism? +2. **Allocation Consistency:** If FIFO allocation differs between utilities for the same trade (due to data timing), how to reconcile? -4. **Future Trade Horizon:** Should v1 allow long-horizon trades (T+30, T+60)? If yes, we need the full futures/options complexity. +3. **Cross-Utility Trust:** What compels SellerUtility to forward `/confirm` to BuyerUtility honestly? -5. **Regulatory Structure:** If multiple trade exchanges exist, who regulates them? How do we ensure interoperability (or do we)? +4. **Offline Handling:** If a utility is temporarily unavailable during confirmation cascade, how to handle? -6. **Partial Fulfillment:** How do we deal with partial fulfilment of contract? Is it an all or none model? +5. **Audit Trail Access:** How do trading platforms access the full signature chain for disputes? --- From a29af4254256423b71d3eed6aa61fb9a7605f79c Mon Sep 17 00:00:00 2001 From: Ameet Deshpande Date: Mon, 19 Jan 2026 01:45:37 +0530 Subject: [PATCH 7/8] reverted old inter discom arch file. --- ...ergy_retailer_P2P_trading_altarch_draft.md | 629 ++++++++++++ ...Inter_energy_retailer_P2P_trading_draft.md | 894 +++++++++--------- 2 files changed, 1079 insertions(+), 444 deletions(-) create mode 100644 docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_altarch_draft.md diff --git a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_altarch_draft.md b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_altarch_draft.md new file mode 100644 index 00000000..c343eb2f --- /dev/null +++ b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_altarch_draft.md @@ -0,0 +1,629 @@ +# Inter-Energy Retailer P2P Energy Trading (Decentralized Approach) + +## Overview + +This document describes an alternative approach to inter-energy retailer P2P trading that **eliminates the need for a central trade exchange/ledger**. Instead, each utility maintains its own ledger for its customers, and trust is established through cascading Beckn protocol calls with multi-party digital signatures. + +For the original approach using a central ledger, see [Inter_energy_retailer_P2P_trading_draft.md](./Inter_energy_retailer_P2P_trading_draft.md). + +For a detailed comparison of both approaches, see [Central_vs_Decentralized_Ledger_Comparison.md](./Central_vs_Decentralized_Ledger_Comparison.md). + +--- + +## Scenario + +P2P trading between prosumers belonging to different energy retailers/distribution utilities (discoms). Each discom handles routine activities: providing electricity connections, certifying meters, billing, maintaining grid infrastructure, and ensuring grid resilience within their jurisdiction. + +**Example:** A seller (Meter ID: M1, Utility A) sells electricity to a buyer (Meter ID: M7, Utility B). + +--- + +## Key Architectural Difference + +| Aspect | Central Ledger Approach | Decentralized Approach | +|--------|------------------------|------------------------| +| Trade records | Single central ledger (Trade Exchange) | Each utility maintains its own ledger | +| Trust model | All parties trust the central ledger | Multi-party signatures create distributed proof | +| Trading limits | Central ledger tracks all limits | Each utility tracks only its own customers' limits | +| Reconciliation | Central ledger allocates actual energy | Each utility allocates for its own customers | +| Privacy | Central entity sees all trade details | Each utility only sees trades involving its customers | + +--- + +## Actors + +| # | Actor | Role | Beckn Role | +|---|-------|------|------------| +| 1 | **BuyerTP** | Consumer's trading platform | BAP (Beckn Application Platform) | +| 2 | **SellerTP** | Producer's trading platform | BPP (Beckn Provider Platform) | +| 3 | **BuyerUtility** | Buyer's energy retailer/distribution company | BPP (for limit checks and settlement) | +| 4 | **SellerUtility** | Seller's energy retailer/distribution company | BPP (for limit checks and settlement) | +| 5 | **Buyer** | Energy consumer in P2P trade | End user | +| 6 | **Seller** | Energy producer in P2P trade | End user | + +> **Note:** When buyer and seller are with the **same utility**, the flow simplifies naturally - BuyerUtility and SellerUtility collapse into a single entity, reducing the number of hops while maintaining the same protocol structure. + +--- + +## Core Design Principles + +1. **BuyerTP-initiated, SellerTP-orchestrated flows**: All transactions start from BuyerTP (BAP), and are orchestrated by SellerTP, including informing multiple utilities if needed. Utilities do not need to ordinate directly with eachother. +2. **Cascading calls**: Multi-party flows cascade through SellerTP to both utilities +3. **Utility involvement patterns**: Utility participation within init is optional, and only needed in case customers or trading platforms don't have the trading limits imposed by the utility. After the trade is confirmed, a non-blocking intimation is required to sent to utility informing them of trade, so they can avoid double-billing and compute wheeling and deviation charges, post delivery. +4. **Distributed ledgers**: Each utility maintains its own ledger for its customers only +5. **Natural collapse**: Same-utility trades collapse to single-discom flow automatically + +--- + +## Overall Process Flow + +```mermaid +sequenceDiagram + autonumber + participant B as Buyer + participant BuyerTP as BuyerTP (BAP) + participant SellerTP as SellerTP (BPP) + participant S as Seller + participant BuyerUtility as BuyerUtility + participant SellerUtility as SellerUtility + + rect rgb(230, 245, 255) + note over BuyerTP,SellerTP: Phase 1: Trade Discovery & Selection + B->>BuyerTP: Search for energy offers + BuyerTP->>SellerTP: /select (choose offer) + SellerTP->>BuyerTP: /on_select (offer details) + end + + rect rgb(255, 250, 230) + note over BuyerTP,SellerUtility: Phase 2: Trade Initialization + BuyerTP->>SellerTP: /init (trade details) + opt Optional Utility Limit Checks + BuyerTP-->>BuyerUtility: /init (if trading limits unknown OR multi-platform onboarding is allowed) + SellerTP-->>SellerUtility: /init (cascaded) + SellerUtility-->>SellerTP: /on_init (seller's remaining limit) + BuyerUtility-->>BuyerTP: /on_init (buyer's remaining limit) + end + SellerTP->>BuyerTP: /on_init + end + + rect rgb(230, 255, 230) + note over BuyerTP,SellerUtility: Phase 3: Trade Confirmation + BuyerTP->>SellerTP: /confirm (trade contract) + alt Non-blocking (Recommended) + SellerTP->>BuyerTP: /on_confirm (trade confirmed) + par Inform utilities + SellerTP->>SellerUtility: /confirm (inform utility) + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility->>SellerTP: /on_confirm (acknowledged) + and + SellerTP->>BuyerUtility: /confirm (inform utility) + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility->>SellerTP: /on_confirm (acknowledged) + end + else Blocking + par Utility confirmations + SellerTP->>SellerUtility: /confirm + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility->>SellerTP: /on_confirm (signed) + and + SellerTP->>BuyerUtility: /confirm + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility->>SellerTP: /on_confirm (signed) + end + SellerTP->>BuyerTP: /on_confirm (signed sealed order) + end + end + + opt Phase 3b: Trade Update (e.g., scheduled outage/congestion/trading limit violation) + BuyerUtility->>SellerTP: /update (cancel/curtail trade) + par Cascade update + SellerTP->>SellerUtility: /update (notify of change) + SellerUtility->>SellerUtility: Update trade in ledger + SellerUtility-->>SellerTP: /on_update (acknowledged) + and + SellerTP->>BuyerTP: /update (notify of change) + BuyerTP->>BuyerTP: Update trade status + BuyerTP-->>SellerTP: /on_update (acknowledged) + end + SellerTP->>BuyerUtility: /on_update (update confirmed) + BuyerUtility->>BuyerUtility: Update trade in ledger + end + + rect rgb(255, 230, 230) + note over S,BuyerUtility: Phase 4: Energy Delivery + S->>SellerUtility: Request to inject energy + SellerUtility->>SellerUtility: Grid security check + alt Grid stable + SellerUtility->>S: Permit injection + S->>S: Inject energy into grid + B->>B: Consume energy + else Grid unstable + SellerUtility-->>S: Reject/limit injection + end + end + + rect rgb(245, 230, 255) + note over SellerTP,BuyerUtility: Phase 5: Post-Delivery Allocation + SellerUtility->>SellerUtility: Allocate actual pushed to trades + BuyerUtility->>BuyerUtility: Allocate actual pulled to trades + par Utilities report to SellerTP + SellerUtility-->>SellerTP: /on_status (seller allocated qty) + and + BuyerUtility-->>SellerTP: /on_status (buyer allocated qty) + end + SellerTP->>BuyerTP: /on_status (trade settlement summary) + end + + rect rgb(255, 240, 245) + note over S,B: Phase 6: Billing & Settlement + B->>S: Pay for P2P trade (post-delivery) + SellerUtility->>S: Monthly bill (excl. P2P sold, incl. wheeling) + S->>SellerUtility: Pay bill + BuyerUtility->>B: Monthly bill (excl. P2P bought, incl. wheeling) + B->>BuyerUtility: Pay bill + end +``` + +--- + +## Phase 1: Trade Discovery and Selection + +This phase follows standard Beckn discovery flow. Buyer searches for energy offers and selects one. + +```mermaid +sequenceDiagram + autonumber + participant B as Buyer + participant BuyerTP as BuyerTP (BAP) + participant SellerTP as SellerTP (BPP) + participant S as Seller + + B->>BuyerTP: Search for energy offers
(delivery window, quantity, location) + BuyerTP->>SellerTP: /select + Note right of SellerTP: Offer: 5 kWh, 2-4 PM,
$0.50/kWh + SellerTP->>BuyerTP: /on_select
(offer details, seller info) + BuyerTP->>B: Display offer details +``` + +--- + +## Phase 2: Trade Initialization + +The initialization phase optionally checks trading limits with both utilities. This is optional but recommended to prevent trade failures at confirmation time. + +### Why Check Limits? + +Each utility may impose trading limits on its customers to: +- Manage grid capacity +- Control financial exposure +- Comply with regulatory requirements + +### Initialization Flow + +```mermaid +sequenceDiagram + autonumber + participant BuyerTP as BuyerTP (BAP) + participant BuyerUtility as BuyerUtility + participant SellerTP as SellerTP (BPP) + participant SellerUtility as SellerUtility + + Note over BuyerTP,SellerUtility: Trade: 5 kWh, 2-4 PM, $0.50/kWh + + BuyerTP->>SellerTP: /init (trade details) + + opt Optional Utility Limit Checks + par Parallel limit checks + BuyerTP->>BuyerUtility: /init (buyer limit check) + BuyerUtility->>BuyerUtility: Look up buyer's
remaining trading limit + BuyerUtility-->>BuyerTP: /on_init
(remaining limit: 20 kWh) + and + SellerTP->>SellerUtility: /init (seller limit check) + SellerUtility->>SellerUtility: Look up seller's
remaining trading limit + SellerUtility-->>SellerTP: /on_init
(remaining limit: 15 kWh) + end + end + + SellerTP->>BuyerTP: /on_init
(trade initialized, limits OK) +``` + +### What Each Utility Tracks in Its Own Ledger + +| Data Element | Owner | Description | +|--------------|-------|-------------| +| Customer's trading limit | Customer's utility | Max energy that customer can trade in a period | +| Customer's confirmed trades | Customer's utility | All confirmed trades for the customer | +| Customer's actual delivery/consumption | Customer's utility | Metered data for the customer | +| Customer's allocated trade quantities | Customer's utility | Post-delivery allocation of actuals to trades | + +--- + +## Phase 3: Trade Confirmation + +This is the critical phase that establishes trust without a central ledger. SellerTP coordinates with both utilities in parallel, and each utility logs the trade and (optionally) signs the order. + +Two modes are supported: + +| Mode | When to Use | Trade Confirmed | +|------|-------------|-----------------| +| **Non-blocking (Recommended)** | Utilities cannot block trades; they are informed for record-keeping | Immediately after SellerTP receives `/confirm` | +| **Blocking** | Utilities must approve before trade is confirmed | After both utilities respond with `/on_confirm` | + +### Confirmation Flow + +```mermaid +sequenceDiagram + autonumber + participant BuyerTP as BuyerTP (BAP) + participant SellerTP as SellerTP (BPP) + participant SellerUtility as SellerUtility + participant BuyerUtility as BuyerUtility + + Note over BuyerTP,BuyerUtility: Trade: 5 kWh, 2-4 PM, $0.50/kWh + + BuyerTP->>SellerTP: /confirm (trade contract) + + alt Non-blocking (Recommended) + SellerTP->>BuyerTP: /on_confirm (trade confirmed) + par Inform utilities + SellerTP->>SellerUtility: /confirm (inform utility) + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility-->>SellerTP: /on_confirm (acknowledged) + and + SellerTP->>BuyerUtility: /confirm (inform utility) + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility-->>SellerTP: /on_confirm (acknowledged) + end + else Blocking + par Utility confirmations + SellerTP->>SellerUtility: /confirm + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility->>SellerTP: /on_confirm (signed) + and + SellerTP->>BuyerUtility: /confirm + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility->>SellerTP: /on_confirm (signed) + end + SellerTP->>BuyerTP: /on_confirm (signed sealed order) + end +``` + +### What Each Utility Does on `/confirm` + +1. Verify customer identity +2. Check customer's remaining trading limit +3. Deduct trade quantity from limit +4. Log trade in own ledger +5. (Blocking mode only) Sign the order + +### Multi-Party Signature Chain (Blocking Mode) + +In blocking mode, the sealed trade order contains signatures from all parties: + +| Signature | Attests To | +|-----------|-----------| +| BuyerTP | Buyer's intent to purchase | +| SellerTP | Seller's agreement to supply | +| BuyerUtility | Trade is within buyer's limits, logged in buyer's utility ledger | +| SellerUtility | Trade is within seller's limits, logged in seller's utility ledger | + +This creates a **tamper-proof, distributed proof of trade commitment** without requiring a central ledger. + +### Non-blocking vs Blocking Trade-offs + +| Aspect | Non-blocking | Blocking | +|--------|--------------|----------| +| **Latency** | Lower (immediate confirmation) | Higher (waits for utilities) | +| **Utility control** | Utilities informed, cannot block | Utilities can reject trades | +| **Trust model** | Trust SellerTP to inform utilities | Full multi-party consensus | +| **Use case** | High-frequency trading, trusted platforms | Regulatory requirement for utility approval | + +--- + +## Phase 3b: Trade Update (Optional) + +After a trade is confirmed but before energy delivery, a utility may need to modify or cancel the trade due to operational reasons (e.g., scheduled outage, grid constraints, regulatory intervention). + +### Why Trade Updates? + +- **Scheduled outages:** Utility plans maintenance that affects the delivery window +- **Grid constraints:** Forecasted congestion or stability issues +- **Regulatory intervention:** Compliance requirements or emergency orders +- **Meter issues:** Problems detected with buyer's or seller's metering equipment + +### Update Flow + +The initiating utility (in this example, BuyerUtility) sends `/update` to SellerTP, which coordinates the update across all parties. + +```mermaid +sequenceDiagram + autonumber + participant BuyerUtility as BuyerUtility + participant SellerTP as SellerTP (BPP) + participant SellerUtility as SellerUtility + participant BuyerTP as BuyerTP (BAP) + + Note over BuyerUtility,BuyerTP: Trade update triggered (e.g., scheduled outage) + + BuyerUtility->>SellerTP: /update (cancel/curtail trade) + Note right of SellerTP: Update reason: scheduled outage
Action: cancel OR curtail to X kWh + + par Cascade update to all parties + SellerTP->>SellerUtility: /update (notify of change) + SellerUtility->>SellerUtility: Update trade in ledger + SellerUtility-->>SellerTP: /on_update (acknowledged) + and + SellerTP->>BuyerTP: /update (notify of change) + BuyerTP->>BuyerTP: Update trade status + BuyerTP-->>SellerTP: /on_update (acknowledged) + end + + SellerTP->>BuyerUtility: /on_update (update confirmed) + BuyerUtility->>BuyerUtility: Update trade in ledger + + Note over BuyerUtility,BuyerTP: All parties now have consistent view of modified trade +``` + +### Update Types + +| Update Type | Description | Effect on Trade | +|-------------|-------------|-----------------| +| **Cancel** | Full cancellation of the trade | Trade marked as cancelled; limits restored | +| **Curtail** | Reduce contracted quantity | Trade quantity reduced; partial limits restored | +| **Reschedule** | Change delivery window | New delivery window; same quantity | + +### What Each Party Does on `/update` + +| Party | Actions | +|-------|---------| +| **SellerUtility** | Update trade in ledger; adjust seller's trading limit if cancelled/curtailed | +| **BuyerTP** | Notify buyer of change; update local trade status | +| **BuyerUtility** | Update trade in ledger; adjust buyer's trading limit if cancelled/curtailed | + +### Update Initiation + +While this example shows BuyerUtility initiating, updates can also be initiated by: + +| Initiator | Route | Use Case | +|-----------|-------|----------| +| **BuyerUtility** | BuyerUtility → SellerTP → (SellerUtility, BuyerTP) | Outage on buyer's side | +| **SellerUtility** | SellerUtility → SellerTP → (BuyerUtility, BuyerTP) | Outage on seller's side | +| **BuyerTP** | BuyerTP → SellerTP → (SellerUtility, BuyerUtility) | Buyer requests cancellation | + +In all cases, SellerTP acts as the coordination hub, ensuring all parties receive the update and acknowledge it. + +--- + +## Phase 4: Energy Delivery + +*(Could be anywhere from a few hours to a few days later)* + +Energy delivery follows the same physical process as the central ledger approach. The key difference is that each utility records meter data in its own ledger. + +### Energy Injection + +- At scheduled time, seller injects energy into the grid +- Seller's utility performs grid security checks and permits injection only if grid stability is maintained + +### Energy Consumption + +- Buyer consumes energy as usual during the delivery window + +```mermaid +sequenceDiagram + autonumber + participant S as Seller + participant SM_S as Seller's
Smart Meter + participant SellerUtility as SellerUtility + participant BuyerUtility as BuyerUtility + participant SM_B as Buyer's
Smart Meter + participant B as Buyer + + Note over S,B: Scheduled Delivery Window Begins + + S->>SM_S: Generate/inject energy + SM_S->>SellerUtility: Report injection request + + SellerUtility->>SellerUtility: Grid security check + alt Grid stable + SellerUtility->>SellerUtility: Permit injection + SM_S->>SM_S: Energy injected into grid + + SM_B->>B: Energy consumed + + SM_S->>SM_S: Record injection (kWh, timestamp) + SM_B->>SM_B: Record consumption (kWh, timestamp) + else Grid unstable + SellerUtility-->>SM_S: Reject/limit injection + Note over SellerUtility: Grid stability
takes priority + end + + Note over S,B: Scheduled Delivery Window Ends +``` + +--- + +## Phase 5: Post-Delivery Allocation and Status + +After the delivery window, each utility performs allocation independently for its own customers and reports to SellerTP, which then notifies BuyerTP. + +### Why Allocation Matters + +A prosumer may have multiple trades in the same delivery window but inject/consume less than the total contracted amount. Each utility must allocate actual meter readings to specific trades to determine: +- What quantity was actually delivered/received for each trade +- What to include in billing adjustments +- Whether penalties apply for under-delivery + +### Allocation Flow + +```mermaid +sequenceDiagram + autonumber + participant BuyerTP as BuyerTP (BAP) + participant SellerTP as SellerTP (BPP) + participant SellerUtility as SellerUtility + participant BuyerUtility as BuyerUtility + + Note over SellerUtility,BuyerUtility: Verification Cycle (e.g., every X hours) + + rect rgb(255, 245, 230) + Note over SellerUtility: Seller-Side Allocation + SellerUtility->>SellerUtility: Get all confirmed trades for
seller in delivery period + SellerUtility->>SellerUtility: Get actual meter injection data + SellerUtility->>SellerUtility: Allocate actuals to trades
(FIFO or pro-rata) + end + + rect rgb(230, 245, 255) + Note over BuyerUtility: Buyer-Side Allocation + BuyerUtility->>BuyerUtility: Get all confirmed trades for
buyer in delivery period + BuyerUtility->>BuyerUtility: Get actual meter consumption data + BuyerUtility->>BuyerUtility: Allocate actuals to trades
(FIFO or pro-rata) + end + + par Utilities report to SellerTP + SellerUtility-->>SellerTP: /on_status
(seller allocated qty per trade) + and + BuyerUtility-->>SellerTP: /on_status
(buyer allocated qty per trade) + end + + SellerTP->>BuyerTP: /on_status
(trade settlement summary) + Note right of BuyerTP: Buyer knows what to expect
in P2P payment and bill adjustment +``` + +### Allocation Example (FIFO) + +**Seller's trades for delivery window 2-4 PM:** + +| Trade | Trade Time | Contracted Qty | Priority | +|-------|------------|----------------|----------| +| T1 (with Buyer A) | 9:00 AM | 5 kWh | 1st | +| T2 (with Buyer B) | 9:30 AM | 4 kWh | 2nd | +| **Total** | | **9 kWh** | | + +**Actual injection: 7 kWh** + +**SellerUtility allocation (FIFO):** + +| Trade | Contracted | Allocated | Status | +|-------|------------|-----------|--------| +| T1 | 5 kWh | 5 kWh | Full delivery | +| T2 | 4 kWh | 2 kWh | Partial delivery | + +SellerUtility sends `/on_status` to SellerTP with these allocated quantities. + +--- + +## Phase 6: Billing and Settlement + +Settlement involves two separate payment flows: +1. **P2P payment:** Buyer pays Seller directly for the traded energy (post-delivery) +2. **Utility billing:** Each utility bills its customer, excluding P2P energy but including wheeling charges + +```mermaid +sequenceDiagram + autonumber + participant S as Seller + participant SellerUtility as SellerUtility + participant BuyerUtility as BuyerUtility + participant B as Buyer + + rect rgb(240, 255, 240) + Note over S,B: P2P Settlement (Post-Delivery) + B->>S: Pay for P2P trade
(allocated qty × agreed price) + S-->>B: Payment confirmed + end + + Note over SellerUtility,BuyerUtility: Monthly Billing Cycle + + rect rgb(255, 245, 230) + Note over SellerUtility: Seller's Bill + SellerUtility->>SellerUtility: Look up P2P trades from own ledger + SellerUtility->>SellerUtility: Calculate: Regular bill
- P2P sold energy credit
+ Wheeling charges + SellerUtility->>S: Monthly bill + S->>SellerUtility: Pay bill + end + + rect rgb(230, 245, 255) + Note over BuyerUtility: Buyer's Bill + BuyerUtility->>BuyerUtility: Look up P2P trades from own ledger + BuyerUtility->>BuyerUtility: Calculate: Regular bill
- P2P purchased energy
+ Wheeling charges + BuyerUtility->>B: Monthly bill + B->>BuyerUtility: Pay bill + end +``` + +### P2P Payment + +The buyer pays the seller directly for the P2P trade after delivery is confirmed (via `/on_status`). Payment amount is based on: +- **Allocated quantity** (from Phase 5, may be less than contracted if under-delivery) +- **Agreed price** (from the confirmed trade contract) + +Payment mechanism options include direct bank transfer, UPI, or platform-mediated escrow (see original document for detailed settlement options). + +### Anti-Double-Billing + +- **Buyer:** BuyerUtility excludes P2P energy from regular charges (buyer already paid seller directly) +- **Seller:** SellerUtility excludes P2P energy from injection credit (seller already received payment from buyer) + +--- + +## Same-Utility Collapse + +When buyer and seller are with the **same utility**, the flow simplifies naturally: + +```mermaid +sequenceDiagram + autonumber + participant BuyerTP as BuyerTP (BAP) + participant SellerTP as SellerTP (BPP) + participant Utility as Utility
(same for both) + + BuyerTP->>SellerTP: /confirm (trade contract) + SellerTP->>Utility: /confirm (single utility call) + + Utility->>Utility: Check both limits + Utility->>Utility: Log single trade entry + Utility->>Utility: Sign and seal order + + Utility-->>SellerTP: /on_confirm + SellerTP-->>BuyerTP: /on_confirm + + Note over BuyerTP,Utility: Same protocol, fewer hops +``` + +The protocol structure remains identical, but: +- Only one utility is involved +- No cross-utility confirm/on_confirm +- Single ledger entry (but from same utility's perspective for both parties) + +--- + +## Comparison with Central Ledger Approach + +| Aspect | Central Ledger | Decentralized (This Approach) | +|--------|---------------|------------------------------| +| **Trust model** | All trust central exchange | Multi-party signatures | +| **Privacy** | Central entity sees all trades | Each utility sees only its customers' trades | +| **Single point of failure** | Yes (central ledger) | No | +| **Cross-utility coordination** | Via central ledger queries | Via cascading Beckn calls | +| **Regulatory complexity** | Central exchange needs regulation | Each utility self-regulates | +| **Deployment** | Requires new central infrastructure | Builds on existing utility systems | +| **Dispute resolution** | Central ledger is arbiter | Multi-party signatures provide evidence | + +--- + +## Open Questions + +1. **Signature Format:** What cryptographic format for multi-party signatures? (JWS, EdDSA, etc.) + +2. **Allocation Consistency:** If FIFO allocation differs between utilities for the same trade (due to data timing), how to reconcile? + +3. **Cross-Utility Trust:** What compels SellerUtility to forward `/confirm` to BuyerUtility honestly? + +4. **Offline Handling:** If a utility is temporarily unavailable during confirmation cascade, how to handle? + +5. **Audit Trail Access:** How do trading platforms access the full signature chain for disputes? + +--- + +[^1]: Non-exhaustive diff --git a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_draft.md b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_draft.md index c343eb2f..0ab7e945 100644 --- a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_draft.md +++ b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_draft.md @@ -1,57 +1,50 @@ -# Inter-Energy Retailer P2P Energy Trading (Decentralized Approach) +# Inter-Energy Retailer P2P Energy Trading -## Overview - -This document describes an alternative approach to inter-energy retailer P2P trading that **eliminates the need for a central trade exchange/ledger**. Instead, each utility maintains its own ledger for its customers, and trust is established through cascading Beckn protocol calls with multi-party digital signatures. +## Scenario -For the original approach using a central ledger, see [Inter_energy_retailer_P2P_trading_draft.md](./Inter_energy_retailer_P2P_trading_draft.md). +P2P trading between prosumers belonging to different energy retailers. Each energy retailer and energy distribution utility handles routine activities: providing electricity connections, certifying meters, billing, maintaining grid infrastructure, and ensuring grid resilience within their jurisdiction. -For a detailed comparison of both approaches, see [Central_vs_Decentralized_Ledger_Comparison.md](./Central_vs_Decentralized_Ledger_Comparison.md). +**Example:** Prosumer P1 (Meter ID: M1, Retailer A) sells electricity to Prosumer P7 (Meter ID: M7, Retailer B). --- -## Scenario - -P2P trading between prosumers belonging to different energy retailers/distribution utilities (discoms). Each discom handles routine activities: providing electricity connections, certifying meters, billing, maintaining grid infrastructure, and ensuring grid resilience within their jurisdiction. +## Present World Reality / Constraints[^1] -**Example:** A seller (Meter ID: M1, Utility A) sells electricity to a buyer (Meter ID: M7, Utility B). +1. **Physical delivery is guaranteed by the grid.** Unlike other commodity exchanges, electrons flow based on physics. If P1 produces 10 kWh and P7 consumes 10 kWh on connected grids, energy "settles" physically regardless of any contract. The settlement problem is therefore purely financial: who owes whom, based on metered production and consumption. ---- - -## Key Architectural Difference +2. **Energy Retailers face bill collection challenges.** Inter-energy retailer P2P trading must not worsen this problem. -| Aspect | Central Ledger Approach | Decentralized Approach | -|--------|------------------------|------------------------| -| Trade records | Single central ledger (Trade Exchange) | Each utility maintains its own ledger | -| Trust model | All parties trust the central ledger | Multi-party signatures create distributed proof | -| Trading limits | Central ledger tracks all limits | Each utility tracks only its own customers' limits | -| Reconciliation | Central ledger allocates actual energy | Each utility allocates for its own customers | -| Privacy | Central entity sees all trade details | Each utility only sees trades involving its customers | +3. **Fewer actors is better.** Requiring many systems or institutions to participate will slow market innovation and adoption. --- -## Actors +## User Journey -| # | Actor | Role | Beckn Role | -|---|-------|------|------------| -| 1 | **BuyerTP** | Consumer's trading platform | BAP (Beckn Application Platform) | -| 2 | **SellerTP** | Producer's trading platform | BPP (Beckn Provider Platform) | -| 3 | **BuyerUtility** | Buyer's energy retailer/distribution company | BPP (for limit checks and settlement) | -| 4 | **SellerUtility** | Seller's energy retailer/distribution company | BPP (for limit checks and settlement) | -| 5 | **Buyer** | Energy consumer in P2P trade | End user | -| 6 | **Seller** | Energy producer in P2P trade | End user | +### Model I - Direct Settlement and Contracting -> **Note:** When buyer and seller are with the **same utility**, the flow simplifies naturally - BuyerUtility and SellerUtility collapse into a single entity, reducing the number of hops while maintaining the same protocol structure. +*Energy distribution companies/Energy retailers provide infrastructure and have visibility but are not in the payment flow.* --- -## Core Design Principles +## Actors -1. **BuyerTP-initiated, SellerTP-orchestrated flows**: All transactions start from BuyerTP (BAP), and are orchestrated by SellerTP, including informing multiple utilities if needed. Utilities do not need to ordinate directly with eachother. -2. **Cascading calls**: Multi-party flows cascade through SellerTP to both utilities -3. **Utility involvement patterns**: Utility participation within init is optional, and only needed in case customers or trading platforms don't have the trading limits imposed by the utility. After the trade is confirmed, a non-blocking intimation is required to sent to utility informing them of trade, so they can avoid double-billing and compute wheeling and deviation charges, post delivery. -4. **Distributed ledgers**: Each utility maintains its own ledger for its customers only -5. **Natural collapse**: Same-utility trades collapse to single-discom flow automatically +| # | Actor | Role | +|---|-------|------| +| 1 | **Energy retailers** | Consumer facing role | +| 2 | **Energy distribution companies** | Wire role / physical infra operator | +| 3 | **Buyer** | Energy consumer in P2P trade | +| 4 | **Seller** | Energy producer in P2P trade | +| 5 | **Trade platform(s)** | Consumer-facing applications that: | +| | | - Allow prosumers to interact with the trade exchange | +| | | - Handle user interfaces for trade placement and management (Energy retailer may also have a consumer interface) | +| | | - Are a separate entity from the trade exchange itself | +| 6 | **Trade exchange(s)** | A logical entity (like NYSE/NSE/LSE in stock markets) that: | +| | | - Runs the permissioned transaction ledger | +| | | - Establishes relationships with Energy distribution companies/Energy retailers (and is trusted by them) | +| | | - Provides regulatory backing and trust assurance | +| | | - May be implemented using various technologies (blockchain, database, etc.) | + +> **Assumption:** Whoever is running the permissioned ledger IS the trade exchange. This is a necessary logical construct. Whoever (regulators or other operators) runs this, that entity becomes the trade exchange. --- @@ -60,569 +53,582 @@ P2P trading between prosumers belonging to different energy retailers/distributi ```mermaid sequenceDiagram autonumber - participant B as Buyer - participant BuyerTP as BuyerTP (BAP) - participant SellerTP as SellerTP (BPP) - participant S as Seller - participant BuyerUtility as BuyerUtility - participant SellerUtility as SellerUtility + participant S as Seller (P1) + participant B as Buyer (P7) + participant TP as Trade Platform + participant TE as Trade Exchange/Ledger + participant RA as Retailer A + participant RB as Retailer B + participant DU_A as Distribution Utility A + participant DU_B as Distribution Utility B rect rgb(230, 245, 255) - note over BuyerTP,SellerTP: Phase 1: Trade Discovery & Selection - B->>BuyerTP: Search for energy offers - BuyerTP->>SellerTP: /select (choose offer) - SellerTP->>BuyerTP: /on_select (offer details) - end - - rect rgb(255, 250, 230) - note over BuyerTP,SellerUtility: Phase 2: Trade Initialization - BuyerTP->>SellerTP: /init (trade details) - opt Optional Utility Limit Checks - BuyerTP-->>BuyerUtility: /init (if trading limits unknown OR multi-platform onboarding is allowed) - SellerTP-->>SellerUtility: /init (cascaded) - SellerUtility-->>SellerTP: /on_init (seller's remaining limit) - BuyerUtility-->>BuyerTP: /on_init (buyer's remaining limit) - end - SellerTP->>BuyerTP: /on_init + note over S,TE: Phase 1: Trade Placement + S->>TP: Initiate trade + B->>TP: Accept trade + TP->>TE: Submit signed contract + TE->>TE: Record on ledger + Note right of TE: Ledger: Discom A, Discom B, seller, buyer,
Trade Time, Delivery Start/End,
Trade Qty, Actual pushed, Actual pulled Qty + DU_A-->>TE: Visibility into upcoming trades + DU_B-->>TE: Visibility into upcoming trades end rect rgb(230, 255, 230) - note over BuyerTP,SellerUtility: Phase 3: Trade Confirmation - BuyerTP->>SellerTP: /confirm (trade contract) - alt Non-blocking (Recommended) - SellerTP->>BuyerTP: /on_confirm (trade confirmed) - par Inform utilities - SellerTP->>SellerUtility: /confirm (inform utility) - SellerUtility->>SellerUtility: Deduct from seller limit, log trade - SellerUtility->>SellerTP: /on_confirm (acknowledged) - and - SellerTP->>BuyerUtility: /confirm (inform utility) - BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade - BuyerUtility->>SellerTP: /on_confirm (acknowledged) - end - else Blocking - par Utility confirmations - SellerTP->>SellerUtility: /confirm - SellerUtility->>SellerUtility: Deduct from seller limit, log trade - SellerUtility->>SellerTP: /on_confirm (signed) - and - SellerTP->>BuyerUtility: /confirm - BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade - BuyerUtility->>SellerTP: /on_confirm (signed) - end - SellerTP->>BuyerTP: /on_confirm (signed sealed order) - end + note over S,DU_B: Phase 2: Trade Delivery + S->>DU_A: Inject energy at scheduled time + DU_A->>DU_A: Grid security check + B->>B: Consume energy end - opt Phase 3b: Trade Update (e.g., scheduled outage/congestion/trading limit violation) - BuyerUtility->>SellerTP: /update (cancel/curtail trade) - par Cascade update - SellerTP->>SellerUtility: /update (notify of change) - SellerUtility->>SellerUtility: Update trade in ledger - SellerUtility-->>SellerTP: /on_update (acknowledged) - and - SellerTP->>BuyerTP: /update (notify of change) - BuyerTP->>BuyerTP: Update trade status - BuyerTP-->>SellerTP: /on_update (acknowledged) - end - SellerTP->>BuyerUtility: /on_update (update confirmed) - BuyerUtility->>BuyerUtility: Update trade in ledger + rect rgb(255, 245, 230) + note over TE,RB: Phase 3: Trade Verification + DU_A->>TE: Add/allocate actual pushed signed meter data to ledger (P1) + DU_B->>TE: Add/allocate actual pulled signed meter data to ledger (P7) end rect rgb(255, 230, 230) - note over S,BuyerUtility: Phase 4: Energy Delivery - S->>SellerUtility: Request to inject energy - SellerUtility->>SellerUtility: Grid security check - alt Grid stable - SellerUtility->>S: Permit injection - S->>S: Inject energy into grid - B->>B: Consume energy - else Grid unstable - SellerUtility-->>S: Reject/limit injection - end + note over S,B: Phase 4: Financial Settlement + Note right of TE: Settlement via chosen
mechanism (Options A-D) + B->>S: Payment (via settlement mechanism) end rect rgb(245, 230, 255) - note over SellerTP,BuyerUtility: Phase 5: Post-Delivery Allocation - SellerUtility->>SellerUtility: Allocate actual pushed to trades - BuyerUtility->>BuyerUtility: Allocate actual pulled to trades - par Utilities report to SellerTP - SellerUtility-->>SellerTP: /on_status (seller allocated qty) - and - BuyerUtility-->>SellerTP: /on_status (buyer allocated qty) - end - SellerTP->>BuyerTP: /on_status (trade settlement summary) - end - - rect rgb(255, 240, 245) - note over S,B: Phase 6: Billing & Settlement - B->>S: Pay for P2P trade (post-delivery) - SellerUtility->>S: Monthly bill (excl. P2P sold, incl. wheeling) - S->>SellerUtility: Pay bill - BuyerUtility->>B: Monthly bill (excl. P2P bought, incl. wheeling) - B->>BuyerUtility: Pay bill + note over RA,RB: Phase 5: Wheeling & Billing + RA->>TE: Look up P2P trades (P1) + RB->>TE: Look up P2P trades (P7) + RA->>S: Bill (excl. P2P + incl. wheeling) + RB->>B: Bill (excl. P2P + incl. wheeling) + S->>RA: Pay bill + B->>RB: Pay bill + RA->>DU_A: Remit wheeling charges + RB->>DU_B: Remit wheeling charges end ``` --- -## Phase 1: Trade Discovery and Selection +## Phase 1: Trade Placement + +### 1. Trade Placement -This phase follows standard Beckn discovery flow. Buyer searches for energy offers and selects one. +- P1 (Energy Retailer A) logs into a trading app and initiates a trade with P7 (Energy Retailer B) +- Trade contract specifies: fulfillment terms (delivery window, energy quantity), agreed price, meter IDs for both parties, destination energy retailer details +- Contract is digitally signed by P1 and P7 using certificates issued by the trade exchange +- **Example:** P1-A agrees to deliver 5 kWh between 2–4 PM at USD 5/kWh to P7-B + +> **Note:** As trading volumes grow, matching individual buyers to individual sellers might become impractical. A stock-exchange-style approach, where supply and demand are aggregated and matched algorithmically, may be more viable at scale. + +### 2. Ledger Recording + +- The trade is recorded on the trade exchange +- Energy distribution utilities gain visibility into scheduled trades for grid security management, capacity planning and financial reconciliation ```mermaid sequenceDiagram autonumber - participant B as Buyer - participant BuyerTP as BuyerTP (BAP) - participant SellerTP as SellerTP (BPP) - participant S as Seller - - B->>BuyerTP: Search for energy offers
(delivery window, quantity, location) - BuyerTP->>SellerTP: /select - Note right of SellerTP: Offer: 5 kWh, 2-4 PM,
$0.50/kWh - SellerTP->>BuyerTP: /on_select
(offer details, seller info) - BuyerTP->>B: Display offer details + participant S as Seller (P1)
Retailer A + participant B as Buyer (P7)
Retailer B + participant TP as Trade Platform + participant TE as Trade Exchange/Ledger + participant DU as Distribution Utility + + S->>TP: Login & initiate trade + TP->>S: Request trade details + S->>TP: Submit trade details
(delivery window, quantity,
price, meter IDs) + TP->>B: Trade invitation + B->>TP: Accept trade terms + + TP->>TE: Request signing certificates + TE-->>TP: Issue certificates + + S->>TP: Digital signature + B->>TP: Digital signature + TP->>TE: Submit signed contract + + TE->>TE: Validate signatures + TE->>TE: Record on permissioned ledger + TE-->>TP: Confirmation + TP-->>S: Trade confirmed + TP-->>B: Trade confirmed + + DU-->>TE: Visibility into scheduled trades
(for grid planning) ``` --- -## Phase 2: Trade Initialization +## Phase 2: Trade Delivery + +*(Could be anywhere from a few hours to a few days later)* -The initialization phase optionally checks trading limits with both utilities. This is optional but recommended to prevent trade failures at confirmation time. +### 3. Energy Injection -### Why Check Limits? +- At scheduled time, seller injects energy into the grid +- Corresponding energy distribution utility performs grid security checks and permits injection only if grid stability is maintained -Each utility may impose trading limits on its customers to: -- Manage grid capacity -- Control financial exposure -- Comply with regulatory requirements +### 4. Energy Consumption -### Initialization Flow +- Buyer consumes energy as usual during the delivery window ```mermaid sequenceDiagram autonumber - participant BuyerTP as BuyerTP (BAP) - participant BuyerUtility as BuyerUtility - participant SellerTP as SellerTP (BPP) - participant SellerUtility as SellerUtility - - Note over BuyerTP,SellerUtility: Trade: 5 kWh, 2-4 PM, $0.50/kWh - - BuyerTP->>SellerTP: /init (trade details) - - opt Optional Utility Limit Checks - par Parallel limit checks - BuyerTP->>BuyerUtility: /init (buyer limit check) - BuyerUtility->>BuyerUtility: Look up buyer's
remaining trading limit - BuyerUtility-->>BuyerTP: /on_init
(remaining limit: 20 kWh) - and - SellerTP->>SellerUtility: /init (seller limit check) - SellerUtility->>SellerUtility: Look up seller's
remaining trading limit - SellerUtility-->>SellerTP: /on_init
(remaining limit: 15 kWh) - end - end + participant S as Seller (P1) + participant SM_S as Seller's
Smart Meter + participant DU_A as Distribution
Utility A + participant DU_B as Distribution
Utility B + participant SM_B as Buyer's
Smart Meter + participant B as Buyer (P7) - SellerTP->>BuyerTP: /on_init
(trade initialized, limits OK) -``` + Note over S,B: Scheduled Delivery Window Begins -### What Each Utility Tracks in Its Own Ledger + S->>SM_S: Generate/inject energy + SM_S->>DU_A: Report injection request -| Data Element | Owner | Description | -|--------------|-------|-------------| -| Customer's trading limit | Customer's utility | Max energy that customer can trade in a period | -| Customer's confirmed trades | Customer's utility | All confirmed trades for the customer | -| Customer's actual delivery/consumption | Customer's utility | Metered data for the customer | -| Customer's allocated trade quantities | Customer's utility | Post-delivery allocation of actuals to trades | + DU_A->>DU_A: Grid security check + alt Grid stable + DU_A->>DU_A: Permit injection + SM_S->>SM_S: Energy injected into grid ---- + SM_B->>B: Energy consumed + + SM_S->>SM_S: Record injection (kWh, timestamp) + SM_B->>SM_B: Record consumption (kWh, timestamp) + else Grid unstable + DU_A-->>SM_S: Reject/limit injection + Note over DU_A: Grid stability
takes priority + end + + Note over S,B: Scheduled Delivery Window Ends +``` -## Phase 3: Trade Confirmation +--- -This is the critical phase that establishes trust without a central ledger. SellerTP coordinates with both utilities in parallel, and each utility logs the trade and (optionally) signs the order. +## Phase 3: Trade Verification -Two modes are supported: +*(Will happen at a time gap from execution - verification frequency can be pre-determined, like every x hours)* -| Mode | When to Use | Trade Confirmed | -|------|-------------|-----------------| -| **Non-blocking (Recommended)** | Utilities cannot block trades; they are informed for record-keeping | Immediately after SellerTP receives `/confirm` | -| **Blocking** | Utilities must approve before trade is confirmed | After both utilities respond with `/on_confirm` | +### 5. Trade Verification -### Confirmation Flow +- Distribution utilities update the ledger with digitally signed meter data for both parties +- For overlapping trades (same delivery window), actual energy is allocated FIFO by trade time; reconciled quantity = min(trade qty, actual pushed) +- Trade exchange/ledger marks trade as complete ```mermaid sequenceDiagram autonumber - participant BuyerTP as BuyerTP (BAP) - participant SellerTP as SellerTP (BPP) - participant SellerUtility as SellerUtility - participant BuyerUtility as BuyerUtility - - Note over BuyerTP,BuyerUtility: Trade: 5 kWh, 2-4 PM, $0.50/kWh - - BuyerTP->>SellerTP: /confirm (trade contract) - - alt Non-blocking (Recommended) - SellerTP->>BuyerTP: /on_confirm (trade confirmed) - par Inform utilities - SellerTP->>SellerUtility: /confirm (inform utility) - SellerUtility->>SellerUtility: Deduct from seller limit, log trade - SellerUtility-->>SellerTP: /on_confirm (acknowledged) - and - SellerTP->>BuyerUtility: /confirm (inform utility) - BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade - BuyerUtility-->>SellerTP: /on_confirm (acknowledged) - end - else Blocking - par Utility confirmations - SellerTP->>SellerUtility: /confirm - SellerUtility->>SellerUtility: Deduct from seller limit, log trade - SellerUtility->>SellerTP: /on_confirm (signed) - and - SellerTP->>BuyerUtility: /confirm - BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade - BuyerUtility->>SellerTP: /on_confirm (signed) - end - SellerTP->>BuyerTP: /on_confirm (signed sealed order) - end -``` + participant TE as Trade Exchange/Ledger + participant DU_A as Distribution Utility A + participant DU_B as Distribution Utility B -### What Each Utility Does on `/confirm` + Note over TE: Verification cycle triggered
(e.g., every X hours) -1. Verify customer identity -2. Check customer's remaining trading limit -3. Deduct trade quantity from limit -4. Log trade in own ledger -5. (Blocking mode only) Sign the order + DU_A->>TE: Update ledger with signed meter data
(Meter M1, P1 injection: X kWh) + DU_B->>TE: Update ledger with signed meter data
(Meter M7, P7 consumption: Y kWh) -### Multi-Party Signature Chain (Blocking Mode) + Note over TE: Anti-double-dipping: For overlapping trades,
actual kWh allocated FIFO by trade time.
Recon Qty = min(Trade Qty, Actual Pushed).
(See Overlapping Trade Reconciliation) -In blocking mode, the sealed trade order contains signatures from all parties: + TE->>TE: Validate digital signatures + TE->>TE: Compare actuals vs contract -| Signature | Attests To | -|-----------|-----------| -| BuyerTP | Buyer's intent to purchase | -| SellerTP | Seller's agreement to supply | -| BuyerUtility | Trade is within buyer's limits, logged in buyer's utility ledger | -| SellerUtility | Trade is within seller's limits, logged in seller's utility ledger | + alt Delivery matches contract + TE->>TE: Mark trade COMPLETE + Note over TE: Proceed to settlement + else Partial delivery + TE->>TE: Record actual delivery + Note over TE: Apply settlement rules
(see Contract Modification) + else No delivery + TE->>TE: Mark trade FAILED + Note over TE: Trigger penalty/
enforcement + end +``` -This creates a **tamper-proof, distributed proof of trade commitment** without requiring a central ledger. +--- -### Non-blocking vs Blocking Trade-offs +## Phase 4: Financial Settlement -| Aspect | Non-blocking | Blocking | -|--------|--------------|----------| -| **Latency** | Lower (immediate confirmation) | Higher (waits for utilities) | -| **Utility control** | Utilities informed, cannot block | Utilities can reject trades | -| **Trust model** | Trust SellerTP to inform utilities | Full multi-party consensus | -| **Use case** | High-frequency trading, trusted platforms | Regulatory requirement for utility approval | +### Settlement Options (Open for Group Discussion) --- -## Phase 3b: Trade Update (Optional) +### Option A: Clearing House Model -After a trade is confirmed but before energy delivery, a utility may need to modify or cancel the trade due to operational reasons (e.g., scheduled outage, grid constraints, regulatory intervention). +- Central clearing house holds funds from the buyer (at the time of trade placement or at a later date for trades happening much later) +- Releases to seller upon delivery confirmation +- Similar to stock exchange settlement -### Why Trade Updates? +| Pros | Cons | +|------|------| +| Familiar pattern, trusted intermediary, proven at scale | Requires new infrastructure; problematic for long-horizon trades (when does money go to the clearing house for a T+60 trade - day 1 or day 59?) | -- **Scheduled outages:** Utility plans maintenance that affects the delivery window -- **Grid constraints:** Forecasted congestion or stability issues -- **Regulatory intervention:** Compliance requirements or emergency orders -- **Meter issues:** Problems detected with buyer's or seller's metering equipment +```mermaid +sequenceDiagram + autonumber + participant B as Buyer (P7) + participant CH as Clearing House + participant TE as Trade Exchange + participant S as Seller (P1) + + Note over B,S: At Trade Placement (or later for future trades) + B->>CH: Deposit funds + CH->>CH: Hold funds in escrow + CH-->>B: Deposit confirmed + + Note over B,S: After Trade Verification + TE->>CH: Trade verified
(delivery confirmed) + CH->>CH: Release funds + CH->>S: Transfer payment + S-->>CH: Payment received + + CH->>TE: Settlement complete +``` -### Update Flow +--- -The initiating utility (in this example, BuyerUtility) sends `/update` to SellerTP, which coordinates the update across all parties. +### Option B: Money Block / Escrow Model + +- Funds blocked at trade placement +- Released on delivery confirmation +- Many payment rails like credit cards already support blocking + +| Pros | Cons | +|------|------| +| Real-time assurance, works for immediate trades | Complex for future trades - how will we block money for 15, 30, 60 days? | ```mermaid sequenceDiagram autonumber - participant BuyerUtility as BuyerUtility - participant SellerTP as SellerTP (BPP) - participant SellerUtility as SellerUtility - participant BuyerTP as BuyerTP (BAP) - - Note over BuyerUtility,BuyerTP: Trade update triggered (e.g., scheduled outage) - - BuyerUtility->>SellerTP: /update (cancel/curtail trade) - Note right of SellerTP: Update reason: scheduled outage
Action: cancel OR curtail to X kWh - - par Cascade update to all parties - SellerTP->>SellerUtility: /update (notify of change) - SellerUtility->>SellerUtility: Update trade in ledger - SellerUtility-->>SellerTP: /on_update (acknowledged) - and - SellerTP->>BuyerTP: /update (notify of change) - BuyerTP->>BuyerTP: Update trade status - BuyerTP-->>SellerTP: /on_update (acknowledged) - end - - SellerTP->>BuyerUtility: /on_update (update confirmed) - BuyerUtility->>BuyerUtility: Update trade in ledger - - Note over BuyerUtility,BuyerTP: All parties now have consistent view of modified trade + participant B as Buyer (P7) + participant Bank as Buyer's Bank/
Payment Rail + participant TE as Trade Exchange + participant S as Seller (P1) + + Note over B,S: At Trade Placement + TE->>Bank: Request fund block
(amount, duration) + Bank->>Bank: Block funds in
buyer's account + Bank-->>TE: Block confirmed + Bank-->>B: Funds blocked notification + + Note over B,S: After Trade Verification + TE->>Bank: Release blocked funds
to seller + Bank->>Bank: Unblock & transfer + Bank->>S: Payment credited + Bank-->>B: Funds released notification + + Note over Bank: Challenge: How to maintain
block for 15-60 days? ``` -### Update Types +--- -| Update Type | Description | Effect on Trade | -|-------------|-------------|-----------------| -| **Cancel** | Full cancellation of the trade | Trade marked as cancelled; limits restored | -| **Curtail** | Reduce contracted quantity | Trade quantity reduced; partial limits restored | -| **Reschedule** | Change delivery window | New delivery window; same quantity | +### Option C: Prepaid Model -### What Each Party Does on `/update` +- Every consumer/prosumer pre-pays their smart meter with x amount +- All purchases are directly addressed by respective retailers' bill collection and payments infra against the bill using the data from trade exchange -| Party | Actions | -|-------|---------| -| **SellerUtility** | Update trade in ledger; adjust seller's trading limit if cancelled/curtailed | -| **BuyerTP** | Notify buyer of change; update local trade status | -| **BuyerUtility** | Update trade in ledger; adjust buyer's trading limit if cancelled/curtailed | +```mermaid +sequenceDiagram + autonumber + participant S as Seller (P1) + participant B as Buyer (P7) + participant SM_B as Buyer's
Smart Meter + participant RA as Retailer A + participant RB as Retailer B + participant TE as Trade Exchange -### Update Initiation + Note over B: Pre-funding Phase + B->>SM_B: Pre-pay smart meter
(top-up balance) + SM_B-->>B: Balance: $X -While this example shows BuyerUtility initiating, updates can also be initiated by: + Note over S,B: After Trade Verification + TE->>RB: P2P trade data
(P7 owes P1 $Y) -| Initiator | Route | Use Case | -|-----------|-------|----------| -| **BuyerUtility** | BuyerUtility → SellerTP → (SellerUtility, BuyerTP) | Outage on buyer's side | -| **SellerUtility** | SellerUtility → SellerTP → (BuyerUtility, BuyerTP) | Outage on seller's side | -| **BuyerTP** | BuyerTP → SellerTP → (SellerUtility, BuyerUtility) | Buyer requests cancellation | + RB->>SM_B: Debit P2P purchase + SM_B->>SM_B: Deduct from balance -In all cases, SellerTP acts as the coordination hub, ensuring all parties receive the update and acknowledge it. + RB->>RA: Inter-retailer settlement
(P7's payment for P1) + RA->>S: Credit to seller
(via regular bill credit) ---- + Note over B: Next bill cycle + RB->>B: Regular bill
(reflects P2P debits) +``` -## Phase 4: Energy Delivery +--- -*(Could be anywhere from a few hours to a few days later)* +### Option D: Country Specific Bill Presentation Rails -Energy delivery follows the same physical process as the central ledger approach. The key difference is that each utility records meter data in its own ledger. +**Example: BBPS in India** -### Energy Injection +Settlement via BBPS with either seller or seller's platform as registered biller. -- At scheduled time, seller injects energy into the grid -- Seller's utility performs grid security checks and permits injection only if grid stability is maintained +--- -### Energy Consumption +#### Sub-option C1: Seller as Bill Presenter -- Buyer consumes energy as usual during the delivery window +- Seller (with platform support for KYC/registration) registers as biller on BBPS +- Trade verified → Seller raises invoice to buyer via BBPS +- Buyer pays within stipulated window +- Payment flows directly to seller +- If buyer defaults → Seller's discom notified → Buyer's discom notified for enforcement ```mermaid sequenceDiagram autonumber - participant S as Seller - participant SM_S as Seller's
Smart Meter - participant SellerUtility as SellerUtility - participant BuyerUtility as BuyerUtility - participant SM_B as Buyer's
Smart Meter - participant B as Buyer - - Note over S,B: Scheduled Delivery Window Begins + participant S as Seller (P1) + participant TP as Trade Platform + participant BBPS as BBPS + participant B as Buyer (P7) + participant RA as Retailer A
(Seller's Discom) + participant RB as Retailer B
(Buyer's Discom) + + Note over S: One-time Registration + S->>TP: Request BBPS registration + TP->>TP: KYC verification + TP->>BBPS: Register seller as biller + BBPS-->>S: Biller ID assigned + + Note over S,B: After Trade Verification + S->>BBPS: Raise invoice to P7
(amount, due date) + BBPS->>B: Bill notification + + alt Buyer pays + B->>BBPS: Pay invoice + BBPS->>S: Direct payment + BBPS-->>B: Payment confirmed + else Buyer defaults + BBPS->>S: Payment overdue + S->>RA: Notify default + RA->>RB: Cross-retailer notification + RB->>B: Enforcement action + end +``` - S->>SM_S: Generate/inject energy - SM_S->>SellerUtility: Report injection request +--- - SellerUtility->>SellerUtility: Grid security check - alt Grid stable - SellerUtility->>SellerUtility: Permit injection - SM_S->>SM_S: Energy injected into grid +#### Sub-option C2: Platform as Bill Presenter - SM_B->>B: Energy consumed +- Platform registers as BBPS biller +- Trade verified → Platform presents invoice to buyer +- Buyer pays via BBPS +- Platform credits seller (minus platform fee, if any) +- If buyer defaults → Platform notifies buyer's discom for enforcement - SM_S->>SM_S: Record injection (kWh, timestamp) - SM_B->>SM_B: Record consumption (kWh, timestamp) - else Grid unstable - SellerUtility-->>SM_S: Reject/limit injection - Note over SellerUtility: Grid stability
takes priority +```mermaid +sequenceDiagram + autonumber + participant S as Seller (P1) + participant TP as Trade Platform
(BBPS Biller) + participant BBPS as BBPS + participant B as Buyer (P7) + participant RB as Retailer B
(Buyer's Discom) + + Note over TP: Platform is registered
BBPS biller + + Note over S,B: After Trade Verification + TP->>BBPS: Present invoice to P7
(amount, due date) + BBPS->>B: Bill notification + + alt Buyer pays + B->>BBPS: Pay invoice + BBPS->>TP: Payment received + TP->>TP: Deduct platform fee
(if any) + TP->>S: Credit seller + else Buyer defaults + BBPS->>TP: Payment overdue + TP->>RB: Notify default + RB->>B: Enforcement action end - - Note over S,B: Scheduled Delivery Window Ends ``` +| Pros | Cons | +|------|------| +| Existing infrastructure, no new rails needed, familiar UX for consumers, handles small ticket sizes well, enforcement can piggyback on discom relationship | "Bill" framing may not fit P2P trade semantics, settlement timing tied to buyer action (not automatic), need to verify BBPS allows this use case | + --- -## Phase 5: Post-Delivery Allocation and Status +## Phase 5: Wheeling Charges and Declaration + +This phase ensures accurate billing by preventing double-counting and collecting grid usage (wheeling) fees for P2P energy transfers. -After the delivery window, each utility performs allocation independently for its own customers and reports to SellerTP, which then notifies BuyerTP. +### Step-by-Step Flow -### Why Allocation Matters +| Step | Action | Purpose | +|------|--------|---------| +| 1 | Retailers look up P2P trades from ledger | Retailers learn which energy was traded peer-to-peer | +| 2 | Retailers prepare bills (excl. P2P energy, incl. wheeling charges) | Customers only pay retailer for non-P2P energy; wheeling fees added | +| 3 | Customers pay Retailers | Single consolidated bill payment | +| 4 | Retailers remit wheeling charges to Distribution Utility | Grid usage fees flow to infrastructure operator | -A prosumer may have multiple trades in the same delivery window but inject/consume less than the total contracted amount. Each utility must allocate actual meter readings to specific trades to determine: -- What quantity was actually delivered/received for each trade -- What to include in billing adjustments -- Whether penalties apply for under-delivery +### Anti-Double-Billing Rules -### Allocation Flow +- **Buyer (P7):** Not charged by retailer for energy already purchased via P2P +- **Seller (P1):** Not credited by retailer for energy already sold via P2P ```mermaid sequenceDiagram autonumber - participant BuyerTP as BuyerTP (BAP) - participant SellerTP as SellerTP (BPP) - participant SellerUtility as SellerUtility - participant BuyerUtility as BuyerUtility + participant TE as Trade Exchange/Ledger + participant RA as Retailer A + participant RB as Retailer B + participant S as Seller (P1) + participant B as Buyer (P7) + participant DU as Distribution Utility - Note over SellerUtility,BuyerUtility: Verification Cycle (e.g., every X hours) + rect rgb(230, 245, 255) + Note over TE,RB: Step 1: Ledger Lookup + RA->>TE: Look up P2P trades
(P1, billing period) + TE-->>RA: P1 sold X kWh, time slot T + RB->>TE: Look up P2P trades
(P7, billing period) + TE-->>RB: P7 bought X kWh, time slot T + end rect rgb(255, 245, 230) - Note over SellerUtility: Seller-Side Allocation - SellerUtility->>SellerUtility: Get all confirmed trades for
seller in delivery period - SellerUtility->>SellerUtility: Get actual meter injection data - SellerUtility->>SellerUtility: Allocate actuals to trades
(FIFO or pro-rata) + Note over RA,RB: Step 2: Retailer Billing + RA->>RA: Verify: Exclude P2P energy
from retailer settlement + RA->>RA: Add wheeling charges
for P2P transfers + RA->>S: Bill (non-P2P energy +
wheeling charges) + + RB->>RB: Verify: Exclude P2P energy
from retailer charges + RB->>RB: Add wheeling charges
for P2P transfers + RB->>B: Bill (non-P2P energy +
wheeling charges) end - rect rgb(230, 245, 255) - Note over BuyerUtility: Buyer-Side Allocation - BuyerUtility->>BuyerUtility: Get all confirmed trades for
buyer in delivery period - BuyerUtility->>BuyerUtility: Get actual meter consumption data - BuyerUtility->>BuyerUtility: Allocate actuals to trades
(FIFO or pro-rata) + rect rgb(230, 255, 230) + Note over S,B: Step 3: Customer Payment + S->>RA: Pay bill + B->>RB: Pay bill end - par Utilities report to SellerTP - SellerUtility-->>SellerTP: /on_status
(seller allocated qty per trade) - and - BuyerUtility-->>SellerTP: /on_status
(buyer allocated qty per trade) + rect rgb(245, 230, 255) + Note over RA,DU: Step 4: Wheeling Remittance + RA->>DU: Remit wheeling charges (P1) + RB->>DU: Remit wheeling charges (P7) end - - SellerTP->>BuyerTP: /on_status
(trade settlement summary) - Note right of BuyerTP: Buyer knows what to expect
in P2P payment and bill adjustment ``` -### Allocation Example (FIFO) +--- + +## Phase 6: Enforcement -**Seller's trades for delivery window 2-4 PM:** +*(Open for Group Discussion)* -| Trade | Trade Time | Contracted Qty | Priority | -|-------|------------|----------------|----------| -| T1 (with Buyer A) | 9:00 AM | 5 kWh | 1st | -| T2 (with Buyer B) | 9:30 AM | 4 kWh | 2nd | -| **Total** | | **9 kWh** | | +When a prosumer registers for P2P trading, they sign an agreement consenting to energy retailer/distribution utility enforcement in case of payment default. -**Actual injection: 7 kWh** +### Enforcement Triggers -**SellerUtility allocation (FIFO):** +- **Payment default:** Buyer fails to pay within stipulated window +- **Non-delivery:** Seller fails to inject contracted energy +- **Repeated violations:** Pattern of defaults or contract breaches -| Trade | Contracted | Allocated | Status | -|-------|------------|-----------|--------| -| T1 | 5 kWh | 5 kWh | Full delivery | -| T2 | 4 kWh | 2 kWh | Partial delivery | +### Escalation Levels -SellerUtility sends `/on_status` to SellerTP with these allocated quantities. +| Level | Action | When Applied | +|-------|--------|--------------| +| 1 | Warning notice | First-time minor default | +| 2 | Fine added to bill | Repeated defaults or moderate amounts | +| 3 | P2P trading privileges suspended | Persistent non-compliance | +| 4 | Service disconnection | Severe cases only | + +### Seller Compensation + +If enforcement recovery succeeds (e.g., fine collected from defaulting buyer), the affected seller may receive credit through their retailer. --- -## Phase 6: Billing and Settlement +## Contract Modification and Partial Fulfillment -Settlement involves two separate payment flows: -1. **P2P payment:** Buyer pays Seller directly for the traded energy (post-delivery) -2. **Utility billing:** Each utility bills its customer, excluding P2P energy but including wheeling charges +### Pre-delivery Modification -```mermaid -sequenceDiagram - autonumber - participant S as Seller - participant SellerUtility as SellerUtility - participant BuyerUtility as BuyerUtility - participant B as Buyer - - rect rgb(240, 255, 240) - Note over S,B: P2P Settlement (Post-Delivery) - B->>S: Pay for P2P trade
(allocated qty × agreed price) - S-->>B: Payment confirmed - end +Either party can request changes (quantity, time, cancellation) via trading platform. The other party accepts/rejects. Trade exchange records modified contract with a small penalty to the requester. Energy retailers verify against modified contract. - Note over SellerUtility,BuyerUtility: Monthly Billing Cycle +### Settlement on Actuals - rect rgb(255, 245, 230) - Note over SellerUtility: Seller's Bill - SellerUtility->>SellerUtility: Look up P2P trades from own ledger - SellerUtility->>SellerUtility: Calculate: Regular bill
- P2P sold energy credit
+ Wheeling charges - SellerUtility->>S: Monthly bill - S->>SellerUtility: Pay bill - end +Regardless of contract, settlement = actual verified delivery × agreed price. Deviations handled as: - rect rgb(230, 245, 255) - Note over BuyerUtility: Buyer's Bill - BuyerUtility->>BuyerUtility: Look up P2P trades from own ledger - BuyerUtility->>BuyerUtility: Calculate: Regular bill
- P2P purchased energy
+ Wheeling charges - BuyerUtility->>B: Monthly bill - B->>BuyerUtility: Pay bill - end -``` +| Scenario | Settlement | +|----------|------------| +| **Seller under-delivers** | Buyer pays for actual; seller penalized | +| **Buyer under-consumes** | Open question: Pay for actual or contracted? | +| **Over-delivery/consumption** | Excess settles with respective energy retailer at standard rates | -### P2P Payment +**Example - Tolerance band:** Minor deviations (±10%?) settle at actuals without penalty. -The buyer pays the seller directly for the P2P trade after delivery is confirmed (via `/on_status`). Payment amount is based on: -- **Allocated quantity** (from Phase 5, may be less than contracted if under-delivery) -- **Agreed price** (from the confirmed trade contract) +### Overlapping Trade Reconciliation (Anti-Double-Dipping) -Payment mechanism options include direct bank transfer, UPI, or platform-mediated escrow (see original document for detailed settlement options). +When a prosumer has multiple trades within the same delivery window, actual meter readings must be allocated carefully to prevent double-counting: -### Anti-Double-Billing +1. **FIFO Allocation:** Actual energy is allocated to trades in order of trade placement time (earliest first) +2. **Per-Trade Cap:** Each trade receives at most its contracted quantity +3. **Reconciled Qty:** `Recon Qty = min(Trade Qty, Remaining Actual)` -- **Buyer:** BuyerUtility excludes P2P energy from regular charges (buyer already paid seller directly) -- **Seller:** SellerUtility excludes P2P energy from injection credit (seller already received payment from buyer) +**Example:** ---- +| Trade | Trade Time | Delivery Window | Trade Qty | Actual Injected | Recon Qty | +|-------|------------|-----------------|-----------|-----------------|-----------| +| T1 | 9:00 AM | 2–4 PM | 5 kWh | — | 5 kWh | +| T2 | 9:30 AM | 2–4 PM | 4 kWh | — | 3 kWh | +| **Total** | — | — | 9 kWh | **8 kWh** | 8 kWh | -## Same-Utility Collapse +*P1 contracted 9 kWh across two trades but only injected 8 kWh. T1 (earlier trade) gets full 5 kWh; T2 gets remaining 3 kWh.* -When buyer and seller are with the **same utility**, the flow simplifies naturally: +A more detailed multi-party, multi-epoch example is worked out in a table [here](https://docs.google.com/spreadsheets/d/1ZXdvUnLshdOmiaqJJQuONigPK_KnTZ3Pq8aiLWYClaA/edit?usp=sharing). + +--- ```mermaid sequenceDiagram autonumber - participant BuyerTP as BuyerTP (BAP) - participant SellerTP as SellerTP (BPP) - participant Utility as Utility
(same for both) - - BuyerTP->>SellerTP: /confirm (trade contract) - SellerTP->>Utility: /confirm (single utility call) + participant P as Requesting Party + participant TP as Trade Platform + participant TE as Trade Exchange + participant O as Other Party + participant L as Ledger + + Note over P,O: Pre-Delivery Modification + + P->>TP: Request modification
(quantity/time/cancel) + TP->>TE: Submit modification request + TE->>O: Notify: Modification requested + + alt Other party accepts + O->>TE: Accept modification + TE->>L: Record modified contract + TE->>L: Apply penalty to requester + TE-->>P: Modification confirmed
(penalty applied) + TE-->>O: Modification confirmed + else Other party rejects + O->>TE: Reject modification + TE-->>P: Modification rejected
(original contract stands) + end - Utility->>Utility: Check both limits - Utility->>Utility: Log single trade entry - Utility->>Utility: Sign and seal order + Note over TE: Settlement Phase - Utility-->>SellerTP: /on_confirm - SellerTP-->>BuyerTP: /on_confirm + TE->>TE: Compare actuals vs contract - Note over BuyerTP,Utility: Same protocol, fewer hops + alt Within tolerance (±10%) + TE->>L: Settle at actuals
(no penalty) + else Seller under-delivers + TE->>L: Buyer pays actuals + TE->>L: Seller penalized + else Over-delivery/consumption + TE->>L: Contract amount via P2P + Note over TE: Excess settles with
retailer at standard rates + end ``` -The protocol structure remains identical, but: -- Only one utility is involved -- No cross-utility confirm/on_confirm -- Single ledger entry (but from same utility's perspective for both parties) - ---- - -## Comparison with Central Ledger Approach - -| Aspect | Central Ledger | Decentralized (This Approach) | -|--------|---------------|------------------------------| -| **Trust model** | All trust central exchange | Multi-party signatures | -| **Privacy** | Central entity sees all trades | Each utility sees only its customers' trades | -| **Single point of failure** | Yes (central ledger) | No | -| **Cross-utility coordination** | Via central ledger queries | Via cascading Beckn calls | -| **Regulatory complexity** | Central exchange needs regulation | Each utility self-regulates | -| **Deployment** | Requires new central infrastructure | Builds on existing utility systems | -| **Dispute resolution** | Central ledger is arbiter | Multi-party signatures provide evidence | - --- ## Open Questions -1. **Signature Format:** What cryptographic format for multi-party signatures? (JWS, EdDSA, etc.) +1. **Settlement Mechanism:** Which approach (clearing house, money block, hybrid, prepaid) and why? + +2. **Smart Meter Data Latency:** How quickly can energy retailers release meter data to trade exchanges? This is the binding constraint on settlement timelines. -2. **Allocation Consistency:** If FIFO allocation differs between utilities for the same trade (due to data timing), how to reconcile? +3. **Inter-institution Enforcement:** If buyer defaults and buyer's energy retailer needs to act, what compels retailer B to enforce on behalf of a seller in retailer A's territory? What's the contractual or regulatory mechanism? -3. **Cross-Utility Trust:** What compels SellerUtility to forward `/confirm` to BuyerUtility honestly? +4. **Future Trade Horizon:** Should v1 allow long-horizon trades (T+30, T+60)? If yes, we need the full futures/options complexity. -4. **Offline Handling:** If a utility is temporarily unavailable during confirmation cascade, how to handle? +5. **Regulatory Structure:** If multiple trade exchanges exist, who regulates them? How do we ensure interoperability (or do we)? -5. **Audit Trail Access:** How do trading platforms access the full signature chain for disputes? +6. **Partial Fulfillment:** How do we deal with partial fulfilment of contract? Is it an all or none model? --- From 2005a6bcc9d2a4192978b8f39136eff612a1d408 Mon Sep 17 00:00:00 2001 From: Ameet Deshpande Date: Thu, 5 Mar 2026 09:58:33 +0530 Subject: [PATCH 8/8] simply sequence diagram --- ...ergy_retailer_P2P_trading_altarch_draft.md | 136 ++++-------------- 1 file changed, 26 insertions(+), 110 deletions(-) diff --git a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_altarch_draft.md b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_altarch_draft.md index c343eb2f..70f1a316 100644 --- a/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_altarch_draft.md +++ b/docs/implementation-guides/v2/P2P_Trading/Inter_energy_retailer_P2P_trading_altarch_draft.md @@ -6,8 +6,6 @@ This document describes an alternative approach to inter-energy retailer P2P tra For the original approach using a central ledger, see [Inter_energy_retailer_P2P_trading_draft.md](./Inter_energy_retailer_P2P_trading_draft.md). -For a detailed comparison of both approaches, see [Central_vs_Decentralized_Ledger_Comparison.md](./Central_vs_Decentralized_Ledger_Comparison.md). - --- ## Scenario @@ -89,28 +87,15 @@ sequenceDiagram rect rgb(230, 255, 230) note over BuyerTP,SellerUtility: Phase 3: Trade Confirmation BuyerTP->>SellerTP: /confirm (trade contract) - alt Non-blocking (Recommended) - SellerTP->>BuyerTP: /on_confirm (trade confirmed) - par Inform utilities - SellerTP->>SellerUtility: /confirm (inform utility) - SellerUtility->>SellerUtility: Deduct from seller limit, log trade - SellerUtility->>SellerTP: /on_confirm (acknowledged) - and - SellerTP->>BuyerUtility: /confirm (inform utility) - BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade - BuyerUtility->>SellerTP: /on_confirm (acknowledged) - end - else Blocking - par Utility confirmations - SellerTP->>SellerUtility: /confirm - SellerUtility->>SellerUtility: Deduct from seller limit, log trade - SellerUtility->>SellerTP: /on_confirm (signed) - and - SellerTP->>BuyerUtility: /confirm - BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade - BuyerUtility->>SellerTP: /on_confirm (signed) - end - SellerTP->>BuyerTP: /on_confirm (signed sealed order) + SellerTP->>BuyerTP: /on_confirm (trade confirmed) + par Inform utilities + SellerTP->>SellerUtility: /confirm (inform utility) + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility->>SellerTP: /on_confirm (acknowledged) + and + SellerTP->>BuyerUtility: /confirm (inform utility) + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility->>SellerTP: /on_confirm (acknowledged) end end @@ -131,15 +116,8 @@ sequenceDiagram rect rgb(255, 230, 230) note over S,BuyerUtility: Phase 4: Energy Delivery - S->>SellerUtility: Request to inject energy - SellerUtility->>SellerUtility: Grid security check - alt Grid stable - SellerUtility->>S: Permit injection - S->>S: Inject energy into grid - B->>B: Consume energy - else Grid unstable - SellerUtility-->>S: Reject/limit injection - end + S->>S: Inject energy into grid + B->>B: Consume energy end rect rgb(245, 230, 255) @@ -240,14 +218,7 @@ sequenceDiagram ## Phase 3: Trade Confirmation -This is the critical phase that establishes trust without a central ledger. SellerTP coordinates with both utilities in parallel, and each utility logs the trade and (optionally) signs the order. - -Two modes are supported: - -| Mode | When to Use | Trade Confirmed | -|------|-------------|-----------------| -| **Non-blocking (Recommended)** | Utilities cannot block trades; they are informed for record-keeping | Immediately after SellerTP receives `/confirm` | -| **Blocking** | Utilities must approve before trade is confirmed | After both utilities respond with `/on_confirm` | +This is the critical phase that establishes trust without a central ledger. SellerTP coordinates with both utilities in parallel. The trade is confirmed immediately by SellerTP, and utilities are informed non-blockingly for record-keeping — they cannot block trades. ### Confirmation Flow @@ -262,29 +233,15 @@ sequenceDiagram Note over BuyerTP,BuyerUtility: Trade: 5 kWh, 2-4 PM, $0.50/kWh BuyerTP->>SellerTP: /confirm (trade contract) - - alt Non-blocking (Recommended) - SellerTP->>BuyerTP: /on_confirm (trade confirmed) - par Inform utilities - SellerTP->>SellerUtility: /confirm (inform utility) - SellerUtility->>SellerUtility: Deduct from seller limit, log trade - SellerUtility-->>SellerTP: /on_confirm (acknowledged) - and - SellerTP->>BuyerUtility: /confirm (inform utility) - BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade - BuyerUtility-->>SellerTP: /on_confirm (acknowledged) - end - else Blocking - par Utility confirmations - SellerTP->>SellerUtility: /confirm - SellerUtility->>SellerUtility: Deduct from seller limit, log trade - SellerUtility->>SellerTP: /on_confirm (signed) - and - SellerTP->>BuyerUtility: /confirm - BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade - BuyerUtility->>SellerTP: /on_confirm (signed) - end - SellerTP->>BuyerTP: /on_confirm (signed sealed order) + SellerTP->>BuyerTP: /on_confirm (trade confirmed) + par Inform utilities + SellerTP->>SellerUtility: /confirm (inform utility) + SellerUtility->>SellerUtility: Deduct from seller limit, log trade + SellerUtility-->>SellerTP: /on_confirm (acknowledged) + and + SellerTP->>BuyerUtility: /confirm (inform utility) + BuyerUtility->>BuyerUtility: Deduct from buyer limit, log trade + BuyerUtility-->>SellerTP: /on_confirm (acknowledged) end ``` @@ -294,29 +251,6 @@ sequenceDiagram 2. Check customer's remaining trading limit 3. Deduct trade quantity from limit 4. Log trade in own ledger -5. (Blocking mode only) Sign the order - -### Multi-Party Signature Chain (Blocking Mode) - -In blocking mode, the sealed trade order contains signatures from all parties: - -| Signature | Attests To | -|-----------|-----------| -| BuyerTP | Buyer's intent to purchase | -| SellerTP | Seller's agreement to supply | -| BuyerUtility | Trade is within buyer's limits, logged in buyer's utility ledger | -| SellerUtility | Trade is within seller's limits, logged in seller's utility ledger | - -This creates a **tamper-proof, distributed proof of trade commitment** without requiring a central ledger. - -### Non-blocking vs Blocking Trade-offs - -| Aspect | Non-blocking | Blocking | -|--------|--------------|----------| -| **Latency** | Lower (immediate confirmation) | Higher (waits for utilities) | -| **Utility control** | Utilities informed, cannot block | Utilities can reject trades | -| **Trust model** | Trust SellerTP to inform utilities | Full multi-party consensus | -| **Use case** | High-frequency trading, trusted platforms | Regulatory requirement for utility approval | --- @@ -400,43 +334,25 @@ In all cases, SellerTP acts as the coordination hub, ensuring all parties receiv Energy delivery follows the same physical process as the central ledger approach. The key difference is that each utility records meter data in its own ledger. -### Energy Injection - -- At scheduled time, seller injects energy into the grid -- Seller's utility performs grid security checks and permits injection only if grid stability is maintained - -### Energy Consumption - -- Buyer consumes energy as usual during the delivery window +At the scheduled time, the seller injects energy into the grid and the buyer consumes energy as usual during the delivery window. Smart meters on both sides record the actual quantities. ```mermaid sequenceDiagram autonumber participant S as Seller participant SM_S as Seller's
Smart Meter - participant SellerUtility as SellerUtility - participant BuyerUtility as BuyerUtility participant SM_B as Buyer's
Smart Meter participant B as Buyer Note over S,B: Scheduled Delivery Window Begins S->>SM_S: Generate/inject energy - SM_S->>SellerUtility: Report injection request - - SellerUtility->>SellerUtility: Grid security check - alt Grid stable - SellerUtility->>SellerUtility: Permit injection - SM_S->>SM_S: Energy injected into grid + SM_S->>SM_S: Energy injected into grid - SM_B->>B: Energy consumed + SM_B->>B: Energy consumed - SM_S->>SM_S: Record injection (kWh, timestamp) - SM_B->>SM_B: Record consumption (kWh, timestamp) - else Grid unstable - SellerUtility-->>SM_S: Reject/limit injection - Note over SellerUtility: Grid stability
takes priority - end + SM_S->>SM_S: Record injection (kWh, timestamp) + SM_B->>SM_B: Record consumption (kWh, timestamp) Note over S,B: Scheduled Delivery Window Ends ```