Optimizing Teacher Portfolio Integrity with a Cost-Effective Smart Contract for School-Issued Teacher Documents

Abstract

Diplomas and academic transcripts issued at the conclusion of a university cycle have been the subject of numerous studies focused on developing secure methods for their registration and access. However, in the context of high school teachers, these initial credentials mark only the starting point of a much more complex professional journey. Throughout their careers, teachers receive a wide array of certificates and attestations related to professional development, participation in educational projects, volunteering, and institutional contributions. Many of these documents are issued directly by the school administration and are often vulnerable to misplacement, unauthorized alterations, or limited portability. These challenges are amplified when teachers move between schools or are involved in teaching across multiple institutions. In response to this need, this paper proposes a blockchain-based solution built on the Ethereum platform, which ensures the integrity, traceability, and long-term accessibility of such records, preserving the professional achievements of teachers across their careers. Although most research has focused on securing highly valuable documents on blockchain, such as diplomas, certificates, and micro-credentials, this study highlights the importance of extending blockchain solutions to school-issued attestations, as they carry significant weight in teacher evaluation and the development of professional portfolios.

1. Introduction

Blockchain is a distributed ledger [1], meaning that data is not kept in a single, centralized location but is instead replicated and maintained across a network of computers globally [2]. This decentralized structure removes reliance on a central authority and enhances the resilience and availability of the data. Each piece of data is recorded in a block that is cryptographically secured and linked to the previous one using digital signatures and hash functions [1], ensuring both authenticity and integrity. Data stored on a blockchain is resistant to tampering, as its chronological organization within the chain makes unauthorized modifications easily detectable and practically infeasible. These features collectively protect sensitive data, making blockchain well-suited for applications across various domains [3,4,5]. In the healthcare sector, blockchain technology is used to facilitate the secure sharing of clinical data across borders by allowing healthcare institutions in different countries to access accurate and complete patient records in real time, thereby enabling interoperability and supporting the development of integrated and universal medical services that particularly benefit individuals who travel frequently or receive treatment from multiple international healthcare providers [6,7]. In public administration, often perceived as inefficient, overly bureaucratic, and lacking transparency [8], blockchain presents a promising solution for improving administrative processes, welfare services, and regulatory practices [9], as demonstrated by Estonia’s pioneering role in adopting this technology within the public sector [10]. In the field of education, most research has focused on its application for storing and verifying information related to students’ academic performance, encompassing a wide range of processes such as recording and managing grades, tracking credits earned throughout academic programs, and validating diplomas and transcripts [11].

Besides these documents of great importance, issuing locally generated documents with significant institutional or legal importance is a common practice in various sectors. Areas such as education, healthcare and public administration frequently rely on documents such as certificates, attestations or permits, which are produced locally but carry weight far beyond their point of origin. In the educational context, locally issued attestations hold significant value as they contribute directly to the formal evaluation of a teacher’s professional activity [12,13], serving as supporting evidence in processes related to career advancement or eligibility for performance-based salary incentives [14]. In our research we define an attestation as a school-issued document that certifies a teacher’s work in activities with students, projects, or professional development. As institutions move toward digital transformation, replacing traditional paper-based documents with electronic equivalents presents both opportunities and challenges. Given that highly valuable documents such as diplomas, certificates, and micro-credentials are already anchored on the blockchain, it is equally important to extend this approach to documents issued at the school level, as they carry significant weight in teacher evaluation and the development of teacher portfolios. Attestations that capture a teacher’s involvement in school projects, extracurricular activities, or professional development initiatives are central to assessing performance and career progression. Because these documents are produced in large numbers across many teachers and institutions, their integration into blockchain-based systems must rely on transactions that remain extremely low in cost.

1.1. Objectives and Research Questions

This study aimed to address the challenges faced by centralized systems in managing locally issued school attestations, which are included in teacher evaluation processes. The proposed blockchain-based system responds to this need by decentralizing the storage of attestations, safeguarding their integrity through cryptographic mechanisms and smart contracts, and providing a transparent and reliable framework for their verification within the educational evaluation context.

Our research is designed to address the following key questions:

• How can blockchain technology address the current challenges in securely storing, managing, and accessing school-issued attestations?
• What are the operational trade-offs between cost and processing latency in implementing such a blockchain system?

1.2. Research Contribution and Paper Outline

This article advances the field by presenting a blockchain-based system capable of securely recording locally issued school attestations while preserving their authenticity and resistance to tampering. The system’s effectiveness is examined through an evaluation of its performance, with particular attention to the trade-off between operational cost and processing delay, offering insights into its practical deployment. In addition, a security analysis is conducted to demonstrate that the system can withstand common threats to the blockchain infrastructure and data confidentiality, thereby complementing its functional and operational strengths.

The rest of this paper is organized into several sections: Section 2 describes blockchain technology and smart contracts. Related work is analyzed in Section 3. Section 4 outlines the foundational concepts, while Section 5 presents the detailed methodology underlying the proposed approach. In Section 6 and Section 7, the findings are discussed, while Section 8 explores conclusions and future work.

2. Blockchain and Smart Contracts

In centralized systems, data management is handled by a single trusted entity, which allows for simplified administration and uniform control [15]. This centralized structure, while efficient, is a highly attractive target for malicious actors, and any breach or technical failure can lead to significant data loss or exposure. These risks make security and resilience major concerns in centralized architectures [15], especially as the volume and sensitivity of stored information continue to grow across various domains such as banking, education, healthcare, and public administration.

Unlike centralized systems, decentralized architectures such as blockchain eliminate reliance on a single authority by sharing control and decision-making across a network of participants. Blockchain is a decentralized system for recording and verifying data, built on a distributed network of machines that continuously replicate and maintain a growing chain of data blocks [16]. Each block contains a set of validated information and is cryptographically linked to the previous one, forming a chronological and tamper-resistant chain [17]. These blocks are propagated across the entire network, enabling all participating machines to access and verify the complete chain independently. This decentralized verification process ensures the authenticity of the data and preserves the integrity of the entire blockchain system. Bitcoin pioneered the world of cryptocurrencies by introducing the groundbreaking concept of blockchain technology [1], laying the foundation for secure, decentralized digital transactions, while Ethereum expanded the capabilities of blockchain beyond simple currency exchange to become a versatile development platform that empowers developers to build and deploy decentralized applications (dApps) and programmable smart contracts [18], thereby enabling a wide range of innovative use cases across various industries. Whereas a conventional web application operates on infrastructure controlled by a single organization, a dApp is a application that runs on a decentralized blockchain network.

