A Framework for Blockchain Alignment for Implementing Public Business Registers: A European Perspective

Abstract

This paper examines the alignment of blockchain architecture with the specific requirements of public business registers in Europe. Through a comprehensive literature review, categorization of blockchain models, and analysis of European public business registry cases, this study develops a framework to guide blockchain adoption in public registries. A distributed ledger taxonomy tailored for business registers is presented. This article also introduces a registry mapping procedure and addresses security concerns essential for the transition to blockchain-based architectures. Blockchain technology, popularized in 2009, has evolved into a versatile tool with applications across various domains, including the public sector, where its potential for decentralized solutions is especially promising. In particular, strategic systems that constitute the backbone of the legal and economic order require special considerations providing superior quality and the appropriate level of security. This study proposes a categorization method, outlines a registry mapping procedure, and discusses security concerns integral to blockchain implementation in public registries. The potential of blockchain technology to change the architecture of public business registries is also discussed.

1. Introduction

Blockchain, emerging alongside cryptocurrencies, extends beyond their primarily economic focus [1], offering a decentralized database for diverse financial and non-financial applications [2,3,4,5,6]. Its key features include immutability, non-repudiation, integrity, transparency, and equality [7]. A decade of development has led to a variety of blockchain models, each with distinct characteristics.

Distributed ledger technologies have issues of their own, especially in terms of scalability, flexibility, and governance [8]. However, the challenge for public policy- and decision-makers is to decide whether blockchain technology is appropriate to be promoted as a backbone of future public service and administration repositories [9].

Therefore, we define and discuss the methodological approach in which blockchain typology and architectural features are confronted with the diversified public service registers and their requirements.

This article aims to propose a framework that allows or at least facilitates the task of the selection of a blockchain solution that will be the best fit for the needs of specific public services. The formulated framework should allow for balancing the expected benefits and costs of the blockchain-based implementation and thus assist in deciding to switch from legacy centralized architectures to decentralized ones, if applicable.

To achieve the projected aim, the authors perform the following:

• Introduce the typology of selected public registries (we deliberately omit land, movable property, and civil and focus solely on business entities, for instance, as elaborated in [6]).
• Find common or specific characteristics and requirements for given types of registries.
• Create the framework that would enable one to address (or map) the requirements of selected types of registries by identifying models of the blockchain (architectures) as different classes of blockchain models should be suitable for implementing specific public registers—or not suitable at all.

In addition, in the article:

• Selected state-of-the-art blockchain-based solutions for different kinds of public (legal) registries (mainly land and cadaster) are reviewed.
• A comprehensive list of blockchain system models together with their properties is identified based on the literature.
• A particular set of security concerns that may arise from the suggested switch towards a blockchain-based approach is addressed.

The analysis could reveal two key outcomes: identifying registry types that are currently unsuitable for blockchain implementation due to technological or regulatory limitations [10] and highlighting the needs future blockchain-based approaches must address to meet the specific requirements of certain registers.

The authors focus on a specific type of public database: registers of business entities in EU countries. Public registry solutions vary significantly across EU member states. The authors compared these solutions based on key criteria, including the responsible entity, scope, and available interface. From this analysis, four use cases were selected: Poland, Austria, Estonia, and Germany.

2. Methodology and Related Works

2.1. Research Method

The research presented in this paper adopts a structured approach combining a scoping literature review and qualitative content analysis to identify and synthesize key framework elements. This foundational phase enabled the development of several artifacts that constitute the primary contributions of this research:

• Concepts: public business registers typology, blockchain types, criteria groups and clusters, and requirements of registry groups;
• Models: a framework for mapping registry requirements to blockchain architecture;
• Methods: a method and set of rules for determining the mapping between registry requirements and specific blockchain types;
• Instances: an adaptation of the framework-based analysis for a specific registry.

These artifacts were developed iteratively, guided by a conceptualization of research goals, and informed by the gaps identified in the literature. While the research process aligns partially with the principles of the Design Science Research (DSR) [11,12,13] approach—specifically in terms of artifact creation and refinement—it does not encompass the full cycle of validation typically associated with DSR, such as evaluations through exploratory case studies, expert panels, or confirmatory studies.

As a result, this study primarily serves as a theoretical foundation, with its contributions offering a basis for further empirical investigation. Future research could build on this work by employing DSR or Design Research Methodology (DRM) to validate and refine the proposed artifacts in practical contexts, such as through user evaluations, expert consultations, or real-world case studies.

The structure of this article mirrors the phases of the research. First, a comprehensive literature review has been conducted (Section 2.2), which resulted in the identification of the application of blockchain technology in various public registries and different blockchain types (Section 2.3). Subsequently, a taxonomy of the distributed ledger has been analyzed (Section 3). In the following phase, public business registries from EU countries have been investigated. The authors decided to focus on four use cases: Polish, German, Austrian, and Estonian business registries as they provide a variety of approaches (Section 3). Based on this comparative analysis, the authors developed a framework that enables the determination of which blockchain models are best suited (or entirely unsuitable) for implementing particular public registries (Section 4).

2.2. Literature Review

The literature review was conducted using several indices: Springer Link, the ACM Digital library, Scopus, and Google Scholar. The search queries combined keywords such as “blockchain for public registers”, “blockchain taxonomy”, and “blockchain design”, with a focus on journal papers and peer-reviewed conference materials published in English. Additionally, relevant legal documents from various European countries and the European Commission were included. When official English translations of regulations were unavailable, the original sources in German or Polish were cited.

Blockchain is a relatively new technology, especially in terms of innovation adoption models. We present publications that describe trials and theoretical analysis of the potential of blockchain technology for use in the public sector. For instance, Thomas [14] argues that blockchain’s simplified structure is incompatible with the nuanced legal frameworks governing high-value assets like real estate. The text introduces disambiguation between low-valued assets, which are, in terms of legal title, mostly homogenous in their nature. The real properties in contrast are usually high-value resources with sophisticated legal characteristics and with customizable rights that may be bound.

Building on this critique, Vos [15] analyzes the fundamental principles that any land registry system must meet to serve as a legal database. The study highlights the challenges blockchain poses, such as the need for a “genesis block” to include comprehensive data reflecting the existing legal situation before implementation. This requirement could lead to a significantly large and complex initial dataset, potentially undermining the practicality of blockchain for land registries. Furthermore, Vos critiques early blockchain adoption initiatives for overlooking the intricacies of legal systems and the wide range of exceptional cases that may arise during the life cycle of real property.

Despite these legal and technical concerns, there are notable examples of successful blockchain implementations in public sector services, as highlighted by Navadkar, Nighot, and Wantmure [16]. In Estonia, several record services have already been realized with blockchain technology since the year 2012. In India, two services use blockchain: land agreement registry and vehicle transactions registry. These implementations illustrate how blockchain can enhance service quality, integrate personal identity systems, and bolster citizen trust in government processes. The authors also emphasize the potential for blockchain to improve resource efficiency and accountability compared to traditional technological systems.

