GeoLedger: blockchain and GIS architecture for trusted emergency incident mapping

Abstract

Most existing emergency management systems are centralized, leaving critical information vulnerable to unauthorized access, manipulation, and single points of failure. Blockchain has been extensively studied as a decentralized means of improving the security, integrity, and auditability of incident data. However, using full incident payloads on the blockchain is constrained by latency, throughput, and storage limits imposed by high-volume incident streams, which hinder real-time visualization and rapid decision-making. This paper presents GeoLedger, a blockchain–GIS architecture for secure, ledger-backed geospatial representation of emergency event data. In GeoLedger, incident data are first normalized by a registration authority before being compacted into signed metadata digests and content pointers anchored to a permissioned ledger. Incident narratives are then stored securely in off-chain repositories. The on-chain records are projected onto a GIS dashboard as interactive geospatial markers, enabling operators to inspect incident types, times, locations, and blockchain transaction identifiers without exposing full incident details to all participants. A prototype utilizing a custom Ethereum-compatible permissioned blockchain and a Python GIS layer was implemented and evaluated using replayed London Fire Brigade incident traces. The results show that GeoLedger attains average latencies of approximately 400 ms for incident-to-visualization and delivers a 20%–30% increase in sustained throughput at high incident rates compared with full-payload centralized and blockchain approaches. GeoLedger also yields significant reductions in the on-chain communication and storage required by committing metadata alone. The security analysis demonstrates that GeoLedger enhances integrity, accountability, and privacy against forgery, tampering, and unwarranted disclosure, supporting its deployment in large-scale, time-critical emergency operations.

1 Introduction

Recent advances in technology have reshaped the way organizations plan and handle emergency responses today, relying heavily on continuous data streams, intelligent analytics, and interconnected systems to support rapid decision-making when people and infrastructure are under threat. Studies have also shown that the use of emergency management platforms significantly improves resource allocation, coordination, and communication between responding agencies (Wibowo et al., 2025). Furthermore, the adoption of new technologies, including IoT sensors, satellite links, and artificial intelligence-based analysis, provides an additional opportunity for early risk detection and enhanced emergency responses during both natural and human-made emergencies (Khashan, 2025a). However, these technologies can only provide real value when the data pipelines are secure, scalable, and dependable, especially in high-stress scenarios, where system failures can lead to a significant negative impact on response efforts (Khan et al., 2023). Typically, traditional crisis and emergency management systems utilize centralized architectures, where a single authority or server maintains all the critical data and controls the core operational functions (Khashan, 2025b).

Research on emergency communication infrastructures has demonstrated that centralized emergency systems are more susceptible to service disruptions and cyberattacks during large-scale emergencies, specifically when communication networks are highly strained (Carreras-Coch et al., 2022). Moreover, central authorities have privileged access, leading to an increased attack surface for adversaries attempting to compromise event records or manipulate emergency response coordination (Khashan et al., 2015). Attackers may exploit systemic chaos during such conditions; therefore, it is imperative to ensure the authenticity and reliability of situational information to prevent systemic breakdowns and misinformation (Khashan et al., 2023a).

These incidents illustrate that unauthorized access to operational dashboards can disable critical services and corrupt incident logs. Delayed or altered information during emergencies, such as wildfires, floods, or public health emergencies, could put lives at risk through misdirection or concealment of critical threats (Almheiri et al., 2025). The inherent vulnerabilities of emergency management platforms, combined with insufficient authentication controls, increase the risk of insider threats, data manipulation, and denial-of-service attacks. Developing systems that can absorb cyber risks and remain operational while subjected to physical, technical, and strategic attacks has become a primary necessity for today’s emergency management infrastructure (Djenna et al., 2021).

The use of geographic information systems (GIS) is rapidly advancing as a key component of disaster operations by providing tools for real-time spatial mapping, risk visualization, and decision support in emergency response situations (Franchi et al., 2023). GIS platforms collect environmental data, field sensor feeds, and operational intelligence to develop dynamic dashboards for identifying high-priority zones, tracking hazard propagation, and effectively deploying resources (Cao et al., 2023). For example, GIS-based flood monitoring systems can integrate hydrological sensor data, weather forecasting models, and evacuation route maps to provide timely situational awareness to first responders (Chatrabhuj et al., 2024).

Distributed data environments increasingly rely on blockchain technology to keep data exchange transparent and trustworthy. This approach eliminates the need for central control of data by maintaining a decentralized ledger that allows any participant to verify whether a transaction has been altered. These features provide value to multi-agency emergency management settings, where such applications require authentic, auditable data, and trusted information between agencies (Khashan, 2024). Smart contracts automate rules based on predetermined conditions, such as access controls and event validation, without requiring human intervention. Recent research has examined the use of blockchain to ensure that both operational data streams and sensor data remain unaltered during transmission over insecure channels (Achour et al., 2025).

Despite the benefits provided by blockchain-based solutions, such architectures face practical limitations in real-time emergency settings. Consensus algorithms introduce latency, and many systems struggle to handle the data volumes required for emergency management operations that depend on rapid, time-critical decision-making (Tong et al., 2025). In addition, the storage requirements of such ledgers present further issues related to scalability, particularly when dealing with large, continuous data streams. Many resource-constrained emergency environments and field infrastructures lack sufficient computational and energy capacity to participate in blockchain consensus protocols without causing premature exhaustion of available resources and degradation of service continuity (Khashan et al., 2023b).

The remainder of this paper is organized as follows. Section 2 provides an overview of the related work. Section 3 explains the proposed architecture. Section 4 discusses the analysis and experimental results. Finally, Section 5 concludes the paper.

2 Related work

GISs have long served as critical tools for providing real-time awareness and for guiding decision-making in emergency situations, thereby underscoring the role of these technologies in improving disaster preparedness and response. Aggarwal et al. (2024) demonstrated that GIS and remote sensing can help reduce disaster risk by enabling earlier detection of hazards and supporting more effective early warning systems. Leeonis et al. (2024) developed a GIS-based system to analyze flash-flood management; the study highlighted the analytical capabilities provided by GIS and how centralized data control and limited interoperability negatively affected operational responsiveness. Park et al. (2024) utilized spatial autocorrelation and routing models to evaluate the efficiency of emergency dispatch in Seoul and concluded that centralized control structures slow response times in high-density areas. Nayyeri et al. (2024) introduced a model using fuzzy logic and spatial analysis to locate disaster management bases. Although the results indicated improved coverage, the model relied heavily on centralized data repositories.

Although GIS-based crisis and emergency management systems can improve both visualization and situational awareness, their reliance on centralized architectures makes them vulnerable to failure or manipulation during emergencies. Several studies have investigated the use of blockchain technology to enhance emergency management systems by addressing security and coordination issues. For instance, the study by Wang and Liu (2023) addressed interagency coordination challenges by proposing a distributed ledger–based framework for secure and auditable information exchange among disaster response organizations. The results showed enhanced interoperability and reduced data fragmentation when multiple agencies were involved in disaster response operations. Wang et al. (2024) developed a consortium blockchain-based model for emergency logistics traceability, which employed a combination of genetic and simulated annealing algorithms to optimize supply allocation in emergency relief. Diallo et al. (2024) presented a blockchain-based decentralized incident-reporting model that allows urban communities to submit verified crisis information directly through mobile interfaces. The model enhances transparency and accountability while reducing dependence on centralized control.

Broader analyses of blockchain adoption during emergencies provide insights into trends and research gaps. Shevchuk et al. (2025) conducted a bibliometric analysis to identify transparency, efficiency, and trust as dominant research themes but observed that most implementations remain conceptual. Peker et al. (2023) integrated blockchain with intuitionistic fuzzy multi-criteria decision-making to evaluate disaster governance models. The study reported improvements in accountability with blockchain but noted its limited applicability in live emergency scenarios. These findings collectively indicate that blockchain can ensure trustworthy record-keeping and cross-agency transparency; however, few studies have integrated real-time geospatial intelligence or addressed the performance issues associated with high-volume data streams (Khashan et al., 2025).

