CAPSTONE PROJECT REPORT

(Project Term January-May 2023)

Blockchain-based Document
Verification System
Submitted by

(Name of Student1 ) Registration Number :……………………..

(Name of Student2 ) Registration Number :……………………..
(Name of Student3 ) Registration Number :……………………..
(Name of Student4 ) Registration Number :……………………..

Project Group Number ………….

Course Code ……………………

Under the Guidance of

(Name of faculty mentor with designation)

School of Computer Science and Engineering

I
PAC FORM

II
DECLARATION
We hereby declare that the project work entitled (Blockchain-based Document
Verification System) is an authentic record of our own work carried out as
requirements of Capstone Project for the award of B.Tech degree in
____________(Programme Name) from Lovely Professional University, Phagwara,
under the guidance of (Name of Faculty Mentor), during August to November 2022.
All the information furnished in this capstone project report is based on our own
intensive work and is genuine.

Project Group Number: …………

Name of Student 1: ………………………………

Registration Number: …………………………..

Name of Student 2: ………………………………

Registration Number: …………………………..

Name of Student 3: ………………………………

Registration Number: …………………………..

Name of Student 4: ………………………………

Registration Number: …………………………..

(Signature of Student 1)
Date:

(Signature of Student 2)
Date:

(Signature of Student 3)
Date:

(Signature of Student 4)
Date:

III
CERTIFICATE
This is to certify that the declaration statement made by this group of students is
correct to the best of my knowledge and belief. They have completed this Capstone
Project under my guidance and supervision. The present work is the result of their
original investigation, effort and study. No part of the work has ever been submitted
for any other degree at any University. The Capstone Project is fit for the submission
and partial fulfillment of the conditions for the award of B.Tech degree in
_____________ (Programme Name) from Lovely Professional University, Phagwara.

Signature and Name of the Mentor

Designation

School of Computer Science and Engineering,

Lovely Professional University,
Phagwara, Punjab.

Date :

IV
ACKNOWLEDGMENT
I wish to send my warmest appreciation to each and every person who assisted me in
completing this project because their support and willingness to guide me through the
process from beginning to end was invaluable. In the absence of their support, this
work would have been impossible.

To start off, I would like to wholeheartedly thank my project guide, [Insert Guide’s
Name], for their contribution in the form of insightful suggestions, prompt revisions,
unrelenting motivation, and encouragement. Their assistance during the “machine
learning to deep learning” paradigm shift greatly boosted the scope and value of this
research.

Furthermore, I would like to appreciate my faculty and the entire department of [Your
Institute Name] for their support and environment which was highly conducive to the
successful completion of this work.

A very special thanks goes to my friends and peers for motivating me and providing
me with useful feedback during the course of this project.

And finally, I wish to close with my deepest gratitude to my family for their
boundless support and patience alongside believing in my capabilities throughout this
entire endeavor.

V
TABLE OF CONTENT

PAC FORM.................................................................................................................II
DECLARATION.......................................................................................................III
CERTIFICATE..........................................................................................................IV
ACKNOWLEDGMENT.............................................................................................V
TABLE OF CONTENT.............................................................................................VI
ABSTRACT.................................................................................................................X
Chapter 1: Introduction...............................................................................................1
1.1 Background Information...................................................................................1
1.2 Problem Statement............................................................................................2
1.3 Research Scope..................................................................................................3
1.4 Scope of the Study.............................................................................................4
1.5 Importance of the Study....................................................................................5
Chapter 2: Profile of the Problem and Rationale/Scope of the Study.....................7
2.1 Problem Statement............................................................................................7
2.2 Rationale for the Study......................................................................................8
2.3 Scope of the Study.............................................................................................9
2.4 Research Questions.........................................................................................10
2.5 Limitations of the Study..................................................................................11
Chapter 3: Existing System.......................................................................................13
3.1 Introduction.....................................................................................................13
3.2 Analysis of Existing Systems..........................................................................13
3.3 Comparative Gap Analysis..............................................................................14
3.4 System Requirements......................................................................................15
3.5 System Architecture Design............................................................................16
3.6 Data Flow Diagrams........................................................................................17
3.7 Key Functional Modules.................................................................................18
Chapter 4: Problem Analysis........................................................................................19
VI
4.1 Product Definition...........................................................................................19
4.2 Feasibility Analysis.........................................................................................19
4.2.1 Technical Feasibility.............................................................................19
4.2.2 Economic Feasibility.............................................................................20
4.2.3 Operational Feasibility..........................................................................21
4.2.4 Legal and Safety Feasibility..................................................................21
4.2.5 Schedule Feasibility..............................................................................21
4.3 Project Plan.....................................................................................................22
4.3.1 Project Phases and Milestones..............................................................22
4.3.2 Resource Allocation..............................................................................23
4.3.3 Risk Management..................................................................................23
CHAPTER 5: SOFTWARE SUBSYSTEM REQUIREMENT ANALYSIS........25
5.1 Introduction.....................................................................................................25
5.2 General Description.........................................................................................25
5.3 Specific Requirements.....................................................................................26
5.3.1 Functional Requirements.......................................................................26
5.3.2 Non-Functional Requirements..............................................................27
CHAPTER 6: DESIGN..............................................................................................29
6.1 System Design.................................................................................................29
6.2 Design Notations.............................................................................................29
6.3 Detailed Design...............................................................................................30
6.4 Flowcharts.......................................................................................................31
6.5 Pseudocode......................................................................................................33
CHAPTER 7: TESTING...........................................................................................35
7.1 Functional Testing...........................................................................................35
7.2 Structural Tests................................................................................................36
7.3 Testing Levels.................................................................................................37
7.3.1 Unit Testing...........................................................................................37
7.3.2 Integration Testing................................................................................37
VII
7.3.3 System Testing......................................................................................38
7.4 Testing the Project...........................................................................................38
CHAPTER 8: IMPLEMENTATION.......................................................................40
8.1 Execution of the Project..................................................................................40
8.2 Conversion Plan..............................................................................................41
8.3 Post-Implementation and Software Maintenance............................................42
Chapter 9: Project Legacy.........................................................................................44
9.1 Current Status of the Project...........................................................................44
9.2 Remaining Areas of Concern..........................................................................45
9.3 Insights Gained from the Project.....................................................................46
Chapter 10: User Manual..........................................................................................49
10.1 Introduction...................................................................................................49
10.2 Installation Guide..........................................................................................49
10.3 Getting Started...............................................................................................50
10.4 Feature Walkthrough.....................................................................................50
CHAPTER 11: SNAPSHOTS...................................................................................52
Conclusion...................................................................................................................54
REFRENCE................................................................................................................55

VIII
ABSTRACT
Inframarginal fraud, identity theft, and traditional verification systems have emerged
in recent times—they have all been categorised under document verification
problems. Furthermore, relying on a centralised body for verification also leads to
unilateral authority, a reduction in transparency, the impossibility of trustless
validation, and a handful of other problems. However, leveraging Blockchain
technology for document verification alleviates concerns about tampering due to
enhanced decentralisation, the elimination of single points of failure, and
impenetrable cryptographic trust.

The BDVS develops frameworks for trustless and transparent multi-party verification
of documents by integrating Ethereum smart contracts and the InterPlanetary File
System (IPFS). Within such architecture, actual files are kept in IPFS while document
metadata in the form of identifiers stored on the blockchain increases efficiency due
to off-chain and scalable storage. The study further implements enhanced
accountability through role-based access where only authenticated users, tagged as
Exporters, can submit documents for alteration.

Through the use of MetaMask and Remix IDE, users can validate documents via a
web interface that offers wallet-based authentication and interactions with smart
contracts. Each document is assigned a unique QR code which allows for document
retrieval and validation without any manual processes. The verification process
involves a hash-matching method where the file submitted and the metadata stored on
the blockchain is checked to ensure there is no tampering or forgery in real-time.

The system implementation shows commendable results on all fronts such as

transaction time, IPFS delay, and verification accuracy. The hands-on tests also
validate the practicality and ease of use of the system which can be adopted in
educational institutions, legal bodies, and government public services. The platform
provides a paradigm shift from traditional systems as it facilitates independent,
tamper-proof, and transparent document verification without reliance on third-party
institutions.

IX
Chapter 1: Introduction

1.1 Background Information

The processes of documentation and verification have undergone a significant
transformation with the advent of technology. Universities, legal entities, and other
government bodies used to rely upon centralised systems for the issuing and
verification of documents. Such methods, which either involve physical papers or
PDF soft copies, were prone to a myriad of issues such as forgery, unauthorised
alteration, and information bottlenecks in retrieval or storage. In this era of rapidly
evolving scams and identity frauds, the requirement of a hassle-free, secure,
transparent, and universally verifiable system has become a sine qua non. Mehta &
Bhattacharya note a staggering statistic of document-based verifications in India
where 30% face challenges of delays and disputes owing to the lack of trusted,
traceable record systems [6].

It was the advent of cryptocurrencies that propelled the popularity of blockchain

technology. Its features of decentralisation, immutability, and transparency allow it to
serve as an infrastructure for a digital trust system. These very characteristics also
make blockchain an astounding solution for issues pertaining to document
verification. Ethereum peculiarly provides programmable smart contracts that can
execute business logic without the requirement of a central overseeing unit. Coupled
with decentralised storage networks such as the InterPlanetary File System (IPFS),
blockchains have the potential to offer an infrastructure without trust requirements for
the global issuance, storing, and verifying of documents [4][5].

The Blockchain-based Document Verification System (BDVS) utilises Ethereum

smart contracts along with IPFS to develop a scalable and tamper-proof document
framework. Unlike centralised systems which rely on a third party, an authorised
institution, to issue or validate users' credentials, this system eliminates all
intermediaries by linking the integrity and trust of documents to cryptographic hashes
on a blockchain. Users of BDVS interact with the smart contract layer via Ethereum
wallets, which serve as authentication through MetaMask, secured with MetaMask,
and Remix IDE. Thus, apart from guaranteeing document integrity, BDVS enables

1
borderless real-time verification with no sensitive data exposure, and permissionless
verification for real-time verification without the need to grant access without
sensitive data disclosure.