A smart contract is a self-executing program, written in high-level programming languages, that resides on a blockchain platform and automatically enforces the terms of an agreement without the need for intermediaries [19]. Figure 1 depicts the structured life cycle of a smart contract, which progresses through three fundamental phases: creation, deployment, and execution [20].

A smart contract runs on a decentralized computing environment [21] designed to execute smart contracts on the blockchain. A transaction submitted to a smart contract encapsulates a well-defined set of data that determines how the operation is processed on the blockchain. It specifies the account initiating the call, the contract that receives it, the function signature that identifies the intended action, and any parameters required for execution [21].

In order for a transaction to be recorded on the blockchain, the computational effort required for its execution must be compensated, a cost covered through gas fees. Gas in Ethereum and other networks operating on the Ethereum Virtual Machine (EVM) represents the computational cost of executing operations on the blockchain [22]. Transactions that modify storage consume considerably more gas than simple computations, making write-type functions inherently more expensive [21]. However, the total fee is not fixed, as the gas price varies dynamically with network congestion and competition for block space. These fluctuations can be extremely high during periods of peak demand, when many users simultaneously broadcast transactions, driving costs upward and introducing unpredictability in the final execution fee [23]. By contrast, read-only functions, which merely retrieve data without altering the contract’s state, require no gas [21].

Once submitted, the transaction is cryptographically signed, validated by the network, and then executed, with the outcome permanently stored on the blockchain. The input data used to trigger the contract’s functions is embedded in the transaction itself and cannot be changed, ensuring reliability and transparency in how the contract operates.

A major challenge in today’s blockchain landscape is the limited interoperability of smart contracts across networks [24], which often constrains the functionality of dApps. This issue is rooted in the fact that various blockchains operate using distinct programming languages and architectures [25]. In such cases, developers must implement third-party bridges or external oracles to transfer and validate data between platforms, which introduces additional complexity and potential security risks. Without native interoperability, cross-chain collaboration between dApps remains limited, ultimately restricting innovation and adoption in sectors like education, where multi-platform accessibility and verification are crucial. Some degree of cross-platform compatibility is possible through shared environments like the EVM, enabling Solidity-based smart contracts to be deployed on multiple chains such as Ethereum, Polygon, and Avalanche [26].

Table 1. Smart contracts characteristics.

Platform	Type of Contracts	Programming Language	Environment	Compatibility
Ethereum	Smart Contract	Solidity [27]	EVM [27]	-
Solana	Programs	Rust, C, C++ [28]	Sealevel [28]	-
Cardano	Smart Contract	Plutus (Haskell) [29]	Plutus Core [29]	-
Hyperledger Fabric	Chaincode	Go, node.js, Java [30]	Executes within a containerized environment (e.g., Docker) [30]	-
PolkaDot	Smart Contract	Rust/ink! [31]	Wasm [31]	Supports Solidity contracts executed by the PolkaVM and EVM [31]
Avalanche	Smart Contract	Solidity [32]	EVM [32]	EVM-compatible on the C-Chain [32]
MultiversX	Smart Contract	Rust [33]	Wasm [33]	-

presents the smart contract languages supported by various blockchain platforms, highlighting the diversity in development environments and execution frameworks.

3. Related Work

Sha Ouyang and Xinjing Huang [34] propose using blockchain technology to improve the educational evaluation process, addressing issues like limited evaluation criteria, lack of transparency, and low trust in results. By creating a secure, tamper-proof, and decentralized evaluation platform, the system enhances data reliability, encourages institutional collaboration, and supports better implementation of quality and policy measures in education.

Ren et al. [35] present a blockchain-based blended teaching evaluation system designed to address issues of data fragmentation, security, and transparency in modern education. By integrating Ethereum, Inter Planetary File System (IPFS), a decentralized protocol for storing and sharing files across a distributed network, smart contracts, and encryption algorithms, ensures reliable storage, controlled access, and accurate recording of learning outcomes, offering a scalable and adaptable solution for modern educational institutions.

Kistaubayev et al. [36] explore the development and performance evaluation of a blockchain-based platform, Univer Cert, designed to create a unified digital register of student academic achievements. Utilizing Ethereum consortium, the study emphasizes important performance indicators such as transaction throughput, cost efficiency, and data storage capacity, which are often overlooked in similar research.

Leka et al. [32] introduce BCert, a prototype system utilizing the Ethereum blockchain in conjunction with the IPFS to issue and manage academic certificates. Their approach emphasizes speed, security, and efficiency in credential management.

Sultana et al. [37] propose a blockchain-based system for storing academic certificates as cryptographically secured digital assets on the Ethereum network, each uniquely identified and timestamped to ensure integrity and immutability. The system enables direct verification without intermediaries, minimizing fraud risks, and includes both a security and performance analysis to validate its effectiveness.

Fernández-Blanco et al. [38] presents a solution for recording and verifying academic records using a decentralized application supported by an Ethereum smart contract and IPFS for storage. The system’s performance and energy efficiency are evaluated by comparing the traditional proof-of-work consensus with the more recent proof-of-authority protocol.

Tiganoaia and Alexandru [39] present a decentralized application that uses blockchain technology to improve transparency and efficiency in educational donations aligned with sustainable development goals. They address issues in traditional donation systems by enabling secure and traceable transactions through smart contracts, and showcase the platform’s design, implementation, and potential impact through demos and use cases.

McCabe et al. [40] address the limitations of traditional authentication methods, particularly the vulnerabilities of username-password combinations and conventional two-factor authentication (2FA) systems. While 2FA adds an extra layer of security, it remains susceptible to evolving cyber threats. To address these challenges, the paper proposes the integration of blockchain technology as a more secure form of 2FA.

Tahir et al. [41] introduce a blockchain-enabled framework designed to enhance the management of sensitive patient health data by overcoming the structural limitations of conventional centralized systems. Through the implementation of a decentralized architecture on the Ethereum platform, the framework ensures greater data integrity, privacy, and interoperability while reducing reliance on centralized control. By incorporating smart contracts, the system facilitates automated, transparent, and secure access to health information among authorized parties. The evaluation of the proposed approach demonstrates its practicality in terms of both performance and cost, highlighting its adaptability across various blockchain infrastructures.

Table 2. Summary of the related work.

