GDPR-Compliant Academic Certification via Blockchain: Legal and Technical Validation of the GAVIN Project

Abstract

For years, combining the immutability associated with blockchain technology with the European Union’s General Data Protection Regulation (GDPR) has been considered a practically unsolvable conflict due to the very nature of blockchain and the GDPR. This article presents the GAVIN project (GDPR-Compliant Blockchain-Based Architecture for Universal Learning, Education and Training Information Management), a pioneering initiative that overcomes this challenge through an innovative technical and legal approach to trusted digital academic certification. Developed by atlanTTic (University of Vigo) and funded by the European Union, GAVIN proposes a scalable architecture that combines off-chain storage, encrypted Hash-Based Message Authentication Code (HMAC) anonymization, access notarization, and blockchain-based access control. The legal validation of the working prototype under development demonstrates that blockchain decentralization is compatible with GDPR compliance. The model is presented as a replicable reference for institutions wishing to leverage distributed ledger technologies without compromising personal data protection. This paper details the legal design, technical architecture, and compliance mechanisms, offering a practical framework for implementing decentralized systems with privacy by design.

1. Introduction

The digitization of educational records has amplified the demand for secure and verifiable systems capable of long-term data retention [1], fraud prevention [2], and global interoperability [3]. Traditional centralized systems are vulnerable to institutional discontinuity, technological obsolescence, and malicious manipulation. Blockchain [4] is a technology characterized by decentralization, transparency, and cryptographic security, and due to these features, it offers potential solutions to these challenges. Nevertheless, the integration of blockchain into personal data processing domains, particularly education, raises significant regulatory concerns, especially regarding compliance with the General Data Protection Regulation (Regulation (EU) 2016/679, hereafter GDPR) [5], as it will be later discussed in more detail in this article.

This paper investigates the GAVIN project (GDPR-Compliant Blockchain-Based Architecture for Universal Learning, Education and Training Information Management), a pioneering initiative that overcomes the challenge of issuing and verifying academic information through an innovative technical and legal approach to trusted digital academic certification. It was developed by atlanTTic (University of Vigo) and funded by the European Union as a real-world implementation of a GDPR-compliant academic certification model [6] using blockchain and seeks to answer whether it is legally and technically feasible to align blockchain-based certification with GDPR principles. We aim to assess its legal soundness and technical viability, proposing it as a referential model for institutions seeking to leverage distributed ledger technologies in compliance with data protection standards.

This research contributes to the field in several ways. First, it provides a comprehensive legal analysis of the GAVIN model, a GDPR-compliant blockchain-based framework for academic certification. Second, it bridges the gap between technical implementation and regulatory requirements, validating that the model adheres to personal data protection principles. Finally, it introduces an architecture that can inspire similar initiatives in other sectors requiring both decentralization and legal compliance.

The remainder of this paper is structured as follows. Section 2 introduces the legal and technological background necessary to contextualize the work, while Section 3 reviews the most relevant related studies in the field and GDPR challenges un blockchain systems. Section 4 describes the methodology applied to conduct the legal analysis of the model. Section 5 presents the technical architecture of the GAVIN system, and Section 6 carries out a detailed GDPR compliance assessment. Section 7 offers a discussion of the main findings and open challenges, and finally, Section 8 concludes the paper and outlines directions for future research.

2. Legal and Technological Background

Despite the regulatory difficulties associated with the integration of blockchain in personal data processing environments, its application in the field of academic certification presents important key differential advantages. First, it allows for the generation of immutable records that guarantee the integrity of certificates, preventing fraud or manipulation. Blockchain technology enables the notarization of information and prevents malicious users from altering it. In the event of modification by authorized users, there is always a record of who changed the information and when. This approach is not always possible in centralized systems. Second, the blockchain-based model considered facilitates the verification of credentials in a decentralized manner, even if the issuing institution disappears, something that is not possible with centralized systems. Furthermore, the traceability, censorship resistance, and international interoperability offered by blockchain make it a viable solution to address the growing need for portable, verifiable, and permanent certificates in global contexts of academic and professional mobility. These characteristics position it as an ideal mechanism to complement traditional systems (personal data remains stored in the centralized systems of the issuing institutions), but these are often limited by institutional dependence, lack interoperability, and are vulnerable to manipulation or cyberattacks. Blockchain acts as a digital notary, certifying that the data has not been altered.

2.1. General Data Protection Regulation (GDPR)

GDPR [7] is a comprehensive legal framework adopted by the European Union in 2016 to strengthen and harmonize data protection across member states. Its primary purpose is to safeguard individuals’ fundamental rights and freedoms, particularly their right to privacy, in the context of personal data processing.

The GDPR establishes key principles that govern data handling, including lawfulness, fairness, and transparency; purpose limitation; data minimization; accuracy; storage limitation; integrity and confidentiality; and accountability.

These key principles (

Table 1. GDPR’s main articles.

Article	Principle	Description
GDPR, art. 5.1.a	Lawfulness, fairness and transparency.	Personal data shall be processed lawfully, fairly and in a transparent manner in relation to individuals.
GDPR, art. 5.1.b	Purpose limitation.	Personal data shall be collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall not be considered to be incompatible with the initial purposes.
GDPR, art. 5.1.c	Data minimization.	Personal data shall be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed.
GDPR, art. 5.1.d	Accuracy.	Personal data shall be accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay.
GDPR, art. 5.1.e	Storage limitation.	Personal data shall be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes subject to implementation of the appropriate technical and organisational measures required by the GDPR in order to safeguard the rights and freedoms of individuals.
GDPR, art. 5.1.f	Integrity and confidentiality (security).	Personal data shall be processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures.
GDPR, art. 5.2	Accountability.	The controller shall be responsible for and be able to demonstrate compliance with.
GDPR, art. 16	Right to rectification.	The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement.
GDPR, art. 17	Right to erasure (right to be forgotten).	The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies: (a) the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed; (b) the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing; (c) the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2); (d) the personal data have been unlawfully processed;
GDPR, art. 20	Right to data portability.	The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided;
GDPR, art. 22	Right not be subject to a decision based solely on automated processing.	The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her;
GDPR, art. 25.	Data protection by design and by default.	Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures (…) in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.

) aim to ensure that personal data is processed in a responsible, secure, and transparent manner, empowering individuals with greater control over their information while imposing obligations on organizations that collect and manage such data.

Additionally, it is important to note that the GDPR establishes a series of key figures in the processing of personal data, each with well-defined responsibilities:

• Data Subject: This is the natural person who owns the personal data. They have the right to control how their information is collected, used, and protected.
• Data Controller: This is the entity, which can be either an organization or an individual, which decides what personal data is collected, for what purpose it is processed, and what means are used. Although it may outsource processing, it remains the primary guarantor of compliance with the GDPR and must ensure that data processing is legitimate, transparent, and secure.
• Data Processor: This acts on behalf of the Data Controller, performing operations on personal data in accordance with their instructions. They are required to implement appropriate technical and organizational measures to ensure data protection and comply with the provisions of the GDPR. We should point out that personal data processing is any operation or set of operations performed on personal data or sets of personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction, in accordance with Article 4 of the GDPR.

2.2. Blockchain

Blockchain technology emerged in 2008 with Satoshi Nakamoto’s [4] publication as the basis for the Bitcoin cryptocurrency. Since then, its use has expanded beyond the financial sector with cryptocurrencies into the supply chain [8], the medical sector [9], and Decentralized Finance (DeFi) [10], among other examples, establishing itself as a decentralized data structure that distributes information among nodes belonging to a peer-to-peer network. This technology allows data to be grouped into blocks linked together using cryptographic techniques, thus forming an unalterable chain. Each block contains a set of transactions (or other data depending on the use case), as well as a hash pointer that references the previous block, ensuring the integrity of the recorded information.

One of the most relevant features of blockchain is its ability to offer immutable and verifiable records without relying on a trusted third party. This makes it an attractive option for systems where traceability, transparency, and tamper resistance are priorities.

There are different types of blockchain, each with different technical and legal implications:

• Public blockchain: These are completely open networks where any user can participate by sending transactions, operating nodes, or even mining new blocks. Although this model guarantees high transparency and censorship resistance, it has significant limitations in terms of scalability and privacy. All stored information is visible to all participants, which implies total data exposure. Although encryption can be used, its use in immutable environments poses future risks due to the obsolescence of cryptographic algorithms, especially with the emergence of technologies such as quantum computing. Representative examples of this model are Bitcoin and Ethereum [11].
• Private blockchain: Unlike the previous model, private blockchains are managed by a centralized organization that restricts access to authorized nodes. This type of implementation allows for greater control over the network, improving both efficiency and privacy. Frameworks such as the Linux Foundation’s Hyperledger Fabric [12] enable the development of these types of solutions, adapted to contexts where confidentiality and performance are essential, such as in the financial or corporate sectors.
• Consortium or federated blockchain: This approach combines elements of public and private networks. They are maintained by a group of organizations that share governance of the system. Although participation is restricted, certain levels of openness for public consultation can be enabled. This balance between controlled decentralization and privacy enables its use in inter-institutional collaborative contexts, such as higher education.

