# Proof of Flow: A Design Pattern for the Green Energy Market
## 4 Proof of Flow Design Pattern
### Phase 1: A DER joins an Energy Community  
To participate in the system and provide electric power, DERs need to register as energy providers by invoking the ARIA Join() function. This registration process involves transferring a security deposit to Vault which, if the DER is accepted, creates an account associated with the DER's wallet address. Additionally, the DER communicates the following parameters that characterize it, that are stored in ARIA, and will be used in subsequent activities:  
* The ID of the smart meter;
* Category: type of the DER, representing the specific source of energy used;
* Power output: namely the maximum capacity or amount of electric power it can generate and supply to the energy grid over a given time period \(t\);
* Availability: the schedule of the DER, specifying the time periods during which it can actively participate in energy provision;* Flexibility: the capability of the DER to modulate its energy production based on varying requirements;
* Compensation: the desired price expected by the DER for the supplied energy; the energy price is proposed by the DER and when ARIA analyses whether to include the DER among the energy suppliers, the proposed price can be deemed satisfactory;
* Wallet address: the unique identifier of the DER in the blockchain, allowing identification and tracking, that is the sender of the registration transaction and represents the DER univocally. These parameters are stored by the Join() function in a list that holds the prospective-DERs, enabling ARIA to determine whether to authorize a DER to transmit energy. When a DER is allowed to feed the grid, it is notified via a blockchain event (see Sections 4.5 and 4.7) and its address is moved from the list of prospective-DERs to the active DERs' pool. The security deposit provided by the DER serves as a countermeasure against unreliability and is used in cases of non-compliance or failure to fulfill obligations. During the acceptance waiting period, if the DER cancels its subscription before actively participating in the energy provision, the security deposit can be redeemed. Alternatively, it can be redeemed at the end of the contract period if it has not been used to pay fines in case the DER failed to meet its obligations or violated the terms and conditions set by ARIA. Similarly, the Aggregator is required to stake a deposit to ensure the proper functioning and adherence to the rules of the system, and may face penalties imposed by the Operator, as described in Section 4.4. This mechanism incentivizes DERs and the Aggregator to comply with the system's requirements by holding them financially responsible for their actions. To successfully implement the pattern, we make the following assumptions. 1. The pattern's time interval is synchronized with the block time of the blockchain. i.e., ARIA's SweepEpoch() function (see Section 4.7), cannot be executed more frequently than the block time. 2. When we refer to \"time\", we intend the validation of a certain number of blocks in the blockchain starting from a specific block. 3. We use the term \"epoch\", denoted as \(E\), to define a specific duration of time, univocally identified by a progressive nonce, that is represented by a fixed number of blocks. 4. We use the term \"blockstamp\" to denote a reference of a specific block in the blockchain, represented by its hash, that provides a reliable mechanism for avoiding synchronization issues. This value is used to establish a temporal cadence that is derived from the blockchain, allowing to overcome some issues that may arise when adopting timestamps. Timestamps might not provide an accurate time reference, as clocks can be tampered with or subject to malfunctions. Furthermore, unlike a timestamp, a blockstamp establishes a definitive temporal order in relation to the blockchain state and events, and is synchronized with the blockchain's pace. 5.