A Digital Identity Blockchain Ecosystem: Linking Government-Certified and Uncertified Tokenized Objects

Abstract

This paper presents a novel digital identity ecosystem built upon a hierarchical structure of Blockchain tokens, where both government-certified and uncertified tokens can coexist to represent various attributes of an individual’s identity. At the core of this system is the government, which functions as a trusted authority capable of creating entities and issuing a unique, non-replicable digital identity token for each one. Entities are the exclusive owners of their identity tokens and can attach additional tokens—such as those issued by the government, educational institutions, or financial entities—to form a verifiable, token-based digital identity tree. This model accommodates a flexible identity framework that enables decentralized yet accountable identity construction. Our contributions include the design of a digital identity system (supported by smart contracts) that enforces uniqueness through state-issued identity tokens while supporting user-driven identity formation. The model differentiates between user types and certifies tokens according to their source, enabling a scalable and extensible structure. We also analyze the economic, technical, and social feasibility of deploying this system, including a breakdown of transaction costs for key stakeholders such as governments, end-users, and institutions like universities. Considering the benefits of blockchain, implementing a digital identity ecosystem in this technology is economically viable for all involved stakeholders.

1. Introduction

In our digital world, where most things tend to be online and scams, frauds, and identity theft are rising, digital identity plays a crucial role in forming a digitized ecosystem. Digital identity has undoubtedly grown in importance internationally [1].

Digital identity information was commonly stored in traditional databases using encryption mechanisms to provide confidentiality and integrity, as well as replication processes to provide availability. Digital identity is the cornerstone of a digital economy [2]. So, the next evolution of digital identity involves storing digital identity information in a trusted Ledger Distributed Technology like blockchain. Blockchain is a technology that provides greater trust in the digital world [3]. As noted by Rathee et al. [4], blockchain technology can enhance security, privacy, and user control over personal data.

Blockchain technology offers some key advantages: (i) reduces the risk of failures; (ii) ensures transparency; (iii) offers immutability; (iv) reduces risks of fraud and tampering; and (v) provides traceability. Blockchain can provide a decentralized solution for managing sensitive personal information through programmable smart contracts. This technology permits, through smart contracts, the conversion of data into tokens. Tokens are intangible objects with public and private attributes. This is an important mechanism to provide confidentiality.

Various countries around the world are exploring blockchain technology for digital identity, for example, China [5,6], Germany [7,8], and the United States [9]. Furthermore, several works have focused on conveying the digital identity using blockchain [2,10,11,12,13,14]. However, we have identified the following limiting aspects: (a) Most of them are self-sovereign identity mechanisms, and the figure of a legal authority certifier like a government has seldom been explored. (b) Absence of mechanisms to link different entities: in a digital identity ecosystem, people’s digital identity must be interrelated with other entities (physical or virtual objects). For example, a person should usually be linked to different entities, such as a birth certificate, a passport, and a visa, as well as to physical things, like cars and houses. (c) Lack of transactional costs evaluation: it includes how much it would cost for governments and end-users to have a digital identity ecosystem.

This paper focuses on how to establish the relationship process between types of users and different entities. We propose the creation of a digital identity ecosystem, which is built by different tokens that can be regulated or not by a government. The government is a crucial actor that can create entities. For each entity created, the government generates a digital identity token, of which the entity is the owner. Each entity can link other tokens, which were previously certified or not by the government, into their digital identity token, thereby generating a digital tree of tokens.

The contributions of this research are abstracted as follows:

• We propose a digital identity ecosystem that accommodates both government-certified and uncertified tokens. The government can create different entities, each one with its own digital identity token. Each entity decides the tokens to link and form its identity through tokens.
• The creation of digital identity tokens avoids the duplicity characteristic. It means that the government can only create a digital identity token for each entity.
• We provide certainty about the transaction costs that the government, end-user, and an external entity (a University) would incur by having this ecosystem.
• We describe the feasibility of having a digital ecosystem from three perspectives: economic, technical, and social.

The paper is organized as follows: Section 2 cites and explains important works focused on the study of digital identity with solutions applying blockchain. Section 3 proposes our tokenized digital identity system, which is described more technically in Section 4 and Section 5. Section 6 describes our prototype, which explains how to link tokens certified or not by a government. In Section 7, we detail our proof of concept, emphasizing the proof in the transaction costs. Section 8 analyzes our proposal from three perspectives: economic feasibility, technical feasibility, and social feasibility. Finally, in the last section, we give our conclusions.

2. Background and Related Work

We begin by introducing key concepts of blockchain, smart contracts, and how these technologies pave the way for tokenization. We then highlight current trends in digital identity, concluding with an overview of how tokenization is applied in digital identity systems. Finally, we outline related works that intersect the digital identity challenge with the use of blockchain.

2.1. Blockchain Tokens

Blockchain, firstly introduced by Nakamoto [15], is a chain of blocks where each block keeps a list of transactions, and new blocks are added by consensus among different distributed nodes. The information can never be deleted or modified, only added [16]. Blockchain includes the following characteristics: decentralization, trustworthiness, collective maintenance, reliable database, openness, security, immutability, anonymity, programmability, verifiability, and traceability [17]. These features are reason enough to prefer blockchain implementation over traditional database solutions.

In general, there are two blockchain types: permissioned and non-permissioned [18]. Permissioned, also known as a private blockchain, only authorized and trusted entities can participate in the generation of blocks. Non-permissioned, also known as a public blockchain, allows public nodes to create, modify, and validate blocks; the stored information is transparent and accessible to everyone.

Although Bitcoin is widely recognized as the first blockchain implementation [15], other cryptocurrencies have emerged [19]. However, the idea of smart contracts, first introduced by Nick Szabo [20], was implemented with the introduction of the cryptocurrency Ethereum [21], which, together with Bitcoin, is the most successful cryptocurrency based on public blockchain.

Ethereum contains a virtual machine (EVM), which allows smart contracts to be programmed, deployed, and executed, enabling immutable computer logic. A smart contract is deployed through a transaction by spending a certain amount of Ether (the cryptocurrency in the Ethereum blockchain). Smart contracts have become one of the most sought-after technologies [22,23]. Transactions are one or more atomic operations executed by permissioned users.

Smart contracts have moved blockchain technology beyond the scope of cryptocurrencies and made them applicable to other sector applications such as digital identity, supply chain, healthcare, IoT, business process management, insurance, financial systems, etc. [24,25].

Non-fungible tokens (NFTs), or simply tokens, have become one of the more notable successes of blockchain applications [26]. NFTs are digital cryptographic assets stored in a blockchain. These assets are owned through smart contracts, which store a unique identifier and metadata that distinguish each asset from the others. Tokens represent something unique, ideal for representing digital identity.

Other technologies have emerged as alternatives inspired by the blockchain paradigm. One such example is IOTA [27], an open-source distributed ledger technology (DLT) designed to enable secure, scalable, and feeless data and value exchange—particularly suited for Internet of Things (IoT) applications. Unlike traditional blockchains, IOTA does not rely on blocks or miners; instead, it employs a novel architecture called the Tangle, which is based on a directed acyclic graph (DAG). Nevertheless, this work focuses on pure blockchain platforms, as they represent a more mature and widely adopted technology at present.

2.2. Digital Identity

A digital identity is a collection of data points that comprise the characteristics, attributes, and activities that identify an entity [28]. A digital identity is not always mandatory to be linked to a real-world identity [29]. For example, through authentication and authorization mechanisms, digital identity may be used to verify persons, organizations, applications, or devices to have access whenever they are authorized and to prevent unauthorized users from stealing or manipulating data.