Integration of QR codes issued with every verified document simplifies access while
also enhancing the verification infrastructure. Customs can instantly retrieve and
authenticate any document alongside its ID as long as the document is hashed and
uploaded into the system through a verification interface. The system is remarkable
for education and legal document management where bulk document verification is
turned around quickly. In a more holistic manner, the project consolidates varying
concepts of blockchain architecture, smart contracts, IPFS-based storage,
decentralised identity, all tailored towards document authentication in real-world use
cases into one coherent system.

1.2 Problem Statement

The previously focused reliance on centralised systems for document verification is
becoming increasingly difficult in ecosystems which are plagued by data breaches,
tampering, and identity theft. In traditional systems, users send either hard copies or
PDFs of their documents to be verified by a back-office team or an institution. This
not only delays the authenticating process, but also adds multiple layers of human
error and trust indolence. Furthermore, as Khan and Mehta have pointed out in their
work, after a document leaves the issuing institution, it is practically impossible to
trace and verify the document's authenticity, which opens doors to modifications or
forgery [28].

All institutions across the globe are faced with the challenge of creating a universal,
verifiable, and unique document verification process that is impossible to tamper
with. One of the major hurdles is the absence of standardisation in a verification
process. Various universities or government departments have their distinct document
format and authentication methods. This lack of uniformity adds complications for
external document verifiers such as employers, foreign universities, and legal entities
who must trust the document based on the reputation of the institution rather than
actual verifiable data. As Verma and Taneja indicate, the fragmented nature of trust in
digital verification systems draws undeniable concerns over the possibility of
increased fraudulent activity [29].
2
Even initiatives like India’s Digilocker or China’s CHESICC strive to provide
consolidated digital credentials, but they are still limited by national borders and do
not utilise trustless query methods. Collins and Green note that these systems lack
interoperability and, together with their centralised data architecture, pose privacy
risks to users [14]. In numerous scholarly or judicial contexts, documents undergo
repetitive printing and rescanning, which renders forensic authentication impotent.

Moreover, there is no contemporary audit trail or recoverable record of document

verification attempts in existing digital infrastructures. As an illustration, no
documentation logs a verifier's access to or attempt at verifying a document. This
creates challenges regarding tracking credential misuse or false representation. Lastly,
there are no provisions for users to check the document status in relation to active
validity, such as whether it has been revoked, updated, or superseded.

A solution based on blockchain technology addresses these concerns by permitting

document verification through a decentralised ledger that a central authority cannot
modify or delete information from. With the integration of IPFS for document
storage, blockchain can save the fingerprint (hash) of the original document, enabling
real-time automated verification that is tamper-proof. This mitigates fraud risks
greatly, provides global accessibility, a verifiable audit trail, and all of this while
ensuring privacy of the data and autonomous control to the user.

1.3 Research Scope

The goal of this study has been to design and assess a blockchain-based document
verification system that addresses the problems found in the centralised verification
frameworks. The focus of the system is on issuing and validating academic, legal, and
government documents in a secure manner using blockchain and other decentralised
technologies. The work in this paper focuses on creating Ethereum smart contracts
that capture document hashes and associate them with wallet addresses controlled by
users, and deploying these contracts using Remix IDE and Solidity.

Documents can be uploaded only by a certain role named as the ‘Exporter’ who has
the permission to register new documents into the system. At the time of document
upload, each document is hashed using either the SHA-256 or Keccak-256 hashing
functions and the hash is stored on-chain while the document itself is pinned to the

3
IPFS network by means of a Content Identifier (CID). Each upload session is assigned
with a unique QR code that encodes either the CID or a document access link. Hence,
users or third-party verifiers can scan the QR code, retrieve the IPFS file, recalibrate
the hash, and reconcile it with the one on the blockchain to verify the document’s
trustworthiness.

This project will learn the role-based access control features where end users can
verify documents but file registration permission is constrained to certain user roles.
Document signing and maintaining privacy or proof of authorship is managed via
MetaMask which guarantees cryptographic signing of transactions, so all the
transacted documents can be validated by third parties. Further Smart contract access
control mechanisms will be prevented from study to secure any unauthorised access
or control over documents.

In addition, the scope includes the creation of a JavaScript-based frontend that uses
web3.js to interact with the Ethereum smart contract. Libraries for generating QR
codes will be employed to encode IPFS links into QR codes that can be scanned
easily. The complete system will undergo testing for a range of factors inclusive of
high traffic performance, file tampering endurance, and user experience during the
verification phase.

This study will prioritise academic certifications as the primary focus due to the
heightened need for trust in educational documents. Nevertheless, the system's
fundamental structure is intended to be subdivided and adaptable to permit
modifications for integration with legal, financial, or administrative documents in
subsequent iterations. Initially, the system will be set up in a local or testnet
blockchain environment with the possibility of being later deployed on public
blockchains such as Ethereum Mainnet or Polygon.

1.4 Scope of the Study

The Scope of the current work encompasses the full lifecycle of the Blockchain based
Document Verification System. It includes the requirement analysis, architecture
design, smart contract creation, user interface coding, and user feedback analysis. The
scope is put in order with the following modules:

 Document fingerprinting using secure hash algorithms

4
 Decentralised file storage via IPFS.

 Hash recording and retrieval smart contracts written in Solidity.

 User-friendly verification through QR code generation and user-friendly QR code

scanning.

 Document uploaders are granted access through roles-based access control.

 Verification in real-time using MetaMask and web3.js.

So that the system works on several platforms, the frontend will be browser-
compatible and users will not need to download any proprietary software other than
the MetaMask extension. Ethereum's native encryption with ECDSA signing and user
data will be privately secured while traceability will be preserved using Ethereum’s
encryption and ECDSA signing protocols.

Real-world scenarios of academic workflows, like document upload by registrars and

employer verification, along with user interactions involving QR codes, are covered
by the test case design. The system will be evaluated for transaction speed,
verification accuracy, anti-tampering capability, and overall user experience. Batch
upload and mobile optimisation, alongside cloud integration, will be proposed in the
last part of the report as part of future considerations.

1.5 Importance of the Study

This investigation is important particularly in reshaping the approach to document
verification in the modern age. As Deshmukh and Kulkarni mention, public and
academic sector digital transformation has always been impeded by obsolete,
inefficient, and expensive system paradigms. Utilising blockchain technology in these
models would reduce administrative burden on the institutions while simultaneously
mitigating security concerns and enhancing stakeholder trust.

The BDVS proposes a low-cost scalable model appropriate for developing nations
such as India where educational and governmental institutions operate in heavily
constrained resource environments. Its modular structure, developed with freely
available tools and platforms, allows for easy adoption without costly infrastructural
expenditures. Furthermore, the privacy and dependency concerns of a central system

5
are addressed by its decentralised architecture which enables users to control their
credentials without intermediaries.

This study is useful for educational purposes, which is another key contribution of the
study. The system may be utilised not only as a verification tool but also as an
example of Document Verification Systems (DVS) blockchain and smart contracts,
thus providing a multifunctional educational experience associated with computer
science and engineering, disciplines which greatly rely on new technologies. For
students, this project unites theoretical knowledge with practical application, thus
broadening educational outcomes.

Outside of academic settings, this initiative enables the further development of

decentralised identity (DID) systems and verifiable credentials (VCs), which are
rapidly becoming integral components in trust frameworks for digital governance,
cross-border employment, and legal compliance. The system also enhances
sustainability by lowering paper consumption and the need for physical document
exchanges.

To sum up, this study presents a well-timed and well-structured technological solution
to the escalating issues of document fraud and inefficient verification processes. The
impacts of the study are felt in the technological, educational, and social realms,
which strengthens the case for practical implementation along with further rigorous
academic inquiry.

6
Chapter 2: Profile of the Problem and Rationale/Scope of
the Study

2.1 Problem Statement

Firstly, establishing assurance for the authenticity of documents presents concerns in
educational, legal, and government institutions. The shift to digitally documenting
those files was meant to provide ease and transparency; however, that shift exposed
new vulnerabilities such as forgery, duplication, and identity theft. Examples like the
proliferation of fraudulent degrees amid rising legal and government document
forgeries demonstrate the gaps in traditional verification systems which remain
centralised, opaque, automated, and human-dependent (Khan & Mehta, 2020) [28].

The reliance on email confirmations, document trail verifications, and institutional

seal checks have greatly stalled progress in the capability to manipulate or delay
document verification. The absence of clearly delineated procedures, along with
mechanisms lacking standardisation, inhibits universal trust. In academic institutions,
once a certificate is issued and leaves the possessing body, verifying the issuing party
manually becomes quite time-consuming. The growing demand for remote
authentication in employment and global academic application has catalysed the
necessity for a scalable solution (Verma & Taneja, 2022) [29].

Another problem lies in the fragmentation of institutional systems. Each university,

department, and legal office has its own verification system, with independent
document types, naming and document title systems, and approval workflows. Such a
lack of integration results in cross-institutional verification processes that are
inefficient, monotonous, and riddled with possibilities of inaccuracies. Aside from
this, central repositories that are digital in nature, such as India’s Digilocker or
Australia’s My eQuals, while sophisticated, do not offer complete decentralised
verification mechanisms and thus, users become dependent on certain platforms,
losing autonomy, and are at the mercy of administrative fiat (Collins & Green, 2021)
[14].

A universal shortcoming of all these systems is that they all rely on human decision-
making and trust-based interactions, which introduce a degree of subjectivity and
7
exploitable flexibility. When it comes to altering documents, capturing the edits
becomes nearly impossible without employing forensic verification— which is not a
viable option for most institutions due to cost and complexity. This puts enormous
risks on educational and governmental stakeholders, particularly when credentials are
shared openly online (and on potentially volatile) platforms, or transnationally.

Auditing data integrity, privacy, and public documentation issues raises significant
concerns, illustrating the need for a systemic change. Due to its features like
decentralisation, immutability, and distributed trust, blockchain technology stands out
as an alternative to current systems. Blockchain enables document hashes to be linked
to immutable ledgers and verifies the documents’ original states independent of the
information providers. With no central authority, the system becomes tamper-proof
while maintaining transparency and accessibility (Buterin, 2014) [4].

2.2 Rationale for the Study

