Developing a framework for designing humanitarian blockchain projects

Blockchain technology promises to improve the efﬁciency, transparency, and accountability of human-itarian operations. Yet at the same time, especially the humanitarian context with its characteristic volatility poses unique challenges to any technology. Most prominent are the humanitarian principles that are fundamental to humanitarian operations. These ethical principles are set to protect the most vulnerable populations. Designing blockchain projects in the humanitarian context therefore requires a systematic framework that helps humanitarians make critical choices. While some design instructions can be found for commercial applications, the humanitarian context requires different design principles and guidelines. To address the lack of a design framework for humanitarian blockchain projects, in this paper, we design and validate guidelines for humanitarian blockchain-projects. We use data from two humanitarian blockchain pilots in Jordan and Kenya to design our framework. Thereafter, we benchmark its applicability and relevance against another pilot in Vanuatu. Our framework highlights the need to consider infrastructure, end-users, ethics, stakeholders, and privacy in contexts, scalability and in/out mechanisms in technology, and knowledge/skills and intellectual property in organisation-related design requirements. © 2021 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY license (http://creativecommons.org/


Introduction
Each year, conflicts and natural disasters leave millions of people in need of humanitarian assistance. Given the increasing number of people in need and the rise in funding gaps (Global Humanitarian Assistance, 2020), humanitarian organisations (HOs) have started to explore innovative solutions to improve aid efficiency (Altay and Kovács, 2018). One of them is the use of cash-based assistance (CBA) to complement and sometimes replace time-and cost-consuming distribution of relief items (Heaslip et al., 2018). In CBA, technology can provide substantial benefits through facilitating cash transfer via internet banking, the use of electronic vouchers, contactless payment, and mobile money.
The blockchain is a prime example of the need for introducing innovative information and communication technologies (ICT) in humanitarian operations (Walton et al., 2016). Improved informa-end fees by 98% for the WFP's CBA pilot). In a nutshell, blockchain is a type of Distributed Ledger Technology where transactions are recorded with an immutable cryptographic signature called a hash. The transactions are then grouped in blocks, and each new block includes a hash of the previous one, chaining them together. Due to the cryptography and immutability features of the blockchain, its application in humanitarian operations has been identified as a future research direction in recent reviews (Wang et al., 2019;Wamba et al., 2020). In the literature, the use of blockchain in humanitarian operations has been mainly discussed with respect to swift trust (Dubey et al., 2020), sharing logistics resources (L'Hermitte and Nair, 2020), ID management (Zwitter and Boisse-Despiaux, 2018), and partnership . To the best of our knowledge, there is only one study supporting the decision of whether to use the blockchain technology in humanitarian projects (HumanityX, 2018). All studies emphasise the potential to improve the efficiency, coordination and transparency of humanitarian operations. However, how a humanitarian blockchain project should be designed systematically to reap the theoretically claimed in practice remains open.
There are several studies in the business literature that discuss the design of blockchain projects with respect to technological and organisational requirements (cf. Section 4.1). However, these contributions do not account for the humanitarian principles of humanity, neutrality, impartiality, independence (cf. Section 2.1). Adopting frameworks from business to design humanitarian blockchain projects could result in violating these principles, putting at risk the vulnerable communities typical for humanitarian contexts. Further, the dynamics and volatility typical for humanitarian operations  are not accounted for. This research gap is echoed by practice, where recent reports confirm a lack of guidelines to support the design of blockchain projects for humanitarian purposes (e.g., Coppi and Fast (2019)). As Cardia et al. (2017) note, most of the debate on humanitarian blockchain projects takes place in the grey literature, and more scholarly research is needed to answer design-related questions.
In this paper, we address the lack of systematic frameworks to design blockchain projects. Our objective is to propose a validated design framework that includes critical requirements for designing humanitarian blockchain projects. The framework contributes to the literature by providing design requirements that are grounded in theory and two in-depth case studies in different contexts. The framework is subsequently validated with another pilot project.