With the increasing emphasis on geospatial data management, several research efforts have been initiated to explore blockchain–GIS integration for securing spatial information. In particular, Zou et al. (2023) introduced a multilevel blockchain–GIS architecture to manage remote sensing data security by storing raw imagery off-chain using the Interplanetary File System (IPFS) and anchoring the hashed metadata on the Ethereum platform. While the method was effective in providing transparency and integrity for geospatial data, it nevertheless encountered scalability limitations with large, high-frequency spatial datasets. A similar study by Chafiq et al. (2024) examined blockchain’s potential for geospatial data sharing and interoperability, where the resulting solution complied with the standards established by the Open Geospatial Consortium. However, both approaches focus on static or archival spatial datasets, rather than on the dynamic, event-driven mapping that is often required in emergency environments.

The integration of blockchain with geospatial systems has also been explored in both urban and collaborative contexts. Farnaghi and Mansourian (2020) presented a blockchain-based participatory GIS model for Ethereum that secured citizen input through smart contracts. Their findings demonstrated blockchain’s potential to enhance transparency and accountability in spatial decision-making. The study by Zhang et al. (2022) proposed a blockchain- and smart contract–based architecture that enables the secure management of construction site information, ensures document control, and facilitates transparent stakeholder collaboration. This approach demonstrates the architectural similarities relevant to spatial data coordination in real-time crisis mapping. Mia et al. (2022) extended this approach by combining deep learning-based flood susceptibility mapping with a blockchain-enabled coordination platform. Their CNN–RF ensemble achieved high predictive accuracy for hazard zoning, and the blockchain layer enabled decentralized information exchange between help-seekers and responders. This hybrid design represents an early practical application of blockchain technology for geospatial crisis coordination.

A recent study by Yue and Shyu (2024) introduced an artificial general intelligence (AGI)-based intelligence fusion network that uses a blockchain to secure shared data. This shows how combining AI-driven forecasting with decentralized data sharing can improve early warning and coordination in governmental emergency management. Hafeez et al. (2024) presented a blockchain-enabled UAV coordination framework for post-disaster communication networks. The framework employs a hybrid delegated proof-of-stake (PoS) and practical Byzantine fault tolerance (PBFT) consensus mechanism. Although the results showed improvements in security and coordination across multiple agencies, its focus remained on UAV communication rather than on comprehensive emergency mapping. Recent work has also extended blockchain application to evacuation coordination in zero-trust outdoor environments through a hybrid-voting design for hiking trails and mountainous terrain (Kim et al., 2025).

Recent studies have also examined hybrid blockchain-edge architectures to reduce delay and distribute trust closer to data sources. Khashan and Khafajah (2023) presented a hybrid centralized and blockchain-based authentication architecture for heterogeneous IoT systems, which showed how distributed trust can be combined with practical deployment efficiency in constrained environments. Nguyenz et al. (2024) reviewed the architectural, security, and application dimensions of blockchain-enabled edge IoT systems, while Rashid et al. (2025) surveyed blockchain-based task placement and resource management in edge computing. Recent studies based on Deep Reinforcement Learning (DRL) have also addressed routing optimization in dynamic wireless and IoT environments (Suresh et al., 2024; Rao et al., 2024). However, these studies mainly focus on blockchain-edge integration or routing efficiency, whereas GeoLedger addresses trusted emergency incident mapping through permissioned blockchain validation, protected off-chain payload handling, and GIS-linked visualization. This distinction is important because the present work is driven by event integrity, auditability, and cross-agency geospatial coordination, rather than by route optimization or edge-side forwarding efficiency.

Despite the advancements made to date, blockchain-based emergency management models have several limitations. The primary challenges arise from latency and storage requirements, as well as from the inability to support real-time processing of high-volume spatial data streams. Most schemes typically employ either private or consortium blockchains to achieve better performance; however, many approaches reintroduce centralized control or limit broader access to the network. Additionally, the interoperability between blockchain protocols and GIS standards remains limited, and few studies have explicitly addressed standardized geospatial data exchange. Even in participatory or UAV-focused blockchain models, the ability to integrate spatial data visualization, interagency coordination, and validated event logging into a single cohesive system has not yet been realized.

The proposed GeoLedger framework builds on these insights by integrating ledger-based data integrity with GIS-supported emergency mapping. It records verified emergency event metadata in a decentralized, immutable permissioned ledger and associates these records with spatial entities within a GIS environment. This enables reliable visualizations and cross-agency information sharing without a central authority.

3 Proposed architecture

The proposed GeoLedger framework is built on a hybrid architecture that brings together decentralized trust from a permissioned blockchain and the spatial intelligence of a GIS for use in emergency management operations. The proposed framework overcomes the disadvantages of centralized approaches by supporting lightweight delegated validation, metadata-only sharing with the GIS layer, and timely visualization of event data among stakeholders in distributed agency environments. The blockchain layer is implemented as a custom Ethereum-compatible permissioned prototype. It retains Ethereum-style transaction handling in a permissioned environment, while block admission and finalization are controlled by the DVG through the quorum-based procedure defined in this work.

GeoLedger was designed based on the principle that the effectiveness of an emergency response effort depends on having access to trusted information and situational awareness. All events created by sensors, field units, or authorized operators are validated by DVG using signed digests and content pointers. Upon validation, they are represented as dynamic spatial entities within the GIS platform and linked by transaction IDs for audit purposes, whereas payloads remain off-chain and encrypted. A continuous operational map that provides a means for rapid situation assessment and efficient resource allocation is created by combining blockchain and GIS. Figure 1 illustrates the overall architecture of the proposed GeoLedger model. Its dual-layer structure enables the blockchain validation and geospatial visualization processes to operate as complementary components.

FIGURE 1

The two layers are interconnected through a metadata-only, low-latency synchronization interface that supports real-time coordination without introducing significant processing delay. In the prototype, verified event metadata are exported to the GIS layer through a lightweight point-feature schema. This schema preserves the transaction identifier, node identifier, location, incident type, timestamp, and content pointer. These fields provide a stable exchange structure for synchronization across participating systems while keeping the on-chain record compact.

At the GIS exchange layer, the representation is GeoJSON-compatible, which supports practical interoperability with common agency-side geospatial tools, even though the digest itself remains a compact ledger object rather than a full geospatial document. In practical terms, each synchronized incident is exposed as a feature-level exchange object in which geometry is derived from the reported location and the associated properties carry the transaction identifier, node identifier, incident type, timestamp, and content pointer. This gives downstream GIS systems a stable application-layer structure for import, filtering, and visualization without requiring them to interpret blockchain-specific block or consensus metadata. This also supports standards-aligned data exchange with external GIS and emergency response systems at the application layer, although the present prototype does not implement a full Open Geospatial Consortium (OGC) service stack.

In practical deployment, GeoLedger can be introduced incrementally alongside existing emergency reporting and GIS platforms, so current operational systems remain in place while ledger-backed validation and metadata synchronization are added as overlay functions. For larger or multi-agency adoption, this requires a clear governance model for validator admission and oversight, routine certificate renewal and revocation procedures, and phased scaling of validation and dashboard policies as incident load increases. Symbols used throughout this study and their respective definitions are shown in Table 1. The following subsections present additional details about each layer of the proposed GeoLedger model.

3.1 Node registration and emergency event validation

This section describes the procedures for node registration and emergency event validation, and establishes the trust and intake pipeline that precedes any blockchain processing. The registration authority (RA) operates as a trusted authority that initiates a registration process with authorized parties, issues digital certificates, and maintains revocation status. A node, denoted , can be a constrained sensor, mobile responder, UAV platform, or command station. During registration, the RA binds a network identifier to a public-private key pair () and issues a certificate that encodes the node’s role and validity window. The RA records the enrollment timestamp and maintains revocation status, so that suspended credentials are immediately refused by intake services. In GeoLedger, the RA is not part of the block validation or block finalization path. Its function is limited to admission control, certificate issuance, key-possession verification, and revocation management. The integrity of these operations is protected through signed administrative records, bounded certificate validity periods, and auditable registration and rekeying logs. To improve service continuity, the RA state is replicated to authorized standby administrative instances so that certificate lookup and revocation checks remain available during failure recovery. This design keeps the RA outside the consensus path while reducing the operational impact of a single administrative failure. The registration record is defined in Equation 1.

