Cryptographic evidence for curtailment compliance and settlement verification
These procedures ship in SWT3 v0.7.0. SDK packages publish to all registries the week of September 1, 2026.
Demand response aggregators, distributed energy resource operators, grid services providers, FERC compliance teams, ISO/RTO market participants.
Demand response settlement disputes cost aggregators millions annually. The fundamental problem: when a grid operator says you curtailed 400 kW and your meters say 500 kW, who is right? Both sides are using their own measurement systems to make their own claims.
FERC Order 2222 opened wholesale electricity markets to distributed energy resources, dramatically increasing the volume and complexity of settlement data. More participants means more disputes. More disputes means more need for independently verifiable evidence of what actually happened during each DR event.
Voltus is the largest independent demand response technology company in North America. It aggregates distributed energy resources (DERs) for wholesale electricity markets, connecting commercial and industrial energy consumers to grid operators through its software platform.
Voltus participates in capacity, energy, and ancillary services markets across ISOs and RTOs including PJM, ERCOT, CAISO, NYISO, ISO-NE, MISO, and SPP. Its platform manages the full demand response lifecycle: enrollment, baseline calculation, dispatch, curtailment verification, and financial settlement.
A DR event has four critical phases -- signal receipt, baseline establishment, curtailment execution, and financial settlement. Today, each phase is documented in the aggregator's own systems. SWT3 creates an independent witness anchor at each phase, forming a verifiable chain from grid signal to payment.
| Voltus Activity | SWT3 Procedure | What the Anchor Captures |
|---|---|---|
| DR event signal + response | ADR-EVENT.1 |
Event phase, committed kW, signal source |
| Baseline load measurement | ADR-BASE.1 |
Baseline kW, measurement method, confidence level |
| Load curtailment during event | ADR-CURT.1 |
Actual reduction kW, committed kW, compliance ratio (x1000) |
| Financial settlement | ADR-SETTLE.1 |
Settlement kWh, price per MWh, event count |
| Grid operator signal | ADR-GRID.1 |
Signal type, response latency ms, grid operator |
| Carbon credit generation | ADR-CARBON.1 |
Credit type, quantity MWh, registry ID |
SWT3 witnesses each phase of the DR event lifecycle independently. Each anchor is minted at the time the event data is reported, not retroactively. The anchors form a chain that traces the complete path from grid signal receipt through financial settlement.
Each anchor is independently verifiable. The chain provides a complete audit trail from signal receipt through financial settlement. SWT3 does not participate in load control or bidding. It observes and records.
A Voltus integration typically calls witness methods at four points in the existing workflow:
ADR-SETTLE.1 -- Settlement AttestationWhat Voltus provides: Settlement calculations from ISO/RTO market clearing.
What SWT3 records: Energy quantity, clearing price, and event count in a single verifiable anchor.
Why this matters: Settlement is where the money changes hands. If your curtailment evidence is just your own meter data, counter-parties can challenge it. An independently witnessed settlement anchor locks the energy quantity, price, and event count at the moment of calculation, before any dispute arises.
factor_a = settlement energy (kWh x100). factor_b = price per MWh (USD x100). factor_c = event count. For a $50/MWh settlement of 250 kWh across 3 events: factor_a=25000, factor_b=5000, factor_c=3.
from swt3_ai import Witness
witness = Witness(
endpoint="https://sovereign.tenova.io",
api_key="axm_live_...",
tenant_id="YOUR_TENANT"
)
# After Voltus settlement calculation
settlement = voltus_api.get_settlement(event_id="DR-2026-0830")
witness.witness_settlement(
settlement_kwh=settlement["energy_kwh"],
price_usd_per_mwh=settlement["clearing_price"],
event_count=settlement["events"]
)
import { Witness } from '@tenova/swt3-ai';
const witness = new Witness({
endpoint: 'https://sovereign.tenova.io',
apiKey: 'axm_live_...',
tenantId: 'YOUR_TENANT'
});
const settlement = await voltusApi.getSettlement('DR-2026-0830');
await witness.witnessSettlement({
settlementKwh: settlement.energyKwh,
priceUsdPerMwh: settlement.clearingPrice,
eventCount: settlement.events
});
ADR-CURT.1 -- Curtailment ComplianceWhat Voltus provides: Metered load reduction during DR events.
What SWT3 records: Actual vs committed curtailment with compliance ratio.
Why this matters: The compliance ratio is the make-or-break number. Did you deliver what you promised? Below 80% typically triggers penalties in most ISO programs. An independent witness of actual vs. committed curtailment removes the "whose meter do we trust" problem from settlement disputes.
Compliance ratio in factor_c uses x1000 encoding. 1000 = 100% compliance. Below 800 (80%) typically triggers settlement penalties in most ISO programs. Cross-reference with ADR-BASE.1 to validate the baseline used for reduction calculation.
witness.witness_curtailment(
actual_reduction_kw=450.0,
committed_kw=500.0,
compliance_ratio_x1000=900
)
ADR-BASE.1 -- Baseline MeasurementWhat Voltus provides: Customer baseline load (CBL) calculation.
What SWT3 records: Baseline value, methodology used, statistical confidence.
Why this matters: The baseline is what you would have consumed without the DR event. It is the most contested number in demand response because it is hypothetical. Witnessing the baseline method, value, and confidence level at the time of calculation prevents after-the-fact baseline manipulation.
Baseline methods: metered_10day_avg(1), regression(2), real_time_meter(3), deemed_savings(4). FERC Order 745 requires baseline accuracy for settlement. factor_c contains confidence level (x1000, so 950 = 95%).
witness.witness_baseline_consumption(
baseline_kw=500.0,
measurement_method="metered_10day_avg",
confidence_x1000=950
)
ADR-GRID.1 -- Grid Signal ResponseWhat Voltus provides: Signal receipt and dispatch timing.
What SWT3 records: Signal type, response latency, originating grid operator.
Why this matters: Response latency determines whether you qualify for premium ancillary services markets. Frequency regulation requires sub-second response. An independently witnessed timestamp of signal receipt and response proves you met the timing requirements, which directly affects your revenue.
Signal types: emergency(1), economic(2), capacity(3), frequency_regulation(4), voltage_support(5). Response latency in factor_b is milliseconds. NERC BAL-001 requires sub-second response for frequency regulation.
witness.witness_grid_signal(
signal_type="capacity",
response_latency_ms=1200,
grid_operator="PJM"
)
| Examiner Question | Where to Look |
|---|---|
| "Did the site meet its curtailment obligation?" | ADR-CURT.1, compliance_ratio_x1000 >= 1000 |
| "What baseline method was used?" | ADR-BASE.1, factor_b (method code) |
| "How fast did the site respond to the DR signal?" | ADR-GRID.1, factor_b (latency in ms) |
| "What was the settlement value?" | ADR-SETTLE.1, factor_a (kWh) x factor_b ($/MWh) / 100 |
| "Can settlement data be disputed?" | Anchors are minted at event time. SHA-256 fingerprints make retroactive alteration detectable. |
| "Is this sufficient for FERC Order 2222 compliance?" | The ADR anchor chain covers signal, baseline, curtailment, and settlement -- the four elements FERC requires for DER market participation evidence. |
# Python pip install swt3-ai # TypeScript npm install @tenova/swt3-ai
Both SDKs include all ADR witness methods. No additional packages or plugins required.