Characteristics of humanitarian operations
The objective of humanitarian operations is to save lives, alleviate the suffering of vulnerable people, and maintain human dignity (Global Humanitarian Assistance, 2020). Humanitarian operations include acquiring and delivering aid (in many forms such as cash or in-kind donations) to the hands of beneficiaries effectively and efficiently to meet the urgent needs (Kovacs and Moshtari, 2019).
Humanitarian operations are different from other operations in other sectors. First, humanitarian operations have specific characteristics as follows Holguín-Veras et al., 2012;Wagner and Thakur-Weigold, 2018). (i) In humanitarian operations, different objectives are being pursued under severe time pressure. The time pressure to respond swiftly and behave with fast-changing situations on the field is a compelling reason for dysfunctional operations. The pressure can result in cognitive biases and consequently introduce reactive behaviours, which reduces the efficiency of humanitarian operations (Comes, 2016). (ii) There is huge uncertainty about the actual needs. Because of the continuous fluctuations of demand and supply during the execution of humanitarian operations, humanitarians frequently face unex-pected constraints on budget, supply of goods and services, and technical infrastructure on the ground (Charles et al., 2016). (iii) Decision-making and coordination structures are often based on information in the short term, not hierarchy nor long-term perspectives. (iv) Different kinds of network dynamics exist in disaster zones due to several types of roles and types of relationships as well as supporting systems for operations (Jones and Faas, 2017).
(v) The goals of humanitarian operations are to save lives, alleviate human suffering, and maintain human dignity as much as possible while upholding the humanitarian principles (Besiou and Van Wassenhove, 2020).
Importantly, humanitarian operations differ from development programmes (Wagner, 2021). These are programmes that often seek to address the underlying socioeconomic factors leading to a crisis in developing countries. They are triggered by the systemic social, political, and economic problems of countries or regions. The populations in these countries might live in poverty and have insufficient food or housing, or the countries might face unfavourable climatic conditions, lack economic resources as a consequence of disasters or emergencies, and have underdeveloped health or education systems, or the political system might be unstable. The goals of development programmes are, therefore, to contribute to better lives and more broadly realise the Sustainable Development Goals in the long run (Wagner, 2021).
Second, access to critical information is often lacking in humanitarian operations, driven by a combination of infrastructure gaps and barriers to information sharing (Van de Walle and Comes, 2015). Sometimes excessive information via media coverage is available, while in other instances, incomplete information (from the field) is provided (Wagner and Thakur-Weigold, 2018). Because humanitarian decisions and coordination rely on information, successful humanitarian operations require access to up-to-date and reliable information to prioritise scarce resource and facilitate collaboration. However, especially in large-scale disasters, information about the number of victims, access conditions or demand characteristics is often not available to all responding HOs (Warnier et al., 2020). Particularly smaller or new HOs that do not have access to or experience with the information collection and sharing within the humanitarian coordination system 2 face difficulties in accessing the available information, although their contributions and expertise are highly relevant . Because of a lack of information sharing, there is a significant potential in humanitarian operations to improve collaboration. Better collaboration through communication, information exchange, and coordination can facilitate international HOs' objective to raise the efficiency and effectiveness of humanitarian operations (Wagner and Thakur-Weigold, 2018).To handle the humanitarian crisis more effectively and combat the stress from donors and competition, HOs must consider the significance of a coordinated approach and apply information and communication policies that enhance collaboration (Maiers et al., 2005).
Third, several stakeholders (e.g., governments, international HOs, non-governmental organisations (NGOs), donors, volunteers, and the private sector) are involved in managing and delivering humanitarian assistance with the dominant positions of NGOs and governmental authorities. There is variability in suppliers. The choice for suppliers is limited, and on some occasions, even undesirable suppliers are included (Kovács and Spens, 2007). Although stakeholder involvement is also important for operations in other sectors, the concept of stakeholder involvement for the humanitarian operations (as an example of socially-oriented projects) proposes a higher magnitude given their buy-in impacts on the success of projects (De Camargo et al., 2019). Because of several stakeholders' involvement, the collaboration process in humanitarian operations is more complex and challenging compared to commercial firms (Wagner and Thakur-Weigold, 2018). All these stakeholders (aid agencies, suppliers, and local and regional players) apply different operating techniques, and coordination among them can be very demanding, especially between the military and relief agencies; collaboration is often unbalanced and unpredictable (McLachlin and Larson, 2011;Heaslip et al., 2012).
Fourth, the high staff turnover in HOs and the distinct nature of disasters in different countries make the growth and shift of know-who challenging, which is why it is hard to build institutional memory to improve the efficiency of humanitarian operations and to implement lessons learned. As such, the diversity of technical knowledge and skill sets of staff is limited, and training courses are often focused on organisation and coordination issues (Allen et al., 2013;Wagner and Thakur-Weigold, 2018).
The essential feature of the humanitarian operation is its dynamic and volatility. The following characteristics express the dynamic nature and uncertainty of the humanitarian sector: changes in the number and responsibility of stakeholders in humanitarian operations, different stages of the disaster life-cycle (mitigation, preparedness, response, and rehabilitation), the number and type of disasters that are affected by the complicated global challenges such as climate change, urbanisation and political conflicts, HOs' objectives (keeping a balance between effectiveness and efficiency), use of modern technology which is expensive in humanitarian context unlike the commercial sector, the type of aid given to beneficiaries (providing money and vouchers instead of in-kind relief things) and HO's business model (for instance whether to own the vehicle instead of outsourcing transport activities) (Besiou and Van Wassenhove, 2020).
Overall, the above-mentioned characteristics set apart humanitarian operations from operations in other sectors (e.g., business). Aside from introducing incentive schemes to make HOs cooperate and eliminate unnecessary costs, a new basis for information sharing is needed to decrease redundancies while guaranteeing privacy to the most vulnerable despite potentially limited technical skills and training of practitioners. Moreover, numerous intermediaries (e.g., financial service providers or governmental institutions) that are involved in managing funds and donations for the humanitarian assistance (Wakolbinger et al., 2011) spend a significant amount of donations on administrative processes 3 that do not have a direct impact on beneficiaries (Goldschmidt and Kumar, 2016). As such, donor expectations on project results are sometimes not fulfilled, making them reluctant to donate, which limits HOs in their scope of action (Besiou and Van Wassenhove, 2020). The use of blockchain in the humanitarian sector improves transparency, reduces transaction costs and bureaucratic processes, enables the beneficiaries to satisfy their requirements more accurately, and provides accurate information about the beneficiaries' actual needs to the HOs (de Vrij et al., 2018). Blockchain technology has shown the potential to increase efficiencies, eliminate intermediaries, diminish redundancy, improve information sharing, and reduce privacy issues. However, we stress that humanitarian blockchain projects are different from other types of projects. The difference is not only considerable compared to business projects (that we will explain later with evidence from case studies in Section 5) but also compared to other "blockchain for good" projects that often do not have similar urgency and impact on lives (Adams et al., 2018). The dif-ferences imply the need for a design framework that can effectively support designing humanitarian blockchain projects.

