Transparency of Donations with Blockchain: Traceability Prototype

Calebe Ocanha Isacc Birer; Luciano Bérgamo

DOI: 10.22167/2675-6528-202602767

Article derived from a Final Course Work (TCC), with content based on the student’s original work and adapted to the editorial format of the E&S Magazine with the support of the ResumeAI tool, an artificial intelligence solution developed by Instituto Pecege for textual synthesis and organization.

Summary

The opacity in financial flows and the need for auditable mechanisms for donation management motivated the development of this study. The effectiveness of blockchain technology and smart contracts in promoting the transparency and integrity of digital records was investigated. The objective was the development and validation of a functional traceability prototype operated on a distributed network. The adopted methodology is applied in nature and experimental in character. It was structured in stages of bibliographic review, code implementation in Solidity language, and operational tests on a public test network (Sepolia) via the Metamask digital wallet interface. The results evidenced the technical viability of the solution, validating the role-based access control and the logical conformity of the approval quorum. The analysis of performance metrics indicated the predictability of computational costs (gas) and the efficiency of the Ethereum Virtual Machine in processing immutable governance rules. It was verified that the emission of on-chain events allowed for the integral reconstruction of the decision-making flow, guaranteeing the permanent auditability of the system. It was demonstrated that the substitution of institutional trust with cryptographic proofs materialized financial disintermediation, providing an effective tool for decentralized governance and total resource visibility.

Keywords: Disintermediation; Ethereum; Digital governance; Data integrity; Cryptographic proof.

1. Introduction

The opacity in financial flows, particularly in donation management, represents a persistent challenge that compromises trust and transparency. The need for auditable mechanisms to ensure the integrity of resources and correct accountability has driven the search for innovative solutions. In this scenario, digital transformation has intensified the adoption of systems that promise greater clarity and reliability in transactions.

Blockchain technology, in its essence, constitutes a digital ledger shared and distributed among multiple computers, ensuring that each participant maintains an identical copy of the transaction history. Information is grouped into blocks, each containing a cryptographic summary of the previous block, which ensures the immutability and temporal integrity of the data (Haber; Stornetta, 1991; Bayer; Haber; Stornetta, 1993; Merkle, 1988). This decentralized model reduces reliance on intermediaries, simplifying verification and fraud detection. The initial proposal for blockchain emerged with Nakamoto (2008) in the context of Bitcoin, popularizing the concept of a public, auditable, and immutable ledger.

Complementarily, the concept of smart contracts, introduced by Nick Szabo (1997), refers to automatic mechanisms that simulate the logic of traditional contracts digitally. Through code, obligations and rules can be autonomously fulfilled, eliminating the need for total trust between parties. The Ethereum platform, created by Buterin (2013), expanded the use of this technology beyond simple financial transactions, allowing the creation of general-purpose smart contracts and the execution of immutable governance rules (Antonopoulos; Wood, 2018).

Despite theoretical advances and diverse applications of blockchain, its practical use to ensure traceability and transparency in donations remains limited. Most studies focus on conceptual, economic, or security aspects, without presenting concrete evidence of its functionality in operational prototypes. This gap prevents the real demonstration of the integrity and auditability benefits that the technology can offer. The opacity in traditional financial flows and the reliance on manual accountability processes in the third sector generate information asymmetry and distrust between donors and philanthropic institutions, highlighting the need to convert complex governance rules into secure and immutable computational algorithms.

Given this scenario, the present research is justified for two main reasons. From an academic point of view, there is a lack of detailed studies explaining implementation decisions, result validation, and blockchain-based traceability solutions, which hinders replication and comparison between approaches. In the practical sphere, organizations need auditable and decentralized mechanisms to increase trust and reduce information asymmetry. By developing and evaluating a functional prototype, this study offers concrete evidence of feasibility, cost, and performance, contributing to the strengthening of both theory and conscious adoption of this technology.

The motivation for this design arises from the observation of latent professional and market demands in the management of third-sector resources. Thus, the general objective of this study consists of developing and validating a functional traceability prototype for the flow of digital donations using blockchain technology and smart contracts. The research proposes to design a governance logic based on multiple signatures and achievement of minimum quorum, validating the integrity of operations and analyzing the technical feasibility of the solution through quantitative metrics of computational consumption in an experimental distributed network environment.