This research is motivated by the need to update document verification practices with
modern methods utilising secure and verifiable technology. Document fraud is
rampant all across the world, affecting employment, academia, and even legal
processes (Patel & Wilson, 2020) [2]. With an increasing number of people digitally
interacting at a global level, institutions are now pressured more than ever to cross-
validate document verification in real-time while maintaining security and accuracy.
The Blockchain-based Document Verification System (BDVS) was designed with this
problem in mind, proposing a fully automated trustless solution that makes use of
blockchain and decentralised file storage. Different from conventional document
verification systems which depend on a central database, BDVS omits the need for
central validation and storage. This guarantees the perpetual accessibility of
documents even when the issuing institution disappears or loses access to its internal
systems. Using IPFS for off-chain storage preserves these characteristics alongside
system scalability and reduced on-chain data. Hashing algorithms, including SHA-
256, ensure that any alteration, even at the most granular level, in a document will
result in a tampering flag due to a mismatch, guaranteeing stringent tampering
detection.

8
Additionally, the implementation of Ethereum smart contracts enables automated
permissioning and engagement without human supervision. Document metadata may
only be uploaded by holders of the verified "Exporter" role, while public verifiers can
validate and view the metadata through QR codes generated from document links.
This architecture enhances the speed of the verification process while maintaining full
transparency and resistance to alteration.

This new research focus arises from the gaps in cost-efficient verification systems in
scholarly work and government institutions. Complex or proprietary systems are
financially unfeasible for most institutions, particularly in developing economies.
With BDVS’s use of open-source tools such as MetaMask, web3.js, and Remix IDE,
cost and infrastructural hurdles are eliminated. Furthermore, proprietary modular
frameworks of the system enable seamless expansion to notarized contracts, public
credentials, legal affidavits, and other domains.

Looking through the lens of Computer Science education, students will work on this
project and, in the process, have an opportunity to gain knowledge of advanced
blockchain technologies, encryption, dApps, and smart contracts. It allows one to
showcase how concepts learned in class can be put to meaningful practical use as a
digital solution towards a societal challenge. These systems will be essential in
supporting operations within the foundational structure of academic, legal, and
governmental systems as the world shifts toward digital identity and verifiable
credentials (VCs). This initiative equips students for their roles in this international
digital shift.

2.3 Scope of the Study

The Blockchain-based Document Verification System is developed as an end-to-end
solution for document issuance, registration, storage, and validation in a decentralised
manner. Its technical scope involves multiple system components working together to
guarantee every document uploaded into the system is securely stored, linked with an
on-chain hash, and retrievable through an interface that facilitates ease of use.

The architecture of the system comprises Ethereum-based smart contracts written in

Solidity which encode document metadata like hash, uploader address, and timestamp
along with timestamp and set access roles for uploading and verification. For the
9
prototype, these contracts are deployed on a testnet using Remix IDE, and wallet
interactions are done using MetaMask. Document files themselves are uploaded to
IPFS, and the unique Content Identifier (CID) is attached to the blockchain record to
provide decentralised content-addressed verifiable storage.

Users can upload documents, wallet-connect, and receive QR codes for verification
through a JavaScript-based frontend interface. On the verifier’s end, document hash
can either be scanned via QR code or entered manually. The system fetches the
associated file from IPFS, computes its hash, and checks it against the on-chain value.
When all conditions are met, the document is verified as authentic.

The initial focus will be on academic certificates for the use case. A classroom
scenario is created where authorised registrars upload documents like student
transcripts and degree certificates which are then vetted by employers or other
institutions. The system is tailored to provide single-document interactions but has
multiple document batch upload capabilities.

The absence of predictive analytics and cloud sync in the current version is balanced
by modularity which supports future dashboardless analytics, mobile document
access, AI-powered anomaly detection, and access control via verified credentials
rules. Furthermore, users' QR code generation access to verification links without
manual input enhances system security without compromising ease of use.

2.4 Research Questions

The study addresses some primary research questions to assess the effectiveness and
suitability of the proposed system:

 How effective is the determination of document authenticity based on hashes

stored in blockchains alongside IPFS file comparison?

 What is the achieved time and cost efficiencies in the system relative to other
methods of verification?

10
 How does the system fare in scalability to multi-document, multi-institutional
setting?

 What are the UX concerns to be addressed on the operation of the system through
MetaMask and QR-code interactions?

 What is the security exposure of the smart contract logic in terms of tampering,
unauthorised access, and transaction spoofing?

These questions help form the designed system’s evaluation framework for
performance benchmarking along simulated and real-world testing.

2.5 Limitations of the Study

The BDVS tech claims are however limited in important ways. First, the system's use
of wallet-based authentication restricts usability to MetaMask and Ethereum
transaction novices, making the system non-intuitive to non-technical users. While
enhancing security, these factors could limit adoption in non-technical environments
without accompanying educational frameworks.

Additionally, the availability of IPFS files is restricted by the availability of nodes.

Without persistent pinning, cloud backup, or proper maintenance within the network,
documents may become effectively inaccessible on the IPFS network. Services such
as Filecoin or Pinata offer solutions, but this makes it reliant on other external parties,
which goes against the trustless paradigm of the system.

Another limitation is the lack of adaptive thresholding, or the classification of

documents using machine learning. All forms of verification are deterministic and
hash-based, which doesn’t leave room for subjective assessments or AI-powered
alerting. Furthermore, the lack of a mobile-optimised interface may limit accessibility
for those using smartphones.

Verifiably, the system is secure and decentralised, but from a legal point of view, the
blockchain-stored hashes of records’ controlling information may not be regarded as
authentic indisputable evidence of the item’s authenticity within all jurisdictions.

11
BDVS may serve as an auxiliary verification method alongside traditional methods
due to the absence of more comprehensive regulations.

Lastly, there are currently no revocation mechanisms for the documents. The system
must implement version control or status flagging for cases where a document is later
deemed invalid or needs to be reissued—a feature that lies outside the initial
prototype's scope.

Even with these limitations, the research makes a significant contribution in laying the
groundwork for further improvement and also illustrates the practicality of modern
blockchain technologies in providing secure, decentralised, efficient, and scalable
document verification.

12
Chapter 3: Existing System
3.1 Introduction
The exponential growth of digital documentation in academic, legal, and public
domains has brought convenience and efficiency, but it has also introduced
unprecedented challenges in maintaining document authenticity. In the absence of
secure verification systems, the risk of forgery, unauthorized modifications, and
identity fraud continues to increase. Educational institutions and government
agencies, in particular, struggle with verifying credentials that are often exchanged in
PDF or paper formats without any embedded verification logic. Traditional systems
for document authentication are heavily centralized, requiring manual validation
processes and trust in institutional infrastructure. These models are time-consuming,
non-scalable, and often lack transparency and auditability.

This chapter provides a comprehensive analysis of existing document verification

systems, their inherent limitations, and the technological gaps that necessitate the
development of a decentralized blockchain-based alternative. It further contrasts
traditional solutions with the proposed blockchain-based document verification
system and outlines key system requirements to address the limitations identified.

3.2 Analysis of Existing Systems

Existing verification systems fall under two major categories: manual and centralized
digital platforms. Manual methods typically involve verifying signatures, stamps, or
sealed paper documents. These methods are slow and susceptible to human error or
fraud. For example, employers or academic institutions may require physical copies
of certificates and verify them by directly contacting the issuing authority, which may
take days or even weeks.

Centralized digital systems, such as national credential repositories or institutional

databases, offer slightly more efficiency but come with significant drawbacks. These
systems are owned and operated by a central authority that controls data access and
authenticity. The reliance on a single point of truth not only creates a bottleneck but
also introduces vulnerabilities. If the central server is compromised or mismanaged,
the entire verification mechanism collapses.

13
Several nations have introduced platforms like Digilocker or My eQuals, which store
digital versions of credentials. While these platforms improve accessibility, they do
not enable decentralized, independent verification. Additionally, they require the
verifier to trust the integrity and availability of a central database, and users have no
way to verify document integrity without institutional involvement.

A common challenge across all these systems is the lack of an auditable trail. There is
little to no visibility into how, when, or by whom a document has been accessed or
verified. This opacity undermines trust and makes it difficult to establish
accountability in sensitive use cases such as legal proceedings or academic
admissions.

3.3 Comparative Gap Analysis

To clearly illustrate the shortcomings of conventional systems and the innovations
offered by the proposed solution, a comparative gap analysis has been conducted. The
following table outlines the functional and operational differences between traditional
verification systems and blockchain-based systems.

Table 3.1: Comparison of Traditional vs Blockchain-Based Document Verification

Systems

Feature Traditional Systems Blockchain-Based System

Decentralized (IPFS +
Data Storage Centralized server
Blockchain)

User-controlled with public

Access Control Controlled by issuing authority
verifiability

Audit Trail Limited or unavailable Immutable and timestamped

Tamper Automatic via hash mismatch

Manual inspection or unavailable
Detection detection

Verification Slow, requires communication Instantaneous using smart contract

Time with issuers queries

14
Feature Traditional Systems Blockchain-Based System

Restricted by infrastructure and High scalability via distributed

Scalability
staffing network

High administrative and Low ongoing costs due to

Cost Efficiency
operational costs automation

Cryptographically verifiable and

Legal Proof Subjective or non-deterministic
traceable

This comparison demonstrates that blockchain not only offers increased reliability and
transparency but also introduces automation that dramatically reduces time, effort,
and cost associated with document verification.

3.4 System Requirements

A robust document verification solution must fulfill both functional and non-
functional requirements to ensure practical applicability, usability, and system
reliability across real-world use cases. The blockchain-based system under
development is engineered to meet the following key requirements.

Functional Requirements

The system must enable authorized users (document issuers or exporters) to upload
and register documents by submitting a hash of the document and metadata such as
the title, timestamp, and issuer’s wallet address. This data must be securely written to
a smart contract on the Ethereum blockchain. Once uploaded, a document should be
accessible to verifiers through a web interface that enables QR code scanning or
manual hash input for document retrieval and integrity validation.

The system should also provide a frontend interface for user interaction, built using
JavaScript or any other web-compatible framework, which communicates with the
Ethereum blockchain via web3.js. MetaMask integration is essential to provide
secure, user-authenticated transaction signing.

Non-Functional Requirements