From a policy perspective, Gabison [17] presents a decision-making framework for evaluating blockchain’s role in public systems, advocating for a cost–benefit approach. He notes that current policy ecosystems are misaligned with blockchain, requiring significant regulatory adjustments for broader adoption. While blockchain’s drawbacks may currently outweigh its benefits, the author argues it is well suited for government data dissemination, as its cryptographic architecture enhances transparency, accuracy, and legitimacy in shared information.

In developing countries, blockchain is seen as a transformative tool to address systemic inefficiencies and corruption. Oprunenco and Akmeemana [18] describe a proof-of-concept land registry system in Panchkula, India, designed to combat unregulated ownership and bureaucratic corruption. The text highlights blockchain’s significant potential in poorer nations, despite its high implementation costs. By fostering trust and decentralizing from unreliable or absent state services, blockchain can address challenges like unregulated ownership and corruption, offering transformative solutions. Even high-cost systems may deliver a favorable cost–benefit ratio, though tailored analyses and optimized solutions are needed to align with economic constraints. The authors note that many poorer countries face common issues, such as inadequate public services and registries, hindering economic recovery. The report emphasizes blockchain’s key attributes—immutability, transparency, and tamper-proof integrity—as essential factors, making it an ideal candidate for testing in these contexts. Similarly, Kshetri and Voas [19] highlight blockchain’s potential for property rights and land registration in regions like Honduras and rural Africa, where land ownership documentation is scarce, and corruption undermines trust in public records. They emphasize blockchain’s tamper-proof integrity as a key feature that can help mitigate these issues.

Other studies further explore blockchain’s applications in public services. In Bangladesh, efforts to implement blockchain-based land registries demonstrate the technology’s growing relevance in governance [20,21]. Tahar et al. [22,23] describe a Land Administration System that uses blockchain, while Meng [24] presents a framework for agricultural product traceability. Rede Blockchain Brasil provides another example of a government blockchain network supporting a range of applications, including public record management [25].

An overview of different blockchain applications is presented in [26]. The authors explore the transformative potential of blockchain technology within Industry 5.0, a paradigm emphasizing human-centricity, sustainability, and resilience. Blockchain offers security through cryptography, transparency via immutable shared ledgers, decentralization to prevent single points of failure, and automation with smart contracts. These features make blockchain crucial for advanced industrial applications. Examples include improving human-centric production, enabling sustainable traceable value chains and green energy verification, and enhancing resilience in supply chain management, disaster response, and cybersecurity. Practical uses include decentralized resource trading, pharmaceutical supply chain optimization, and secure data sharing for smart cities.

An important area of blockchain applications is finance. Decentralized finance (DeFi) has been receiving more attention recently as national banks undertake projects to introduce Central Bank Digital Currency (CBDC) [27,28]. At the same time, DeFi projects gain attention and are adapted to the market to provide services that compete with commercial banks, e.g., loans [29].

These studies collectively highlight blockchain’s promise as well as its limitations in the public sector. While its advantages—such as transparency, accountability, and efficiency—are evident, challenges related to scalability, legal complexity, and regulatory alignment remain significant. The challenges will be considered in Section 4.2 and Section 4.6.

On 23 July 2014, the regulatory framework of the European Parliament and the Council on “electronic identification and trust services for electronic transactions in the internal market” was established [30]. The regulation took effect on 1 July 2016. The most important norms are related to the legal effects of electronic signatures (Article 25), whereas Article 41 of the same regulation perceives parallel legal consequences for electronic timestamping. The European-level regulations override the national law, which effectively means that in all EU countries, the data and documents that persisted on the blockchain will be treated as legally binding and thus effective proof in the court hearing both in terms of signature and timestamping. Consequently, they will not be perceived by the court as handwritten signatures unless some additional conditions occur.

Analogical regulatory initiatives have taken place in the USA. The US state of Vermont took the lead in blockchain legislation on 2 June 2016, recognizing blockchain data as valid in the court system. Bill H868 states that ‘A digital record electronically registered in a blockchain shall be self-authenticating’. Another state, namely Arizona, followed a similar path. Its legislature introduced Bill No. 2417, which brings numerous amendments and adds Article 5 about the legal status of blockchain [31]. The introduction effectively recognizes both entries and data placed on the blockchain as legally valid signatures and records. It also regulates the status of smart contracts as valid agreements in commerce. On 21 July 2017, Bill No. 69 was signed, becoming the official law of the state of Delaware. The preparation of the landmark legislation was executed by the Delaware Blockchain Initiative. The new law changed the policy to Delaware’s General Corporation Law. The amendments introduced give the authority to corporations to issue and maintain the records of their stock shares on a blockchain. There are several currently undergoing projects that focus on implementing blockchain technology for government services. Those projects are continuously compared and assessed. For example, Brinkmann and Heine [32] performed a Delphi-based analysis of such projects.

Table 1. Governmental initiatives and expectations.

Administration	Outlook	Document
EU	‘potential to accelerate, decentralize, automate and standardize data-driven processes at lower cost has the potential to alter fundamentally how assets are transferred, and records are kept’, ‘increase data sharing, transparency, and trust not only between the government and citizens’	[33]
Vermont, USA	‘the costs and challenges associated with the use of blockchain technology for Vermont’s public recordkeeping outweighs the identifiable benefits.’ The document recognizes twofold effects: the benefits (1) from a direct adoption of blockchain technology for Vermont governmental functions and the benefits (2) from legal recognition of blockchain for private uses, such as the evidentiary recognition	[34]
Dubai	‘[…] stands to unlock 5.5 billion dirhams in savings annually in document processing alone—equal to the one Burj Khalifa’s worth of value every year.’	[35]
UAE	‘[…] save AED 11 billion in transactions and documents processed routinely, 398 million printed documents annually, 77 million work hours annually.’	[36]
India	‘[…] Blockchain characteristics such as tamper-evident, consensus-based transaction validations and secured data storage act as key driving forces for its adoption in various sectors’	[37]
Nigeria	‘[…] can contribute to strengthening Nigeria’s digital economy by expanding financial inclusion and enhancing openness and accountability’	[38]
Bangladesh	‘Blockchain technology is widely regarded as one of the core and foundational technologies that will be one of the driving forces for the upcoming 4IR’	[21]

contains excerpts from officially issued documents and strategies about the expected outcomes of employing blockchain architecture in the public sector.

The EU’s eIDAS regulation and US state laws, such as those in Vermont, Arizona, and Delaware, recognize blockchain-based signatures, timestamps, and records as legally valid. These frameworks provide guidelines and set expectations for using blockchain in public administration and commerce, aiming to enhance trust and legal clarity in these areas. These guidelines and expectations will be referred to later in Section 4.4.

2.3. Blockchain Types Landscape