Authors	Blockchain Name	Blockchain Type	Storage Method	Application Domain	Area of Interest
Ouyang and Huang [34]	Not Specified	Not Specified	Cloud	Education	The educational evaluation management is assessed
Ren et al. [35]	Ethereum	Public	IFPS	Education	Blended teaching evaluation system is assessed
Kistaubayev et al. [36]	Ethereum consortium	Private	IFPS	Education	Managing diplomas and certificates
Leka et al. [32]	Ethereum	Public	IFPS	Education	Managing diplomas and certificates
Sultana et al. [37]	Ethereum	Public	IFPS	Education	Managing diplomas and certificates
Fernández-Blanco et al. [38]	Ethereum	Public	IFPS	Education	Managing diplomas and certificates
Tiganoaia and Alexandru [39]	Polygon	Public	IFPS	Social	Managing donations for social and educational causes
McCabe et al. [40]	Ethereum	Public	Local storage	Authentication	Improving username-password combinations and conventional two-factor authentication system
Tahir et al. [41]	Ethereum	Public	IPFS	Health	Health care information

presents a summary of the related work, outlining the selected blockchains along with their types, storage methods, application domains, and the area of interest discussed in the research papers.

In summary, a significant amount of research has been carried out on the application of blockchain technology in various areas. In education, while considerable research has been conducted on the application of blockchain technology for student diploma verification and academic performance evaluation at both school and university levels, limited attention has been given to the assessment of teachers through the use of digital portfolios. Current studies predominantly address the authentication of student-related data, yet fail to examine the potential of blockchain for securely managing and validating teacher credentials, including academic diplomas, professional development certificates, and locally issued attestations. Moreover, existing frameworks often lack mechanisms for ensuring the integrity, traceability, and controlled access of such documents across educational institutions. This reveals a research gap and underscores the need for a blockchain-based evaluation model that facilitates the systematic and transparent management of teacher qualifications.

4. Preliminaries

Figure 2 illustrates the system’s functional architecture, offering a clear representation of how the integrated technologies work together to address the challenge of secure and transparent attestation management. Teacher-related information is recorded on the Ethereum blockchain to ensure data immutability, while encrypted attestation files are stored using IPFS, supporting decentralized and tamper-resistant storage. Smart contracts automate the validation and traceability of the records. The system assigns two distinct roles: the school, functioning as the administrator with full control over data input and management, and the user, who is limited to viewing authenticated attestations. Collectively, Ethereum, IPFS, smart contracts, and role-based access control make up the core technological infrastructure of the system. The following section introduces the fundamental components of the system: Ethereum for secure and immutable data storage, MetaMask for user authentication and interaction with the blockchain, IPFS for decentralized file storage, and role-based access control for managing user permissions.

4.1. Ethereum Blockchain

The Ethereum blockchain is selected as the foundation for our solution to manage attestations in a school context due to its public, decentralized nature and robust support for smart contracts and dApps [40].

Ethereum Mainnet is the primary public blockchain of the Ethereum network, where real transactions are executed with actual economic value and recorded permanently on the distributed ledger. Ethereum Mainnet was launched in 2015, with currently 11,878 accessible nodes [42], and is a mature blockchain. Ethereum’s shift from proof-of-work consensus mechanism to proof-of-stake in 2022 marked a major upgrade aimed at improving energy efficiency, reducing reliance on computational power, and laying the foundation for future scalability enhancements. To obtain consensus, Ethereum’s proof-of-stake mechanism relies on validators who are randomly selected to propose and attest to blocks based on the amount of ethers they have staked [43,44], promoting energy efficiency and network security. Ethereum’s proof-of-stake consensus requires participants to lock 32 ethers in a smart contract to become validators, who are randomly chosen to create and verify new blocks [43]. These validators form committees that collectively review and vote on proposed blocks, requiring a majority of two-thirds approval for inclusion in the blockchain. Validators who act maliciously are subject to sanctions through a process called slashing, which results in the loss of their staked ethers. Security derives from rewards for honest behavior and slashing penalties for misbehavior, creating high economic cost for attackers [45].

The Ethereum main application test network, called Sepolia, was launched in 2021 and is an environment designed for developers to deploy and experiment with smart contracts and dApps without using real assets [46]. Sepolia closely replicates the conditions of the Ethereum Mainnet while using test ether [46], making it ideal for testing functionalities, security, and network behavior before production deployment.

Ethereum’s most powerful features are smart contracts. Unlike Bitcoin’s primary focus on peer-to-peer value transfer, Ethereum enables developers to create self-executing contracts that automatically enforce agreements without intermediaries. Each smart contract on the Ethereum blockchain is permanently recorded with a dedicated storage space that preserves its current state and ties it to unchangeable executable logic [47]. The EVM enables the execution of smart contracts. EVM is a runtime environment used by all nodes in the Ethereum network to execute smart contracts independently of the main protocol layer [40]. Ethereum’s smart contracts are written in the Solidity programming language. Solidity was developed with a syntax and structure similar to that of the JavaScript programming language [40].

Table 3. Characteristics of Ethereum.

Characteristic	Description
Type of blockchain	Layer 1
Main network	Ethereum Mainnet
Main test network	Sepolia
Consensus mechanism	Proof-of-stake
Smart contracts	Native support
Smart contracts language	Solidity
Runtime environment	EVM

provides an overview of the key characteristics of Ethereum.

4.2. MetaMask Wallet

Communication with the blockchain is established through a wallet, and for this research, we used MetaMask, the most widely adopted Ethereum wallet [48]. MetaMask provides users with a secure and user-friendly interface for creating and managing Ethereum accounts by locally storing private keys on the user’s device, thereby reducing the security risks associated with cloud-based key storage. It offers functionality for importing and exporting private keys, allowing users to easily manage access across multiple devices or platforms. MetaMask also supports seamless switching between different Ethereum networks, such as Mainnet and testnets [49], enabling users to monitor account balances specific to each network. Beyond basic wallet functions, it facilitates the transfer of ether and tokens and provides access to detailed transaction histories through blockchain explorers. Moreover, by integrating the web3.js JavaScript library [44], MetaMask enables direct interaction with the Ethereum blockchain from within web applications, making it a vital tool for developers and users engaging with decentralized applications.

Table 4. Characteristics of MetaMask.

Characteristic	Description
Type of wallet	Browser extension Mobile app
Key Storage	Locally
Account Management	Allows creation, import, and export of accounts and private keys
Network Support	Layer 1 blockchains (e.g., Ethereum) Layer 2 blockchains (e.g., Polygon) Testnet (e.g., Sepolia)
Web3 Integration	Supports

