Proof of Flexibility

DayFi's network of distributed energy systems faces the challenge of ensuring availability and responsiveness when called upon for grid support dispatching by an Energy Market Operator (EMO). Proof of Flexibility was designed to build trust in availability of the protocol's aggregated capacity by randomly but regularly testing connected battery systems for responsiveness.

PoF Modeling

Proof of Flexibility (“PoF”) is the protocol's decentralized fraud proof to verify that connected energy devices are connected to the same building as the deployed meter, are listening for dispatch requests, and can provide a measurable degree of energy flexibility.

In PoF, randomized challenges are issued by a Challenger (a "validator"), directly to a Miner (a connected energy device). Challengers are continuously connected to all energy devices connected to the protocol, with direct ability to issue controls to connected devices through the protocol’s integration suite. Challenges are comprised of dispatch instructions sent to a connected device to alter its state for a limited period of time. Challenges are targeted for a random weekly issuance to each contributor’s network of connected devices. The Miner must respond to this randomized, isolated dispatch request for 15 minutes. The contributor’s associated energy monitor continuously records energy data during the challenge period.

Climate zones of the U.S.

Energy consumption data is a time series that is dependent upon multiple factors including weather, occupancy, building envelope, and climate zone. Base, or always-on, load stays relatively constant, while intermediate and peak load change based on the factors listed, among others. The goal of Proof of Flexibility is to compare actual performance data from a dispatch event against forecasted performance, within a target confidence interval.

In PoF, the 15 minute post-device dispatch energy consumption time series is compared against a deterministically derived forecast using regression models that use historical usage data, weather, and climate zone data as inputs to derive a forecasted energy usage value. A stochastic model provides upper and lower bound values around the deterministically derived value. A pseudorandom number generator is used to generate random seeds for each stochastic simulation to produce unique results for each simulation, preventing replication of forecasts in future periods.

Example load shape of a building.

The results of the contributor’s associated energy consumption change is compared against the simulated forecast. If the actual data is within an acceptable margin of error for the forecast, it is given a pass designation. If it does not, a fail designation is given. As more data is gathered, the comparison target becomes more stringent.

Onchain PoF Challenging

The FlexibleCapacityChallenger.sol contract implements DayFi's challenge mechanism for verifying energy capacity commitments, using an optimistic approach that assumes participants are fulfilling their obligations until proven otherwise. Energy consumption and dispatch data is stored in a publicly accessible off-chain database, enabling transparent verification of participant performance.

The challenge process begins when validator nodes publishes forecast results for a dispatch request to the off-chain database. At this point, the participant's actual energy consumption data should also be available in the database. A challenge condition is triggered if either the consumption data is missing or there is a significant deviation between the forecasted and actual consumption patterns.

Challengers can initiate a slashing process by submitting an onchain query through the Lagrange network to the protocol's off-chain database. This query returns two critical pieces of information: a zero-knowledge proof of the forecasting data and a success boolean that evaluates whether the actual consumption aligned with expectations within an allowable margin of error (maxError). The maxError parameter is initially set during contract deployment and can be modified through protocol governance to adjust for changing network conditions.

When the Lagrange prover network returns the query response, the protocol verifies the validity of the zero-knowledge proof. If the proof is valid but the success boolean is false, indicating a performance failure outside the maxError bounds, the protocol executes a partial slash of the participant's staked $DAY. The protocol does nothing otherwise.

The contract includes configurable timing parameters that control the challenge process. The challengeDeadline determines how long participants have to respond to a challenge, while the challengeWindow sets the maximum duration for which a challenge can remain active.