Let denote the proof-of-possession signature produced by node . The node proves possession of its private key by generating a digital signature over a challenge derived from () with . The RA verifies the signature using the corresponding public key , confirming authenticity without involving encryption or decryption operations, as shown in Equation 2.

When rekeying is performed, the RA records both the previous and new keys in its audit log to maintain traceability. Successful verification prevents spoofing and enables admission to the permissioned network.

GeoLedger does not assume that blockchain validation alone can prove that an originally reported coordinate is physically correct. Instead, trust in the initial coordinate depends on certified reporting devices that pass through the registration process. Before ledger admission, the intake layer applies freshness checks, geofencing rules, duplicate suppression, and cross-record consistency checks. These controls reduce the effect of GPS spoofing and other oracle-side manipulation at the reporting boundary. However, the correctness of the first capture step still depends on the trustworthiness of the reporting device and the operating environment. For that reason, GeoLedger treats initial coordinate capture as a guarded reporting-boundary problem. Reports whose coordinates conflict with the declared area of operation, freshness window, or surrounding incident context can be rejected or flagged before ledger admission, even when the submitting node itself remains cryptographically valid.

The node submits an event as a structured tuple that includes origin, location, type, timestamp, and payload, as shown in Equation 3. Here encodes geographic coordinates, is the incident class, is the event timestamp, and represents the event’s content.

To minimize bandwidth usage and the cost of validating event integrity, the node submits only a compact message containing the event digest computed using the hash of the event , a content pointer referencing the protected payload (encrypted or stored off-chain), and the signed encapsulation generated with the node’s private key , according to Equation 4.

The payload is not transmitted during intake; authorized access to the protected content is deferred by policy through . The off-chain repository is implemented as a protected replicated storage service that maintains encrypted incident payloads outside the blockchain layer. This design also supports data minimization by limiting on-chain exposure to operational metadata while keeping sensitive incident narratives accessible only through authorized retrieval paths.

Each is bound to one encrypted payload object and its associated storage record. In this design, acts as a hash-linked content pointer recorded in the ledger metadata. Any later modification to the stored payload causes a digest mismatch during verification against the corresponding on-chain record. When authorized retrieval is requested, the client resolves to the protected storage object, retrieves the encrypted payload, and verifies its digest against the blockchain-anchored metadata before release.

As a result, the reporting node is limited to local hashing, signing, and compact metadata transmission, while the heavier quorum validation and block-construction workload remains on the validator side. This separation reduces the computational burden placed on field units and is consistent with deployment in resource-constrained reporting environments, although direct power profiling was outside the scope of the present evaluation. Field units therefore do not participate in committee voting, block assembly, or multi-party confirmation exchange, which keeps the edge-side workload bounded to the incident preparation path rather than the consensus path.

Access control is enforced through authenticated role-based retrieval rules. Therefore, general participants can view exposed metadata such as incident type, time, location, and transaction identifier through the GIS interface, while only authorized entities with the required privileges can retrieve and decrypt the full incident narrative. Replicated storage backends support service continuity and reduce the risk of data loss during repository failure. In the prototype, this off-chain layer is realized as a private replicated storage service under administrative control rather than a public content-sharing network. Payloads remain encrypted at rest, and decryption is permitted only after authenticated role verification against the access-control policy associated with the requested incident record. Each retrieval request is therefore evaluated against both the requester role and the incident-specific access policy before the protected object is released. Because the stored object remains bound to its recorded content pointer and digest, any unauthorized substitution or later tampering at the storage layer is detectable during verification against the corresponding on-chain metadata. Algorithm 1 illustrates the node registration and emergency incident event validation processes.

3.2 Blockchain architecture and consensus operations

In this section, we outline the blockchain architecture and the workflow process for validating events, coordinating committees, and finalizing blocks. The pre-consensus path ingests lightweight digests and content pointers. The DVG formation and delegated voting enable deterministic consensus with full auditability via hash chaining and Merkle commitments.

First, the validation module evaluates each candidate event for policy compliance prior to committee processing. Gate checks include the structural completeness of the event, timestamp freshness within the operational window, geofence membership for the active area, duplicate-digest detection against a recent cache, and certificate validity at the event time. All passed transactions are then forwarded to the DVG. Let denote the size of the DVG committee, denote the number of validator acknowledgments received for a transaction , and be the quorum threshold. Each validator in the committee verifies the origin integrity of the transaction by validating the digital signature against the submitted digest–pointer pair using the sender’s public key; acknowledgments are counted until a quorum is reached. A transaction is accepted when both integrity and quorum hold:

This confirms that the signature verified correctly under the given and that the original message was successfully recovered from the digest–pointer pair ().

Admitted transactions are batched by a proposer and put together as a block at height . Now, let denote the new block whose header includes a block identifier , a predecessor link , a Merkle summary , a block timestamp , and a validator attestation :

The height increases monotonically with each committed block, which yields a total order over blocks.

Let be the number of transactions included in , indexed , …, . The Merkle root commits to the set, enabling efficient inclusion proofs without retrieving the full block:

Standard Merkle paths enable verification of a specific within without retrieving the full block, which keeps the consensus path lightweight, as each contains only a signature, a digest, and a pointer.

Let denote byte length and the offered transaction rate (tx/s). The approximate transaction size and the per-round message volume scale according to Equations 8, 9 respectively.

Here, is the signature length, which depends on the chosen signature scheme (e.g., ECDSA), while is the consensus traffic per round.

The intake predicate is:where the predicates , , , and implement, respectively, schema conformance, time-window freshness, geofence membership, and recent-digest replay detection.

If identical digests arrive with differing pointers, a conflict is raised; the earliest valid is preferred while both pointers are logged for forensics. Let ) capture this condition; admission to consensus becomes:

The term prevents divergent payload pointers from propagating, while preserving evidence for audit.

Committee formation draws from a permissioned validator pool with . Each candidate is assigned a reliability score , and selection is proportional to this score to limit long-term collusion. Only certified and non-revoked validators are eligible for DVG selection. The reliability score is computed from auditable validation records maintained by the system. Its main inputs include successful participation in earlier rounds, timely response to validation requests, certificate compliance, and the absence of invalid or conflicting attestations. The score is not based on self-declared information. Score updates are bounded and are recomputed from signed historical records, which reduces the chance of score manipulation. DVG members are selected through randomized, score-weighted sampling. The random seed is derived from the previous committed block hash and the current round identifier, so the selection result can be verified by authorized participants and cannot be fixed in advance by a single validator. Fault tolerance conditions satisfy:where bounds the number of Byzantine faults tolerated per round. Committees rotate periodically by block count or a time window to reduce capture risk and balance load. At the end of each block window or time interval, a new DVG is formed from the eligible validator pool under the same selection rule. This rotation limits prolonged committee concentration and reduces the risk of repeated control by the same validator subset. Validators that show persistent misbehavior or repeated non-participation are penalized through score reduction and may be removed from future committee selection through administrative certificate revocation. GeoLedger does not adopt a token-based reward scheme.

In operational deployment, this governance model also covers validator admission, key lifecycle control, committee oversight, and revocation decisions under administrative authority. Instead, continued validator eligibility and institutional accountability within the permissioned governance model provide the main incentive for honest participation. If a selected committee cannot reach quorum because a large number of validators become unavailable during a major disruption, the pending candidate set is returned to the admission queue and a replacement DVG is formed from the remaining eligible validator pool under the same randomized score-weighted rule. This fallback re-election step allows validation to resume without depending on a fixed committee during prolonged outage conditions. Re-election is triggered only after the current round fails to satisfy the quorum condition within the allowed liveness window, and the new committee is drawn only from validators that remain certified, reachable, and non-revoked at that time. Partial approvals from the failed round are not carried forward, which prevents incomplete or stale committee state from influencing the next validation round.