provides an overview of the essential features of MetaMask.

4.3. IFPS

Due to the high cost and limited capacity of on-chain storage, attestations are not stored directly on the blockchain; instead, they are uploaded to the IPFS. Unlike centralized servers, which store data in a single, controlled location, making them more vulnerable to failures or unauthorized access, IPFS reduces reliance on a single server by distributing file fragments across multiple nodes and identifying files based on their content rather than their physical location [50]. When a file is added to the IPFS, it is divided into smaller blocks, each individually hashed, and these hashes are combined to generate a unique content identifier (CID), which serves as a permanent reference to the file [51]. This CID, together with other metadata, is recorded on the blockchain to guarantee authenticity and traceability.

5. Proposed Solution

5.1. Design

The proposed system is designed to address the need for digitalizing the issuance, storage, and verification of academic attestations in a secure, transparent, and verifiable manner. Figure 3 illustrates the layered architecture of the blockchain-based attestation management system, providing a structured view of its core components organized according to their functional responsibilities and their interdependent roles within the platform.

5.1.1. Security Layer

Metamask Wallet

In this research, MetaMask, recognized as the most widely used Ethereum wallet, was employed as a browser extension to facilitate communication with the Ethereum network. All operations initiated within the system are authorized through digitally signed transactions using the school’s MetaMask private key, thereby guaranteeing the integrity and legitimacy of each interaction [52]. To enhance authenticity and traceability, the teacher’s public key is embedded in encrypted form within each transaction, ensuring that attestations are verifiably linked to their intended recipients while maintaining privacy and security.

Role-Based Access Control

Access control within the system is governed by a role-based model, which restricts sensitive operations to authorized entities by assigning distinct roles such as the administrator, which is the school, responsible for issuing attestations in the school, and various types of verifiers, including the attestation recipient, such as a teacher, as well as members of an evaluation committee or external institutional stakeholders [53].

Figure 4 illustrates the procedural workflow used by the administrator, which is the school, tasked with the management and population of attestation records via an interface.

Figure 5 illustrates the procedural workflow followed by the verifier, such as a teacher, company, or educational institution, responsible for consulting the issued attestations.

5.1.2. Application Layer

The web-based user interface is designed to be intuitive and accessible, enabling institutional administrators to issue attestations and allowing recipients and verifiers to access relevant information. The front-end of the application was developed using a combination of HTML and CSS for structuring and styling the user interface, respectively, while Python (version 3.11.0), as employed on the back-end to handle core logic and blockchain interaction. The interface comprises several web pages, including an initial role-selection page where users choose whether to interact with the platform as an administrator or verifier, followed by separate login pages for administrators and verifiers, as well as a registration page exclusive to verifiers. Once authenticated, administrators gain access to functionalities for generating and viewing attestations, while verifiers are restricted to attestation consultation. Similar interface designs have been proposed in prior blockchain-based credential management systems, emphasizing clear role differentiation and secure access control [54].

5.1.3. Communication Layer

The communication layer acts as the intermediary that processes, validates, and coordinates data transactions. This layer manages the encryption of the input data, communicates with decentralized storage services, and interacts with smart contracts deployed on the Ethereum blockchain. It ensures that data integrity and confidentiality are maintained before the information transitions to the storage infrastructure. The logic within this layer plays a critical role in enforcing application rules, encoding data for IPFS, generating CID, and invoking the appropriate functions within the smart contracts. Similar architectures have been employed in blockchain-based document management, highlighting the critical role of a secure middleware layer in maintaining trust and efficiency [55,56].

5.1.4. Smart Contract Layer

In our approach, teacher attestations are managed through a smart contract, removing the need for reliance on trusted third parties. This ensures a transparent, secure, and decentralized process for verifying and recording attestations. In this part, we detail the smart contract, which is responsible for executing the attestation logic and storing verifiable evidence directly on the blockchain. Appendix A contains the complete Solidity code of the smart contract, providing a clear overview of its logic, structure, and the mechanisms used to manage data and operations.

Smart Contract Data

A key aspect of developing the smart contract is determining which data should be stored on-chain and how to structure it to ensure efficient access, security, and transparency. In our implementation, relevant attestation metadata is encapsulated within the Attestation struct, with each entry uniquely identified by an identifier (ID).

The metadata is stored on-chain using the EVM’s persistent storage, enabling auditability and verifiability. The full attestation documents are stored off-chain on the IPFS, and the smart contract retains only the corresponding CID, serving as a decentralized pointer to the external content.

The data stored in the smart contract includes the following:

• teacher: The public address of the teacher wallet, the recipient of the attestation.
• teacherName: The teacher’s name.
• ipfsHash: The CID that points to the full attestation stored off-chain on IPFS.

These records are maintained in a mapping called attestations, which functions as a key-value store, linking each attestation ID to its associated data. This allows for efficient retrieval through public getter functions and enables external systems or users to verify the existence and integrity of specific attestations.

In line with best practices for gas optimization, the contract avoids storing large documents directly on-chain. Instead, the use of IPFS for off-chain storage significantly reduces gas costs and enhances scalability, while still preserving the verifiability of each attestation via the immutable hash reference. This approach aligns with best practices in blockchain-based credentialing and decentralized data management [54,57].

Smart Contract Functions

The smart contract provides three main public functions that handle the creation, retrieval, and verification of teacher attestations in a decentralized and secure way. These functions are:

• generateAttestation: This function allows the contract owner to create a new attestation for a teacher using their blockchain address, full name, and the IPFS hash of the document stored off-chain, while assigning it a unique numeric ID.
• getAttestation: This is a read-only function that retrieves an existing attestation based on its numeric ID.
• isVerified: This utility function verifies whether a given attestation ID is registered in the system or not.

Smart Contract Event

Events act as logs that are triggered during contract execution and can be captured by off-chain systems to monitor important changes without the need for constant blockchain queries.

In our contract, the main event is as follows:

• AttestationGenerated: This event is emitted every time a new attestation is successfully created through the generateAttestation function. It includes the numeric attestation identifier along with the address of the teacher and their name.

Events in Solidity are stored in transaction logs, making them a cost-effective alternative to on-chain storage for recording actions. They provide a secure and lightweight solution that enables decentralized applications to maintain synchronized views of blockchain state based on emitted logs.

Table 5. Smart contract description.

Elements	Description
contract Attestations {}	Encapsulates attestation data
function generateAttestation()	Creates an attestation
function getAttestation()	Retrieves an existing attestation
function isVerified()	Verifies whether a given attestation ID is registered
event AttestationGenerated()	Announces the successful creation of an attestation

