1 Introduction

We are living in a digital world where most people are exposed to digital information. This digital information is driven by the advancement of technologies that are being used daily. Digital information requires electronic devices that have the capabilities of processing and manipulating digital data. These capabilities tend to affect the perception of society as they rely in some way on how we collect, process, analyse and retrieve data more easily and efficiently. Some of these capabilities also play an important role when it comes to new innovations in information and communication technologies (ICTs). The evolution of these technologies has positively benefited society by providing access to information and improving communication channels. The internet is one of the most used platforms that provide such services. Adversely, various risks come with the usage of the internet. These risks include identity theft, cybercrime, fraud, and many other malicious activities [1, 2]. The most used electronic devices that are targeted by these activities are computers and mobile devices. However, these cyber threats do not stop the adoption of ICTs as a tool that aims at enhancing the standard of living [3], because as ICTs evolve, new mechanisms are being implemented to address some of these risks.

The South African organs of state have also adopted the use of these devices as a tool that enables them to perform some of their tasks. Even though some of their tasks are still using manual processes, where they rely heavily on paperwork to accomplish certain tasks. For instance, various South African organs of state collect tendering information through the use of paperwork, which will then be captured and converted into a digital format. Tendering is one of the methods used by these organs to deliver some of their basic services. Tendering can also be regarded as a process that enables the government to procure goods and services from a contractor, which is an organisation within the private sector in most cases. Tendering data is collected whenever there is a call for tender projects. During the tendering process, there might exist some negative activities or irregularities that seek to undermine the norms of a tendering system. The following section explores this problem statement in more detail.

1.1 Problem statement

The current South African tendering system still relies heavily on manual processes, which requires skilled personnel to deal with manual forms and also administer the entire process [4]. The main reason behind using paperwork is to accommodate all the participants including small and new contractors because some of them are unable to share their projects due to various reasons. Some of the reasons are; lack of internet access or personal computers, which lead to the usage of files to store their project information. Project information plays an important role when it comes to awarding a tender to a particular contractor since it reflects the competency area and project history of a particular contractor. All contractors are required to submit such information when they are applying for a tender. Some of this information will go through a verification process, whereby a referee will then be contacted regarding a specific item indicated on the documents. A referee, in this case, might be either a client of that particular contractor or someone who might provide more information or clarity. Some of the tools that are used to share project information are reports, meetings, presentations, site visits, and other intermediaries such as trusted third parties. Through these processes, information might be altered for corrupt purposes at any given stage.

Therefore, the primary problem of this study is that paperwork is used to share project information, which might contribute to the illicit altering of information during the process. This might also affect the fairness, transparency, data integrity, and competitiveness of the tendering system. To provide a solution to this problem, the following questions are also addressed:

  • Research question (RQ) 1: how does the tendering system work in the South African context?

  • RQ 2: is distributed ledger technology (DLT) a possible solution to the identified problem?

  • RQ 3: how does transparency, accountability, and integrity of data in a potential solution work and how will it contribute to digital forensics?

1.2 Research objectives

There are various ways of providing a solution to a problem, however, there are certain goals that need to be set before attempting to solve a particular problem. Therefore, this study addresses the following objectives:

  1. i.

    To investigate how Blockchain as a technology work and how data transparency and accountability are achieved. Blockchain technology (BCT) can be viewed as peer-to-peer decentralised, DLT that is replicated to all nodes participating in a network [1].

  2. ii.

    To develop a Blockchain prototype that allows various organisations to share project information securely and efficiently. The proposed prototype might also be used to improve the current tendering project communication in South Africa.

  3. iii.

    To investigate how digital forensics might be applied to trace the accountability of the records or data.

The remainder of this study is structured as follows: the adopted research method is detailed in Section II. A brief overview of the background details related to the tendering system landscape and the adopted technology description is detailed in Section III. Section IV provides the details of the proposed model used to distribute project information. Section V explores the design of the proposed model. The application of the proposed model is demonstrated in Section VI, whereby a fictional use-case scenario is provided. The details of the ShareTendPro model results are discussed in Section VII. Thereafter, Section VIII depicts the evaluation of the research study by outlining some of the benefits and shortcomings associated with the adoption of the proposed solution. Finally, the last section, which is Section IX, provides the conclusion of this study, which includes a recall of the problem statement and future work.

2 Research methods

This study has adopted the following research methods to achieve the desired objectives, namely: design science research (DSR), literature reviewing, modelling, theoretical use-case, and prototype methodologies. This study adopted the DSR because it is a problem-solving paradigm that seeks to develop or enhance an artifact with an aim of improving the functional performance of the existing tendering system [5]. In order to understand the identified problem, a brief literature study is detailed to explore how the tendering system work in the SALG, which also includes how the adopted technology work in general and some of the related work. After obtaining a holistic idea of how the tendering system work, then this study proposes a model that can be used to share project information securely and efficiently with all the parties that have an interest in it. Hence, the modelling methodology was adopted to achieve this objective. Additionally, this study also uses a theoretical use-case to expand the idea behind the proposed model, which is based on a fictional use-case scenario. Lastly, the prototype methodology was adopted to implement the proposed solution to provide a proof of concept1.

Figure 1 depicts how these various research methods were adopted.

Fig. 1
figure 1

Adopted research methods

Full size image

The following section focuses on the background details that seeks to provide an in-depth on the identified problem, as well as outlining some of the terminologies used within this study.

