arxiv: 2605.02824 · v1 · submitted 2026-05-04 · 💻 cs.CR

Recognition: 2 theorem links

· Lean Theorem

InsureConnect: Blockchain and Digital Identity for the Property Insurance Market

Jo\~ao Eduardo Travassos , Miguel Correia

Authors on Pith no claims yet

Pith reviewed 2026-05-08 18:14 UTC · model grok-4.3

classification 💻 cs.CR

keywords blockchainself-sovereign identityproperty insurancesatellite imageryHyperledger Fabricverifiable credentialsIPFSdisaster recovery

0 comments

The pith

InsureConnect integrates blockchain, self-sovereign identity, and satellite imagery to enhance property insurance transparency and auditability after disasters.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper presents InsureConnect, a prototype system for handling property insurance after natural disasters. It registers user identities and contracts using decentralized identifiers and verifiable credentials on a permissioned blockchain while keeping property images in off-chain storage. Satellite imagery helps validate damage claims, and chaincode manages access and signatures. Tests with up to 3000 concurrent requests show the system keeps throughput rising even as latency grows and some connections drop. A reader would care because the approach could make claims processing more verifiable and less open to disputes.

Core claim

InsureConnect is a blockchain-based system for property-insurance workflows after natural disasters that 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 the permissioned blockchain. Users interact through a desktop application, chaincode enforces role-based access control and validates digital signatures. The prototype was evaluated under concurrent request loads from 50 to 3000, and the results show it sustains increasing 0,

What carries the argument

InsureConnect prototype that integrates SSI with DIDs and VCs for identity registration, Hyperledger Fabric permissioned blockchain with chaincode for role-based access and signature validation, IPFS for off-chain storage of property images, and satellite imagery to support damage claim validation.

If this is right

The system registers identities, insurance contracts, and damage claims with improved transparency, authentication, and auditability.
The prototype sustains increasing throughput under concurrent request loads from 50 to 3000.
Latency rises and dropped connections appear at higher concurrency levels.
Chaincode enforces role-based access control and validates digital signatures for all records.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

The same integration of digital identities and evidence storage could apply to other insurance types that rely on verifiable external data.
Permissioned blockchains may limit full decentralization but could ease regulatory compliance for insurers.
Satellite-based damage assessment might shorten claims timelines by reducing the need for immediate physical inspections.
Performance at 3000 requests suggests the design is viable for regional rather than global-scale events without further tuning.

Load-bearing premise

Satellite imagery combined with digital signatures will reliably and accurately validate property damage and user identities in real disaster scenarios without significant errors, security failures, or adoption barriers.

What would settle it

Running the system on actual post-disaster satellite images and claims data and finding frequent mismatches between assessed damage and verified claims or repeated signature validation failures.

Figures

Figures reproduced from arXiv: 2605.02824 by Jo\~ao Eduardo Travassos, Miguel Correia.

**Figure 2.** Figure 2: INSURECONNECT architecture INSURECONNECT 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 thr… view at source ↗

**Figure 3.** Figure 3: INSURECONNECT 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 cli… view at source ↗

**Figure 5.** Figure 5: BPMN diagram of the insurance contract creation/update view at source ↗

**Figure 6.** Figure 6: BPMN diagram of the lifecycle of a claim view at source ↗

**Figure 7.** Figure 7: INSURECONNECT’s operations diagram TABLE I ERROR 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 0 0 0 0 0 100 0 0 0 0 0 250 0 0 0 0 0 500 0 0 0 0 0 1000 0 0 0 0 0 1500 0 0 0 0 0 2000 0 0 0 0 0 2500 0 12 12 16 20 3000 0 16 16 20 30 0 500 1,000 1,500 2,000 2,500 3,000 0 5 10 15 2… view at source ↗

**Figure 8.** Figure 8: Latency & throughput of the create DID documents function view at source ↗

**Figure 9.** Figure 9: Latency & throughput of the create insurance contract function view at source ↗

**Figure 12.** Figure 12: Latency & throughput of the update claim function view at source ↗

read the original abstract

This paper presents InsureConnect, 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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

InsureConnect is a clean but incremental prototype that wires up known blockchain and identity tools for post-disaster claims, with load-test numbers that stop short of validating the satellite damage step.

read the letter