provides an overview of the attestation smart contract, outlining its principal structural components and associated functionalities.

5.1.5. Data Storage Layer

The data storage layer utilizes the IPFS to securely store encrypted attestation files off-chain. In this project, the Pinata pinning service was employed to upload attestations [58] and generate CIDs, which are then referenced within the blockchain to maintain data integrity without incurring excessive storage costs on-chain. Concurrently, the Ethereum blockchain is used to record essential metadata, enabling long-term verifiability and immutability of attestation data. By storing only these concise references on-chain, the system optimizes gas consumption. This hybrid approach balances efficient data storage with the security and transparency inherent in decentralized ledger technology.

5.2. Implementation and Deployment

For the temporary backend and to create a secure testing environment, we used Hardhat, version 2.26.1, a widely adopted and user-friendly development tool in the Ethereum ecosystem [59]. The setup of Hardhat requires a prior installation of Node.js. We used the Long-Term Support (LTS) release, obtained from the official Node.js website [60], which also installs Node Package Manager (npm) as part of the package. Once the environment was prepared, Hardhat was integrated into the project. Hardhat provides an all-in-one framework for building, testing, and deploying smart contracts and dApps [59]. It includes integrated components for writing and editing smart contracts, compiling Solidity code, debugging transactions, and simulating deployments in a local blockchain environment. This made it an ideal choice for our solution implementation, as it allowed us to safely test and refine our smart contract.

When we initialized a Hardhat project in our local environment, this structure that includes the following important files and folders was created:

• contracts: .sol files.
• artifacts: Artifacts produced out of the contract compilation.
• test: .js files for using testing libraries.
• hardhat.config.js: File with project configurations.

A local Ethereum network for development and testing was instantiated using the command npx hardhat node. This process launches a simulated blockchain on the local machine, initialized with 20 prefunded test accounts. For our implementation, the first account was designated to manage contract deployment and subsequent interactions. The local execution environment was hosted on a machine equipped with an Intel Core Ultra 7 155H processor (Intel Corporation, Santa Clara, USA) operating at 3.80 GHz, 16 GB RAM, and a 64-bit operating system on an x4-based architecture. These hardware specifications ensured efficient handling of local blockchain simulation.

Using Visual Studio Code (version 1.104.0, Microsoft Corporation, Redmond, WA, USA), we wrote the smart contract for our project.

The smart contract was compiled using the Hardhat development framework, configured with the Solidity compiler version 0.8.28, consistent with the pragma ^0.8.13, which allows compilation with any version from 0.8.13 up to, but not including, 0.9.0. Compilation was executed through the command npx hardhat compile, which successfully processed all contract files and confirmed compatibility with the targeted EVM version Paris. This step ensured that the contracts were properly transformed into deployable bytecode and Application Binary Interface (ABI) definitions, forming the foundation for subsequent deployment and interaction on local network.

The deployment was carried out on the local Hardhat network using the command npx hardhat run deploy.js --network localhost. The contract was successfully deployed from the first of the 20 prefunded accounts to a generated address, as shown in Figure 6.

After successfully testing our smart contract on a local blockchain network, we advanced to evaluating its performance in an environment that more closely mirrors the real Ethereum blockchain by deploying and testing it on the Sepolia test network. To facilitate interaction with the Sepolia test network, we configured MetaMask with the following parameters:

• Network Name: Sepolia
• Default RPC URL: sepolia.infura.io
• Chain ID: 11155111
• Currency Symbol: SepoliaETH
• Block Explorer URL: https://sepolia.etherscan.io

Next, we obtained test Ether, necessary to cover gas fees for contract execution, through faucets such as Google Cloud Web3 [61]. It is important to note that certain faucets, including those from Alchemy, implement anti-bot measures and require users to maintain a minimum balance of 0.001 ETH on the Ethereum Mainnet [62] before granting access to Sepolia test funds. With the environment fully prepared, we imported our smart contract into Remix, compiled it, and deployed it to the Sepolia network.

The development phase of the dApp was a comprehensive and meticulous process. It involved designing and styling user interfaces using HTML and CSS [63] to create an intuitive and visually appealing experience. Meanwhile, Python was employed to implement the core logic, serving as the backbone of the application’s functionality.

The application was designed to facilitate blockchain transactions directly from its interface, as shown in Figure 7. This was achieved by integrating the dApp with the Sepolia test network, enabling the simulation of real Ethereum blockchain interactions in a controlled environment.

Once the admin, which is the school, fills in the required fields in the interface, the system generates a digital attestation as a PDF file. This file is uploaded to IPFS through Pinata via a direct API call, authenticated with the application’s API keys. Pinata responds with a unique CID, which is returned to the application and serves as a permanent reference to the attestation, as illustrated in Figure 8. When the admin confirms submission, the application prepares and broadcasts a blockchain transaction that embeds this CID, ensuring the attestation is immutably anchored on Ethereum. While the interface also collects information such as “Category” and “Activity”, these fields are intentionally excluded from the transaction to reduce on-chain storage costs, while still being preserved and managed off-chain.

All transactions resulting from the submission process can be independently verified through the Etherscan, a public blockchain explorer for Ethereum [64]. By entering the transaction hash, third parties can confirm that the attestation has been recorded on Ethereum and review details such as gas fees, block number, and confirmation time.

6. Results

6.1. Gas Consumption Evaluation

In Ethereum and other EVM-compatible blockchains, every operation on the blockchain consumes gas, which measures the computational effort required to execute transactions or deploy contracts [65]. These costs are directly proportional to the complexity and resource intensity of the operation being executed. Among all operations, on-chain data storage is one of the most expensive in terms of gas consumption. Writing data to the blockchain’s persistent storage typically costs 20,000 gas units per 32-byte word [66].

The initial design of the smart contract included several data fields, such as a unique identifier, the IPFS content identifier of the attestation, the teacher’s full name, the category of the activity, and a description of the completed activity. Following deployment and execution of transactions, it became evident that the gas consumption was substantial. This presented a major limitation, particularly considering the intended implementation within educational institutions, where attestations are issued in high volumes and financial resources are constrained. In response, the contract was restructured to include only the essential information required for verification. The revised version retains the teacher’s public key, which serves as a verifiable identifier of the rightful recipient, the teacher’s name, and the IPFS hash of the attestation. This modification significantly enhances the contract’s efficiency. Figure 8 illustrates the results of tests conducted in a local development environment, which facilitated a detailed analysis of gas consumption across each stage of the process, from smart contract deployment to attestation issuance, and enabled a direct comparison between the original contract, characterized by a more extensive data structure, and the optimized version, which demonstrated a lower gas consumption due to its streamlined design focused on essential verification elements.