3 Background

This section is classified into three subsections namely: the current tendering system used by SALG, the adopted technology description, and related work. The current tendering system used by the SALG focuses on the background details related to the tendering system used by the SALG. The adopted technology description focuses on the background details that seek to explore the technology solution adopted by this study to implement the prototype of the proposed solution, while the related work focuses on some of the related work that can be associated with this study.

3.1 The current tendering system used by SALG

The delineation of this study lies in sharing tendering project information amongst organs of state that fall within the SALG because it is the smallest sphere used by the South African Government to deliver some of the basic services to the surrounding communities. Additionally, most of these services or projects have a direct impact on the surrounding communities. The SALG is divided into three categories namely: Metropolitan (Metro), District, and Local Municipalities [6]. District and Local municipalities share their responsibilities when it comes to executing some of the projects, while Metros are regarded as standalone municipalities since they report directly to the Provincial Government.

The Local Municipalities (LMs) are responsible for all the tendering projects that fall under their mandate, even though some of these projects are overseen by their District Municipality (DM) [7]. The execution of these tendering projects requires municipalities to contract suppliers which are capable of executing similar projects. Thereafter, all these municipalities are also required to share some of their project information with the affected parties, such as Communities and Investigators. Communities act as the beneficiaries of some of these projects, while the Investigators are responsible for investigating irregularities that might occur during the execution of some of these projects. Additionally, these municipalities are also required to share their financial reports of these projects with their Auditors because there are responsible for overseeing how these municipalities use public funds. The communication channel used by these municipalities to share project information is structured in a centralised manner whereby municipalities are seen as the centre that distributes project information to all the parties that have an interest in the project information, as shown in Fig. 2. Furthermore, this communication channel relies heavily on paperwork to share project information, even though some of this information is used for decision making-purpose, especially when it comes to awarding a tender to a particular supplier. Therefore, Fig. 2 seeks to summarise this concept by providing a high-level visualisation of how the current project information-sharing work.Footnote 1

Fig. 2
figure 2

Current project information sharing concept

Full size image

This section has outlined an overview of how the tendering system works in the SALG, which includes identifying various stakeholders. Therefore, the following section seeks to explore the adopted technology that might be used to share project information securely and efficiently.

3.2 Adopted technology

This study adopts DLT as the technology solution that might be used to address the identified problem. ASTRI [8] defined DLT as a “technology protocol that can be used for developing a replicated and shared ledger system that stores a wide range of assets and transactions in a distributed manner”. This implies that a distributed ledger (DL) is regarded as a shared ledger system since its records of transactions are maintained across several locations or among multiple nodes, regardless of their geographical location [9]. Furthermore, it implies that all the nodes that are found within that network have the same copy of the ledger. Hence, a DL does not consist of a central repository or a single point of failure like a centralised ledger system. However, every time when a specific node in a DL has made some valid changes on the ledger, those changes are propagated automatically and shared with other nodes that form part of the network. Additionally, this mechanism of sharing information ensures that there is no single point of failure and it is also aimed at maintaining data integrity across all the nodes within that network.

Note that the DLT has become more prevalent in 2008, after the circulation of a white paper titled “Bitcoin: a peer-to-peer electronic cash system” authored by Satoshi Nakamoto [10]. The white paper proposed a solution for the financial industry that addresses the issue of double-spending and eliminating the norm of using intermediaries. However, the ideology of the proposed solution existed theoretically [11, 12], until 2009 when the first DLT implementation (Bitcoin system) emerged [10]. The underlying technology used to implement the Bitcoin system was termed “Blockchain” technology. Blockchain refers to the ways in which the proposed system stores and organises its information. The word “Blockchain” is a combination of two words namely “block” and “chain”. This is due to the fact that “Blockchain” technology use blocks to store their information, and these blocks are linked together to form a chain-like data structure, hence “Blockchain”. As time progresses, similar ways of organising and storing information emerged which led to the term DLTs as a broad term used to categorise such technologies [9].

Various DLTs support or use the Blockchain data structure to organise and share their information. However, all the frameworks that adopt the use of Blockchain data structure can be classified into three categories namely [13]:

  • Permissionless (public) Blockchain allows any member of the public to join the network and participate in it.

  • Public-permissioned Blockchain allows any member of the public to verify the records or transactions stored in the network.

  • Private-permissioned (private) Blockchain allows specific members to participate in the network, hence it is designed to support private network configurations.