Generally speaking, an inherent limitation of blockchain networks is their processing capacity [13]. Distributed verification, which guarantees the security and integrity of the system, leads to lower performance compared to centralized architectures [14]. In the case of public blockchain networks, they present limitations in terms of processing capacity due to the distributed consensus mechanism, which can negatively impact the scalability and latency of the system. However, this limitation depends on the blockchain solution, since developments such as Layer 2 solutions [15] (e.g., Polygon or Arbitrum [16]) have significantly improved scalability in public networks such as Ethereum. Furthermore, permissioned blockchains, such as Hyperledger Fabric, allow much higher transaction rates to be achieved by operating in closed and controlled environments [17,18], which greatly mitigates this limitation [19]. Additionally, recent studies have focused on optimizing the performance of consensus mechanisms used in permissioned blockchain networks, such as Practical Byzantine Fault Tolerance (PBFT) [20]. These improvements are particularly relevant for improving scalability and fault tolerance in permissioned environments, specially consortium blockchains [21,22,23,24,25] and even in large-scale deployments [26].

In the case of the GAVIN model, based on a consortium blockchain created with Besu [27], this restriction is also significantly reduced, although the trade-offs between performance, security and decentralization posed by Buterin’s Trilemma [28] must still be considered.

It is also important to note that there is an active debate about the relevance of permissioned blockchains since, as mentioned in the previous paragraph, public blockchains are increasingly offering improved performance. It is true that permissioned networks offer greater privacy and performance, but they also entail higher outlays, as the network must be deployed and maintained, and its maintenance requires a degree of centralization. However, several recent studies show that these platforms remain widely adopted in the business world. In a comparative analysis of permissioned platforms [29] the authors conclude that these networks “are increasingly used in the industry” and highlight their technological maturity, the activity of their communities and their balanced performance/privacy relationship, but it depends largely on the use, corresponding, for example, to the deployments of cryptocurrencies or other public exchanges to permissionless networks, while more business-like operations, where efficiency and privacy prevail, are deployed in permissioned blockchains (although they are much less widespread than public ones) [30] but each one has its pros and cons [31] even within the different permissioned ones [32]. However, it must be taken into account that there are also studies that indicate that permissioned systems tend to re-centralize control in the hands of consortia, contradicting the principle of decentralization of the blockchain and making this technology, in many cases, unnecessary and no longer used, as in the case of Supply Chain [33] and others [34]. This is because permissioned systems reproduce centralized power structures, as they depend on a trusted authority to grant permissions and control access, which limits the transparency and openness that characterize public blockchains. [35]. However, in some environments they are still used, so their application or not should be carefully analyzed [36]. Some relevant examples of initiatives built on permissioned blockchains include the European Blockchain Services Infrastructure (EBSI https://ec.europa.eu/digital-building-blocks/sites/display/EBSI/Home, accessed on 15 July 2025), which is developed using Hyperledger Besu. This infrastructure represents a major policy initiative by the European Union and the European Blockchain Partnership, aimed at leveraging blockchain technology to create cross-border services for public administrations, businesses, citizens, and their respective ecosystems. Its core objective is to facilitate information verification and to foster trust in digital processes. Alastria (https://alastria.io/en/home/, accessed on 15 July 2025), a consortium blockchain platform in Spain based on Ethereum (Quorum and Hyperledger Besu), brings together more than 500 companies, public administrations and universities to develop services. Another example is eNaira [37], launched by the Central Bank of Nigeria in 2021 as a retail Central Bank Digital Currency (CBDC) [38] in a two-tier hybrid architecture that uses Hyperledger Fabric to issue and distribute the digital currency designed to serve payments, public aid, and remittances.

Another key component of the blockchain ecosystem is smart contracts. Initially conceived by Nick Szabo [39], these smart contracts are programs that execute automatically when certain conditions are met. Although not exclusive to blockchain, their implementation within these networks ensures autonomous, unalterable execution without the need for intermediaries. Ethereum [40], one of the most well-known platforms, has popularized their use since its launch in 2015.

The synergy between blockchain and smart contracts has given rise to multiple innovative applications as described earlier in this section.

The implementation of blockchain in education has attracted growing academic attention since 2013 [41]. It is perceived as a promising solution to revolutionize the issuance and verification of academic information, particularly in relation to its potential for enhancing trust, transparency, and portability of credentials. Blockchain allows the automation of processes such as issuing certificates [42], tracking academic achievements [43], and verifying credentials [44], among other use cases [45,46,47]. These features guarantee the validity of records to be verified without the need for human intervention. However, the regulatory implications in this sector (especially compliance with the GDPR) remain unresolved. This issue will be discussed in the Related Works Section.

In short, blockchain technology, with its ability to offer a secure, immutable, and distributed ledger, along with smart contracts, provides a solid foundation for revolutionizing the management of formal, non-formal, and informal academic information. This article will explore how these technologies can be effectively implemented in the education sector, offering a GDPR-compliant solution for the issuance, storage, and verification of academic data and the verification of this compliance is the objective of this paper.

3. Related Works

This section reviews relevant contributions in two main areas: (1) the use of blockchain for educational credentialing, and (2) the legal challenges of aligning such systems with European data protection standards. A final subsection highlights the limitations of existing models and positions the GAVIN project within this research gap.

3.1. Blockchain in Education

Numerous academic contributions have explored the application of blockchain to educational certification. Grech and Camilleri [41] argued that blockchain can enhance the trustworthiness and portability of academic records. Sharples and Domingue [48] envisioned lifelong learning passports stored on immutable ledgers. More recently, Turkanović et al. [49] presented EduCTX, a decentralized platform for credit exchange. These works primarily emphasize technical feasibility and educational innovation. A comprehensive review of blockchain-based academic certificate verification systems is provided by [42], highlighting a wide range of platforms and approaches used to ensure transparency, data security, and cost-effective maintenance of educational records. Under a different thematic focus, Saadati et al. [43] explore the development of a blockchain-based learning management system aimed at fostering self-regulated learning in online higher education, integrating metacognitive tools to support planning, monitoring, and reflection. Arenas and Fernández [44] present CredenceLedger, a permissioned blockchain solution designed to enable decentralized and verifiable storage of academic credentials, emphasizing secure and transparent access for stakeholders.

After reviewing relevant systematic reviews of the blockchain literature in the education sector [45,46,47,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72], it is concluded that blockchain in this field is applied with very varied approaches, although the issuance and validation of academic certifications are its most frequent use case [46,47], but in these initiatives little attention is paid to something as relevant as the protection of personal data, in general, and compliance with the GDPR, in particular. Most models lack robust legal compliance and verification, which undermines their applicability in real-world educational contexts [46].

While there are numerous initiatives aimed at applying blockchain technology in the educational sector very few of them except [6,73] consider aspects as crucial as compliance with data protection regulations such as the GDPR.

Although this work does not aim to carry out a technical evaluation of the model’s performance (focusing instead on its legal compliance), it is still possible to establish some relevant differences with respect to the existing proposals. More precisely, we refer to the only known initiative specifically focused on GDPR compliance. This initiative is based on the same model [6] used in GAVIN and also includes a previous work using Non-Fungible-Tokens (NFTs) to issue and validate academic accreditations [74].

More specifically, it is relevant to compare the proposed model with the alternative developed by Molina et al. [73], also focused on GDPR compliance in the educational context.

Table 2. Comparison of academic data certification models with a focus on the GDPR.

Feature	GAVIN (This Article)	Molina et al. [73]
Number of blockchains	A combination of private and consortium blockchains is used to improve scalability.	It does not clearly mention whether it uses more than one blockchain.
Partial data sharing	Sharing only certain parts of academic information is allowed (for example, title only, no grades).	It does not explicitly mention this aspect.
Data regeneration in case of data loss	A strategy is offered to recover certificates even if the issuing institution disappears.	It does not explicitly mention this aspect.
Scalability	Solutions are proposed for managing large volumes of academic data.	Not specifically addressed.
Prototype	There is a prototype in development with current blockchain technology.	It does not explicitly mention this aspect.

summarizes this comparison, highlighting the main differentiating elements between the two proposals:

3.2. GDPR Challenges in Blockchain Systems

The GDPR enshrines principles such as the right to erasure (“right to be forgotten”, Art. 17), purpose limitation (Art. 5.1.b), and data minimization (Art. 5.1.c), which are difficult to implement in immutable, decentralized environments. Finck [75] categorizes blockchain as “technology at odds with the GDPR,” noting irreconcilable conflicts between inalterable ledgers and dynamic regulatory rights. The European Data Protection Board [5] stresses that data controllers remain responsible, regardless of technological constraints.

Blockchain’s main features (immutability, decentralization, and transparency) come into conflict with several core principles of the GDPR, particularly when blockchain is used to store or reference personal data. These tensions revolve around the following key areas:

• Immutability vs. the Right to Erasure (“Right to be Forgotten”).
  • Regulatory Issue: Under Article 17 of the GDPR, data subjects have the right to request the erasure of their personal data. Blockchain, by design, ensures that data written to the ledger is immutable and cannot be deleted.
  • Conflict: If personal data (e.g., student names, transcripts, or identifiers) are stored directly on-chain, this may conflict with the ability to comply with erasure requests. Even if off-chain storage is used, references or hashes may still be considered personal data.
• Data Minimization and Purpose Limitation.
  • Regulatory Issue: GDPR enshrines data minimization (Article 5(1)(c)) and purpose limitation (Article 5(1)(b)), personal data should be collected only when necessary and for specified, explicit purposes.
  • Conflict: The transparency and redundancy of blockchain means that data is replicated across multiple nodes, which can challenge the principle of data minimization. Once on-chain, it is also difficult to limit or redefine purposes for which data is used.
• Lawfulness, Fairness, and Transparency of Processing.
  • Regulatory Issue: Article 5(1)(a) requires processing to be lawful, fair, and transparent.
  • Conflict: In blockchain systems, especially decentralized ones, data subjects may not have a clear understanding of how their data is processed or who the participants (nodes) are, which limits transparency and undermines informed consent (Article 7) [76].
• Pseudonymization vs. Anonymization.
  • Regulatory Issue: GDPR does not apply to anonymous data but continues to apply to pseudonymized data if re-identification is possible (Recital 26).
  • Conflict: Blockchain implementations often use pseudonymous identifiers (e.g., public keys), but these can sometimes be linked to individuals using auxiliary data, meaning GDPR still applies.
• Identification of the Data Controller in Decentralized Systems.
  • Regulatory Issue: The GDPR requires the identification of a data controller, the entity that determines the purposes and means of processing personal data (Article 4(7)).
  • Conflict: In public, permissionless blockchains, there is often no clearly identifiable data controller or centralized authority. This undermines the accountability and governance structures expected by GDPR.
• Cross-border Data Transfers.
  • Regulatory Issue: GDPR restricts the transfer of personal data outside the EU to jurisdictions that do not ensure adequate protection (Chapter V).
  • Conflict: Public blockchains involve international nodes, making it difficult to control or monitor data flows. This potentially constitutes unlawful international data transfer under the GDPR.

Additionally, as noted in Section 3.1, there are very few academic initiatives specifically focused on resolving the conflict between issuing and verifying academic credentials and strict GDPR compliance. Some proposals choose to record only the hash digest of academic information, rather than storing the full data on the blockchain.

The first institution to issue certificates using blockchain is considered to be the University of Nicosia [41]. In 2014, they recorded the hash digest [77] of academic information (not the full data) on the Bitcoin network, so that anyone could verify its authenticity simply by comparing the hash digest of the data with the information stored on the Bitcoin blockchain. It was an innovative proposal for its time, but very manual. The MIT Media Lab initiative, which created Blockcerts [78], is somewhat more elaborate. This is an open-source development that can be used in Bitcoin and Ethereum, storing the hash digest of the information in the corresponding blockchain for later verification.

In these cases, the certificate data is not stored, but only its hash digest. This means that if the holder of the academic information loses it and the institution disappears, it can no longer be used.

A slightly different approach is that of Alumnichain [79], which stores academic credentials in a private blockchain based on Hyperledger Fabric, something that the GDPR, as already mentioned, does not consider an option since it is a non-erasable storage medium.

While the approach of storing only the hash digest may initially seem compatible, given that hash functions are unidirectional, the GDPR itself and regulatory bodies such as the Spanish Data Protection Agency (Agencia Española de Protección de Datos—AEPD) and the European Data Protection Committee (EDP) warn that the use of hashes alone is not a valid anonymization technique. Consequently, this practice does not exempt data controllers from legal obligations relating to personal data since, according to [5,80], a hash digest of data is not a valid anonymization technique under the GDPR perspective.

In a traditional centralized information storage system, there is a central node that determines what information, when and where it will be stored, as well as who will have access to it and with what level of privileges, as well as the relationships with third parties. Therefore, in a traditional centralized system, the central node will be the data controller, and the third parties that collaborate (subcontractors, suppliers, etc.) will be the data processors. A personal data controller, in accordance with Article 4 of the GDPR, is the natural or legal person, public authority, agency, or other body that, alone or jointly with others, determines the purposes and means of processing. If Union or Member State law determines the purposes and means of processing, the controller or the specific criteria for its nomination may be laid down by Union or Member State law. A data processor is a natural or legal person, public authority, service, or other body that processes personal data on behalf of the data controller.

However, blockchain is a distributed information storage technique, in which there is no centralized or hierarchical management of the information (decentralization). This technique uses consensus policies (algorithms) to validate the information included by each node and policies to detect the integrity of the originally recorded data and check whether the recorded information has been altered. Therefore, to understand the specific blockchain model, we must understand its constituent elements, which are basically:

• A participation policy that establishes the conditions under which and with what role one participates in the network.
• A distributed information storage policy.
• A data sharing policy.
• A consensus policy to validate new information in the system.
• An information integrity management policy.

In addition, blockchain governance is necessary to define:

• Who can access or participate in the network;
• With what permissions;
• What levels of service are provided;
• Block validation strategies;
• Traceability of information, etc.

The implementation of blockchain technology itself does not constitute the processing of personal data. Rather, it will be the use or various uses made of this blockchain that will give rise to one or more processing operations of personal data.

However, it must be taken into account that blockchain technology, regardless of the number and type of processing that can be implemented on it, will require a series of processing operations for its own management, such as:

• Recording transactions on the blockchain, which requires transforming the data into operations valid for the blockchain.
• Validating transaction blocks, proceeding to verify them according to the selected consensus mechanism.
• Implementing other additional processing operations that a node can perform on transactions, such as managing pending transactions, reordering them, storing historical data, processing events associated with smart contracts, providing data and services to applications, etc. In this sense, the use of a specific blockchain infrastructure as an element for the processing of personal data could generate specific non-compliance and risks to the rights and freedoms of data subjects. One of its key aspects is ensuring compliance with data protection principles, as well as allowing the exercise of data subjects’ rights, and particularly the principle of accuracy, the principle of retention, and the rights of rectification and erasure.

Furthermore, taking into account the provisions of Recital 15 of the GDPR: “In order to avoid a serious risk of circumvention, the protection of natural persons should be technologically neutral and should not depend on the techniques used.” Compliance with this regulation must be guaranteed. In this regard, the European Data Protection Board has stated that technical impossibility cannot be invoked to justify non-compliance with the requirements of the GDPR, especially considering that Article 25(1) of the GDPR establishes that data protection by design shall be taken into account at the time of determining the means of processing and at the time of the processing itself.

As established by the Spanish Data Protection Agency (AEPD) [81]:

“Compliance with the GDPR in the processing of personal data using one or more blockchain infrastructures requires two phases:

(1)

ensuring regulatory compliance and once achieved,

(2)

evaluating and assessing the risks, some of which can be mitigated with legal, organizational, and technical measures. In cases of high risk, the assessment of the suitability, necessity, and proportionality of the processing must be completed.”

Another factor to consider is that due to the relocation of nodes, international transfers of personal data may be taking place, which must comply with the GDPR provisions in this regard.

4. Methodology

This manuscript is structured around a clear and well-defined central research question: “Can blockchain technology, from a legal perspective and in compliance with the GDPR, serve as a valid and legitimate infrastructure for the registration and certification of academic degrees?”

Our primary methodological framework is based on doctrinal legal research, which is widely recognized as the core methodology in legal scholarship. This approach involves the systematic analysis, interpretation, and evaluation of legal sources (legislation, case law, regulations, and academic commentary) to answer normative legal questions [82,83,84].

In alignment with this methodology, our research proceeds through the following steps:

• Definition of the normative legal question: Can a blockchain-based model for academic certification comply with the GDPR, particularly concerning data protection principles such as data minimization, purpose limitation, and the right to erasure?
• Comprehensive legal source analysis: Examination of relevant EU primary and secondary legislation (especially the GDPR), official regulatory guidance (e.g., EDPB—European Data Protection Board, CNIL—Commission Nationale de l’Informatique et des Libertés), and pertinent case law from the Court of Justice of the EU).
• Synthesis with existing legal doctrine: Integration of academic literature addressing blockchain, privacy law, and data protection compliance.
• Doctrinal interpretation: Interpretation of the GDPR core principles in light of the facts and architecture of the proposed model.
• Application and conclusion: Reasoned legal judgment regarding whether the proposed architecture satisfies these requirements, along with a discussion of limitations and possible regulatory developments.

