## 5 Automation of Debt Compensation Process by Means of Smart Contracts  
In this section, the framework for the process of compensating for a set of invoices obtained from the debt graph is presented. Figure 4 depicts the flow of the entire process. Here, the gear icon represents the system, and the user icon represents the operator. Let us remark that fully automatic compensation is not possible in Spain since, in the final step of  
Figure 3: Example of gas fees for deploying a set of contracts in the main Ethereum network. the workflow (choosing the cycles to be compensated), it is mandatory that the involved parties sign the legal allowance for the cancelation of the corresponding debts. Thus, the framework automatically obtains the set of possible cycles that can be canceled, but the tool operator (normally, a consultant) must decide the specific cycles. Then, just by clicking a button (see Figure 11), the framework automatically creates and processes the transactions in the blockchain. As can be observed in Figure 4, the process starts when a consultant extracts a set of invoices from the enterprise resource planning software as a csv file. In our case, IPI Conocimiento y Flexibilidad uses Odoo. Then, the file is uploaded to an Azure storage account. The framework automatically downloads the file and anonymizes it, as can be seen in Figure 4. Once processed, the operator can upload it (see Figure 5), and it is automatically sent to a backend process that calculates the possible cycles. When they are ready, the operator can proceed with the compensation (after all companies legally agree to it). Lastly, all the transactions are created and processed in Ethereum so that the companies have an immutable record of their transactions in the system. Figure 4: Complete system workflow. Figure 5: Upload file screen. Next, the algorithm (see Algorithm 1) for cycle finding and the smart contract for debt cancelation are presented. In this tool, a smart contract is used to mimic the entities involved in the process of debt cancelation (e.g., companies). Listing 1 depicts that a company has a mapping, where a list of company addresses and their corresponding debts is simulated; that is, this data structure simulates a database for each company where its debtors are stored. Moreover, two functions are defined. The first is used to add invoices to the company mapping, i.e., this function is invoked when reading the input csv file that mimics the debt graph so that the debts are updated accordingly. We omit here the screenshot of the graphical user interface implemented in the tool to invoke this method. The second one is invoked to cancel a specific invoice. Let us remark that when the \"cancel cycle button\" is pressed (see Figure 11), it is run for each row in the screen. In Figure 10, the three transactions automatically created for the cycle of Figure 11 can be observed. On the other hand, the algorithm is based on [PERSON]'s shortest path between two cities (in this case, companies). The main differences are summarized as follows: in this case, the matrices are not symmetric since a directed graph is provided, whereby the debt from company A to B is not normally the same as the debt from company B to A. This slight variation of [PERSON]'s algorithm is not a contribution of the article, but an inevitable step in the overall context of debt cancelation. Moreover, the paths under study are from one company to itself in order to discover cycles involving it. The algorithm has some data structures to store the current minimum debt from one company to another, the path between two companies, and a visited array to avoid visiting a company twice in the same path. Moreover, in the _while_ loop, the algorithm studies all the companies in the problem, whereas _for_ loops are used to calculate the minimum neighbor company and the minimum debt. Let us remark that we check if one of the neighbors of the company under consideration is the company indeed.