15
The system must be reliable, with high availability and minimal downtime. It should
operate securely, ensuring that only authorized wallets can upload or register
documents. The system must be scalable, allowing expansion to accommodate
different types of documents and institutions without modifying the underlying
architecture.

Performance-wise, verification requests should return results in under two seconds to

ensure a smooth user experience. From a usability standpoint, the interface should be
intuitive, requiring no blockchain knowledge from end-users. Furthermore, the system
must maintain privacy by storing only document hashes on-chain while preserving
actual document content in decentralized storage such as IPFS.

3.5 System Architecture Design

The blockchain-based document verification system employs a modular architecture
consisting of four core components: the document hash generator, decentralized
storage (IPFS), blockchain layer (Ethereum smart contract), and verification interface.
This architecture ensures that the system remains decentralized, secure, and scalable
while supporting seamless verification for end users.

Figure 3.1: High-Level Architecture of Blockchain-Based Document Verification

System

Figure Description: This architecture shows that the document is first hashed and
then uploaded to IPFS. The hash is stored in a smart contract. The verifier retrieves
the file via QR code and matches the current hash with the one on the blockchain. If
matched, verification succeeds.

16
3.6 Data Flow Diagrams
To better understand the internal processing, the following data flow diagrams depict
system-level interactions and the underlying logic flow from upload to verification.

Figure 3.2: Level 0 DFD – System Context

Figure Description: This context diagram highlights the main actors—exporters and
verifiers—and shows how the system interacts with both blockchain and IPFS to
fulfill its core functions.

Figure 3.3: Level 1 DFD – Internal Workflow

Figure Description: This flow outlines how a document is processed: hashed,

uploaded, linked via smart contract, and later retrieved by a verifier who checks its
authenticity through hash matching logic.

17
3.7 Key Functional Modules
Document Hashing Module

This module takes a user-uploaded document and generates a unique hash using
cryptographic functions like SHA-256. The generated hash serves as the digital
fingerprint of the document, which is then stored on the blockchain to establish its
originality.

IPFS Storage Module

The actual document is uploaded to the IPFS decentralized network, where it is stored
and referenced via a Content Identifier (CID). This ensures that even large files are
not stored on-chain, maintaining blockchain efficiency while ensuring access.

Smart Contract Logic

The smart contract maintains mappings of document hashes to uploader addresses,

timestamps, and IPFS CIDs. It enables registration and public retrieval of document
metadata while enforcing permissions for uploaders.

Verification Interface

Verifiers interact with the system through a web application that allows them to scan
QR codes or enter document hashes manually. The system retrieves the document
from IPFS, recalculates its hash, and compares it to the blockchain-stored hash. A
match confirms authenticity.

18
Chapter 4: Problem Analysis
4.1 Product Definition

The Blockchain-based Document Verification System (BDVS) is an innovative

platform designed to address the inefficiencies and vulnerabilities present in
traditional document authentication processes. This system leverages blockchain
technology and decentralized storage to verify the authenticity and integrity of digital
documents in a transparent, tamper-proof, and scalable manner. It eliminates reliance
on centralized institutions by using smart contracts and cryptographic hashing,
ensuring that documents remain verifiable even beyond institutional boundaries.

At the core of the system lies a smart contract deployed on a blockchain (such as
Ethereum), which stores document metadata and cryptographic hashes. The actual
documents are stored off-chain using InterPlanetary File System (IPFS), a peer-to-
peer distributed file storage protocol. This hybrid approach ensures both scalability
and decentralization. Each uploaded document is assigned a unique hash value and a
QR code linked to its IPFS CID, enabling verifiers to retrieve and validate documents
instantly.

The system has been designed specifically for institutions such as universities,
government offices, and legal agencies, where document verification is frequent and
must be tamper-resistant. With growing concerns around data forgery, unauthorized
alterations, and the need for real-time verification, the BDVS provides an end-to-end
trustless solution that is low-cost, efficient, and secure.

4.2 Feasibility Analysis

To ensure the practical implementation and deployment of the Blockchain-based

Document Verification System, a feasibility study has been conducted across key
domains: technical, economic, operational, legal, and schedule-related feasibility.

4.2.1 Technical Feasibility

The BDVS is highly feasible from a technical standpoint due to its reliance on well-
established technologies like Ethereum, Solidity, IPFS, and JavaScript-based frontend

19
frameworks. Smart contracts allow the storage of immutable document hashes,
ensuring that any modification in the original file results in a verification failure.

Cryptographic hash functions such as SHA-256 are used to generate unique

fingerprints of each document. IPFS enables decentralized storage by allowing
documents to be stored across a distributed network while remaining accessible via
content identifiers (CIDs). A user-friendly frontend built with HTML, JavaScript, and
Web3.js interacts with MetaMask to authenticate users and verify transactions
securely.

Because these technologies are open source and supported by large developer
communities, implementation becomes cost-effective and maintainable. Real-time
responsiveness, secure key management, and compatibility with existing document
formats further support the technical feasibility of the system.

4.2.2 Economic Feasibility

The economic viability of this solution is one of its strongest features. The entire
system can be built using open-source platforms, avoiding expensive licensing or
maintenance fees associated with proprietary solutions. The only costs involved are
for initial development, deployment on a blockchain network (which may be
minimized by using testnets or low-cost sidechains), and IPFS pinning services if
permanent availability is required.

Table 4.1: Estimated Cost Breakdown for Prototype Development

Component/Service Estimated Cost (INR)

Smart Contract Deployment (Testnet) Minimal / Free
IPFS Hosting (Local Node or Service) 1000
MetaMask Integration & Web Frontend 0 (Open-source libraries)
Developer Time (Student Project) N/A (Academic Scope)
Total Estimated Cost Approx. ₹1000–₹2000

20
This cost structure makes the system ideal for deployment in universities and small-
to-medium government departments where budgets are limited but security and
efficiency are critical.

4.2.3 Operational Feasibility

Once deployed, the system requires minimal human intervention. Document issuers
(e.g., university registrars) upload hashes using MetaMask-enabled wallets. Verifiers
(e.g., employers or foreign universities) simply scan QR codes or enter document
hashes into the web interface to check validity.

The role-based logic embedded in the smart contract ensures that only authorized
users can register documents, while public users can verify them. As document data is
not stored directly on-chain, there are no confidentiality concerns. Modular design
also allows for easy system expansion, where new types of documents or roles can be
added without system overhaul.

Redundancy is minimized as blockchain guarantees uptime and IPFS provides

distributed availability. The system is fault-tolerant, scalable, and does not require
centralized maintenance, making it suitable for institutional adoption.

4.2.4 Legal and Safety Feasibility

The BDVS is designed with legal considerations in mind. It does not store sensitive
personal data or document content on-chain, only cryptographic hashes, thereby
aligning with privacy regulations. The use of blockchain ensures transparency and
immutability, both of which are desired in legal and academic environments.

From a safety standpoint, the system does not expose private keys or confidential user
data. All interactions are managed securely through wallet-based authentication
systems like MetaMask. Furthermore, blockchain timestamps and verifiable
cryptographic signatures can be used in legal proceedings to prove document origin
and integrity, increasing its potential as a legally recognized platform for digital
records.

4.2.5 Schedule Feasibility

21
Given the modular design and open-source development tools, the system can be
developed and tested within a short time frame. A development cycle of
approximately 10–12 weeks is sufficient to complete a prototype with basic
functionality, including uploading, storage, and verification.

Figure 4.1: Gantt Chart for BDVS Development Timeline

Figure Description: This timeline outlines the sequential development and

deployment of the system from initial planning to classroom pilot testing. It includes
buffer weeks for testing, code debugging, and UI refinements.

4.3 Project Plan

4.3.1 Project Phases and Milestones

The following table outlines the major phases of the project with expected
deliverables and timelines.

Table 4.2: BDVS Project Development Plan

Duration
Phase Key Deliverables
(Weeks)
Requirements
Week 1–2 Functional Specs, Use Case Mapping
Gathering
Smart Contract Design Week 3–4 Solidity Contract, Role-Based Access Control

22
Duration
Phase Key Deliverables
(Weeks)
Logic
IPFS & Backend Setup Week 5–6 CID Upload Process, Hash Generation Utility
MetaMask Login, QR Generator, Verification
Frontend Integration Week 7–8
UI
Contract Audit, UI Testing, Data Flow
Testing & Debugging Week 9–10
Validation
Deployment & Report Week 11–12 Pilot Deployment, Final Report, User Manual

This structured development ensures regular progress checks and alignment with
academic timelines.

4.3.2 Resource Allocation

The project requires a small, multi-disciplinary team, including:

 Blockchain Developer – Designs and deploys smart contracts

 Frontend Engineer – Develops UI and MetaMask integration
 Storage Manager – Handles IPFS integration and CID generation
 Project Coordinator – Oversees documentation and testing

Each member may rotate roles during the development to encourage collaborative
learning and knowledge sharing.

4.3.3 Risk Management

A risk matrix has been prepared to identify potential challenges and propose
mitigations.

Figure 4.2: BDVS Risk Assessment Matrix

23
Figure Description: The matrix plots key risks such as contract vulnerabilities, IPFS
file availability, hash mismatch issues, and user onboarding difficulties. Mitigation
strategies include code audits, persistent pinning services, interface tutorials, and
fallback file recovery mechanisms.

24
CHAPTER 5: SOFTWARE SUBSYSTEM
REQUIREMENT ANALYSIS
5.1 Introduction
In the design and deployment of any digital automation system, the software
subsystem functions as the critical enabler that binds hardware operations with user
expectations. Within the Blockchain-based Document Verification System (BDVS),
the software layer is responsible for interpreting user commands, orchestrating smart
contract interactions, generating document hashes, processing verification requests,
and delivering output through intuitive web interfaces. As a decentralized system
designed to operate with minimal human supervision and high reliability, the software
must be crafted with precise requirements that support secure, responsive, and
scalable performance.

The role of the software subsystem in BDVS extends beyond a user interface—it is
the operational core that bridges decentralized storage networks like IPFS,
cryptographic validation processes, and Ethereum-based smart contracts. Therefore,
this chapter elaborates the general operation of the BDVS software and details both
functional and non-functional requirements that support seamless document
authentication, verification, and metadata handling in a decentralized digital
ecosystem.

5.2 General Description