Article 5 of the Arizona State Legislature Bill No. 2417, besides establishing the legal status of blockchain technology, includes also a short definition of what it is from a legal point of view [31]. It also brings a basic classification of the technology stating that ‘distributed ledger technology […] may be public or private, permissioned or permissionless, or driven by tokenized crypto economics or tokenless’.

Table 2. Summary of categorization criteria and blockchain types based on reviewed literature.

Criteria	Literature Item	Comments and Synonyms
1. Cardinality of maintaining parties	[15,26,31]	Blockchain scope.
- public		Open to any node.
- hybrid		Consortium/community.
- private		Closed/open to particular nodes.
2. Permission	[7,31]	-
- fully centralized		Not a blockchain.
- permissioned (fine-grained operations)
- permissioned (write, open access read)
- permissionless		Fully open system.
3. Cryptocurrency dependency	[31,39]
- cryptocurrency-based		Driven by tokenized crypto economics.
- non-cryptocurrency based		Tokenless.
4. Smart contracts functionality	[26,39]	-
- smart contracts blockchains		Distributed computations.
- non-smart contracts blockchains		Without or with a basic scripting facility.
5. Verifier	[7]	Actor or node that verifies transactions.
- single
- m-of-n
- ad hoc
6. Consensus Protocol	[7,26]	-
- proof-of-work		Most common consensus algorithm. The probability of the right to create a new block is proportional to computational power.
- proof-of-stake		The probability of the right to create a new block is proportional to the stake in the crypto-economy.
- proof-of-authority
- proof-of-retrievability		The probability of the right to create a new block is proportional to devoted storage resources.
- Byzantine fault tolerance
- hybrid consensus		e.g., PoW plus PoS
- proof-of-elapsed-time
7. Data structure	[7]	-
- chain of blocks		Typical blockchain.
- GHOST
- blocks DAG		Direct Acyclic Graphs allow for parallel transactions.
- segregated witness		Technical improvement within the structure of a block.
- shard chains
- rollups		e.g., optimistic, ZK rollups
8. Data item storage	[7]	-
- embedded within transaction
- embedded within smart contract
- embedded as a log
- in cloud
- P2P system
9. Item collection	[7]	-
- as a smart contract
- on a parallel blockchain
10. Computation	[7]
- transaction constraints only		On-chain, non-Turing complete.
- smart contracts		On-chain, Turing complete.
- private/third-party cloud		Computation outside the blockchain.
- zk-rollup computations
- machine learning on blockchain
11. Mechanisms for data privacy
- zero-knowledge proofs		e.g., ZK-SNARKs, ZK-STARKs
- ring signatures
- confidential transactions
- anonymization mechanisms		e.g., Mixnets, Tornado Cash
12. Off-chain transaction protocol
- mini-blockchain
- leader selection
- state channels
- rollup-based transactions
13. Integration with other systems
- no integration
- API/interfaces to traditional systems
- cross-chain bridges
- interoperability protocols		e.g., Polkadot, Cosmos
14. Governance
- off-chain governance
- on-chain governance		e.g., DAO
- hybrid governance models
15. Resilience to attacks
- quantum-resistant
- Sybil attack protection mechanisms
- censorship resistance mechanisms
16. Energy efficiency and sustainability
- high energy consumption		e.g., proof-of-work
- low energy consumption		e.g., proof-of-stake, proof-of-space
- carbon neutrality		e.g., CO2 offsetting mechanisms
17. Design patterns	[40]	-
- mirror type
- digital record type
- tokenized type
18. Layers
- layer 1	-
- layer 2
19. Project phase	-	-
- testnet		Used for testing purposes.
- mainnet		Working blockchain environment.

enlists the important criteria, categories, and associated types of blockchain as found in the related works (e.g., [7,15,26,31,39,40]). As some of the popular criteria are common and have been mentioned in more than one peer-reviewed article, their remittance was, for obvious reasons, omitted. Sometimes the same criterion is given by more than one author under diversified names, or the analogous type is named nonuniformly by different authors. In this case, where the situation was plain to observe, the analogous names are treated as synonyms.

An important issue is the interdependence of criteria, as some types within one criterion are linked to requirements from others. This can result in certain requirements acting as negative prerequisites, excluding some types from classification. In other words, the criteria are not mutually exclusive and may be interrelated. For example, enabling on-line Turing-complete computation necessitates a smart contract-based blockchain, as does embedding data items within smart contracts.

Although some criteria can be enlisted (Table 2), making a common typology is challenging. The relationships between some of the criteria are not always easy to establish. On one hand, criterion number 1 (cardinality of maintaining parties) may be perceived as a substitute for criterion number 4 (permission). On the other hand, some authors observe the discussed criteria as parallel [41]. The latter point of view allows for presenting a matrix of combined types. Moreover, even the sole nature of the given criterion may be rebutted. For instance, Kravchenko distinguishes the constitutional feature for criterion number 1 as the level of anonymity and for criterion number 4 to be the level of trust in validators [41]. It is a matter of discussion whether such an approach to the definition of both criteria is methodologically suitable.

2.4. Distributed Ledger Taxonomy

Modern blockchains are often defined by five key properties: immutability, non-repudiation, integrity, transparency, and equality. However, as technology evolves, some of these features may become less essential or be redefined. By questioning these core attributes and modifying secondary ones, diverse blockchain or quasi-blockchain systems can emerge. The term “quasi” highlights the debate over whether solutions lacking certain properties qualify as decentralized ledgers. As blockchain technology continues to mature, these definitions remain fluid and contested in both research and industry. A common classification divides blockchains into private, public, and hybrid types, based on users’ access rights [15].

A primitive approach of classification is demonstrated in [8] where the authors presented a straightforward typology based on the occurrences of most notable blockchains. Each blockchain (e.g., Bitcoin, Ethereum, IPFS, Hashgraph) is characterized by a few properties. Those properties make up two groups: achieving traditional information security principles and performance characteristics.

Another classification [39] divides the architectures into cryptocurrency blockchains, cryptocurrency-based smart contracts blockchains, and non-cryptocurrency smart contracts blockchains.

In the work of Xu and others besides the functional properties of the distributed ledger, the authors familiarize the reader with non-functional properties, which include accessibility (‘data privacy’) and scalability [7]. The main motivation of the authors is to assist architects in the evaluation or blockchain comparison processes, and, alternatively, to advance the study of architectural decision-making frameworks.

The challenge of ensuring blockchain scalability, reliability, and privacy is also discussed by Kuglik et al. [42]. Authors remark that those problems are particularly significant for smart contracts where they affect transaction costs and execution efficiency; however, related implications might also be addressed for public registries. Although public permissioned blockchains can outperform their permissionless counterparts, security risks may still arise when a large number of users manage the network’s processing power. As a result, many industry-based applications opt for private blockchains, leveraging open-source frameworks to combine high performance with data confidentiality.