To further examine scalability, we extended the experiment by executing 1000 consecutive generateAttestation() transactions. Contract efficiency was evaluated using a custom Python script that employed Web3.py together with the EthereumTester backend to simulate transactions and record the exact gas usage. The results, presented in Figure 9, reveal gas consumption patterns across groups of 100 transactions, highlighting the average of each group along with the overall minimum and maximum values. The analysis shows that, after a slightly higher cost incurred during the initial insertions, gas usage stabilized at approximately 146,502 gas per transaction and maintained this consistency throughout subsequent operations. For the entire batch of 1000 transactions, the average gas cost per transaction was 146,519, with a minimum of 146,502 and a maximum of 163,602. The only notable deviation occurred in the first 100 attestations, where the average reached 146,673 due to additional storage overhead associated with initial contract state updates. Beyond this point, gas usage consistently stabilized at 146,502, indicating that the contract achieves a steady operational cost once its mappings and storage structures are initialized. This consistency underscores the scalability of the design, as the marginal cost of issuing attestations remains uniform and predictable even when executed at large volumes.

6.2. Cost Evaluation

Ethereum fees compensate validators for the computational resources [67] required to process and validate transactions, thereby ensuring network security and preventing abuse. In August 2021, Ethereum introduced a new transaction fee model through EIP-1559, aiming to enhance efficiency and predictability in fee estimation [68]. This updated mechanism replaced the traditional fixed gas price system with a dual-component structure consisting of a base fee, which is burned, and a priority fee, which incentivizes validators [68].

The formula:

Gas used × min(Base fee + Priority fee, Max fee per gas)

defines the calculation of the actual transaction cost under Ethereum’s EIP-1559 gas pricing model [69], where each component contributes to the overall fee structure as follows:

• Gas used refers to the total computational resources consumed by a transaction, measured in gas units, with more complex transactions requiring a greater amount of gas to execute.
• Base fee denotes a mandatory charge per unit of gas that adjusts dynamically based on network demand. This fee is not transferred to validators but is instead permanently removed from circulation through a burning mechanism.
• Priority fee, also known as a tip, is an optional additional amount offered per unit of gas to incentivize validators to include the transaction in a block more promptly.
• Max fee per gas represents the upper limit that a user is willing to pay per unit of gas, encompassing both the base fee and the priority fee, thereby allowing users to control their maximum expenditure under varying network conditions.

Typically, gas prices are expressed in a smaller unit called Gwei, rather than in ether itself, where 1 ether = 10⁹ Gwei [70].

Our smart contract was deployed to the blockchain using the Remix development environment, with the deployment process completing in under 12 s. The transaction fee for this deployment amounted to approximately 0.0019 ETH, which corresponds to roughly 6.81 USD at the time of execution. This demonstrates a relatively efficient and cost-effective deployment with these details documented in Figure 10.

Our smart contract consumed 884,344 gas units, with the total transaction fee determined by a base fee of 0.61832036 Gwei and a priority fee of 1.5 Gwei, resulting in a final cost of 0.00187332 ETH, as illustrated in Figure 11.

The deployment of a test transaction through the developed application demonstrated the system’s ability to efficiently interact with the Ethereum blockchain via the Sepolia testnet. During our testing phase, the Ethereum network experienced minimal congestion, which enabled us to maintain low priority fees across all transactions. The optimized smart contract design contributed to stable and moderate gas usage, resulting in consistent and affordable transaction costs. The recorded transaction, executed at a minimal cost, highlights the economic viability of the proposed solution, particularly in contexts where high volumes of attestations are expected. This outcome underscores the potential of the application to support scalable implementation without imposing substantial financial burdens. Detailed metrics related to the transaction are provided in

Table 6. Transaction fee details.

Transaction	Gas Price per Unit in Gwei		Gas Used	Transaction Cost in Gwei 1	Transaction Cost in ETH 2	Transaction Cost in USD 3
	Base Fee in Gwei	Priority Fee in Gwei
Transaction 1	0.000008157	0.001	163,918	165.255	0.00000016	0.00057
Transaction 2	0.000018558	0.001	146,818	147.090	0.00000014	0.00050
Transaction 3	0.000019033	0.001	146,818	147.097	0.00000014	0.00050
Transaction 4	0.000017642	0.001	146,818	149.408	0.00000014	0.00050
Transaction 5	0.000166831	0.001	146,818	171.311	0.00000017	0.00061
Transaction 6	0.000385548	0.001	146,818	203.423	0.00000018	0.00064
Transaction 7	0.000332263	0.001129204	146,818	214.569	0.00000021	0.00078
Transaction 8	0.000036173	0.001	146,818	152.128	0.00000015	0.00056
Transaction 9	0.000034593	0.001	146,818	151.896	0.00000015	0.00056
Transaction 10	0.00039385	0.001	146,890	204.742	0.00000020	0.00074

¹ Transaction cost in Gwei = (Base fee in Gwei + Priority fee in Gwei) × Gas used. ² Transaction cost in ETH = Transaction cost in Gwei/1,000,000,000 [35]. ³ Transaction cost in USD = Transaction cost in ETH × 3562 (1 ETH ≈ 3562 USD [71]).

, offering a clear perspective on cost-effectiveness.

To better illustrate the distribution of transaction costs compared to the average, the data from the ten recorded transactions were represented as a line chart in Figure 12. Each transaction’s cost is shown alongside the constant average value of 0.0006 USD, allowing for a direct visual comparison.

Based on the recorded transaction costs, the values fluctuate slightly around the calculated average of 0.0006 USD per transaction, with values ranging from 0.0005 USD to 0.00078 USD. While a few transactions, such as Transaction 7 and Transaction 10, were slightly higher than the mean, the variation overall is minimal. This is reflected in the standard deviation of about 0.000094 USD, a statistical measure that indicates how far individual values deviate from the mean. In this case, the low standard deviation demonstrates that costs are tightly clustered around the average, confirming that transaction fees remain consistently close to the mean with only minor fluctuations caused by short-term network demand. Such predictability is crucial for the proposed system, as it ensures that teacher attestations can be recorded on the blockchain at a sustainable and near-negligible cost.