There are various Blockchain frameworks that might be adopted to implement a distributed solution that seeks to address the identified problem. Therefore, the following subsections explore the most popular Blockchain frameworks which are Bitcoin, Ripple, Ethereum, and Hyperledger-fabric (HLF) [8].

  1. 1.

    The Bitcoin framework is the first DLT implementation that was specifically designed to support the native cryptocurrency known as Bitcoin [13]. Additionally, this framework is regarded as a public Blockchain that uses a mining consensus algorithm called proof-of-work [14]. Furthermore, it relies on miners to add new transactions to the network.

  2. 2.

    The Ripple framework is specially designed for digital currency exchange, remittance, and the real-time gross settlement system (RTGS) [15]. The RTGS is an open-source, distributed technology that focuses on payment systems, particularly in banking and finance [16]. It supports a native cryptocurrency known as Ripple and it also uses a custom-made consensus algorithm called the ripple protocol consensus algorithm [17, 18].

  3. 3.

    The Ethereum framework is specially designed to support the native cryptocurrency known as Ether [19]. It also supports smart-contract (SC) [20], which is the mechanism used by some of the DLTs to govern the network transactions, without relying on a trusted party or authority to mitigate the transaction processes. However, the SC used by Ethereum is written in high-level languages (e.g., solidity [21]) and compiled by bytecode which requires an Ethereum Virtual Machine (EVM) to execute it [22, 23]. Furthermore, the Ethereum framework can be regarded as both a private and a public Blockchain that uses proof-of-work and proof-of-stake consensus algorithms [24].

  4. 4.

    The Hyperledger-Fabric framework is an open-source platform hosted by Linux Foundation, created to advance cross-industry Blockchain solutions [25]. It does not support native cryptocurrency since it was designed to build a new generation of transactional applications that aimed at establishing trust, accountability, and transparency [25]. Additionally, it supports private Blockchain and uses a crash fault-tolerance consensus algorithm [26]. HLF also supports the use of SC (also known as chaincode), which can be viewed as a mechanism that seeks to manage access and modification of the data within the network.

  5. 5.

    Selecting a particular Blockchain framework The comparison of these Blockchain frameworks favours HLF because all the requirements are met. Additionally, all the participating members of HLF are also known (since it is a private Blockchain) and such members are, therefore, accountable for their actions. Hence, it can be assumed that all the participants can be trusted with the assigned tasks. Note that the participating members, in this case, refers to the identified stakeholder in the previous section, which are Auditors, Investigators, Communities, Suppliers, District, and Local Municipalities.

Table 1 compares the above Blockchain frameworks to select a suitable framework that might be adopted by this study. The comparison is based on whether the identified requirements are favourable or not. However, some of these requirements are based on the features or benefits offered by these frameworks. The comparison of these Blockchain frameworks favours HLF because all the requirements are met. Additionally, all the participating members of HLF are also known (since it is a private Blockchain) and such members are, therefore, accountable for their actions. Hence, it can be assumed that all the participants can be trusted with the assigned tasks. Note that the participating members, in this case, refers to the identified stakeholder in the previous section, which are Auditors, Investigators, Communities, Suppliers, District, and Local Municipalities.

Table 1 Comparison of blockchain frameworks
Full size table

This section has highlighted the background details of the adopted technology, which included the selection of HLF as a favourable Blockchain framework. Therefore, the following section focuses on the related work that can be associated with this study.

3.3 Related work

There are several related works that can be associated with this study. Some of these related works tend to focus more on the procurement processes, which includes processes such as applying for a tender, submitting tender documents, tender bidding, and awarding of tenders, including managing tender contracts or projects. Various studies classify the following processes: applying for a tender, submitting tender documents, tender bidding, and awarding of tenders as e-procurement because their information is widely used during the procurement proceedings. The management of the tendering contract or projects tends to come after the e-procurement processes to combat issues that emanate from duplication of contracts or tendering projects.

For instance, the study done by [33] proposed an e-procurement system that can be used to create, publish, bid, and award tendering projects. The proposed system is based on the Ethereum platform, which relies on cryptocurrency or mining algorithms to add new transactions to the main network. The study by [34] also adopted the Ethereum platform to expand the tender bidding concept by including processes such as sharing and verifying tendering information. Additionally, the study done by [35] also adopted a similar approach to expand the tender bidding concept by including processes such as supplier habilitation and delivery verification. However, the model presented by [36] has adopted a different approach or technology solution since it uses the Hyperledger-composer (HLC) tool to implement a prototype that can be used to share data associated with the bidding and awarding of tender projects. Note that HLC makes use of HLF as the underlying Blockchain framework. Additionally, HLC is also regarded as a deprecated tool because none of its maintainers are actively providing support or developing new features for it [37]. The solution presented by [38] also adopted HLF to expand the tender bidding concept by including a mechanism that can be used to monitor the procurement proceedings.

The following studies [39, 40] can be associated with managing tender contracts because they contain some of the elements that seek to eliminate issues that emanate from duplication of contracts or projects, especially in the public sector. Some of the issues that are addressed by these studies relate to data integrity, transparency, and accountability among various individuals that are involved in finalising the procurement contracts. The Mexican Government is one of the countries that has implemented a tool that seeks to manage its procurement contracts [41], especially managing contracts of the projects that are executed using tendering systems.

The framework presented by [42] focused on how the Blockchain can be used to facilitate data integrity within the document management for construction-related projects. Note that the proposed framework is also based on the Ethereum platform. Additionally, the work presented by [43] explores a framework that can be used to secure tendering records that are highly susceptible to tampering. The study conducted by [44] expanded this ideology by including a concept that seeks to manage construction projects executed by multiple constructors to provide transparency and accountability within the project.

The study by [45] proposed a framework that might be adopted by the South African Government to reduce corruption and other issues that emanates from managing procurement contracts. However, this study took a slightly different approach since it proposes a concept that can be used to monitor the tendering project, including sharing project information securely and efficiently among various parties that have an interest in the tendering project.

Table 2 summarises the details of the related work by providing a comparative survey that seeks to outline some of the features or issues that were not addressed by these related works. As indicated in Table 2, most of the related work make use of the Ethereum platform as their technology solution, while this study adopted the use of HLF. It should be noted that the features in the last four columns of Table 2 resemble positive features. For example, the column on “Does not support tender bidding” should be conceived as positive because this study focuses on monitoring the execution of tendering projects rather than processes that fall within e-procurement. The notion of monitoring tendering projects aimed at ensuring that it is executed successfully and all the parties that are involved during the execution phase account for their action.