This perspective allows us to analyze not only the formal legality of the model but also the design principles and governance mechanisms that ensure compliance in practice.

The assessment was guided by GDPR principles (Art. 5), rights of data subjects (Chapter III), controller and processor responsibilities (Chapters IV and V), and with special attention to data minimization, pseudonymization, international transfers, and joint controllership.

The developments described in the manuscript are not hypothetical or proprietary. The GAVIN project delivers a working blockchain-based solution for academic credentialing, and its technical and legal architecture is publicly documented. This guarantees replicability and allows other researchers and institutions to examine, test, and potentially adapt the model for alternative domains, such as health records or professional certifications.

Moreover, in this article we explicitly detail the legal reasoning, criteria applied, and interpretations followed, ensuring transparency and enabling scholarly scrutiny and debate. As such, the research fulfills a key objective of legal scholarship: to critically evaluate and inform policy and regulatory developments through a structured and systematic normative inquiry.

The legal-technical architecture proposed could inform further empirical studies, comparative legal analyses, and sector-specific adaptations of blockchain-based identity and credentialing systems. By bridging legal scholarship and digital innovation, the article contributes original insights to a rapidly evolving and socially significant area of inquiry.

The validation presented in this work is of a doctrinal-legal nature, focusing on the interpretative consistency of the model with GDPR requirements. While empirical testing of legal and organizational adoption remains a complementary line of future research, our current contribution rigorously addresses the model’s legal compliance through analysis of binding norms, guidance from data protection authorities, and relevant legal doctrine.

5. Technical Architecture of the GAVIN Model