The main thing to know is that this paper builds a working prototype for registering insurance contracts and damage claims on Hyperledger Fabric, using DIDs, VCs, and IPFS for off-chain images, then reports throughput and latency under synthetic loads up to 3000 concurrent requests. It does not introduce new primitives or algorithms; it applies established pieces to the property-insurance workflow after natural disasters. The architecture description is clear and the role-based access control in chaincode looks straightforward. The load-test results are concrete enough to show the system does not collapse immediately under moderate concurrency, which is useful for anyone who needs to size a permissioned ledger for similar claim volumes. That said, the central promise of improved transparency and auditability for damage claims rests on an untested assumption about satellite imagery. The abstract and evaluation section give no pipeline details, no ground-truth dataset, no accuracy numbers, and no end-to-end experiment that checks whether the imagery plus signatures actually produce reliable damage assessments. Without that, the transparency benefit stays aspirational. Security analysis is also absent beyond basic signature validation. The work is aimed at practitioners building blockchain applications in insurance or at applied-systems venues that accept prototypes with performance data. It is coherent on its own terms and shows honest engineering effort, so it deserves a serious referee rather than a desk reject. I would send it out for review in a blockchain or fintech systems track, but I would flag the missing damage-validation evidence as the main point for authors to address.

Referee Report

3 major / 1 minor

Summary. The paper presents InsureConnect, a blockchain-based prototype that integrates Self-Sovereign Identity (SSI), Decentralized Identifiers (DIDs), Verifiable Credentials (VCs), satellite imagery, Hyperledger Fabric, and IPFS to register user identities, insurance contracts, and post-disaster damage claims. Property images are stored off-chain in IPFS with content hashes and signed records on the permissioned ledger; a desktop application and chaincode enforce role-based access control and signature validation. The only reported evaluation consists of a load test exercising the system with 50 to 3000 concurrent requests while measuring latency, throughput, and dropped connections.

Significance. If the untested assumption that satellite imagery plus digital signatures can reliably validate property damage holds, the architecture could provide a concrete mechanism for transparent, auditable claims processing in disaster insurance. The work demonstrates that a permissioned blockchain can sustain increasing throughput under synthetic concurrency and correctly combines SSI primitives with off-chain storage, which is a modest but useful engineering contribution. However, the absence of any accuracy metrics, ground-truth comparison, or end-to-end validation for the satellite component means the asserted benefits for authentication and auditability remain unsupported.

major comments (3)

[Evaluation section] Evaluation section: the reported load test (50–3000 concurrent requests) measures only blockchain-level latency, throughput, and dropped connections; no section describes the satellite imagery processing pipeline, any ground-truth damage dataset, detection algorithm, or false-positive/negative rates. Without these data the central claim that the system improves transparency and auditability for damage claims cannot be assessed.
[System architecture description] System architecture description: the integration of satellite imagery with VCs for damage claims is asserted but never specified (e.g., how imagery is analyzed, how results are encoded as verifiable claims, or how false detections are handled), leaving the core workflow for post-disaster claims ungrounded.
[Security and validation] Security and validation: no threat model, formal security analysis, or empirical validation of the combined SSI/DID/VC + satellite + Fabric system is provided, despite the paper’s emphasis on authentication and auditability.

minor comments (1)

[Abstract] The abstract states that “the system sustains increasing throughput under load” yet also notes that “latency rises and dropped connections appear at higher concurrency levels”; a single clarifying sentence would remove the apparent tension.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive comments on our manuscript describing the InsureConnect prototype. We address the major comments point-by-point below, clarifying that our focus is on the blockchain integration and system performance rather than comprehensive evaluation of the satellite damage detection component.

read point-by-point responses

Referee: [Evaluation section] Evaluation section: the reported load test (50–3000 concurrent requests) measures only blockchain-level latency, throughput, and dropped connections; no section describes the satellite imagery processing pipeline, any ground-truth damage dataset, detection algorithm, or false-positive/negative rates. Without these data the central claim that the system improves transparency and auditability for damage claims cannot be assessed.

Authors: The load test evaluates the blockchain's ability to handle concurrent requests for identity registration, contract issuance, and claim processing, which supports the auditability claims by showing the system can operate under realistic loads. The satellite imagery processing is an input to the system but not the core evaluated component; we use it to generate claims that are then recorded transparently on the ledger. We will revise the evaluation section to explicitly state the scope and add a discussion on the satellite component's role and limitations. revision: partial
Referee: [System architecture description] System architecture description: the integration of satellite imagery with VCs for damage claims is asserted but never specified (e.g., how imagery is analyzed, how results are encoded as verifiable claims, or how false detections are handled), leaving the core workflow for post-disaster claims ungrounded.