Lemieux analyses the prospective utilization of blockchain in archive services [40]. Numerous cases of recordkeeping in the domains of land registry (Brazil, Sweden, and Honduras), medical information (Estonia), and finances (Sweden) have been analyzed. The main section of the paper infers from the cases a synthetical view of distributed ledgers typology with three definite design patterns. The blockchain types include mirror type, digital record type, and tokenized type. The first type represents a solution where the blockchain is used merely as a repository for hashes of the original information. The second type is a setting where full information is entirely stored on the blockchain.

Distributed ledger taxonomy explores evolving blockchain properties and diverse classifications, including public, private, and hybrid types. Research highlights functional and non-functional features, guiding evaluation and standardization for varied applications. The properties and classifications will be utilized in Section 4.3.

2.5. Gap Analysis

Based on the literature review, the following conclusions were made. Firstly, a plethora of different blockchain types is currently developed and used in various domains. The different types emerge to solve particular, domain-related challenges. However, at the same time, the process of mapping blockchain types to specific domain-oriented implementations is becoming more complex and time-consuming. Transferring ready-made solutions to a new domain is difficult and limits blockchain’s market adaptation. Secondly, there are numerous initiatives to use blockchain in various public registries. Government administrations recognize the potential of blockchain-based solutions; however, their adoption is relatively slow.

This paper aims to fill the gap in the decision-making process by providing a framework that will allow alignment of blockchain type and specific architecture with given public registry requirements.

3. European Public Business Registers

The presented research focuses on European public business registries due to the following assumptions: (i) How registries are maintained in EU countries is diverse. Their scope, form, technology, etc., are not regulated by overarching Union regulations. (ii) There is good documentation available for registries maintained in EU countries. (iii) Legal regulations are subject to constant change. Limiting the number of analyzed examples to 27 allowed for the analysis to be conducted in a satisfactory time frame, while at the same time providing sufficient diversity to draw conclusions and categorize solutions.

3.1. Public Registry Types

Public business registers in Europe are very diverse in terms of scope, accessibility, costs, and reliability. Different cases of such registers are presented to generalize on some of their properties in Section 4.1 and Section 4.4. There are some law regulations at the European Union level, but country-specific solutions differ significantly.

Most countries provide free access to the registry; however, usually, it is very limited in scope (e.g., free access is available only for basic data like company name, registration number, and address).

All countries provide a website with a search interface that allows executing queries on the register databases. Some offers also have access through other interfaces, like open data (cvs, txt, or xlsx) in Latvia, e-services in Romania, XML data dump in Slovenia, or a dedicated application in Belgium.

Differences between business registers are a result of historical development. Some registries are run by public administration at the national level (e.g., Ministry of Justice in the Czech Republic or Austria), some by courts (e.g., Hungry, Estonia, France, Croatia), and others by designated authorities (e.g., Denmark, Ireland, Malta). In Germany, the Ministry of Justice of the federal state of North Rhine–Westphalia runs the register on behalf of the other German federal states.

The scope of each register is a bit different: ranging from companies only, to include, e.g., associations, employers’ organizations, spin-off enterprises, public benefits associations, foundations, institutes, and more. Moreover, attributes that describe the same entity in different registers have different structures.

All registers are considered to provide only reliable documents; however, there are specific directions on how to act if there is a discrepancy between the wording of the entry and real state or how to act if the register provides out-of-date data. In some cases, the procedure of publishing data in the register included data verification by an authority (e.g., France, Croatia), even though data are submitted by a business entity itself.

In 2017, thanks to a joint effort by the EU governments and the European Commission, an EU Business Register was launched. Business Registers Interconnection System (BRIS) is a single access point to the business registers of all member countries, as well as the registers of Iceland, Liechtenstein, and Norway [43]. BRIS is accessible through an e-Justice Portal (as a web search form). Access to BRIS is free, but if a specific document or information in the original registry is paid, a fee must be paid through BRIS as well. BRIS allows for searching all individual registers at once (see Figure 1).

3.2. The Estonian e-Business Register

Estonia, for a long time, has been renowned for its high-tech-centered governance and pro-citizen attitude. The e-Business Register is part of RIK—Centre of Registers and Information Systems. It was also one of the first services introduced by the Republic of Estonia Information System Authority within the RIK bundle which currently offers about 15 main services.

The e-Business Register is maintained by the registry departments of the county court and presents real-time data. The registry allows reviewing a company’s business card data, general data, and tax arrears data, viewing annual reports, statutes, and personal and commercial pledge data. It also allows for making queries by name, Business Registry code, location, the field of activities; real-time monitoring of processing data and record amendments of companies; and, finally, verifying of business and entrepreneurship prohibitions of Estonian persons.

It is also a basis for other services, which are the Company Registration Portal and the Visualized Business Register. It is divided into three sub-registers allocated to commercial entities, non-profit associations, foundations register, as well as the commercial pledge register.

The commercial entity record is split into five parts. However, an additional four views are available after incurring a fee.

3.3. German Shared Handelsregister

In Germany, the shared Commercial Register portal is run by the Ministry of Justice of the federal state of North Rhine–Westphalia on behalf of the other German federal states (Länder), as commercial registries are run by the courts (Landgerichte) of the Länder [44]. Centralized access to all federal states of companies, cooperatives, and partnerships and announcements for the register are provided [44].

The Commercial Register contains the data of all German business entities that are subject to registration (main register). The documents that are relevant to registration are stored in the register file, which can be run electronically.

The German Commercial Register has an exceptionally long tradition. In recent years, some modernization took place, establishing electronic registers. The structure of the stored information was not changed. Compared to Estonia, it looks old-fashioned and not sufficiently focused on the broader needs of the information society.

The legal provisions for the Commercial Register can be found in sections 8 to 12 of the German Commercial Code and in the Commercial Register Ordinance [45].

The register consists of two sections: section A for sole traders, legal persons, general partnerships, limited partnerships, and the European Economic Interest Groupings; and section B for corporations, joint-stock companies, limited companies, and mutuals.

A legal basis for keeping the Commercial Register in electronic form was established with the Register Procedure Acceleration Act of 1993 [46]. It required the introduction of a single electronic register of company information databases, and since 2007, the Commercial Register has been fully electronic. The entries can be declaratory or constitutive.

The information in the register is in German. General information can be found in other languages. Both the submission and filing of the registration applications must be performed electronically with the standard EGVP (Elektronisches Gerichts- und Verwaltungspostfach).

In addition to the Commercial Register, the Bundesanzeiger keeps a company register containing index data from various registers but also additional information on bankruptcies, accounting/financial reports, and capital markets [47]. The legal basis is the Companies Register Act [48]. The German Company Register is linked to the Commercial Register Portal.

3.4. Austrian Firmenbuch

The Austrian Business Register (Firmenbuch) resembles the German Commercial Register. However, the change to the electronic version took place much earlier, in 1991. It has been in operation since 17 July 1991. The legal basis for this change is the Business Register Statute [49]. It constitutes a public register. Business has been integrated into the services of the justice system.