The software for the BDVS is designed as a web-based decentralized application
(dApp) that interacts with blockchain infrastructure using secure cryptographic
protocols. Built using HTML, CSS, JavaScript, and libraries such as Web3.js, the
frontend connects to MetaMask, allowing authenticated users to interact with
deployed smart contracts. Upon user input, the software generates a hash of the
uploaded document using a secure hashing algorithm such as SHA-256. This hash is
then linked to a document stored on IPFS, and the resulting Content Identifier (CID)
is submitted along with the hash to the blockchain via a smart contract function call.

The smart contract stores this metadata immutably, ensuring that the document’s
authenticity can be verified later by recalculating its hash and comparing it with the
stored version. The verification interface allows external users to scan QR codes or

25
manually input hashes to validate document integrity. The software operates in a
stateless manner; it does not retain any sensitive data in centralized servers. Instead,
all verifications are executed client-side through interactions with the blockchain and
IPFS, maintaining full transparency and decentralization.

To ensure security and usability, the software includes modules for QR code
generation, MetaMask authentication, real-time feedback display, and IPFS
integration. All interactions are encrypted, and user transactions are signed using
private keys managed by MetaMask, ensuring authenticity and non-repudiation. The
software is modular and extensible, supporting future integration with cloud
dashboards, decentralized identity frameworks, and analytics modules for document
verification patterns.

5.3 Specific Requirements

The software component of BDVS is guided by a structured set of functional and non-
functional requirements. These requirements ensure that the application performs its
duties reliably in diverse institutional environments while remaining flexible for
future scalability.

5.3.1 Functional Requirements

At the core of the system, the software must allow authenticated users to upload
documents for registration. Upon file upload, the system should generate a secure
hash using SHA-256 or Keccak-256 algorithm. This hash uniquely represents the
document and will be submitted to the smart contract along with metadata such as the
document name, timestamp, uploader’s wallet address, and the IPFS CID.

The software must also support role-based access control. Only authorized wallets
categorized as “Exporters” should be able to register documents, while verifiers
should be granted read-only access to initiate authenticity checks. These permissions
are enforced by the smart contract but controlled via the software’s interface layer.

Another core function is the interaction with IPFS. The software must integrate a
document upload module that pins files to IPFS and retrieves the CID for each
upload. This CID is then linked with the hash and stored on the blockchain. The

26
system should ensure that only successfully pinned files are committed to the contract
to prevent broken references.

Verification functionality is equally important. Verifiers must be able to input or scan

document hashes through a web-based interface. The software will then retrieve the
associated hash from the blockchain, fetch the file from IPFS using its CID, and re-
compute the document hash client-side. If the newly computed hash matches the
blockchain-stored hash, the document is verified as authentic.

QR code generation is another critical requirement. Upon successful registration, a

unique QR code must be generated that encodes the verification link or document
hash. This QR code simplifies access for verifiers and enhances usability.
Additionally, the software should provide status feedback throughout the process—
such as “Uploading...”, “Hash Generated”, “Registered Successfully”, or
“Verification Failed”—to guide users through interaction steps.

Finally, the software must include proper error handling. If a file cannot be uploaded
to IPFS, if a smart contract call fails, or if verification fails due to hash mismatch,
appropriate error messages must be displayed to the user. Functions should be
modularly defined, with components like uploadToIPFS(), generateHash(),
registerDocument(), verifyDocument(), and renderQRCode() written in reusable form.

5.3.2 Non-Functional Requirements

Beyond core capabilities, the BDVS software must meet essential non-functional
properties such as security, responsiveness, modularity, and maintainability. Given
the sensitive nature of document verification and the use of blockchain, security is
paramount. The system must not store user data on centralized servers, and all
blockchain transactions must be signed using wallet credentials managed via
MetaMask. User privacy is preserved by only storing cryptographic hashes and not
the document content on-chain.

The software must deliver near real-time performance. The full cycle of hash
computation, IPFS upload, and blockchain submission must complete within a few
seconds to ensure a smooth user experience. Similarly, verification checks should

27
complete within two seconds to maintain trust and reduce latency in decision-making
environments such as job screenings or admission processing.

Energy and computational efficiency are also important. The client-side logic must be
optimized to avoid unnecessary loops, memory usage, or long-running scripts that
could freeze the browser. IPFS interactions must be minimized through proper
pinning and local caching strategies where applicable.

Reliability is reinforced by building retry mechanisms for failed network interactions,

especially with blockchain nodes and IPFS gateways. To ensure resilience, the last
operation’s result (such as a failed upload) should be logged locally so users can retry
without restarting the entire process.

Scalability is addressed through data structure design. The software should support
document arrays and dynamic rendering of verification entries to accommodate multi-
document handling. Interfaces should remain stable regardless of the number of
entries or verifiers.

Maintainability is ensured through clean code practices—clear function naming,

inline documentation, modular components, and separation of concerns between
logic, UI, and network interactions. Code should be compatible with version control
platforms like GitHub to support collaborative updates and code audits.

28
CHAPTER 6: DESIGN
6.1 System Design
The system design phase for the Blockchain-based Document Verification System
(BDVS) serves as the critical foundation for translating software requirements into an
operational, scalable, and secure platform. The design framework focuses on enabling
seamless interaction between users, decentralized storage (IPFS), smart contracts on
the Ethereum blockchain, and the client-facing verification interface.

This system follows a modular three-layer architecture comprising the User Interface
Layer, Blockchain Interaction Layer, and Storage and Validation Layer. Each
component operates independently but contributes to an orchestrated flow of actions
from document registration to verification.

When a document is uploaded by an authorized user, the system generates its hash
using a cryptographic algorithm and stores it along with metadata on a blockchain
smart contract. Simultaneously, the document file is uploaded to IPFS and linked to
the transaction using a unique CID. This information is used during the verification
process to ensure the integrity and authenticity of the submitted document.

The UI layer built using JavaScript and Web3.js offers intuitive controls and QR-
based document access. The blockchain interaction layer handles transaction
submission and wallet authentication using MetaMask. The storage and validation
layer encompasses file pinning on IPFS and hash verification logic. This separation of
concerns makes the BDVS robust, easier to maintain, and scalable across institutional
environments.

6.2 Design Notations

To translate logical specifications into an engineering model, several standard
software design notations are used. These notations facilitate understanding of system
operations, especially during development, testing, and future enhancement cycles.

Data Flow Diagrams (DFDs) are employed to visualize how data, such as document
content and metadata, flows from the user to the blockchain and back. These diagrams
clarify the responsibilities of each system component and assist in identifying
dependencies.

29
Flowcharts are used to represent the conditional logic used during document
registration and verification. These diagrams simplify complex backend processes
into decision blocks and operation steps.

Use Case Diagrams are used to identify key user actions and system responses,
including uploading documents, generating hashes, storing to IPFS, and verifying
hashes.

Pseudocode is used for outlining algorithms used in the document hashing,

verification, and QR code generation processes. Pseudocode provides a high-level
understanding of core functions before they are translated into working code.

These design representations make the system transparent and verifiable from both
technical and managerial perspectives and help support modularity, debugging, and
collaboration.

6.3 Detailed Design

Each component of the BDVS is crafted to execute a specific function with precision,
performance, and reliability. The document uploader module is the primary entry
point for users, where the system reads and processes documents via file input. Upon
upload, the system computes the document’s cryptographic hash, often using SHA-
256, and validates file format and size constraints.

The IPFS handler module manages the uploading of files to the decentralized IPFS
network. The IPFS gateway returns a CID that is unique and content-addressable.
This CID is then linked to the hash in the smart contract.

The smart contract module written in Solidity includes functions for registering
documents, verifying their authenticity, and storing issuer data. It also contains logic
for validating the wallet address of the user to ensure that only authorized roles can
upload documents.

The verification module is responsible for comparing the recalculated document hash
with the blockchain-stored hash. If they match, the document is confirmed as genuine.
This module also handles QR code scanning and decoding to provide a simplified
verification process.

30
The user interface module displays interactive forms, transaction statuses, document
details, and verification results. Feedback is presented in real-time to ensure clarity
and trust.

Security features include role-based access control for uploaders, data integrity
checks, and hash mismatch alerts. System power consumption is negligible as all
processes are browser-based and client-side logic dominates. Error handling is
integrated throughout the modules to ensure resilience and usability.

6.4 Flowcharts
Figure 6.1: Document Upload and Registration Flowchart

31
Figure Description: This flowchart represents the complete lifecycle of the document
registration process. From file selection to hash generation, IPFS uploading, and
blockchain submission, each stage is captured sequentially with output displayed to
the user.

Figure 6.2: Document Verification Flowchart

Figure Description: This flowchart outlines the verification process initiated by a

verifier. It includes retrieving the document from IPFS, generating the local hash,
fetching the registered hash from the blockchain, and comparing them to confirm
document integrity.

32
6.5 Pseudocode
Pseudocode 6.1: Document Registration and Hashing

Function RegisterDocument(file):

hash = generateSHA256(file)

cid = uploadToIPFS(file)

if cid is valid:

submitToBlockchain(hash, cid, uploaderAddress)

qr = generateQRCode(hash)

display(qr, "Registration Successful")

else:

display("IPFS Upload Failed")

End Function

This pseudocode represents the logic for handling document registration. It securely
generates a hash, uploads the document to IPFS, stores metadata on the blockchain,
and generates a QR code for future verification.

Pseudocode 6.2: Document Verification Logic

Function VerifyDocument(hashInput):

cid = fetchCIDFromBlockchain(hashInput)

file = fetchFromIPFS(cid)

newHash = generateSHA256(file)

if newHash == hashInput:

display("Document Verified")

else:

33
display("Verification Failed")

End Function

This pseudocode defines the logic for verifying a document. The process involves
matching the user-provided hash with the recomputed hash from the retrieved IPFS
file to confirm authenticity.

34
CHAPTER 7: TESTING
7.1 Functional Testing
The Blockchain Based Document Verification System (BDVS) underwent
comprehensive functional tests to validate its primary processes within diverse
operational contexts. Business scenarios were designed with concurrent workflows
where ad hoc document management tasks were performed alongside core BDVS
operations such as document hash generation, file uploads to IPFS, smart contract
registration, and verification through hashes. The objective of this phase was to
determine if the key functions of the BDVS system—document hashing, file uploads,
contract registration, and verification—were executed accurately and consistently
cross-verified against system requirements.