The GAVIN project aims to build an academic certification model based on blockchain architecture to overcome the shortcomings of current certification systems. These include the lack of standards for managing long-term academic certificates worldwide. This is due both to a lack of persistence, which occurs when the issuer ceases operations or ceases to exist, and to the potential circulation of counterfeit certificates, which represents a legal challenge for society.

The legal validation of the GAVIN model, the main objective of this work, requires knowledge of both the model itself and its technical architecture for the construction of a prototype [85]. For this reason, this section presents the technical implementation of the system, a necessary basis for analyzing its compliance with the GDPR. Unlike purely conceptual studies, the approach adopted here focuses on verifying the regulatory compliance of a real, prototyped model, whose technical decisions determine key aspects such as the legality of processing, traceability, and the guarantee of rights. This technical dimension is, therefore, inseparable from the legal analysis developed in the following section. Academic certification should be understood as any type of learning accreditation, from regulated educational programs to the validation of professional competencies and informal training, professional training in companies, online courses, continuing education courses, letters of endorsement, etc. Therefore, it should be understood in a broad sense.

5.1. Derivation of the Requirements of the Theoretical Model

For academic certification, the theoretical model analyzed in this paper must meet the following conditions or premises. The technical requirements presented below are the result of a systematic requirements engineering process, based on the key principles of the GAVIN model [6]. First, interviews were conducted with legal, institutional, academic, and technical experts to gather the functional and non-functional requirements that a system like the one proposed should satisfy. Then, following formal techniques supported by the specialized literature on requirements engineering [86], these premises were translated into technical requirements aligned with criteria such as privacy, integrity, interoperability, and performance. Finally, these requirements were validated through presentations and iterative reviews with key stakeholders, ensuring documented traceability from their conceptual origin to their technical implementation. Therefore, this model and prototype have been refined and adapted specifically to respond to the identified challenges of academic certification.

• Compatibility with existing systems: It must be possible to use this system without modifying the existing information systems of academic/training institutions or other organizations that issue certificates or academic information and accreditations. This is a key point since the usefulness of this solution goes hand in hand with its massive adoption and given that most issuing institutions store their data in their proprietary systems [6], the system’s ability to adapt to reality is crucial for its success.
• Format flexibility: It must be flexible enough to accommodate different types of academic information, accreditations, etc., regardless of the underlying information models and it must be usable in all types of education: formal, non-formal, and informal. This is defined in the model as a fundamental requirement, since the idea is that it supports the verification of any type of academic certification without format or content restrictions.
• Independence of the issuing institution: It must be possible to verify the validity of the certificate content and associated accreditations even after the dissolution of the institution that originally issued the certificate and all its information systems. Since it is considered that any duly authorized institution can issue academic certifications according to the previous point, it is not ruled out that some will disappear and therefore, a premise of the developed system is that it continues to function even in this scenario.
• Operational scalability: It must be scalable and capable of supporting transactions and operations related to the registration, verification, and query of information by the model’s end users. As also explained in [6] to set this requirement, millions of academic certificates [87] are registered in the world every year, so the solution must be scalable to accommodate them.
• Regulatory compliance: It must comply with personal data protection regulations, and particularly with the GDPR in cases where it affects individuals located in the European Union, which is the subject of validation in this report.
• The model, as already explained, is based on the scientific publication entitled “Application of Blockchain in Education: GDPR-Compliant and Scalable Certification and Verification of Academic Information” [6], which presents the system developed by GAVIN.

This section details the technical architecture designed in the GAVIN project to create a blockchain-based initiative that complies with the GDPR. The design follows a privacy-by-design approach, incorporating both off-chain and on-chain components to manage credential data securely and transparently. The architecture is modular and scalable, aiming to support institutional collaboration through a consortium-based governance model. The following subsections describe the core components and mechanisms that ensure both compliance and operational efficiency.

5.2. Off-Chain Data Storage

To comply with GDPR requirements, particularly the rights to rectification and erasure, the considered model [6] stores academic information on institutional off-chain servers and on blockchain anonymized personal data to enable verification of this academic information. GAVIN, the practical implementation of [6], stores identifiable data off-chain on secure institutional servers and the on-chain proposal is implemented by storing only hashed representations (Hash-based Message Authentication Code—Secure Hash Algorithm 3–HMAC-SHA3) [88] of credentials, which are signed by the issuing entity, are stored on the blockchain.

There are different solutions to anonymize personal data such as generalization or differential privacy [5]. However, in the case of GAVIN, which is the subject of this GDPR compliance analysis, and the model on which it is based, HMAC-SHA3 functions are chosen because they follow the recommendations of the Spanish Data Protection Agency (AEPD) on the use of hash functions as an anonymization technique [80]. This choice guarantees data integrity, cryptographic verifiability, and effective protection against re-identification, key aspects in blockchain environments. In the case of GAVIN, not only is an HMAC-SHA3 generated for each field with a secret key, but this data is also structured in a Merkle Tree, and the process is repeated recursively up to the root, reinforcing the information anonymization process and allowing for selective sharing, as explained in the following section.

It is important to note that the use of HMAC functions with per-field secret keys allows for effective anonymization of personal data by avoiding direct correlations between real data and identifiers. However, its effectiveness depends largely on proper key lifecycle management. In this model and prototype, it is assumed that secret keys are generated per field and per issuing entity and are not shared between systems. Furthermore, they must be stored in secure environments with restricted access and full traceability.

The system includes mechanisms for random key generation, periodic key rotation, access logging, and integrity validation, all with the aim of reducing the risk of accidental exposure or misuse. In the event of a key compromise, the per-field nature of the key allows the scope of the attack to be limited to a single attribute, preventing mass re-identification. These measures are essential to maintain the system’s resilience to external threats, and are aligned with the EDPB’s recommendations on anonymization for GDPR compliance [80]. In general, all keys used in the system must be managed securely.

5.3. Blockchain Layers, Access Control and Use Scenarios

The conceptual model is presented in the following Figure 1:

In the proposed model, three main actors are identified: H, the holder of the academic data; E, the entity issuing the certificates; and T, the authorized third-party verifier. Unlike other approaches that transfer all data to the blockchain, in this architecture the original academic information (c) remains stored in the issuing institution’s internal systems, thus preserving institutional control over the records. What is generated to verify authenticity is a structured manifest (m), represented as a Merkle tree [89]. This scheme allows the different elements of the certificate to be organized hierarchically and flexibly, adapting to heterogeneous academic data structures.

Each branch of the tree represents an information node in accordance with the issuing entity’s data model. In addition to the academic content, additional metadata such as certificate validity, expiration dates, internal storage references, or unique identifiers can be integrated. For each element in the tree, an HMAC value is generated with SHA3, using a unique, secure secret key to reinforce privacy and protect against preimage or length extension attacks. This key, different for each piece of data, is shared between the issuing entity and the data subject. This guarantees both authenticity and the possibility of sharing information in a granular manner, without having to expose the entire set. The value resulting from applying HMAC to each element in the tree is encrypted using the issuing entity’s private key, thus generating an anonymized version of the data (h), which is stored in a smart contract called SCService, deployed on a private blockchain. This network is accessible through an API, allowing its integration with existing IT systems without the need for structural redesigns. Along with this encrypted information, other non-personal data can be stored, such as internal identifiers, pointers to the original database (se), or validity indicators, giving the model great versatility without compromising privacy. The private blockchains used in this scheme are managed by consortia of institutions, organized according to geographic or functional criteria. The data recorded on these networks can be periodically synchronized with a federated consortium blockchain, which consolidates non-personal information from the different private blockchains. Each recorded transaction is immutably reflected in the chain, preventing retroactive manipulation by members of the participating institutions. Any attempt to alter or delete an academic record without authorization will be traced thanks to the use of the SCLog smart contract, which keeps an unalterable record of all interactions and access.

The proposed system includes three main components:

• SCData: A smart contract stored on a consortium blockchain that stores the anonymized values of credentials, implemented using HMACs in the developed prototype.
• SCAccess: A smart contract stored on the consortium blockchain that verifies access permissions granted by data subjects. In the current implementation of the project a Blockchain Application Firewall (BAF) [90] controls data queries and enforces user permissions, functioning as a decentralized access gateway, but this element could not necessarily be used in other implementations as it will be later discussed.
• SCLog: A smart contract in charge of registering all access to the information.

Once the verification data (h) is recorded in the consortium blockchain, access is governed by the SCAccess contract, which maintains control over permissions and authorizations for verification purposes, both by the holder (H) and, where applicable, by the issuing entity (E). The data stored in the SCData contract is always anonymous; it does not allow direct identification of the holder, but it does allow verification of the validity of the linked academic information, provided that T has the corresponding authorization.

The system contemplates various validation scenarios depending on the level of access desired by the holder:

• Scenario 1: Full verification: H sends T the full certificate along with the manifest (m), including all the keys necessary to reconstruct the Merkle tree. T requests the encrypted value (h) from the SCAccess contract, verifies it against SCData, and checks its integrity.
• Scenario 2: Partial verification: H decides to share only part of the academic content. To do so, he transmits to T only the relevant elements and verification paths of the Merkle tree. After receiving the encrypted tree root from SCData (after authorization validated by SCAccess), T can verify that the partial information corresponds to a valid, unrevoked certificate.
• Scenario 3: Direct query to the issuing authority: H delegates the delivery of the information to T to E. In this case, T accesses the database pointer (stored in SCData), and after its authorization is validated in SCAccess, it can obtain the certificate (c) directly from E. This interaction is logged in SCLog.