The Business Register contains the data of all Austrian business entities that are subject to registration (main register) according to the Austrian Business Code: sole traders, business partnerships, limited partnerships, joint-stock companies, limited corporations, mutuals, saving banks, associations, funds, European societies (SE, SCE), and other undertakings obliged to register.

The register contains the following entries: the firm, legal form of the company, location of the company and the business address relevant for delivery, website (joint-stock company and limited company), a short description of the business activities, branches, date of establishment of the Articles of Association, and the name and date of birth of the sole proprietor; with other legal entities, the authorized representatives, start and type of power of representation, name, and date of birth of authorized signatories; start and type of power of representation, business transition, restrictions on disposal and annulment of enforcement and insolvency law, and entries in the insolvency proceedings by the insolvency court. Electronic submission of annual financial statements to the Business Register was introduced in 2001.

The documents that are relevant to registration are stored in the electronic archive of documents of the justice system (Collection of Documents—Urkundensammlung). Applications should be filed electronically via Electronic Legal Communication (ELC). Decisions and invoices for fees are handled automatically.

Since 2009, all applications and documents received by the Business Register Courts and all orders and decisions issued by the Business Register Courts have also been stored electronically. Therefore, completely digital file management in Business Register proceedings is available.

Data from the Business Register can be retrieved by everybody through ‘clearing offices’ via the internet [50]. Public authorities have access to the Business Register via the portal of the Federal Computing Centre. In the Member States of the European Union, access is available via the European Business Register (EBR). Authorized licensees also can purchase Business Register data in a machine-readable format as embodied in the Austrian Statute on Further Use of Information [51]. In addition, the Business Register offers numerous interfaces with other (partly external) applications, which are supplied with data by way of a notification procedure or an exchange service.

Public announcements of the Business Register Courts are made fully automatically in the Database of Official Publications (Ediktsdatei) [52].

3.5. The Polish National Court Register

The public business information in Poland is maintained by two high-level institutions: The National Court Register and the Central Register and Information on Economic Activity. The first one stores all the information concerning the legal entities. The latter is devoted to the information on the business activity of citizens (natural persons).

The National Court Register (NCR) has been functioning since 1 January 2001, when it replaced the pre-World War II Trade Register. The NCR was created on the legal basis of the Statute on the National Court Register passed on 20 August 1997. The NCR underwent one vital reform in the meantime, as, initially, it was made up of three separate registers including (1) businesses; (2) associations, NGOs, and public health institutions, and (3) insolvent debtors. The result of the mentioned amendment is that from 1 February 2019, the insolvent debtors’ information was excluded from a completely new external system.

The Business Register is the most important one of the three formerly existing. The information deposited in it is segregated into six divisions. Those divisions are distinguished based on the generality of information and subject matters.

The system is managed by 27 branches of the National Register Court, distributed across 21 regional courts, ensuring straightforward geographic jurisdiction assignment. Additionally, 51 regional information centers provide offline access to registry information. Initially, the system operated in a non-computerized format, with all changes and registrations handled on paper. Today, access to data in traditional form is still available, albeit for a fee, while online access has been available since June 2012. Printed electronic documents hold the same legal validity as official documents issued by the central information office. However, the online system’s architecture is occasionally inadequate, leading to accessibility issues—a critical shortcoming for a service of such importance to trade relations [53].

The traditional system is criticized for its inefficiency. One of the reasons for poor system performance is that each application that implies whatever change in the register must be approved by the judge. The Statute on the National Court Register asserts that a change in the register’s state should be effective within 7 days of the application. To facilitate access to the register and modernize the registration process, the S24 portal has been introduced on 1 January 2012. S24 is the NCR on-line interface. It allows undergoing some NCR processes completely using electronic means only. When using the S24 system, an entity may be registered electronically but only provided that some restrictions are met. The limitations encompass the legal form of the entity (only three out of six are admitted). Furthermore, the articles of association that are registered with S24 must conform to the general template provided, so that only some normative aspects within the entity may be adjusted.

3.6. European Blockchain Services Infrastructure

European Blockchain Services Infrastructure (EBSI) is a blockchain-based services infrastructure being built by the European public sector [54]. It comprises a peer-to-peer network of interconnected nodes, with each member of the European Blockchain Partnership (EBP) running at least one node. These nodes are responsible for creating and broadcasting transactions, updating the ledger, and ensuring the synchronization of identical ledger copies across the network. EBSI is being developed iteratively, starting with a limited number of use cases, and gradually expanding over time. The initiative started in 2018 and, among others, was meant to provide a unified solution to verify legal entities [55].

As of January 2025, EBSI remains in the development phase and has yet to transition into full production. Several pilot projects are underway to evaluate EBSI’s feasibility and potential for broader adoption [56].

Despite its potential, EBSI must overcome several challenges to achieve its production phase and fully realize its objectives. First and foremost, various stakeholders must be encouraged to participate in the use cases while defining their roles within EBSI’s governance structure. Secondly, the availability and interoperability of EBSI-compliant digital wallets are essential for user adoption. Standardizing data schemes for various credentials is critical for seamless exchange and verification. Finally, EBSI needs to be integrated with existing and emerging digital identity systems, such as eIDAS 2.0 [30], and national initiatives, as it will allow for broader integration and acceptance.

4. Blockchain Alignment Framework

The discussion on the elaborated alignment framework starts with presenting the possible blockchain-based architecture of business registries. Architecture is especially feasible in the EU zone; however, in a more general approach, there is no geographical limitation. We perceive the EU zone as a good exemplification of the use case. The Framework design process is described in detail (Section 4.2). The blockchain categorization was developed based on the results of the literature review. Identified criteria were grouped into certain, topic-centered groups. In Section 4.4 and Section 4.5, an analysis of the requirements of registry groups is presented. Those requirements are divided into functional/non-functional and legal/technical ones, as well as assigned to IS clusters, namely security, infrastructure, and business. A security analysis of the solution presented concludes in Section 4.6.

4.1. The Blockchain-Based Architecture of EU Business Registries

Figure 2 presents a proposed high-level architecture for blockchain-based EU business registries, serving as a decentralized alternative to the European Central Platform. In this model, member states are directly interconnected, with each state maintaining its infrastructure to support both local information and, partially or fully, data from other states. This redundancy is characteristic of blockchain systems and significantly mitigates the risks of successful D/DoS attacks while reducing the need for extensive backup infrastructure. The architecture streamlines and diversifies the flow of cross-border information by enabling direct access to the source member state’s infrastructure, bypassing the central platform. This shift enhances data protection by improving integrity and potentially confidentiality, rather than focusing solely on efficiency.

In a public blockchain design, any entity—whether a legal entity, organization, or individual—can join the network as a peer alongside state infrastructure, unless the network is permissioned. In a permissionless system, a peer node could theoretically access and update on-chain data with ease, enabling businesses to manage their information. Some countries already permit similar forms of ‘self-governance’. However, this raises significant concerns regarding data placement responsibility and, more critically, the quality and accuracy of the information.