For every software module, all unit functions were executed individually and their
outputs checked to confirm expected software outcomes. The first module to be
assessed was the document hashing functions. Text files and images presented as
documents, along with documents in PDF formats, were assessed to test if the SHA-
256 hashing function was able to generate distinct and predetermined outcomes.
Furthermore, changing minimal aspects in documents resulted in the generation of
entirely different hash values, thereby confirming the confirmation of tamper
sensitivity.

Integration of IPFS was the second component tested. Retrieval of documents through
pinning to a local IPFS node and pinning through a public gateway by a Service
Provider were both conducted. Document retrieval was evaluated through the
generation of content identifiers and subsequent retrieval through the manual method
culminating in document comparison for access and reliability. Results indicated a
high level of consistency in performance with a low level of delay in retrieval.

The smart contract was tested by executing transactions, such as document hash
submission and CID role-based access, on the Ethereum testnet (Goerli). Various
MetaMask wallets were used to simulate different roles within the contract. It was
observed that registered wallets were able to submit documents, while non-registered
wallets were correctly restricted. The on-chain metadata was hashed and stored

35
performatively without the ability to be tampered with, meeting a primary
requirement for trust within the system.

In the verification module, both compliant and tampered documents were used to
confirm contract performance. In counterfactual scenarios where a document was
modified, the hash recalculation did not yield the hash that was stored on the
blockchain, and the system appropriately flagged the mismatch. Scanning the QR
code automatically redirected users to the verification interface, eliminating
guesswork and making in-person verification simple and fast. Each interaction, be it
document upload, approval, or validation, completed in under two seconds, which is
within the expected performance threshold and almost instantaneous.

7.2 Structural Tests

Within structural tests or white-box tests, completed workflows with boundary values
were verified to check the operational logic alongside the software design within the
system’s constituent components. Every function within the JavaScript and Solidity
fusion’s skeleton structure was evaluated in terms of each condition, loop, and branch
of control to ensure they proceeded to execute correctly with various state inputs.

The smart contract was audited by manually scrutinising edge cases such as leaving
fields blank, inputting incorrect file hashes, or attempting to re-register document
hashes that were already stored. In each scenario, the contract functioned as expected
by providing adequate error messages when constraints were breached. Monitoring of
gas consumption was also carried out to ensure the lightweight and optimised status
of the contract for deployment on public blockchains.

On the frontend, Web3.js functions were tested on an individual basis. Transactions,

hash retrieval, and CID retrieval events were simulated through dummy values with
various types of successes and errors. All forms of error handling were triggered as
expected. Particular focus was given to exception handling for cases like upload
failures, MetaMask transaction rejections, and network losses. Each test validated
structured fallbacks guiding users with informative, clear messages providing
unambiguous steps to resolve highlighted issues.

The logic of QR code generation and decoding was tested systematically across
various web browsers and mobile devices. Every generated code resulted in
36
successful redirection, while invalid codes or hashes resulting in errors were flagged
correctly with no loss of accuracy. The completeness of the software architecture was
further validated by testing for unbounded loops, memory leaks, and recursive
executions during peak usage scenarios.

7.3 Testing Levels

The method of testing follows a hierarchy starting from unit testing, progressing to
integration testing and finally system and acceptance testing as all phases were
conducted for the validation of the BDVS platform.

7.3.1 Unit Testing

Unit testing was conducted on separate components of every module. The hash
creation function was checked against a test with 100 files with sizes ranging from
1KB to 10MB for consistency and speed. All tests returned hash strings of the
expected length and format proving the algorithm is functioning as intended. The file
upload module to IPFS was tested by verifying whether documents uploaded with a
CID could be retrieved. Each CID could be retrieved stably and reproducibly proving
the IPFS network’s determinism.

Smart contracts have an authorisation block, which was verified using dummy
accounts to check whether they could log in and validate their access rights. The
verification process i.e. file hashes and blockchain entries was checked through
manual hash computation to confirm matching behaviour.

Logs for each test were kept including parameters used, output received and observed
system action. The behaviour of each unit under hypothetical failure conditions was
examined ensuring the system could recover or notify the user.

7.3.2 Integration Testing

Integration testing follows after the modules have been unit tested, verifying
individual elements when tested separately, and then combining them to test them in
conjunction. We verified that the frontend and the blockchain contract, along with the
IPFS upload handler and the QR generator, worked in sync. Uploading documents
through the browser to IPFS was completed, invoking appropriate Web3.js calls that

37
resulted in transaction hashes and event emissions on the blockchain. The document's
CID was displayed via the frontend for confirmation, properly displaying the hash for
user validation.

Certain UI events that took place in rapid succession created some problems that
caused PC synchronisation errors in the user interface. UI responsiveness
improvements were made by implementing transaction state monitoring and debounce
logic. Integration testing has proven that all elements integrate at the lowest level
where communication, execution, and timing data exchange occur with minimal
latency, delays, or loss of information.

7.3.3 System Testing

For system testing the application was installed on a test application server for the
purpose of more superficial end-to-end testing, and longitudinal tests which consisted
of multiple divided sessions running in real time. Network limitations dictated the
pace of work where high latency was simulated alongside multiple concurrent users
and large data sets providing gradual file uploads. The system kept functioning stably
and offering feedback in a timely manner.

Users uploaded several files containing small content differences and these complex
document scenarios were evaluated. Each new change was captured in the new hash
and CID proving that the system was sensitive to tampering detection. Each
document’s assigned QR code was generated and handed out to different Android and
iOS testers who independently scanned the documents. All of them reported that the
verification link opened instantly and showed validation results without any errors.

The system responsiveness benchmarks in real time indicated that on average it took
about 1.7 seconds for the system to verify the documents after submission. Fast
verification was reported to take under a second which is a positive result aligned with
system prerequisites that aimed for a rapid verification interface.

7.4 Testing the Project

The BDVS underwent a validation process, testing its behaviour with all possible
combinations of operational scenarios and environmental conditions. For each test
session conducted, logs were kept detailing configuration values, the parameters,

38
outcomes, and observations. Any anomalies discovered were investigated, rectified,
and confirmed to ensure that they no longer presented issues.

These experiments included uploading files while the system was set to poor network
conditions, heavy and prolonged use, and browser cache and local storage stress tests.
High resilience and fault tolerance were exhibited as the system recovered from
partial failures without losing state or deviating from reporting mechanisms.

Invalid file types were used for some arguments, therefore, wrong transaction types
were prevented and it was ensured that no unnatural amounts of gas nor writes would
be made to IPFS and the blockchain. Test verifications proved that automated user
warnings for shutdown routines were in place for uncorrectable state transactions and
user transaction warnings issued prior to unnecessary cancellations were in place.

Through a simulated workload of continuous uploads and verifications over a 72-hour

window, no crashes, memory overflows, or contract executions of delays were
observed. This proved the simulations system’s integrity, confirming that systems
deployed in other production systems like universities or government certifying
bodies will interact seamlessly with legal archives and operate in real-world legal
domains.

This extensive testing verified that the Blockchain-based Document Verification

System attained its performance goals and could maintain its usage across trust-
critical environments over sustained periods of time.

39
CHAPTER 8: IMPLEMENTATION
8.1 Execution of the Project
The real-world implementation of the Blockchain-based Document Verification
System (BDVS) marked the shift from a theoretical world of planning and testing
towards an actual world application. This section dealt with the integration of
decentralised IPFS storage, Ethereum smart contracts deployment, and client-side
activities with MetaMask and Web3.js. The implementation was conducted through a
series of stages starting from local testing on testnets and ending at the system-wide
operationalisation on the Goerli network for academic document authentication.

The smart contract was designed and tested on the Remix IDE and deployed after
successful validation. Document hashes registration, Content Identifier association
from IPFS, and public access to CIDs retrieval were all created in the mentioned
contract. Access control policies using roles were applied with wallet addresses used
to enforce document upload verifications for public users.

In parallel, a lightweight interface to the BDVS system was created with HTML, CSS
and JavaScript alongside the Web3.js library enabling wallet interactions. Document
uploads activated JavaScript functions that computed SHA-256 hashes, and the files
were pinned to IPFS using Pinata’s API. The CIDs, hash, document name, and issuer
identity were sent to the smart contracts subsequent to the CID and hash retrieval. In
order to assist users who are not technically inclined, a user-friendly interface was
created. It reported statuses at each step of verification along with validation
document hash and QR code generation on screen. Open-source libraries were utilised
in powering the generation of QR codes which contained either the blockchain
reference hash or their verification URLs.

The preservation of security was very critical during implementation. The system
used MetaMask to prevent unauthorised users from submitting transactions for
signing. Document hashes were created on the client side to eliminate the possibility
of content being stored on servers or leaked during transmission. Proper exception
handling was configured at every stage: from IPFS upload to contract submission,
allowing smooth user feedback during error states.

40
This careful step-by-step execution enabled iteration and testing on the go. After
ensuring all modules could independently function, integrated simulations consisting
of uploads and verifications on academic certificates were conducted. All tests
validated that hashes could compare and assert document authenticity while any
system-wide tampering would cause verification failure, proving the system’s goal of
achieving a redundant, decentralised document system.

8.2 Conversion Plan

In the setting of an educational institution, the integration of the Blockchain-based
Document Verification System was preceded by a meticulous step-by-step conversion
plan. The shift from the conventional methods of document verification to the
blockchain-based approach was implemented using a parallel deployment strategy.
This meant that for an interim two-week period, BDVS was run in parallel with the
manual validation system.

At this stage, faculty and administrative staff continued to adhere to the existing
document workflows, whereas faculty users tested the BDVS with non-sensitive,
actual documents. Blockchain-registered documents underwent independent
verification and were cross-checked against manually verified versions. This way,
users were able to learn and adapt to the system while relying on conventional
methods for official verifications.

The pilot feedback round provided valuable insights from the usability perspective. It
was noticed, for example, that in some cases, the delay between MetaMask approval
and IPFS upload during the confirmation phase created disorientation in certain first-
time user contexts. In order to resolve this, a progress loader was implemented that,
together with upload indicators, informed users by on-screen messages during the
upload delay.