It should be noted that in scenarios 1 and 2, the system can continue to function even if the issuing entity disappears, since its direct intervention is not required for verification. However, if both E disappears and H loses its keys, data recovery would be unfeasible. To mitigate this risk, the model provides that, in the event of an institution’s cessation of activity, academic information will be transferred to a distributed storage system, controlled by smart contracts and encrypted with keys previously shared between E and the authorized data subjects. In this context, if the data subject intentionally destroys their key, or if the issuing institution’s key ceases to exist, the stored data would become inaccessible. This loss, being irreversible, could be interpreted as an effective way to comply with the right to be forgotten under the GDPR, given that the information would be permanently encrypted beyond recovery. The procedure for granting access is for the data subject to expressly authorize a third party, identified on the platform, to access the data necessary to verify the academic information. This verification data is stored on the blockchain so that it cannot be accessed without the corresponding permission. Furthermore, the data is hashed with an HMAC- SHA3, and the result is subsequently encrypted.

From a technical perspective, GAVIN implements the model considered in the implementation of a consortium blockchain based on Ethereum technology with several private blockchains, following the model presented in the previous point, and offering the following functionalities:

• Store any type of academic information in a free format.
• Implement smart contracts on the platform.
• Allow the interconnection of blockchains (consortium).
• Implement storage with a blockchain-based access control system [91], where data is stored encrypted and access is restricted to the data subject.

The theoretical model presented is technology-agnostic, and there are some issues that current technology does not easily address. Therefore, the technical reference model considered meets the requirements of the proposed model, including GDPR compliance, but must also address some challenges.

To complete the system architecture, there will be another blockchain or equivalent with a distributed storage system and an access control mechanism that would serve as a backup in the event that an institution ceases to exist or disappears, and the user does not have their academic certifications. They could be recovered from this system as long as the institution issuing the academic data records them there before disappearing. Access to this information will be controlled, and it will be the data subject’s decision to allow the records to be sent to this backup infrastructure in extreme cases in which the institution issuing the academic information disappears. Note that this does not affect the verification of academic data, which can continue to be performed normally with the rest of the designed system. Its usefulness is limited to scenarios in which the issuing institution disappears, and, at the same time, the data subject loses the academic information that can be shared with a potential verifier. In the case of the prototype developed at GAVIN, a distributed storage based on MariaDB [92] was used, in which the academic data of certain users will be stored encrypted, with a sufficiently robust encryption system and using a different secret key known to the data holder and generated by the academic institution.

In addition to being encrypted, the data in this distributed database is not directly exposed to the Internet. Instead, a private Ethereum-based blockchain is used to perform effective access control [91]. It is responsible for storing a record identifier mapped to the database table (regid) and the address of the account authorized to access said data (address).

Thus, in the technical implementation, when a given user H wants to retrieve their data, they make a request to the system, which is responsible for checking whether or not they have permission, verifying through a signature from the user themselves that they own a certain blockchain address (address). If so, user H is returned the regid associated with the address (address). Furthermore, during the execution of this access control process, an event is generated that records access to the blockchain for the purpose of retrieving the data. This event is saved in a system access log for retrieving academic certificates. Once the user has obtained the RegID corresponding to their academic data, they can connect to the MariaDB database and request the stored content associated with that RegID. The database returns the stored data in encrypted form, and the user can decrypt it using the key k, which only they know. This approach ensures that, even if the RegID of the encrypted data is known, only the authorized user who possesses the corresponding key k can decrypt and access their academic data.

5.4. Consortium Governance, Interconnection and Scalability

In order to guarantee the governance and scalability of the platform based on blockchain, the GAVIN project employs a multi-layered architecture:

• Multiple private blockchains, managed by academic institutions.
• A central consortium blockchain aggregating anonymized information to verify academic information and verifying access rights.

This model ensures scalability, interoperability and resilience in the event of institutional dissolution.

It is important to note that implementing an academic certification system in an educational environment, comprising institutions with diverse regulations, organizational structures, and technical standards, poses significant challenges from a scalability perspective. In this context, the GAVIN model has been designed with a distributed architecture that allows each issuing institution (or several of them, grouped according to interests or other criteria such as geography, etc.) to operate its own private blockchain, compatible with the consortium nodes, thus preserving its technological autonomy without the need for homogenization.

This strategy allows for horizontal scaling by incorporating new institutions without affecting the main network. Furthermore, mechanisms for process parallelization and asynchronous data synchronization with the consortium’s blockchain have been planned, thus reducing bottlenecks and allowing a certain tolerance to latency arising from educational contexts with different technological capacities or peak demand, such as the end of the school year. Although this work does not delve into an empirical evaluation of performance under these conditions, the architecture is designed to be agnostic to the source system and adaptable to different regulatory frameworks, which is a key requirement in real-life educational settings.

The technical reference model used in GAVIN project is presented in the following Figure 2:

The main difference observable between Figure 1, which represents the initially proposed design [6], and Figure 2, which shows the component architecture considered for implementing a prototype using real-world technology, is that the consortium blockchain has been split into two separate blockchains. This change was made because it is not technically feasible to restrict access to data stored on a blockchain (specifically, the data contained in the Access smart contract) if access to that blockchain is granted. Therefore, in the GAVIN project, the consortium blockchain has been divided into two distinct blockchains: one is responsible, through the SCAccess contract, for verifying, granting, and revoking access permissions to academic verification data, while the second blockchain is where the actual academic verification data resides. However, it is important to point out that the current technology for interconnecting these Consortium blockchains using Inter-blockchain Communication (IBC) has a relevant limitation [93]: when an origin blockchain makes a query to an external blockchain, the result of this interaction is also recorded in A. This behavior represents a challenge in terms of privacy, since it could allow an unauthorized user (U), with read access to the initial blockchain, to view evidence of queries previously made by legitimately authorized third parties (T), potentially exposing protected academic information without U having the right to access it. Since this behavior does not derive from a defect in the proposed model, but from technical restrictions inherent to current blockchain platforms, an intermediate security solution was implemented in the GAVIN prototype: the BAF [90]. This additional layer is located between the verifying party (T) and the blockchain where the SCAccess is located. In networks such as Ethereum, third parties access the blockchain through the JavaScript Object Notation- Remote Procedure Call (JSON-RPC) interface, connecting directly to specific nodes of the system to issue transactions or make queries. This method exposes a critical risk: any entity capable of executing RPC calls could extract information publicly stored on the blockchain, including data previously verified by other users, even without specific authorization. This problem stems from the fact that, by design, many current blockchain platforms restrict modification of stored data, but not its viewing. Some solutions allow for some level of access control, but these are typically limited to per-account permissions rather than at the node level, which is insufficient for the proposed model, which requires more granular access management. Given this situation, GAVIN incorporated the BAF as an intermediary mechanism. This middleware acts as an intelligent filter, evaluating incoming requests before allowing their transmission to the blockchain node. Its operation is based on predefined rules that determine whether a specific request meets the criteria necessary to be accepted. For example, if a third party (T) attempts to access information contained in a specific smart contract within the blockchain where SCAccess is located, the BAF will validate whether T has the necessary permissions and, only if so, will allow the request to pass; otherwise, it will deny it. In this way, the BAF enables flexible, efficient, and adaptable access control, avoiding unnecessary exposure of sensitive data and complying with regulatory requirements such as those established in the GDPR. It also prevents the abusive use of data stored in the blockchain for unauthorized purposes, such as the mass analysis of academic patterns. Furthermore, the model defines that all access requests must be logged. Ideally, this logging would be carried out in a specific smart contract (SCLog) deployed on blockchain A. However, achieving full on-chain traceability would entail considerable overhead in terms of storage and performance, compromising the system’s efficiency. As a temporary solution while blockchain technologies evolve in capacity, it has been decided to delegate detailed access traceability to the BAF, using a centralized database such as MariaDB. Access events are stored there, along with all relevant metadata. To maintain the integrity of this information, a periodic notarization mechanism has been incorporated: every 24 h (or at a specified frequency), a hash digest of the generated logs is calculated, and this value is stored in blockchain A via the SCLog smart contract. This hybrid technique provides an additional layer of trust. In the event of malicious manipulation of the log stored in the BAF database, any alteration would be detectable thanks to the discrepancy between the current hash and the one previously recorded in the blockchain. This guarantees a balance between operational efficiency and robustness in access traceability.

It is important to note that this paper does not exhaustively detail the internal architecture of the BAF nor present performance metrics; its design and operation have been documented in specific technical publications [90]. In this context, the BAF is presented as a valid solution aligned with the requirements of the GDPR, especially regarding granular access control and the traceability of reading operations, which cannot be directly recorded on the blockchain with current technology.

Another relevant point is that communication between blockchains introduces specific potential risks in terms of privacy and security, such as information exposure, message manipulation, or replay attacks. In the GAVIN model, these risks are addressed by implementing cryptographic verification and access control mechanisms [93]. In particular, the IBC YUI protocol employed enables message verification using Merkle proofs, nonce validation to prevent replay attacks, and the use of redundant relayers to mitigate failures and denial-of-service (DoS) attacks. Furthermore, transmitted data is anonymized by applying HMAC-SHA3 with random keys as described in Section 5.2, ensuring that information shared between blockchains remains confidential and tamper-resistant. These measures enable secure interoperability between different blockchains, aligned with privacy-by-design principles.