The proposer multicasts the candidate set; each validator performs the check in Equation 5 and returns an acknowledgment. Within the DVG, consensus follows a lightweight quorum-based delegated voting procedure. The proposer distributes the candidate metadata set to the committee, and each selected validator verifies the digest, pointer, and signature before issuing its vote. A transaction set is accepted only after the required quorum is reached. The end-to-end validation delay and round message complexity are defined in Equations 13, 14 respectively. covers cryptographic verification, covers the message-exchange time, is the quorum acquisition time, and counts one proposal plus acknowledgments. After quorum, the proposer finalizes as specified in Equations 6,7. The committed footprint remains compact by storing the encapsulations (), identifiers, timestamps, and . With header size and transactions, the block size is estimated in Equation 15.

Therefore, the header dominates when attestations are large, while the transaction sum dominates at high throughput. For liveness control, each delegated consensus round is bounded by a vote-collection timeout and a proposal/finalization timeout . If the proposer does not distribute the candidate set within , or if quorum is not reached within , the current round is terminated and the pending candidate set is returned to the admission queue for the next eligible committee. Because committed records are treated as append-only, GeoLedger does not support silent event reversion after finalization. Instead, error correction or dispute handling is performed through a new superseding transaction that references the original , preserves the audit trail, and records the corrected or contested status without removing the earlier entry. Algorithm 2 outlines the delegated consensus and block-construction procedure described in this section.

3.3 Spatial data visualization and GIS synchronization

The GIS layer renders a live operational picture from verified blockchain events while keeping synchronization light and privacy-aware. It receives only minimal, trusted metadata from the ledger interface and projects them as interactive geospatial entities. Once a block is finalized, the ledger updates its state and exposes verified event metadata via an interface optimized for GIS synchronization. For each committed transaction with identifier , the synchronization component exposes , where the references the full encrypted or off-chain payload. The visualization engine ingests these attributes into a spatial store and updates the map without fetching the full content unless explicitly requested by an authorized user. The projection from confirmed ledger records to a map object is defined in Equation 16:

Here, denotes the GIS-renderable object instantiated from the confirmed event , with its verified attributes bound to a fixed visual symbol and attribute pane.

Let t be the current dashboard reference time and the operational look-back window. The active event set at time t is defined in Equation 17.

The set is recomputed on each refresh using the same policy window defined for operations. Spatial indexing uses an R-tree over for near-constant-time neighborhood queries. Styling is driven by incident class and recency; for example, a view function ) can be scaled using the event type and its age to foreground recent, high-priority events.

Synchronization follows an event-driven model. When a block is finalized, the ledger issues a notification to the GIS synchronization module, which retrieves the newly confirmed set and applies idempotent updates keyed by . Let denote the total dashboard refresh latency, with connector fetch/write time, map redraw time, and the validation delay from Equation 13. The resulting end-to-end refresh time is:

To prevent marker clutter at higher densities, the GIS aggregates nearby events into cluster markers. Let denote the set of events assigned to cluster , and let each event carry a consensus-derived confidence weight defined by . Let the cluster weight , centroid , weight spatial sum , and size be defined as given in Equation 19.

Weights inherit delegated-consensus support; higher pushes toward 1, visually prioritizing high-confidence events. The cluster’s visual summary presents , the dominant incident over , and the temporal span [max , min ] for . Styling is driven by incident class and recency so that recent, high-priority events are foregrounded in the map view.

For spatial filtering and prioritization, let denote a user-specified polygonal area of interest and be a severity cutoff. Here, denotes a normalized policy-based or external model-based score used for display prioritization in the GIS layer. It is not a reward term and is not produced by a reinforcement-learning process. The displayed set is given in Equation 20.

The prioritization used in the GIS layer is rule-based and operational, and the proposed framework does not include a trainable reward-driven controller or reinforcement-learning component. To track load on the dashboard, the operational throughput is computed as an arrivals-per-refresh rate (), as defined in Equation 21:where is the elapsed wall-clock time between the current and previous refresh time. This metric can trigger adaptive strategies: shorten , raise , or increase clustering sensitivity to maintain stable rendering performance during surges. Algorithm 3 enumerates the operational steps that implement the processes detailed in this section.

4 Results and analysis

This section evaluates GeoLedger using an emergency incident dataset replayed as a realistic workload. The focus is on assessing whether the proposed system supports low-latency emergency mapping suitable for operational response while providing its validation, auditability, and lightweight GIS synchronization capabilities.

4.1 Experiment settings

The evaluation was carried out on a GeoLedger prototype that combined a blockchain validation layer with a GIS visualization layer. The prototype ran on a workstation running with a 64-bit operating system with an Intel Core i7-8655U CPU (1.90 GHz, 8 MB cache) and 16 GB of RAM. All processes, including node registration, event intake, delegated validation, and GIS synchronization, were handled by the prototype implementation. The consensus path and block-formation logic, together with the GIS interface module and clustering logic, were implemented according to the GeoLedger system design. The evaluated prototype used the custom Ethereum-compatible permissioned ledger described in Section 3. Web3 libraries were integrated to emulate Ethereum-style transaction submission and block confirmation within a controlled prototype environment. Network delay was synthetically introduced at the validator message-exchange layer to simulate inter-node communication latency rather than applying delay at a single execution node. The GIS front-end relied on a mapping framework to offer interactive geospatial rendering and event clustering.

The experiments used a recent public release of the London Fire Brigade (LFB) incident records, obtained from the London Datastore (London Fire Brigade, 2023). The resulting cleaned subset contained 8,897 incidents from Greater London and retained event time, incident category, and geographic location for replay and spatial visualization. Only incidents from Greater London and within the most recent 30–60 days were included in order to reflect live operational workloads. Rows with null or ill-formed timestamps, missing categories, or invalid geocoordinates were removed.

Duplicate incident reports were dropped using a composite key of timestamp, location, and category. Timestamps were stored in a common ISO-8601 date–time format, location data were expressed in the WGS-84 latitude/longitude coordinate system, and each type of incident was mapped to a single label set for subsequent mapping and analysis. These records served as the basis for all experiments in this section. Figure 2 displays the distribution of incidents used in the study. Each record in the dataset is mapped to the event tuple , where only the metadata required by GeoLedger are injected into the blockchain path. During replay, the incident stream is driven at different offered rates (events/s) and fed into the intake pipeline, where events are checked against the validity predicates in Equations 10, 11, admitted into a DVG committee, and batched into blocks according to the consensus procedure.

FIGURE 2

The evaluation was conducted in a controlled single-host prototype environment, while inter-validator communication delay was emulated at the message-exchange layer. The replay process converts the cleaned historical records into a time-controlled input stream with configurable offered rates, so multiple incidents can be injected concurrently to represent low-, medium-, and high-load conditions. In this setting, the offered rate denotes the number of incident events submitted to the intake pipeline per second. The present evaluation therefore reflects controlled replay-based incident variability derived from the cleaned LFB records rather than a full field deployment with heterogeneous network links, mobile units, or site-specific operational constraints. The tested workload range from 10 to 300 events/s was used to examine low-, medium-, and high-intensity incident conditions under a common prototype configuration, while node heterogeneity and wide-area deployment diversity were not modeled separately in the present study. Once a block is finalized, the corresponding metadata are exported to the GIS layer as objects via the synchronization interface, and the map is refreshed according to Algorithm 3. The same environment and workload are used for all performance criteria reported in the following subsections.

4.2 Performance evaluation

The performance of GeoLedger is evaluated with respect to criteria that are central to real-time emergency management: (i) end-to-end event-to-visualization latency, which measures how quickly validated incidents appear on the GIS dashboard; (ii) sustained throughput as the incident arrival rate increases; and (iii) the impact of blockchain processing on GIS refresh behavior and operator-facing responsiveness.