2. Material and Methods

The developed research has an applied nature and experimental character, seeking to create, test, and evaluate a functional traceability prototype. This approach was selected to prove the technical and operational viability of the proposed model, allowing verification of the tool’s potential in ensuring greater transparency and trust in digital records. The methodological choice valued the development of technological solutions based on solid theoretical knowledge.

The study was structured in five sequential stages. Initially, a bibliographic survey was conducted to understand the theoretical concepts of blockchain, smart contracts, traceability, and digital transparency. Next, the development environment was defined, specifying the languages and tools to be used in the prototype implementation.

The third stage consisted of the prototype modeling and implementation, which involved the creation of smart contracts and the tracking interface. Subsequently, in the fourth stage, simulation with fictitious data was carried out on a test network, recording transactions for tracking. Finally, the fifth stage comprised the collection and analysis of results, evaluating the system’s performance and reliability.

The development environment used the Solidity language for the creation of smart contracts and the Remix IDE as a compilation and deployment platform. Transactions were carried out on Ethereum test networks, such as Sepolia Testnet or Ganache, accessed through the MetaMask digital wallet. This environment allowed simulating the functioning of a real public network without exposing sensitive data.

The verification of records and transactions was conducted through block explorers, such as Etherscan, ensuring that all operations could be tracked and audited. This technical approach guaranteed the observation of the prototype’s behavior in a distributed environment, replicating the conditions of an operational blockchain network.

Regarding ethical and legal aspects, the research did not employ personal, sensitive, or identifiable data. All information entered into the prototype was fictitious and generic, ensuring no link to real individuals or institutions. Therefore, it was not necessary to submit the project to a Research Ethics Committee (CEP/CONEP), and the study aligned with institutional guidelines and the General Data Protection Law.

The analysis of the results was carried out through technical metrics, which allowed evaluating the efficiency and viability of the prototype. The average transaction confirmation time, the estimated cost of transactions, the traceability reliability, and the ease of auditing were considered, the latter evaluated by the clarity and accessibility of the recorded data.

The prototype was designed to demonstrate the traceability and governance of the digital transaction flow, recording all steps of the decision-making process. This included from the creation of a transaction request to its eventual execution, aiming to ensure transparency and the possibility of a complete system audit.

After the deployment of the smart contract in a testing environment, it began to act as the logical repository of control. Subsequently, transaction requests were created, containing essential information such as destination address, value, and description of purpose. Each request remained registered in the contract until it was evaluated by authorized participants, according to predefined rules.

The prototype’s traceability was ensured by the use of events emitted by the contract during its execution. Whenever a request was created, approved, or executed, an event was recorded, allowing these actions to be tracked by any interested party through network auditing tools.

These events functioned as a detailed history of the system’s behavior, enabling the reconstruction of the decision flow and the verification of transaction compliance with established rules. Thus, the prototype ensured transparency at the technical level, allowing for a complete audit of the digital process, even without identifying real-world users.

The “createOrder” function was used to register new transaction requests in the contract, defining parameters such as destination address, nominal value, and description. The “approveOrder” function was executed by different authorized addresses to register the necessary digital signatures. This procedure was crucial for reaching the minimum approval quorum.

After the minimum quorum of approval was reached, the transaction could be executed through the “executeOrder” function. This function processed the financial settlement and updated the contract balance on the test network, transferring the resources to the destination address. The emission of the final “OrderExecuted” event consolidated the system’s transparency.

The prototype’s transparency and audit mechanism allowed direct access to the contract’s internal records. The “getPedido” function, defined with the “view” modifier in the Solidity language, ensured public, immutable, and free consultation of the data stored in the ledger, without the need for intermediaries.

3. Results and Discussion

The research results evidenced the technical viability of the traceability prototype for digital donations, based on blockchain technology and smart contracts. The development and validation of the system demonstrated the capacity to record and audit transactions in a distributed environment, promoting data transparency and integrity. The initial implementation of the code in Solidity language, along with the conceptual validation of the contract execution flow on the Remix IDE platform, established the foundation for operational tests. It was observed that the adequate configuration of the test environment, including the availability of balance on test networks, was crucial for the precise simulation of transactions and the validation of the proposed use cases.

