Software and Systems Modeling (2023) 22:1857–1895 https://doi.org/10.1007/s10270-023-01109-1 SPEC IAL SECT ION PAPER Design of blockchain-based applications using model-driven engineering and low-code/no-code platforms: a structured literature review Simon Curty1 · Felix Härer1 · Hans-Georg Fill1 Received: 28 October 2022 / Revised: 25 April 2023 / Accepted: 2 May 2023 / Published online: 11 June 2023 © The Author(s) 2023 Abstract The creation of blockchain-based software applications requires today considerable technical knowledge, particularly in software design and programming. This is regarded as a major barrier in adopting this technology in business and making it accessible to a wider audience. As a solution, low-code and no-code approaches have been proposed that require only little or no programming knowledge for creating full-fledged software applications. In this paper we extend a review of academic approaches from the discipline ofmodel-driven engineering as well as industrial low-code and no-code development platforms for blockchains. This includes a content-based, computational analysis of relevant academic papers and the derivation of major topics. In addition, the topics were manually evaluated and refined. Based on these analyses we discuss the spectrum of approaches in this field and derive opportunities for further research. Keywords Blockchain · Low-code · No-code · Model-driven engineering · Software development 1 Introduction With the further maturing of blockchain technologies and the on-going transition to more energy-efficient and faster pro- tocols with higher transaction volumes [86, 189], a more widespread adoption of these technologies seems within reach. However, one considerable barrier limiting the adop- tion is the technical and organizational complexity that users are confronted with when creating blockchain-based applications [131]. This complexity originates on the one hand from the underlying technical foundations, which build on distributed and decentralized systems, cryptogra- phy, and algorithmic processing [12]. Blockchains such as Ethereum [272] combine these properties for storing trans- Communicated by Iris Reinhartz-Berger and Dominik Bork. B Simon Curty simon.curty@unifr.ch Felix Härer felix.haerer@unifr.ch Hans-Georg Fill hans-georg.fill@unifr.ch 1 Digitalization and Information Systems Group, University of Fribourg, Bd de Pérolles 90, 1700 Fribourg, Switzerland actions in an append-only data structure, where each new block has a cryptographically verifiable link to its prede- cessor. Thus, users are part of a decentralized network that minimizes the degree of trust required towards other par- ticipants who continuously validate the information of the blockchain [92, 93]. In addition, organizational barriers such as the involvement of new regulatory requirements, the devel- opment of new skills and competencies, and the availability of financial and human resources may prevent adoption in practice [56]. From the perspective of software engineering, the lack of specialists for programming may today be partly com- pensated with so-called low-code platforms [36, 95, 245]. These development platforms are typically available as cloud services with visual, diagrammatic interfaces and declara- tive languages. In our view, they constitute the next step in the industry adoption of academic model-driven engineering (MDE) approaches and their predecessors. The long-standing MDE discipline originated from the development of CASE (computer-aided software engineer- ing) tools in the late 1980s [171], proposing the use ofmodels as primary development artifacts for engineering [42, 76, 266]. MDE methods and tools address requirements, archi- tectural components, and software artifacts with professional developers. 123 http://crossmark.crossref.org/dialog/?doi=10.1007/s10270-023-01109-1&domain=pdf http://orcid.org/0000-0002-2868-9001 http://orcid.org/0000-0002-2768-2342 http://orcid.org/0000-0001-5076-5341 1858 S. Curty et al. The term low-code development has been adopted by industry in recent years where various platforms are provided for the generation of software components or their cloud- based integration. While low-code approaches allow a user to produce results without having to understand source code and there may be an underlying model integrated with fea- tures of the platform [36], the model may not conform to an explicit formalization [76]. Further, we consider so-called no-code approaches as a subset of low-code approaches that operate at an abstraction level above code, not showing code to the user at all. Today, a large number of such platforms and tools are available that either support the development of complete software applications or focus on providing spe- cific functionality, e.g., for entering data in a form and saving it to a database [213]. For easing the creation of blockchain-based applications it seems obvious to revert to MDE and low-code approaches. These carry the potential to abstract from the technical com- plexity and enable users to focus on usage scenarios and the organizational embedding [94]. In this paper we present an extension of a prior study [67] which investigated academic and industrial approaches for realizing blockchain-based applications using these meth- ods and provide a comparative analysis of model-driven and low-code methods in this area. The extension encompasses the literature review, the review of industrial approaches, and their comparison. The literature review is extended in its scope and time frame as well as methodology, in particu- lar through the addition of a computational literature analysis with formalized qualitative assessments. The review of low- code and no-code approaches incorporates platforms until October 2022 with an additional analysis step adding appli- cation characteristics and further platform descriptions. The review sections are concluded by discussing and comparing academic approaches in relation to low-code and no-code platforms. We will do this along the following four research ques- tions: RQ1: Which academic modeling approaches have been developed until today for designing blockchain-based appli- cations? RQ2:Which low-code and no-code platforms permit the realization of blockchain-based applications? RQ3:What are the predominant characteristics and areas of academic modeling approaches as well as low-code and no-code platforms? RQ4:What are future research opportunities not realized today by academic approaches and low-code or no-code plat- forms? In particular, we will regard approaches that are already available for creating blockchain-based software applica- tions or offer interfaces to other platforms enabling this. This will permit to describe the state-of-the-art in this area and derive requirements for the development of future approaches. The remainder of the paper is structured as fol- lows. Section2 will outline foundations and related work in the form of previous studies and lead over to the description of our researchmethodology inSect. 3. Subsequently,wewill present in Sect. 4 our review of academic MDE approaches and in Sect. 5 the review of low-code and no-code develop- ment platforms offered by industry. Section6 discusses the results and insights gained through our analysis and leads to our conclusion in Sect. 7. 2 Foundations and related work In the following we briefly describe the main characteris- tics of blockchains and smart contracts as an introduction for readers who are not familiar with these technologies. Subse- quently, we will outline the related surveys on model-driven approaches for the design of blockchain-based applications. 2.1 Blockchains and smart contracts Blockchains are a family of technologies where transactions between authorized parties are stored in an electronic dis- tributed ledger in a decentralized, distributed, immutable, and transparent way [93]. This is achieved through so-called consensus algorithms that guarantee the validity and integrity of transactions. The term “blockchain” stems from the form of the data structure of the ledger: a cryptographically linked chain of blocks containing records of transactions. The access to the ledger may either be restricted to certain parties (per- missioned blockchain) or it may be openly accessible (public blockchain). Blockchain-based applications then rely on this technol- ogy for its security and integrity properties, as financial channel, or to benefit from an established distributed infras- tructure, e.g., by using a public blockchain. Furthermore, some blockchains allow applications to employ so-called smart contracts, pieces of code added to transactions for the decentralized execution of algorithms [12]. 2.2 Related surveys Developing blockchain-based applications requires a high level of expertise and understanding of the underlying tech- nologies. Blockchain-based applications are empowered by smart contracts, i.e., programs executed on the blockchain. These smart contracts often involve financial transactions or deal with issues related to trust. As such, their correctness is of utmost importance. Due to the immutable nature of blockchains, mistakes in smart contract implementations are difficult to rectify. Many works from different fields in com- puter science investigate these issues and numerous surveys 123 Design of blockchain-based applications using MDE and low-code/no-code 1859 Table 1 Selected surveys on (i) smart contract formalization, veri- fication, engineering, and languages; (ii) blockchain-based business process management, and (iii) MDE techniques for the development of blockchain applications. These surveys have been considered in the review process as well. References Title Ait Hsain et al. [3] Ethereum’s smart contracts construction and development using model driven engineering technologies: a review Alam et al. [4] Blockchain domain-specific languages: survey, classification, and comparison Almakhour et al. [6] Verification of smart contracts: a survey Dwivedi et al. [81] Legally enforceable smart-contract languages: a systematic literature review Fahmideh et al. [85] Engineering blockchain based software systems: foundations, survey, and future directions García-García et al. [103] Using blockchain to improve collaborative business process management: systematic literature review Grishchenko et al. [108] Foundations and tools for the static analysis of ethereum smart contracts Härer and Fill [122] A comparison of approaches for visualizing blockchains and smart contracts Hu et al. [133] A comprehensive survey on smart contract construction and execution: paradigms, tools, and systems Levasseur et al. [152] Survey of model-driven engineering techniques for blockchain-based applications Liu et al. [157] A survey on security verification of blockchain smart contracts Pinna et al. [202] On the use of petri nets in smart contracts modeling, generation and verification Sánchez-Gómez et al. [215] Model-based software design and testing in blockchain smart contracts: a systematic literature review Singh et al. [224] Blockchain smart contracts formalization: approaches and challenges to address vulnerabilities Tolmach et al. [246] A survey of smart contract formal specification and verification Udokwu et al. [254] Evaluation of approaches for designing and developing decentralized applications on blockchain Varela-Vaca et al. [257] Smart contract languages: a multivocal mapping study were conducted from different perspectives. Table1 provides an overview of some related surveys, collected during the review process as elaborated in Sect. 4.1. Most surveys focus on issues related to the development and analysis of smart contracts, while few regard blockchain applications as a broader topic. A general survey on various aspects of smart contract development and execution is pre- sented in [133]. This includes a reviewof tools and techniques for the analysis and verification of smart contracts, e.g., to detect vulnerabilities, design patterns, smart contract lan- guages, and execution schemes. While various issues related to software engineering are discussed, model-driven or low- code techniques to develop blockchain-based software are not regarded. The surveys [4, 81, 122, 257] review smart contract languages, including some of the work presented in this paper, but do not focus on MDE or low-code approaches specifically. While visual programming languages aim to reduce complexity and improve accessibility for the pro- grammer, they do not correspond in general to low-code development approaches, which may involve visual pro- gramming but also deal with the generation and life-cycle management of software artifacts. Blockchain-based approaches in the field of business pro- cess management have been reviewed in [103] with a particular focus on collaborations. While approaches from this field are oftentimes not directly concerned with MDE, the model-based execution of business processes, workflows and choreographies is a central issue. Formal specification and verification techniques for smart contracts is an actively researched field with numerous sur- veys [6, 108, 157, 202, 224]. This field is concerned with the detection or prevention of security vulnerabilities and faults, code optimization, formalization of semantics, and the correctness of smart contract implementations. Some approaches of this field employ MDE techniques, e.g., the generation of code from models. A general survey on software engineering approaches for blockchain applications is presented in [85], including some that applyMDE techniques.However, a comprehensive overview of MDE is not in the scope of this former survey. The surveys [3, 152, 215, 254] review MDE approaches in particular. In [3] the authors discuss MDE specifically for Ethereum smart contracts, however, the review process is not elaborated. Sánchez-Gómez et al. [215] review model- based testing and development approaches and Udokuwu 123 1860 S. Curty et al. Collect review requirements Define research questions Define search protocols Search for academic literature Search for industrial solutions Analyze relevant approaches Report results Fig. 1 Overall process for this study. Since the data sources for aca- demic and industrial approaches differ significantly, two separate search protocols were formulated. The protocols were executed in parallel and isolated et al. [254] focus on the evaluation of software devel- opment processes. Since the publication of these surveys in 2020, newer approaches have emerged. A more recent review of MDE methods was conducted by Levasseur et al. [152] in 2021. In comparison to their work, we applied a broader searchmethodology and identifiedmore approaches. None of these studies considers industrial approaches such as low-code platforms and they focus predominantly on blockchain-based application development. In summary, while numerous studies on issues regard- ing smart contract development have been conducted, to the best of our knowledge, a comprehensive review of the state-of-the-art of MDE and low-code approaches from both academia and industry in this field is missing so far. 3 Researchmethodology For answering the four research questions we will employ the following researchmethodology.At first,we reviewexist- ing academic MDE approaches for blockchain applications in the form of a structured literature review (SLR), followed by a content-based computational analysis of the resulting full text documents using topic modeling [54] and a review of state-of-the-art industrial low-code and no-code software platforms (Fig. 1). The review of MDE approaches is two-fold. Relevant papers were manually retrieved through the structured litera- ture review at first, including the identification of categories and topics. In addition, topics were then identified using a content-based computational analysis for the resulting papers based on their full texts. Both resultswere finally combined in a manual rating and assessment process. In this way, the val- idation of the manually compiled and computational results is ensured. In particular, the SLR involved manual retrieval and paper screenings by the authors for identifying rele- vant papers and topics. Regarding the process, we follow the guidelines by Webster and Watson [264] and vom Brocke et al. [260]. The initial corpus of the SLR was generated by searching all keyword combinations from two groups, where group one included ‘blockchain, distributed ledger, smart contract’ and group two ’enterprise model, conceptual model, business model, model-driven, no-code, low-code’. These keywords were selected based on the domain under- standing of the authors. We expected the relevant concepts to be dispersed, thus we chose a broad set of keywords. Subsequently, the topics were identified in a computa- tional analysis in multiple iterations by applying Latent Dirichlet Allocation (LDA) [54]. The final synthesis of the resulting papers and their topics follows the processes applied by Casalaro et al. [49] for the synthesis and Torres et al. [49, 248] regarding the rating and qualitative assessment through inter-rater reliability measures. For discovering relevant industrial low-code and no-code software platforms, we reverted further to expert knowledge from industry in the field of low-code development combined with our own searches. On this basis, we conducted a sur- vey of available platforms towards suitability for blockchain application development, and identified according character- istics, application areas, and categories.Wediscuss platforms in each category together with representative examples for assessing the state-of-the-art in implemented industry software solutions. This exploratory research approach is directed towards discovering requirements for future plat- forms that combine blockchain application developmentwith the state-of-the-art from academia and industry. 4 Academic MDE approaches In the following subsections, we review approaches of the academic discipline model-driven engineering in regard to development solutions for blockchains. 123 Design of blockchain-based applications using MDE and low-code/no-code 1861 ACM Springer IEEE Xplore (S-1) Keyword searches 3056 2666(S-2) Duplicate removal 94(S-3) Title screening 44 (S-5) Backward/Forward search (S-8) Remove surveys 200(S-7) Remove published preprints 194177 (S-6) Pass assessment 3228 (total) (S-5.1) Screen references and citations by title 504 (total) (S-4) Pass assessment (S-5.2) Paper assessment Final corpus LDA corpus Fig. 2 Systematic review process for the identification of academic MDE-related documents. A keyword search was performed on the por- tals ACM, IEEE Xplore, and Springer. This corpus was filtered by title and then subject to an assessment regarding the documents’ full-texts. Subsequently, a recursive backward-forward search was performed, resulting in a set of 200 relevant documents. Further, any surveys and preprints that have a published version were removed. This final set was then used for a content-based analysis using LDA Model-driven engineering introduces models as primary artifact to the software development process in order to address numerous challenges of software engineering [42, 218]: First, the common understanding of software artifacts can be facilitated by domain-specific models, as such models are easier to interpret for humans than code. Second, model- based reasoning allows the verification of software, e.g., to determine the fulfillment of security properties. And third, well-defined models allow developers to create software artifacts in an automated fashion, which are correct-by- construction, with no or reduced coding effort. To identify existingMDEapproaches that target specifically the develop- ment of blockchain applications, we conducted a systematic literature review as elaborated in the following. 4.1 Review process The systematic review process as shown in Fig. 2 follows the guidelines by Webster and Watson [264] and vom Brocke et al. [260]. To obtain an initial corpus of documents, we per- formed keyword searches in step (S-1) on ACM, Springer, and IEEE Xplore with the search strings shown in Table2. These publishers were chosen as starting point as we had access to the full-texts on their platforms. Moreover, estab- lished outlets of the modeling domain are mostly published on these platforms [123]. The steps (S-5.1) and (S-5.2) ensured that outlets from other publishers are considered as well. In total, the review covers 2173 outlets—a wide array of conferences, consortia, forums, journals, magazines, symposia, and workshops. The search strings are informed by previous studies in this area, namely [67, 123]. In the pre-study [67] we had found that restricting the search cri- teria on terms closely related to model-driven and low-code approaches does not cover fields we deem relevant nonethe- less. This is oftentimes due to differences in the terminology used. Thus, we widened the search with the addition of terms related to models of a specific nature. The study in [123] had shown that the precise meaning assigned to the terms “mod- eling” or “model” is contextual and varies across fields of study. We thus restricted the search terms to account for the broad use of these keywords. Thereby, the term “business modeling” is largely motivated by approaches in the field of value and goal modeling, the term “conceptual modeling” by domain models and ontologies used during any stage of soft- ware development, and lastly the term “enterprise modeling” by the field of enterprise architectures. From this initial corpus of documents, duplicates were removed in step (S-2). Before the full-text analysis, the reduced corpus was then screened by titles in step (S-3). As basis for this third step we formulated loose keyword 123 1862 S. Curty et al. Table 2 The five search strings (in a simplified form) used for retriev- ing the initial corpus, and the number of results found on ACM, IEEE Xplore, and Springer. The exact syntax of search strings varies for each search portal. The search period for academic approaches was restricted to publications between 2014 and July 2022 Search string # results (“blockchain” OR “distributed ledger” OR “smart contract” OR “smart-contract”) AND (“business model” OR “business modeling”) AND (year>2014) 2150 (“blockchain” OR “distributed ledger” OR “smart contract” OR “smart-contract”) AND (“conceptual model” OR ”conceptual modeling”) AND (year>2014) 507 (“blockchain” OR “distributed ledger” OR “smart contract” OR “smart-contract”) AND (“model driven” OR “model-driven”) AND (year>2014) 235 (“blockchain” OR “distributed ledger” OR “smart contract” OR “smart-contract”) AND (“no code” OR “no-code” OR “low code” OR “low-code”) AND (year>2014) 114 (“blockchain” OR “distributed ledger” OR “smart contract” OR “smart-contract”) AND (“enterprise model” OR “enterprise modeling”) AND (year>2014) 50 criteria, whereby the title should contain a term related to a model or the activity of modeling, andmention a blockchain- related word, such as “distributed”, “chain”, or “contract”. Non-exhaustive examples of satisfying the former criteria include thementioning ofmodeling languages,model-driven practices, conceptualizations, structured knowledge repre- sentations, and domains known for applying MDE practices. Excluded were documents with titles indicating the discus- sion of a business model for a particular use case, since these occurred in abundance but do not in general relate to MDE. The title screening in step (S-3) was performed by all authors in isolation, whereby each author noted whether or not a publication seemed relevant and refined the assessment in a second pass. For documents without full agreement by all authors, consensus was established through a discussion. In the next step, the documents were assessed by at least reading the abstract and reviewing tables and images (S- 4), considering the inclusion criteria that (i) the documents should be related to distributed ledger technologies, and (ii) create, discuss, or present a modeling activity. Publi- cations using models to only illustrate software, systems, or a use case, e.g., by means of a standard UML use case diagram, were excluded. For documents that passed the aforementioned assessment we then extracted dimensions for comparison by reading the full-texts. The dimensions are presented in 4.2. For these 44 documents, we then performed a recur- sive backward-forward search (S-5), as proposed in [262]: references and citations were screened by title, relevant pub- lications added to the set (S-5.1), and subsequently assessed (S-5.2). Step (S-5.2) was performed in the same manner as step (S-4). Surveys and versions of already captured documents, namely preprints or published versions thereof, were first considered as well. For all relevant new additions, a backward-forward search was again performed. Eventu- ally, no new relevant documents could be found, and the backward-forward search was concluded. Of all thus col- lected documents, 200 fulfilled the assessment of being in the scope of the literature study by reading the full-texts of the papers (S-6). We further removed preprints for which a published version is contained in the corpus (S-7). The result- ing corpus served as basis for a content-based analysis using LDA. Finally, surveys were removed in step (S-8), resulting in the set of documents presented in the following. This was done since these surveys were considered secondary studies and do not present an original approach, but rather focus on the synthesis of previous approaches. 4.2 Results of the literature review process Through the SLR we identified 177 academic publications relevant in the context ofMDE for blockchain-based applica- tions. A discussion of the academic approaches is presented in Sect. 6. Each publication was subject to a classification based on three dimensions. The choice of these particular dimensions is informed by a pre-study [67]. Base language: This dimension refers to the model- ing language that was applied in the approach or used as foundation for an extension, for example, in the form of a profile or through an addition of domain-specific concepts. Some approaches do not revert to such a base language. Instead, they propose a tailor-made method for modeling some aspect of a blockchain system. We therefore refer to any such method as a domain-specific language (dsl). This domain-specificity is to be understood in the context of the development and modeling of blockchain-based applica- 123 Design of blockchain-based applications using MDE and low-code/no-code 1863 Fig. 3 Treemap of the identified modeling languages, that have been employed by academic approaches—approaches may use or propose multiple languages, resulting in a total of 232 assignments. The area of a rectangle represents the number of approaches using this language: domain-specific language (dsl, 74), BPMN (51), UML (38), Petri Net (10), DEMO (9), OWL (8), ArchiMate (4), DMN (4), i* (4), REA (3), AOM (3), RDF (3), e3 value (3) RuleML (3), ER (2), SCXML (2), SWRL (2), BPEL (1), CMMN (1), DatalogMTL (DMTL, 1), IFML (1), OCL (1), EER (1), SOM (1), TOVE (1), and USDL (1) tions. Furthermore, we did not distinguish between different versions of languages. Blockchain technology: This dimension is defined as the base blockchain technology relevant for the approach. That is, the technology that the approach either applies, analyzes or, targets. For approaches of a conceptual nature that do not specify a technology, or for which considering such specifics is not relevant, we denote the blockchain tech- nology to be unspecified. Some approaches target multiple blockchain systems, for which we assign the value multiple. The use of programming languages compiled to bytecode for Ethereum’s virtual machine [272] is regarded as using the Ethereum blockchain technology, regardless of the exis- tence of other blockchains compatible with such bytecode. An implementation of non-established blockchain systems is denoted as custom. We did not distinguish between devel- opments under an overarching umbrella, namely the various Hyperledger projects. Furthermore, the distinction between permissioned and permissionless networks is not considered, since this is generally an issue of system and network con- figuration. Nature of realization:We distinguish between executable code generating and conceptual approaches. The former refers to an approach that automatically or partially automat- ically generates code artifacts from some model representa- tion. These artifacts must be executable using a blockchain technology. Such artifacts include but are not limited to smart contracts, blockchain connectors, integration facilities, user-interface components for blockchain applications and process or workflow encodings. We denote those approaches as conceptual that do not satisfy the code generation criterion, but instead focus on the conceptualization of the blockchain domain, resulting in a model representation, reasoning on blockchain systems based on models, conceptual language mappings or model- based methodologies for the design and development of blockchain applications. Conceptual artifacts produced by such approaches include but are not limited to ontologies, metamodels, methodologies, semantic models, and business models. 4.2.1 Employed modeling languages The academic approaches at hand may use or propose one or several modeling languages. These have been identified according to the previously definedbase languagedimension. In this section we present the modeling languages ordered by the number of occurrences (totaling in n = 232) in terms of the number of applications in academic approaches (c.f. Fig. 3). In total, we have identified 25 base languages, most of which are only sparingly used for the development of blockchain-based applications. In the following, the lan- guages and their primary function in the context of DLT are briefly summarized,while a discussion of the approacheswill follow in Sect. 6. Domain-specific language (dsl): Papers proposing or applying a domain-specific language for the blockchain domain form the largest group with 74 representatives (out of 232). This group is notably heterogeneous, ranging from declarative (e.g., [125, 149, 207]) to graphical (e.g., [31, 39, 123 1864 S. Curty et al. 265]) modeling approaches with a varying degree of formal- ization. Some approaches combine a dslwith non-blockchain specific modeling languages, for example for the model- based generation of smart contract code (e.g., [128, 256]). Business process model and notation (BPMN) [238]: With 51 occurrences BPMN is the most widely employed standard modeling language in the corpus of documents. In the context of blockchain-based applications, BPMN has been applied, for example, to execute business processes on-chain, based on smart contracts (e.g., [159]), or for the collaborative execution and enforcement of choreographies (e.g., [146]). Unified modeling language (UML) [241]: UML is the secondmost prominent modeling language after BPMNwith 38 representatives. This group accounts for all types of UML diagrams, although UML class diagrams are the most widely used by the approaches at hand. Approaches reverting to UML include development methodologies (e.g., [168]), con- ceptual modeling and ontology design (e.g., [70, 194]), as well as model-based code generation (e.g., [113]). Petri Nets [199, 200]: Petri Nets (n = 10) allow for the description of concurrent processes in distributed sys- tems. Thereby, system states and transitions between these aremodeledwith a formalized diagrammatic notation.Appli- cations of Petri Nets in the context of blockchain technology include, for example, the formalization of ontologies (e.g., [78]), smart contract simulation and verification (e.g., [277]) and the encoding of business processes for execution engines (e.g., [102]). Design and engineering methodology for organizations (DEMO) [74, 75]: DEMO (n = 9) is a methodology with an ontological foundation for the design (and re-design) of orga- nizations. A main concern of DEMO is the separation of the abstract representation of an organization’s operation from its realization [74]. These essential features are described by means of four diagrammatic models. The approaches at hand applyDEMO, or parts thereof, for various purposes. For example, the generation of code (e.g., [226]), and the use as ontological foundation (e.g., [70]). Of particular interest as well is the actor transaction diagram of DEMO (e.g., [223]). Web ontology language (OWL) [261]: OWL (n = 8) is an ontology language for the semantic web with formally defined semantics. An OWL ontology may be represented in various ways, for example, as an RDF graph (see description below), which is the main exchange syntax of an OWL doc- ument, or with an UML class diagram. Several academic approaches express DLT-related domain models in OWL (e.g., [26, 28]). The formalized semantics of OWL allow for the application of formal reasoning mechanisms in order to gain new insights, in particular in combination with query and rule languages (e.g., [29]). ArchiMate [151, 244]: ArchiMate (n = 4) is a multi- layered enterprise architecture modeling language. The lay- ers represent various aspects of an enterprise, ranging from strategy and business concerns to the technical infrastruc- ture. Academic approaches employ ArchiMate to model blockchain systems and the interrelationswith businessmod- els (e.g., [66, 135]), for the creation of reference models (e.g., [82]), and as input for the generation of software artifacts based on a concept mapping (e.g., [19]). The appli- cation and technology layers of ArchiMate are considered, for example, in [66], while other approaches may regard mainly the top-level layers (e.g., strategy [135] or business layer [82]). Decision model and notation (DMN) [243]: DMN (n = 4) is a business decision modeling language, designed to be usable as complementary modeling method along- side BPMN, thereby allowing the decisions to be inte- grated in business processes. The combination of DMN and blockchain technologies was explored for example for the purpose of executing decision models on-chain, as seen in [115–117], or for supporting decision making as part of a development methodology [192]. i* strategic actor relationships modeling framework (i*) [274–276]: The i* framework (n = 4) is a graphical modelingmethodwhere information systems are regarded as socio-technical systems inwhich actors are related to another in regards to goals, tasks and resources. This framework has been discussed, e.g., for requirements engineering and goal modeling for supporting the development of decentralized applications in an organizational setting [118, 258, 259], and for the policy compliant generation of smart contract code [252]. Agent-oriented Modeling (AOM) [230]: AOM (n = 3) is a methodology for modeling socio-technical systems. Thereby, an information system is represented by interac- tions among autonomous agents. Several works regard AOM as integral part of some developmentmethodology for decen- tralized applications, e.g., [153, 253, 255]. e3value [107]: The e3 value language (n = 3) provides a notation to model value streams between actors. It is thus mostly used to explore business models and use cases with a focus on value exchanges. The usage in the context of blockchains is two-fold: either employed as part of a smart contract development methodology (e.g., [105]) or for use case modeling and analysis. In the latter case, the main con- cern is, e.g., the identification of DLT use cases [203] or the modeling thereof [198]. Resource–Event–Agent (REA) [175]: The REA model (n = 3) provides a general business ontology and model- ing notation for expressing economic resources, economic events, and economic agents and their relations. It has ini- tially been proposed as an accounting framework for shared data environments with a data modeling notation resem- bling the Entity-Relationship model. The business ontology 123 Design of blockchain-based applications using MDE and low-code/no-code 1865 of REA is used in combination with DEMO, e.g., in [69, 70] for the development of blockchain domain ontologies. Resource description framework (RDF) [124]: The RDF standard (n = 3) provides a notation for the exchange and description of graph data. Thereby, a graph is represented as collection of triple statements. While RDF was origi- nally intended as description language for metadata in the semantic web, it has found more general use since then, e.g., for modeling and exchanging ontologies. For example, blockchain-related ontologies have been expressed in RDF, as seen in [10, 201, 220]. Rule markup and modeling language (RuleML) [212]: RuleML (n = 3) is a standard for the semantic web based on RDF and XML for the specification of rules and constraints regarding the transformation and semantic interpretation of data. Several other markup languages have been developed based on RuleML, e.g., SWRL. Approaches at hand apply RuleML, for example, for the verification of DApps in regard to compliance rules [256]. An extended version of RuleML is proposed as a declarative smart contract language [71, 72]. Entity-relationshipmodel (ER) [52]: TheERmodel (n = 2) has originally been proposed for the design of database models, but is commonly used for general data modeling tasks as well. It has been suggested to revert to ER for the design of the data domain model as part of the blockchain application development methods presented in [100, 208]. State chart extensible markup language (SCXML) [25]: SCXML (n = 2) is a W3C standard for the declara- tion of state machines in an XML format. While numerous approaches at hand involve state machines, only two revert to this standard [185, 216]. In these works, SCXML is used as input format for a blockchain-based engine, with the purpose of executing smart contracts modeled as state machines. Semantic web rule language (SWRL) [132]: The W3C standard SWRL (n = 2) is a combination of OWL and RuleML, expanding the expressiveness of OWL with the capability of formulating constraints or rules on ontologi- cal concepts. Together with ontologies formalized in OWL, SWRL enables deductive reasoning and knowledge infer- ence. This has been used, e.g., in [29] for gaining insights in DApps modeled according to an ontology. Another approach uses the combination of domain ontologies and SWRL expressions as a starting point for the generation of contract code [53]. Business process execution language (BPEL) [193]: The declarative XML-based Business Process Execution Lan- guage (BPEL or WS-BPEL, n = 1) is a standard for the specification of executable processes. It relies upon the Web Service Description Standard for service specification and discovery, but adds capabilities for the description of inter- actions among business processes and web services. Thus, BPEL allows for the description of workflows orchestrating service invocations as seen, for example, in [48], where a BPEL process is translated into a smart contract which calls external web services. Case management model and notation (CMMN) [242]: CMMN (n = 1) is a business process modeling method designed to be complementary to BPMN. As opposed to BPMN, which describes a process as a predefined sequence of activities, CMMN regards a subject in a situation where actions to be taken may need to be chosen and ordered dur- ing run-time. CMMN is used, e.g., in [179] for the modeling of common blockchain application patterns, such as oracles and tokenization. DatalogMTL (DMTL) [43]: Datalog is a logic program- ming language. Its applications include ontology representa- tion and querying deductive systems. DatalogMTL (n = 1) is an extension introducing concepts of metric temporal logic, allowing expression on temporal data. An example for the application of DatalogMTL is the work of Nissl et al. [190], where logic-based smart contracts modeled with DatalogMTL were translated into code executable by Ethereum’s virtual machine [272]. Extended entity-relationship model (EER) [104]: The EER model (n = 1) includes all concepts of ER, but incor- porates several extensions, such as inheritance concepts, clustering of entity types, and complex attributes. EER is used, e.g., in [129] for the representation of anOWLontology of the block and transaction structure as present in Bitcoin, Ethereum, and Hyperleder Fabric. Interaction flow modeling language (IFML) [240]: The IFML standard (n = 1) offers notations tomodel interactions of users with front-end applications and the related behav- ior triggered by user actions or system events. In [100], the authors apply IFML as part of an MDDmethod for so-called hybrid applications, that involve a DLT system as well as a centralized database. The interactive system component is modeled with IFML. Furthermore, an extension of IFML is used to model workflows. Object constraint language (OCL) [239] The formal and declarative Object Constraint Language (n = 1) allows to specify expressions on UML models. This includes, for example, the definition of queries, invariants, and condi- tions on operations. The work of Syahputra et al. [235] presents a development method for smart contracts involving REA, UML and OCL. The UMLmodels enriched with OCL expressions serve as input for the generation of code. Semantic object model (SOM) [90]: The semantic object model (n = 1) is an object- and process-oriented model- ing method for enterprises. In SOM, a business system is represented on the levels of the enterprise plan, business pro- cesses, and resources, especially IT systems. In contrast to ArchiMate or BPMN, SOM describes processes and IT sys- tems in a structural as well as a behavioral view and derives IT systems in their specification by a model-driven method- 123 1866 S. Curty et al. ology. Härer [121] applied SOM in conjunction with BPMN for modeling decentralized organizations. Toronto virtual enterprise ontology (TOVE) [96]: TOVE (n = 1) is a formal ontology with a layered structure, con- taining sub-ontologies for the modeling of various parts of an enterprise, such as activities, products, or organizational structure [97]. Kim et al. [141] adapted TOVE for prove- nance tracking in supply chain applications. The extended ontology then serves as the foundation for the development of smart contracts. Unified service description language (USDL) [47]:USDL (n = 1) provides means for the description of web services and their relation to underlying business services. Thereby, USDL reverts to an XML-based syntax and includes an extension mechanism. This has been used, e.g., in [27] to adopt USDL for the description of smart contract functional- ity, aiming to increase the user’s trust in contracts for which the implementation is not public. 4.2.2 Employed blockchain technologies We have identified seven blockchain technologies that have been regarded by academic approaches. In this work, we do not differentiate between the various Hyperleder projects, and instead group them together. An overview on the pop- ularity of the employed blockchain technologies is shown in Fig. 4. By far the most popular technology is Ethereum (n = 99), a general purpose blockchain with the capability of executing turing-complete smart contract in a decentralized virtual machine [272]. Numerous approaches did not spec- ify a blockchain technology (n = 39). This is exclusively the case for conceptual works that are technology inde- pendent. Further, we have found approaches that consider multiple blockchains (n = 16). This includes some concep- tual works, but more common are multi-chain approaches focusing on the technical level. The second most popular choice is then one of the infrastructure blockchain tech- nologies developed under the umbrella of the Hyperledger project [134] (n = 15). These are typically less focused on crypto-economic aspects than general-purpose blockchains, but instead are tailored towards consortial settings, where the cooperation of organizations is enabled through a collec- tively established blockchain as trust-basis. Hyperledger is followed by another two general purpose blockchain tech- nologies in this ranking, namely Corda [127] (n = 4) and Cardano [46] (n = 2). Only one approach employs Bit- coin [184]. This lowadoptionmaybe explainedby the limited smart contract capabilities of the Bitcoin technology. Since blockchain technologies were not an area of active research prior to 2014, this review covers publications from 2014 onward. The research activity has risen considerably since then, as is evident by the increase of publications over the years, shown in Fig. 5. Fig. 4 Employed blockchain technologies of the approaches in the final corpus. Ethereum is by far the most popular choice in this set. However, numerous conceptual approaches do not rely on a specific blockchain technology 0 10 20 30 40 50 60 2014 2016 2017 2018 2019 2020 2021 2022 Published documents Fig. 5 Number of documents in the final corpus grouped by year. This includes preprints but no surveys. Note that the review does not cover the entirety of 2022 4.2.3 Nature of realization All documents in the final corpus have been grouped by their realization, that is, in conceptual and executable code gen- erating. Conceptual approaches: Documents presenting concep- tual approaches are shown in Table3. Most commonly, these conceptual approaches do not relate to a specific blockchain technology (n = 39). This is not surprising, as conceptual works generally allow for a higher degree of abstraction. However, some approaches are technology-specific. In these cases, Ethereum is the most popular blockchain technol- ogy (n = 17), followed by Hyperledger (n = 5), Corda (n = 1), and Bitcoin (n = 1). UML is the most prominently employed modeling language in this group (n = 25), e.g., as part of a methodology or for the design of metamodels. 123 Design of blockchain-based applications using MDE and low-code/no-code 1867 Table 3 Publications proposing a conceptual method for the design of blockchain applications, or reasoning thereof. That is, the method does not automatically generate code artifacts executable in the con- text of a specific blockchain technology. Instead, such approaches may focus on the conceptualization of the blockchain domain, resulting in a model representation, reasoning on blockchain systems based on models, conceptual languagemappings, or model-basedmethodologies for the design and development of blockchain applications. Concep- tual artifacts include but are not limited to ontologies, metamodels, methodologies, semantic models, business models, and model-based verification and simulation without code generation Base language BT References Base language BT References AOM u LiBin et al. [153] dsl, OWL, UML ETH Dwivedi et al. [80] AOM u Udokwu et al. [253] e3 value u Perrelet et al. [198] AOM, UML u Udokwu et al. [255] e3 value u Poels et al. [203] ArchiMate m Curty et al. [66] EER, OWL m Hector et al. [129]‡ ArchiMate u Jiang et al. [135] i* u Hamadi et al. [118] ArchiMate, BPMN, UML m Ellervee et al. [82] i*, UML u Vingerhoets et al. [258] BPMN HL Panduwinata et al. [196] i*, UML u Vingerhouts et al. [259] BPMN, CMMN u Milani et al. [179] OWL ETH Bella et al. [26] BPMN, DEMO HL Guerreiro et al. [114] OWL u Scrocca et al. [219]‡ BPMN, DMN ETH Nousias et al. [192] OWL, RDF, UML u Amato et al. [10] BPMN, dsl, Petri Net HL Dittmann et al. [77] OWL, SWRL ETH Besançon et al. [29] BPMN, e3 value ETH Gómez et al. [105] OWL, SWRL u Choudhury et al. [53] BPMN, ER, UML u Rocha et al. [208] Petri Net ETH He [126] BPMN, OWL u Besançon et al. [28] Petri Net, UML u Dwivedi et al. [78] DEMO ETH Aparício et al. [13] Petri Net, UML u Kherbouche et al. [140] DEMO ETH Aparício et al. [14] Petri Net, UML u Ladleif et al. [144] DEMO, REA, UML u de Kruijff et al. [69] RDF ETH Petrović et al. [201] DEMO, REA, UML u de Kruijff et al. [70] RDF u Seebacher et al. [220] DEMO, UML HL Silva et al. [223] RuleML u de Kruijff et al. [71] dsl BC Andrychowicz et al. [11] RuleML u de Kruijff et al. [72] dsl HL Bollen [37] TOVE ETH Kim et al. [141] dsl m Six et al. [225] UML CO Górski et al. [110] dsl u Amaral de Sousa et al. [8] UML ETH Cano-Benito et al. [44] dsl u Amaral de Sousa et al. [9] UML ETH Lallai et al. [147] dsl u Bai et al. [22] UML ETH Marchesi et al. [168] dsl u Barisic et al. [24] UML ETH Marchesi et al. [170] dsl u Conchon et al. [58] UML ETH Olivé [194] dsl u He et al. [125] UML ETH Teruel et al. [237] dsl u Park et al. [197] UML u Górski [109] dsl u Purnell et al. [204] UML u Jurgelaitis et al. [138] dsl u Regnath et al. [207] UML u Roussille et al. [211] dsl u Shi et al. [222] UML u Sánchez-Gómez et al. [214] dsl u Tsai et al. [251] UML, USDL ETH Ben Slama Souei et al. [27] AOM agent-oriented model, BPMN business process model and notation, CMMN case management model and notation, DEMO design and engineering methodology for organizations, DMN decision model and notation, ER entity-relationship, EER extended ER, OWL web ontology language, RDF resource description framework, TOVE Toronto virtual enterprise ontology,UML unified modeling language,USDL unified service description language, dsl domain-specific language,BT blockchain technology,ETH Ethereum,CACardano,COCorda,HLHyperledger, c custom, m multiple, u unspecified ‡Preprint or technical report 123 1868 S. Curty et al. Table 4 Publications proposing an executable code generatingmethod. That is, the method automatically or partially automatically generates code artifacts from somemodel representation, and the artifacts are exe- cutable in the context of a specific blockchain technology. Such artifacts include but are not limited to smart contracts, blockchain connectors, integration facilities, UI components for blockchain applications, and process or workflow encodings Base language BT References Base language BT References ArchiMate, DEMO HL Babkin et al. [19] dsl ETH Bistarelli et al. [33] BPEL ETH Carminati et al. [48] dsl ETH Boubeta-Puig et al. [39] BPMN ETH Abid et al. [2] dsl ETH Boychenko et al. [40] BPMN ETH Azzopardi et al. [18] dsl ETH Chen et al. [51] BPMN ETH Bagozi et al. [20] dsl ETH Dharanikota et al. [73] BPMN ETH Brahem et al. [41] dsl ETH Dwivedi et al. [79] BPMN ETH Corneli et al. [59] dsl ETH Frantz et al. [98] BPMN ETH Corneli et al. [60] dsl ETH Franz et al. [99] BPMN ETH Corradini et al. [61] dsl ETH Henry et al. [130] BPMN ETH Corradini et al. [62] dsl ETH Kolb et al. [143] BPMN ETH Corradini et al. [64] dsl ETH Liu, C. et al. [154] BPMN ETH Corradini et al. [65] dsl ETH Liu, C. et al. [155] BPMN ETH Di Ciccio et al. [55] dsl ETH Liu, C. et al. [156] BPMN ETH Klinger et al. [142] dsl ETH Liu, Y. et al. [158] BPMN ETH Ladleif et al. [146] dsl ETH Madsen et al. [166] BPMN ETH López-Pintado et al. [159] dsl ETH Mao et al. [167] BPMN ETH López-Pintado et al. [160] dsl ETH Marchesi et al. [169] BPMN ETH López-Pintado et al. [162] dsl ETH Mavridou et al. [172] BPMN ETH Loukil et al. [164] dsl ETH Mavridou et al. [173] BPMN ETH Morales-Sandoval et al. [181] dsl ETH Mavridou et al. [174] BPMN ETH Schindelmann et al. [217] dsl ETH Meng et al. [177] BPMN ETH Spalazzi et al. [229] dsl ETH Nelaturu et al. [186] BPMN ETH Sturm et al. [232] dsl ETH Nelaturu et al. [187] BPMN ETH Sturm et al. [233] dsl ETH Rosa-Bilbao et al. [210] BPMN ETH Tonga Naha et al. [247] dsl ETH Sergey et al. [221]‡ BPMN ETH Tran et al. [249] dsl ETH Suvorov et al. [234]‡ BPMN ETH Weber et al. [263] dsl ETH Tan et al. [236] BPMN HL Alves et al. [7] dsl ETH Trebbau et al. [250] BPMN m Bagozi et al. [21] dsl ETH Weingärtner et al. [265] BPMN m Corradini et al. [63] dsl ETH Wickramarachchi et al. [267] BPMN m Falazi et al. [87] dsl ETH Wöhrer et al. [270] BPMN m Falazi et al. [88] dsl ETH Wöhrer et al. [271] BPMN m Ladleif et al. [145] dsl HL Astigarraga et al. [16] BPMN, DEMO, dsl ETH Skotnica et al. [227] dsl HL Bore et al. [38] BPMN, DEMO, dsl m Skotnica et al. [226] dsl HL Merlec et al. [178] BPMN, DMN ETH Haarmann et al. [116] dsl HL Mirković et al. [180] BPMN, dsl, Petri Net ETH López-Pintado et al. [161] dsl m Hamdaqa et al. [119] BPMN, dsl, Petri Net ETH López-Pintado et al. [163] dsl m Hamdaqa et al. [120] BPMN, dsl, UML ETH Skotnica et al. [228] dsl m Qasse et al. [205]‡ BPMN, Petri Net ETH García-Bañuelos et al. [102] dsl m Qasse et al. [206] BPMN, SCXML HL Nakamura et al. [185] dsl u Abbas et al. [1] BPMN, SOM ETH Härer [121] dsl, RuleML ETH van den Heuvel et al. [256] BPMN, UML ETH Lu et al. [165] dsl, UML m Heckel et al. [128] BPMN, UML ETH Sturm et al. [231] dsl, UML, SCXML HL Sato et al. [216] 123 Design of blockchain-based applications using MDE and low-code/no-code 1869 Table 4 continued Base language BT References Base language BT References DatalogMTL ETH Nissl et al. [190] ER, IFML, UML HL Fraternali et al. [100] DMN ETH Haarmann [115] i* ETH Tsiounis et al. [252] DMN ETH Haarmann et al. [117] OCL, REA, UML m Syahputra et al. [235] dsl CA Lamela Seijas et al. [148] Petri Net c Evermann et al. [84] dsl CA Lamela Seijas et al. [149] Petri Net ETH Zupan et al. [277] dsl ETH Allouche et al. [5] UML CO Górski et al. [111] dsl ETH Asawa et al. [15] UML CO Górski et al. [112] dsl ETH Azzopardi et al. [17] UML CO Górski et al. [113] dsl ETH Baresi et al. [23]‡ UML ETH Garamvölgyi et al. [101] dsl ETH Biryukov et al. [30] UML ETH Jurgelaitis et al. [137] dsl ETH Bistarelli et al. [31] UML HL Jurgelaitis et al. [139] dsl ETH Bistarelli et al. [32] BPEL business process execution language, BPMN business process model and notation,DEMO design and engineering methodology for organiza- tions, DMN decision model and notation, ER entity-relationship, IFML interaction flow modeling language, OCL object constraint language, REA resource-event-agent ontology, SCXML state chart extensible markup language, SOM semantic object model, UML unified modeling language, dsl domain-specific language,BT blockchain technology,ETH Ethereum,CACardano,COCorda,HLHyperledger, c custom,mmultiple, u unspecified ‡Preprint or technical report Some approaches propose or revert to domain-specific lan- guages (n = 16). This includes, for example, declarative legal languages, notations for state machines or automata, and non-standard specification languages. Semanticweb lan- guages, including OWL, RDF, SWRL, RuleM, and USDL (n = 13) are used for example to author domain ontologies. Executable code generating approaches: Documents presenting approaches with the capability of generating exe- cutable code are shown in Table4. The most used blockchain technology in this group is by far Ethereum (n = 82), followed by Hyperledger (n = 10), Corda (n = 3), and Cardano (n = 2). Twelve (n = 12) approaches support or tar- get multiple blockchains. This is achieved either by directly implementing the necessary code translation and connectors or by targeting an intermediary language that is compati- ble with multiple blockchain technologies, for example, the DAML language (c.f. Table6) as used in [119]. Most code generating approaches apply domain-specific languages for modeling (n = 58), ranging fromdeclarative textual to visual diagrammatic representations. In this group, BPMN is the most commonly used standard modeling language (n = 42), followed by UML (n = 13). 4.3 Content-based computational analysis In addition to the manual literature review we conducted a content-based computational analysis of the derived set of relevant papers. For this purpose we reverted to Latent Dirichlet Allocation (LDA), an established topic modeling approach for text summarization in the field of information retrieval [50].We follow the process of a computational anal- ysis based on LDA as established and successfully applied before in [123, 182, 195]. Topic modeling techniques have been developed since the 1990s stemming from Latent Semantic Indexing and similar approaches, leading to research onLDA in the 2000s [34, 35]. LDA introduced the identification of topics from a document collection by training a model of topic-word distributions, resulting in the generation of k topics consisting of word occurrences. Today, LDA with optimizations such as Gibbs sampling is considered an online topic modeling with high performance characteristics [54], in addition to graph-based, biterm, and self-aggregating methods as well as further run- time optimizations such as GPU acceleration [50, 54]. In particular, LDA allows for the generation of k topics for a document collection such that each document is character- ized by its own topic distribution θd , representing multiple topics per document in the underlying model. The model of topic-word distributions is trained through expectation maximization, maximizing the likelihood that the topic dis- tributions of each document θd,k form an overall topic-word distribution of k topics in the collection [34]. Furthermore, themodel is characterized by the ratio of topics per document (α) and the ratio of words per topic (β). As a result, each of the k topics is represented by the top n words according to the weight, corresponding to occurrences in the probabilis- tic model. In terms of software, the LDA implementation of MALLET (MAchine Learning for LanguagE Toolkit1) was used in RapidMiner 9.5 with optimizations for Gibbs sam- pling [188] and concurrent processing [273]. 1 http://mallet.cs.umass.edu/topics.php. 123 http://mallet.cs.umass.edu/topics.php 1870 S. Curty et al. Fig. 6 Final results of the computational analysis using LDAwith a set of 10 topics based on five terms and the final weights assigned by the algorithm. The final set of topics displayed here was then subjected to a manual refinement (see Sect. 4.4) over three iterations. These iterations consisted of the identification of topics, their assignment to papers by three raters, the calculation of inter-rater reliability measurements, joint discussions of the results involving manual screening of the papers in unclear cases We apply LDA as part of a data mining process, con- sisting of data selection, preprocessing, transformation, and data mining as suggested initially by the KDD model [89]. Data selection concluded with the full text PDF documents resulting from the literature review, including a small set of survey papers (c.f. Table1) and few relevant papers only published as report or on ArXiv (c.f. Tables3 and 4 marked with ‡) for generating an initial set of topics computationally through LDA. With this collection, preprocessing and trans- formation of the PDF documents to text documents followed. In preprocessing, data cleaning and related operations took place, in particular the tokenization of documents, minimal stemming, synonym replacement, cleaning for the removal of stop words, incomplete data, and irrelevant article fragments such as header texts or comments. The LDA was carried out over multiple iterations. In particular, for determining the initial k topics, iterations for k ∈ [6, 14] were calculated first, followed by defining domain-related stop words and synonyms. The results were evaluated manually by the authors with the criterion being to avoid overly generic or specific topics andwords, concluding with the selection of k = 10 topics. The topics that resulted from this initial application of LDA are shown in Fig. 6. 4.4 Manual topic refinement and synthesis by rating and qualitative assessment In a next step we refined the topics proposed by LDA, screened and assigned papers to the resulting topics man- ually over multiple iterations with inter-rater reliability measurements, leading to a synthesis of computationally and manually determined topics. The initial step consisted of identifying suitable labels for each topic in a joint discussion by the authors and the com- bination of similar topics. Given the topics, each subsequent iteration consisted of manually assigning papers to topics by three raters, the authors of this paper, the calculation of inter-rater reliability measurements, joint discussions of the results, and screenings of paper abstracts in unclear cases. The following inter-rater reliability indicator was measured as a qualitative assessment concerning the percentage agree- ment and Cohen’s Kappa [57, 176] over the assignments of n = 177 papers in the collection. (1) The unanimous agree- ment AU = 1/n ∗ ∑n i=1 ui where ui ∈ [0, 1] is the agreement for the assignment of paper i with ui = 1 if all raters made the same assignment and ui = 0 if assignments differed. (2) The mean agreement Aμ = 1/n ∗ ∑n i=1 vi/3 where vi ∈ [0, 3] is the number of raters in agreement for the topic assignment of paper i . (3) Cohen’s Kappa κ was calculated according to the procedure described by Cohen and McHugh [57, 176], accounting for agreements due to chance. In the first of three iterations, the initial assignment resulted in AU = 62.1% of the papers assigned to the same categories by all raters with a mean agreement Aμ = 72.5%, indicatingmoderate to high agreement below the threshold of Aμ = 75% that might be considered sufficient [191]. When accounting for chance with Cohen’s Kappa, κ = 0.60 was reached, considered slightly belowa substantial agreement at κ = 0.61 or above, according to Cohen and Landis et al. [57, 150]. In the joint discussion, papers not assigned to categories by at least two reviewers were identified first for discussing the scope and suitability of topics. This concerned 8 papers that were determined out of scope for the existing topics and assigned to the newly added topics Reference Models and Business Modeling. Secondly, under-represented or unclear 123 Design of blockchain-based applications using MDE and low-code/no-code 1871 Table 5 Final set of topics resulting from computational analysis (Sect. 4.3) and three iterations of manual refinement (Sect. 4.4). For each topic, the number of papers that were assigned to the topic with unanimous agreement by all raters is given. The inter-rater reliability measurements of unanimous agreement AU = 72.3%, mean agreement Aμ = 79.3%, and Kappa κ = 0.71 indicated very high agreement (see Sect. 4.4) Topic Number of assigned papers Process, workflow, choreography, and decision models 48 Application development 42 Formal aspects and verification 15 Legal aspects, rules, and languages 9 Ontology 7 UML modeling 5 Business modeling 4 Reference models 3 Supply chain 2 aspects for existing topics were discussed when raters had noted additional comments during the rating. This discussion revealed unclear assignments for papers on decision model- ing, which were considered part of a process-centered topic Process, Workflow, Choreography, DecisionModels as result of the discussion. Furthermore, formal verification papers were grouped with papers on further formal aspects, such as formal specification, in a topic Formal Aspects and Verifica- tion. In the second iteration, unanimous agreement AU = 72.3%, mean agreement Aμ = 79.3%, and Kappa κ = 0.71 were reached, indicating relatively high agreement on the assign- ment of topics and substantial agreement regarding κ . The joint discussion did not reveal topics unclear in scope or suit- ability, with all papers being assigned by at least two raters. Based on the rater’s comments, unclear aspects during the assignment led to marking related papers for an additional abstract screening as input for the last iteration. In the third iteration, after screening abstracts in 23 unclear cases, the final measurements indicate unanimous agreement AU = 76.3%, mean agreement Aμ = 83.1%, and Kappa κ = 0.75. At this point, agreement on topics among the raters was considered very high, even when accounting for agreement by chance through κ . Table5 shows the final set of topics with the number of papers assigned through unanimous agreement. The details of these topics will be discussed in Sect. 6 by highlighting the core papers found for each topic. 5 Industrial low-code and no-code software platforms In the following, we continue in our research methodology by reviewing state-of-the-art low-code and no-code software platforms towards their suitability for blockchain application development. The review process is described in Fig. 7. Low-code and no-code software platforms are increas- ingly available for practitioners to develop applications using abstractions beyond source code [36, 76]. While low-code Fig. 7 Systematic review process for the identification of industrial low-code and no-code software platforms supporting blockchain appli- cation development. The data sources consist of (DS-1), an existing compilation by Invernizzi and Tossell (see Sect. 5.1), (DS-2), prior work [122], and (DS-3), additional research on the web. After (S-1), an initial filter step leaving reachable and sufficiently described plat- forms, (S-2) assessed blockchain support, concluding in (S-3) and (S-4), where platforms were tested with small example implementations for classifying in (S-3) their blockchain capabilities and for determining application attributes (S-4) such as open source availability 123 1872 S. Curty et al. platforms are in their representation still close to the source code and often suited for technical users and developers, no-code platforms go one step further by providing repre- sentations on an abstraction level above source code that are accessible to non-technical domain experts and even cit- izen developers [209]. For example, low-code approaches might provide an interactive drag-and-drop environment for arranging blocks of statements in a procedural manner, while no-code approaches often guide users through dialogs and allow arranging pre-configured user interface (UI) compo- nents. Since many platforms are today web-based, their ease of use also stems from integrations, by connecting to existing cloud-services or websites and integrating their functional- ity [213]. 5.1 Review process Relying on expert knowledge, the review considers as a start- ing point an informal compilation by Invernizzi and Tossell2 that identified 145 web-based platforms such as website and app builders, e-commerce services, and data dashboards. The identified solutions differ substantially in the scope and appli- cations they target. We review solutions of the compilation, extended with approaches from prior research and addi- tional investigations of state-of-the-art platforms in October 2022. Therefore, the data sources for this review are (DS-1): the compilation by Invernizzi and Tossell, (DS-2): practical approaches from prior research [122], and (DS-3): additional research on blockchain-specific low-code and no-code solu- tions available on the web. We applied a four-step process, consisting of an initial fil- tering step (S-1), the evaluation of scope and applicability for blockchains in step (S-2), the classification of solutions appli- cable to blockchains (S-3), and the characterization through representation and application attributes (S-4). Initially, 179 solutions were identified. In (S-1), we manually retrieved descriptions from the vendor websites in addition to informa- tion provided by (DS-1), followed by filtering out duplicate entries, those that could not be reached on the web, or did not provide sufficient information on their websites (e.g. closed beta software). The remaining 150 solutions were evaluated in (S-2) regarding their scope of blockchain inte- gration. Finally, 47 solutions were identified as applicable for blockchains. For these platforms, further evaluations for assigning (S-3) categories and (S-4) the type of the predom- inant representation and application attributes were carried out. 2 https://pinver.medium.com/decoding-the-no-code-low-code- startup-universe-and-its-players-4b5e0221d58b. 5.2 Results For discussing available platforms and their blockchain inte- gration, we distinguish between 1st degree and 2nd degree integration. A platform supports 1st degree integration if it interacts directly with blockchains through its software or services. 2nd degree integration is supported if an external service could be integrated that offers 1st degree integra- tion. The criteria for the selected platforms (S-3) listed in Table6 are that they (a) offer blockchain integration of 1st or 2nd degree and (b) were considered a low-code or no- code approach. For (S-4), the table outlines the 9 categories identified in this step along with a description of applica- tion attributes, 1st and 2nd degree blockchain integration (columns d1 and d2), open source (column s) availability of the implementation, and the representation (column r) pri- marily used to abstract from source code. 5.2.1 Platforms with 1st degree integration 1st degree blockchain integration has been found in 18 solutions intended for building mobile apps, web apps and websites, workflow integration and automation, and smart contract development. App builders: The primary integration features in the categories for app builders, concerning platforms primar- ily for mobile applications (AM) or web applications (AW), are the creation of decentralized apps (DApps) and the integration of cryptocurrency-related data, e.g., price infor- mation. Platforms such as Outsystems (AW-6) and Bubble (AW-1) support DApps, where components of a mobile, desktop, or web app can send blockchain transactions and call smart contract functions, e.g., throughweb3 plugins such as the MetaMask browser extension.3 In the case of Outsys- tems, web3 functionality through MetaMask is available in pre-defined components provided as part of the platform’s integrated development environment (IDE). Following the web3 concept [45], apps or websites are created using decen- tralized platforms and infrastructures that depend less on large, centralized, and potentially influential entities such as cloud providers which could represent potential single points of failure. This might be achieved by blockchain transactions made through MetaMask or by decentralized data retrieved from Ethereum. An example for the development of a blockchain-based app for supply chain tracking is shown in Fig. 8 as demon- strated before by the authors in [67]. In this category, representations abstract from source code (column r) and often use flow-based editors. Elements connected by flow relationships specify, e.g., the navigation through user inter- faces, computational steps, or other actions carried out 3 https://metamask.io/. 123 https://pinver.medium.com/decoding-the-no-code-low-code-startup-universe-and-its-players-4b5e0221d58b https://pinver.medium.com/decoding-the-no-code-low-code-startup-universe-and-its-players-4b5e0221d58b https://metamask.io/ Design of blockchain-based applications using MDE and low-code/no-code 1873 Table 6 Industrial low- and no-code approaches with 1st or 2nd degree blockchain integration Cat-ID Name Website Description d1 d2 s r AM-1 Adalo adalo.com Apps and websites, creation of spreadsheets − + ◦ u AM-2 Axonator axanator.com Apps, additional workflows and dashboards − + − f AM-3 BuildFire buildfire.com Apps with e-commerce and industry-specific focus − + ◦ u AM-4 Glide gildeapps.com Apps, esp. data-centric apps with tabular data, BC temp + + − u AW-1 Bubble bubble.io Websites and cloud apps, small business focus, web3 plugins + + − u AW-2 Builder.ai builder.ai Websites and progressive web apps, BC temp + − − u AW-3 Draftbit draftbit.com Websites and apps, mobile use focus, industry-specific temp − + ◦ u AW-4 Landbot landbot.io Chatbot builder, specification using visual flows − + − u AW-5 Mendix mendix.com Complex apps, websites, cloud services, multi-view UI, IDE − + − f AW-6 Outsystems outsystems.com Complex apps, websites, cloud services, multi-view UI, IDE, web3 + − − f D-1 Levity levity.ai Predictive analytics for documents, images, text − + − f D-2 Obviously AI obviously.ai Predictive analytics for tabular data and databases − + − d D-3 Parabola parabola.io Analytics for data flows from multiple sources, sales data focus − + − f F-1 Arengu arengu.com Forms and dialog flows, components for e.g. authentication, payments − + ◦ d F-2 Formstack formstack.com Forms using dialogs with if-then-logic − + − d F-3 Tally tally.so Forms using documents and integration − + − d IN-1 Budibase budibase.com Tools esp. for tabular data of ERP, HR, sales, customers − + − u IN-2 Jet Admin jetadmin.io Tools esp. for administration, CRM, approval workflows − + ◦ u IN-3 Windward windwardstudios.com Tools for building reports and dashboards, document generation − + − d SC-1 DAML daml.com SC generation, DSL for contract logic, tokens, assets + − + t SC-2 Dappbuilder dappbuilder.io Small decentralized apps with websites and SCs, pre-defined temp + − + d SC-3 Simba Chain simbachain.com SC generation, graph-based data models, generation of data structures + − − t SP-1 Actiondesk actiondesk.io Spreadsheet-based apps, focus on integration with apps, reports − + − s SP-2 Airtable airtable.com Spreadsheet-based apps, multiple views, temp., data integrations − + − s 123 1874 S. Curty et al. Table 6 continued Cat-ID Name Website Description d1 d2 s r SP-3 Rows rows.com Spreadsheet-based apps, esp. database, web API access, event triggers − + − s WA-1 Aurachain aurachain.ch Process automation with database and API access, BC temp + − − d WA-2 AWS aws.amazon.com Workflow Studio, flows for cloud services, lambda functions, serverless + + − f WA-3 Azure azure.microsoft.com Azure Logic, visual flows for services, lambda functions, user-facing apps − + − f WA-4 IFTTT ifttt.com If-then workflows, esp. web apps and services, BC services + + − d WA-5 Make www.make.com Integration, esp. of existing services, event-based, BC services + + − d WA-6 Kissflow kissflow.com Integration using temp. components, esp. reports, cases, apps − + − f WA-7 n8n n8n.io Integration, esp. w1eb apps and services, data processing, BC services + − + f WA-8 NodeRed nodered.org Integration using components for logic, esp. for cloud services, IoT, BC + + + f WA-9 Pipefy pipefy.com Integration, esp. pre-defined ERP functions such as accounts and HR − + − f WA-10 Process Str process.st Business processes and workflows, document-based workflows − + − f WA-11 Tray tray.io Integration, esp. web services, enterprise and e-commerce focus − + − f WA-12 Waylay waylay.io Integration, esp. IoT, digital twins, process automation, data processing − + − f WA-13 Workato workato.com Integration, esp. of business cloud services − + − f WA-14 Zapier zapier.com Integration, esp. of existing web apps and services, BC services + + ◦ d WB-1 Atra atra.io Websites and web3 apps, UI focus, plugins for cryptocurrency wallets + − ◦ f WB-2 ICME icme.io Websites, temp.-based, builder and websites hosted on Dfinity BC + − − u WB-3 Pory pory.io Websites and small apps, integrations from external sites and services − + − f WB-4 Softr softr.io Websites and small apps, integrations from external sites and services − + − f WB-5 Squarespace squarespace.com Websites, UI focus, dialogs and visual flows for specification, temp − + − u WB-6 Unstack unstack.com Websites, UI focus, focus on landing pages and e-commerce − + − u WB-7 Webflow webflow.com Websites with complex structures, BC temp. for e-commerce + + − u WB-8 Xooa xooa.com Websites and web3 apps, pre-defined components, dashboards + − ◦ d A platform denoted to have 1st degree integration interacts directly with supported blockchains through its software or services. 2nd degree integration refers to the support of an integration with an external service that offers 1st degree integration Cat: category (AM: app builder with mobile focus, AW: app builder with web focus, D: data, F: form builder, IN: internal tools, SC: smart contract development, SP: spreadsheet tools, WA: workflow integration and automation tools, WB: website builder), d1: 1st degree blockchain integration, d2: 2nd degree blockchain integration, s: open source implementation, r: primary representation abstract from code (u: UI-based, f: flow-based, d: dialog-guided, s: spreadsheet-based, t: text-based) +: applicable, ◦: partially applicable, −: not applicable, app: application, temp: template 123 Design of blockchain-based applications using MDE and low-code/no-code 1875 Fig. 8 Outsystems studio, a low-code application builder for web and mobile applications showing an integrated development environment usingvisual flows (right-hand side), here specifying the user interactions and processing steps in a supply chain tracking application, along with an android emulator executing the app (left-hand side) with retrieval of blockchain data sequentially or non-sequentially using conditional branches or events. In the example, a list of goods or so-called com- modities is retrieved from the Ethereum blockchain, stored in a local list, and—for each supplier—processed regarding shipment and product data. Website builders: For website builders, blockchain inte- gration has only been found for integrating cryptocurrency- related data, with the exception of ICME (WB-2). ICME is a website builder for creating websites on the Dfinity blockchain. The app and the resulting websites are hosted on Dfinity, such that the creation of the website as well as the hosting do not rely on traditional client–server-architectures and instead retrieve and process data on nodes of the decen- tralized blockchain network. Workflow integration and automation tools: Tools in this area automate and execute user-defined workflows and allow for integration. This concerns on the one hand cloud providers such asAmazonWebServices (AWS) (WA-2) inte- grating services for cloud computing. On the other hand, there exist platforms focused on the integration of web apps and web services. For instance, n8n (WA-7), and Zapier (WA-14)4 realize this approach. AWS (WA-2) and Microsoft Azure (WA-3) are cloud providers offering low-code solutions in combination with their cloud services, whereAWSoffers 1st degree integration in supporting service calls to the Amazon Quantum Ledger 4 In addition to platforms supporting 2nd degree integration WA-4 to WA-14. Database (QLDB) and Amazon Managed Blockchain. For AWS and Azure, flow-based representations are used for specifying calls to services and lambda functions. Similar to the flows shown in Fig. 8, they visualize the subsequent invocation of steps for execution along with execution logic. Using cloud services, steps are specified, possibly depending on conditions or events, for invoking programs of platform- as-a-service offerings with corresponding computation and data storage steps of infrastructure-as-a-service components. Lambda functions allow for specifying functions abstract from concrete servers or services offering scalability and dis- tribution advantages not tied to the implemented source code or the servers. AWS relies on a state machine representa- tion called step functions for this purpose that follows the serverless compute paradigm. Azure allows for lambda functions through Azure Logic Apps that describe application logic in a flow-based manner. Furthermore, Azure allows the connection and integration with user-facing apps, branded power apps, developed in a no-code environment through the composition of UI ele- ments. Apart from cloud providers, platforms focused on the inte- gration of web apps and web services realize applications on the principle of so-called integrations, by connecting exist- ing apps and services in an automated workflow. In this area, simple workflows might be specified with platforms such as If-This-Then-That (IFTTT) (WA-4) that conditionally call services based on the output of other platforms, e.g. reading 123 1876 S. Curty et al. Fig. 9 Simba Chain, a no-code smart contract development platform showing a data model consisting of assets (rectangles) and transac- tions (ellipses) that result in the generation of a smart contract with corresponding data structures. On the right-hand side, attributes of the Commodity asset are specified with data types and names a temperature value from a weather app and activating an internet of things (IoT) device through an IoT online plat- form in case of extreme conditions. In this category, the representation abstract from source code (column r) is either dialog-guided or flow-based. For example, IFTTT (WA-4) will present users with a series of dialogs prompting the involved web apps along with their actions and specific con- ditions. An example offeringmore complex workflows in this area is n8n (WA-7), where a flow-based editor connects different services based on advanced application logic. Here, an appli- cation might retrieve documents from a spreadsheet web app and decide based on complex branching logic the process- ing with data operators; for instance, transformations of data columns and the calculation of formulas. Then, the process- ing in further apps might be triggered, e.g., adding entries to an SQL database or e-mailing the results with a mail appli- cation in case specified criteria are met. Integration with blockchain transactions and smart con- tracts is supported in the surveyed approaches for the Ethereum blockchain in Zapier (WA-14) and Aurachain (WA-1), for the Amazon Managed Blockchain and Amazon Quantum Ledger Database in AWS, and for the Hyper- ledger Fabric blockchain in NodeRed (WA-8) and Aurachain (WA-1). Further blockchain integrations concern the support of crypto-currency data. Smart contract development is supported primarily for Ethereum,HyperledgerFabric,HyperledgerSawtooth,Ama- zon Quantum Ledger Database in DAML (SC-1), Dapp- builder (SC-2), and SimbaChain (SC-3). In particular, Simba Chain supports smart contract design based on templates and a visual editor for Ethereum, Hyperledger Fabric, and others. As an example, smart contract development in Simba Chain is shown in Fig. 9. In the editor, a datamodel consisting of assets and transactions is defined for a smart contract to be generated with data structures accordingly persisting data on the blockchain. In the example, the smart contract of the sup- ply chain tracking application demonstrated before in Fig. 8 is defined in its data structures. From the app, it will store shipments with a certificate of origin and the commodities contained in it, specified with the displayed attributes such as global trade item number (GTIN), quantity, and weight data. Generated data structures allow for efficient data storage and will provide basic reading and writing functionality through setter and getter functions. In comparison, DAML (SC-1) uses a text-based represen- tation in the form of a domain-specific language that can specify complex smart contract functionality. The language uses textual descriptions with a notation that is mostly based on natural language elements, interpreted and deployed to a blockchain. The language encompasses primarily the specifi- cation of contract logic, e.g., triggering transactions based on 123 Design of blockchain-based applications using MDE and low-code/no-code 1877 contractual conditions, the handling of tokens, e.g., sending out tokens if contractual conditions aremet, and the definition of assets as abstract concepts represented by tokens. While this approach offers complex features due to the expressivity of the language, it is geared towards technical domain experts and developers as a low-code approach. On the other side of the complexity spectrum,Dappbuilder (SC-2) offers smart contract creations through the instanti- ation of pre-defined templates for Ethereum, Polygon, and other blockchains. The approach is limited in applicability to the foreseen application areas that utilize standardized con- tracts modified according to the specification of the user, e.g., for issuing user-defined tokens on the Ethereum blockchain. For this purpose, a smart contract of the site is used based on the standardized Ethereum ERC-20 token implementation. 5.2.2 PlatformsWith 2nd degree integration 2nd degree blockchain integration has been found in 37 solu- tions intended for building websites, mobile or web apps, or forms, for workflow integration and automation, internal tools for companies, for data processing, and spreadsheet- based applications. Eight solutions also offer 1st degree blockchain integration. The integration features across the categories rely on another service supplying a direct inte- gration for blockchain applications. Among the no-code or low-code applications, it is typical to integrate other ser- vices in the fashion of a composition, for example, creating an application in an app builder with data provided by an external service. Blockchain integration features, due to this capability, rely on other services for integration. Based on the integration paradigm, existing web services might be com- bined or access blockchain data. Workflow integration and automation tools offer 2nd degree integration in this way. For example, workflows spec- ified with cloud services such as with AmazonWeb Services (AWS) (WA-2), orwithMicrosoftAzure (Azure) (WA-3) can define API calls in their flow-based editors to a platformwith 1st degree integration, e.g., calling Zapier (WA-14) for the retrieval of Ethereum transactions. Similarly, workflow tools focused on integrating web apps and web services (WA-4 to WA-14) such as Pipefy (WA-9) might utilize Zapier and sim- ilar services in web-based workflows. In this way, most 2nd degree integration platforms offer the possibility of interact- ing with Ethereum smart contracts and transactions. Appbuilders andwebsite builders provide further integra- tion possibilities for mobile and web applications as well as websites. For instance, in Glide (AM-4), which can embed dialogs for smart contracts and transactions, in addition to integrating cryptocurrency data. In this way, applications composed of these components might be realized with work- flow automation. Websites might also integrate dialogs from Glide (AM-4), e.g., e-commerce payments using cryptocur- rencies or for enhancing websites with web3 functionality. Websites following the web3 concept [45] depend less on large, centralized, and potentially influential entities such as websites of well-known social networks. Instead, decen- tralized platforms and infrastructures host components of websites, e.g., using blockchain transactions made in a browser through theMetaMask extension or by decentralized data retrieved fromEthereum through services such as Zapier (WA-14). The integration paradigm can be applied and used in combination with platforms in the other categories con- cerning data, form builders, internal tools, and spreadsheets. For example, a transaction may be sent after the workflow has been started by another action such as entering data in a spreadsheet. Spreadsheet tools may be used for building small appli- cations with platforms such as Actiondesk (SP-1), AirTable (SP-2), or Rows (SP-3) by pre-defined components and mul- tiple views that allow defining input fields and the processing of submitted data, e.g., calculating statistical measures of sales transactions on Ethereum retrieved through Zapier. Form builders typically provide input fields for enter- ing data with user-defined UI elements such as labels and buttons with the possibility of triggering external actions. For instance, retrieving corresponding transactions from Ethereum, and sending out results through notifications or e- mails. For example, Arengu might be used in this way (F-1). Internal tools focus on company-internal tasks, encom- passing enterprise tools for the automation of enterprise resource planning (ERP) or operational tasks. For exam- ple, by handling customer data and sales orders, managing human resources (HR), customer relationship management (CRM), creating dashboards or admin panels.For instance, using data from the Ethereum blockchain, tools such as Jet Admin (IN-2) might present a tabular structure and trigger an approval workflow for a back-office team. Data processing tools permit the analysis of data with formulas or measures, e.g., of statistical nature, and offer predictive analytics features such as found in Levity (D-1) and Obviously AI (D-2). In this way, smart contract func- tion calls might for example be evaluated regarding their frequency or sales volume. By permitting the integration of further data sources and the integration of other web applications, data analysis might involve the processing of newly appearing blockchain transactions. Such processing may include, for example, the storage of transaction data in spreadsheets, or the triggering of workflows. Integrations in this context can extend to enterprise-focused business pro- cess management when combined with platforms such as Process Street (WA-10), offering advanced functionality in combination with workflow engines. Overall, the results show that the integration possibilities for the creation of websites or apps rely on few services such as Zapier (WA-14), predominantly found in the workflow 123 1878 S. Curty et al. automation category. Typical integration features consist of access to blockchain transactions or cryptocurrency data. Further integrationpossibilitieswithAPIs on a technical level are very common, however, they were not considered no- code or low-code when using Webhooks, Rest, other forms of HTTP requests, or API access based on technical param- eters. For the development of smart contracts, few no-code platforms could be found in practice, with most solutions being low-code approaches using representations closer to source codewhere technical knowledge is required for devel- opment and blockchains. 6 Discussion For discussing the results of our study we will first elabo- rate on the academic papers as shown in Tables3 and 4. We characterize each topicwith relevant papers found in the liter- ature search. The topics were derived via the topic modeling technique of LDA and the subsequent manual refinement as has been described in Sects. 4.3 and 4.4. The selection of papers included in the discussion is based on all papers assigned to a particular topic with unanimous agreement by all raters (see Sect. 4.4 and Table 5) and discusses further papers from the literature search 4.3 that characterize each topic to illustrate the scope of approaches. This will permit us to give detailed insights into each of the proposed topics. Subsequently, we will draw the relations between the topics of the academic papers and the tools found in the analysis of low-code approaches. As a synthesis, we will be able to derive commonalities and differences in academic model- driven as well as industrial low- and no-code approaches for blockchain design and point to further research and develop- ment opportunities. Process, workflow, choreography, and decision models: Model-driven design and implementation aspects of pro- cesses, workflows, choreographies, and decisions are sup- ported in various approaches utilizing the blockchain at design-time or run-time. Concerning especially publications on process modeling and related subjects, the topic captures a substantial part of the overall literature on modeling and blockchains. Centered on process and workflow models, most publi- cations apply BPMN on the Ethereum blockchain and con- cern run-time aspects. Especially monitoring and execution are addressed by Weber et al. [263], following optimiza- tions [102], and systems implementing execution such as Caterpillar [41, 159, 160] and further approaches focused on workflows, e.g., by Sturm et al. [231, 232] or based on anno- tations by Bagozi et al. [20]. For these execution approaches, BPMN is transformed to representations used for execution with a smart contract. Oftentimes, BPMN is transformed into an intermediate model closer to execution and then used as input for a generator program resulting in one or more smart contracts. The intermediate model has the role of specifying well-defined execution semantics, often relying on Petri Nets such as in [102, 163]. Business process management and workflow systems implementing execution consist of additional process or workflow engine components, listening to events emitted by the blockchain mostly through smart contracts as in Cater- pillar and subsequent works [20, 160], usually with further blockchain-external components such as model repositories; only in some cases using decentralized repositories, e.g., based on distributed file systems as suggested by Bagozi et al. [20]. In few systems related to processes and workflows, approaches not relying on smart contract generation can be found. Here, processes and workflows are interpreted such as suggested by López-Pintado et al. [162], using workflow engines as also proposed by Falazi et al. [87, 88] and Sturm et al. [232]. Primarily static smart contracts, not changing over time, are used for the interpretation of process and workflow definitions. Also, combinations of static smart contracts and generated contracts could be found, e.g., proposed by Bagozi et al. [20] using smart contract templates, Härer suggesting a combination with multiple object- and participant-specific contracts [121] for business systems, and Klinger et al. also proposing partial generation of the contracts [142, 217]. While the approaches discussed so far rely primarily on BPMN and Ethereum with smart contracts, few pro- cess and workflow approaches also exist for other modeling languages and blockchain platforms. Not relying on smart contracts at all, Evermann and Kim [84] propose a work- flow system based on blockchain transactions, where Petri Net representations of workflows are used to create transac- tions that trigger the execution on a workflow engine using a blockchain connector, possibly applicable also for bitcoin or other blockchains. Relying on statecharts, few works such as Nakamura et al. [185] can be found, where statecharts spec- ified in SCXML are reduced and transformed to contracts on the Hyperledger Fabric blockchain for workflow execu- tion with distributed node.js applications. SOM and BPMN are applied by Härer [121] for describing business systems consisting of structural views for distributed organizations in SOMand process behavior specified byBPMNcollaboration diagrams, also concerning design-time aspects for collabo- rative modeling based on voting mechanisms together with the generic tracking of instances at run-time for monitoring. DEMO is applied in few instances, e.g., by Loukil et al. suggesting a non-generative approach [164], where smart contracts are interpreted in a three-layered architecture and evaluated on Ethereum, and by Silva et al. [223] propos- ing DEMO for its actor transaction diagrams with further diagrams of transactions and UML classes as part of a com- prehensive transformationmethod involving execution on the Hyperledger Fabric blockchain. Guerreiro et al. [114] apply 123 Design of blockchain-based applications using MDE and low-code/no-code 1879 BPMN initially and suggest also DEMO for actor transaction diagrams that represent business transactions with a transfor- mation implemented in Hyperledger Fabric smart contracts. Concerning declarative modeling approaches, few works investigate decision models using DMN and case man- agement by CMMN. For DMN, execution is proposed by Haarmann et al. [115, 117], where DMN provides decision rules based on formulas or decision tables that are encoded in smart contract logic for execution and demonstrated on the Ethereum blockchain. Concerning CMMN, Milani et al. [179] provide a comparison of BPMN with CMMN and point out their limitations regarding execution characteristics such as missing expressivity for completed tasks in CMMN. Related to process choreographies, most works concern BPMNchoreography diagramswith few approaches describ- ing other modeling languages such as DCR graphs. Works in this area address the collaborative execution of process choreographies, where choreography tasks are executed by multiple participants exchangingmessages. Based onBPMN and execution aspects, this is investigated by Ladleif et al. [146] and following approaches such as by Corradini et al. [61, 65], Sturm et al. [233], Corneli et al. [59], and Spalazzi et al. [229]. In BPMN choreographies, the control flow is restricted according to the choreography structure that is established by the tasks, relationships, and special- ized gateways and events, effectively defining permitted patterns of message exchanges. Most approaches generate smart contracts such asCorradini et al. [61], possiblywith the non-generative use of static components such as by Ladleif et al. [146]. In addition to the Ethereum-based approaches, also a multi-chain implementation has been proposed by Ladleif et al. [145]. Choreographies based on languages beside BPMN appear in comparatively few works based on DCR as addressed by Madsen et al. [166] and Henry et al. [130] in methods allow- ing for execution on the Ethereum blockchain. Provided an external execution engine exists, control flows between col- laborative tasks of multiple participants are restricted to the edges defined by the DCR graphs in these approaches. Further domain-specific notations exist in few works, not applying standardized modeling languages. For workflows, JSON is used by Bore et al. [38] for execution in a workflow system connected to Hyperledger Fabric. Another domain- specific notation using transaction concepts derived from Ethereum for business processes is suggested by Boychenko and Gavrikov [40] by a UI prototype without implementa- tion. Further specializations for the body of literature dis- cussed for process andworkflowapproaches exist in addition, primarily concerning run-time aspects and optimizations. For example, on traceability and monitoring by Di Ciccio et al. [55], confidential execution such as in Carminati et al. [48], trust, e.g., Bagozi et al. [21], and flexibility aspects for instance in López-Pintado et al. [163], as well as BPMN- specific concepts, e.g., with focus on time and events byAbid et al. [2] and Naha et al. [247]. Applicationdevelopment: Thedevelopment of blockchain- based applications using models and model-driven engineer- ing has been the subject ofmany retrieved publications. Thus, the range of methods found for this topic comprises both conceptual and executable, code-generating approaches and spans from base languages such as AOM, e.g., [153], BPMN and DMN, e.g., [192], DEMO, e.g., [14], ER, e.g., [100], OCL, e.g., [235], OWL [28] to RuleML, e.g., [256], and UML, e.g., [101, 139, 168, 237], as well as a large num- ber of blockchain domain-specific languages, e.g., [39, 99, 120, 158, 210, 236, 271], and visual programming paradigms such as Blockly, e.g., [167, 178, 265]. In terms of the targeted blockchain platforms for application development approa