Authors: In the system architecture, satellite imagery is acquired post-disaster, stored in IPFS with hashes on the blockchain, and damage assessments lead to VCs issued by the insurance provider after review. The encoding into VCs includes the claim details and signatures. False detections can be challenged through the audit trail. We will enhance the architecture description with a detailed workflow diagram and explanations in the revised version to ground the claims workflow. revision: yes
Referee: [Security and validation] Security and validation: no threat model, formal security analysis, or empirical validation of the combined SSI/DID/VC + satellite + Fabric system is provided, despite the paper’s emphasis on authentication and auditability.

Authors: Authentication and auditability are achieved through the use of DIDs for identities, VCs for claims with cryptographic proofs, and Hyperledger Fabric's permissioned ledger with chaincode for validation. While we did not include a formal threat model, the design follows best practices for SSI and blockchain security. We will add a security analysis section outlining the assumed threat model and how the components address them in the revision. revision: yes

Circularity Check

0 steps flagged

No circularity: system description and direct measurements are independent of inputs

full rationale

The paper presents a blockchain prototype architecture and reports direct empirical measurements of latency, throughput, and dropped connections under synthetic loads (50–3000 requests). No equations, fitted parameters, predictions, or derivations are present that could reduce to self-definition or self-citation. Central claims rest on the described components (SSI/DID/VC, Hyperledger Fabric, IPFS) and the reported benchmark results rather than any circular reduction. Self-citations, if present, are not load-bearing for the architecture or evaluation.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The paper is a systems-design contribution with no mathematical derivations, fitted parameters, or newly postulated entities. It rests on standard domain assumptions about the security and reliability of the chosen technologies.

axioms (2)

domain assumption Hyperledger Fabric provides secure, permissioned blockchain functionality with enforceable role-based access control
Invoked to support the claim that chaincode can validate signatures and enforce access rules.
domain assumption Satellite imagery can be used to objectively assess property damage for insurance claims
Central to the damage-claim validation workflow described in the abstract.

pith-pipeline@v0.9.0 · 5446 in / 1527 out tokens · 30871 ms · 2026-05-08T18:14:24.127794+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

33 extracted references · 2 canonical work pages

[1]

Bitcoin: A peer-to-peer electronic cash system,

S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008

2008
[2]

Blockchains: How they work and why they’ll change the world,

M. E. Peck, “Blockchains: How they work and why they’ll change the world,”IEEE Spectrum, vol. 54, no. 10, pp. 26–35, 2017

2017
[3]

The path to self-sovereign identity,

C. Allen, “The path to self-sovereign identity,”Life With Alacrity,
[4]

Available: https://www.lifewithalacrity.com/article/the- path-to-self-soverereign-identity/

[Online]. Available: https://www.lifewithalacrity.com/article/the- path-to-self-soverereign-identity/
[5]

Decentralized identifiers (DIDs) v1. 0,

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

2020
[6]

Verifiable credentials data model 1.0,

M. Sporny, D. Longley, and D. Chadwick, “Verifiable credentials data model 1.0,” W3C, Tech. Rep., 2019. [Online]. Avail- able: https://w3c.github.io/vcdata-model/https://www.w3.org/TR/vc- data-model/

2019
[7]

Sporny, T

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

2024
[8]

Untangling blockchain: A data processing view of blockchain systems,

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

2018
[9]

Ethereum: A next-generation smart contract and decentralized application platform,

V . Buterin and Ethereum team, “Ethereum: A next-generation smart contract and decentralized application platform,” 2014-17, white paper

2014
[10]

Hyperledger Fabric documentation,

Hyperledger Fabric team, “Hyperledger Fabric documentation,” 2024, accessed: 2024-10-08. [Online]. Available: https://hyperledger- fabric.readthedocs.io/en/release-2.5/

2024
[11]

IPFS - Content Addressed, Versioned, P2P File System

J. Benet, “IPFS: Content addressed, versioned, P2P file system,”arXiv preprint arXiv:1407.3561, 2014