4.2.1 End-to-end latency

The first evaluation criterion focuses on end-to-end event-to-visualization latency, defined as the elapsed time from the creation of an incident event until its marker appears on the GIS dashboard. For each offered event rate (events/s), the LFB incident stream is replayed through the registration, delegated validation, and GIS synchronization pipeline, and the overall refresh delay is calculated by in Equation 18 is sampled over multiple blocks. Two statistics are used to describe performance: the median latency, representing the typical delay perceived by operators, and the 95th percentile (P95), capturing tail behavior under bursty conditions. The resulting values are summarized in Figure 3.

FIGURE 3

GeoLedger’s latency increases slowly in response to increasing incident rates from 10 to 300 events/s, as shown in Figure 3. At a rate of 10 events/s, the median and P95 latencies are approximately 228 ms and 296 ms, respectively. This represents the baseline overhead of validation, block commit, and map refresh. As the rate increases to 50 and 100 events/s, the median latency remains around 260 ms and 300 ms, with P95 values of about 338 ms and 390 ms, respectively. Under the highest tested load of 300 events/s, the median latency is approximately 460 ms and the P95 remains below 600 ms. Taken together, these results indicate that latency increases gradually with the incident rate and remains below one second across all tested loads, suggesting that GeoLedger can sustain urban-scale emergency workloads while keeping event visualization delays within sub-second bounds acceptable for operational dashboards.

4.2.2 Throughput

Throughput is evaluated as the number of incidents per second that are fully processed and committed under different levels of concurrent load. Using an incident stream derived from the LFB dataset, the offered rate is varied from 10 to 300 events/s. For each rate, the effective throughput is measured for the proposed GeoLedger system and benchmarked against two representative full-payload baselines: a centralized microservice-based emergency management backend study in Ovando-Leon et al. (2022) and a blockchain-based emergency management scheme that records complete incident payloads on chain study in Ghani et al. (2025).

For comparison fairness, both baselines were evaluated under the same replayed incident workload and host environment used for GeoLedger. The centralized baseline was treated as a single-server backend that parses the complete incident record, executes application logic, and commits the full payload to a conventional persistent store together with index and logging overhead. The blockchain full-payload baseline used the same Ethereum-compatible permissioned prototype environment adopted for GeoLedger, but stored the complete incident payload on chain rather than only the metadata digest and content pointer. This keeps the comparison focused on the effect of metadata-only ledgering versus full-payload processing under otherwise aligned execution conditions.

An incident is counted only when validation and state update are completed in the corresponding architecture.

The results in Figure 4 show that all schemes follow the offered rate closely for low and moderate loads, but with different efficiencies. At an offered rate of 150 events/s, GeoLedger achieves a throughput of 142.5 events/s, compared with throughput values of 110 and 120 events/s for the centralized study in Ovando-Leon et al. (2022) and blockchain-based in Ghani et al. (2025) schemes, respectively. When the offered rate reaches 300 events/s, GeoLedger still sustains 180 events/s, whereas the centralized and blockchain baselines level off at 110 and 140 events/s, respectively. These results show that GeoLedger maintains higher effective throughput under increasing concurrent incident rates than both full-payload baselines.

FIGURE 4

Differences in throughput results arise from the average time each architecture needs to process one incident. The centralized scheme spends this time on full-payload parsing, application logic, and database operations in Ovando-Leon et al. (2022), while the blockchain scheme additionally incurs consensus and block-finalization overhead in Ghani et al. (2025). GeoLedger commits only compact metadata digests and content pointers, which shortens per-incident processing and leads to a higher sustainable service rate. As the incident rate increases, these processing and coordination overheads accumulate more quickly in the full-payload centralized and blockchain-only schemes, which explains the widening throughput gap in Figure 4.

Within the tested range, the highest sustained throughput observed for GeoLedger is 180 events/s at an offered load of 300 events/s. Beyond this range, the main expected scaling pressure remains in the validation and committee-processing path. Possible extension strategies include committee parallelization, sharded validation domains, or multi-chain coordination for larger operational workloads, which remain part of future work.

4.2.3 GIS refresh behavior and operator responsiveness

We evaluated the impact of blockchain processing on GIS refresh behavior and operator-facing responsiveness. For each offered incident rate between 10 and 300 events/s, the GeoLedger implementation records the median end-to-end refresh time and their three components: blockchain validation and consensus , ledger–GIS synchronization , and map rendering , consistent with the definition in Equation 18. The resulting breakdown is presented in Figure 5. The results show that blockchain validation processing constitutes the dominant share of the refresh delay across the tested load range. At 10 events/s, the median refresh time is approximately 228 ms, of which about 136 ms are attributed to validation and consensus, and about 46 ms each to synchronization and map rendering. These values indicate that the GIS-side processing remains responsive at low load, with both synchronization and rendering staying well below 50 ms per refresh. Interactive functions such as marker update, cluster aggregation, and visual refresh therefore remain within a short operator-facing response window at this workload level.

FIGURE 5

As the incident rate increases to 100 events/s, rises to around 300 ms, with 180 ms, and about 120 ms spent in the GIS synchronization and rendering stages. At the highest tested load of 300 events/s, the median refresh latency reaches roughly 460 ms, composed of about 276 ms for blockchain processing and around 184 ms for synchronization and rendering combined. Even at this load, the combined GIS synchronization and rendering cost remains below 200 ms, which indicates stable clustering, update, and redraw behavior under the tested incident volume.

This result is consistent with the metadata-only synchronization design, where the GIS layer receives verified event metadata rather than full incident payloads. In the prototype, the synchronization interface is implemented as an event-driven metadata export step that is triggered after block finalization and passes only the attributes required for spatial indexing, symbolization, and map updates.

Across all loads, the three components grow smoothly without signs of instability or abnormal growth on the GIS side. This load progression provides a controlled stress view of the prototype under increasing incident intensity, with the highest evaluated rates showing that validation pressure rises before GIS-side rendering becomes the dominant limit.

The blockchain layer remains the principal contributor to latency, yet synchronization and rendering costs stay below 100 ms even at 300 events/s, and the total refresh time remains within sub-second limits suitable for operational dashboards. This behavior suggests that GeoLedger’s combination of delegated validation and lightweight GIS synchronization can handle increased workload from the blockchain layer without degrading operator-facing responsiveness beyond acceptable bounds. Within the tested range, the results do not show a point at which GIS rendering becomes the dominant bottleneck. At the highest evaluated load of 300 events/s, blockchain-side validation and committee processing account for about 276 ms of the total 460 ms refresh time, whereas GIS synchronization and rendering account for about 184 ms. The observed stress point is therefore already visible in the validation path within the tested regime, even though a separate node-count scaling experiment was not conducted in the present prototype.

Beyond the tested load range, the most likely scalability pressure remains in the validation and committee-processing path rather than in the metadata-only GIS synchronization step, although this higher-load regime was not evaluated directly in the present prototype. Instead, the first clear scalability pressure appears in the blockchain validation and committee-processing path as the offered rate approaches the upper end of the evaluated load range. This indicates that, under the present prototype configuration, consensus-related processing constrains scaling before GIS refresh operations do.

4.3 Storage and communication overhead

We examine the overheads incurred during emergency event validation, transmission, and storage in GeoLedger, and benchmark them against the centralized study in Ovando-Leon et al. (2022) and blockchain-based study in Ghani et al. (2025) schemes. For this analysis, a representative incident payload of about 1 KB per event is assumed, and Figure 6a decomposes the resulting logical overhead into four components: signature and digest, pointer or index metadata, payload, and header or control fields. GeoLedger records only compact metadata on chain, with about 96 bytes for signature and hash, 64 bytes for a content pointer, and 80 bytes of header information, giving a budget of roughly 240 bytes per event, while the full payload remains off-chain or encrypted.

FIGURE 6