Table 2 A comparative survey of the related work
Full size table

4 A forensic Blockchain model for distributing tendering project information

Fig. 3 depicts how various components, i.e., actors, gateway, and Blockchain network of the proposed model interact with each other. The following items briefly explore the logic behind these components as used by the ShareTendPro model [46]:

Fig. 3
figure 3

Sharetendpro model [46]

Full size image
  1. 1.

    Actors consist of various organisations that were identified in Fig. 2.

  2. 2.

    The gateway allows actors to interact with the Blockchain network by managing the identities of various resources (i.e., actors and nodes). HLF achieves this by using the following mechanisms: REST-API, access control list, and secure communication channel [46].

  3. 3.

    The Blockchain network stores and distributes project information among all the nodes used by various actors that form part of the network.

5 ShareTendPro model design

This section is classified into two subsections namely: the functional requirements, and the ShareTendPro design. The functional requirements summarises the functions of the proposed model, while the ShareTendPro design focuses on the information flow within the proposed model.

5.1 Functional requirements

Figure 4 depicts an algorithm that seeks to outline the features or functions of the proposed solution. The process starts when the network is initialised and resources (which are organisations and their members) are added. Thereafter, all the participants that form part of the network would now have access to perform various functions such as: submit project reports, update project data, and access the entire history of a particular project. The delete tender function is only accessible by LM/DM that has created that project. This section has outlined the functional requirements of the proposed model. The following section explores how various components within the ShareTendPro model interact with the project information.

Fig. 4
figure 4

Functional requirements algorithm

Full size image

5.2 ShareTendPro design

This section focuses on how the proposed solution work in general, which is the theoretical concept that seeks to explore the distributed nature or implementation of the proposed solution. Additionally, the information flow discussed in this section explores the interaction between some of the embedded objects and the surrounding environment within the proposed solution. Note that HLF consists of various nodes that seek to ensure that the network achieves the desired objective of securely and efficiently distributing project information to all the nodes within the network. These nodes can be classified into three categories: clients, peers, and orderers [49].

Fig. 5 depicts a theoretical representation of the information flow within the proposed solution. For instance, the proposed solution will enable actors such as Suppliers and Communities to utilise the municipality’s resources whenever they want to share their project information related to a particular tendering project. Fig. 5 also represents how the identified nodes interact with each other to accomplish certain objectives within the network. However, all these nodes are represented using Docker containers (virtual nodes) within this study as supported by the HLF framework. A Docker container is a component that can be used to package a code or an application with all its dependencies (i.e., libraries) and deployed as one package [50]. Note that Fig. 5 consists of four organisations namely: LM, DM, Auditor’s Firm (AF), and Investigator’s Firm (IF). Each of these organisations contains a client node and n number of peer nodes (which are labelled from nodes 1-n). Additionally, Fig. 5 represents the four ordering nodes (represented by nodes 1–4) used by the proposed solution to add or append new transactions to the network. The numbering from 1–6 in Fig. 5, represents the order in which various nodes interact with each other to achieve certain objectives within the network [51].

Fig. 5
figure 5

Sharetendpro model transaction flow

Full size image

All these processes seek to ensure that the ledger within the peer nodes is kept up-to-date across the network.

6 Fictional use case scenario

This section explores a fictional use-case scenario used to expand the idea behind the proposed solution, which includes identifying a problem and providing a counter-solution to it using the ShareTendPro model. Therefore, the following items present the process that takes place within the scenario and these processes are visualised later in Fig. 6.

  • 1–The LM opens tendering project X for bidding.

  • 2–Various suppliers apply for tender project X by submitting tender documents to the LM.

  • 3–The tendering committee assigned by the LM assesses all the suppliers who applied for project X and submits the results of the assessment to the LM.

  • 4–The LM awards project X to Supplier S based on the outcomes presented by the tendering committee.

  • 5–The LM assigns Peter to manage project X. Thereafter, Peter uses computer LM_N0 (which stands for LM node 0) to issue a progress report for project X as part of his responsibilities which seeks to portray the following progress “so far, 20% of project X was completed within four months”.

  • 6–Peter shared this report with John from the AF who was tasked to audit the financial expenditure of tendering project X. Hence, the report acts as proof of payments associated with the work that was completed by Supplier S.

  • 7–Peter also shared this report with David from the IF who was tasked to investigate allegations of corruption in tendering project X. The report acts as proof of work completed by Supplier S.

  • 8–Later on, the DM opens tender project Y for bidding. Assume that project Y is similar to project X.

  • 9–Assume that Supplier S decided to collude with Peter when it comes to falsifying the report of project X to portray the following progress “50% of project X was completed within four months”.

  • 10–Various suppliers apply for project Y, including Supplier S. Assume that Supplier S has included a falsified progress report of project X when applying or bidding for project Y and included Peter as a referee who can provide more clarifications regarding project X.

  • 11–The DM assigns Martha from the tendering committee of project Y a task to request a progress report of project X from Peter as part of trying to confirm whether Supplier S managed to complete 50% of the project within four months or not. Note that Martha used computer DM_N0 (which stands for DM node 0) to send an electronic mail (email) to Peter when requesting the progress report of project X.

  • 12–Peter submitted a falsified progress report of project X to Martha (DM_N0) at the DM.

  • 13–The tendering committee of the DM assesses all the suppliers who applied for project Y and submits the results of the assessment to the DM.

  • 14–The DM awards tendering project Y to Supplier S based on the outcome of the assessment which was motivated by the information provided by the supplier and confirmed by Peter who works at the LM.