work page Pith review arXiv 2014
[12]

The state of art, opportunities and challenges of blockchain in the insurance industry: A systematic literature review,

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

2024
[13]

A blockchain and IPFS-based anticounterfeit traceable functionality of car insurance claims system,

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

2023
[14]

INCHAIN: A cyber insurance architecture with smart contracts and self-sovereign identity on top of blockchain,

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

2024
[15]

A gen- eralized framework for designing open-source natural hazard parametric insurance,

C. B. Steinmann, B. P. Guillod, C. Fairless, and D. N. Bresch, “A gen- eralized framework for designing open-source natural hazard parametric insurance,”Environment Systems and Decisions, vol. 43, no. 4, pp. 555– 568, 2023

2023
[16]

A blockchain-based approach for parametric insurance under multiple sources of truth,

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,
[17]

Available: https://doi.org/10.1109/TSC.2023.3296808

[Online]. Available: https://doi.org/10.1109/TSC.2023.3296808

work page doi:10.1109/tsc.2023.3296808 2023
[18]

Privacy-preserving blockchain- enabled parametric insurance via remote sensing and IoT,

M. Hao, K. Qian, and S. C.-K. Chau, “Privacy-preserving blockchain- enabled parametric insurance via remote sensing and IoT,”IEEE Trans- actions on Services Computing, vol. 18, no. 5, pp. 3093–3105, 2025

2025
[19]

Blockchain-based method for spatial retrieval and verification of remote sensing images,

Y . Liu and Y . Chang, “Blockchain-based method for spatial retrieval and verification of remote sensing images,”Sensors, vol. 24, no. 7, 2024

2024
[20]

(2016) Blockchain and land registry

International Council for Accreditation of IT Managers. (2016) Blockchain and land registry. [Online]. Available: https://ica- it.org/pdf/Blockchain Landregistry Report.pdf

2016
[21]

(2020) Land registration using blockchain

Government of India, Ministry of Electronics and Information Tech- nology. (2020) Land registration using blockchain. [Online]. Available: https://blockchain.gov.in/Home/CaseStudy?CaseStudy=LandRegistration

2020
[22]

(2021) Blockchain-based land registry

Borgen Project. (2021) Blockchain-based land registry. [Online]. Available: https://borgenproject.org/blockchain-based-land-registry/

2021
[23]

N. Asia. (2017) Japan to tidy up scattered property records. [Online]. Available: https://asia.nikkei.com/Markets/Property/Japan-to- tidy-up-scattered-property-records

2017
[24]

Title and code: Real estate transaction recording in the blockchain in Brazil (RCPLAC-01),

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

2018
[25]

Blockchain based land registry system using ethereum blockchain,

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

2020
[26]

Smart contract definition for land registry in blockchain,

A. Sahai and R. Pandey, “Smart contract definition for land registry in blockchain,” inIEEE 9th International Conference on Communication Systems and Network Technologies, 2020, pp. 230–235

2020
[27]

Blockchain-based framework for secure and reliable land registry system,

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

2020
[28]

Decentralised land registration and transaction with blockchain and self-sovereign identity,

P. C. Henriques and M. Correia, “Decentralised land registration and transaction with blockchain and self-sovereign identity,” in2025 44th International Symposium on Reliable Distributed Systems (SRDS), DLT4SEC 2025 - International Workshop on DLT for Cybersecurity and Vice Versa. IEEE, 2025, pp. 404–409

2025
[29]

Dhillon, D

V . Dhillon, D. Metcalf, and M. Hooper,The Hyperledger Project. Berkeley, CA: Apress, 2017, pp. 139–149

2017
[30]

In search of an understandable consensus algorithm,

D. Ongaro and J. Ousterhout, “In search of an understandable consensus algorithm,” in2014 USENIX Annual Technical Conference, 2014, pp. 305–319

2014
[31]

Perspectives on the CAP theorem,

S. Gilbert and N. Lynch, “Perspectives on the CAP theorem,”Computer, vol. 45, no. 2, pp. 30–36, 2012

2012
[32]

Incentives build robustness in bittorrent,

B. Cohen, “Incentives build robustness in bittorrent,” inWorkshop on Economics of Peer-to-Peer systems, vol. 6, 2003, pp. 68–72

2003
[33]

Swarm: The decentralized storage and communication system for a sovereign digital society,

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

2020