Relative to the centralized baseline footprint of about 1,440 bytes per event, this corresponds to an approximate 83.3% reduction in per-event on-chain or ledger-facing data volume. Relative to the full-payload blockchain baseline footprint of about 1,248 bytes per event, the reduction is about 80.8%. The same difference appears in long-run storage growth. At 100,000 recorded events, GeoLedger reaches about 68.7 MB, compared with about 412 MB for the centralized baseline and about 357 MB for the blockchain baseline, which corresponds to reductions of about 83.3% and 80.8%, respectively.

In contrast, the centralized emergency management baseline stores the complete incident record together with database index and logging structures, resulting in around 1,440 bytes per event, composed of 96 bytes of authentication metadata, 256 bytes of index and log data, 1,024 bytes of payload, and 64 bytes of header and control information. The blockchain-based baseline maintains full incident payloads on chain plus transaction and validator metadata, for approximately 1,248 bytes per event, composed of 96 bytes of signature and digest, 32 bytes of chain index information, 1,024 bytes of payload, and 96 bytes of header and consensus-related fields. GeoLedger therefore incurs a substantially smaller per-event footprint than both full-payload baselines. , Figure 6b scales these per-event budgets to cumulative storage and transmission overhead under increasing numbers of recorded incidents, incorporating a replication and logging factor to reflect realistic deployments. For 1,000 recorded events, GeoLedger produces about 0.7 MB of cumulative data, whereas the centralized and blockchain baselines generate roughly 4.1 MB and 3.6 MB, respectively.

At 10,000 events, the footprint rises to around 6.9 MB for GeoLedger, 41.2 MB for the centralized design, and 35.7 MB for the blockchain design. At 100,000 events, GeoLedger remains close to 68.7 MB, while the centralized and blockchain baselines reach approximately 412 MB and 357 MB. All three curves increase roughly linearly with the number of events, but with clearly different slopes: the metadata-only design in GeoLedger shows a much flatter growth than the full-payload centralized and blockchain baselines.

These results indicate that GeoLedger can handle high event rates while placing significantly lower long-term demands on storage and communication, which is particularly important in prolonged, high-volume emergency operations. Table 2 summarizes representative quantitative results reported across the evaluation section to provide a compact numerical overview of throughput, latency, GIS responsiveness, and storage overhead.

4.4 Spatial visualization and incident mapping

This part evaluates how GeoLedger supports situational awareness by projecting validated emergency metadata onto a geospatial interface. The cleaned LFB incident dataset is used to generate maps in which each confirmed record appears as a point at its reported coordinates, styled by incident group and time, while the underlying payload remains off-chain or encrypted. These spatial views complement the latency, throughput, and overhead results by showing how validated metadata is translated into actionable geographic information.

Figure 7 shows a map of sampled incidents with valid GPS coordinates grouped by the Incident Group field. For clarity, a subset of 500 incidents is displayed, which remains representative of typical urban call patterns while avoiding visual clutter. Incidents are drawn on a light basemap with clustering at lower zoom levels to reduce marker clutter, and the spatial distribution reveals dense corridors and local hotspots where repeated calls accumulate within the same boroughs.

FIGURE 7

Figure 8 organizes this information into a two-panel dashboard. The left panel reproduces the incident distribution map, while the right panel presents a GeoLedger-centric metadata view in which each marker corresponds to a blockchain-recorded event. Popups expose the transaction identifier (), node identifier (), incident group, time, and borough, mirroring the metadata structure defined in the system design. This layout allows operators to move from a spatial overview to ledger-anchored record inspection, combining familiar GIS tools with explicit traceability to on-chain evidence. The same dashboard structure can be extended with severity or time-window filters without changing the underlying blockchain–GIS integration.

FIGURE 8

4.5 Security analysis

GeoLedger is structured to reinforce emergency management workflows against data forgery, tampering, and uncontrolled disclosure. At GeoLedger’s intake boundary, the registration authority issues certificates and validates possession of each node’s key, so only authenticated entities and responders can inject events into the system. Every report is encapsulated as a signed digest–pointer tuple, and the predicate valid (Equation 10) enforces schema validation, freshness, geofencing, and replay checks before a transaction is considered for consensus. This combination of certificate validation, origin authentication, and duplicate suppression significantly increases the cost associated with injecting either forged or stale incidents into GeoLedger.

In the threat model, we assume a computationally bounded adversary that could compromise a subset of field devices, attempt to replay or reorder incidents, attempt to modify previously committed blocks, or control a minority of validators within GeoLedger, and that cannot compromise any of the underlying cryptographic primitives or control a super-majority of the DVG committee. Within the ledger, integrity and non-repudiation follow from delegated validation and hash-chained blocks. A transaction is considered valid only when the digital signature verifies successfully under the public key associated with the registering node and matches the submitted digest and content pointer, and the number of acknowledgements from the DVG meets the quorum threshold (Equation 5).

As the ledger uses a block structure, it links each batch to its predecessor and to a Merkle summary (Equations 6, 7). This allows detection of attempts to modify, delete, or reorder committed events. Additionally, the conflict predicate (Equation 11) protects against equivocation by preventing different pointers for the same digest from being placed into the canonical chain; however, both pointers can be retained for forensic purposes. Collectively, these methods provide end-to-end provenance from the originating node key through the attestations provided by the DVG to the final GIS marker. They also enhance accountability compared with centralized dashboards and opaque blockchain logging schemes.

GeoLedger supports post-processing and correction through append-only audit records rather than in-place modification of committed entries. If an incident requires correction, review, or dispute handling, a new superseding transaction can reference the original transaction identifier while preserving the earlier record in the audit trail. This policy is important in emergency settings, where later review, accountability, and evidentiary traceability may be required even when an operational record is updated.

Availability and resistance to validator compromise are addressed through randomized, score-weighted committee selection and the requirement ≥ 3 + 1 (Equation 12), which constrains the number of Byzantine validators allowed per round. A related risk in permissioned operation is repeated committee overlap or long-term validator concentration. GeoLedger limits this through periodic committee rotation, score-based exclusion of persistently unreliable validators, and certificate-based administrative revocation. Because committee membership is score-weighted and regularly refreshed, a minority of validators cannot depend on stable representation across successive rounds to sustain censorship or ordering bias over time. If collusive behavior is suspected, the affected committee can be replaced from the remaining eligible validator pool, and the corresponding validator records can be audited before re-admission.

In addition, the use of a metadata-only commitment model limits on-chain content to compact digests, pointers, and minimal descriptors, while the full payload of all incidents remains in protected off-chain repositories deployed using replicated storage backends with redundancy and access control enforcement. These repositories are logically decoupled from the ledger and do not constitute a single point of failure, as availability is ensured through infrastructure-level replication and backup mechanisms.

The indirection allows for verifiable mapping between the location of the map marker and its underlying record without exposing sensitive narratives or personal data to all ledger participants, providing a stronger privacy posture than full-payload blockchain architectures. In a read-only ledger access scenario, a participant can inspect only the committed metadata, transaction identifier, and content pointer. The protected narrative cannot be reconstructed from alone, since full payload retrieval remains subject to the off-chain access controls and decryption requirements defined in the storage layer.

The two layers are interconnected through a metadata-only, low-latency synchronization interface that supports real-time coordination without introducing significant processing delay. In the prototype, verified event metadata are exported to the GIS layer through a lightweight point-feature schema. This schema preserves the transaction identifier, node identifier, location, incident type, timestamp, and content pointer. These fields provide a stable exchange structure for synchronization across participating systems while keeping the on-chain record compact. At the GIS exchange layer, the representation is GeoJSON-compatible, which supports practical interoperability with common agency-side geospatial tools, even though the digest itself remains a compact ledger object rather than a full geospatial document. This also supports standards-aligned data exchange with external GIS and emergency response systems at the application layer, although the present prototype does not implement a full Open Geospatial Consortium (OGC) service stack.