Information system design for humanitarian operations
Literature that discusses the need for dedicated design frameworks for ICT in humanitarian contexts can be divided into two categories. The first category argues for the importance of humanitarian principles, namely humanity, neutrality, impartiality, and independence (Sandvik et al., 2014;Cardia et al., 2017). The second category notes the importance of considering beneficiaries' dignity while designing applications for humanitarian purposes (Sandvik et al., 2014;Talhouk et al., 2019). According to the first category, a distinguishing factor for humanitarian contexts is the need to uphold the humanitarian principles (Raymond and Card, 2015) as follows.
The principle of humanity states that human suffering must be addressed wherever it is found, and no distinction should be made between places or populations (UN OCHA, 2012) -expressed as 'leaving no one behind.' However, the inclusion has proven difficult to achieve in blockchain pilots for humanitarian organisations that solely relied on design guidelines from the business sector (Hallwright and Carnaby, 2019). One of the main hurdles in adopting technologies in a humanitarian context is a difference between humanitarian values and the factors that aspire to technological development. The growth of the economy has been a driving force in the advancement of technology. In this context, the engine of change in technology was mainly driven by the motive to earn a profit (Romer, 1990;Sundström, 1998). In contrast, humanitarian work's main driving factor is to assist individuals in need (Walton et al., 2016).
The principle of neutrality asserts that humanitarians must not take sides in hostilities or engage in controversies of a political, racial, religious, or ideological nature (UN OCHA, 2012). In humanitarian operations, to create impactful change, it is necessary to translate the principles of fairness into policies and systems (Gutjahr and Nolz, 2016). However, design frameworks from the business sector often have not been developed to acknowledge the existence of different beneficiary groups in targeted areas for humanitarian operations. As such, following business-driven frameworks can unintentionally start a controversy between different beneficiaries' groups and the respective HO (Cardia et al., 2017).
The principle of impartiality requires prioritising the most urgent cases of distress, specifically the marginalised groups like women, children, elderly people, disabled people, and refugees (UN OCHA, 2012). However, these groups often have less access to technology because they either do not have the network coverage or own a cell phone or a computer and are literacy-challenged (Sandvik et al., 2014;Riani, 2018). That said, if not designed properly, the benefits of innovative approaches (like using blockchain) may not be evenly distributed, resulting in a 'digital divide' and leave many excluded. If designed and developed properly, the use of advanced technology such as blockchain can empower women to alleviate poverty, reduce hunger and improve health in developing countries (Tang, 2020).
The principle of independence demands humanitarian operations to be autonomous from the political, economic, military, or other objectives that any actor may hold concerning humanitarians' target areas (UN OCHA, 2012). As Cardia et al. (2017) notes, several use-cases of ICT in the field and remotely often lack analyses of the challenges they represent to the independence principle for their application, such as the required access or consent to data infrastructure from governments in targeted areas.
As discussed by the second category, design frameworks should account for the 'achievement dignity' of beneficiaries, who are often are the most vulnerable located in less developed regions of the world, fraught with violence and political instability. The achievement dignity refers to "being in a dignified state" (Formosa and Mackenzie, 2014). With digitalisation, a composition of both offline and online activities of mankind are increasingly emerging (Zwitter et al., 2020). To protect digital identity, the United Nations (UN) stresses that "the same rights that people have offline must also be protected online." (UN, 2014). That said, several scholars have called for design frameworks that facilitate embedding dignity within technologies for humanitarian operations (e.g., Sandvik et al. (2014)). Zwitter et al. (2020) mentioned that the four humanitarian principles (humanity, neutrality, impartiality, and independence) are still the "core principles" and emphasised that these principles should be observed with any technological solutions. Also, as Coletti et al. (2017) explain, the applicability of an information system design for the humanitarian context is determined by how well it incorporates humanitarian values and embeds dignity. Talhouk et al. (2019) assert that embedding dignity means that maintaining dignity is an aim that should be inherent in the designs of technologies for humanitarian purposes and given significant consideration when configuring such technologies.