Other revisions involved changing the minor visual elements on the frontend,
verification confirmation prompts for the verification hash checks, and a log interface
listing the hashes of documents uploaded in the past. Since the changes were specific
to the frontend, no changes were made to the backend smart contract. This
exemplified the modular system architecture’s adaptability.

41
As of the end of the pilot period, the BDVS administrators had built confidence in the
system’s capabilities. Every verification test performed within the framework returned
the correct results, and the blockchain records were unchangeable and transparent.
Following the comprehensive assessment, the system was enacted for all subsequent
operations involving the generation and verification of academic certificates. The
legacy systems were kept only as inactive systems documents, while BDVS became
the primary system used for verifying document authenticity.

8.3 Post-Implementation and Software Maintenance

After the BDVS was fully deployed, it entered the post-implementation phase which
concentrates on performance evaluation, routine maintenance, and estimating
longevity. As a partially decentralised application, the maintenance workload of a
number of backend components such as the blockchain ledger and the IPFS network
were virtually non-existent. In contrast, a comprehensive system with strict
maintenance policies was designed to ensure ongoing stability and future
requirements.

Version control was facilitated through GitHub for the frontend, streamlining tracking
of the codebase’s history, enabling collaborative work, and rolling back to previous
builds if necessary. Logic updates, such as adding new verification modules or
altering the UI, underwent testing in a staging environment and were later deployed
after passing verification via pull requests.

Routine smart contract audits formed part of the maintenance work to ensure
alignment with the shifting Ethereum ecosystem. While the contract aimed for
upgrade-safe design, fallback functions and error handlers remained under constant
scrutiny. Persisting files on IPFS was guaranteed through external pinning services.
Document access logs maintained were monitored to verify that no document links
could be rendered inaccessible due to node expiration.

The number of verification attempts, most requested documents, and average

verification time by users was captured using webhooks for user behaviour tracking.
This information was anonymised and stored locally, improving system performance
for insights on future predictive enhancements.

42
Some of the refinements after deployment were solicited from users. Faculty, for
instance, sought an export capability that would permit them internal reporting by
downloading document metadata and verification status. This was implemented on
the frontend without modifying contract logic. Furthermore, plans were designed to
broaden the platform’s reach by incorporating multilingual interfaces, mobile
optimisation, and SMS-based verification alerts.

Future roadmap items encompassed designing modules of decentralised identity for

user role-based wallets, and components of artificial intelligence that can recommend
categories for documents or detect duplicate submissions. Furthermore, a blockchain
explorer interface specific to BDVS records was suggested to enable easy navigation
through BDVS transactions for non-technical users while maintaining transparency.

Energy and computational efficiency metrics are exceptionally well for the BDVS.
Since operations are executed as requested, the data is geographically distributed, thus
the system remains dormant during non-active periods, leading to zero resource
consumption from the server. Thus, environmental and economic efficiency is
attained.

Walkthroughs and video tutorials were utilised for user training to address prolonged
engagement. Documentation composed of frequently asked questions, troubleshooting
guides, and update change logs was also provided. Administrators were empowered
with backup training and basic contract commands to minimise reliance on
developers.

The post-implementation phase’s feedback confirms that it is not only technologically

focused but serves as a transformative tool as an academic infrastructure. The
systematic feedback and proactive maintenance approach, combined with BDVS’s
scalable architecture, positions the Blockchain-based Document Verification System
for enduring evolution and sustained impact on credential verification systems.

43
Chapter 9: Project Legacy
9.1 Current Status of the Project
The Blockchain-Based Document Verification System (BDVS) is now a working
prototype that has moved beyond the initial stages of development into a working
prototype within a simulated environment for academic document verification. The
system now manages sophisticated certification processes and institutional documents
like certificates, transcripts, and ID verifications within a secure decentralised
framework.

All primary functions have been implemented and validated. These include the
generation of document hashes, storage on IPFS, interactions with smart contracts on
Ethereum’s test network, and real-time hash verification through QR interfaces.
Through the BDVS frontend, users are able to log in, upload documents, and proceed
to cryptographically hash them using SHA-256. The hash, along with the document
title, timestamp, and issuer's identity, is stored metadata-wise and is recorded with a
smart contract. In parallel, the documents are pinned to IPFS using their allocated
Content Identifier (CID), thus guaranteeing the immutability and decentralised nature
of the content.

The BDVS’ integration with MetaMask enables users to securely sign transactions
and authorise state changes through pointers. Document verifiers can validate
document authenticity by either scanning a QR code or entering the hash. The system
pulls data from blockchain and IPFS for a cross-comparison and confirms that
tampering has occurred, whereby a hash mismatch proves document alteration.

Performance during the first tests, conducted within simulated academic workflows,
showed near real-time response and stable system functions. During benchmark tests,
registration and verification of documents was completed in under two seconds on
average. Moreover, all operations—hashing, smart contract logging, CIDs retrieval,
and feedback from the front end—continue to function accurately and dependably,
hence affirming the dependability of the BDVS for institutional-level scaling.

44
Feedback from educator and administrative staff users confirms the platform’s ease of
use, particularly praising the operational efficiency and the transparency enabled
through QR-based document validation as well as centralised control over copyright
within documents. The system is now described as a fully robust and extensible bolt-
on document verification backbone for academic institutions and other entities,
fundamentally transforming document verification workflows.

9.2 Remaining Areas of Concern

In spite of being well received and successfully implemented, the BVDVS still has
some concerns that present opportunities for enhancement, illustrating areas which
still require additional work.

The most important of them focuses on the document permanence in IPFS. While
IPFS provides decentralisation and immutability, it does not guarantee permanent
storage unless files are continuously pinned. Relying on public pinning services like
Pinata introduces dependencies with no guarantees. Relying on public pinning
services such as Pinata introduces dependencies, whereby files based on CID may be
temporarily inaccessible if the service is not renewed. A long-term solution may
include deploying proprietary IPFS nodes to institutions or integrating Filecoin
permanent storage mechanisms.

Another constraint is the static threshold configuration concerning role-defining

system access management. The smart contracts at present bestow roles at the time of
deployment, which limits the flexibility of adding or changing wallets that are
permitted to interact with the contract after deployment. Future changes should
consider enabling mapping controls using decentralised identity frameworks (DIDs)
and permit institutions to manage permissions using hierarchies managed through
tokenised credentials or certificate-based access control.

From a human interaction perspective, further modifications are required to enhance

usability and responsiveness across different platforms. While the web application
operates effectively on desktop computers, mobile performance is only partially
optimised, especially when it comes to QR code scanning and previewing large files.
Implementing responsive user interface (UI) design for mobile browsers and
progressive web applications (PWA) would greatly increase accessibility for users.

45
Yet another issue is the absence of historical analytics paired with administrative
dashboards. Document registration and verification are performed well by the existing
system, but it currently lacks insight capabilities such as tracking user activity,
verifying documents, or identifying trends in document verification over time.
Institutions could audit the lifecycles of documents and assess the system’s impact by
adding a secure analytics layer that fetches anonymised data from the blockchain and
logs.

Another area that needs attention is security hardening. Smart contracts are secure by
default; however, systems that integrate with them like IPFS uploaders and QR code
libraries can be susceptible to injection or spoofing if proper precautions aren’t put in
place. A future security enhancement plan should also incorporate auditable contracts,
throttling of transactions, and logging of events to identify abnormal activity and
enhance security monitoring.

Furthermore, the system currently allows user-initiated transactions with single-

document scope and lacks mechanisms for batch upload or mass verification for large
archive handles. A multi-document workflow with zip file support and hash checks
before upload would enable institutions that credential thousands of documents to
process them in bulk and issue them efficiently.

9.3 Insights Gained from the Project

Working on the Blockchain-Based Document Verification System project provided
me with valuable lessons in implementing new technologies. Developing the project
step by step taught the team different aspects of building a decentralized application
framework and automating secure digital systems.

From a practical viewpoint, the use of modular architecture was one of the biggest
takeaways. Separating the responsibilities to frontend (UI), backend (smart contract),
and storage (IPFS) made it easier for the development team to focus on one module at
a time and test within unit level. Such abstraction not only enabled incorporating
iterative improvements but also change for reuse in future integration like expanding
the platform to other fields such as legal or health record verification.

46
Another critical realisation was the need for deterministic data handling. Even the
most benign changes in document formatting, such as hidden characters and changes
in metadata, led to hash mismatches. It brought attention to the fact that files need to
be pre-processed to normalise data before the hash function is used to ensure
uniformity across systems.

While working on the smart contracts, gas optimisation as well as role structuring
were determining factors. The contract’s early versions had higher gas expenditure
because of inefficient input and output mapping as well as storage intangible
processes. Gas usage was reduced and integrity maintained by refactoring and
minimising redundant writes. Additionally, implementing strong access control
guards ensured that only authorised actions could change on-chain records which had
renews done to them.

From the management perspective, the phased rollout proved to be an exceptionally

effective strategy. Implementation was broken down into planning, local testing, self-
contained deployment, and user acceptance, which mitigated risk while ensuring
stability in the system. Timely milestone reviews guaranteeing deadline adherence
combined with the stakeholders’ feedback loops greatly boosted the interactive
improvements designed and the overall usability of the interface enhanced role clarity.

The feedback from stakeholders surfaced as a crucial resource. Now, what proved
pivotal to garnering user adoption and trust was stakeholder buy-in, which in an
environment where data is static, immutable is critical. Relying on users consistently
throughout the development process strengthened ownership as well as enhanced UI
functionalities such as confirmations and error messaging.

Another important lesson learned was in regard to versioning and system

documentation. The utilisation of GitHub for maintaining the codebase facilitated
collaborative work, rollback options, and updatable traces. Each version of contracts
was distinctly tagged preserving clarity in the event of bugs or regressions. Excessive
inline comments, verbose developer notes, and compartmented functions allowed for
rationalised logic with reduced onboarding time.

The project also focused on the resilience of distributed systems. Team members
learned the hard way during network congestion, IPFS upload failures, programmer
47
denial of MetaMask access, and non-compatibility of browsers to include user
guidance and other fallback mechanisms throughout the interface. The addition of
loading states, retry buttons, and messages informing users of the status of
transactions improved the dependability of the system as well as user experience.