The critical analysis of the development revealed a significant technical trade-off between logical validation in local simulators and deployment on external test networks, such as Sepolia. While the local Remix IDE environment offered speed and agile debugging, the transition to the public test network exposed the prototype to real conditions of block propagation latency and synchronization between distributed nodes, as theorized by Buterin (2013). This practical experience confirmed that validation in an external emulated environment is essential to prove the resilience and readiness of the code in a distributed production scenario, overcoming the limitations of purely syntactic tests.

Operational challenges were identified during the experimental phase, mainly the dependence on third-party infrastructures for maintaining the test pipeline. Obtaining fictitious currency through “faucets” to execute write functions on the Sepolia network frequently faced instability and quota limitations, impacting the testing cadence. Furthermore, the test network itself experienced congestion peaks or forks, slowing down transaction confirmation times. These factors highlight that the development of decentralized solutions requires rigorous resource planning, as external infrastructure variables can escape the developer’s direct control, as pointed out by Antonopoulos and Wood (2018).

Another critical aspect of scalability was the volatility and unpredictability of network fees, known as “gas”. Although the amount of gas units consumed by each prototype function proved to be deterministic and predictable, the actual financial cost on the Ethereum mainnet fluctuates dynamically with global demand for block space (Antonopoulos; Wood, 2018). Writing new persistent memory states (SSTORE) is charged with high costs to discourage inefficient data storage. Computational optimization based on “hot slots” resulted in a 31% saving on the second approval of a request, demonstrating a technical mitigation effort, but without eliminating the economic risk of network fee variations.

To enable large-scale practical applicability, the observed economic limitations suggest a transition to second-layer networks (Layer 2) or sidechains. These structures process transactions off the main chain before consolidating the aggregated security data “on-chain”, reducing execution fees and increasing the scalability of the collective governance system, without compromising data immutability (Nakamoto, 2008). Additionally, the individual custody of private keys associated with digital wallets, such as MetaMask, represents a human and operational challenge, transferring security responsibility to the institution’s managers. Operational errors, such as key loss, can result in irreversible loss of resources, reinforcing the need for governance and personnel training programs.

The prototype was designed to demonstrate the traceability and governance of the digital transaction flow, recording all decision-making steps, from the creation of a request to its execution. After deploying the smart contract in a testing environment, it was possible to create transaction requests with essential information such as destination address, value, and description of purpose. Each request remained registered in the contract until evaluated by authorized participants, following predefined rules. Reaching a minimum number of approvals, established by the “quorum”, allowed for the autonomous execution of the transaction, ensuring the transparency and auditability of the process.

The prototype’s traceability was primarily ensured by the emission of events by the contract during its execution. Each time a request was created, approved, or executed, an event was recorded, allowing these actions to be tracked by any interested party through network auditing tools. These events served as a detailed history of the system’s behavior, enabling the reconstruction of the decision-making flow and verification of transaction compliance with established rules. Thus, the prototype ensured transparency at the technical level, allowing for a complete audit of the digital process, even without identifying real-world users.

The technical validation of the source code was an essential step. The compilation process of the smart contract in the Remix IDE development environment demonstrated that the logical structure was syntactically valid for execution in version 0.8.20 of the compiler. The confirmation of success, verified by a visual success indicator, ensured that the code was ready to be processed by the Ethereum Virtual Machine (EVM). This technical validation materializes the concepts of Szabo (1997), who defines smart contracts as automatic mechanisms to simulate traditional contracts, and Buterin (2013), who points to correct compilation as a guarantee that the contract acts as an immutable and auditable logical repository, fundamental for transparency.

The deployment of the smart contract in a testing environment, as illustrated in the original thesis, demonstrated that the contract was duly instantiated and became an element available for interaction through function calls. The left sidebar of the Remix IDE interface displayed structured fields for each function, allowing command execution and data reading directly on the simulated network. This instantiation step is fundamental for the materialization of the solution, as, upon deployment on the EVM, the code becomes an immutable and auditable logical repository. The transition from static code to an “on-chain” executing contract reflects the breakdown of the centralized trust model, enabling “trustless” systems, where the validity of operations is guaranteed by the network’s cryptographic verification, not by intermediaries (Nakamoto, 2008).