Research methodology
We follow a qualitative multi-method approach, combining a literature study and in-depth case studies to develop the design framework. As the paper aims to explore in-depth the complexity of designing humanitarian blockchain projects, qualitative methods were chosen as they are appropriate in understanding complex systems and framing hypotheses and relationships (Szajnfarber and Gralla, 2017). Using different qualitative methods enables methodological triangulation and a deeper understanding than using any single method. Methodological triangulation means that a researcher off-sets the weaknesses of one method with the strengths of another as a means of improving the reliability and validity of their research (Bekhet and Zauszniewski, 2012). Data triangulation, however, involves gathering data through differing sampling strategies such as interviewing at different times, in different contexts, or from different people (Modell, 2005). Fig. 1 provides a schematic overview of our research methodology and shows how the different steps feed into each other.
We conducted a systematic narrative review of the peerreviewed literature to identify and collect design requirements on blockchain architecture design. Systematic reviews are often designed to provide a reliable picture of "current best evidence" relevant to a particular question (Hunt et al., 2018). In most cases, the final product of a literature review is the presentation of a statistical (quantitative) or narrative (qualitative) summary of findings.
Due to the aim of our study (i.e., identifying the latest development in the literature about designing blockchain projects and addressing research gaps for supporting humanitarian blockchain projects) and research design (i.e., validating literature derived dimensions through case studies), a narrative review approach to synthesise literature was used (Hunt et al., 2018). According to Wiles et al. (2011), narrative review draws conclusions about the topic and identifies gaps or inconsistencies in a body of knowledge.
Although there are also several frameworks and guidance notes from practice (Coppi and Fast, 2019;Hallwright and Carnaby, 2019) that we took into account for motivation and positioning, we focus here on peer-reviewed academic literature to develop our framework. To complement our findings, we reviewed papers that discuss the risks of using blockchain technology in the humanitarian sector. We argue that taking into account relevant considerations upfront in the design phase can help to mitigate these risks.
To conduct the review, we used the keywords 'block chain' OR 'blockchain' with 'design' OR 'architecture' OR 'framework' in Scopus and Web of Science databases. The databases were chosen as they represent worldwide references that have been subject to comparisons from the perspective of their coverage: collected articles, journal titles, thematic and geographical areas, affiliation, languages, citation analysis (Wamba et al., 2020). We considered (January 1st) 2014-(January 1st) 2020 as our search timeline, in line with the rise of blockchain technology. The restrictions were narrowed down to English language, academic articles and the field tags topic and title. These tags were chosen to increase the relevance of the generated results. We included papers only in the following subject areas: 'Computer Science', 'Business, Management and Accounting', 'Economics, Econometrics and Finance', and 'Social Sciences'. The list of subject areas was derived from similar literature reviews regarding adopting technologies to humanitarian contexts, e.g., Altay and Kovács (2018). After removing duplicated results, we also excluded papers with a primary focus on reviewing papers, market trends, cryptocurrencies, and theoretical algorithms (1st exclusion relevance criterion). Moreover, we excluded papers that did not elaborate on the suggested design aspect(s) in detail (2nd exclusion criterion). Fig. 2 illustrates the process that we followed in our literature search.
To analyse papers, we followed Mayring (2004)'s guidelines for conducting the qualitative content analysis. First, we formulated a criterion of definition for each aspect derived from theoretical background. This helped us to determine the attributes of the textual material taken into account. Following the criteria, the selected papers were read through, categorised tentatively and step by step deduced. We coded papers using NVivo 11. The coding scheme was derived from the research question and included classification based on two macro design requirements categories:  technology-related and organisation-related. Within a feedback loop, the categories were revised, and eventually each macro requirement was categorised into multiple micro design aspects, as explained in Section 4.
The identified design requirements were subsequently explored through two case studies (cf. Section 4.1). Case-study research is one of the most prominent methods in humanitarian operations, for it enables a rich understanding of the underlying problems (Vega, 2018). We followed Yin (2009)'s multiple-case design. Multiple-case design is a research methodology in which several instrumental, bounded cases are examined using multiple data collection methods. Our approach had three main stages, following Yin (2009): • Stage I -Theoretical framework and design: this stage includes theory and selecting cases. Our research evolves around identifying design requirements for blockchain projects for the humanitarian sector. Two pilots, the 'Building Blocks' (UN WFP) and 'Blockchain Open Loop Cash Transfer' (IFRC) were selected for case studies. We argue that these cases represented different crisis contexts (refugees vs drought) and organisations (UN agency vs international NGO). As such, the cases allow for an ini-tial exploration of the domain. An overview of the two cases is given in the supplementary material file. • Stage II -Data collection and analysis: We conducted 12 semistructured interviews with representatives from key actors and stakeholders of the two pilot projects; six senior managers from HOs (minimum five years with innovative projects in the humanitarian sector), two experts from blockchain enterprises (more than fours years of experience with blockchain projects in different sectors) partnered with HOs for pilots, two representatives from the largest vendors in the pilots, and two representatives from beneficiary groups. Interview guideline is given in the Appendix A. Interviews were transcribed and complemented by reviewing twenty-five projects documents, including project descriptions, internal reports, fact-sheets and reports. To analyse the data, we followed a hybrid approach, combining interpretive thematic analysis based on a coding schema and inductive coding based on emerging codes (Fereday and Muir-Cochrane, 2006). The transcripts were read through multiple times, and micro design dimensions were written in margins to describe every aspect of the content. The micro dimensions were collected, and if necessary, new micro dimensions were generated at this stage. Micro dimensions with similar objectives were grouped together. Thereafter, the lists of new micro dimensions were grouped under macro dimensions. The purpose of creating two-level categorisation (macro vs micro) is to provide a means of describing the phenomenon, to increase understanding and to generate knowledge (Elo and Kyngäs, 2008). In conclusion, we could only characterise one extra macro category compared to literature-derived categories. We named the new macro category using content-characteristic words: contextrelated requirements. Fig. 3 shows an example of a code sheet for one of the interviews. • Stage III -Interpretation of cases: First, each case in the research was treated as a single case. All of the data in each single bounded case was carefully examined, and the data organised into a comprehensive description that is a unique, holistic entity. Once a full account of each case is developed, cross-case comparisons were developed based on tables derived from our analysis notes. We examined the data across cases to see if a pattern of design aspect transcends the cases. Patterns were noted and clarified, commonalities in essential elements or components identified, clusters developed and sorted along macro design requirements. Moreover, potential correlations between design aspects were noted.
The case studies were conducted through multiple interviews with key informants representing different levels at HOs (executive, manager and consultant), as well as different functional domains (IT and project management). Additionally, we interviewed informants at different levels and forms of involvement in the pilots, including members of project business partners, beneficiaries, and vendors. Focusing the twelve interviews on key actors allowed for developing a solid understanding of design dimensions for humanitarian blockchain projects. The number of interviews was considered sufficient as we achieved theoretical saturation: the interviewees' opinions converged, and we concluded that further interviews would not bring incremental benefit to the theory (Rowlands et al., 2016). However, we acknowledge that the scarcity of publicly announced humanitarian blockchain projects (at the time of conducting this research (Coppi and Fast, 2019)) limits the opportunity to find a large number of relevant experts. Among the key informants, we also interviewed two participants (village/camp leaders) involved in each case to get the beneficiaries perspective. Internal reports and documentation were also used as sources. Table 1 offers further detail on the case study process used leveraging screens for rigorous case study research from Vega (2018) and Barratt et al. (2011). For trustworthiness, however, we followed Elo et al. (2014)'s checklist.
To benchmark our framework against applicability and relevance, we used focus group discussions. We used the data publicly available online for the Oxfam's Unblocked Cash project and communicated our proposed framework with five experts involved in the project. Experts participating in the focus group discussions were senior managers and had at least four years of experience in innovative humanitarian projects in different countries to combat poverty and hunger. We contacted the experts via email first, providing the proposed framework (cf. Fig. 6) and design steps. Thereafter we organised a Skype meeting and asked them for their input on the following two questions: (a) is the proposed framework relevant and informative for designing humanitarian blockchain projects? (b) what would you change in the design phase of your project if you had the chance to use the framework?
Our rationale for selecting cases is as follows. Indeed, blockchain is among the emerging technologies that the humanitarian sector has been exploring over the last years. The two pilots from UN WFP and IFRC that we used for exploring the literature-derived design requirements were the only publicly announced blockchain projects in the humanitarian sector at the time of data collection for our study (autumn and winter 2018). The Oxfam's pilot was selected for benchmarking and validation because not only it was also publicly announced, but also it could offer a comparison opportunity with respect to the two previously studied pilots (all were cash transfer pilot projects). Moreover, the Oxfam's pilot has been a success referring to the pilot's research report (Rust, 2019).