In practical deployment, GeoLedger can be introduced incrementally alongside existing emergency reporting and GIS platforms, so current operational systems remain in place while ledger-backed validation and metadata synchronization are added as overlay functions. A realistic integration path is therefore to preserve existing incident intake and mapping services while adding ledger-backed validation and protected metadata exchange around them. For larger or multi-agency adoption, this requires a clear governance model for validator admission and oversight, routine certificate renewal and revocation procedures, and phased scaling of validation and dashboard policies as incident load increases.

Such reports still satisfy the valid predicate and include signatures that can be verified using certified keys. Furthermore, as long as the attacker does not control at least voting validators, they cannot accumulate DVG approvals to be finalized. GeoLedger also limits Sybil-style admission by requiring registration authority approval, certificate issuance, proof of key possession, and revocation tracking before a node can enter the reporting path. As a result, an adversary cannot expand influence by creating arbitrary new reporting identities without first passing the permissioned registration process.

Second, assume an attacker controls a minority of validators and is attempting to censor or reorder incidents. The quorum rule, chained block headers, and Merkle roots cause any deviation from the agreed history to be detectable by honest validators. In addition, since validator selection is randomized and periodically rotated, the likelihood of selecting the same set of malicious validators to be placed along the critical path multiple times across many epochs is low. Third, assume an adversary gains read-only access to the ledger but not to the off-chain repositories: only pseudonymous metadata, digests, and coarse spatial tags are visible. Reconstructing the individual reports would require a further breach of the custodial domains that enforce the respective authentication and authorization policies for each report.

We finally assume that operational controls such as key lifecycle management, hardening of off-chain stores, and rate-limiting or traffic filtering against volumetric attacks are provisioned by the operator; these aspects depend on deployment choices and are not exhaustively modeled here, but GeoLedger provides a tamper-evident, audit-ready backbone on which such controls can be layered. Taken together, these mechanisms deliver a substantially stronger security posture than conventional centralized dashboards and full-payload blockchain schemes for emergency management and limit the impact of device compromise, validator misbehavior, and partial ledger disclosure relative to related centralized and blockchain-based systems. A comparison of the main security features of GeoLedger and related centralized and blockchain schemes is shown in Table 3.

5 Conclusion

This paper presents GeoLedger, a hybrid blockchain–GIS architecture tailored for emergency management systems. In the proposed design, incident reports are initially normalized and verified at a registration authority, and subsequently reduced to signed digest-pointer tuples. The tuples are then validated by a designated validator group before being committed to a permissioned ledger. Only compact metadata, including hashes, content identifiers, and minimal descriptors, is committed on-chain, while full incident payloads remain in secure off-chain stores. Each GIS marker is therefore anchored to an immutable transaction without exposing the full operational narrative to all participants. The reported evaluation shows that this design supports low-latency, ledger-backed emergency mapping under replayed urban incident workloads. At a representative load of 150 events/s, GeoLedger processes approximately 142.5 events/s, compared with 110 and 120 events/s for the centralized and full-payload blockchain baselines, respectively. Under the highest evaluated load, the dashboard refresh latency remains sub-second, and the metadata-only design substantially reduces per-event ledger-facing data and cumulative storage growth relative to both baselines. The security analysis further shows that the framework strengthens integrity, accountability, and controlled disclosure through certificate-based admission, delegated quorum validation, metadata-only ledger commitment, and protected off-chain storage. Taken together, these results support the claim that GeoLedger provides an effective and operationally practical architecture for trusted emergency incident mapping in high-load, multi-agency settings. The reported results remain consistent with the design objective of combining ledger-backed trust, protected payload handling, and responsive geospatial situational awareness within a single framework. Future work will further extend and evaluate the proposed framework under broader operational settings and deployment conditions.

References

• 1

  AchourI.IdoudiH.AyedS. (2025). Access control modeling and validation for ethereum smart contracts. Concurrency Comput. Pract. Exp.37 (12-14), e70108. 10.1002/cpe.70108

  • CrossRef
  • Google Scholar

• 2

  AggarwalS. P.KunduS. S.SarmaK. K. (2024). Geospatial technology for effective disaster risk reduction: best practices in capacity building. Int. Archives Photogrammetry, Remote Sens. Spatial Inf. Sci.48, 147–153. 10.5194/isprs-archives-xlviii-5-2024-147-2024

  • CrossRef
  • Google Scholar

• 3

  AlmheiriS.AlshkeiliS.AlnuaimiA.AlmazrouiN.AlsubousiM.KhashanO. A. (2025). “IoT-Based framework to enhance emergency communication for people with disabilities,” in 2025 international conference on artificial intelligence, computer, data sciences and applications (ACDSA) (IEEE), 1–5.

  • Google Scholar

• 4

  CaoY.XuC.AzizN. M.KamaruzzamanS. N. (2023). BIM–GIS integrated utilization in urban disaster management: the contributions, challenges, and future directions. Remote Sens.15 (5), 1331. 10.3390/rs15051331

  • CrossRef
  • Google Scholar

• 5

  Carreras-CochA.NavarroJ.SansC.ZaballosA. (2022). Communication technologies in emergency situations. Electronics11 (7), 1155. 10.3390/electronics11071155

  • CrossRef
  • Google Scholar

• 6

  ChafiqT.RidaA. Z. M. I.FadilA.MohammedO. (2024). Investigating the potential of blockchain technology for geospatial data sharing: opportunities, challenges, and solutions. Geomatica76 (2), 100026. 10.1016/j.geomat.2024.100026

  • CrossRef
  • Google Scholar

• 7

  ChatrabhujK.MeshramK.MishraU.OmarP. J. (2024). Integration of remote sensing data and GIS technologies in river management system. Discov. Geosci.2 (1), 67. 10.1007/s44288-024-00080-8

  • CrossRef
  • Google Scholar

• 8

  DialloE. H.AbdallahR.DibM.DibO. (2024). Decentralized incident reporting: mobilizing urban communities with blockchain. Smart Cities7 (4), 2283–2317. 10.3390/smartcities7040090

  • CrossRef
  • Google Scholar

• 9

  DjennaA.HarousS.SaidouniD. E. (2021). Internet of things meet internet of threats: new concern cyber security issues of critical cyber infrastructure. Appl. Sciences11 (10), 4580. 10.3390/app11104580

  • CrossRef
  • Google Scholar

• 10

  FarnaghiM.MansourianA. (2020). Blockchain, an enabling technology for transparent and accountable decentralized public participatory GIS. Cities105, 102850. 10.1016/j.cities.2020.102850

  • CrossRef
  • Google Scholar

• 11

  FranchiF.GraziosiF.Di FinaE.GalassiA. (2023). A survey of cloud-enabled gis solutions toward edge computing: challenges and perspectives. IEEE Open J. Commun. Soc.5, 312–331. 10.1109/ojcoms.2023.3344198

  • CrossRef
  • Google Scholar

• 12

  GhaniA.ZinedineA.El MohajirM. (2025). Eghatha: a blockchain-based system to enhance disaster preparedness. Computers14 (10), 405. 10.3390/computers14100405

  • CrossRef
  • Google Scholar

• 13

  HafeezS.ChengR.MohjaziL.ImranM. A.SunY. (2024). “A blockchain-enabled framework of uav coordination for post-disaster networks,” in 2024 IEEE 99th vehicular technology conference (VTC2024-Spring), 1–5.

  • Google Scholar

• 14

  KhanS. M.ShafiI.ButtW. H.DiezI. D. L. T.FloresM. A. L.GalánJ. C.et al (2023). A systematic review of disaster management systems: approaches, challenges, and future directions. Land12 (8), 1514. 10.3390/land12081514

  • CrossRef
  • Google Scholar

• 15

  KhashanO. A. (2024). Blockchain-machine learning fusion for enhanced malicious node detection in wireless sensor networks. Knowledge-Based Syst.304, 112557. 10.1016/j.knosys.2024.112557

  • CrossRef
  • Google Scholar

• 16

  KhashanO. A. (2025a). Dual-stage machine learning approach for advanced malicious node detection in WSNs. Ad Hoc Netw.166, 103672. 10.1016/j.adhoc.2024.103672

  • CrossRef
  • Google Scholar

