1
I NSURE C ONNECT: Blockchain and Digital Identity for the Property Insurance Market
arXiv:2605.02824v1 [cs.CR] 4 May 2026
João Eduardo Travassos Miguel Correia INESC-ID, Instituto Superior Técnico, Universidade de Lisboa – Lisboa, Portugal {joaotravassos,miguel.p.correia}@tecnico.ulisboa.pt
Abstract—This paper presents I NSURE C ONNECT, a blockchain-based system for improving transparency, authentication, and auditability in property-insurance workflows after natural disasters. The system combines Self-Sovereign Identity (SSI), Decentralized Identifiers (DIDs), Verifiable Credentials (VCs), satellite imagery, Hyperledger Fabric, and IPFS to register identities, insurance contracts, and damage claims. Property images are stored off-chain in IPFS, while content hashes and signed records are maintained on a permissioned blockchain. Users interact with the system through a desktop application, while chaincode enforces role-based access control and validates digital signatures. The prototype was evaluated under concurrent request loads from 50 to 3000 requests, measuring latency, throughput, and dropped connections. The results indicate that the system sustains increasing throughput under load, although latency rises and dropped connections appear at higher concurrency levels.
I. I NTRODUCTION Blockchain technology, first introduced in 2009 by Satoshi Nakamoto in the Bitcoin whitepaper, has gained significant traction due to its diverse applications [1], [2]. As a decentralized peer-to-peer distributed ledger, blockchain eliminates the need for trusted third parties in online transactions. Over the years, its potential has expanded beyond cryptocurrency, leading to the development of private and permissioned blockchains that enable organizations to use this technology in contexts where trust is not inherent among parties. This evolution also gave rise to Self-Sovereign Identity (SSI), a transformative approach to identity management that empowers individuals to control their personal data without relying on centralized authorities [3]. Using Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs), SSI leverages blockchain to provide a secure and privacy-preserving method for verifying identitie [4]–[6]. This innovation allows users to disclose only necessary information, fostering trust while maintaining privacy, making it particularly relevant in sectors like real estate and insurance. Natural disasters, such as floods and earthquakes, pose significant challenges, often resulting in property damage and financial losses. Addressing these challenges requires innovative solutions that streamline the claim process and ensure trust between affected individuals and insurance companies. This paper presents I NSURE C ONNECT, a system that registers entities, insurance contracts, and damage claims after natural disasters using Decentralized Identifier documents, satellite imagery, SSI, and blockchain technologies.
I NSURE C ONNECT enhances the reliability and transparency of the insurance process through a blockchain-based framework. This shared ledger supports trust between clients seeking financial assistance and insurance companies processing claims. Although primarily aimed at natural disaster scenarios, I NSURE C ONNECT has the potential to adapt to various markets, including auto insurance, serving as a versatile model for insurance-related transactions. Built on a permissioned Hyperledger Fabric blockchain, I NSURE C ONNECT uses DIDs and VCs to verify client identities and proof of property ownership. The InterPlanetary File System (IPFS) stores satellite images off-chain to avoid overloading the blockchain. The system provides three key services: DID Document registration, Insurance Contract registration, and Damage Claim registration. Each entity must first register with a DID Document, after which clients and insurance companies can establish insurance contracts based on property images. When a client experiences damage, they submit a claim, which the insurance company updates throughout the claim-handling process. Through this approach, I N SURE C ONNECT aims to improve traceability, authentication, and auditability in property-insurance workflows after natural disasters. II. BACKGROUND Blockchain [7] is a transparent, immutable, distributed, and decentralized ledger technology that securely links blocks of transactions using cryptographic techniques. It ensures data integrity and security, making it resistant to tampering and attacks. Blockchains can be public or private. Public blockchains, like Bitcoin [1] and Ethereum [8], are open to anyone and use consensus mechanisms such as proof-ofwork to validate transactions, while private blockchains restrict access to authorized participants, providing greater control, faster transaction processing, and customizable permissions for different users. Hyperledger Fabric [9] is a permissioned blockchain framework developed for enterprise solutions, featuring a modular architecture and plug-and-play consensus. It enables multiple channels, each representing a separate blockchain with its own ledger, allowing for private communication between specific members. Authentication and identity management are handled through cryptographic certificates issued by a Membership Service Provider (MSP). The transaction process in Fabric follows an execute-order-validate model, which includes endorsing transactions, ordering them into blocks, and
2
validating them to ensure the integrity and consistency of the blockchain. Digital identity involves verifying attributes beyond authentication, such as education or residency. Traditional systems require multiple siloed accounts, leading to privacy and security issues. Self-Sovereign Identity (SSI) [3] uses blockchain to give individuals full control over their digital identity without relying on central authorities. With Decentralized Identifiers (DIDs) [4] and Verifiable Credentials (VCs) [6], SSI enables privacy-preserving identity management, reducing intermediary dependence and minimizing data breaches. Decentralized ledgers support a user-centric trust model based on cryptographic proofs rather than centralized authorities. The InterPlanetary File System (IPFS) [10] is a decentralized peer-to-peer file system designed for high-throughput content-addressed storage. It connects nodes using a Distributed Hash Table (DHT) for peer discovery and uses BitSwap, a protocol for exchanging data blocks between nodes, to incentivize content sharing. IPFS constructs a Merkle Directed Acyclic Graph (Merkle DAG) to link data cryptographically, ensuring content addressing, tamper resistance, and deduplication. This architecture ensures efficient file storage, content availability, and resilience without relying on a central authority or a single point of failure, making IPFS a robust solution for distributed storage. III. R ELATED W ORK Blockchain has been increasingly studied in the insurance sector as a mechanism for improving transparency, traceability, automation, and auditability. A recent systematic literature review identifies blockchain as a promising technology for insurance workflows, while also noting that adoption remains limited by technical, organizational, regulatory, and economic challenges [11]. These challenges are particularly relevant for claims management, where several parties must agree on policy validity, evidence authenticity, claim status, and payment decisions. Several works propose blockchain-based architectures for insurance claims. Chen et al. propose a car-insurance claims system based on blockchain, IPFS, Hyperledger Fabric, digital signatures, and smart contracts, aiming to reduce fraud, improve traceability, and lower the cost of storing claim-related data [12]. Their work is close to I NSURE C ONNECT in its use of a permissioned blockchain and IPFS for claim evidence, but it focuses on car-insurance scenarios. I NSURE C ONNECT instead targets property insurance after natural disasters and uses satellite imagery to document the state of insured property before and after a claim. Self-Sovereign Identity (SSI) has also been explored in insurance-related blockchain systems. Farao et al. present INCHAIN, a cyber-insurance architecture that combines blockchain, smart contracts, and SSI to support traceability, process automation, and customer identification [13]. This work demonstrates the relevance of SSI in insurance, especially for authentication and fraud reduction. However, INCHAIN focuses on cyber-insurance workflows, whereas I N SURE C ONNECT applies DIDs and VCs to property-insurance contracts, proof of ownership, and post-disaster claims.
Natural-disaster insurance is also related to parametric insurance, where payouts are triggered by predefined indicators rather than traditional damage assessment. Steinmann et al. propose a framework for natural-hazard parametric insurance and discuss the importance of reducing basis risk, i.e., the mismatch between parameter-based payouts and actual damages [14]. Rabehaja et al. address blockchain-based parametric insurance under multiple sources of truth, highlighting the risk of relying on a single data source for payout decisions [15]. Hao et al. further explore blockchain-enabled parametric insurance using remote sensing and IoT data, with privacypreserving claim verification based on zero-knowledge proofs [16]. These works are relevant because they show how external evidence sources can support insurance automation. In contrast, I NSURE C ONNECT does not automate payouts through parametric triggers; instead, it records and authenticates contract and claim evidence so that clients, insurers, and auditors can verify the claim history. The use of blockchain for remote-sensing image verification is another related area. Liu and Chang propose a blockchainbased method for retrieval and verification of remote-sensing images using Hyperledger Fabric and IPFS [17]. Their work supports the idea that large geospatial images should be stored off-chain while hashes and metadata are maintained on-chain. I NSURE C ONNECT follows a similar storage principle, but applies it to insurance evidence: satellite images are stored in IPFS, while blockchain records link those images to identities, contracts, claims, timestamps, and signatures. Blockchain has also been studied in land-registry systems, which are relevant because property insurance depends on reliable ownership and property-state information. Several land-registry initiatives have explored blockchain in countries such as Sweden [18], India [19], Honduras [20], Japan [21], and Brazil [22]. Academic proposals in this area typically focus on registering property records, verifying ownership, and recording transfers through smart contracts [23]–[26]. These systems improve the integrity of property records, but they generally do not address the full insurance lifecycle or integrate SSI-based identity verification with claim evidence. Overall, existing work has explored blockchain in insurance, SSI for insurance identification, parametric disaster insurance, remote-sensing verification, and blockchain-based land registries. I NSURE C ONNECT combines these directions in a single property-insurance workflow: participants are identified through DIDs, ownership can be supported through VCs, contracts and claims are recorded on a permissioned blockchain, and satellite imagery is stored off-chain through IPFS. The proposed system therefore focuses on authenticated and auditable evidence management for property-insurance claims after natural disasters. IV. I NSURE C ONNECT D ESIGN AND I MPLEMENTATION I NSURE C ONNECT is a system designed to help insurance companies and clients register, manage, and resolve insurance contracts and property damage claims, particularly for large terrains visible via satellite imagery. It focuses on natural disaster scenarios such as floods, earthquakes, and typhoons.
3
Fig. 1. InsureConnect roles and permissions
Fig. 2. I NSURE C ONNECT architecture
Participants must register on the platform to establish contracts and submit claims. The authenticity of the data is ensured through digital signatures, allowing third-party verification. The media is stored in IPFS to achieve decentralization.
I NSURE C ONNECT is designed as a decentralized, containerized system using Docker for consistent deployment and orchestration. All components, blockchain nodes and IPFS storage, are packaged in Docker containers, ensuring portability, scalability, and service isolation. Docker simplifies network management, allowing for seamless node addition or removal. The architecture has three layers: the blockchain network, decentralized storage, and client interface. Each component and their interaction is detailed below. • I NSURE C ONNECT Blockchain - Hyperledger Fabric stores DID Documents, Insurance Contracts, and Claims. This permissioned blockchain ensures that only relevant users can access their data, providing privacy and security. Chaincode enforces access controls and smart contract execution, ensuring trust, transparency, and data immutability. • Decentralized Storage - A peer-to-peer network, using IPFS, stores satellite images of the property, reducing blockchain storage costs. The blockchain holds content hashes linking to IPFS, ensuring tamper-resistance and easy access to off-chain data. • Desktop App - The app allows users to interact with the blockchain and decentralized storage. Users can securely sign transactions, submit queries, and manage files in a seamless and secure interface. Figure 2 shows the architecture of I NSURE C ONNECT. The solution decentralizes record storage and verification among authorized participants in a permissioned network. All records, such as DID documents, insurance contracts, and damage claims, are stored on the blockchain. Due to the high cost of on-chain storage, the system uses IPFS, a decentralized, tamper-resistant, peer-to-peer storage network. IPFS nodes, hosted alongside Hyperledger Fabric nodes, allow participants to store and access data via the desktop app.
A. Participants and Roles Participants in the system are assigned roles that determine their interactions. The four main roles are: • Higher Authority - A regulatory body responsible for creating and maintaining DIDs for insurance companies, ensuring the integrity and authenticity of their identities. • Insurance Company - Provides financial protection, manages contracts, and processes claims, especially during natural disasters. • Client - Holds a property insurance plan, submits damage claims, and updates contracts. • Auditor - Independently verifies financial records, with read-only access to disputed records for audit purposes. Participants must be registered in two places: the blockchain ledger and Fabric’s Membership Service Provider (MSP). Ledger registration creates a DID Document through chaincode and stores it permanently on the blockchain. MSP registration is separate from the ledger and is performed through the Fabric certificate authority, which issues the certificate and private key required to submit transactions. The Higher Authority is pre-assigned and registers Insurance Company users; Insurance Companies then register their Clients and Auditors. Each role has specific permissions (see Figure 1): • Insurance Companies: Can create, update, and read contracts and claims. • Client: Can update contracts and manage their claims. • Auditor: Have read-only access to disputed records for verification. These roles ensure secure and controlled management of insurance operations. B. Architecture I NSURE C ONNECT uses a private, permissioned Hyperledger Fabric blockchain to store records, a decentralized storage network for images, and a desktop application through which participants interact with the system.
C. Blockchain The blockchain chosen for this project is Hyperledger Fabric [27] from the Linux Foundation. It was selected because it meets the project’s requirements, such as identity management. The blockchain should be hosted by at least five different entities to ensure fault tolerance. Each entity will host a peer node, and 3 of them will also host an orderer node, resulting in a total of 8 nodes. External applications connecting to peer
4
nodes to submit transactions will act as client nodes. This setup ensures network resilience, as peer nodes maintain the ledger and endorse transactions, even if some nodes go offline. The distributed structure supports scalability, allowing the network to handle more transactions as it grows. The orderer nodes use the Raft consensus mechanism [28], chosen over Kafka and Solo due to its simplicity and ease of maintenance. Raft handles leader election and fault tolerance effectively, making it the preferred choice for Fabric, while Kafka adds unnecessary complexity with its need for a ZooKeeper cluster. Solo, designed for testing only, lacks fault tolerance and is not suitable for production. Kafka provides strong consistency and fault tolerance, but its reliance on ZooKeeper adds complexity and can affect the availability of the system during failures or maintenance. According to the CAP Theorem [29], distributed systems can provide only two of three properties: consistency, availability, and partition tolerance. Raft is a CP protocol, ensuring consistency during network partitions but sacrificing availability during leader reelections. Kafka also follows the CP model, but ZooKeeper’s setup increases operational complexity, impacting even more the availability. There are three types of nodes: peer, orderer, and client nodes. Client nodes are used by participants to submit transactions and queries to the network. Each participant uses two distinct credential sets. The first is the DID key pair, used to sign the business content submitted to the ledger, such as DID Documents, contracts, and claims. The second is the Fabric MSP credential, composed of a certificate and private key, used by the client application to authenticate the transaction or query issuer to Hyperledger Fabric. This distinction is especially important for read operations, where no signed business object is submitted but the chaincode must still verify which participant issued the query. In addition to peer and orderer nodes, at least one entity must host a certificate authority (CA) to register participants and issue transaction signing credentials. D. Ledger Each peer node will have one chaincode deployed, to which the client nodes will submit transactions. All objects in the network are stored in a single ledger. The chaincode represents three main objects (see Figure 3): DID documents, insurance contracts, and damage claims. These objects, which contain crucial data, must be accompanied by a signature in JSON format when submitted. The main objects are: • DID Documents - Stored in the ledger to prevent divergent results from external data updates, ensuring consistent blockchain progress. These documents are vital for identifying and verifying who performs write operations. They include the entity’s identity (‘did’), an RSA public key (composed of ‘exponent’ and ‘modulus’), and additional fields like ‘kty’ (key type), ‘DateTime’ (creation time), and ‘EntityType’ (defining role and access permissions). Peers verify the signature before endorsing transactions.
Fig. 3. I NSURE C ONNECT UML class diagram.
Insurance Contracts - Represent agreements between two entities. Each contract contains DIDs for both parties, an IPFS link to property images, verifiable credentials, creation timestamp, and both parties’ signatures. The contract is valid only after both parties sign. Any updates erase the signatures, which require the re-signing for validity. • Damage Claims - Allow clients to seek compensation for losses. Each claim includes a reference to the client, insurance contract, an IPFS link, creation timestamp, claim state (starting with ‘PRESENTED’), and the signature of the issuer (client or insurance company). Claims progress through predefined states: ‘PRESENTED’, ‘PROCESSING’, ‘HANDLED’, and ‘CANCELED’, without reverting to previous stages. Each update requires a new signature and updated values. Figure 3 shows the UML class diagram of these ledger objects. Note that while the ‘kty’ field exists in DID documents, it is unused in this prototype, since only RSA signatures are accepted. RSA was chosen due to system constraints. Hyperledger Fabric runs on Java 11, which limited the use of faster algorithms such as EdDSA, which is available only in Java 16 or higher. As a result, RSA was the first algorithm successfully implemented. •
E. Decentralized Storage As mentioned above, the Interplanetary File System (IPFS) is used to store all content related to property damage, specifically images taken before and after a claim is submitted to document damage. When creating an insurance contract or claim object, an IPFS link is required pointing to an IPFS directory containing these photos. IPFS plays an important role due to the large storage space required for images, which cannot be stored directly on Fabric’s blockchain. To maintain a decentralized solution, IPFS was chosen as the off-chain decentralized storage system for I NSURE C ONNECT. Other options, such as BitTorrent [30] and Swarm [31], were considered. Swarm was discarded because it is tightly
5
integrated with the Ethereum network. BitTorrent, while competitive in performance and efficiency, loses in decentralization and content immutability. BitTorrent relies on centralized trackers to assist in peer discovery, whereas IPFS uses a fully decentralized distributed hash table (DHT). Furthermore, IPFS’s content-addressing ensures data immutability, as altering a file would change its hash, making it useful for proving that images have not been tampered with. The prototype uses the public IPFS network, which means that uploaded images may be retrievable by any party that obtains the corresponding content identifier. Therefore, the IPFS link should not be treated as an access-control mechanism. In a production deployment, sensitive images should be encrypted before being added to IPFS, with decryption keys shared only with authorized parties such as the client, the insurance company, and assigned auditors. A key issue with IPFS is its garbage collector, which removes unused data. To prevent this, content can be pinned, ensuring that it is not deleted. An alternative approach could involve creating a private national IPFS network to ensure privacy. However, this would require additional entities and storage units. Relying on the five current entities hosting the Fabric blockchain would result in a centralized system, which undermines true decentralization, as the failure of one or two nodes could compromise the network.
issue described earlier. In the web app solution, users would submit the transaction content and its corresponding signature through the web interface. The web app’s host would then build the transaction request and submit it using admin privileges. While Write operations would remain unchanged, Read operations would become indistinguishable, making it impossible to identify who submitted them. This issue arose because all transaction requests originated from the same user, the node that received the transaction contents via the web app and built the transaction request to send to Fabric. Due to privacy concerns, the web app solution was abandoned in favor of a more privacy-respecting desktop application. V. I NSURE C ONNECT O PERATIONS This section describes the supported operations in the chaincode. It is divided into two subsections where each one addresses different objects. The first subsection talks about identity object methods, specifically focusing on DID documents. The second subsection details methods for interacting with insurance contracts and managing claims. Figure 7 shows all possible operations for every role. This section also aims to guide the reader through the entire process, from the creation of a DID Document to the resolution of a Claim. A. Identity Management
F. Desktop App As mentioned above, the desktop app will be used by all users to interact with the network. The app does not differentiate between user types like “Insurance Company” or “Client.” Instead, the chaincode on the blockchain handles role-based access control. Thus, the app provides every user with all available interaction options. The user identities and signatures submitted to the blockchain are used to verify transactions. I NSURE C ONNECT’s desktop app is divided into four major components based on functionality: • Identity Management Menu – Responsible for creating DID documents, retrieving identity data, and updating verifiable credentials. • Insurance Contract Management Menu – Handles the creation of insurance contracts, updating client signatures, modifying contracts, and retrieving contract data. • Claim Management Menu – Enables creating, updating, and retrieving claim data. • Add Public and Private KeyPairs Menu – Allows users to upload their public and private keypairs, issued by Fabric’s MSP, so the app can sign transactions for recognition by the blockchain. The “Add Certificate and Private Key” menu is essential for entities to upload their certificate/private key pair, enabling the app to sign transactions and allowing the blockchain to recognize and verify them. 1) WebApp: Although the desktop application was ultimately chosen as the final solution, the original approach involved a web application hosted by each node. However, this solution was later discarded due to the Read operation
Within this menu, there are two further options: Create a DID Document and Check a DID Document. To create a DID Document, the following fields must be provided: • Decentralized Identifier (DID) - This field holds the identity of the entity on the platform. • Exponent - This field holds the exponent of an RSA key. • Modulus - This field contains the modulus of an RSA key. • Date Time - This field holds the date and time at which the transaction was signed and submitted to the network. • Entity Type - This field holds the type of user this entity will be. • Authority Signature - This field holds the signature of the user who issued the transaction and submitted the DID Document creation request. Once the transaction is submitted to the Fabric network, the signature is verified. A Higher Authority user signature is required to create Insurance Company users and an Insurance Company user signature is needed to create Client and Auditor users. If the signature is valid, a new DID Document is created and stored in the ledger. At this stage, an additional procedure is needed: the registration and enrollment of the user in Fabric’s MSP. As mentioned above, this is done by users with admin permissions. These admin permissions are granted only to the Higher Authority and Insurance Companies. Once registration and enrollment are complete, the generated public/private key pair is sent back to the newly created user, allowing them to load the credentials into their desktop app. Figure 4 illustrates the identity creation process.
6
Fig. 5. BPMN diagram of the insurance contract creation/update Fig. 4. BPMN diagram of the identity creation process
To check a DID Document, the only required input is the DID that the user wishes to verify. The corresponding data is then retrieved and displayed.
Fabric MSP identity to authenticate the query issuer. The desktop application signs the Fabric query with the user’s MSP private key, and the chaincode obtains the issuer identity from the transaction context. If the issuer is authorized to access contracts associated with the target DID, the corresponding contracts are returned; otherwise, the request is rejected.
B. Insurance Contract Management Within this menu, there are four further options, Create an Insurance Contract, Update an Insurance Contract, Update the Client Signature and Check my Insurance Contracts. To create an Insurance Contract, the following fields must be provided: • Insurance Company DID - This field holds the identity of the insurance company. • Client DID - This field holds the identity of the client. • Client Property Land Registration VC - This field holds the client’s VC issued by Land Registration Authority stating that the client is the owner of the property the contract will cover. • IPFS Hash - This field holds the link to an IPFS directory with the images of the property at the time of contract issuance. • Date Time - This field holds the date and time at which the transaction was signed and submitted to the network. • Insurance Company Signature - This field holds the signature of the insurance company issuing the transaction and submitting the Insurance Contract creation request. Once the contract is created, the Client user must use the Update the Client Signature option to add their signature to the insurance contract, making it valid. An insurance contract can be updated, but only by the insurance company. The only field which is allowed to be updated is the IPFS Hash. Once it is updated, the Date Time field also is updated to reflect the time of the modification. The insurance company must submit a new signature along with the updated fields, and the client’s signature is deleted. While the client does not update their signature, the contract is considered invalid. Once the client signature is added to the contract, the contract becomes valid again. Figure 5 demonstrates the Insurance Contract creation/update process which happens to be the same. To check an Insurance Contract, the user provides the DID whose contracts should be retrieved. Because read operations do not include a signed business object, the system uses the
C. Claims Management Within this menu there are three further options: Create a Claim, Update a Claim, Assign an Auditor, and Check Claims. To create a Claim, the following fields must be submitted: • Claim ID - This field holds ID of the claim. • Insurance Contract ID - This field holds the ID of the insurance contract the claim will be covered by. • IPFS Hash - This fields holds the link to an IPFS directory with the images of the property at the time of claim issuance. • Date Time - This field holds the date and time at which the transaction was signed and submitted to the network. • Contents Signature - This field holds the signature of either the insurance company or the client, depending on who issued the transaction and submitted the Claim creation request. The claim can be created by either the client or the insurance company. The fields Claim State and Auditor are not filled during the creation, since they will be automatically filled in the object by the chaincode. By default, the claim’s initial state will be PRESENTED, and the Auditor will be set to null. The starting stage must also be included in the signature. After the claim is created, both the client and the insurance company can use the Update a Claim option to update the claim. In addition, the insurance company can assign an auditor to the claim. The only editable fields are the Claim State and Auditor fields, respectively, for each function. The new updated claim state must progress for the claim to be handled and finished. Again, when either claim state or the auditor are updated, a new signature must be submitted by the one who updated it, along with the new updated contents. Figure 6 demonstrates the lifecycle of a claim. To check a Claim, the user provides the target DID or claim identifier. As with contract queries, the desktop application signs the query using the user’s Fabric MSP credentials. The chaincode then verifies whether the requester is authorized to access the claim. Clients and insurance companies can
7
Fig. 6. BPMN diagram of the lifecycle of a claim
access claims associated with their contracts, while auditors can access claims assigned to them. If the requester is not authorized, the query is rejected. D. Solution Recap This section presented the I NSURE C ONNECT system, whose objective is to establish a well-documented insurance process from the beginning to the end. From the moment the entities are created on the platform to the moment that a claim has finished its lifecycle. The section begins by establishing the roles and participants, Client, Insurance Company, Auditor, and Higher Authority, while explaining their access permissions. Following that, the architecture is laid out, detailing the active components involved: Hyperledger Fabric, IPFS, the desktop app, and the possible nodes for hosting the network. Then each component is explained in detail to justify every decision that affected the final product. Such decisions were, for example, the chosen consensus mechanism, Raft, the need for two different public/private keypairs, why are RSA signatures utilized instead of others, and why was a desktop app developed rather than an online web interface. To conclude this section, all of I NSURE C ONNECT’s operations are described to provide insights into the features offered by the desktop app. The different lifecycles of the objects are also presented. VI. E VALUATION The evaluation focused on measuring how the system performs under different loads of concurrent requests. The performance of five functions was tested, each subject to request loads ranging from 50 to 3000 concurrent requests. The evaluation measures the performance of five write operations: Create DID Document, Create Insurance Contract, Update Insurance Contract Signature, Create Claim, and Update Claim. These operations were selected because they exercise the most resource-intensive parts of the system, including signature verification, endorsement, ordering, validation, ledger updates, and the read operations required for data lookup. The results provide an initial basis for understanding the system’s behavior under dynamic request loads. Across the experiments, latency increased with the number of concurrent requests. Throughput also increased initially, but its growth slowed at higher request loads as system resources became saturated. At the highest loads, some requests failed due to dropped connections. Table I reports the percentage of dropped connections for each operation.
The experiments were limited to 3000 concurrent requests because higher loads made the host machine unstable, producing invalid measurements or causing all connections to fail. Figure 8 shows the latency and throughput of the Create DID Document operation. Latency increases almost linearly with the number of concurrent requests, from 1.16 s at 50 requests to 24.54 s at 3000 requests. Throughput also increases, but the growth rate slows at higher loads, indicating that the system approaches resource saturation. Figure 9 presents the results for the Create Insurance Contract operation. Latency increases with the request load, reaching 25.63s at 3000 concurrent requests. Throughput increases across the tested range, reaching 74.84 Tx/s at 3000 requests. However, this operation begins to show dropped connections at 2500 requests, as reported in Table I, indicating that the system is approaching its resource limits. Figure 10 presents the results for the Update Insurance Contract Signature operation. Latency increases from 1.22s at 50 requests to 17.04 s at 2500 requests, followed by a slight decrease to 15.44s at 3000 requests. Throughput generally increases with load, although the measurements fluctuate at higher concurrency levels. These fluctuations suggest that the system is operating near saturation. Figure 11 shows the results for the Create Claim operation. Latency increases from 1.83 s at 50 requests to 24.50 s at 3000 requests. Throughput increases up to 2500 requests, reaching 86.38 Tx/s, before decreasing to 77.02 Tx/s at 3000 requests. This decrease, together with the dropped connections reported in Table I, indicates that this operation is affected by resource saturation at high concurrency levels. Figure 12 presents the results for the Update Claim operation. Latency increases from 1.40s at 50 requests to 14.21s at 3000 requests. Throughput also increases across the tested range, reaching 138.86 Tx/s at 3000 requests. Nevertheless, this operation has the highest dropped-connection rate at high load, reaching 20% at 2500 requests and 30% at 3000 requests. Overall, the results show that higher concurrency leads to higher latency for all evaluated operations. Throughput increases with load in most cases, but its growth slows or fluctuates at higher concurrency levels, suggesting that the system approaches saturation. Dropped connections appear from 2500 concurrent requests onward for all operations except Create DID Document. The increase in latency is mainly explained by finite host resources being shared among a growing number of concurrent requests. Although throughput does not collapse within the tested range, the error rates in Table I show that the system becomes less reliable under the highest loads. These results should therefore be interpreted as prototype-level performance measurements on a resource-limited local deployment, rather than as production-scale benchmarks. VII. C ONCLUSION This paper presents a blockchain-based solution for the insurance market to streamline the registration of insurance contracts and the handling of claims with enhanced security through blockchain technology and digital signatures.
8
Fig. 7. I NSURE C ONNECT’s operations diagram TABLE I E RROR RATE VERSUS NUMBER OF REQUESTS ( IN PERCENTAGE ) Number of Requests
Create DID Documents
Create Insurance Contract
Update Insurance Contract Signature
Create Claim
Update Claim
50 100 250 500 1000 1500 2000 2500 3000
0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 12 16
0 0 0 0 0 0 0 12 16
0 0 0 0 0 0 0 16 20
0 0 0 0 0 0 0 20 30
Create DID Document Latency
Update Insurance Contract Signature Latency
Create DID Document Throughput
Update Insurance Contract Signature Throughput
25 80
100
15
10
Throughput (Tx/s)
15
70 Latency (s)
Throughput (Tx/s)
Latency (s)
20
60
50
10
80
60
5
5
40 40
0
0 0
500
1,000
1,500
2,000
2,500
3,000
0
500
Number of Requests
1,000
1,500
2,000
2,500
3,000
0
500
Number of Requests
1,000
1,500
2,000
2,500
3,000
0
500
Number of Requests
Fig. 8. Latency & throughput of the create DID documents function
1,000
1,500
2,000
2,500
3,000
Number of Requests
Fig. 10. Latency & throughput of the update insurance contract signature function
Create Insurance Contract Throughput
Create Insurance Contract Latency
Create Claim Latency
Create Claim Throughput
25 70
25
10
5
80
60
20
50 40
Throughput (Tx/s)
15
Latency (s)
Throughput (Tx/s)
Latency (s)
20
15
10
30
60
40
5 0 0
500
1,000
1,500
2,000
Number of Requests
2,500
3,000
0
500
1,000
1,500
2,000
2,500
3,000
Number of Requests
Fig. 9. Latency & throughput of the create insurance contract function
20
0 0
500
1,000
1,500
2,000
Number of Requests
2,500
3,000
0
500
1,000
1,500
2,000
2,500
3,000
Number of Requests
Fig. 11. Latency & throughput of the create claim function
The solution combines a permissioned blockchain for shared record-keeping with IPFS for decentralized file storage, while employing satellite imagery for property damage assessment. The system is built on a private, permissioned Hyperledger
Fabric blockchain, enabling identity registration for different entities and using IPFS for content-addressed storage. The blockchain stores three types of assets: Decentralized Identifier
9
Update Claim Latency
Update Claim Throughput 140
12
120 Throughput (Tx/s)
14
Latency (s)
10 8 6
100 80 60
4 40
2 0
500
1,000
1,500
2,000
2,500
3,000
20
0
500
1,000
1,500
2,000
2,500
3,000
Number of Requests
Number of Requests
Fig. 12. Latency & throughput of the update claim function
(DID) Documents, Insurance Contracts, and Damage Claims. Four participants were defined: Client, Insurance Company, Auditor, and Higher Authority, each with specific permissions. Authentication is achieved through DID documents and Fabric’s Membership Service Provider (MSP). The desktop app provides access to all features, with authentication handled in each transaction using uploaded credentials. The evaluation of the system included measurements of latency, throughput, and error on a resource-limited local machine. The results show increasing throughput up to high concurrency levels, at the cost of higher latency and dropped connections beyond 2500 concurrent requests. In summary, this solution improves transparency and efficiency in the insurance process, ensuring that all parties have secure, authenticated access to relevant information, while leveraging blockchain for an immutable record of transactions. ACKNOWLEDGEMENTS This work was financially supported by Project Blockchain.PT – Decentralize Portugal with Blockchain Agenda (Project no 51), WP 6: Digital Assets Management, Call no 02/C05-i01.01/2022, funded by the Portuguese Recovery and Resilience Program (PRR), The Portuguese Republic, and The European Union (EU) under the framework of the Next Generation EU Program. This work was also supported by national funds through Fundação para a Ciência e a Tecnologia, I.P. (FCT) under projects UID/50021/2025 (DOI: https://doi.org/10.54499/UID/50021/2025). R EFERENCES [1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008. [2] M. E. Peck, “Blockchains: How they work and why they’ll change the world,” IEEE Spectrum, vol. 54, no. 10, pp. 26–35, 2017. [3] C. Allen, “The path to self-sovereign identity,” Life With Alacrity, 2016. [Online]. Available: https://www.lifewithalacrity.com/article/thepath-to-self-soverereign-identity/ [4] D. Reed, M. Sporny, D. Longley, C. Allen, R. Grant, M. Sabadello, and J. Holt, “Decentralized identifiers (DIDs) v1. 0,” Draft Community Group Report, 2020. [5] M. Sporny, D. Longley, and D. Chadwick, “Verifiable credentials data model 1.0,” W3C, Tech. Rep., 2019. [Online]. Available: https://w3c.github.io/vcdata-model/https://www.w3.org/TR/vcdata-model/ [6] M. Sporny, T. T. Jr, I. Herman, M. B. Jones, and G. Cohen, Verifiable Credentials Data Model v2.0 (W3C Candidate Recommendation Draft), W3C, oct 2024. [7] T. T. A. Dinh, R. Liu, M. Zhang, G. Chen, B. C. Ooi, and J. Wang, “Untangling blockchain: A data processing view of blockchain systems,” IEEE Transactions on Knowledge and Data Engineering, vol. 30, no. 7, pp. 1366–1385, 2018.
[8] V. Buterin and Ethereum team, “Ethereum: A next-generation smart contract and decentralized application platform,” 2014-17, white paper. [9] Hyperledger Fabric team, “Hyperledger Fabric documentation,” 2024, accessed: 2024-10-08. [Online]. Available: https://hyperledgerfabric.readthedocs.io/en/release-2.5/ [10] J. Benet, “IPFS: Content addressed, versioned, P2P file system,” arXiv preprint arXiv:1407.3561, 2014. [11] T. Dominguez Anguiano and L. Parte, “The state of art, opportunities and challenges of blockchain in the insurance industry: A systematic literature review,” Management Review Quarterly, vol. 74, no. 2, pp. 1097–1118, 2024. [12] C.-L. Chen, Y.-M. Zheng, D.-C. Huang, L.-C. Liu, and H.-C. Chen, “A blockchain and IPFS-based anticounterfeit traceable functionality of car insurance claims system,” Sensors, vol. 23, no. 23, p. 9577, 2023. [13] A. Farao, G. Paparis, S. Panda, E. Panaousis, A. Zarras, and C. Xenakis, “INCHAIN: A cyber insurance architecture with smart contracts and self-sovereign identity on top of blockchain,” International Journal of Information Security, vol. 23, pp. 347–371, 2024. [14] C. B. Steinmann, B. P. Guillod, C. Fairless, and D. N. Bresch, “A generalized framework for designing open-source natural hazard parametric insurance,” Environment Systems and Decisions, vol. 43, no. 4, pp. 555– 568, 2023. [15] T. Rabehaja, S. Pal, A. Hill, and M. Hitchens, “A blockchain-based approach for parametric insurance under multiple sources of truth,” IEEE Transactions on Services Computing, vol. 17, no. 3, pp. 718–732, 2024. [Online]. Available: https://doi.org/10.1109/TSC.2023.3296808 [16] M. Hao, K. Qian, and S. C.-K. Chau, “Privacy-preserving blockchainenabled parametric insurance via remote sensing and IoT,” IEEE Transactions on Services Computing, vol. 18, no. 5, pp. 3093–3105, 2025. [17] Y. Liu and Y. Chang, “Blockchain-based method for spatial retrieval and verification of remote sensing images,” Sensors, vol. 24, no. 7, 2024. [18] International Council for Accreditation of IT Managers. (2016) Blockchain and land registry. [Online]. Available: https://icait.org/pdf/Blockchain Landregistry Report.pdf [19] Government of India, Ministry of Electronics and Information Technology. (2020) Land registration using blockchain. [Online]. Available: https://blockchain.gov.in/Home/CaseStudy?CaseStudy=LandRegistration [20] Borgen Project. (2021) Blockchain-based land registry. [Online]. Available: https://borgenproject.org/blockchain-based-land-registry/ [21] N. Asia. (2017) Japan to tidy up scattered property records. [Online]. Available: https://asia.nikkei.com/Markets/Property/Japan-totidy-up-scattered-property-records [22] V. Lemieux, C. Lacombe, and D. Flores, “Title and code: Real estate transaction recording in the blockchain in Brazil (RCPLAC-01),” Case Study, vol. 1, 2018. [23] R. Khan, S. Ansari, S. Jain, and S. Sachdeva, “Blockchain based land registry system using ethereum blockchain,” Journal of Xi’an University of Architecture & Technology, vol. 12, pp. 3640–3648, 2020. [24] A. Sahai and R. Pandey, “Smart contract definition for land registry in blockchain,” in IEEE 9th International Conference on Communication Systems and Network Technologies, 2020, pp. 230–235. [25] M. Shuaib, S. M. Daud, S. Alam, and W. Z. Khan, “Blockchain-based framework for secure and reliable land registry system,” TELKOMNIKA (Telecommunication Computing Electronics and Control), vol. 18, no. 5, pp. 2560–2571, 2020. [26] P. C. Henriques and M. Correia, “Decentralised land registration and transaction with blockchain and self-sovereign identity,” in 2025 44th International Symposium on Reliable Distributed Systems (SRDS), DLT4SEC 2025 - International Workshop on DLT for Cybersecurity and Vice Versa. IEEE, 2025, pp. 404–409. [27] V. Dhillon, D. Metcalf, and M. Hooper, The Hyperledger Project. Berkeley, CA: Apress, 2017, pp. 139–149. [28] D. Ongaro and J. Ousterhout, “In search of an understandable consensus algorithm,” in 2014 USENIX Annual Technical Conference, 2014, pp. 305–319. [29] S. Gilbert and N. Lynch, “Perspectives on the CAP theorem,” Computer, vol. 45, no. 2, pp. 30–36, 2012. [30] B. Cohen, “Incentives build robustness in bittorrent,” in Workshop on Economics of Peer-to-Peer systems, vol. 6, 2003, pp. 68–72. [31] Swarm Foundation, “Swarm: The decentralized storage and communication system for a sovereign digital society,” https://www.ethswarm.org/swarm-whitepaper.pdf, 2020, accessed: 2024-08-16.