To assess whether our solution remains practical in real-world conditions, we compared its average transaction cost against actual Ethereum Mainnet values. In August 2022, Ethereum fees fluctuated between a minimum of 0.37 USD on 3 August and a maximum of 1.74 USD on 22 August, as reported by Etherscan [72]. Our system recorded an average cost of just 0.0006 USD per transaction on the Sepolia test network, and the results show that our approach could lay the groundwork for integrating low-cost transaction models into teacher attestation systems.

6.3. Latency Analysis

To evaluate latency, we first deployed the smart contract using Remix and then integrated timing logic directly within the application, as illustrated in Figure 13, to measure and display the duration of each transaction involved in generating attestations. This approach records the time elapsed from when the user initiates a transaction until its confirmation on the blockchain. By embedding this measurement process into the application’s workflow, we were able to systematically monitor and report transaction latency across multiple interactions.

The recorded data, capturing the transaction confirmation time during the attestations generation process, are presented in

Table 7. Latency of the transactions.

Transaction	Latency (in Seconds)
Transaction 1	10.32
Transaction 2	11.46
Transaction 3	7.88
Transaction 4	8.08
Transaction 5	8.48
Transaction 6	66.81
Transaction 7	4.37
Transaction 8	9.76
Transaction 9	4.98
Transaction 10	3.51

.

The latency assessment indicates that the majority of transactions were confirmed within a range of 3.51 to 11.46 s, demonstrating consistent responsiveness under standard network conditions. An exception was observed with Transaction 6, which required 66.81 s to finalize. This deviation is attributable to the system’s fee optimization mechanism, which does not rely on external estimators such as MetaMask but instead applies an internally defined calculation procedure that initiates transactions with a conservative gas price. While this strategy enhances cost efficiency, it inherently increases sensitivity to network congestion, as validators prioritize higher-priced submissions. Subsequent measurements returned to expected latency values, confirming the system’s capacity to reconcile cost-effectiveness with operational reliability.

In Ethereum, transaction fees are governed by the base fee mechanism introduced in EIP-1559, which dynamically adjusts according to network congestion. When the average block size exceeds the target, the protocol increases the base fee for subsequent blocks, and, conversely, if the block size falls below the target, the base fee decreases [73]. This iterative process ensures a long-run equilibrium, but it remains highly sensitive to short-term volatility in demand for block space. In our implementation, the transaction fee was determined following the EIP-1559 mechanism. First, the base fee per gas was retrieved from the latest block, with a fallback default value in case the parameter was unavailable. To improve reliability, a dynamic priority fee strategy was adopted, beginning with the network’s suggested tip and gradually increasing by 1–3 Gwei if the transaction remained unconfirmed within predefined waiting intervals of 120, 130, and 150 s. To ensure economic efficiency, an upper spending threshold was enforced. The unusually high latency of 66 s can be attributed to our conservative fee strategy under EIP-1559. Since it had not yet reached the 120 s threshold that would trigger a higher-priority fee, it remained longer in the mempool before being confirmed. This is also reflected in its late inclusion within the block, at position 262. While this approach ensures low costs, introducing an earlier adjustment to the priority fee could help reduce confirmation delays in similar cases.

To better illustrate the distribution of transaction latency, the ten recorded transactions were grouped into ranges and represented in Figure 14, highlighting how most transactions fall within shorter confirmation times.

6.4. Sample Size

The dataset analyzed in this study is limited to just ten transactions, which represents a relatively small sample size. Normally, larger sample sizes provide stronger evidence by capturing a wider range of network conditions and reducing uncertainty. However, the usefulness of a small sample also depends on the degree of variability present in the data. In blockchain systems such as Ethereum, transaction costs are subject to fluctuations in gas prices and network congestion, which can introduce significant variability regardless of sample size. Although a broader dataset would increase the reliability of the conclusions, the present results, even with a limited number of observations, suggest that costs remain consistently low enough to support the feasibility of recording teacher attestations on-chain.

6.5. Security Analysis

6.5.1. Smart Contract Layer Security

To maintain system integrity and prevent unauthorized modifications, the smart contract includes a simple access control mechanism. Only the contract owner, mainly the school that issues the attestations, can generate new attestations, enforced via the onlyOwner modifier. This ensures that attestations are issued by a trusted party and cannot be tampered with by external users.

Also, the smart contract includes validation checks before storing new attestations. For example, it verifies that the attestation ID does not already exist in the mapping, preventing duplicate entries. This is achieved through require statements that enforce these constraints at runtime.

Transactions must be digitally signed using the school’s private key, ensuring that only authorized school personnel can initiate the issuance process and preventing unauthorized individuals from performing this action.

Teachers’ information remains protected, as each attestation is issued individually through separate transactions, avoiding the grouping of teachers by activity and preventing the issuance of a single shared certificate for an entire group.

6.5.2. Application Layer Security

In our application, both administrators and teachers authenticate through a username and password system before interacting with blockchain functions. This dual-level access framework strengthens security by separating roles and limiting privileges according to user responsibilities. Teachers are restricted to read-only access, allowing them to view attestations, verify authenticity, and reconstruct their professional history, without the ability to create or modify records. As a result, the compromise of a teacher’s credentials does not pose a threat to the integrity of on-chain data, since no state-altering actions can be performed. Moreover, this restriction effectively mitigates the risk of denial-of-service attacks initiated through teacher accounts, as no blockchain transactions are generated from their activity.

6.5.3. Network Layer Security

Choosing Ethereum for our application, a network with high degree of decentralization, supported by a large number of validators and nodes, significantly reduces the risk of coordinated attacks, including the possibility of 51% attacks. A 51% attack occurs when a single entity gains control of the majority of a blockchain network’s computational power, enabling them to manipulate the consensus process, reverse transactions, and potentially double-spend funds [37].

Ethereum’s gas fee model serves as a built-in security mechanism by discouraging spam and denial-of-service attacks [37], though it can sometimes pose a cost barrier for users.

7. Discussion

Our hybrid on-chain/off-chain model reduces storage costs and improves scalability, while still ensuring that attestations are verifiable and tamper-proof. Because blockchain storage is costly and limited, the design avoids storing large documents directly on-chain. Instead, we make a connection to the full attestation document stored on the IPFS.

Building a robust and well-designed smart contract is crucial for optimizing performance, security, and cost-efficiency on the blockchain. Our local blockchain tests clearly demonstrate the impact of thoughtful optimization: the improved contract reduced deployment gas used by 11.58%, while gas usage for generating attestations dropped by 58.84%, compared to the initial version. These results, illustrated in Figure 15, emphasize how optimization can lead to substantial cost savings.