The `createOrder` function was responsible for registering new transaction requests in the contract. During its execution, parameters such as destination address, nominal value, and a detailed description were defined, allowing for structured storage of information for auditing. The confirmation of the operation was observed in the side management panel and in the IDE’s output terminal, which reported the function’s positive return and the emission of the corresponding event. The logical implementation of the `createOrder` function used the `onlyOwner` modifier to ensure that only authorized addresses could register new demands, and `require` commands acted as barrier clauses, preventing the processing of invalid data, such as null addresses or zero values.

The `pedidos.push` instruction ensured the immutable persistence of data on the blockchain, while the final `emit PedidoCriado` command materialized the traceability requirement. This line was fundamental because, as discussed by Nakamoto (2008), transparency in distributed systems depends on the publicity of records. By integrating this governance rule directly into the code, the prototype embodied Szabo’s (1997) vision of contractual automation, reducing information asymmetry between donors and the organization through permanent and auditable digital records.

The operationalization of distributed governance was detailed by the `approveRequest` function, which implements the multi-signature (multisig) logic, ensuring that resource movement depends on the consensus among authorized participants. The `require` command acted as a security lock, preventing an non-existent request from being accessed or a participant from voting twice on the same record. The final `emit RequestApproved` line ensured transparency, announcing to the network that the governance rule had been met. This multiple approval mechanism is based on the principles of consensus and decentralized security proposed by Nakamoto (2008), where the validity of an operation depends on the agreement of a majority, protecting the system against arbitrary decisions. The use of consensus allows for the creation of “trustless” systems, where trust resides in the objective verification of code rules (Kuiper & Hogan, 2023).

The computational efficiency of the quorum mechanism was analyzed, showing a significant reduction in resource consumption between the first and second approval of the same request. The implemented governance logic benefited from the optimization of Ethereum Virtual Machine states, with a reduction of approximately 31% in execution cost. This reduction stemmed from the manipulation of already initialized state variables (hot slots), a technical incentive for ledger efficiency, where the initial data write (SSTORE) is intentionally more costly to ensure network sustainability (Antonopoulos; Wood, 2018). This metric validates the prototype’s scalability, proving that multi-signature systems can operate with cost predictability (Badev & Chen, 2014).

The prototype’s transparency and auditing mechanism was demonstrated by direct access to the internal contract records via the `getPedido` function. This function, defined with the `view` modifier, allowed public, immutable, and free consultation of the data stored on the ledger, including destination address, amount, description, number of approvals, and execution status. Information persistence occurred in a structured manner, allowing verification of the current state of any request, including the accumulated approval quorum. The `require` command functioned as an integrity check, and the use of the term `storage` indicated that the data was retrieved directly from the blockchain’s permanent memory, ensuring the fidelity of the recorded history.

The query functionality is based on the public and chronological nature of the blockchain, described by Nakamoto (2008) as a distributed ledger where each transaction is audibly documented by all participants. The public availability of these records is the central element that allows any agent to verify the consistency of operations without resorting to a central authority or intermediary (Badev & Chen, 2014). By allowing donors and auditors to perform the read function for free and immutably “on-chain”, the solution materialized the concepts of total visibility and digital integrity, essential for preventing fraud in donation flows.

The financial settlement stage and contract status update were detailed by the execution of the `executarPedido` function, performed exclusively after validating the minimum quorum of authorized signatures. The transaction was processed successfully, according to the programmed governance rules. The real-time update of the smart contract’s financial balance, with the reduction of the Ethereum balance, constituted empirical proof of resource outflow to the destination address after the transfer function call in the code. This automated and conditional execution reflects the fundamentals described by Antonopoulos and Wood (2018), where smart contracts act as autonomous agents that ensure the fulfillment of complex business rules without manual intervention or financial intermediaries.

By integrating quorum logic directly into the Ethereum Virtual Machine, the prototype ensured the integrity of the decision-making process, materializing the decentralized security model proposed by Nakamoto (2008), where the validity of an operation depends on objective protocol verification. The immutability and transparency generated by this transaction underpin the “trust revolution” (Tapscott & Tapscott, 2016), allowing each step of the donation flow to be publicly auditable and immune to retroactive changes. The full visibility of the ledger enables real-time traceability, solving the problem of opacity in financial flows (Laurence, 2019). The consolidation of this record on the blockchain transforms auditing into a native platform process.