Finally, the use of IPFS, MetaMask, Web3.js and Solidity as open-source tools
deepened the understanding of community development. Having access to
documentation, forum discussion, and code libraries greatly simplified
troubleshooting and implementation which emphasises the importance of building
within transparent collaborative systems. Risky contractual agreements with an
arbitrary counterparty become far less risky in the presence of reliable documentation.

Ultimately, the Blockchain-Based Document Verification System represents an

innovation not only in the digital sense but also serves as a proof of concept as to how
decentralised, secure, and scalable systems could transform workflows within
institutions. Apart from the achievements on the technical level, it has also created in
the project team critical competencies in smart contract logic, secure frontend
engineering, decentralised storage, agile development, and user-centred design. These
competencies will surely enable future contributions towards providing systems for a
digitally secure, transparent, and efficient infrastructure, which is crucial these days.

48
Chapter 10: User Manual
10.1 Introduction

The Blockchain-Based Document Verification System (BDVS) is a decentralized

application developed to address the challenges of document forgery, inefficient
verification, and centralized control. It is specifically designed for academic
institutions, government bodies, and legal agencies that frequently handle sensitive
documentation. The primary audience includes document issuers (like registrars),
verifiers (such as employers or academic institutions), and general users who require
real-time verification of document authenticity. The system combines Ethereum smart
contracts with IPFS storage and provides a user-friendly interface for secure,
transparent, and tamper-proof document handling.

10.2 Installation Guide

To install and deploy the BDVS application, certain prerequisites must be met. The
system requires a machine with a modern web browser (preferably Chrome or
Firefox), internet connectivity, and the MetaMask browser extension installed for
Ethereum wallet interactions.

On the development side, the software components must be set up as follows:

 Node.js and npm must be installed to manage frontend dependencies.

 Remix IDE is used for deploying smart contracts, which can be accessed online
without installation.
 IPFS client or Pinata service is required to handle file storage.

The frontend can be hosted locally or on a cloud platform by running the command
npm start in the project directory.

49
A valid testnet account (e.g., Goerli) and some test ETH are necessary to execute
contract transactions.

After fulfilling the above requirements, clone the frontend repository, install
dependencies with npm install, and launch the application with the appropriate
script. Ensure MetaMask is connected to the correct network and account before
proceeding.

10.3 Getting Started

Once the application is running, users must connect their MetaMask wallet to begin.
Upon login, the user is recognized either as a document issuer (Exporter) or a verifier
based on their wallet’s role, which is predefined in the smart contract.

For issuers, the “Upload Document” section allows the selection of a file, which is
then hashed locally. The document is uploaded to IPFS, and its CID along with the
hash is recorded on the Ethereum blockchain. A QR code is automatically generated,
linking to the document verification page.

For verifiers, the process involves scanning the QR code or manually entering the
hash to initiate verification. The system retrieves the document from IPFS, rehashes it
locally, and compares it with the on-chain hash. The result is immediately displayed
with a verification success or failure message.

10.4 Feature Walkthrough

Wallet Integration:
Upon visiting the site, users are prompted to connect their MetaMask wallet. Once
authenticated, the system checks the user's role for access rights.

Document Upload:

 Click on the "Upload Document" button.

 Select a valid file (PDF, JPG, PNG, DOCX formats supported).
 The system generates a hash using SHA-256 and uploads the file to IPFS.
 Metadata (hash, CID, title, timestamp) is sent to the blockchain.
50
 A QR code is displayed on successful upload.

QR Code Generation:

 Once the document is registered, a QR code is automatically generated using the

document’s verification link or hash.
 This code can be saved or printed for physical or digital distribution.

Document Verification:

 Open the verification interface.

 Scan the QR code or input the document hash manually.
 The system fetches the document from IPFS, recalculates its hash, and compares
it to the blockchain record.
 The result is displayed as “Document Verified” or “Verification Failed.”

Transaction Feedback:

 Users receive real-time messages such as “Uploading to IPFS…”, “Transaction

Submitted…”, or “Verification Successful.”
 Errors such as invalid file type or network issues are also displayed clearly.

Role-Based Access Control:

Only predefined wallets are allowed to upload documents.

All users can perform verification but cannot manipulate on-chain data.

Error Handling and Logging:

 In case of failure during upload or verification, users are informed through

structured messages.
 Logs are maintained for each interaction, which administrators can use for audits.

51
CHAPTER 11: SNAPSHOTS

52
53
Conclusion
The issues that involved document forgery, inefficiency in the manual checking of
documents, and the centralised method of record keeping which was lacking in trust
were solved by developing the Blockchain Based Document Verification System. The
project has adopted Blockchain Technology and IPFS along with Cryptographic
Hashing. These transformative technologies provided a solution to tamperless
forensic, transparent, and scalable verification of institutional and academic
documents.

In the course of the project, great efforts were put into understanding and
implementing smart contracts using Solidity to securely and unchangeably store the
hashes of the documents on the Ethereum Blockchain. The use of IPFS ensured that
the documents could not be stored on central servers and still ensured decentralised
file storage. Web3.js and MetaMask provided a secure and easy interface to document
issuers and verifiers through client side for them.

The system underwent rigorous unit, integration, system, and acceptance testing and
was proven to have very high accuracy and low latency under rigorous sustained
loading. Moreover, users confirmed the system’s efficient performance in real world
operational use, in particular rapid verification in the academic environment where
claim authentication is critical.

Challenges encountered during implementation, such as access control, mobile

usability, and IPFS reliability, were resolved with modular design and iterative
development, creating a scaffold for future refinement. In addition, the research and
study components involving decentralised infrastructures, logical structures for
cryptography, and secure web application development have further deepened the
project team’s technical and analytical skills.

In a nutshell, this project embodies a ready and propelling answer to an ever-present

institutional challenge. It not only meets immediate operational needs but also
demonstrates the impact blockchain technology could have in revolutionising
conventional processes. With advanced features like predictive analytics and the
integration of self-sovereign identities, the system has the potential to transform into a
globally accepted decentralised document verification platform.

54
REFRENCE

[1] Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.

[2] Wood, G. Ethereum: A Secure Decentralised Generalised Transaction Ledger.

Ethereum Foundation, 2014.

[3] Benet, J. IPFS - Content Addressed, Versioned, P2P File System. Protocol Labs,
2015.

[4] Buterin, V. A Next-Generation Smart Contract and Decentralized Application

Platform. 2014.

[5] Szabo, N. Formalizing and Securing Relationships on Public Networks. First

Monday, 1997.

[6] Tapscott, D., & Tapscott, A. Blockchain Revolution: How the Technology Behind
Bitcoin Is Changing Money, Business, and the World. Penguin, 2016.

[7] Christidis, K., & Devetsikiotis, M. Blockchains and Smart Contracts for the
Internet of Things. IEEE Access, 4, 2292–2303, 2016.

[8] Swan, M. Blockchain: Blueprint for a New Economy. O’Reilly Media, 2015.

[9] Mougayar, W. The Business Blockchain. Wiley, 2016.

[10] Zyskind, G., Nathan, O., & Pentland, A. Decentralizing Privacy: Using
Blockchain to Protect Personal Data. IEEE Security and Privacy Workshops, 2015.

[11] Crosby, M., Pattanayak, P., Verma, S., & Kalyanaraman, V. Blockchain
Technology: Beyond Bitcoin. Applied Innovation Review, 2, 6–10, 2016.

[12] Cachin, C. Architecture of the Hyperledger Blockchain Fabric. IBM Research,

2016.

[13] Kshetri, N. The Emerging Role of Big Data in Key Development Issues:
Opportunities, Challenges, and Concerns. Big Data for Development, 2017.

55
[14] Liang, X., Zhao, J., Shetty, S., & Li, D. Integrating Blockchain for Data Sharing
and Collaboration in Mobile Healthcare Applications. IEEE PIMRC, 2017.

[15] Al-Bassam, M. SCPKI: A Smart Contract-based PKI and Identity System. 2017.

[16] Zhang, Y., & Wen, J. An IoT Electric Business Model Based on the Protocol of
Bitcoin. ISCIT, 2017.

[17] Ali, M., Nelson, J., Shea, R., & Freedman, M. J. Blockstack: A Global Naming
and Storage System Secured by Blockchains. USENIX ATC, 2016.

[18] Karame, G. O., & Androulaki, E. Bitcoin and Blockchain Security. Artech
House, 2016.

[19] Yu, J., Wang, S., Kong, L., & Liu, X. Blockchain-Based Solutions to Security
and Privacy Issues in the Internet of Things. IEEE Wireless Communications, 2018.

[20] Gipp, B., Meuschke, N., & Gernandt, A. Decentralized Trusted Timestamping
Using the Crypto Currency Bitcoin. iConference, 2015.

[21] Singh, S., & Singh, N. Blockchain: Future of Financial and Cyber Security.
ICCCI, 2016.

[22] Li, X., Jiang, P., Chen, T., Luo, X., & Wen, Q. A Survey on the Security of
Blockchain Systems. Future Generation Computer Systems, 2018.

[23] Patel, K. Use of Blockchain in Education: A New Way to Verify Degree and
Certificates. IJARIIT, 2018.

[24] Sharples, M., & Domingue, J. The Blockchain and Kudos: A Distributed System
for Educational Record, Reputation and Reward. EC-TEL, 2016.

[25] Grech, A., & Camilleri, A. F. Blockchain in Education. JRC, European

Commission, 2017.

[26] UNESCO. Artificial Intelligence in Education: Challenges and Opportunities for

Sustainable Development. 2020.

56
[27] Deshmukh, S., & Kulkarni, R. Green Technologies and their Impact on
Education Infrastructure. International Journal of Applied Engineering Research,
2021.

[28] Kumar, R., & Verma, S. IoT and Energy Conservation in Smart Campuses.
Journal of Emerging Technologies in Computing Systems, 2022.

[29] Bureau of Energy Efficiency (India). Energy Conservation Building Code

Guidelines for Educational Institutions. 2021.

[30] Sahni, P., Mehra, R., & Rajput, A. Smart Classroom Systems Using Embedded
Technology. Journal of Intelligent Embedded Systems and Applications, 2022.

57