In the scenario described, we opted for a permissioned blockchain for optimized properties of the system. The E-Justice Portal can be reused to facilitate integration and management. As mentioned in Section 2.2, decentralized systems can bring or improve on various characteristics of legal systems, which is why we expect them to excel in the currently operating solutions. Further sections present and instruct on using the framework.

4.2. Framework Design

Several authors proposed various models to classify blockchain technology or support the decision process while choosing the appropriate technology for a specific application [57]. Wüst and Gervais propose such a model that works kind of as a decision process [58]. It is thus like the framework described herein. However, the commented model is very narrow and simplified. It considers only three broad types of blockchain. In this article, a framework for blockchain classification for the needs of the public registry is defined.

The objective of the framework is to allow selection or at least substantially ease the decision process of choosing the right blockchain architecture types presented in Section 2.3 for a limited group of public registry applications considering the challenges and possibilities presented in Section 2.2. This aim is consistent with several analytical tasks proposed in the Multidisciplinary Blockchain Research Framework [59]. The expected path of reasoning on the requirements of the projected system is presented in Figure 3. This figure presents the steps of the design. The elements that correspond to or are employed within each step are described in detail in the following sections.

A decision-maker will in principle be a system analyst who either studies the feasibility of blockchain architecture to be used in a public registry service system or which designs the public registry service system according to some well-established methodology and needs to properly administer the specified requirements to the most suited blockchain configuration.

4.3. Blockchain Categorization Application

In the following section, the earlier analysis of blockchain types presented in Section 2.3 and Section 2.4 will be applied to explore the interrelations and further identify some common groups.

Specifically, we refer to Table 2, which outlines various blockchain criteria and types of related work. The number of types and criteria is also preserved according to the information presented in the reference part of the article.

Making any generalizations or assumptions about the typology is complicated because of the factors mentioned in this part of the related works analysis. Different authors use diverse terms for the same concepts, and these may be treated as synonyms. The criteria are also interrelated, making it difficult to create a unified typology. For example, some criteria overlap, like “Cardinality of maintaining parties” and “Permission”, though some see them as distinct. Different interpretations of the same criteria, such as anonymity and trust, add further complexity to classification.

By analyzing the gathered criteria, one may set apart certain groups (see

Table 3. Blockchain architecture criteria groups.

Group Name	Grouped Criteria
Access-right	1, 2
Functional	3, 7, 8, 9, 17
Verification	5, 6
Computation	4, 10

). The groups are topic-centered. The functional group reflects the different approaches in which blockchain is related to the information. The verification group, in turn, brings together criteria that deal with the issue of verification capabilities both outside and on-chain. The common denominator for the computation group is the manner and extent to which blockchain performs computing operations.

Clusters related to information systems focal areas (IS clusters) may be considered as another—parallel—categorization of criteria. The mentioned areas include infrastructure, business context, and security-related aspects. It should also be noted that not all blockchain criteria from Table 2 were included in the resulting clustering due to their specificity.

The infrastructure cluster covers all criteria related to the technical implementation of blockchain-based information systems solutions: data item storage (8), data structure (7), and item collection (9). The cardinality of maintaining parties (1) belongs to two clusters: infrastructure (because it sets a context for the whole infrastructure development) and security (because it is a basis for security policies, as well as authentication and authorization rules). Security cluster includes also permissions (2) and verifier (5). Moreover, consensus protocol (6) has its place in this cluster as the stability and fault proof of the whole system depending on these criteria, as well as belonging to the business cluster because it is defined according to the business needs and business model the system is used for. Other business-related criteria are cryptocurrency dependency (3), design patterns (17), smart contract functionality (4), and computation (10).

Figure 4 presents a blockchain classification matrix. It shows dependencies between two different criteria classifications: groups and clusters. Access-right and verification groups include criteria mainly from the security cluster since security is a common ‘umbrella’ that connects both aspects. The functional group includes those criteria from infrastructure and business clusters that relate to the aspect of a blockchain, while the computation group focuses more on the mathematical model behind a specific blockchain. As explained above, two elements, (1) and (6), belong to two different clusters since they are related to security, but, at the same time, influence decisions about infrastructure or business.

4.4. Common and Specific Requirements of Registry Groups

Information systems are typically designed around a two-part framework of functional and non-functional requirements. Functional requirements specify the actions users can perform with the system, defining its outcomes. Non-functional requirements, in contrast, describe how the system operates, including its performance characteristics.

For public ledger systems, this traditional approach can be further refined by categorizing requirements based on their source: technical or legal. Technical requirements address the operational functions of the registry system, derived from system analysis and practical needs. Legal requirements, however, stem from the public nature of the registry and its normative obligations. They are described in Section 2.2. Public ledgers, as a distinct subset of information systems, demand particular attention to these legal aspects, which include the following:

• Legal basis—registry must be established and maintained under a specific normative act.
• Legal norms conformance—includes adherence to the founding act, compliance with broader applicable laws, and temporal alignment to reflect amendments in vital regulations.
• Legal binding—registry data are legally guaranteed as trustworthy.
• Admissible as evidence—registry information can be presented in court without additional authentication.
• Legal authority—the existence and administrative powers of the managing or founding entity.

These two requirement categories—technical and legal—are distinct but interconnected and can be analyzed in parallel, as shown in

Table 4. Public registers requirements matrix with exemplary requirements.

	Legal	Technical
Functional	Print-out has legal significance equal to an official document	Search entities by legal form
Non-functional	Legal status depends on and reflects entries	Allows storage of information on 2 million objects with full financial documentation
	Source: normative acts	Source: design/users’ needs

. Functional requirements must balance both the legal requirements and the practical needs essential for a registry system to function effectively.

4.5. Observation of Registry Mapping Procedure

The following section intends to present how the artifacts provided in the above sections may be used according to the procedure suggested in further sections. The whole procedure consists of five steps. These steps consist of the creation of a requirements set; adjustment of the requirements according to their types; transformation of requirements from specified types into information systems focal areas clusters; traversal through the design questions list; and filtering out appropriate blockchain types. The following performed activities are described below.

In the first stage of the procedure, the requirements that characterize the projected public register are gathered. For example, a comprehensive list of varied prerequisites that the information system hosting such a public register must fulfill has been identified. The extracted set of conditions embraces items enlisted in

Table 5. Requirements extracted from the description of public registries.

#	List of Requirements	Comment
R1	Number of nodes	Centralized system with many end-user interfaces.
R2	Read–write permissions	Which actors have the right to access information?
R3	Online access for legal significance/temporal validity	How can the information be accessed?
R4	Print-out has legal significance equal to an official document	What is significance medium dependence?
R5	Availability	The system must be operable in a broad time range.
R6	Accuracy (timelines)	The time needed to change data after the triggering event.
R7	Documents storage	Will the system allow storing additional information? What is the structure of data?
R8	Real-time data presentation	The delay between data alteration and their accessibility by end-user.
R9	Payments	Availability of diverse payable and non-payable services.
R10	External interfaces	Interoperability of the system.
R11	Official acknowledgments (e.g., taxpayer has debt)	Security and flexibility.
R12	Public statistics access	What kind of statistical data are produced? How and by whom can it be traced?
R13	Trusted profile infrastructure interoperability	Is the system aware of security technologies? How efficiently can it cooperate with them? What kind of actors/roles are distinguished?
R14	Number of records	The minimum number of information items a system is capable of persisting and processing.