6. Legal Analysis

Although the central focus of this work is the analysis of GDPR compliance, the inclusion of this technical section is essential for two reasons. First, legal compliance cannot be assessed abstractly, but must refer to a specific technical system, whose design decisions condition essential aspects such as the legal basis for processing, the data controller, or the rights of the data subject. Second, this architecture represents the practical application of the previously analyzed theoretical model, allowing us to examine how the GDPR principles are implemented in a distributed and technologically viable environment. Therefore, this section serves as a necessary basis for the legal analysis developed later in Section 6, ensuring methodological coherence between the technical and legal dimensions of the study.

After analyzing the technical model described in the previous section, this one evaluates the GAVIN architecture’s compliance with the GDPR. The analysis applies a doctrinal legal method, examining how each key GDPR principle and data subject right is operationalized within the system. Particular attention is given to the distribution of responsibilities among actors, the feasibility of data subject rights enforcement, and the management of international data flows.

Operations in private and consortium networks require clearly defining the obligations and limits of each participating entity, not only from a functional or technical responsibilities perspective, but also in the processing of personal data. In this regard, the GAVIN model provides for the formalization of joint responsibility agreements in accordance with Article 26 of the GDPR, where specific functions (primary controller, processors, etc.) are assigned and data flows are documented. This contractual framework serves as a reference for other institutional consortia and could be adapted according to standardized contractual templates available in organizations such as the AEPD or the EDPB.

The subsections that follow correspond to the core legal dimensions evaluated during the project’s legal-technical validation process.

6.1. Scope of the GDPR

As a starting point, we must consider the material and territorial scope of application.

Regarding the material scope, it is evident that it falls within the scope of application whenever the project will process personal data contained in or intended to be included in a file.

Regarding the territorial scope, the project also falls within the scope of application whenever the GDPR applies:

• On the one hand, to the processing of personal data when the controller or processor (RT/ET) has an establishment in the EU, regardless of whether the processing takes place in the Union or not.
• On the other hand, to the processing of personal data of data subjects located in the Union by a controller or processor not established in the Union, when the processing activities are related to:

  ○

  the offering of goods or services to said data subjects in the Union, regardless of whether payment is required from them, or

  ○

  the monitoring of their behavior, to the extent that this takes place in the Union.

It is therefore clear that the GAVIN project will also be subject to territorial scope.

6.2. Personal Data Processed by the GAVIN Project

The GAVIN project aims to use a blockchain to store academic certifications (in the broadest sense as explained above), which is considered data processing, as defined in Art. 4.1 GDPR as any operation or set of operations performed on personal data or sets of personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or modification, extraction, consultation, use, communication by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction. It is evident that an academic certification will contain personal data, within the meaning of Art. 4.1 GDPR defines them as “any information relating to an identified or identifiable natural person (“data subject”); an identifiable natural person is any person whose identity can be determined, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.” Therefore, it is clear that these certificates may contain, but are not limited to, the following data, including personal data:

• Registration Identifier (Code).
• University Registration Identifier (Code).
• National Registration Identifier (Code).
• Surname.
• First Name.
• Identity Document.
• Gender.
• Date of Birth.
• Country of Birth.
• City of Birth.
• Country where the student currently resides.
• Student’s current city of residence.
• Postal Code.
• Student’s email address.
• Student’s phone number.
• Type of study.
• Degree.
• Area of specialization.
• Study ID.
• Issuing Entity ID.
• Start date of studies.
• End date of studies.
• Hours dedicated to completion.
• Number of academic credits (ECTS or equivalent).
• Language of study.
• Program subjects and content description.

Furthermore, as established by the Spanish Data Protection Agency, when a user of a blockchain-based system is a natural person, the public key or wallet address derived from the public key is also personal data, as is any unique identifier that can link that person’s activity within the blockchain infrastructure. Furthermore, we understand that under no circumstances will it be necessary, and therefore, special categories of personal data will not be processed. These are defined in Article 9.1 of the GDPR, such as those that reveal ethnic or racial origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data intended to uniquely identify a natural person, data relating to health, or data relating to a natural person’s sex life or sexual orientation. The processing of this type of data is prohibited, unless there is an exception to its processing as set forth in Article 9.2 of the GDPR. Likewise, we do not believe that the processing of data relating to criminal convictions and offenses or related security measures is necessary (Article 10 GDPR), as the processing of such data is also limited to being carried out under the supervision of public authorities or when authorized by Union or Member State law that provides appropriate safeguards for the rights and freedoms of data subjects. Furthermore, a complete record of criminal convictions may only be kept under the supervision of public authorities.

6.3. Implications for Compliance with the Principles of Article 5 of the GDPR

Article 5 of the GDPR sets forth the principles under which all personal data processing must be conducted, which constitute the core of this regulation. The following sections analyze the GAVIN project’s compliance with each of these principles.

6.4. Data Flows in the Model and Characterization of the Participants as Data Controllers, Processors, or Co-Controllers

The GDPR defines in Article 4.7 the “controller” or “data controller” as the natural or legal person, public authority, agency, or other body that, alone or jointly with others, determines the purposes and means of processing. If Union or Member State law determines the purposes and means of processing, the controller or the specific criteria for its appointment may be established by Union or Member State law.

It is, therefore, the key entity in a processing operation, as it tells us “who” processes personal data, and is therefore a sine qua non requirement for all data processing.

Thus, Article 5 establishes that the data controller (hereinafter the “TR”) will be responsible for compliance with the principles established in this Article 5 and, furthermore, must be able to demonstrate this (“proactive accountability”). Therefore, compliance is not enough; we must also have evidence of such compliance. Given the configuration of the GAVIN project, already described as a consortium blockchain, we can consider the possibility of several data controllers acting jointly, determining the purposes and means.

Therefore, in this case, we must take into account the provisions of Article 26 of the GDPR, which states:

• Where two or more controllers jointly determine the purposes and means of processing, they shall be considered joint controllers. The joint controllers shall determine, in a transparent manner and by mutual agreement, their respective responsibilities for compliance with the obligations imposed by this Regulation, in particular with regard to the exercise of data subject rights and their respective obligations to provide information referred to in Articles 13 and 14, unless and to the extent that their respective responsibilities are governed by Union or Member State law to which they apply. Such agreement may designate a contact point for data subjects.
• The agreement referred to in paragraph 1 shall duly reflect the respective roles and relationships of the joint controllers in relation to the data subjects. The essential aspects of the agreement shall be made available to the data subject.
• Regardless of the terms of the agreement referred to in paragraph 1, data subjects may exercise their rights under this Regulation against and against each of the controllers.

In this regard, it is important to emphasize that the joint controllers of the data processing and the blockchain platform must formalize a joint data processing agreement, without prejudice to the processing carried out by each institution on its blockchain, for which, in principle, they will be the sole controllers.

It is also essential to implement a governance framework that aligns with Article 26 and incorporates best practices recommended by supervisory authorities such as the European Data Protection Board (EDPB). This governance framework must include:

• A joint controllership agreement template, outlining:
  • Purpose and legal basis for processing.
  • Allocation of roles, defining clearly which institution handles data subject rights requests.
  • Mechanisms for accountability, documentation and audit.
  • Dispute resolution clauses
• A proposed enforcement mechanism based on:
  • Periodic governance audits.
  • A steering committee representing participating institutions.
  • Internal dispute resolution mechanisms and escalation paths.
  • Inclusion of these governance terms as binding clauses in consortium agreements.

On the other hand, it must also be taken into account that the blockchain platform or platforms described in this project will require an information systems service provider, most likely in the cloud, which may follow a Platform as a Service (PaaS), Infrastructure as a Service (IaaS), or Software as a Service (SaaS) model. In any case, we must remember that if the controller or joint controllers use a third party to provide these services (e.g., Amazon Web Services, Azure, etc.), personal data will be processed by that third party on behalf of the controller(s), a figure known as a data processor. This consideration is still under discussion and there is no definitive position on the matter from the Supervisory Authorities at the European level.

For these purposes, Art. Article 28 of the GDPR requires that the RT select a data processor that offers sufficient guarantees to implement appropriate technical and organizational measures to ensure that the processing complies with the requirements of the GDPR and guarantees the protection of the data subject’s rights. Furthermore, a data processing agreement or contract must be formalized between the data controller and the data processor, regulating the purpose, duration, nature and purpose of the processing, the type of personal data and categories of data subjects, and the obligations and rights of the controller, as well as any subcontracting, in accordance with the minimum content established in Article 28.3 of the GDPR.

These considerations are from a GDPR compliance perspective. Additionally, from a technical but also legal perspective, the literature concludes that outsourcing blockchain services to cloud platforms tends to centralize operational management, which can hinder some of the system’s inherent decentralization. For example, a comprehensive study of blockchain cloud services notes that, despite the rise in integration between these technologies, cloud computing still suffers from centralization, a lack of trust, and transparency, even before actual cloud deployment [94,95]. This coincides with findings on Blockchain as a Service (BaaS), where although technically promising, a strong dependence on third-party infrastructures is observed, which may compromise the operational sovereignty of the project [96]. In environments like GAVIN, where a consortium blockchain and different private blockchains are proposed, such an approach may be technically appropriate, provided it is designed with explicit operational governance mechanisms. In the GAVIN proof of concept prototype, to avoid these types of issues, deployments were carried out on on-premise equipment.