An important relationship in digital identity is people’s digital identities and those entities linked to them. A person’s digital identity might be defined as the digital version or the information that can be used to identify a person’s identity, such as their complete name, email, date of birth, phone number, social media profiles, social security number, etc., but also secret credentials generally used to control access. A person’s digital identity is used to access Internet services such as financial bank information, medical records, emails, social networks, etc. Digital identity also involves replacing physical documents linked to a person, such as ID cards, driver’s licenses, etc.

The digitization of physical things is an unavoidable tendency because our lives move online. Linking physical things to digital identity is a strong requirement in the digital world to provide ownership. However, utilizing anonymity or pseudonyms (at least in social networks, the Metaverse, etc.) is highly attractive for users and hackers [30], who would prefer to conserve this anonymity. A way to preserve anonymity is to leave the end-user the freedom to decide which tokens to link.

2.3. Digital Identity Models with Blockchain

Lee [10] presented BIDaaS (Blockchain ID as a Service), a digital identity management infrastructure for mobile users on a private blockchain platform. BIDaaS involves three entities: a mobile user, a BIDaaS provider, and a partner. The user creates a credential (public and private key) and a virtual ID by using their mobile device. The credentials and the virtual ID are sent to the BIDaaS provider for registration. When a user wants to access a service offered by a partner, the user signs a message and includes their virtual ID. The partner carries out an authentication process with the BIDaaS provider using the virtual ID of the user and the signed message. This is an interesting solution, but it has disadvantages in various aspects: (a) omits information about how the BIDaaS provider is created; (b) types of users are not possible to be created; (c) BIDaaS provider is only used to validate the virtual ID; (d) any user can be registered without a government or a legal authority.

Sora [2] is a mobile app used to store ciphered personal information within a blockchain. It aims to be used as a remote self-sovereign identity mechanism. To demonstrate identity, a user partially signs their personal information, and the result is stored in the blockchain, which can be consulted or verified by an external entity. This system does not have a government entity able to certify the user creation, although it has the figure of a legal authority certifier.

Careja and Tapus [12] proposed a model for digital identity that uses blockchain technology to store attributes that define the identity of a subject. In this model, the user’s private key is the essential information linked to the identity, leaving it to be stored on any device outside the blockchain. The model is a mechanism in which a user can sign messages using a smart contract, resulting in an authenticity proof. The model can also validate if a specific subject signed an authenticated proof. The implementation was carried out on Ethereum and was accessed with Python programming, using the web3 library to access the smart contracts developed with Solidity. That solution does not provide the existence of an entity created by a government, as we have proposed. The paper mentions that trusted authorities are responsible for creating and authenticating digital identities. However, the paper does not explicitly explain how trusted institutions (such as governments) are created or designated. Instead, it expects that trusted authorities are already predefined.

Kamboj et al. [11] presented a role-based access control model to provide a mechanism to manage user–role assignments. To do that, they developed two smart contracts on the Ethereum blockchain. The first is to issue or revoke the user’s roles and permissions, and the second is to grant or deny access based on the user’s roles.

These mentioned works collectively underscore the growing importance of digital identity in today’s digital society. In particular, Rathee et al. [4] provide a comprehensive review of existing literature, identifying current trends, challenges, and future directions in the field of identity management (IdM). Their study emphasizes the integration of blockchain technology with IdM systems, recognizing its potential to enhance security, privacy, and user control over personal data. The authors conclude that blockchain can overcome many limitations of conventional IdM frameworks. Nonetheless, they highlight several persistent challenges—including scalability, interoperability, transaction costs, data protection, authentication, data storage and replication, and the lack of skilled professionals—that must be addressed for broader adoption. Complementing this view, Ahmed et al. [31] stress that blockchain-based identity systems, especially self-sovereign identity (SSI) models, present a promising shift from traditional centralized approaches. These systems promote decentralized trust, enhance user autonomy, and mitigate the risks associated with single points of failure. However, the field remains in a state of active development, requiring further research into robust architectures, cross-platform interoperability, and advanced security mechanisms to ensure sustainable and scalable identity solutions.

2.4. Digital Identity Systems Using Blockchain

Due to the importance of having a digital identity ecosystem, some initiatives have arisen.

Dentity [13] acquired Trinsic’s Decentralized Id Platform to expand Web3 digital identity adoption. The idea of Dentity is leveraging blockchain’s decentralized and secure infrastructure to empower users with greater control to manage their digital identities securely.

Privado.iD [14] (formerly Polygon ID) merged with Disco to create a unified identity infrastructure bridging Web2 and Web3 ecosystems. This merger seeks to facilitate seamless digital identity management across multiple blockchain networks and traditional systems, enhancing verification processes and user control over personal data.

Several countries are exploring blockchain technology for digital identity systems. India has explored integrating its Aadhaar digital identity system with blockchain to decentralize identity verification and enhance transparency, particularly in use cases such as banking, healthcare, and voting [32]. The United States and members of the European Union have promoted decentralized identity systems using blockchain to reduce reliance on centralized identity providers and enhance privacy. These systems often emphasize self-managed identities and interoperability between national and cross-border services [9]. China RealDID [5,6], a national decentralized identifier system, began trials in Hong Kong. This initiative allows Chinese citizens to verify their identities across borders while maintaining anonymity, particularly when purchasing regulated financial products without a physical ID presentation. In Germany, the European Self-Sovereign Identity Framework (ESSIF) is being developed, which utilizes decentralized identifiers (DIDs) [7] and the European Blockchain Services Infrastructure (EBSI) to explore decentralized digital identity solutions [8].

3. The Digital Identity Model

A person’s identity is typically certified by governments through official documents, such as birth certificates, driver’s licenses, passports, and visas. Currently, a person’s digital identity might be scattered on the Internet from reliable cloud services (offered by the government) and those created by self (for example, social networks, email, etc.). The latter might cause a lack of certainty about a person’s identity, especially if a person could impersonate another.

Unlike self-sovereign identity models, we are interested in trusted certifier identity systems within a blockchain ecosystem, and particularly, the government figure as a trusted entity. To do that, it is mandatory to establish a mechanism to create the first user, which we will call the government.

Figure 1 illustrates our digital identity model in Business Process Model and Notation (BPMN). The figure includes three general roles: government, blockchain, and entities. First, the government is established, and then it has the ability to add entities and issue digital identity tokens upon request. These tokens are used to link other tokens that belong to each entity. All critical data and logic are stored through smart contracts in the blockchain that receive requests and are processed according to them. The rest of this section explains the processes of the government’s creation and linking of tokenized objects in a high-level explanation. At any moment, you can relate each explanation with Figure 1 to follow the general flow.

3.1. Government Creation and the Generation of Digital Identities

In our model, the election of the first user is decisive; therefore, we have denominated it the critical user. Figure 2 illustrates this step. As shown at the beginning of the UML Sequential Diagram in the figure, the government is created with the public key address g of the critical user by executing the constructor mechanism ($constructor\left(g\right)$). At the top of the figure, you can also see $Users\left(\right)$ and $digitalIdentity\left(\right)$ mechanisms, which will be smart contracts later. Then, the critical user, now being the government, might register entities (by sending the instruction $\{register,user,u\}$). While registering a new entity, $Users\left(\right)$ sends the instruction $\{create,digitalIdentity,u\}$ to $digitalIdentity\left(\right)$ to create a digital identity token for user u. Then, the successful answer is returned to each sender.

