# Proof of Flow: A Design Pattern for the Green Energy Market
## 4 Proof of Flow Design Pattern
### Resolving Potential Disputes between DERs and Aggregator
In cases 2, 3, and 4, the Proofs of Flow data allow the Operator to detect a discrepancy, however both Proofs of Flow data are legitimate from the point of view \begin{table}
\begin{tabular}{c c l} \hline \hline
**Name** & **Type** & **Purpose** \\ \hline EpochStart & uint16 & beginning of the time-frame to which the Proof of Flow refers \\ EpochEnd & uint16 & end of the time-frame to which the Proof of Flow refers \\ BlockstampBegin & uint256 & time at the beginning of the epoch \\ BlockstampEnd & uint256 & time at the end of the epoch \\ kWs & uint16 & total kilowatts of energy flow \\ ID & uint256 & unique ID of the smart meter \\ Address & address & address of the wallet of the DER or the Aggregator \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Proof of Flow data types for a range of epochs. of cryptographic signature. To determine the source of discrepancies, the Operator can examine the software of the DER's and the Aggregator's smart meters. If the software is compliant, a physical inspection, examining smart meters and transmission lines of both DER and Aggregator, can establish the cause of the discrepancy. Considering that disputes can be initiated only by the DERs, as a temporary resolution from a software perspective, the Operator can pause the DER's participation in energy production, using the StopDER() function, without unlocking its deposit until the dispute is resolved. If the issue was caused by a malfunction, the Operator, using the ReAdmitDER() function, will re-admit and compensate the DER for the incurred economic losses. However, if the problem was caused by DER tampering, its deposit will be retained to discourage such behavior. On the contrary, if the discrepancy was due the Aggregator tampering, the Operator will re-admit the DER and compensate it for the incurred economic losses using the Aggregator's deposit. The Operator has also the authority to lock the contract, using the emergency stop pattern (see Section 4.8), while searching for a new reliable Aggregator. Once the Operator has resolved the dispute, it will emit the Resolution event, which will be published on the blockchain using the ResolveDispute() function. There could be another scenario in which the provided Proofs of Flow data do not allow the Operator to identify a misbehavior. It occurs when the Aggregator and a DER collude against the Operator, manipulating either the software or the physical system, but resulting in compatible Proofs of Flow data. To keep this scenario from happening, it is the Operator's responsibility to monitor the total energy received from the Aggregator and check if there is a discrepancy with the aggregated amount detected, then the Operator can initiate the actions described above. **Consequences**  
Utilizing blockchain technology to synchronize DERs, the Aggregator and the Operator, provides a verifiable account of all their activities. All the actors involved can rest assured that no entity can take advantage of others, as their interactions are governed by the immutable and verifiable code of the smart contracts. The system of deposits, rewards and penalties incentivizes all participant to fulfill their obligations and discourage malicious behavior. Proofs of Flow represent the history of energy flows, and since they are cryptographically signed by smart meters and stored on the blockchain when requested, they provide reliable evidence to address discrepancies in energy supply and disagreements in payments. By avoiding unnecessary data storage on the blockchain, the Proof of Flow pattern not only mitigates potential privacy concerns, but also reduces the number of transactions, allowing to leverage a public blockchain such as Ethereum without being affected by fee fluctuations while avoiding expenses for on-chain storage.