6.5. Application of GDPR Principles

The legal analysis of the GAVIN project validates compliance with the main GDPR principles:

• Lawfulness, Fairness, and Transparency (Art. 5.1.a): Clear privacy policies, user-informed consent, and transparent data processing.
• Purpose Limitation (Art. 5.1.b): Academic certification as the sole purpose, no other purposes being contemplated at present.
• Data Minimization (Art. 5.1.c): Only essential data is processed and stored off-chain. The data processed is only the HMAC (as recommended by AEPD [80]) and the final result is additionally encrypted before being saved on the blockchain.
• Accuracy (Art. 5.1.d): Regarding this right, the GAVIN project model can fulfill this right by deleting the HMAC of the previous academic certificate, rendering the data arbitrary, which would effectively amount to deletion. A new academic certificate could subsequently be generated with the correct data. In any case, it is worth mentioning that the issuing institution (I) should delete the data from its off-chain systems if permitted by law. It also marks the certificate as invalid, and access control mechanisms [91] ensure that no one can access it, in addition to deleting all related information.
• Storage Limitation (Art. 5.1.e): Data remains available only while necessary or archived under public interest exceptions.
• Integrity and Confidentiality (Art. 5.1.f): According to this article of GDPR, personal data must be processed in a manner that ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction, or damage, by applying appropriate technical or organizational measures (“integrity and confidentiality”). The principle of data integrity is fulfilled by the blockchain technique. Furthermore, we must note that confidentiality is also guaranteed, since the academic transcript data is not visible on the blockchain since an HMAC function has been applied to it and it has been subsequently encrypted. The developed prototype implements a firewall, specifically the so-called BAF [90], which prevents unauthorized access to verification data, although it is true that it is an element outside the consortium blockchain. The BAF performs filtering and access control, verifying which resources can be accessed within SCAccess (it is even possible that the BAF may consult the rules embedded in a blockchain to reinforce trust). In this way, any user with access to said blockchain is prevented from viewing data requested by other entities, thus limiting access to information for which they do not have permissions. This is because with current blockchain technology it is not possible to perform this dynamic segmentation of permissions between accounts considered in the proposed model, so this perfectly valid technological solution is used for its real implementation in the reference technical model. In summary, encryption, access logs, and tamper-proof chains ensure data security.
• Accountability (Art. 5.2): The GAVIN project has defined and implemented appropriate technical and organizational measures to ensure and demonstrate that the processing complies with this Regulation, since, as explained, a robust pseudonymization or anonymization system is in place. Therefore, the impact of an attack or security breach would be low, given that the data stored in the blockchain is the result of several HMAC generation processes with different keys and has been subjected to an encryption process. Furthermore, the BAF mechanism is in place, which provides additional security. It should be noted that the prototype records access notarization information (a hash summary of the log recorded in the BAF to potentially detect tampering) on a blockchain (equivalent to SCLog, defined in the model) so that traceability of what has happened to their data can be maintained. Likewise, the holder can always check in SCAccess who has access permission to their academic information, and the BAF records the accesses and periodically notarizes them on a blockchain to detect potential tampering. In this way, the holder could check who has accessed specific academic information and when. This is performed because current blockchain technology does not allow reading operations to be recorded, only those that modify data. This is how this article is fulfilled in the GAVIN Project.

6.6. Privacy by Default

Article 25 of the GDPR establishes that the data controller must adopt appropriate technical and organizational measures to effectively achieve compliance with the data protection principles and other requirements of the GDPR, with particular attention to the protection of the rights of data subjects.

These measures outlined in the GDPR are security measures, which may be technical, organizational, or other, but must be effective.

Logically, these security measures must be applied based on the state of the art, the cost of implementation, and the nature, scope, context, and purposes of the processing, as well as the risks of varying likelihood and severity that the processing entails for the rights and freedoms of natural persons. Consequently, security measures must be applied after a risk assessment.

Furthermore, these measures must ensure that they are applied in the very design of the procedure, that is, before its implementation. In this sense, we can affirm that the mere purpose of this report is already evidence of compliance with the principle of security by design. Furthermore, both the theoretical design and the technical reference model were also supervised by a legal team.

On the other hand, the data controller must also ensure that, by default, only personal data necessary for each of the specific processing purposes is processed. By “necessary data,” we mean not only the amount of data, but also the duration of processing (retention period) and access to said data, which must be restricted.

Regarding the principle of privacy by default, we understand that it is fulfilled for the following reasons:

• As explained, both the conceptual theoretical model and the prototype developed at GAVIN comply with the principles of the GDPR, including minimization, retention limitation, and purpose limitation, as already explained.
• Regarding access, the model restricts access to only authorized users to consult the information, which is also implemented with the BAF in the reference technical model.
• Access to data by service providers is managed by users, who can choose when to provide such access and can restrict it at any time. Furthermore, all access to the blockchain is recorded.

On the other hand, the system developed to recover academic information to the owner in the event of its loss or if the issuing institution disappears could consist of distributed storage with a blockchain-based access control system, where data is stored encrypted and access is restricted to the owner. This would be applicable when the issuing institution disappears.

In particular, to solve this requirement in this project, a distributed storage system based on MariaDB will be used, in which the academic data of certain users will be stored encrypted, with a sufficiently robust encryption system and using a different secret key known by the data owner (holder) and generated by the academic institution.

In addition to being encrypted, the data in this distributed database is not directly exposed to the Internet. Instead, a private blockchain based on Ethereum technology is used to implement effective access control. It stores a mapping between a record identifier and the database table (regid), and the address of the account authorized to access said data (address).

Thus, in the technical implementation, when a given user H wants to retrieve their data, they make a request to the smart contract, which is responsible for checking whether or not they have permission, verifying through a signature from the user themselves that they own a specific blockchain address (address). If so, user H is returned the regid associated with the address (address). Furthermore, during the execution of this access control process, an event is generated that records access to the blockchain for the purpose of retrieving the data. This event is saved in a system access log for retrieving academic certificates. Once the user has obtained the RegID corresponding to their academic data, they can connect to the MariaDB database and request the stored content associated with that RegID. The database returns the stored data in encrypted form, and the user can decrypt it using the key k, which only they know.

This approach ensures that, even if the RegID of the encrypted data is known, only the authorized user who possesses the corresponding key k can decrypt and access their academic data. As with other parts of the system already described, it is not possible to dynamically restrict the data an external user who wants to obtain data from the private blockchain to implement the solution will have access to. Therefore, once again, a BAF is used to restrict which data on the private blockchain can be accessed externally (for example, only to a specific smart contract where the “address → regid” mapping is stored), ensuring that the system will function without the possibility of additional data being leaked, such as transactions by academic institutions where new address-regid pairs are specified for the mapping.

The BAF itself, after verifying that the user is authorized, can retrieve the information from MariaDB and return it to the user, centralizing access control and data retrieval in this system. Furthermore, the BAF also notarizes each time the user accesses the data to download and periodically saves a hash summary of this information on the private blockchain. In this way, privacy and access control are guaranteed through the combined use of cryptography, a BAF, and smart contracts for access control and recording. In our opinion and taking into account the current state of the art, this allows compliance with the GDPR principles of “secure by design” and “privacy by default.” Additionally, the destruction of the user’s k-key used to encrypt the original academic data converts the information into a non-recoverable sequence of information, which could also be deleted from MariaDB if requested and permitted by law.

6.7. Data Subject Rights

The project GAVIN fully supports the exercise of data subject rights:

• Right to Access (Art. 15): The model’s design allows for automatic access by the user (holder) at any time, without the need for third-party intervention. Furthermore, access to certification records that may be stored on the blockchain by third parties other than the data subject must be authorized by the data subject, who can also revoke this authorization at any time. In this sense, we can clearly infer that the GAVIN project is ready to fulfill this right.
• Right to Rectification (Art. 16): This right can be fulfilled in two ways, as explained in the project:

  ○

  One way to fulfill this right would be to remove the keys used to generate the HMACs for the different fields, meaning that the data stored in the blockchain would become arbitrary and dissociated, and therefore could not be associated with a holder. From this point on, the new information could be uploaded to the blockchain, meaning the academic certification would be “rectified” and the data would be accurate, thus complying with the principle of accuracy.

  ○

  On the other hand, the project’s blockchain could also fulfill this right by generating the new information and linking it to the previous information using the transaction identifier or other data.

• Right to Erasure (Art. 17): It is possible to exercise this right by deleting the keys and data used to generate the HMACs of the Merkle tree, whose signed HMAC was stored in the blockchain, such that the data stored in the blockchain now becomes arbitrary and dissociated data, without the possibility of recovering the original data from it (and access is withdrawn from everyone in SCAccess and, in addition, it is marked as invalid).

Under Recital 26 of the GDPR, data falls outside the scope of the Regulation if it is not reasonably identifiable. The EDPB has emphasized that the concept of personal data must be interpreted with regard to “means reasonably likely to be used” by a data controller or third party to reidentify a data subject. In our view, and in line with prevailing doctrine, hashed values or transaction metadata without access to decryption keys or external linking data cannot be reasonably reidentified in practice.

While jurisprudence directly involving blockchain is still limited, the legal basis for our argument is supported by EDPB Guidelines 05/2020 on consent and Anonymisation Techniques (WP29 Opinion 05/2014), which recognize that irreversibly severing the link between identifiers and individuals (e.g., through cryptographic means) can satisfy anonymization or erasure requirements.

