## 2 Proposed Model: An Overview  
In the following, the proposed dApp, which implements the logic related to the notarization of the information flow related to a given commission within a CDE, is described. In such applications, a smart contract has to implement the logic to manage file versioning, the logic to store the information flow among the different areas of a CDE and the logic to manage the verification and coordination procedures, thus allowing users to identify who did what and allowing content to pass from one area to the next area of the CDE. (In a CDE, the following four processing states/areas for information are defined:  
* The work-in-progress area, in which the information is being processed and is only available to the person responsible for that content;
* The shared area, in which the information is complete for one or more disciplines and can be shared with other users in addition to the responsible user;
* The published area, in which the information is concluded and nobody needs to modify it;
* The archived area, in which the information is related to a completed process. In general, in a CDE, information can be in different states. In the work-in-progress directory, it is in progress, which is indicated with S0/WIP, and in the shared directory, it can be suitable for coordination S1/SfC, suitable for information S2/SfI, suitable for review S3/SfR or suitable for approval S4/SfA. Finally, in the published directory, it is suitable for manufacture D4/SfM. In addition, an approval status is associated with all information: A0, for which the content has not yet been submitted to the approval procedure; A1, for which the content was successfully approved; A2, for which the content has been approved with comments, and changes to the content are required; and finally, A3 for which the information has not been approved. The application aims to support digital processes for the construction chain--precisely, digital processes for building design--and thus, it aims to notarize the related workflow. So it is related to the design phase, but it can be easily modified, for example, to notarize the information flow related to the construction phase. It is assumed that the administrator of the application is the contractor of the commission and has both the burden of arranging a CDE, as required by the information specifications (the information specifications are the document that allows the winners of a tender to draw up the so-called information management plan. ), and the burden of arranging an on-chain system that allows notarizing the information flows and sending the necessary notifications to the off-chain system. Specifically, the dApp is composed of an on-chain subsystem and an off-chain subsystem. The on-chain subsystem consists of a smart contract that implements the logic for notarizing the information flow among the areas of the CDE. The progress of a design is, hence, notarized through the smart contract, which contains appropriate data structures to store all the data need to verify whether the contractual obligations have been respected and the design can go ahead (see the data structures named <<struct>>model and  
Figure 1: SSI-based model. \"structvversion in Figure 2). The off-chain subsystem consists of a graphic user interface (GUI) that provides user-friendly access to all the functionalities of the on-chain subsystem, the application that computes the hash of the information to store, and the server-side software that allow users to listen for events and communicate with CDEs. Only the first two applications were developed in this work, as mentioned previously. For the design of the decentralized application, the agile blockchain dApp engineering (ABCDE) method, which is an innovative process for the development and testing of blockchain applications [35], was adopted. This method proceeds by steps. First, the goal, the actors and the requirements of the system are identified and defined.