The implementation of the `executarPedido` function in Solidity language consolidated the closing of the governance flow, allowing the effective transfer of resources only after rigorous validation of all security premises established in the protocol. The analysis of the function indicated that the automated and conditional execution reflected the foundations of autonomy discussed by Antonopoulos and Wood (2018). The `require(!p.executado)` command functioned as a security lock, preventing operational errors or duplicate payment attempts. The line `p.aprovacoes >= quorumMinimo` materialized the decentralized security model proposed by Nakamoto (2008), ensuring that the validity of the operation depended on the objective verification of the protocol and not on the arbitrariness of a single administrator.

The transfer made via the `call` command resulted in the immediate update of the contract balance on the test network, providing empirical proof of resource outflow. The emission of the final `PedidoExecutado` event consolidated the system’s transparency, allowing donors and auditors to track settlement in real-time, thus resolving the financial opacity issue identified in this research. Although the prototype uses the scenario of a fictitious NGO, the technical structure of multisig and governance is fully adaptable for use by individuals or collectives, ensuring that any financial transaction history is transparent to all parties involved.

The computational resource consumption metrics observed during the prototype’s operational tests were detailed, expressed in units of “gas”. The deployment of the contract (“Constructor”) presented the highest transaction cost, with 1,582,730 gas, and execution cost, with 1,406,910 gas, resulting in an estimated cost of 0.00158273 fictitious ETH. The `createOrder` function consumed 123,507 transaction gas and 101,407 execution gas, with an estimated cost of 0.00012351 fictitious ETH. For the first order approval, the transaction cost was 75,734 gas and execution cost was 54,542 gas, totaling 0.00007573 fictitious ETH. The second order approval demonstrated greater efficiency, with 58,634 transaction gas and 37,442 execution gas, resulting in 0.00005863 fictitious ETH.

The execution of the order (`executarPedido`) had a transaction cost of 66,411 gas and an execution cost of 45,219 gas, with an estimated cost of 0.00006641 fictitious ETH. Query functions, such as `getPedido`, `ehAprovador`, and `totalPedidos`, did not incur fees when executed externally and for free on the network, showing execution costs of 15,047, 2,899, and 2,506 gas, respectively, and being exempt from fictitious ETH cost. This distinction between write and query functions underpins the system’s transparency, allowing public auditing without transaction costs for the external observer (Badev & Chen, 2014).

The deployment of the contract is the most costly operation, justified by the storage of logic and governance rules directly on the network. According to Antonopoulos and Wood (2018), gas cost is a network protection mechanism against infinite loops and inefficient use of the Ethereum Virtual Machine, where write operations (SSTORE) have high fees to ensure the sustainability of the decentralized ledger. The second approval of a request resulted in a lower cost (58,634 gas) compared to the first (73,734 gas), evidencing the EVM’s efficiency in handling already initialized state variables (“hot” memory slots), which favors the scalability of collective governance in the prototype. Assigning a physical value to each contract action materializes the concept of “checks and balances” (Fidelity Digital Assets, 2023; Kuiper & Hogan, 2023), discouraging malicious use and ensuring that only transactions legitimately approved by the quorum are processed.

The logical architecture of the prototype was founded on four operational pillars: balance custody and control via contract, creation of transaction requests with essential metadata, decentralized registration of approvals by authorized addresses, and final execution conditioned on reaching a minimum quorum. This configuration materializes the logic of a multi-signature (multisig) contract, indicating that the system’s governance resides not in a central authority, but in the programmatic verification of consensus rules pre-established in the code. This structural design aligns with the concepts of Szabo (1997) and Nakamoto (2008), who proposed the autonomous execution of contractual rules and payment systems based on cryptographic proof, respectively. The separation between the creation of the request and its execution functions as a “checks and balances” mechanism, essential for integrity in decentralized systems (Fidelity Digital Assets, 2023).