.

The second step in the procedure consists of relaying the assembled prerequisites into the matrix that differentiates them into groups according to two orthogonal dimensions: functional–non-functional and legal–technical (

Table 6. Transformation of the list from Table 5 into a public registers’ requirements matrix.

	Legal	Technical
Functional	R1, R3, R4, R9, R11	R2, R7, R10, R12
Non-functional	R6, R13	R5, R8, R14

).

The conversion of the declared constraints into information systems focal area clusters is another step (

Table 7. The result of the translation of the public registers requirements matrix from Table 6 towards IS clusters.

Cluster	Requirement
Security	R2, R6, R13
Infrastructure	R5, R7, R8, R10, R14
Business	R1, R3, R4, R9, R11, R12

). In most cases, this is a straightforward task that assumes the existence of standard mappings between the above matrix into slots that represent the three clusters. Nevertheless, one should be vigilant, as critical consideration may suggest a better yet atypical placement of some specific requirements.

The last stage consists of drilling down the design question list to establish the characteristics of the eligible blockchain system. The design questions are organized according to the three distinguished clusters (a full set of design questions is provided in Appendix A).

The analyst begins at the diagram’s start point (Figure 5) and follows a path based on answers to queries in rounded activity boxes, which lead to conditional forks. Rectangles indicate candidate blockchain types, and crossing one suggests it as a primary choice. Multiple activity boxes may be traversed, resulting in a combination of blockchain types best suited to the requirements, though some combinations may be mutually exclusive.

The last step is the reconstruction of the best-fitted blockchain type based on desirable characteristics determined previously. The results are segregated according to groups of blockchain types. These groups are already indicated in Table 3.

4.6. Security Analysis of the Blockchain-Based Approach

In Section 4.1, the idea of the blockchain-based architecture for UE business public registers is shown. It was mentioned that the proposal, although it has a few interesting properties, needs to face numerous vulnerability concerns as well, to prove useful. It was also pointed out that different models towards privacy and data access are possible within this presented new approach. An analysis of the most important issues that may have an impact on the overall safety and utility of the discussed architecture is provided below and summarized in

Table 8. The most important threats present in the blockchain-based architecture of business public registers. VH—very high, H—high, M—medium, L—low, VL—very low.

Threat Category	Public Entities Only		Private Entities Allowed
/Susceptibility	Permissioned	Permissionless	Permissioned	Permissionless
1. Data privacy and GDPR compliance
- cross-border data sharing	VL	L	VL	VL
- right to be forgotten	M	M	H	H
2. Data integrity and fraudulent entries
- false (synthetic) data (automated) input	VL	VL	H	VH
- varied data quality	VL	L	H	VH
- uncontrolled validation	L	M	H	VH
3. Smart contract vulnerabilities
- code exploits	VL	L	M	H
- upgradability issues	L	M	M	H
4. Consensus mechanism and governance risks
- consensus attacks	L	M	L	VL
- governance disputes	M	H	L	L
- jurisdictional issues	L	M	H	H
5. Other technological threats
- breaking encryption (quantum computing)	L	L	L	L
- information leakage (side-channel)	M	M	H	H
6. Decentralization and node trustworthiness
- node control and trust	L	M	M	M
- Byzantine fault tolerance	VL	M	L	L
- conflicting business interests	VL	L	H	VH
7. Interoperability issues
- differing security standards	H	H
- cross-chain interoperability risks	L	L	VL	VL
8. Key management and identity verification
- compromised private keys	M	H	H	VH
- authentication vulnerabilities	H	M	M	H
9. System data overload
- data pollution	VL	L	H	VH
- spam	VL	L	H	VH
10 Distributed denial of service (DDoS) attacks
- network integrity	VL	L	VL	VL
- infrastructure	M	L	VL	VL
11. Insider threats and malicious actors
- collusion between parties	VL	L	H	VH

. Part of the aspects mentioned here result from Section 2.2.

Ensuring data privacy and General Data Protection Regulation (GDPR) Compliance becomes challenging when blockchain nodes are spread across multiple jurisdictions. Personal and sensitive data may be stored on multiple nodes, making it harder to enforce consistent data protection rules. Moreover, blockchain’s immutable design conflicts with GDPR’s “right to be forgotten”, posing a significant challenge in balancing immutability with the legal obligation to delete data.

While the “right to be forgotten” may conflict with blockchain-based public business registers, its application could be limited due to the public interest these registers serve. GDPR allows exceptions for legal obligations and public interest. Technological solutions, like storing hashed data or implementing controlled access, could help reconcile immutability with legal requirements. Exploring these solutions is key to ensuring compliance without compromising the blockchain’s integrity.

Another group of endangerments involves data integrity and fraudulent entries. Allowing private parties to update critical information opens the system to the risk of fraudulent or incorrect data entries. Companies might deliberately or accidentally enter false information, such as bogus headquarters locations or fake executive profiles, potentially to avoid legal oversight, taxation, or accountability. Particularly, in an open system, ensuring the accuracy and legitimacy of data entered by private parties becomes challenging. Public entities would need robust mechanisms to verify and validate every change made, which could be resource intensive and slow down the system.

When it comes to node trustworthiness, since multiple public entities across various EU countries would be involved, there is a risk that some nodes may not be adequately secured. This raises concerns about ensuring that all nodes can be trusted to act in the network’s best interest. If malicious or compromised nodes start behaving unpredictably or feeding incorrect data into the blockchain, the system must be resilient enough to handle such situations.

A blockchain system can achieve resilience against malicious or compromised nodes through robust consensus protocols, such as Proof of Stake or Byzantine fault tolerance, which are designed to tolerate a certain proportion of malicious behavior while ensuring only valid data are added to the blockchain. Additionally, the system’s distributed architecture provides data redundancy, preventing a few compromised nodes from overriding the majority. Advanced techniques like node reputation systems and behavior monitoring enhance security by detecting and isolating malicious actors. Exploring these approaches in the context of public business registers presents an important area for future research.

If the smart contract infrastructure is part of the solution, other vulnerabilities may materialize. If smart contracts are used to manage business data or handle automated updates across registries, vulnerabilities in the contract code could be exploited. These could lead to unauthorized changes to business records, financial fraud, or other malicious actions. Moreover, patching smart contracts on a blockchain is complex due to the immutability of the ledger. Fixing a vulnerability might require deploying a new contract, potentially causing downtime or data inconsistencies.