Testing on a local blockchain environment enables developers to rigorously evaluate such performance improvements, catch errors early, and fine-tune the contract without incurring costs or network delays [74]. This controlled testing phase is vital before deploying on public testnets like Sepolia, where every transaction consumes resources [74].

In educational institutions where budgets are often constrained, minimizing the cost of blockchain transactions is very important, particularly when thousands of attestations may be issued each year. To ensure cost-efficiency in a system where a high volume of attestations must be issued annually, optimizing the smart contract is essential. Recording extensive information directly on the blockchain, such as the teacher’s public key, name, activity category, and detailed description, significantly increases gas consumption [75], particularly because text fields like activity descriptions can be quite large. For example, adding around 500 characters can raise gas costs by approximately 120,000 to 200,000 units [75]. To preserve the authenticity and integrity of each attestation without excessive on-chain data, the system links each transaction to an off-chain file stored on IPFS via a hash. This hash securely connects the blockchain entry to the full attestation details, including the category and description, thereby ensuring data verifiability while keeping transaction costs manageable.

An important factor influencing the economic viability of blockchain-based attestation systems is the volatility of transaction fees, which are directly impacted by network congestion. During periods of high transactional activity, gas prices on the Ethereum network can rise substantially, making routine operations financially unsustainable for institutions issuing attestations at scale. Given such variability [76] and considering that schools are unlikely to sustain high transaction costs, we decided to integrate a pricing safeguard mechanism within the application. Specifically, if the estimated transaction cost exceeds a predefined threshold, the transaction should not be executed immediately but instead placed on hold until network conditions improve and fees fall below the threshold. While this strategy introduces a slight increase in latency, it offers a practical trade-off to ensure affordability and sustainable usage.

In

Table 8. Comparison of blockchain-based solutions in terms of platform, transaction fee, and latency.

Solution	Type of Document Used in Solution	Solution Name	Year	Ethereum Test Network	Transaction Fee (ETH)	Latency (in Seconds)
Sultana et al. [37]	Academic certificates	-	2023	localhost 8485	0.01124786	not specified
Fartitchou et al. [77]	Academic certificates	BlockMEDC	2025	ZKsync Era Sepolia	0.0000070533	not specified
Farabi et al. [78]	Academic certificates	ShikkhaChain	2025	Sepolia	not specified	12–25
Our solution	Locally issued attestations	-	2025	Sepolia	0.000000164 1	3.51–66.81

¹ Average cost of ten transactions.

we compare our solution with other recent blockchain-based approaches, with differences in focus, but related to education, as most articles in this field address the topic of academic certificates on blockchain [11]. Sultana et al. [37] implemented a system for academic certificates using Ethereum on a local test network, where transaction fees reached 0.0112 ETH. In contrast, BlockMEDC [77] achieved a significant reduction in costs by deploying on ZKsync Era Sepolia, a Layer 2 scaling solution for Ethereum. This explains their much lower average fee of 0.0000070533 ETH, as Layer 2 networks are specifically designed to increase throughput and reduce gas expenses. Another recent system, ShikkhaChain [78], reported transaction confirmation times between 12 and 25 s, showing the feasibility of near real-time certification. Our solution, focused on locally issued teacher attestations rather than academic diplomas, demonstrates that such documents can also be anchored securely on-chain. On the Ethereum Sepolia test network, we obtained an average transaction cost of only 0.0000001641 ETH, with latency ranging from 3.51 to 66.81 s. This balance between low cost and acceptable confirmation time underscores the practicality of extending blockchain certification to school-level attestations, offering teachers a transparent and verifiable way to preserve their professional achievements.

8. Limitations and Threats to Validity

The proposed solution demonstrates that blockchain can serve as a reliable foundation for ensuring the integrity and traceability of teacher attestations, offering transparency and long-term accessibility. However, this work remains limited in scope, as the experiments were conducted on a small set of transactions within a test network. While these results provide useful insights, they may not capture the full complexity of real-world deployments, particularly under conditions of high transaction volume or fluctuating gas fees. Given the limited number of transactions conducted and analyzed on the Sepolia test network, these results should be considered preliminary, with future studies aiming to expand the sample and further explore related transaction behaviors.

In addition, while Ethereum provides strong decentralization and a mature ecosystem, its transaction speed is modest compared to some alternative blockchain platforms that prioritize throughput, which may affect scalability in high-demand scenarios.

A further consideration is the fluctuating nature of Ethereum’s gas costs, where during periods of network congestion, fees can rise substantially, introducing uncertainty and potential barriers to adoption in educational contexts where budgets are constrained. Although our evaluation shows low costs on the test network, real-world deployment would require strategies, such as batching transactions, using Layer 2 solutions, or adopting optimized fee mechanisms, to mitigate the financial impact of volatility.

9. Conclusions and Future Work

This paper has introduced a blockchain-based solution for managing school-level attestations, a category of documents often overlooked in the literature compared to diplomas, certificates, and micro-credentials. By focusing on records issued directly by school administrations, our approach addresses an important yet underexplored dimension of teacher professional development, one that has significant implications for long-term career mobility. Built on the Ethereum blockchain, the system ensures integrity, traceability, and accessibility of teacher attestations.

Our contribution lies in extending the scope of blockchain applications in education to include locally issued documents, highlighting their importance for teacher recognition and evaluation. Experimental results confirm that the proposed solution remains cost-effective and operationally viable compared to real-world Ethereum transaction metrics.

We introduce a blockchain-based solution designed with the potential to scale across multiple schools and institutions. Scalability in our context refers to the ability of our dApp to accommodate broader usage across different institutions [79] without major architectural changes or increased operational costs. By refining role management and introducing hierarchical delegation of authority, higher-level authorities would retain exclusive authority to accredit or withdraw schools, whereas schools would function as delegated operational entities responsible for the issuance and management of attestations.

We intend to extend our current solution by exploring the integration of zk-Rollups, a Layer 2 scaling technology that bundles multiple transactions off-chain and submits them as a single proof to the Ethereum Mainnet [37,77]. By using this approach, large volumes of attestations could be processed more efficiently, with significantly reduced gas fees and faster confirmation times. In future iterations, we plan to test how zk-Rollup-based attestations can support broader adoption in educational contexts, where schools and administrators may need to issue and verify a high number of records across multiple institutions.