• Right to Portability (Art. 20): The Implementation in the reference technical model of the project GAVIN would also guarantee this right, as it allows the download of information in a structured, commonly used, and machine-readable data format.
• Right not be subject to a decision based solely on automated processing. (Art. 22): This right would not apply since the proposed model does not consider automated processes on or off-chain. The model proposes that, for the issuance of a new certificate, the issuing institution is responsible for executing this issuance. Furthermore, the interested party is the only one who can grant or revoke access permissions to their information. Finally, to verify data, the verifying entity is the one who actively interacts with the blockchain. Automated decisions are not made, nor are data subject profiles created. This is not applicable since there is no automated decision-making by either the promoters of the initiative or third parties, as mass access to user data is not possible, as the theoretical model and the technical implementation of the prototype have adequate access control mechanisms. Specifically, in the theoretical model, the record is made in the SCLog, while in the technical reference model, the record is achieved with the BAF, since read accesses are not recorded in the blockchain. In the prototype, although access control is implemented through smart contracts and the BAF, which operate automatically, these mechanisms do not constitute automated decision-making within the meaning of Article 22 of the GDPR. Access permissions are explicitly granted by the data subject, who retains full control over who can access their academic information. The system does not create profiles or make decisions that produce legal effects or similar impacts without human intervention. Therefore, the right not to be subject to automated decision-making is not activated in this context.

6.8. Roles and Responsibilities

The model proposed in the GAVIN project identifies data controllers (institutions), data subjects (students), and processors (cloud providers). For consortium governance, joint controller agreements are necessary, as per Art. 26 GDPR.

6.9. Cross-Border Data Flows

It should also be noted that the GDPR assumes the free movement of personal data within the European Economic Area. However, any export of data to third countries will be considered an international data transfer.

In this regard, Article 44 of the GDPR establishes that transfers of personal data that are being processed or will be processed after their transfer to a third country or international organization will only take place if, subject to the other provisions of this Regulation, the controller and processor comply with the conditions set out in the GDPR, including those relating to onward transfers of personal data from the third country or international organization to another third country or international organization.

First, if data is to be transferred to third countries (e.g., the use of a cloud service hosted abroad), it is necessary that said country guarantee an adequate level of protection. GAVIN’s analysis suggests that a consortium or private blockchain will be used. Therefore, these blockchains require validators and nodes to be physically located within the European Economic Area (EEA) or in one of the countries for which an adequacy decision has been issued, such as those mentioned above. Consequently, the fact that these are private and consortium blockchains means that the entities in charge oversee compliance with the network’s conditions and policies. In the specific architecture analyzed in this manuscript (the GAVIN project), the blockchain layer does not contain any personal data, and therefore does not in itself constitute a transfer of personal data under the meaning of Chapter V GDPR. All personally identifiable information (PII) is stored off-chain within EU-based infrastructures, under the exclusive control of accredited academic institutions acting as data controllers.

In any case, if an international data transfer (IDT) were to be carried out within the framework of the GAVIN project or another project using this model, one of the aforementioned instruments would be necessary to comply with the GDPR.

7. Discussion

The design of the GAVIN model, together with its ongoing implementation, provides relevant insights into both the technical and legal challenges involved in reconciling blockchain systems with strict data protection requirements such as the GDPR. This section reflects on the project’s key technical and legal contributions, identifies remaining obstacles, and considers broader implications for policy, standardization, and institutional adoption. By positioning GAVIN within ongoing regulatory and technological debates, we aim to assess its potential as a replicable framework beyond the educational domain.

7.1. Innovations and Contributions

The GAVIN project represents a pioneering implementation where GDPR compliance is not an afterthought but a foundational criterion. Its use of off-chain storage, HMAC encryption, and BAF middleware to improve security and even adds logging features exemplifies privacy-by-design principles (Art. 25 of GDPR).

Although this work does not include a formal threat model, certain risk scenarios relevant to the legal validation of the model have been considered, such as key compromise, which is mitigated through generation by field and entity, periodic rotation, and secure storage. Likewise, the use of a BAF [90] and a blockchain-based access control system [91] limits queries and prevents misuse, such as enumeration attacks or unauthorized queries. However, threats such as Sybil attacks, replay attacks, and others, have not been specifically analyzed, as they are beyond the scope of the legal analysis of this study. A formal security analysis will be conducted in future works.

7.2. Technical and Legal Challenges

• Immutability vs. Erasure: This challenge is achieved through deletion of off-chain data and hash revocation.
• Shared Responsibility: The final deployment of the model proposed by the GAVIN project requires robust legal frameworks among consortia.
• International Hosting: It is clearly an ongoing risk due to limited global GDPR harmonization.
• At the legal level, GAVIN also successfully addresses the complexities arising from co-responsibility in consortium networks. The proposal to formalize co-responsibility agreements between participating institutions and the correct identification of roles in data processing constitute a solid starting point that can be replicated in other institutional contexts.

Although the proposed model uses blockchain technologies, some of its components (such as the use of private blockchains and the BAF) may raise concerns about its effective decentralization. In this sense, it should be understood that the model prioritizes the balance between scalability, regulatory compliance, and technical traceability. The private blockchain does not replace the consortium, but rather acts as a secure buffer to enable system operation and performance before notarization on the consortium blockchain.

However, certain limitations remain that deserve to be highlighted. These include the dependence on hybrid solutions (off-chain/on-chain) and centralized infrastructures such as the BAF for access traceability. It is important to note that the BAF is introduced as a technical solution in the prototype to address a limitation identified in the actual implementation and is managed under the same consortium structure as the main network. The firewall’s operating rules can be defined as smart contracts read from the blockchain, eliminating dependence on a single actor and increasing trust. This BAF, like the consortium blockchain, would be managed and maintained by the entities responsible for deploying and maintaining the solution. Although these decisions are technically justified, they reveal that blockchain technology, in its current state, does not yet offer a completely autonomous and functionally self-sufficient solution to meet the necessary requirements. However, the overall result fulfills its objective of being compatible with data protection, as well as supporting all types of academic certification, scalability, and, through the use of APIs, not requiring structural changes to organizations’ information systems to adapt and integrate with GAVIN. The GAVIN model presents a conceptually and legally sound design, but it is important to recognize that legal analysis is not an exact science. Judicial interpretations, regulatory guidelines, or the work of data protection authorities may alter the applicability or prioritization of certain legal requirements over time. Furthermore, in many cases, compliance assessments are based on interpretations that could evolve if jurisprudential criteria are modified or regulatory guidelines are updated.

Additionally, as is common in systems that integrate blockchain technology with data protection regulations, certain operational challenges persist: the need for clear governance within consortia, dependence on network-specific configurations (permissioned/public), and risks associated with interoperability between educational institutions with different information systems, as well as the need to legally model user terms of use.

Finally, the legal analysis focuses on the regulatory framework of the European GDPR; therefore, its applicability may vary in other jurisdictional contexts. These factors must be taken into account in the future evolution of the model aimed at its global implementation.

7.3. Policy and Standardization Implications

Wider adoption of models like GAVIN requires standardization (e.g., ISO/IEC blockchain frameworks) and updated guidance from regulatory bodies tailored to decentralized contexts. Regarding this point, the GAVIN team members have already made two proposals to the European Union (already accepted) to combine the proposed model with electronic Identification, Authentication and trust Services (eIDAS) [97] and blockchain interconnection [98] to advance the definition of standards for this use case.

8. Conclusions

The GAVIN project affirms the viability of GDPR-compliant blockchain architectures for academic certification. By combining technological innovation with rigorous legal analysis, it offers a scalable and transferable model for trusted digital credentials that complies with the principles of the GDPR through a balanced combination of cryptographic techniques, distributed storage, smart contracts, and blockchain-based access control mechanisms, achieving a system that is not only compatible with the model, but also a functional, scalable, and legally robust solution for the issuance, validation, and even retrieval of academic information.

The main objective of this work was to analyze the compliance with the GDPR of the previously proposed GAVIN model, in its theoretical and technical configuration. This objective has been met, and the results obtained allow us to consider that this model, as designed, is applicable as a basis for the creation of real academic certification systems based on blockchain and compliant with European regulations. A technical prototype of the model is currently in an advanced stage of development, the practical results of which (both quantitative and qualitative) will be published in a subsequent work specifically dedicated to its implementation and functional validation.

GAVIN not only responds to a real, latent need in today’s digital society to verify any type of academic information but does so based on a design that aligns with the data protection principles established in Article 25 of the GDPR. This “privacy by design” approach sets a relevant precedent for the development of decentralized systems in other sectors with high regulatory requirements, such as healthcare, justice, and finance, to name a few. Despite the progress made, the path toward standardizing blockchain architectures compatible with European data protection regulations still presents challenges. Legal interoperability between jurisdictions, the technological evolution of blockchain platforms, and the lack of specific guidelines from regulatory authorities remain open areas for research and innovation, along with, for example, automated compliance tools and AI-assisted credential verification.

Ultimately, GAVIN represents a necessary, real, and innovative proposal (in fact, both the model considered, and the prototype created can be said to be academically pioneering) and can undoubtedly contribute significantly to the digital transformation of the educational ecosystem, offering a secure and GDPR-compliant alternative for the issuance, verification, and even retrieval of academic information in any format.