Preliminary evidence and validations performed registered success in compiling the code in the Remix IDE environment, validation of the logical structure of functions, and the execution of basic functional tests, including reading state variables and returning calls that do not require balance consumption (“gasless calls”). These initial procedures ensured that the syntax and internal logic of the contract comply with the standards of the Solidity language in version 0.8.20. The validation of these read and write functions is fundamental to confirm the contract’s readiness to be processed by the Ethereum Virtual Machine (EVM). As pointed out by Buterin (2013), the transition from static code to a functional smart contract transforms software into an immutable and auditable logical repository within the network. The stability demonstrated in variable reading tests reinforces the reliability of “on-chain” data persistence, a central element for guaranteeing the temporal integrity of donation records (Haber & Stornetta, 1991).

The analytical confrontation between the prototype’s functionalities and the theoretical framework demonstrated the validation of fundamental concepts. The prototype implemented “trustless” systems through code execution without the need for a central administrator, aligning with Kuiper and Hogan (2023). Immutability was guaranteed by permanent and irreversible records on the Sepolia network, according to Nakamoto (2008). Digital transparency was materialized by public and free auditing via the `getPedido` function, corroborating Badev and Chen (2014). Contractual automation was evidenced by the automatic transfer trigger after reaching quorum, following Szabo (1997). Finally, state efficiency was proven by the reduction of gas costs in already initialized variables, as per Buterin (2013).

The presented correlation indicates that the prototype not only executes computational commands but also materializes the governance rules proposed by Szabo (1997) and Nakamoto (2008). The ability to audit the approval quorum “on-chain” reduces information asymmetry, solving the opacity problem in financial flows identified in the introduction of this work. This technical validation, even if occurring in a test environment, confirms the viability of decentralized systems for donation management, aligning with the “trust revolution” foreseen by Tapscott and Tapscott (2016).

Among the limitations and challenges observed, the dependence on external infrastructure stands out, especially the stability of test networks and obtaining fictitious balance via “faucets” for executing transactions with value movement. This dependence indicates that the development of distributed solutions requires rigorous additional planning, as network latency and resource availability in environments like Sepolia or Ganache impact the cadence of functional evaluations. The management of network fees (gas) and integration with third-party infrastructures are inherent technical aspects of smart contracts on public platforms, imposing scalability and cost challenges that must be mitigated in the prototyping phase (Antonopoulos; Wood, 2018).

The tests performed confirmed the pseudonymous nature of the blockchain, demonstrating that the tracking obtained is restricted to the digital flow of “on-chain” addresses. In practice, it is observed that it is impossible to determine the real civil identity behind each address solely with the metadata provided by the network. This limitation is a fundamental characteristic of the privacy model proposed by Nakamoto (2008), where transactions are publicly announced, but the identity of the key owners remains dissociated from the record. Although the ledger is transparent and auditable by any participant, the boundary between technical visibility and real-world identification remains a challenge for the application of the technology in contexts requiring strict legal compliance (KYC – “Know Your Customer”), as analyzed by Badev and Chen (2014).

The practical viability of the proposed traceability model lies in the simplicity of its open-source architecture, which guarantees a high rate of reproducibility and replication by different third-sector organizations. For another philanthropic institution to adopt the system, the operational procedure is limited to parameterizing the constructor method at the time of deploying the smart contract on the network. At this stage, the organization must define the cryptographic addresses of its authorized managers and establish the signature quorum consistent with its internal governance rules. This technical feature aligns with the concepts of disintermediation and systemic autonomy discussed by Tapscott and Tapscott (2016), as it allows each entity to configure a personalized environment of digital checks and balances without the need to develop a new software solution from scratch.

The transition from a preliminary prototype to a real production environment requires significant structural adaptations. In large institutions, the static model of approvers defined in the contract constructor can become obsolete due to staff turnover and changes in management. To mitigate this limitation, the software architecture must be adapted to include dynamic permission management functions, allowing the insertion or deletion of approver addresses upon prior collective approval by quorum. Furthermore, the reliance on complex technical interfaces such as Remix IDE restricts the system’s use to specialized users. Full-scale replication demands the development of a user-friendly interface layer (“front-end”), capable of translating Solidity function calls into simple visual buttons and intuitively integrating the MetaMask digital wallet, thereby reducing the entry barrier for non-technical managers.