Fig. 6
figure 6

Scenario problem

Full size image

The main objective of this scenario was to depict a loophole that might be used to tamper with the project information in such a way that it can be used to influence the decision of other projects offered by a different municipality. For instance, in the scenario, a falsified report of project X was used to influence the decision when it comes to awarding project Y offered by the DM. Fig. 6 seeks to visualise this scenario as various actors in different organisations interact with either a falsified or a legit report of project X. Assume that the communication mechanism used to share the report of project X was an email. Hence, Fig. 6 depicted the computers used by various actors in different organisations as they interact with an electronic report of project X.

To support the current tendering system, this study proposed a distributed model, instead of conventional email, that seeks to connect all the computers of various organisations that have an interest in the tendering project. For instance, the computers that have an interest in project X are LM_N0 (i.e., LM node 0), DM_N0, IF_N0, and AF_N0 as shown in Fig. 6. Therefore, the proposed model would be used as a tool that replaces email when it comes to sharing project information with all the people that have an interest in the tendering project. Additionally, the establishment of the Blockchain network also allows these computers to share project information securely while preserving the integrity of the information. The establishment of the ShareTendPro network as a solution is also aimed at enforcing trust and transparency among various organisations that have an interest in the tendering project.

Fig. 7 depicts how this study addresses the identified problem within the scenario by introducing the ShareTendPro network as a solution. A more detailed discussion of the ShareTendPro solution as shown in Fig. 7 follows next in an attempt to solve the problem shown in Fig. 6.

Fig. 7
figure 7

Sharetendpro solution

Full size image

The process taking place within the ShareTendPro solution (which is Fig. 7) is as follows:

  • 1–4: These steps are similar to steps 1–4 as discussed in the scenario of Fig. 6.

  • 5–Represents the establishment of the ShareTendPro network that would be used to share project information securely while preserving the integrity of the information.

  • 6–Depicts Peter using computer LM_N0 to create a progress report of project X. Note that computer LM_N0 is one of the computers of the LM that has joined the ShareTendPro network. Hence, the report created by Peter would be stored within the blockchain of the ShareTendPro network.

  • 7–Depicts various computers accessing the report of project X that was created using computer LM_N0. Note that this step is automatically activated when computer LM_N0 submits the report of project X to the Blockchain in the ShareTendPro network, whereby the ShareTendPro network distributes it to all the computers that have joined the communication channel, due to the inner workings of the HLF framework.

  • 8–Depicts the DM opening project Y for bidding. This step is similar to step 8 of Fig. 6.

  • 9–Depicts Supplier S and Peter colluding by falsifying the report of project X. This step is similar to step 9 of Fig. 6. Later it will become clear how this falsification is detected.

  • 10– Depicts various suppliers applying for tendering project Y offered by the DM, including Supplier S. This step is similar to step 10 of Fig. 6. Assume that Supplier S has included the falsified report on the tendering documents when bidding for project Y.

  • 11–Represents Martha who was tasked by the tendering committee of project Y to confirm the progress report submitted by Supplier S within the ShareTendPro network. Note that Martha at node DM_N0 did not request the report of project X as compared to the scenario depicted in step 11 of Fig. 6 because the report is now available in the ShareTendPro network as she can access it directly.

  • 12–Depicts the tendering committee of the DM assessing all the suppliers that have applied for project Y and submitting the results of the assessment to the DM. However, the tendering committee realised that the report (i.e. document) of project X submitted by Supplier S contradicts the actual details (i.e. report) stored within the Blockchain of the ShareTendPro network. Due to this discrepancy, Supplier S is removed from the bidding process of project Y with consequences, and another supplier will need to be appointed.

  • 13–Depicts the DM awarding tender project Y to supplier Z. Note that this was achieved after penalising Supplier S since the information or report provided by the supplier does not correspond with the actual report stored within the ShareTendPro network.

  • 14–Represents Martha who is part of the tendering committee of project Y alerting the LM and IF about the falsified report of project X for further investigations. The LM will conduct an internal investigation to discipline Peter, while the IF will conduct corruption-related activities or investigations between Peter and Supplier S which include acts of bribery. This, however, is out of the scope of this research and will not be shown further.

This section has outlined the theoretical use-case scenario and its solution with an aim of visualising how the proposed model handles such issues. Therefore, the following section focuses on the results of the ShareTendPro prototype.

6.1 ShareTendPro prototype results

The algorithm depicted in Fig. 8 describes the basic process used to generate the results of the proposed solution. Note that there are various results that were generated by the ShareTendPro prototype during the testing phase. Some of these results were associated with the Blockchain network configurations and the operational network testing. However, this section only focuses on the results associated with operational testing of the proposed solution because it seeks to either create, modify, query, and delete project information within the network. Hence, the following subsections explore the results generated by these operations starting from “creating tender”, “querying tender”, “updating tender”, and “deleting tender”, as well as “querying tender history”.

Fig. 8
figure 8

Sharetendpro algorithm

Full size image

6.2 Creating tender

