## 4 Platform Design
### Trading Platform Interacting Entities
It is a restricted function which can only be called by the providers' deployed smart contracts */
2:Input:\(addr:address\), \(N:uint256\)
3:\(i\gets 0\)
4:\(k\gets 0\)
5:while\(i\leq N\)do
6:if!ProviderEnergyTokens[addr][k].spentthen
7:\(ProviderEnergyTokens[addr][k].spent\gets true\)
8:\(i\gets i+1\)
9:endif
10:\(k\gets k+1\)
11:endwhile
```  
**Algorithm 7** DSO Smart Contract: UpdateProviderBalance1  
```
1:\(\triangleright\) /* This function returns the energy balance of a given address' account. */
2:Input:\(addr:address\)
3:Output:\(uint256\)
4:\(CountOfUnspentEnergyToken:uint256\)
5:\(CountOfUnspentEnergyToken\leftarrow\)
6:for\(i\gets 0\) to \(ProviderEnergyTokens[addr].Length\)do
7:if!ProviderEnergyTokens[addr][i].spentthen
8:\(CountOfUnspentEnergyToken\gets CountOfUnspentEnergyToken+1\)
9:endif
10:endfor
11:Return:\(CountOfUnspentEnergyToken\)
```  
**Algorithm 8** DSO Smart Contract: UpdateProviderBalance1  
Energy tokens have been used to represent the providers' energy balance instead of a simple numerical abstraction, to keep track of the history of the providers' contributions to the utility grid. The relevance of keeping track of prosumers' energy contributions in a P2P energy trading platform can be found in [66]. ```
1:\(\triangleright\) /* This function is called to redeem N tokens, it takes two inputs, an integer N and an address addr. It sets N spent tokens from the tokens owned by addr to unspent. It is a restricted function which can only be called by the providers' deployed smart contracts */
2:Input\(addr:address,N:uint256\)
3:\(i\gets 0\)
4:\(k\gets 0\)
5:while\(i\leq N\)do
6:ifProviderEnergyTokens[addr][k].spent then
7:ProviderEnergyTokens[addr][k].spent\(\gets false\)
8:\(i\gets i+1\)
9:endif
10:\(k\gets k+1\)
11:endwhile
```  
**Algorithm 8** DSO Smart Contract: UpdateProviderBalance2  
Smart contract 2 (Provider): The contract is deployed by the provider ahead of each trading round; it contains the ToU pricing for electricity consumption. Once deployed, consumers have to subscribe to the trading round during a defined period of time, by depositing money corresponding to the amount of electricity they wish to consume. The reason a deadline for subscription is defined, is that receiving a new subscription at any time can prolong the trading round indefinitely, which is not following the proposed scheme since electricity pricing is set according to prediction based on data collected during trading rounds. Each time a new subscription occurs, the smart contract checks the subscribing consumer account by calling Smart Contract 1; in case this is later certified and the provider still has enough energy balance to supply the new coming demand, the provider balance is updated accordingly, otherwise the subscription is denied. The smart contract stops accepting upcoming subscription requests if the subscription-defined time has elapsed, or if the provider has exhausted all his energy balance. The trading round then starts; it ends when all subscribing consumer deposit balance in the smart contract is zero. This time-dependent smart contract state is illustrated in Figure 8. Consumers' electricity consumption data are uploaded to the smart contract. It is used to charge consumers as well as being added to the energy consumption dataset serving to train the prediction model as discussed in Section 4.1 above. Figure 8: Time dependency of the Provider smart contract state. To test the deployed smart contract, one Ether is set to correspond to 100 kWh. Although this is not realistic, it is simpler for the sake of testing. However, other security tokens, and even stable coins linked to the country's actual currency asset, can serve as a payment method rather than Ether cryptocurrency, which has a very fluctuating value. The global smart contract variables and events are presented below in Algorithms 9 and 10, respectively.