Blockchain technology, supply chains and humanitarian operations
Literature review indicates that the application of blockchain technology to supply chains can bring several advantages. For instance, decentralised last-mile delivery services through advanced technology such as blockchain improve transparency, service quality, and trust in the logistic industry (Choudary et al., 2019). Blockchain technology facilitates Supply tracking and contributes to sustainability, which could be critical advantages for today's supply chains (Saberi et al., 2019). Moreover, the technology helps to reduce risks particularly associated with intermediaries' interventions such as hacking, compromised privacy, political dis-  (2019) Highlight the significance of enterprise requirements and call for focus on system integration (e.g., enterprise integration and external system integration) to facilitate adoption. Schulte et al. (2019) Define the technical design as how the running system is structured and behaves and discuss it with respect to (a) data, (b) functions, (c) deployment, (d) activities and (e) technologies with a focus on choices related to (a) what kind of data, where and with how much storage, (b) smart contracts and user interfaces, (c) hardware properties, (d) existing or a new blockchain platform, and (e) ledger type, consensus, and transaction costs. Xu et al. (2019) Consider different technical design aspects such as decentralization, ledger structure, consensus protocol, block configuration, anonymity, and incentives. Bahga and Madisetti (2017) Argue that attention has to be paid when selecting a blockchain platform in the design phase since requirements such as ledger structure, consensus protocol, and block configuration are fixed once a particular blockchain (e.g., Ethereum) is selected. Yermack, 2017Yermack (2017) Lack of support, compliance issues with current legislation, and insecure key management are critical risks that threaten blockchain projects. Hardjono et al. (2018) Stress the risk of interoperability for blockchain projects and argue for the existence of many blockchain platforms (which often differ in parameters such as consensus models, transaction schemes, and smart contract functionality) and an absence of standards. Baxter and Sommerville (2011) One requirement of design frameworks for the humanitarian sector focuses in reaching some degree of alignment between the end-users through an iterative design process.
order, costly compliance with government rules and regulation, instability of financial institutions, and contractual disputes (Min, 2019). Other advantages of blockchain are reduced transaction fees, public transparency, asset integrity, fraud detection and prevention, peer-to-peer connectivity, and better order fulfilment (Min, 2019). By applying the transaction cost theory, Schmidt and Wagner (2019) explored that blockchain might impact the supply chain relationships, specifically in terms of transaction costs and governance forms. They argued that blockchain might mitigate the governance costs by reducing the several dimensions of transaction costs such as reduction in search and information cost, (re-)negotiation and agreement cost and post-contract control costs. The application of blockchain might control opportunistic behaviour and reduce environmental and behavioural uncertainty. And governance forms might converge to a more market-oriented governance mode. Despite benefits, several barriers hinder the application of blockchain to supply chains. Kurpjuweit et al. (2019) identified 24 barriers and divided them into four broad categories: i). technological, ii). organisational, iii). environmental and iv). relational. The study also revealed that the most critical barriers are not technical barriers. For instance, the results showed that the most important barriers are the unavailability of blockchain-skilled specialists, missing governance, lack of internal technical expertise, and (uncertain) regulatory conditions. These barriers are linked to a firm's internal competencies, its environment, and interorganisational relationships. Kurpjuweit et al. (2019) echo similar barriers and indicate that to adopt and implement blockchain in supply chains successfully, such barriers need to be addressed carefully.
The drivers and barriers mentioned above are relevant to the contexts of humanitarian operations, too. Blockchain can enable richer access to information by providing a shared record of information to all disaster responding HOs. Not only commercial but also humanitarian partners can benefit from this technology that makes critical information visible and available for all HOs, although some investments into in-house ICT infrastructure might be needed (Coppi and Fast, 2019). Moreover, blockchain can eliminate thirdparty involvement and instead directly connect donors with aid recipients. Costly and time-consuming administration is removed from the funding process, and donors can see the direct impact of funds, which is extremely difficult to visualise in the current funding system. Blockchain can also enable humanitarian parties to share critical information about relief item types and quantities in real time with each other (L'Hermitte and Nair, 2020). Distributing this information to all HOs could reduce redundancy along humanitarian supply chains, as supply types and quantities are completely visible for all HOs. Moreover, making shipments traceable for humanitarian operators, donors and beneficiaries could increase the accuracy of delivery times, prevent fraud and increase donor satisfaction (Zwitter and Boisse-Despiaux, 2018). The humanitarian sector can benefit from one of the crucial features of blockchain technology i.e., it's potential to boost information sharing among the stakeholders and strengthen their collaboration. (Rodríguez-Espíndola et al., 2020). The development and application of blockchain technology in supply chain management have attracted the attention of policymakers in the humanitarian sector to facilitate aid supplies or transfer of money. However, the practical application of this technology has not yet been fully implemented and is still in a conceptual phase in the humanitarian operations sector (Wagner, 2021).

Design frameworks for blockchain projects
Designing blockchain projects can only be successful if the design is rooted in an understanding of the underlying complex socio-technical problem. Besides the direct impact on functional requirements (a data store vs a computational infrastructure), design decisions impact a blockchain system's ability to meet non-functional requirements (NFRs) that are associated with nonfunctional properties such as cost, privacy, or transparency (Xu et al., 2019). Moreover, design choices for blockchain projects introduce trade-offs between conflicting NFPs (e.g., privacy vs transparency), too.
Guidelines and frameworks for designing blockchain projects in business environments exist in the literature. Our narrative review of blockchain literature indicates that scholars have mainly focused on technical and enterprise requirements when proposing blockchain design frameworks (Tasca and Tessone, 2019;Xu et al., 2019;Bahga and Madisetti, 2017). Some of these authors have discussed design requirements through the risks of using blockchain technology, such as a lack of support, compliance issues with current legislation, insecure key management and a lack of standards and interoperability (Yermack, 2017;Paech, 2017;Scott et al., 2017;Gomber et al., 2018;Linkov et al., 2018;Trump et al., 2018;Dorofeyev et Table 2 presents examples of common design requirements in the blockchain literature. The list of the most common aspects in the literature (i.e., repeated more than four times) is categorised into macro and micro requirements and illustrated in Fig. 4.

Case study findings
Based on Nuseibeh and Easterbrook (2000), we extract requirements from the conducted interviews with the involved experts in the humanitarian blockchain projects. The design requirements that we identified from interviews and case studies are schematically presented in Fig. 5. As it can be observed, not all literature-derived micro requirements could be confirmed while many others were missing. Comparing to Fig. 4, contextual design requirement and its aspects emerged from our interviews. Furthermore, we identified some additional requirements in the technical (such as scalability and in/out mechanisms) and organisational domains (such as knowledge/skills and intellectual property). Table 3 shows a summary of insights with respect to case studyderived design aspects. Details are provided in the supplementary material file, and we elaborate on how to use the design aspects in Section 4.2.
Comparing to Fig. 4, we did not include two technical requirements in our investigations. The first requirement referred to incentives. We argue that incentives are often paid (on public blockchains) to make miners join the network, validate transactions, generate blocks, and (where applicable) execute smart contract functions correctly. However, our cases were private blockchains, and there was no incentive. The second is the interface, which requires a dedicated study to identify sub-requirements given the diversity of users in the humanitarian sector.
While we were able to identify contextual requirements, our interviewees shared very little insight about important technical requirements, such as the rationale for choosing blockchain platforms. This aspect covers details such as the consensus protocol, the ledger structure, the block configuration and the encryption technology. Similarly, strategies for developing effective interactions (e.g., application programming interface (API)) in connection to other tools, like assessment applications, remained unclear. For privacy (and anonymity) we identified important conflicts in the claims. According to IFRC (2018), 'IFRC relied on the GDPR as well as the Handbook on Data Protection in Humanitarian Action to ensure the privacy of the beneficiaries was protected. The GDPR gives the right to data subject to be forgotten. However, we could not confirm how this could be addressed without the private architecture. Furthermore, interviewees did not explain whether individual purchases were tracked or not, which is critical as such tracking is not aligned with the privacy aspect. Fig. 6 illustrates our design framework for humanitarian blockchain projects. To operationalise the framework for practice, we translate the requirements into critical design questions. The questions enable a systematic exploration of requirements when designing humanitarian blockchain projects. We also suggest an iterative order as shown in Fig. 7. We argue that some technical design aspects, such as the blockchain platform, might determine or influence other design aspects. In turn, privacy may require to re-check the technical design decisions. Therefore, some iteration and alignment should be expected when using the following users' guidelines. While a complete list of questions can be found in the supplementary material file, we explain (some of) the process in the following.

Design framework for humanitarian blockchain projects
[I] Start with key technical design aspects. Describe decentralisation and proceed with the data requirement having in mind different services or components that can be identified for each aspect. Then, continue with the blockchain platform and then key management. After that, think about the scalability issue.
Decentralisation refers to the choices of deployment (public vs. consortium vs. private) and permission (permissioned vs. permissionless). The data storage alternatives are on-chain or off-chain 4 , including functionalities such as user interfaces, cryptographic key management, and communication with other external systems. For blockchain platforms, there are two principal options. The first option refers to build the blockchain network from scratch. The second option is to select one of the commercial platforms such as Ethereum, Hyperledger Fabric, or Multichain. Closely connected to blockchain platform selection is how to configure its components such as blocks, consensus and encryption. Key management is essential as every participant in a blockchain network has one or more public or private keys, which are used to sign transactions digitally. Considerations for this aspect refer to questions such as how keys are generated, by whom, and according to what information. Technical choices regarding scalability are database choices for the shared ledger, adjacent system integration, encryption, and consensus. The key question refers to the extent that the system will be scaled in future. Furthermore, blockchain technology has limitations in terms of throughput and size of data stored.
[II] Proceed with the in/out mechanisms and regulations aspects carefully. After that, take care of the databases and interoperability aspects.
In and out mechanisms are necessary to facilitate data sharing and data ownership as the entities join and leave the network. There are also sector requirements for the durability of data. These considerations should be evaluated as to who owns the data in the system and how data owners can keep the right to be forgotten. Regulations refer to the implementation of legal requirements such as the GDPR. This is a broad topic ranging from technical questions and infrastructure to process and governance questions. Designing for interoperability goes beyond the legacy systems and includes future applications and systems.
[III] Continue working with the contextual aspects in parallel. Give priority to privacy and ethical aspects.
For privacy, by default, blockchain technologies lead to the visibility of all data written to the blockchain ledger for all participants for all times. Thus, informed decision must be taken regarding the desired level of transparency that can address privacy concerns. Ethical concerns evolve around questions of equal access; preventing that errors in the system delay operations; and informed consent. Infrastructure investigates what infrastructure or software, or network requirements are necessary to use the selected blockchain technology. End-users (beneficiaries, administrators, donors, vendors, developers and other potential users) should have access to the system effectively. Second, it should be clarified that how blockchain nodes will be allocated to the users. Stakeholder involvement determines how different groups interact with the system (e.g., what level of access) and the roles in the design process.
[IV] Proceed with the remaining aspects in the order of interactions, support, knowledge and skills, and intellectual property.
For interaction options, there are several ways that users and organisations can interact with the blockchain. Examples include command line interfaces, client software development kits, or software development kits. Questions that could be asked here refer to API design, component design, and APIs management. Knowledge/skill-set is important to ensure broad adoption. Relevant questions refer to user guidelines and how they are developed. For intellectual property, the objective is to ensure that the application network has sustainable business growth elements. We want to know if the model would be able to allow every HO to deploy the chaincode and change it to address their goals.
[V] Using humanitarian principles (cf. Section 2.1) to analyse the impact of the blockchain-based system in the field should allow identifying risks as well as providing strategies to mitigate them (if possible). We note that the principles and their definitions have to be checked before this step as distinct humanitarian organisations -such as UN agencies and international aid organisations (e.g., IFRC) -may use or refer to principles differently.

Discussion and validation
In this section, we first discuss our paper's main findings, moving ahead from the design process to essential design choices. Subsequently, we discuss our attempts to benchmark the framework.

Designing humanitarian blockchain projects
Knowledge gaps Our interviewees from HOs shared a few insights about the technical requirements. This may have three main reasons. First, HOs rely on close collaboration with business partners, which often take care of the technical aspects instead of developing expertise in-house. Second, Coppi and Fast (2019) note that pilot managers are often restricted from sharing technical information to protect proprietary and commercial information. Third, the blockchain projects have not moved to the scaling point yet, and HOs are still in the pilot evaluation phase. This supports the fact that the technical design requirements have not yet been effectively recognised or disseminated in the humanitarian sector.
Infrastructure and information gap Our findings reveal that the availability of required data infrastructure was not taken into account, resulting in delayed implementation. The main reason can be that many state-of-the-art tools and applications assume the availability of data infrastructure and access to data. While in humanitarian contexts, either no or partial access to data infrastructure is commonplace (Van Wassenhove, 2006). To overcome this obstacle, Sokat et al. (2018) recommend to derive and implement a unifying framework to estimate incomplete information in limited data.
Ethics Our findings showed a lack of ethical guidelines for blockchain projects in the humanitarian sector. Yet, the humanitarian innovation literature emphasises the importance of ethics in design, application, and evaluation (Hunt et al., 2016;van Wynsberghe and Comes, 2019;Stute et al., 2020). Ethical frameworks are necessary to uphold humanitarian principles, avoid digital or physical harm, maintain privacy and security, respond to inequalities, demonstrate respect, protect relationships, and address expectations. In the absence of such a framework, the risk of facing the above problems is high due to working in remote areas, the high turnover rate in the sector, and differences in language, social, cultural, and economic conditions. Table 3 Summary of case study findings related to design requirements.

Requirement
Evidence Design status in the studied pilots Infrastructure Working with no or limited data infrastructure for blockchain projects is of high importance as humanitarian contexts can rarely offer wide (if any) access to Internet The availability of required data infrastructure was not considered in pilots and therefore, delayed implementation.
End-users First, designs did not meet different end-users' IT literacy, knowledge and skills; second, developing new projects based on in-place technologies worked well.
End-users were not involved from the beginning of the projects. However, available technologies (such as mobile payments) in the targeted area were assessed before implementation. Ethics First, insufficient access to technology and technology malfunctions can cause harm to vulnerable communities; second, acquiring informed and sustained consent was difficult.
Lack of ethical guidelines for blockchain pilots in the humanitarian sector.

Stakeholders
Inviting authorities, beneficiaries' representatives and technology experts to joint workshops improved collaboration and pilot implementation.
No engagement of stakeholders in the design of one project, some level of engagement through interviews in the other.

Privacy
We identified a close connection between privacy, stakeholders and data in our interviews meaning that trade-offs between transparency &engagement vs privacy have to be carefully addressed.
Lack of guidelines to address privacy concerns affected several design decisions in the pilots such as decentralisation and data.

Decentralisation
We identified two types of decisions: first, deployment that spans from public to private; second, permission with permissioned and permissionless options.
Despite interest in public permissioned systems, the pilots were mainly private permissioned with single service provider, which also might be seen as a database.

Key management
In one of the pilots, keys were generated and managed by a business vendor, which required sharing beneficiaries' ID with a third party. In the other pilot, keys were generated and stored on a local computer.
Insecure key management strategy was observed in both projects.

Data
For on-and off-chain storage, humanitarians kept transactions data on-chain while personal data were stored off-chain.
Relatively good overview on data storage mechanisms.

Requirement Evidence
Design status in the studied pilots Scalability Scalability remained unexplored due to specific design decisions, e.g., decentralisation.
Both pilots showed limitations with respect to scalability.

In and out mechanisms
Interviewees mentioned the importance of considering collaborations meaning that an HO may want to join or leave other organisations' blockchain projects.
Such mechanisms were not considered in the studied pilots.

Databases
As some of the data would be off-chain and referring to the often centralised nature of repository systems at HOs, the choice of tool was an important consideration.
Some considerations were taken into account in the pilots, however, links between the blockchain and HOs' databases did sometimes not work. Interoperability Although interviewees referred to interoperability as a must for a sustainable blockchain project, we observed that blockchain pilots were designed and implemented in silos.
No interoperability consideration could be identified in the pilot projects.

Regulations
The two pilots had to follow different legal frameworks although the majority of interviewees mentioned that the blockchain space was not regulated. Some interviewees discussed regulations in relation to in and out mechanisms or data aspects.
No common legal framework, although both sought legal council.

Support
Often referred to as technical support, interviewees noted this as important early stage requirement because skills may be missing in HOs. Cultural support was also noted in some interviews.
In one pilot a technical IT developer was assigned from the business partner to the HO as technical support during the implementations. We found no evidence for cultural support.

IT knowledge and skill
Interviewees had difficulties to describe the technology and changes for headquarters, peers, donors, country office and other project members.
None of the studied pilots considered this aspect upfront in the design stage.

Intellectual property
One concern of partnership with the business sector in both pilots was the ownership of the system.
One HO considered developing their application as open-source which could eventually facilitate other design aspects such as interoperability.

End-users and other stakeholders
Our findings indicate that the designs did not meet different end-users' IT literacy, knowledge, and skills effectively. Moreover, end-users were not involved from the beginning of the projects. Literature supports that bringing different stakeholders (authorities, beneficiaries, and technology experts) in one platform, such as information sharing workshops, enhance collaboration and ensure successful project implementation in the humanitarian sector (Kovacs and Moshtari, 2019). The findings also support the literature regarding the need for further studies to identify barriers, motives, and drivers that can increase beneficiaries' participation in humanitarian information systems (Altay and Kovács, 2018). The literature on evidence-based action in humanitarian crises mainly concentrates on how information systems can be used to improve humanitarian operations (e.g., Comes et al. (2018)). However, little attention has been paid to find out the preferences of stakeholders, specifically beneficiaries, in the humanitarian sector (Gralla et al., 2015). Like ethics, collaboration among stakeholders is also hindered by the difference in cultures, laws, interests, and organisational resources (Fontainha et al., 2016). Furthermore, the concept of sharing knowledge/information between business and humanitarian sectors (Van Wassenhove, 2006) has not yet received weight from companies' perspective because it might not be beneficial for them (Fontainha et al., 2016).
Privacy The study pointed out the lack of guidelines to address privacy concerns that have affected several other design decisions in the pilots, such as decentralisation and data. Furthermore, from our study, we did not understand whether HOs would turn over the ownership of the data to beneficiaries or not. Also, if the data transacted on the blockchain is immutable, do people have the right or the ability to remove themselves from the blockchain? Using a blockchain makes it harder to request a financial service provider (FSP) to change the data (Guo and Liang, 2016;Pramanik et al., 2019). Published reports from the pilots showed that HOs are trying to determine what measures or privacy standards could be put  in place to ensure that vulnerable people fully understand the technology and potential consequences of their interaction with it (IFRC, 2018).
Scalability Scaling the pilots would be difficult because of the design challenges and the slow pace of process change in HOs (Heaslip et al., 2018). HOs, like most large bureaucracies, tend to be risk-averse and slow to innovate (Sandvik et al., 2014). Convincing HOs to shift from legacy systems to a blockchain-based one will be cumbersome given concerns about governance and operational resilience. Design trade-offs Discussing how the design trade-offs (cf. Section 4) should be addressed requires further investigation with the HOs. We think that the trade-off challenge can be better analysed if the HOs who have already conducted pilot projects report the metrics they have used to measure pilot projects' achievements. In the absence of this information on metrics and measurements, the ability to discern what blockchain designs are most likely to work and, in turn, decide where investments should be made, will be limited.

Applicability and relevance: insights from experts
The Unblocked Cash project was first implemented in Pango and later in Mele Maat, Vanuatu where nineteen shop owners were onboarded onto the system, and 187 recipients (heads of households) were given Near field communication (a.k.a. NFC) cards that held the balance of their digital wallets in the form of an encrypted sequence of deposits and withdrawals. Recipients then used the NFC cards at participating shops throughout their communities. The solution consisted of three main components, namely prefunded NFC cards, phones issued to the shopkeepers, and Ethereum public blockchain backend for controlling the flow of digital cash. Approximately 2000 transactions were recorded during the pilot. Due to privacy concerns, individuals' purchases were not tracked. However, the program recorded the general category of purchases such as medicine, food or bills.
With respect to the questions that we asked (cf. Section 3), all participants agreed on the relevance of the proposed framework for humanitarian blockchain projects and found it informative, specifically concerning the context-related aspects. However, the answers to the second question were different. We elaborate on some of the responses with respect to frequently mentioned requirements. In the context category, two participants highlighted that the framework could help with better planning for data infrastructure issues: In Vanuatu, smartphones are rare, and the Internet can go down for days at a time [. . .] While the system was designed to withstand some degree of service interruption, issues did present with intermittent connectivity. The framework helps to make additional consideration to ensure a high-quality intervention in future.
Among the technology-related requirements, multiple participants pointed out the issues with key management. Value on Ethereum's distributed ledger is assigned to a public address, which anyone with the correct key can access. The combination of an address or a public key with a private key constitutes a digital wallet. While one of the keys is public (similar to a bank account number), the other one is private, and one can lose access to value on the blockchain if the private key is lost. One participant noted that key management issues could be taken into consideration upfront in the design phase.
The question for Oxfam was who governs the wallet and what processes needed to be developed for safe and effective use thereof? Alternatively, did Oxfam need to govern the wallet at all?
The other frequently mentioned problem was scalability given the low number of participants in the pilot and the stable conditions of the target community. Moreover, the project has to be redesigned to accommodate for in/out mechanisms in future.
For us, the plan for scaling up is still vague. It remains unclear how the tested system is likely to respond at scale or in a different context, especially in an emergency response or recovery effort. We could have thought about this earlier.
We are interested in the inclusion of donors include[ing] traditional government back donors, corporate donors, or individual donors. Donors could contribute crypto assets directly and the asset could be forwarded directly, to an NGO like Oxfam or committed to a specific type of intervention. However, for such functionality, the project would have to be redesigned to accommodate a donor front end.
Furthermore, one expert pointed out that available knowledge and skillsets requirement in the organisation category were not considered carefully in the project design: The project simply had a single point of failure and that was Oxfam's immense dependence on one of the partners' core staff, who travelled to Vanuatu for the duration of the pilot [. . .] Unless Oxfam staff improve their skillsets to be able to respond to hardware and software issues in-country without that partner's support, this indispensable expert represents a single point of failure, and, therefore, a significant risk for future implementations which the framework highlights clearly.
With respect to humanitarian principles, one expert commented that the critical concern of "dignity" 5 could help the project design.
The important thing to remember is that many of beneficiaries only possess a feature phone and may have limited or no access to mobile data networks [. . .] even a significant number are unable to confidently send SMS or make phone calls without assistance. Such risks associated with humanitarian principles could be mitigated with help of the framework. Fig. 8 shows the summary of benchmarking session and compare the project characteristics with the support that our framework could offer. The frequency of dark boxes (shortcomings) in the context-and organisation-related categories indicate that several aspects specifically important for humanitarian operations were not thought through when designing the blockchain-based system in the project. On the other hand, the rather majority of white boxes (strengths) in the technology-related category indicates that the project was well prepared technically. The divergence could be explained by the fact that blockchain-based systems in the humanitarian sector have often been developed by business consultants who offer a good range of technical skills and expertise but have little knowledge about humanitarian principles, contexts and working culture (Coppi and Fast, 2019).

Conclusions
This study proposes a framework for designing humanitarian blockchain projects that explicitly accounts for the distinct factors that differentiate humanitarian operations in both commercial and development contexts. Most importantly, these factors include the humanitarian principles, the volatile and highly uncertain conditions of infrastructure and access, as well as the extreme importance of stakeholders and HOs working conditions and culture. Based on the literature review, we identify two macro design categories, namely technology-and organisation-related requirements, and their associated micro aspect. Then, we validate the literature-derived macro and micro requirements through two case studies (Building Blocks pilot and Blockchain Open Loop Cash Transfer pilot projects) and add additional case-driven factors. Finally, we benchmark the validated design framework by comparing what practitioners did in the Unblocked Cash pilot project and what our framework could suggest. While our research supports literature regarding the importance of technological and organisational requirements, it sheds light on the importance of context-related macro requirements based on our findings from the case studies including five aspects of infrastructure, endusers, ethics, stakeholders, and privacy. Moreover, our research introduces case-study driven micro aspects in all macro design requirements that were not considered in other studies. Our findings suggest that two additional aspects need to be taken into account as technology-related requirements (scalability and in/out mechanisms). Similarly, under the organisation-related requirement, we recommend including knowledge/skills and intellectual property. Thereby, our framework accounts for the humanitarian principles of humanity, neutrality, impartiality, independence, and dignity transparently and systematically.
For practice, our research provides five steps for designing humanitarian blockchain projects. Given that we verified the requirements through two recent blockchain pilots (WFP's Building Blocks project and IFRC's Open Loop Cash Transfer project) and illustrated its strength through data from a real case, the proposed framework can help HOs and practitioners decide what macro and micro requirements they should consider when designing a humanitarian blockchain project.
Our research also opens future research avenues. First, in this study, we reviewed peer-reviewed academic papers to ensure high quality and research rigour of selected studies; grey literature was excluded in the review. As such, one future research direction could be to conduct a systematic evidence review following the Brown et al. (2012)'s suggested approach. Second, our cases were limited to CBA. However, blockchain has been introduced for other problems in the humanitarian sector, such as ID management. Future research would be testing the design framework with other humanitarian blockchain projects. Third, insights from experts regarding our framework's validity show that at least one aspect is not addressed by our framework: identity management and/or beneficiary registration. This requires further investigation. Fourth, to weigh the design requirements is another research direction as it can support addressing the trade-offs between different design requirements and aspects when considering multiple design options.