The results generated by the “creating tender” process (which is step 6 of Fig. 7) depict the creation of a tendering project report by computer LM_N0 as shown in Fig. 9. Therefore, lines 202–212 of Fig. 9 depict a function called chaincodeInvokeByAddingProject() that contains a command line used by peer0 (i.e. corresponding to LM_N0) of the LM to create the tendering project information of project X. Line 203 of Fig. 9 calls a function called setGlobalsForPeer0LocalMunicipality() that enables the Blockchain network to initialise peer0 (LM_N0) in the LM. Lines 204–211 represent the command line that creates tendering project information within the Blockchain network. Line 210 represents a flag that seeks to execute a function called createTender() contained within the chaincode with the following five arguments namely:

$${\text{args}}\left[ 0 \right]\,\,\, = \,\,Tender1000$$
(1)
$${\text{args}}\left[ {1} \right] \, = \, Local \, Municipality$$
(2)
$${\text{args}}\left[ {2} \right] \, = \, Project \, X$$
(3)
$${\text{args}}\left[ {3} \right] \, = \, 20\% \, of \, the \, project \, has \, been \, completed \, within \, four \, months$$
(4)
$${\text{args}}\left[ {4} \right] \, = \, Supplier \, S$$
(5)
Fig. 9
figure 9

Create tender

Full size image

Note that this project report is identified using the key (1). Label R of Fig. 9 represents the results displayed within the command prompt after executing the chaincodeInvokeByAddingProject() function, as presented by line 213. Additionally, the command line returns a successful status of 200 which implies that the information of the tendering project X was successfully created within the Blockchain network, as shown in label R.

After the project information has been added to the Blockchain network, that information would automatically be available for other nodes to access it. The following section focuses on the results generated by the “query tender” process. Note that other nodes use the key (1) to access the project report created in Fig. 9.

6.3 Querying tender

The results generated by the “querying tender” process (which is step 7 of Fig. 7) depict an example of how nodes can access project X information using the key (1), as shown in Fig. 10. Therefore, lines 215–232 of Fig. 10 depict the details of a function called chaincodeQueryByProject(), which contains the command lines used by various nodes to access the report of tendering project X. For instance, lines 217 and 218 represent the command used by peer0 (i.e. AF_N0) of the AF to access project X information (using (1)). Additionally, line 2017 seeks to call a function called setGlobalsForPeer0AuditorFirm() that enables the Blockchain network to initialise AF_N0, while line 218 depicts the command line used by AF_N0 to access project X information using the key (1). Note that the command line makes use of a function called queryTender() contained within the chaincode to interact with the Blockchain network, as shown in Fig. 10. The results of this command line are displayed within the command prompt represented by label R. However, the same notion applied to the command line represented in line 218 can also be used to other command lines used by other nodes. Label R of Fig. 10 represents the results generated after executing the chaincodeQueryByProject() function using line 233. Hence, the results contained within this process also portray the distributed nature of the ShareTendPro model because other nodes automatically have access to the report of tendering project X compared to the scenario depicted in Fig. 6.

Fig. 10
figure 10

Query tender

Full size image

After the project information of tendering project X is distributed to other nodes, we can then proceed with a process that seeks to update some of the details contained within the project report. The following section focuses on the results generated by a process that seeks to update the details of the supplier and project report. Note that the update process might still be used for illegal altering of project information by some of these authorised nodes. However, the project history that would be discussed later can be used as a mechanism that seeks to explore what has transpired within that project since the information stored within the Blockchain data of the ledger is immutable by default as indicated earlier on.

6.4 Updating tender

The results generated by the “updating tender” process depict a process that seeks to modify some of the information of a particular tendering project (i.e., project X in this case). However, this section explores the two possible updating processes implemented within the ShareTendPro network which are “update supplier details” and “update tender report details”. The “update supplier details” process focuses on the results generated during a process that seeks to update the details of the supplier (e.g., contact details or to assign a new supplier altogether). The “update tender report details” process focuses on the results generated by a process that seeks to update the report of the tendering project (e.g., doing editorial updates).

  1. 1.

    Update supplier details

Fig. 11 depicts the results generated by a process that seeks to update supplier information on tendering project X. For instance, lines 235–244 of Fig. 11 depict a function called InvokeByChangingSupplier(), which is a function used by peer0 of the LM to update the details of a supplier from “Supplier S” to “Supplier Z”. As indicated in lines 237–243, the command makes use of a function called changeTenderSupplier(), as seen in line 243, contained within the chaincode to interact with the Blockchain network. The changeTenderSupplier() function requires two arguments. The first argument represents a key (1) used to identify a tendering project, while the second argument is used to assign the updated details of the supplier which is “Supplier Z” in this case. Therefore, the results displayed (as presented by label R) are generated after executing the InvokeByChangingSupplier() function using line 245. The status of the results reflected within label R is 200, which implies that the supplier details were updated successfully.

Fig. 11
figure 11

Update tender supplier

Full size image

After updating the details of the supplier, the second process that seeks to update the details of a project report is considered. Hence, the following section explores the results generated by a process that seeks to update the project report of a tendering project.

  1. 2.

    Update tender report details

Note that the results generated using the “update tender report details” process are similar to the results generated by the “update supplier details” process (as depicted in Fig. 11). Hence, the in-depth details of the results generated by the “update tender report details” process are not explored in detail to avoid the repetition of some of the concepts. Furthermore, note that the “update tender report details” process seeks to modify the project report to reflect the new report that portrays the following progress “50% of the project was completed within four months”.