From the perspective of scalability and financial sustainability, the limitations imposed by the fluctuation of network fees (gas) on the Ethereum main layer demand strategic architectural decisions. As analyzed by Badev and Chen (2014), cost planning is crucial for technological adoption in non-profit organizations. In scenarios with high transaction volumes or recurring small donations, direct processing on the main network becomes unfeasible. To circumvent this bottleneck, the technical infrastructure must be deployed on second-layer networks (Layer 2), which aggregate and process transactions off the main chain, significantly reducing computational fees while inheriting the cryptographic security of the underlying decentralized network, as proposed by Buterin (2013).

The applicability in real contexts of governance and regulatory auditing imposes the need to integrate the technical transparency of blockchain with the civil and legal frameworks of the physical world. Although the immutability of the ledger ensures the chronological integrity of the actions of the involved addresses (Nakamoto, 2008), the pseudonymity of digital wallets prevents the immediate validation of the real identity of managers to external supervisory bodies. Therefore, future adaptations must consider integration with decentralized identity protocols (Decentralized Identifiers – DID) and identity verification processes (Know Your Customer – KYC) outside the network (“off-chain”). This convergence between the algorithmic sovereignty of software and the legal requirements of civil compliance constitutes the necessary link to consolidate mutual trust and integral transparency in philanthropic donations.

In summary, the prototype demonstrated the effectiveness of blockchain technology and smart contracts in promoting the transparency and integrity of digital records for donations. The validation of role-based access control and the logical compliance of the approval quorum were confirmed, and the predictability of computational costs, along with the efficiency of the Ethereum Virtual Machine, were evidenced. The emission of on-chain events allowed for the integral reconstruction of the decision-making flow, ensuring the permanent auditability of the system and materializing financial disintermediation through cryptographic proofs, which provides an effective tool for decentralized governance and total resource visibility, responding to the objective of developing and validating a functional traceability prototype.

4. Conclusion

The study sought to develop and validate a functional traceability prototype for the digital donation flow using blockchain technology and smart contracts. The technical feasibility of the solution was verified, confirming role-based access control and the logical compliance of the approval quorum. The analysis of performance metrics indicated the predictability of computational costs and the efficiency of the Ethereum Virtual Machine in processing immutable governance rules. It was observed that the emission of on-chain events allowed for the integral reconstruction of the decision-making flow, ensuring the system’s permanent auditability. The main contribution lies in the materialization of financial disintermediation through cryptographic proofs, providing an effective tool for decentralized governance and total resource visibility, which resolves the issue of opacity in financial flows.

However, it was identified that the dependence on external infrastructures, such as the stability of test networks and the acquisition of fictitious balance, represents an operational limitation. The volatility of network fees and the challenge of individual private key custody were also observed, transferring security responsibility to managers. Additionally, the pseudonymous nature of the blockchain prevents the direct linking of addresses to civil identities, which imposes challenges for strict legal compliance. For future studies and large-scale applicability, a transition to second-layer networks or sidechains is suggested to optimize costs and scalability. It is also recommended to develop more user-friendly interfaces and integrate with decentralized identity protocols and off-chain KYC processes, aiming for convergence between algorithmic sovereignty and the regulatory requirements of the physical world.

Bibliographic References

“””

# Alternative for incorrectly formatted or unforeseen citation styles, even if the input appears consistent.

# For individual authors, take the last word (assumed last name)

# Special handling for identified corporate authors

# Split by common separators: ‘;’, ‘ and ‘, ‘ & ‘

“`python

author_names = re.split(r’;| e | & ‘, author_part)

author_section = segments[0].strip()

def parse_citation(citation_string):

Otherwise:

for name in author_names:

Handles various author separators (;, and, &) and corporate authors.

if “Fidelity Digital Assets” in author_part:

if len(parts) != 2:

if name: # Ensure name is not empty

import re

key_authors = set()

key_authors.add(“fidelity digital assets”)

key_authors.add(name.split()[-1].lower())

name = name.strip()

Analyzes a citation string to identify primary authors (by last name or full corporate designation) and the publication year.

sections = citation_text.rsplit(‘,’, 1)

return {‘key_authors’: key_authors, ‘year

return {‘key_authors’: {citation_string.lower()}, ‘year’: 0, ‘original_string’: citation_string}

year = int(year_str)

year_str = parts[1].strip()

Article originating from the Final Course Work of the Specialization in Software Engineering of the MBA USP/Esalq

To learn more about the course, click here and access the MBX Academy platform