Governance disputes and jurisdictional issues may become another threat to the system. As the system would involve multiple countries and public administrations, disputes over governance, protocol upgrades, or changes to the ledger could arise. Lack of clear, enforceable governance rules could lead to fragmentation or a “fork” in the blockchain, causing confusion and mistrust. Additionally, if private companies operate across different jurisdictions with varying regulations, it becomes harder to enforce consistent rules regarding what data must be entered, how it must be verified, and what the consequences of fraudulent data are.

Allowing private parties to directly access and modify data on a blockchain-based public registry system introduces even more significant risks. While it could improve efficiency, transparency, and self-service capabilities, it also exposes the system to at least higher data integrity risks, insider threats, fraudulent activity, increased attack surfaces, and regulatory challenges.

5. Discussion and Conclusions

5.1. Addressing the Security Concerns

Presentation of the catalog of possible endangers that may be introduced by switching the business public registers architecture from centralized to blockchain-based is by any means conclusive. The identification of potential vulnerabilities merely opens the space for further exploration and analysis of risk mitigation strategies. Future research should focus on assessing these vulnerabilities in specific use cases and developing respective frameworks. Selected security issues are discussed below.

In the case of personal data privacy, a few mitigation instruments can be suggested. They encompass such potential solutions as zero-knowledge proofs (ZKP), off-chain storage with on-chain pointers, encryption with selective disclosure, tokenization of personal data, and privacy-focused blockchain architectures (i.e., permissioned ledgers as described earlier). Some other steps may also be further taken to tackle the fraudulent entries processing with a particular focus on automated attacks and synthetic data generation. Those steps include digital identity (DID) verification and strong authentication, notarization and proof of authenticity (e.g., using oracles), business rule validation via smart contracts, regular auditing and data integrity monitoring, whitelisting and blacklisting of entities, timestamping and immutable audit trails, role-based access control (RBAC), and voting mechanisms for major changes. The pointed means of protection will be addressed briefly below.

The system can prevent fraudulent entries by malicious actors impersonating legitimate companies or administrators by ensuring that only authorized entities with verified identities can input or modify data. This can be achieved by implementing decentralized digital identity solutions and strong multi-factor authentication (MFA) requirements before any entity (including private companies) can input data onto the blockchain. Digital identities should be cryptographically verified and tied to legal documents or credentials.

A significant reduction in the risk of fraudulent entries or incorrect information being uploaded to the system may be accomplished with the introduction of elevated security-level external validation procedures. This ensures that any change to the blockchain is authentic and verified by trusted third parties. Thus, before a company can modify or input new data (e.g., changing its headquarters address), external validators or oracles will verify the information using trusted third-party sources, such as government records or financial institutions.

Another approach to this issue may involve some crypto- or token-omics solutions. It could be used in the form of incentives or stakes, which could be lost in case of misappropriate node-entity behavior.

One can use automated validation to reduce the risk of fraudulent or incorrect entries by requiring that information updates conform to predefined rules and standards. Fraudulent data are rejected automatically. Smart contracts are especially appropriate to enforce such business rules that automatically validate the correctness of new entries. For example, when a company submits a change in executive staff, the smart contract cross-checks legal or financial requirements (e.g., proof of registration, and tax records) before allowing the update to proceed.

Regular auditing and data integrity monitoring are mechanisms that should be set up for continuous or periodic auditing of blockchain data to detect inconsistencies, suspicious activity, or anomalies that could indicate fraud. Such regular audits would ensure that any fraudulent entries are detected and corrected quickly. Blockchain’s transparency allows auditors to trace any questionable data back to its origin, providing accountability and reducing fraud.

5.2. Implications for Policy and Practice

When discussing the utility of the application of blockchain architectures in the public sector, the factor of rationality is the plain imperative for assessing architectural suitability. Rational design is one in which either additional benefits outweigh associated costs or no further gains are encountered, yet the drawbacks or trade-offs of the solution are diminished. There is a growing pressure of expectations towards blockchain technology in terms of its capabilities and revolutionary or disruptive outcomes. Some of these expectations have been voiced in terms of public projects and have been mentioned in the beginning section of the article. Such pressure and the creation of overwhelming anticipations are not proper for two reasons. It introduces potential misunderstandings and pushes the trend of applying the technology for all possible tasks, even when it is not meant to be successful.

In terms of public services, the benefits of decentralized design may be threefold: seamless scalability; improved security; and public information access. The scalability means not only the easy possibility of extending the network with new nodes (i.e., member states from an international perspective). The accession of new member states into EU structures is an occasional event. Nevertheless, it has taken place a couple of times in history. The process may also work in the opposite direction as it is in the case of Brexit. The primary benefit is the effortless incorporation of different parties within the already functioning member states’ infrastructure. In real life, many actors use the information gathered in the business registers. The stakeholders are not merely businesses that need viable and trustworthy information about their counterparts. Such information is tremendously important to sustain a thriving and reliable business environment in each member state, as well as in the whole European Union. However, other groups of stakeholders use public records. Those are diversified public institutions like tax authorities or social security authorities.

To improve security, one should understand a feature of no single point of failure (accessibility). Cyberattacks on public infrastructure are not a rarity [60,61]. An excellent example is the sabotage efforts on eastern European countries during the ongoing conflict in Ukraine, which started in 2014. That is why the issue of ensuring uninterrupted access to crucial services is of utmost importance. It is especially vital in the case of warfare actions. In cases of redundant infrastructure, the level of security against D/DoS attacks is increased. On the other hand, the blockchain design of service systems allows an organizational memory of a given state to be backed up seamlessly in multiple copies for a modest rise in resource consumption. Moreover, it is easily achievable to maintain nodes on other member states’ infrastructure. But, one needs to keep in mind that decentralization always comes at a cost.

In Section 4.1, a high-level architecture for EU business registries was proposed. It is a blockchain-based alternative to the current European Central Platform. In this decentralized model, each EU Member State maintains its infrastructure. This setup enhances security by reducing the risk of D/DoS attacks and eliminates the need for a central backup system. Data access routes are shortened, increasing data protection in terms of integrity and confidentiality. In a public blockchain, any legal entity or individual can join the network and potentially write data, which is an important issue. Such a situation may raise concerns about data placement responsibility and the quality of information. That is why, generally, it should be assumed that the public and the permissionless network are hardly probable because of acceptance by regulatory bodies, as well as compliance with the adhered norms.

5.3. Future Work

The Blockchain Alignment Framework presented in this paper was built for the public registries’ domain. As a future work, the authors plan to continue its development by enhancing distributed ledger taxonomy. The current Framework is based on the taxonomies found in the literature; however, the technological landscape in this domain is constantly changing, and, thus, there is a need to further unify different approaches.

Another research direction is to examine the Framework transferability into different domains, such as land registries or intellectual property databases. Additionally, the aspects of implementation costs and compliance with particular legal regulations like GDPR are interesting ideas for expansion.