• 17

  KhashanO. A. (2025b). Trust-based fog-blockchain model for scalable authentication in smart cities. Comput. Netw.264, 111278. 10.1016/j.comnet.2025.111278

  • CrossRef
  • Google Scholar

• 18

  KhashanO. A.KhafajahN. M. (2023). Efficient hybrid centralized and blockchain-based authentication architecture for heterogeneous IoT systems. J. King Saud University-Computer Inf. Sci.35 (2), 726–739. 10.1016/j.jksuci.2023.01.011

  • CrossRef
  • Google Scholar

• 19

  KhashanO. A.ZinA. M.SundararajanE. A. (2015). ImgFS: a transparent cryptography for stored images using a filesystem in userspace. Front. Inf. Technol. and Electron. Eng.16 (1), 28–42. 10.1631/fitee.1400133

  • CrossRef
  • Google Scholar

• 20

  KhashanO. A.KhafajahN. M.AlomoushW.AlshinwanM.AlamriS.AtawnehS.et al (2023a). Dynamic multimedia encryption using a parallel file system based on multi-core processors. Cryptography7 (1), 12. 10.3390/cryptography7010012

  • CrossRef
  • Google Scholar

• 21

  KhashanO. A.AlamriS.AlomoushW.AlsmadiM. K.AtawnehS.MirU. (2023b). Blockchain-based decentralized authentication model for IoT-Based E-Learning and educational environments. Comput. Mater. and Continua75 (2). 10.32604/cmc.2023.036217

  • CrossRef
  • Google Scholar

• 22

  KhashanO. A.KhafajahN. M.MohamedN.AlomoushW.AlshinwanM. (2025). “Blockchain for decentralized authentication in IoT networks using digital certificates,” in 2025 IEEE Canadian conference on electrical and computer engineering (CCECE) (IEEE), 67–72.

  • Google Scholar

• 23

  KimM.Ben-OthmanJ.JungB. C.KimH. (2025). Blockchain-enabled maximum evacuation system using hybrid voting in zero trust hiking trail and mountainous terrain. IEEE Internet Things J.12 (5), 5847–5858. 10.1109/jiot.2024.3490560

  • CrossRef
  • Google Scholar

• 24

  LeeonisA. N.AhmedM. F.MokhtarM. B.LimC. K.HalderB. (2024). Challenges of using a geographic information system (GIS) in managing flash floods in shah alam, Malaysia. Sustainability16 (17), 7528. 10.3390/su16177528

  • CrossRef
  • Google Scholar

• 25

  London Fire Brigade (2023). “Incident records,” in London datastore, dataset. Available online at: https://data.london.gov.uk/dataset/london-fire-brigade-incident-records (Accessed September 14, 2025).

  • Google Scholar

• 26

  MajumdarS.AwasthiA. (2025). From vulnerability to resilience: securing public safety GPS and location services with smart radio, blockchain, and AI-driven adaptability. Electronics14 (6), 1207. 10.3390/electronics14061207

  • CrossRef
  • Google Scholar

• 27

  MiaM. U.RahmanM.ElbeltagiA.Abdullah-Al-MahbubM.SharmaG.IslamH. T.et al (2022). Sustainable flood risk assessment using deep learning-based algorithms with a blockchain technology. Geocarto Int.38, 1–29. 10.1080/10106049.2022.2112982

  • CrossRef
  • Google Scholar

• 28

  NayyeriH.ZandiS.SouriM. (2024). Location of disaster management bases using spatial analysis. J. Syst. Sci. Syst. Eng.33 (1), 1–29. 10.1007/s11518-023-5586-4

  • CrossRef
  • Google Scholar

• 29

  NguyenzT.NguyenH.GiaT. N. (2024). Exploring the integration of edge computing and blockchain IoT: principles, architectures, security, and applications. J. Netw. Comput. Appl.226, 103884. 10.1016/j.jnca.2024.103884

  • CrossRef
  • Google Scholar

• 30

  Ovando-LeonG.Veas-CastilloL.Gil-CostaV.MarinM. (2022). Bot-based emergency software applications for natural disaster situations. Future Internet14 (3), 81. 10.3390/fi14030081

  • CrossRef
  • Google Scholar

• 31

  ParkH. S.KwonS. A.AzamM. (2024). A study on GIS-Based spatial analysis of emergency response for disaster management: focusing on Seoul. Heliyon10 (7), e28669. 10.1016/j.heliyon.2024.e28669

  • Pubmed Abstract
  • CrossRef
  • Google Scholar

• 32

  PekerI.ArI. M.ErolI.SearcyC. (2023). Leveraging blockchain in response to a pandemic through disaster risk management: an IF-MCDM framework. Operations Manag. Res.16 (2), 642–667. 10.1007/s12063-022-00340-1

  • CrossRef
  • Google Scholar

• 33

  RaoZ.WangC.ZhangY.LiuX. (2024). DAR-DRL: a dynamic adaptive routing method based on deep reinforcement learning for mobile-centric wireless networks. Comput. Commun.223, 149–161. 10.1016/j.comcom.2024.107983

  • CrossRef
  • Google Scholar

• 34

  RashidS. M.AliyuI.IsahA.HahnM.KimJ. (2025). Blockchain-based task placement and resource management in edge computing: a survey. Electronics14 (17), 3398. 10.3390/electronics14173398

  • CrossRef
  • Google Scholar

• 35

  ShevchukR.LishchynskyyI.CiuraM.LyzunM.KozakR.KasianchukM. (2025). Application of blockchain technology in emergency management systems: a Bibliom(khashan and etric) analysis. Appl. Sci.15 (10), 5405. 10.3390/app15105405

  • CrossRef
  • Google Scholar

• 36

  SureshS. S.ThangaveluK.AyyanarR.VairavasundaramS. (2024). Intelligent data routing strategy based on federated deep reinforcement learning for IoT-enabled wireless sensor networks. Smart Agric. Technol.8, 100538.

  • Google Scholar

• 37

  TongX.HamzeiM.JafariN. (2025). Towards secure and efficient data aggregation in blockchain‐driven IoT environments: a comprehensive and systematic study. Trans. Emerg. Telecommun. Technol.36 (2), e70061. 10.1016/j.measen.2023.101012

  • CrossRef
  • Google Scholar

• 38

  WangQ.LiuY. (2023). “Enhancing collaborative emergency management: leveraging blockchain distributed ledger for inter-agency data sharing,” in Proceedings of the 8th ACM SIGSPATIAL international workshop on security response using GIS, 13–17.

  • Google Scholar

• 39

  WangC.GuoZ.ShiF.ChenM.WangX.LiuJ. (2024). Research on emergency logistics information traceability model and resource optimization allocation strategies based on consortium blockchain. Plos One19 (5), e0303143. 10.1371/journal.pone.0303143

  • Pubmed Abstract
  • CrossRef
  • Google Scholar

• 40

  WibowoA.AmriI.SurahmatA.RusdahR. (2025). Leveraging artificial intelligence in disaster management: a comprehensive bibliometric review. Jàmbá J. Disaster Risk Stud.17 (1), 1–9. 10.4102/jamba.v17i1.1776

  • CrossRef
  • Google Scholar

• 41

  YueY.ShyuJ. Z. (2024). A paradigm shift in crisis management: the nexus of AGI‐driven intelligence fusion networks and blockchain trustworthiness. J. Contingencies Crisis Management32 (1), e12541. 10.1111/1468-5973.12541

  • CrossRef
  • Google Scholar

• 42

  ZhangY.WangT.YuenK. V. (2022). Construction site information decentralized management using blockchain and smart contracts. Computer‐Aided Civ. Infrastructure Eng.37 (11), 1450–1467. 10.1111/mice.12804

  • CrossRef
  • Google Scholar

• 43

  ZouQ.YuW.BaoZ. (2023). A blockchain solution for remote sensing data management model. Appl. Sci.13 (17), 9609. 10.3390/app13179609

  • CrossRef
  • Google Scholar