From grid signal to settlement payment. Cryptographic evidence chains that prove every stage of a curtailment event -- baseline, dispatch, execution, measurement, and settlement -- as a single verifiable structure.
v8.1 Preview • Milestone Merkle Trees ship in SWT3 v8.1 (November 2026). SDK parity across Python and TypeScript. API endpoints go live on release.
Who this is for: Demand response aggregators, ISO/RTO market operations, utility settlement teams, carbon credit registries, energy regulators (FERC, OFGEM, AEMO), measurement and verification (M&V) auditors, and developers building grid-connected evidence systems.
August 12, 2027. The Eastern Interconnection is under strain. A persistent heat dome has pushed afternoon temperatures above 102°F across the PJM Interconnection footprint -- 13 states and the District of Columbia. Grid demand is forecast to exceed 150 GW, approaching the system's capacity reserve margin.
At 13:42 ET, PJM dispatches an emergency demand response event. The curtailment window is 14:00 to 18:00 ET -- four hours of peak load reduction.
The aggregator: GridSync Energy manages a 50 MW commercial and industrial demand response portfolio across 12 enrolled sites in the PJM footprint:
GridSync must prove to PJM, to the settling utility, and to voluntary carbon market registries that the curtailment actually happened. Today, this evidence is scattered across interval meter data, SCADA exports, spreadsheets, and email confirmations. The settlement process takes 60 to 90 days. Disputes are common. Carbon credit double-counting is difficult to detect.
With SWT3 milestone trees, the entire lifecycle -- from grid signal receipt to settlement payment to carbon credit issuance -- becomes a single cryptographic structure. Every stage is witnessed. Every proof is offline-verifiable. The settlement question is answered by the math.
A demand response event follows six sequential stages. Each stage produces evidence that the next stage depends on. If any stage is missing or its evidence is incomplete, the settlement claim is weakened or invalid.
The ISO/RTO dispatches a curtailment signal via the OpenADR or proprietary protocol. The aggregator's energy management system (EMS) receives the signal and acknowledges it. Evidence required:
The aggregator confirms participation and distributes curtailment instructions to enrolled sites. Evidence required:
Each site reduces load according to its curtailment plan. This is where physical evidence meets the digital record. Evidence required:
The aggregator calculates actual load reduction against the established baseline. Evidence required:
An independent M&V entity or the ISO/RTO itself confirms the measurement. Evidence required:
The ISO/RTO or utility issues payment based on verified load reduction. Evidence required:
Assessor Note
Baseline integrity is the foundation of the entire lifecycle. ADR-BASE.1 attestations must be timestamped before the curtailment event begins. Any baseline attestation recorded after the event start time (14:00 ET in this scenario) is suspect -- the aggregator could have retroactively chosen a favorable baseline. Verify the ADR-BASE.1 timestamp against the ADR-EVENT.1 dispatch signal timestamp. The sequence must be provable.
Each lifecycle stage maps to one or more ADR procedures. The SWT3 protocol records evidence from each procedure and evaluates it deterministically. The table below shows who needs each piece of evidence and why.
| Lifecycle Stage | ADR Procedure | Evidence Captured | Who Needs It |
|---|---|---|---|
| Signal Receipt | ADR-EVENT.1 |
Dispatch signal content, receipt timestamp, ISO event ID | ISO/RTO (dispatch confirmation), Aggregator (obligation record) |
| Acknowledgment | ADR-EVENT.1 |
Aggregator ack, per-site instructions, site-level confirmation | ISO/RTO (participation confirmation), Sites (curtailment orders) |
| Curtailment Execution | ADR-CURT.1 |
Interval meter data, SCADA telemetry, BMS action logs | M&V auditor (actual reduction), ISO/RTO (compliance), Insurer (performance) |
| Measurement | ADR-BASE.1, ADR-GRID.1 |
Baseline profile, weather data, grid signal correlation, load delta | M&V auditor (methodology), ISO/RTO (settlement basis) |
| Verification | ADR-GRID.1, ADR-CURT.1 |
Independent M&V report, meter validation, methodology compliance | Utility (payment authorization), Regulator (market integrity) |
| Settlement | ADR-SETTLE.1, ADR-CARBON.1 |
Settlement statement, payment, carbon credit issuance | Utility (financial), Carbon registry (credit integrity), Aggregator (revenue) |
ADR-VOLT.1 (Autonomous Voltage Regulation) applies separately to sites with voltage regulation capabilities. When a site participates in both demand response and voltage support during the same event, ADR-VOLT.1 attestations are recorded alongside ADR-CURT.1 in the curtailment execution milestone.
Assessor Note
Settlement evidence completeness: all six lifecycle stages must have attestations for a valid settlement claim. If any stage is missing -- particularly Stage 4 (Measurement) or Stage 5 (Verification) -- the settlement proof is incomplete. The phase gate for the Settlement stage will block until all upstream milestones are satisfied. An aggregator cannot skip straight from curtailment to payment.
The demand response milestone tree has two levels of structure. A single curtailment event (the August 12 four-hour window) is one structure. The summer 2027 season portfolio -- all events dispatched between June 1 and September 30 -- rolls up into a higher-level structure.
Season Structure Root
"GridSync Summer 2027 Portfolio"
================================
/ | \
/ | \
Event Aug-12 Event Aug-19 Event Sep-03 ...
============ ============ ============
|
+--------------+--------------+--------------+
| | | |
Signal & Curtailment Measurement Settlement
Acknowledge Execution & Verify & Carbon
Milestone Milestone Milestone Milestone
| | | |
+--+--+ +---+---+ +---+---+ +---+---+
| | | | | | | | | |
ADR ADR ADR ADR ADR ADR ADR ADR ADR ADR
EVT.1 EVT.1 CRT CRT CRT BAS GRD CRT SET.1 CRB.1
(sig) (ack) .1 .1 .1 .1 .1 .1 (pay) (REC)
s1 s2 s3
Individual attestation fingerprints (one per site per procedure)
roll up to milestones. Milestones roll up to the event structure.
Event structures roll up to the season portfolio root.Three-tier tree: per-site attestations roll up to lifecycle milestones, milestones roll up to a single event structure root, and event roots roll up to the season portfolio.
For the August 12 event, the tree contains:
The event structure root is a single hash that represents the complete evidence state for one curtailment event. Change one site's interval meter data and the root changes. The math is the audit trail.
PJM needs to verify that GridSync actually curtailed 50 MW during the August 12 event. Today, this involves collecting interval meter data from 12 sites, running settlement calculations, and resolving disputes manually. With the milestone tree, the verification is a single cryptographic operation.
PJM wants to confirm that the Ashburn data center (Site DC-01, 5.2 MW obligation) curtailed as claimed. The aggregator provides a multi-tier proof for DC-01's ADR-CURT.1 attestation fingerprint:
PJM receives:
1. Attestation fingerprint: "c7a3e9f10b2d" (DC-01 curtailment)
2. Multi-tier proof:
- Milestone siblings (other sites in the curtailment milestone)
- Phase siblings (other milestones in the event)
- Structure root (the full event hash)
PJM verifies:
- Recompute milestone root from fingerprint + siblings ✓
- Recompute event root from milestone root + phase siblings ✓
- Compare event root against published structure root ✓
Result: DC-01's curtailment evidence is cryptographically
bound to the same event structure as all other sites.
Tampering with DC-01's data would change the event root.Multi-tier proof verification: PJM confirms one site's curtailment against the full event root without accessing data from other sites.
The proof is logarithmic in size. For 12 sites, the proof contains roughly 8 hashes -- not the full data from all 12 sites. PJM verifies the binding without seeing proprietary data from other sites. The aggregator's competitive information is protected. The cryptographic integrity is proven.
For the seasonal audit, PJM can verify the season portfolio root and spot-check individual event roots. Full coverage of every event in the summer season. Logarithmic effort for each check.
Today, demand response settlement takes 60 to 90 days. The delay is not computational -- it is evidentiary. Utilities and ISOs spend weeks collecting meter data, resolving baseline disputes, and reconciling aggregator claims against actual grid conditions. The data exists. The trust does not.
With milestone trees, the settlement flow becomes deterministic:
1. Event completes (18:00 ET, August 12)
2. Aggregator records per-site ADR-CURT.1 attestations
3. M&V milestone accumulates:
- ADR-BASE.1 (pre-event baseline, timestamped before 14:00)
- ADR-GRID.1 (grid signal correlation, weather normalization)
- ADR-CURT.1 verification (meter data vs baseline delta)
4. Phase gate check: M&V milestone
- All 12 sites have terminal PASS verdicts?
- Baseline timestamps precede event start?
- Grid signal correlation within tolerance?
--> GATE_OPEN
5. Settlement milestone unlocks:
- ADR-SETTLE.1 records payment calculation
- Utility verifies multi-tier proof for settlement milestone
- Payment triggers automatically on verified proof
6. Optional: ADR-CARBON.1 records carbon credit issuance
referencing the same attestation fingerprintsSettlement flow: payment triggers only after the M&V phase gate opens with verified evidence from all enrolled sites.
The utility or ISO does not review 12 spreadsheets. It verifies a hash. The multi-tier proof confirms that every upstream milestone -- signal receipt, curtailment execution, measurement, and verification -- is complete and internally consistent. The settlement question is answered by the cryptographic structure, not by manual reconciliation.
For GridSync's 50 MW portfolio, this reduces settlement from 60-90 days to the time it takes to accumulate attestations and run the gate check -- typically hours to days, depending on meter data availability.
Assessor Note
The settlement phase gate will not open if any upstream milestone has unresolved failures. If Site DC-03 has an ADR-CURT.1 FAIL (meter data gap during the event window), the M&V milestone remains incomplete, and the settlement gate blocks. The aggregator must either remediate (obtain corrected meter data) or exclude DC-03 from the settlement claim. Both actions are recorded as witnessed leaves in the tree.
Demand response curtailment produces two types of value: capacity payments from the ISO/RTO and carbon credits from avoided generation. The same 50 MW curtailment on August 12 avoided an estimated 40 metric tons of CO2 (based on PJM marginal emissions rate during the event window). That avoided generation has value in the voluntary carbon market.
The problem is double-counting. If GridSync claims carbon credits for the same curtailment that already received an ISO capacity payment, and the carbon registry has no way to verify uniqueness, the same emission reduction is monetized twice. This undermines the integrity of both markets.
ADR-CARBON.1 attestations reference the same fingerprints as ADR-SETTLE.1 attestations. The carbon credit record does not exist independently -- it is cryptographically bound to the settlement record in the same milestone tree.
The carbon credit and the capacity payment share the same cryptographic root. They are provably linked to the same physical event. A verifier can confirm both claims trace back to the same curtailment attestation without accessing the raw meter data.
SWT3 prevents double-counting within a single event structure. If the same physical curtailment is recorded in two separate structures (e.g., ST-gridsync-pjm-aug12 and ST-gridsync-ercot-aug12), SWT3 does not automatically detect the overlap because the fingerprints belong to different trees with different roots.
This scenario is unlikely for a single site -- a facility in PJM territory cannot simultaneously curtail in ERCOT because they are separate electrical interconnections. An aggregator with sites in multiple ISOs can legitimately claim carbon credits for each ISO's curtailment, provided each site is distinct and each curtailment is independently metered. The actual risk is narrower: an aggregator submits the same curtailment evidence to two different carbon registries (e.g., Verra and Gold Standard), each of which issues credits independently. SWT3 cannot detect cross-registry duplication because it operates at the evidence level, not the issuance level.
Voluntary carbon registries (Verra, Gold Standard, ACR) maintain their own double-counting rules at the registry level, including correspondent arrangements with other registries. SWT3 provides the curtailment evidence; the registry verifies issuance uniqueness. The correct architecture is: SWT3 proves the curtailment happened (evidence layer), the registry verifies no other registry has issued credits for the same event (deduplication layer). If a registry does not participate in cross-registry deduplication, the auditor must verify uniqueness manually.
Assessor Note
When auditing carbon credit claims backed by SWT3 evidence, verify two things independently: (1) within the event structure, ADR-SETTLE.1 and ADR-CARBON.1 share the same attestation fingerprints (SWT3 verification), and (2) across structures, no curtailment fingerprint from this claim appears in any other carbon credit issuance on the target registry (registry-level verification). SWT3 handles (1) cryptographically. The auditor must verify (2) against the registry's own records. A claim that passes SWT3 verification but fails registry deduplication is a valid curtailment with a duplicate credit -- the evidence is real but the claim is not unique.
For Insurers
Weather-indexed demand response insurance products can use the milestone tree as an independent claims trigger. If a weather event exceeds the indexed threshold (e.g., temperature above 100°F) and the ADR-EVENT.1 attestation confirms an ISO dispatch, the insurer can verify the curtailment occurred and the settlement was completed -- all from the structure root and a multi-tier proof. The claims investigation that once required weeks of meter data reconciliation becomes a cryptographic verification. Parametric payouts can reference the same evidence chain that the ISO uses for settlement.
Demand response operates under different regulatory frameworks in different jurisdictions. An aggregator like GridSync may participate in PJM (US), provide flexibility services in the UK, and enroll in AEMO's Wholesale Demand Response Mechanism in Australia. The lifecycle stages are the same. The regulatory requirements differ.
| Jurisdiction | Regulatory Basis | Key Requirements | Milestone Tree Adaptation |
|---|---|---|---|
| US -- PJM, ERCOT, CAISO | FERC Order 2222 (aggregator participation in wholesale markets) | Aggregators can bid DER into wholesale markets; baseline methodology per ISO tariff; 5-min interval data required. Dual participation rules: a DER cannot simultaneously provide capacity and energy from the same resource in the same interval (prevents double-compensation). Each ISO implements its own dual participation safeguards. | One structure per ISO. Separate roots for PJM and ERCOT portfolios. Shared ADR-BASE.1 methodology evidence can be referenced across structures. For dual participation compliance: ADR-GRID.1 attestations record the market product (capacity vs. energy) for each interval. If the same resource appears in both capacity and energy structures for the same dispatch interval, the milestone tree will contain conflicting ADR-GRID.1 attestations -- a verifiable violation. |
| EU | Electricity Directive 2019/944, Art. 17 (right to demand response participation) | Art. 17 establishes the right of consumers to participate in demand response through independent aggregators, without undue barriers from suppliers. Note: Art. 17 governs market access and participation rights, not M&V methodology. M&V requirements are set by each member state's national transposition and the relevant TSO/DSO network codes. REMIT (Regulation 1227/2011) governs market integrity for all wholesale energy transactions. | Same milestone structure. ADR-SETTLE.1 includes supplier compensation calculation per national transposition of Art. 17 balance responsibility provisions. Additional attestation for REMIT compliance if curtailment affects wholesale market positions. |
| Australia | AEMO Wholesale Demand Response Mechanism (Oct 2021) | Demand Response Service Provider (DRSP) registration; baseline methodology approved by AEMO; 5-min dispatch intervals; NEM settlement | ADR-BASE.1 methodology must reference AEMO-approved baseline. Settlement milestone includes NEM-specific reconciliation. Structure root shared with AEMO for spot-check verification. |
| UK | Demand Flexibility Service (National Grid ESO); Capacity Market | DFS event dispatch via Flex platform; half-hourly settlement; baselining per P376 methodology; Capacity Market settlement via Low Carbon Contracts Company | ADR-EVENT.1 records DFS dispatch. ADR-BASE.1 references P376 baseline. Settlement milestone handles both DFS payments and Capacity Market settlement separately. |
The milestone tree structure is identical across all four jurisdictions. The procedures are the same. The attestation content adapts to local requirements -- baseline methodology, settlement intervals, regulatory references -- but the cryptographic structure is universal. An aggregator operating across PJM and AEMO uses the same SDK, the same proof format, and the same verification mechanism.
Assessor Note
Cross-ISO/RTO evidence portability: an aggregator participating in multiple ISOs (PJM + ERCOT, for example) should maintain separate structure roots per ISO. This prevents cross-market settlement confusion. However, baseline methodology evidence (ADR-BASE.1) can be shared if the methodology is approved by both ISOs. When auditing a multi-ISO aggregator, verify that each settlement claim references the correct ISO-specific structure root and that no curtailment attestation fingerprint appears in structures belonging to different ISOs.
This example creates the August 12 curtailment event structure, records attestations for the six lifecycle stages, checks the phase gate, and generates a proof that PJM can verify.
from swt3_ai.milestone_merkle import MilestoneAccumulator, verify_multi_tier_proof
# Create the event structure
acc = MilestoneAccumulator(structure_id="ST-gridsync-pjm-aug12-2027")
# Define lifecycle phases (sequence enforces ordering)
acc.add_phase("PH-signal", "Signal and Acknowledgment", sequence=0)
acc.add_phase("PH-curtailment", "Curtailment Execution", sequence=1)
acc.add_phase("PH-measurement", "Measurement and Verification", sequence=2)
acc.add_phase("PH-settlement", "Settlement and Carbon", sequence=3)
# Define milestones with required ADR procedures
acc.add_milestone(
"MS-signal", "PH-signal", "Dispatch and Ack",
required_procedures=["ADR-EVENT.1"]
)
acc.add_milestone(
"MS-curtail", "PH-curtailment", "Site Curtailment",
required_procedures=["ADR-CURT.1"]
)
acc.add_milestone(
"MS-measure", "PH-measurement", "Baseline and Grid Correlation",
required_procedures=["ADR-BASE.1", "ADR-GRID.1"]
)
acc.add_milestone(
"MS-verify", "PH-measurement", "Independent Verification",
required_procedures=["ADR-CURT.1"]
)
acc.add_milestone(
"MS-settle", "PH-settlement", "Payment Settlement",
required_procedures=["ADR-SETTLE.1"]
)
acc.add_milestone(
"MS-carbon", "PH-settlement", "Carbon Credit Issuance",
required_procedures=["ADR-CARBON.1"]
)
# --- Stage 1: Signal Receipt ---
acc.add_leaf("MS-signal", "a1b2c3d4e5f6", "ADR-EVENT.1", verdict="PASS")
# --- Stage 2: Curtailment (one per site, 12 sites) ---
site_fingerprints = {
"DC-01": "c7a3e9f10b2d", "DC-02": "d8b4f0a21c3e",
"DC-03": "e9c5a1b32d4f", "DC-04": "f0d6b2c43e5a",
"CW-01": "a1e7c3d54f6b", "CW-02": "b2f8d4e65a7c",
"CW-03": "c3a9e5f76b8d", "SM-01": "d4b0f6a87c9e",
"SM-02": "e5c1a7b98d0f", "OT-01": "f6d2b8c09e1a",
"OT-02": "a7e3c9d10f2b", "UC-01": "b8f4d0e21a3c",
}
for site_id, fp in site_fingerprints.items():
acc.add_leaf("MS-curtail", fp, "ADR-CURT.1", verdict="PASS")
# --- Stage 3: Measurement ---
acc.add_leaf("MS-measure", "ba12cd34ef56", "ADR-BASE.1", verdict="PASS")
acc.add_leaf("MS-measure", "cb23de45fa67", "ADR-GRID.1", verdict="PASS")
# --- Stage 4: Verification ---
acc.add_leaf("MS-verify", "dc34ef56ab78", "ADR-CURT.1", verdict="PASS")
# Check the measurement phase gate before settlement
gate = acc.check_gate("PH-measurement")
print(f"M&V gate open: {gate['passed']}") # True
# --- Stage 5: Settlement ---
acc.add_leaf("MS-settle", "ed45fa67bc89", "ADR-SETTLE.1", verdict="PASS")
# --- Stage 6: Carbon Credits ---
acc.add_leaf("MS-carbon", "fe56ab78cd90", "ADR-CARBON.1", verdict="PASS")
# The structure root represents the entire event
print(f"Event root: {acc.structure_root}")
# Generate a proof for PJM to verify DC-01's curtailment
proof = acc.get_multi_tier_proof("c7a3e9f10b2d")
# PJM verifies offline -- no access to other sites' data
assert verify_multi_tier_proof("c7a3e9f10b2d", proof)
print("PJM verification: PASS")
import { MilestoneAccumulator, verifyMultiTierProof } from "@tenova/swt3-ai/milestone-merkle";
const acc = new MilestoneAccumulator("ST-gridsync-pjm-aug12-2027");
// Lifecycle phases
acc.addPhase("PH-signal", "Signal and Acknowledgment", 0);
acc.addPhase("PH-curtailment", "Curtailment Execution", 1);
acc.addPhase("PH-measurement", "Measurement and Verification", 2);
acc.addPhase("PH-settlement", "Settlement and Carbon", 3);
// Milestones
acc.addMilestone("MS-signal", "PH-signal", "Dispatch and Ack",
["ADR-EVENT.1"]);
acc.addMilestone("MS-curtail", "PH-curtailment", "Site Curtailment",
["ADR-CURT.1"]);
acc.addMilestone("MS-measure", "PH-measurement", "Baseline and Grid",
["ADR-BASE.1", "ADR-GRID.1"]);
acc.addMilestone("MS-settle", "PH-settlement", "Payment",
["ADR-SETTLE.1"]);
acc.addMilestone("MS-carbon", "PH-settlement", "Carbon Credits",
["ADR-CARBON.1"]);
// Record attestations
acc.addLeaf("MS-signal", "a1b2c3d4e5f6", "ADR-EVENT.1", "PASS");
acc.addLeaf("MS-curtail", "c7a3e9f10b2d", "ADR-CURT.1", "PASS");
acc.addLeaf("MS-measure", "ba12cd34ef56", "ADR-BASE.1", "PASS");
acc.addLeaf("MS-measure", "cb23de45fa67", "ADR-GRID.1", "PASS");
acc.addLeaf("MS-settle", "ed45fa67bc89", "ADR-SETTLE.1", "PASS");
acc.addLeaf("MS-carbon", "fe56ab78cd90", "ADR-CARBON.1", "PASS");
// Check gate and verify
const gate = acc.checkGate("PH-measurement");
console.log(`M&V gate: ${gate.passed}`); // true
console.log(`Event root: ${acc.structureRoot}`);
// PJM verifies one site's curtailment
const proof = acc.getMultiTierProof("c7a3e9f10b2d");
console.log(verifyMultiTierProof("c7a3e9f10b2d", proof!)); // true