The results depicted in Fig. 12, under transaction ID updateTenderSupplier and updateTenderReport, seek to verify that the project information was updated successfully since it has changed:

  • From: “20% of the project was completed within four months”, as shown in Fig. 10.

  • To: “50% of the project was completed within four months”, as shown in Fig. 12.

  • From: “Supplier S”, as presented in Fig. 10.

  • To: “Supplier Z” as shown in Fig. 12.

Fig. 12
figure 12

Query tender history

Full size image

After updating the details of a tendering project, one might decide to delete the project information stored within the ShareTendPro network. Assume that this process was activated by a withdrawal of the tendering project by a supplier that results in the termination of a contract between “Supplier Z” and the LM. Therefore, the following section explores the results generated by a process that seeks to delete project information stored within the ShareTendPro network. As indicated in the previous section, the evidence of the existence of tendering project X will not be completely lost because this information is still stored in the Blockchain data of the ledger and it is immutable by default (which implies that it cannot be changed or permanently deleted for historic investigation purposes).

  • 3Deleting tender

The concept used to implement the “deleting tender” process within the ShareTendPro network is similar to the concept used to implement the update tender supplier process (depicted in Fig. 11). Hence, the details of the delete tender process are not explored in detail to avoid the repetition of some of the concepts. However, the main difference is that the delete tender process calls a deleteTender() function contained within the chaincode instead of calling updateTenderSupplier() function. The deleteTender() function only takes one argument which is the key (1).

After performing all the processes that seek to either create, update or delete the project information of a particular tendering project, then the evidence related to such processes is stored within the Blockchain data. As indicated earlier on, the information stored within the Blockchain data is immutable since it seeks to preserve the evidence of what transpired within that specific tendering project. Additionally, the evidence contained within the Blockchain data can also be used as forensic data since it portrays the entire history of a particular tendering project. Therefore, the following section focuses on the results generated by a process that seeks to access a project history of tendering project X.

6.5 Querying tender history

The results generated by the “querying tender history” process depict how various nodes can access the entire project history of a particular tendering project, which is project X in this case. Therefore, lines 296–302 of Fig. 12 depict a function called chaincodeQueryProjectHistory(), which contains the details used by a command line that seeks to access the project history of a tendering project associated with the key (1). As indicated in lines 299 and 300, the command makes use of a function called getHistoryForTender(), as seen in line 300, contained within the chaincode to interact with the Blockchain network. The results displayed (as presented by label R) are generated after executing the chaincodeQueryProjectHistory() function using line 303. Note that the project information displayed within label R contains various transaction IDs and each of these transaction IDs represents a specific process that was executed using the key (1). Furthermore, note that these processes have been executed already, as follows. The processes that were executed using key (1) are creating a tender project (as shown in Fig. 9), updating the tender supplier (as shown in Fig. 11), updating the tender report, and deleting a tender project. All these processes are identified using a unique transaction ID (represented by TxID in label R). Again, note that the status of a tag “IsDelete” is only true when it comes to the Transaction ID that represents a process that seeks to delete the information of a tendering project, else it is false.

7 Evaluation of the research study

The details contained within this section are classified into two subsections namely: the “benefits of this research study” and the “shortcoming of this research study”. Therefore, the following items provide the details of these two subsections.

7.1 The benefits of this research study

  1. 1.

    Distributed nature of the proposed solution–it is derived from the use of DL to share project information with all the actors that have an interest in it. This ensures that the participants would not be able to collude with each other over project data since they would have access to the same data.

  2. 2.

    Enhanced information security–refers to the mechanisms used to increase the difficulty for unauthorised parties (i.e., hackers) to either access or tamper with project information within the ShareTendPro network. The mechanisms used by the proposed solution to secure project data are: distributing project data in multiple locations, the use of cryptography for a secure communication channel, and the use of timestamp and immutable transactions for data integrity.

  3. 3.

    Greater transparency over project information–is derived from the use of DL because it ensures that the business process used to either create, modify, or delete project information within the ShareTendPro network is transparent. Hence, the authorised actors will not have to worry about accessing project data that might be processed unnoticed. This mechanism disables the rogue parties the ability to collude over project information.

  4. 4.

    Automated transactions–refer to the use of chaincode components to reduce human interactions within the ShareTendPro network while increasing the efficiency and speed at which it processes transactions. As indicated in the previous section, all the transactions submitted by various nodes are sent to a specific method contained within the chaincode. Thereafter, the processes that follow next are triggered automatically since the chaincode uses the submitted transactions to perform certain tasks within the network.

  5. 5.

    Time efficiency–refers to the time it takes for a participant to have full access to the entire project history of a specific tendering project of their interest using the ShareTendPro network. Note that the authorised parties within the network have full access to the data collected by the Blockchain component of the ledger since it contains records of the transactions that seek to create, update, or delete project information of a specific tendering project. Therefore, this data is readily available to all the authorised parties who have an interest in knowing what transpired within that tendering project. For instance, having access to such data by the AF enables them to audit the tendering project in real-time, which reduces the time taken to look at the financial documents that portray the expenditure incurred during the execution of the tendering project at the end of a fiscal year or closing period of the desired project. Furthermore, having access to such data by the IF enables them to conduct a real-time investigation without going to the municipality to collect such information in person. Additionally, having access to such data by both the AF and IF enables them to quickly resolve issues related to irregular expenditure or corruption allegations while promoting accountability on other hand.

  6. 6.

    Credible evidence–refers to information that can be presented to the court of law as evidence of what has transpired within a specific tendering project. This evidence is collected by an investigator from the ShareTendPro network by accessing the project history of a particular tendering project because the data stored within the Blockchain component of the ledger is immutable, timestamped, and cryptographically encrypted. All these mechanisms of having data that is immutable, time-stamped, and cryptographically encrypted seek to preserve the integrity of the evidence that portrays what transpired within that project.

  7. 7.

    Promotes real-time auditing and investigations–refers to information that can be accessed in real-time that allows both auditors or investigators to either audit or investigate a tendering project in real-time. The benefit of having real-time auditing or investigation is derived from the distributed nature of the ShareTendPro network because it enables both auditors and investigators to access project information in real time. Having access to real-time data allows the auditors or investigators to complete their auditing or investigation process quickly, which also contributes towards having greater accountability over the tendering project, while aiming at saving the municipality’s funds that might be spent through irregular expenditure or corruption activities.

  8. 8.

    Improve collaboration–refers to the use of the ShareTendPro network to share project information among various actors working on the same tendering project. For instance, the improved collaboration can benefit both the LM and DM when it comes to executing a joint project because the use of the ShareTendPro network will eliminate issues related to collusion over project information. The responsibility of the LM within the joint project might be executing the tendering project, while the responsibility of the DM might be to oversee the project executed by the LM. Hence, the use of a ShareTendPro network by these municipalities will ensure that accountability is achieved because the process of reporting that tendering project would be more transparent compared to the conventional method of sharing project information in a joint project.