3.2. Linking Tokenized Objects

Linking physical things (e.g., cars, jewelry, and goods) to a person is part of the eagerness required to build an ecosystem of digital identities. With this, we could provide a model where all identities are connected. However, some physical things could change ownership, whereas others do not. For example, a birth certificate is linked to a user and is not transferable; the same applies to a diploma awarded to one user and generated by a university. There exist standards for creating NFTs to be unique and indivisible, e.g., ERC-721 [33] and ERC-1155 [34]. The reason we do not adopt the ERC-721 standard is that it inherently supports token transferability between users or contracts. However, in our identity model, certain digital assets (such as birth certificates or university diplomas) are strictly bound to the original user and are, by design, non-transferable. Assigning these assets as transferable would contradict their inherent immutability and ownership constraints in the real world. On the other hand, although ERC-1155 offers a flexible framework for handling both fungible and non-fungible tokens, it still assumes that tokens are transferable by default. In our identity model, certain tokens (such as birth certificates or academic diplomas) must remain permanently associated with a single user and cannot be transferred. Therefore, adopting ERC-1155 without modification would contradict the immutability and ownership restrictions required for these identity-bound assets.

We propose creating a system to link tokenized objects into a tokenized digital identity, certified or uncertified by a government. When receiving the linkToken instruction—within the blockchain role in Figure 1—it is verified whether a token can be added or not and if it is certified or uncertified.

Figure 3, in general, illustrates the process of tokenizing objects. The figure consists of two parts: the real world and the digital world. You can think of it as entities of the real world executing remote functions in the cloud.

The figure shows, in general, various abstract mechanisms. For example, for the arrow with a circled 1, the government has tokenized three entities: an end-user, a car agency, and a university. Tokens in the figure are illustrated with an abbreviation address within a rectangle. The government could also create other types of tokens, such as birth certificates (circled 2). Other types of entities (after having been created by the government) could make their own tokenized assets (circled 3), for example, tokenizing physical cars by a car agency or tokenizing diplomas by universities. Note that, in the figure, we distinguish some tokens with an insignia, meaning that such tokens were certified by the government.

A token must hold an owner attribute to know who it belongs to. However, when an entity creates tokens, they are scattered on the blockchain, and a special kind of wallet is required to link them. Therefore, in our model, there exists a step where each entity links one or more of their external tokens into their digital identity token through an established protocol. The protocol validates whether the owner of the external token corresponds to the same owner of the digital identity token. The circled 4 in the figure illustrates the digital identity token of the entity ($0x1AF...101$) already linked with the other tokens.

More technical details will be tackled in the following sections.

4. Digital Identity Creation Through User Mechanisms

Starting with a user system is a solid foundation for creating a digital identity. It must contemplate various mechanisms such as account creation, registration, authentication, user profiles, and user access control, among others. Blockchain lets users own their identity credentials, storing them in a wallet or application. These credentials enable users to work across different platforms. Our user system contemplates various mechanisms, such as registration and consultation of user profiles, which might be used later for authentication issues. This section comprises a description of the user and digital identity models.

4.1. The Users Token Model

Figure 4 shows a use case model of this mechanism. We have set numbered circles and numbered squares to explain the following steps:

➀:

The first user is critical to trust completely in the system, whom we have labeled as a Crucial user, becoming the government (in ) through the creation of a smart contract using the constructor method. Therefore, this step is crucial for the system’s security.

➁:

Once the government has been created, any user might consult the general information of any digital identity token, whenever the public key address is known.

➂:

In this step, the government, through a registerUser(⋯) method, can register types of users. In the figure, the government creates User1 (in ) and another government (in , in this case $Government2$). While registering users, the government creates digital identity tokens for each user, $createDigitalIdentity\left(\right)$. Blockchain enables users to own their identity credentials; therefore, the method $registerUser\left(\right)$ does not store private keys, only public.

➃:

The created $Government2$ might, in turn, create other users. In this case, it creates a university (in ) and a new User2 (in ).

➄:

Once the government has created users, any user might consult public information of any other registered user whenever it knows the registered user’s public address.

4.2. Digital Identity Token Model

We explained in the previous section that while a government registers a user, it also creates their digital identity token. In this section, we explain the details of the digital identity model.

Figure 5 illustrates the use case diagram of the digital identity smart contract. The figure has four actors: the government, the UsersContract, $User1$, and Anyone. In addition, you can see circled numbers and a squared letter, which will be used to reference the following steps:

⓪:

The government,

➀:

through UsersContracts, creates a digital identity token and assigns (the owner’s role to the user (in this case, $User1$). It is carried out by executing the constructor.

➁:

$User1$, being the owner, might add external tokens using $linkToken\left(addr\right)$ function, $addr$ is the address of the external token.

➂:

The owner can also consult their private and public attributes and all linked tokens.

➃:

Finally, any user, knowing any user’s public address ($addr$), might consult particular information, for example: the number of linked tokens, the name of a particular token, the creator of a particular token, or to know if a particular token was created by a government or not.

5. External Tokens

The previous section described that the function $linkToken\left(addr\right)$ was used by each user to add external tokens. This section provides two examples: (a) creating tokens certified by the government; and (b) those tokens created by other users outside of the government.

5.1. Birth Certificate Token Model

To illustrate how different tokens can be linked to a digital identity, we have created a Birth Certificate model. It is the primary information commonly used to identify individuals, such as full name, date of birth, and place of birth, among others.

Figure 6 illustrates the use case diagram of BirthCertificate. The figure has three actors: the government, the owner, and anyone.

➀:

The government first creates the token.

➁:

Once the token has been created, the following actors exist:

• Anyone might consult public information of any user as long as they know the user’s address.
• Owner can consult their private and public information.
• Government may associate the user with parental addresses by executing functions $setFatherAddress\left(address\right)$ and $setMotherAddress\left(address\right)$. In addition, the government can consult the private attributes of the user.

5.2. Scholar Curriculum Token Model

This example illustrates a scenario where a different government user has generated an external token, even though it can be linked to the digital identity.

The scholar curriculum represents the students’ academic accomplishments, certified by a university. It has personal attributes imported from the birth certificate token and a mechanism to store achievements by the university’s authority.

Figure 7 illustrates the use case diagram of smart contract ScholarCurriculum. The figure has three actors: the university, owner, and anyone.

➀:

The university first creates the token. To create it, the token imports the address of the smart contract BirthCertificate (bCert) and a student’s identifier (id). From the smart contract BirthCertificate private (personal) and public information of the student is obtained.

➁:

Once the token has been created, the university can add the student’s achievements, including their detail data.

➂:

Owner or anyone might consult information:

• Owner might consult their private information, achievements, and other public information.
• Anyone might know public information of any particular token as long as they know the user’s address.

6. Digital Identity Prototyping

This section begins by detailing the technical aspects of our prototype implementation. It then presents a step-by-step execution involving different types of users. For example, we describe how the government is created and how it, in turn, creates two entities: an end-user and a university. The government issues a birth certificate token, while the university generates another token, both of which are associated with a specific end-user. Then, we demonstrate how the end-user links these tokens to form a token tree. The prototype is intended to illustrate the feasibility of our architecture and its potential for replication or adaptation. Finally, we explain how our model promotes confidence and compatibility between public and private identification systems by implementing granular access control within the smart contract layer.

6.1. Smart Contract Implementation

We implemented the design described in the previous sections in Solidity Language Programming version 0.8.23. To consult more details about Solidity Language Programming, refer to [35].

Table 1. Match between the use cases model and the smart contracts’ implementation in [36].

Use Case Figure	Smart Contract in [36]	Smart Contract	Interface
Right dotted rectangle in Figure 4	UsersInterface.sol		Yes
Left dotted rectangle in Figure 4	OwnerInterface.sol		Yes
Figure 4	Users.sol	Yes
Figure 5	DigitalIdentity.sol	Yes
Figure 6	BirthCertificate.sol	Yes
Figure 7	ScholarCurriculum.sol	Yes

shows the relation between the use cases previously described with the implementation of the smart contracts (which can be found in [36]).

Figure 8 illustrates the class diagram of the digital identity ecosystem implemented in [36], and Figure 9 illustrates the class diagram of two external tokens that will be linked into the digital identity ecosystem. The figures use a notation similar to that employed for classes in the object-oriented paradigm [37], since Solidity language programming is based on this paradigm. Each smart contract has a constructor function used to create the contract and might include parameters. The smart contract is illustrated as a rectangle divided into three parts: the name at the top, attributes in the middle, and methods below. Attributes and methods include (among others): private (−), public (+), and abstract (a). Private methods can only be called within the contract; public methods are accessible within and from other contracts. Abstract methods are template methods that are not implemented in the contract. If a smart contract includes at least one abstract method, it is also considered abstract and can only be deployed when abstract methods are implemented. When all methods are abstract, the contract is called an interface. Figure 8 and Figure 9 show two interfaces (OwnerInterface and UsersInterface), and their implementation can be seen in the figures with dotted arrows.

The figure also illustrates the dependency relationship between contracts using the use-arrow, as seen in both figures.

Although the implementation details of the smart contracts can be found in [36], we will emphasize the technical description of the linkToken mechanism, since this encompasses an important part of our digital identity tree construction.

6.2. Linking Tokens

Listing  is a fragment (function) of smart contract DigitalIdentity. Function linkToken takes one parameter, contractAdd, which is the address of the token contract to be linked. To link a token, this function executes a series of validations in lines 2, 4 to 6 (using statement require), and 9 to 11 (a traditional conditional statement). Statement require has two parameters, the first checks if a condition is held, then passes it to the following line instruction; if not, it reverts with the error message established in the second parameter and the function is not executed. Line 2 checks if the executor (msg.sender) is the owner of the DigitalIdentity contract. If not, it reverts with the error message “Incorrect owner”. This verification is carried out internally within the blockchain (or corresponding wallet) using the owner’s private key, as the executor (using its public key) sends the transaction. Line 4 checks if the executor is also the owner of the contract to be linked (to do this, in line 3, an instance of the OwnerInterface for the contract at address contractAdd is created). If not, it reverts with the error message “Incorrect owner of contract address”. Line 5 checks an assignation of government address. If not, it reverts with the error message “Not government”. Line 6 checks if the token at address contractAdd is not already linked. If it is already linked, it reverts with the error message “Token already exists”. Lines 7 to 11: this block checks if the government address exists in the UsersInterface contract. If it exists, it sets gcert to true if it is a government and the token is certified. Otherwise, gcert is set to false, meaning that the linked token is uncertified. Lines 12 to 13 store the linked token information in the linkedTokens mapping. Finally, line 14 adds the token address contractAdd to the addressesTokens array, which keeps track of all linked token addresses.

Listing 1: linkToken function of DigitalIdentity Smart Contract coded in Solidity Programming Language.

6.3. Execution Example

Table 2. Entities, their addresses, and abbreviations.

Entity	Entity Abbreviation	Address Abbreviation	Address
Crucial user	$C_u$	0x2CF…341	0x2CFcBB9Cf2910fBa7E7E7a8092aa1a40BC5BA341
Government	$G_1$	0x2CF…341	0x2CFcBB9Cf2910fBa7E7E7a8092aa1a40BC5BA341
Government2	$G_2$	0xeBa7…317	0xeBa76CCB873f7d78B5007ad89b64a11cCfBb7317
User1	$U_1$	0x32d…4a83	0x32d680Aa90D45B677BBa0fFE9Af3d3578dcB4a83
User2	$U_2$	0x207…94b	0x207Ee448397059BA705629674b2F8c9Df1CA594b
University1	$U{n}_1$	0x295…57D	0x295865c0e1BfE88A898068aab9608f8277BF257D
Anyone	A	0x1B4…236	0x1B46a9Af29aa1C4b493E55A8aa2c03FAf54b7236

shows an example of various entities together with their addresses and their abbreviations. These abbreviations can be related to those shown in Figure 4 and will be used in our later explanation.

Figure 10 illustrates an example of the digital identity system executed by five entities: The government, $User1$, $User2$, $University1$, and $University2$. The figure shows blue dotted rectangles, indicating four grouped instances of smart contracts (from left to right): ScholarCurriculum, BirthCertificate, users, and $DigitalIdentity$.

These instances resemble object models in UML (Unified Modeling Language), and we have included boxes to denote transactions. The arrows with numbered circles denote operations on the smart contracts; they will be used to pinpoint our explanation. Two circles with the same number but different letters (e.g., 3a and 3b) indicate that they may be executed in parallel, and the letter will be used to identify the operation. The explanation is as follows:

➀:

The first step in our digital identity ecosystem is to create the government. So, a crucial user (with address $0x2CF\dots 341$) becomes the government by creating an instance of the smart contract users. The result of that operation generates the smart contract address $0x1AF\dots 101$.

After step 1, the government can create different types of users. In particular, from the figure we have the following:

• and : The government registers two users ($0x32d\dots 4a83$ and $0x207\dots 94b$) $User1$ and $User2$.
• and : While registering the users, the $government$ creates their instances of the smart contract $DigitalIdentity$. The resulting smart contract addresses of those operations were $0x1BF\dots 201$ and $0x1BF\dots 202$, respectively. The owners of such instances are $user1$ and $user2$, respectively.

The government could create new tokens such as BirthCertificate, Passport, Driver’s license, etc. Then, users could link their external tokens to their digital identity token. We exemplify it, with the creation of a BirthCertificate:

• and : The government creates two instances of smart contract BirthCertificate. The resulting smart contract addresses of those operations were $0x1CF\dots 301$ and $0x1CF\dots 302$, respectively. The owners of such instances are $User1$ and $User2$, respectively. The information stored in such instances can be seen in the figure.
• and : $User1$ and $User2$ link their BirthCertificate tokens into their DigitalIdentity token.

As you can see, until now, the smart contracts were created by the government, but sometimes other entities could create tokens, and these tokens could be added to the digital identity of the users. The following is an example of this:

• and : Two external entities, so-called $University1$ and $University2$ ($0x295\dots 57D$ and $0x508\dots 85c$ respectively), create two instances of smart contract ScholarCurriculum. The smart contracts’ addresses of those operations are $0x1CF\dots 401$ and $0x1CF\dots 402$, respectively. The owners of such instances are $User1$ and $User2$, respectively. Although the government does not create these tokens, they could be created by reliable entities such as universities.
• and : $User1$ and $User2$ can link their ScholarCurriculum into their $DigitalIdentity$ token. With these operations, each user can add a token not necessarily certified by the government.

Table 3. Smart contracts created by users.

Steps	User	Smart Contract Address	Address Abbreviation	Description
1	$C_u$	0x1AF…101	$S{C}_u$	$C_u$ creates smart contract User $S{C}_u$
3a	$G_1$	0x1BF…201	$S{C}_{di1}$	$G_1$ creates Digital Identity $S{C}_{di1}$
3b	$G_1$	0x1BF…202	$S{C}_{di2}$	$G_1$ creates Digital Identity $S{C}_{di2}$
4a	$G_1$	0x1CF…301	$S{C}_{bc1}$	$G_1$ creates Birth Certificate $S{C}_{bc1}$
4b	$G_1$	0x1CF…302	$S{C}_{bc2}$	$G_1$ creates Birth Certificate $S{C}_{bc2}$
6a	$U{n}_1$	0x295…57D	$S{C}_{sc1}$	$U{n}_1$ creates Scholar CV $S{C}_{sc1}$
6b	$U{n}_2$	0x508…85c	$S{C}_{sc2}$	$U{n}_2$ creates Scholar CV $S{C}_{sc2}$

shows a list of the smart contracts previously created. The Steps column provides the circled steps previously explained; User denotes who has created the smart contract; Smart Contract Address is the address generated when the smart contract was created, the next column is its abbreviation; and the last column is a description.

6.4. Granular Access Control

Our model promotes confidence and compatibility between public and private identification systems by implementing granular access control and modular certification logic directly within the smart contract layer. We achieve this through the following:

• Access modifiers and visibility scopes: we use Solidity’s public, private, and internal visibility keywords along with modifier functions to control access to identity attributes and operations. For example, sensitive data (e.g., government-issued digital identity tokens) is only accessible through authorized roles (government or the owner), while public attributes (e.g., owner, type, nameToken) are openly accessible for verification (consulting). This supports both transparency for public systems and privacy guarantees for private or user-controlled data.
• Differentiation between certified and uncertified tokens: Our model explicitly supports both government-certified tokens (e.g., birth certificates) and uncertified tokens (e.g., university scholar curricula). This design ensures interoperability with both centralized identity providers and self-sovereign identity systems.
• Auditable smart contracts: the logic is modular and auditable, meaning any verifying party can programmatically check whether a token is certified, by whom, and under what conditions. This promotes trust and verifiability across jurisdictions and use cases.

7. Proof of Concept

This section presents the transaction costs associated with each operation described in the previous section. Additionally, we propose several cost estimation scenarios. For instance, we estimate the total cost (in ETH and USD) of migrating digital identities and issuing birth certificates for an entire population, using Mexico’s population as an example. Another scenario estimates the cost for a university to issue certificates for its student body, using the Panamerican University (Guadalajara Campus) as a case study. Finally, we evaluate the cost incurred by an individual user when linking all of their associated tokens.

7.1. Transaction Costs

Table 4. Transaction costs of smart contract users.

Executor	Operation’s Type	Method or Attribute	Transaction Cost
			User	Contract
$C_u$	Deploying	Constructor ()	2,801,010
$G_1$	Setter	registerUser ($U_1$,0)	1,404,589
$*U_1$	Getter	getCreator ($U_1$)		3206
$*U_1$	Getter	getDigIdentityAdd ($U_1$)		2963
$*U_1$	Getter	getType ($U_1$)		5168
$*U_1$	Getter	government		2531
$*U_1$	Getter	nameToken		3479
$*U_1$	Getter	owner		2508
$*U_1$	Getter	userExists ($U_1$)		2924

shows the transaction costs spent after deployment and after executing some methods. In the table, the Executor column pinpoints who has executed the transaction (a user account or a contract address); Operation type shows the type of transaction (a deployment, setter, or getter); Method or attribute shows the attribute name or method being executed; finally, the last two columns show the Transaction cost (User or Contract); User presents the cost when it is executed by a user account address and Contract shows the cost when an attribute or method is executed by another smart contract.

The transaction costs of Table 4, Table 5, Table 6 and Table 7 were executed using a blockchain based on the Ethereum Network. The equivalent currency used on the Ethereum network is: 1 ether (ETH), which equals $1\times {10}^{18}$ Wei. Wei is the smallest denomination of ether (ETH). The transaction costs were generated using the Remix Integrated Development Environment (IDE). The formula of the transaction cost is:

$$TransactionCost=gasUsed\times gasPrice$$

$gasUsed$ is the amount of computational effort required to process a transaction; in our calculus, the $gasPrice$ was 1. The $gasPrice$ is

$$gasPrice=baseFee+priorityFee$$

$baseFee$ is the minimum network fee, and $priorityFee$ is an optional extra fee used to prioritize a transaction. In our case, $baseFee$ was equal to 1, and $priorityFee$ was 0.

Some executor cells in Table 4, Table 5, Table 6 and Table 7 are marked by an asterisk, meaning that the cost only applies when called by a contract.

Table 5. Transaction costs of smart contract digital identity.

Executor	Operation’s Type	Method or Attribute	Transaction Cost
			User	Contract
$S{C}_u$	Deploying	Constructor ($U_1$,$S{C}_u$,$G_1$)		1,203,000
$*U_1$	Getter	government		2531
$*U_1$	Getter	nameToken		3479
$*U_1$	Getter	numberOfLinkedTokens		2484
$*U_1$	Getter	owner		2527
$U_1$	Setter	linkToken ($S{C}_{sc1}$)	148,575
$*U_1$	Getter	creatorIsGovernment ($S{C}_{sc1}$)		8402
$*U_1$	Getter	getCreatorOfToken ($S{C}_{sc1}$)		8423
$*U_1$	Getter	getNameToken ($S{C}_{sc1}$)		8672

Table 5. Transaction costs of smart contract digital identity.

Executor	Operation’s Type	Method or Attribute	Transaction Cost
			User	Contract
$S{C}_u$	Deploying	Constructor ($U_1$,$S{C}_u$,$G_1$)		1,203,000
$*U_1$	Getter	government		2531
$*U_1$	Getter	nameToken		3479
$*U_1$	Getter	numberOfLinkedTokens		2484
$*U_1$	Getter	owner		2527
$U_1$	Setter	linkToken ($S{C}_{sc1}$)	148,575
$*U_1$	Getter	creatorIsGovernment ($S{C}_{sc1}$)		8402
$*U_1$	Getter	getCreatorOfToken ($S{C}_{sc1}$)		8423
$*U_1$	Getter	getNameToken ($S{C}_{sc1}$)		8672

Data d1 was used to deploy the smart contract BirthCertificate:

Table 6. Transaction costs of smart contract BirthCertificate.

Executor	Operation’s Type	Method or Attribute	Transaction Cost
			User	Contract
$G_1$	Deploying	Constructor ($d_1$)	1,524,535
$G_1$	Setter	setFatherAddress ($U_2$)	63,320
$G_1$	Setter	setMotherAddress ($U_3$)	63,298
$*G_1$	Getter	dateCreation		2492
$*G_1$	Getter	dateLastUpdate		2536
$*G_1$	Getter	fLastName		3501
$*G_1$	Getter	gender		2488
$*G_1$	Getter	getDay		15,290
$*G_1$	Getter	getMonth		15,242
$*G_1$	Getter	getYear		15,332
$*G_1$	Getter	getMunicipalty		16,162
$*G_1$	Getter	getState		16,207
$*G_1$	Getter	government		2553
$*G_1$	Getter	mLastName		3479
$*G_1$	Getter	name		3435
$*G_1$	Getter	nameToken		3501
$*G_1$	Getter	owner		2596
$*G_1$	Getter	tokenFather		2554
$*G_1$	Getter	tokenMother		2531

Table 6. Transaction costs of smart contract BirthCertificate.

Executor	Operation’s Type	Method or Attribute	Transaction Cost
			User	Contract
$G_1$	Deploying	Constructor ($d_1$)	1,524,535
$G_1$	Setter	setFatherAddress ($U_2$)	63,320
$G_1$	Setter	setMotherAddress ($U_3$)	63,298
$*G_1$	Getter	dateCreation		2492
$*G_1$	Getter	dateLastUpdate		2536
$*G_1$	Getter	fLastName		3501
$*G_1$	Getter	gender		2488
$*G_1$	Getter	getDay		15,290
$*G_1$	Getter	getMonth		15,242
$*G_1$	Getter	getYear		15,332
$*G_1$	Getter	getMunicipalty		16,162
$*G_1$	Getter	getState		16,207
$*G_1$	Getter	government		2553
$*G_1$	Getter	mLastName		3479
$*G_1$	Getter	name		3435
$*G_1$	Getter	nameToken		3501
$*G_1$	Getter	owner		2596
$*G_1$	Getter	tokenFather		2554
$*G_1$	Getter	tokenMother		2531

Data $a1$ was used to add a student’s achievement, as illustrated in Table 7:

Table 7. Transaction costs of smart contract scholar curriculum.

Executor	Operation’s Type	Method or Attribute	Transaction Cost
			User	Contract
$U{n}_1$	Deploying	Constructor ($S{C}_{bc1}$ ${,}^{\prime }{0220530}^{\prime }$)	1,356,594
$U{n}_1$	Setter	addAchievement ($a1$)	186,837
$*U{n}_1$	Getter	dateCreation		2470
$*U{n}_1$	Getter	dateLastUpdate		2514
$*U{n}_1$	Getter	fLastName		3479
$*U{n}_1$	Getter	fLastName		3523
$*U{n}_1$	Getter	name		3413
$*U{n}_1$	Getter	nameToken		3435
$*U{n}_1$	Getter	owner		2574
$*U{n}_1$	Getter	studentId		2491
$*U{n}_1$	Getter	gender		2511
$*U{n}_1$	Getter	getAchievement (1)		19,668
$*U{n}_1$	Getter	government		2531
$*U{n}_1$	Getter	government		2531
$*U{n}_1$	Getter	numberOfAchievements ()		2476

Table 7. Transaction costs of smart contract scholar curriculum.

Executor	Operation’s Type	Method or Attribute	Transaction Cost
			User	Contract
$U{n}_1$	Deploying	Constructor ($S{C}_{bc1}$ ${,}^{\prime }{0220530}^{\prime }$)	1,356,594
$U{n}_1$	Setter	addAchievement ($a1$)	186,837
$*U{n}_1$	Getter	dateCreation		2470
$*U{n}_1$	Getter	dateLastUpdate		2514
$*U{n}_1$	Getter	fLastName		3479
$*U{n}_1$	Getter	fLastName		3523
$*U{n}_1$	Getter	name		3413
$*U{n}_1$	Getter	nameToken		3435
$*U{n}_1$	Getter	owner		2574
$*U{n}_1$	Getter	studentId		2491
$*U{n}_1$	Getter	gender		2511
$*U{n}_1$	Getter	getAchievement (1)		19,668
$*U{n}_1$	Getter	government		2531
$*U{n}_1$	Getter	government		2531
$*U{n}_1$	Getter	numberOfAchievements ()		2476

7.2. Transaction Costs Deploying Digital Identity Ecosystem

This section shows the transaction costs generated to deploy users and digital identity in a country ecosystem. Then, we exemplify it considering the Mexican inhabitants.

Let,

$$T{\$}_U=2801010\mathit{Weis}$$

be the gas generated by executing the $Constructor\left(\right)$ of smart contract users (first row in Table 4), and let:

$$T{\$}_{RU}=1404589\mathit{Weis}$$

be the gas generated by registering a new user into smart contract users and creating a $DigitalIdentity$ instance (second row in Table 4).

The formula for the gas for registering all inhabitants I of a country $T{\$}_C$ would be:

$$T{\$}_C=T{\$}_U+\sum _{i=1}^I{\left(T{\$}_{RU}\right)}_i$$

Let I be the number of Mexican inhabitants, being 131,822,858 million [38]. The gas generated to add other users will be similar to $T{\$}_{RU}$ because the parameter values are very similar and they did not represent any considerable coefficient of variation, according to our proof (less 0.19%). Thereby, we will assume $T{\$}_{RU}$ as the average gas cost for each Mexican inhabitant. Considering the previous assumption, we have the following calculation:

$$T{\$}_C=2801010\mathit{Weis}+\sum _{i=1}^{131822858}{\left(1404589\mathit{Weis}\right)}_i$$

$$T{\$}_C=2801010+185156936295362$$

$$T{\$}_C=185156939096372$$

equal to 0.000185157 ETH. Taking into account that 1 ETH equals 2477.41 USD (Exchange rate calculated at https://www.coinbase.com/converter/eth/usd on 20 May 2025), the amount $T{\$}_C$ would be 0.46 USD.

7.3. Transaction Costs to Deploy BirthCertificate

This section outlines the transaction costs incurred to deploy BirthCertificate within a country ecosystem; then, we add these to the previous transaction costs generated for deploying the digital identity ecosystem. We exemplify it considering the Mexican inhabitants.

Let,

$$T{\$}_{BC}=(1524535+63320+63298)=1651153\mathit{Weis}$$

be the gas generated by executing the $Constructor\left(\right)$ of smart contract BirthCertificate and setting the set father and mother address of a user (first, second, and third rows of Table 6). Although $d1$ is a particular example, and it has repercussions in $T{\$}_{BC}$, we will use such a value as the average for all users of a country. The formula to calculate the gas for generating all birth certificates in a country would be:

$$T{\$}_{BCs}=T{\$}_C+\sum _{i=1}^I{\left(T{\$}_{BC}\right)}_i$$

Considering the previous formula, we have the following calculation for a scenario in Mexico:

$$T{\$}_C=185156939096372Weis+\sum _{i=1}^{131822858}{\left(1651153Weis\right)}_i$$

$$T{\$}_C=185156939096372Weis+217659707455274Weis$$

$$T{\$}_C=402816643750636.00Weis$$

$$T{\$}_C=0.000402817Ethers$$

Taking into account that 1 ETH equals 2477.41 USD (Exchange rate calculated at https://www.coinbase.com/converter/eth/usd on 20 May 2025.), it generates:

$$T{\$}_C=0.99USD$$

7.4. Transaction Costs to Deploy ScholarCurriculum

This section shows the transaction costs generated to deploy ScholarCurriculum for a university ecosystem. Then, we exemplify it with the number of students in Universidad Panamericana Campus, Guadalajara.

Let,

$$T{\$}_{SCc}=1356594\mathit{Weis}$$

be the gas generated by executing the $Constructor\left(\right)$ of smart contract ScholarCurriculum (first row of Table 7). Although the data that was built $T{\$}_{SCc}$ represents a particular example, and it has repercussions in the cost, we will use such a value as the average for the creation of all students.

Consider that a university adds an achievement for each subject that a student has taken. Let,

$$T{\$}_{Ach}=186837\mathit{Weis}$$

be the gas generated by adding a simple achievement in smart contract ScholarCurriculum (second row of Table 7). There, although the data $a1$ represents a particular example, we will use such a value as the average for the creation of all achievements.

The following formula represents the gas cost for generating a student’s academic record for each student:

$$T{\$}_{SCi}=\sum _{i=1}^S{\left(T{\$}_{Ach}\right)}_i$$

where S denotes the number of subjects in a bachelor’s curriculum. Although some students may deserve additional achievements, we will consider, for now, the minimum student’s achievements.

Finally, the transaction costs to have all scholars’ curriculum in a university ecosystem will be represented by the following formula:

$$T{\$}_{SC}=T{\$}_{SCc}+\sum _{j=1}^N{\left(T{\$}_{SCi}\right)}_j$$

where N denotes the number of students registered in a university. Broken down, the formula is:

$$T{\$}_{SC}=T{\$}_{SCc}+\sum _{j=1}^N{\left(\sum _{i=1}^S{\left(T{\$}_{Ach}\right)}_i\right)}_j$$

Considering the previous formula, we will generate the following calculation for a scenario at Universidad Panamericana Campus, Guadalajara (UP-Gdl), where $N=4300students$. In addition, considering that the number of subjects in a Bachelor curriculum typically varies by country, in the case of UP-Gdl, which usually takes about 7 subjects per semester, with 10 semesters, it results in $S=70subjects$. So, replacing the variables:

$$T{\$}_{SC}=1356594Weis+\sum _{j=1}^{4300}{\left(\sum _{i=1}^{70}{\left(T{\$}_{186837Weis}\right)}_i\right)}_j$$

$$T{\$}_{SC}=1356594Weis+\sum _{j=1}^{4300}{13078590Weis}_j$$

$$T{\$}_{SC}=1356594Weis+56237937000Weis$$

$$T{\$}_{SC}=56239293594Weis$$

$$T{\$}_{SC}=0.00000005623929359400Ethers$$

Taking into account that 1 ETH equals 2477.41 USD (Exchange rate calculated at https://www.coinbase.com/converter/eth/usd on 20 May 2025.), it generates:

$$T{\$}_{SC}=0.00013932778834271200USD$$

7.5. Transaction Costs to Link Tokens

Once a smart contract $DigitalIdentity$ was created, a user might link their own tokens. These tokens are all digital documents $DDs$ converted to tokens, for example, BirthCertificate and ScholarCurriculum in this paper, but could be others (e.g., passport, driver’s permit, etc.), which might be created by the government (e.g., BirthCertificate) or by other users (Universities for the case of ScholarCurriculum). The procedure to link tokens uses the method $linkToken\left(\right)$ within the smart contract $DigitalIdentity$. Let $T{\$}_{Linktoken}$ be the gas required to link a token, then the following calculates all tokens $DDs$ for a specific user:

$$T{\$}_{LinkT}=\sum _{i=1}^{DDs}{\left(T{\$}_{Linktoken}\right)}_i$$

Considering $T{\$}_{Linktoken}=148575Weis$ obtained from the sixth row of Table 5 and assuming $DDs=10$ (We assume $DDs=10$ only to have heuristic calculus, but we have considered that a person could have the following digital documents: birth certificate, CURP, passport, driver permission, at least three scholar certificate -elementary, middle, high,- tax identity, id identity, certificate of ownership -car, house,- among others.), and considering that $T{\$}_{Linktoken}$ remains constant:

$$T{\$}_{LinkT}=\sum _{i=1}^{10}{\left(148575Weis\right)}_i$$

$$T{\$}_{LinkT}=1485750Weis$$

$$T{\$}_{LinkT}=0.00000000368081190750USD$$

8. Analysis

This section analyzes the feasibility of implementing a blockchain-based digital identity ecosystem from three perspectives: economic, technical, and social. We conclude this section by providing a comparison with other closely related works and our contributions.

8.1. Economic Feasibility

Analyzing the economic feasibility of developing a decentralized application (DApp) means considering the cost involved in its cycle development process, and considering off-chain and blockchain parts. However, in this section, we will delimit our study on the cost involved in setting it up in the blockchain and the entities that would have to pay to make this proposal a reality. The fundamental entities are the government and the end-user. However, we also analyze the university user because it is part of the entities in our example.

Table 8. Costs generated in Wei and USD by deploying a digital identity ecosystem and payers.

Variable	Description (Gas Generated to)	Transaction Cost		Payer
		Wei	USD
$T{\$}_C$	Know the gas for registering all inhabitants of a country; example with 131,822,858 inhabitants.	185,156,939,096,372	0.46	Government
$T{\$}_{BCs}$	Create all birth certificates in a country; example with 131,822,858 inhabitants and including $T{\$}_C$.	402,816,643,750,636	0.99	Government
$T{\$}_{SCi}$	Create a scholar curriculum; example of a student having completed 70 subjects.	13,078,590	0.000000032	University
$T{\$}_{SC}$	Gas required for 4300 students; example in UP-Gdl.	56,239,293,594	0.0001393278	University
$T{\$}_{Linktoken}$	Gas required to link a token by a user; example linking its scholar.	148,575	0.0000000001	End-user
$T{\$}_{LinkT}$	Curriculum; gas required to link all tokens by a user; example linking 10 tokens.	1,485,750	0.0000000037	End-user

summarizes some general transaction costs generated in Section 7. The table has five columns, the first one denotes different variables explained in Section 7, and the next column gives a brief description. The third and fourth columns denote the transaction cost in Wei and USD, respectively, and the last column indicates who should pay. The first row represents the expenses that a government would have to pay out to generate all digital identity tokens in a country like Mexico, with 131,822,858 inhabitants. The second row represents the previous expenses plus the cost of generating the birth certificates for all Mexican inhabitants. The third row denotes an approximated expense that a university would have to pay out for each student having finished all subject credits, and the fourth row is an approximated expense for having all the scholars’ curriculum in a university (e.g., 4300 students in UP-Gdl). The fifth row denotes an approximated expense that an end-user would have to pay out for linking a token, and the sixth row represents the expenses generated for linking 10 tokens, which means for an end-user having their complete identity in a blockchain platform.

According to Table 8 and considering the benefits of blockchain, we can conclude that having a digital identity ecosystem on a blockchain platform is not expensive for either entity. However, it is important to note that we assumed a gas price unit of 1 in our calculation. In reality, ETH gas prices fluctuate significantly depending on network congestion, which was not taken into account in this analysis. For example, Koutmos [39] showed a time series evolution of ETH gas prices (expressed as natural log of Wei) for a period between September 2015 and May 2023, oscillating between  22 and  27. It clearly shows that considering real peak fees could reach higher costs per transaction. However, Solana and Cardano could maintain fees much lower than ETH’s gas costs [40,41]

8.2. Technical Feasibility

Our proof of concept has been deployed using Remix-ETH IDE. Remix IDE is an open-source web-based Integrated Development Environment (IDE) primarily used for developing and deploying smart contracts on the Ethereum blockchain. Remix supports solidity, the primary programming language for ETH smart contracts, and facilitates various stages of the development process, including writing, compiling, testing, and deploying smart contracts.

However, deploying a DApp in a real blockchain (e.g., ETH mainnet, testnets, or sidechains like Polygon, among others) introduces significant technical feasibility challenges that we have not considered, but developers working in the off-chain part should do it:

• Latency: Ethereum no longer uses a proof of work (PoW) mining mechanism; instead, it now uses proof of stake (PoS). Therefore, there is no mining time in the traditional sense. It means Ethereum no longer has a traditional mining process where miners compete to solve complex puzzles. In the case of our experiments with Remix, it executes near-instant blocks; however, Ethereum currently takes approximately 12.12 s [42]. Something to consider in the logic is to assume fast feedback or instant confirmations that will not hold in a production environment.
• Disconnections: Although public blockchain networks are highly reliable, the off-chain code must take into account availability troubles.
• Upgradability: our design does not contemplate any proxy pattern for contract upgrades. It means that if our smart contracts are deployed, they cannot be reset as easily as modifying them using Remix.
• Large storage: In our examples, such as BirthCertificate and ScholarCurriculum, we only considered plain text stored directly in smart contracts. However, blockchain was not designed for storing large documents or binary data (e.g., scanned PDFs). To address this limitation, off-chain storage using the InterPlanetary File System (IPFS) could be employed in future token designs that require larger data capacity [43,44]. In such cases, only the IPFS content hash would be stored on-chain, ensuring data integrity while maintaining cost efficiency.

8.3. Social Feasibility

We analyze the social feasibility of developing a DApp-based digital identity system created and certified by a government and with token issuance by governments, universities, or other entities. Social feasibility will evaluate whether people and institutions will accept, trust, and use the system, considering their incentives, concerns, and societal norms.

• End-Users: They could feel motivated to control their digital identity with official tokens that represent part of their identity. Considering the reliability of blockchain, users could trust that tokens represent them. The token works like a digital wallet card; it proves who you are and what you own. End-users could easily carry and manage their identity (e.g., implemented in a mobile device) without needing to understand the underlying technology (assuming easy interaction). Each piece of a person’s identity (e.g., birth certificate, diplomas, etc) would be represented as a separate token, making the digital identity easy to extend. In addition, anyone can verify the authenticity of a token without needing to contact the issuer directly. However, it also represents some challenges. Many people are not comfortable with managing wallets, keys, or tokens. In contrast, these challenges can be mitigated with good software practices, such as abstracting the complexity of wallet management (e.g., keys or token addresses) and providing recovery mechanisms for the keys. They would have to learn to store their keys, because losing them could cause a loss of identity or impersonation. Perhaps the primary challenge is convincing the end-user to pay for the service.
• Government: Adopting blockchain technology in the implementation of a digital identity ecosystem, the government could typically provide innovation, greater trust, security, transparency, etc. However, some challenges consist of migrating from traditional technologies to DApp, initial investment, and having gas to execute transactions (even if it is a little). Create legal standards for digital token identity, such as the interfaces we have proposed.
• External entities: They could be motivated because of credentials, degrees verification could become frictionless and instant, and could be globally trusted; it could be harder to forge digital, signed tokens. Insurance companies could be very interested in using digital identity to form a trusted electronic medical record. Vendors could be interested in generating ownership invoices in the form of tokens to avoid fraud. Some challenges to consider in this kind of DApps are that external entities must hire specialists to implement the standards we are proposing, investment to install this new technology, and paying to execute transactions.

8.4. Comparison and Contribution

Table 9. A comparison of digital identity models using blockchain with our proposal. Symbols used: yes (✓), no (✗), and partially (✾).

Works	Reg. in BC	Auth	User Types	Self Sovereign	Authority Certifier	SC	Pluggable	Costs	BC Platform
Lee [10]	✓	✓	✗	✓	✗	✗	✗	✗	Not mentioned
Careja and Tapus [12]	✓	✓	✗	✓	✓	✓	✗	✗	Ethereum
Kamboj et al. [11]	✓	✓	✗	✗	✗	✓	✗	✗	Ethereum
Takemiyaa et al. [2]	✓	✓	✗	✓	✓	✗	✾	✗	Hyperledger Iroha
This research	✓	✓	✓	✗	✓	✓	✓	✓	Ethereum

provides a comparative overview of previous digital identity models based on blockchain technology described in Section 2.3; and the last row represents this research. Each row corresponds to a cited work, and the table is structured across ten columns. The presence or absence of specific features in each work is denoted using the following symbols: yes (✓), no (✗), and partially (✾). The first column lists the referenced works. The second column (Reg. in BC) indicates whether the model includes user registration directly on the blockchain. The third column (Auth) specifies if the approach is designed as an authentication mechanism. The fourth column (User types) denotes whether the system supports differentiated user roles or types. The fifth column (Self-sovereign) assesses whether the model follows a self-sovereign identity (SSI) paradigm, granting users full control over their identity data. The sixth column (Authority certifier) indicates the presence of a legal or trusted authority acting as an identity certifier. The seventh column (SC) identifies whether the work provides implementation details or logic related to smart contracts. The eighth column (Pluggable) shows if the identity architecture is modular or supports integration and substitution of identity components (i.e., is pluggable). The ninth column (Costs) denotes whether the model provides transaction costs. Finally, the tenth column (BC Platform) specifies the blockchain platform utilized in each respective work.

9. Conclusions

This work introduces a decentralized digital identity ecosystem built on a token-based architecture that empowers both governments and individuals in identity creation and management. By allowing identity trees composed of both certified and uncertified tokens, the model supports user autonomy while ensuring baseline trust through state-issued digital identity tokens. The constraint of one identity token per user mitigates duplication risks, reinforcing the reliability of the system. The model is composed of two interfaces (OwnerInterface and UsersInterface) and two smart contracts (Users and $DigitalIdentity$) that inherit from the interfaces. The interfaces serve as standards that must be implemented if new tokens are to be created; in this paper, we illustrate two examples: one certified by a government, called BirthCertificate, and the other not certified by the government but by a university, called ScholarCurriculum. Both interfaces and smart contracts were coded in Solidity programming language.

Our economic analysis shows that the implementation costs—only smart contract deploying and transactions—for each stakeholder (government, end-users, and third parties like universities) are within feasible limits, with an estimated transaction costs of less than 1 USD for the government (in an example of 131,822,858 inhabitants, a country like Mexico); approximately $1.39\times {10}^{-4}$ USD for a university with 4300 students; and approximately $1\times {10}^{-10}$ USD for an end-user for having its management. Technically, the system demonstrates scalability and interoperability through the ability to add tokens using the $linkToken\left(\right)$ method in the smart contract $DigitalIdentity$; however, off-chain challenges must be considered within the DApp application process, such as latency, disconnections, and upgradability. Socially, Stakeholders may be motivated to participate and may place trust in the system, but they could request legal standards when developing digital data of tokens, for example, to consider the General Data Protection Regulation (GDPR) [45]. This ecosystem presents a promising pathway for decentralized digital identity infrastructure that remains grounded in public trust and regulatory oversight.

10. Future Work

To guide future research, we outline potential directions to extend this work. As a next step, we are developing a microservice-based architecture that integrates off-chain components with on-chain smart contracts using Web3 technologies. This framework will enable us to assess the system’s performance under various conditions, with a particular focus on transaction latency, scalability, and responsiveness in high-load scenarios.

On the other hand, our model is currently designed to link tokens with fixed ownership; it can not unlink expired tokens (e.g., expired diplomas or diplomas revocation). A valuable extension would be to enable dynamic linking and automatic unlinking of tokens when ownership changes or tokens lose validity.

Furthermore, it would be valuable to benchmark the transaction costs presented in this study against those observed on public blockchain networks, particularly Ethereum, which has consistently demonstrated higher transaction fees due to its auction-based fee model and limited throughput. In contrast, alternative platforms such as Solana and Cardano offer significantly lower and more predictable transaction costs, owing to their distinct consensus mechanisms and scalability-focused architectures.