7.2 The shortcoming of this research study:

  1. 1.

    Lack of political will–this can only be regarded as a shortcoming because most of these higher-ranking positions or members of the organisations are easily influenced by the political space. Hence, the political will might be reluctant to adopt a solution that seeks to manage issues associated with monitoring the tendering projects since some of them might be linked to these projects.

  2. 2.

    Training or workshop-related issues–this study foresees this as a shortcoming because some of the participants might be reluctant to undergo such training, especially when they are already using several systems or applications.

8 Conclusion and future work

This section provides a summary of this research study while aiming to shed light on the contribution made by this research. However, the details contained within this section are classified into three subsections: a “recap of the problem statement”, “future work”, and “concluding remarks.

8.1 Recap of the problem statement

The primary problem this study sought to address is the use of paperwork to share project information among various organisations since it might contribute to illicit altering of project information during the process. This might also affect the fairness, transparency, data integrity, and competitiveness of the tendering system used by the SALG. To address this problem, this study outlined the following research questions:

  • RQ 1: how does the tendering system work in the South African context? This question was answered in the following way. It was addressed by Section III because it explored the background details on how the current tendering system used by SALG work.

  • RQ 2: is DLT a possible solution to the identified problem? This question was answered in the following way. It was addressed by implementing a Blockchain prototype that might be used to securely share project information among participants that have an interest in it. The ShareTendPro prototype was designed in Section V and the test results of it were discussed in Section VII.

  • RQ 3: how does transparency, accountability, and integrity of data or information in a potential solution work, and how will it contribute to digital forensics? This question was answered in the following way. The transparency, accountability, and data integrity part of this research question was addressed in Sections IV & V. The other information security mechanisms were also highlighted in other sections such as Sections VII & VIII, including the issue that is related to how does the proposed solution contribute to the digital forensic investigation.

8.2 Future work

The implementation of the ShareTendPro solution shows the potential of sharing tendering project information within the SALG. One of the main benefits is that the proposed solution seeks to enforce collaboration among various organisations that have an interest in tendering project information by providing real-time data. The access to real-time data also assists other organisations such as AF and IF to audit or investigate a specific tendering system in real-time, which also promotes accountability within that tendering project.

9 Concluding remarks

The ShareTendPro network demonstrates how BCT as a tool can be used to securely share project information with all parties that have an interest in the tendering project. The ShareTendPro network secures its project information using various information security mechanisms such as DL, cryptographic encryptions, timestamps, and immutable data or transactions. Note that the ShareTendPro network satisfies the four features or issues highlighted in Table 2 because it seeks to monitor the execution of the tendering projects (i.e., project X), rather than focusing on the processes that fall within the e-procurement (i.e., tender bidding process). Additionally, the ShareTendPro network supports a private Blockchain network configuration that does not rely on either gas or mining algorithms to add new transactions to the network.

The SALG uses a tendering system to promote public and private partnerships, therefore, the ShareTendPro network becomes an essential platform for securely sharing project information without colluding. Additionally, the ShareTendPro network will provide greater transparency and accountability over project information, while enforcing trust on the other hand because no one will have to worry about the illegal altering of project information that might be processed unnoticed. This ensures that the ShareTendPro network stores credible digital evidence of the tendering project that can be used to depict the entire project history of a particular project of interest. Furthermore, the ShareTendPro network ensures that all the participants have instant access to real-time data stored within the Blockchain network without having to worry about issues that emanate from requesting that data directly from a specific organisation because some of them might be reluctant to share it.

The ShareTendPro network, therefore, would provide a revolutionary step towards curbing corruption in countries, like South Africa, where corruption currently enjoys high tide. Additionally, it is hoped that other countries that face similar issues might also adopt this scheme since it can be configured to accommodate various tendering systems used by different countries.