Blockchain-Based Multi-Signature System for Critical Scenarios

Cristina Alcaraz

, Davide Ferraris

, Hector Guzman and Javier Lopez

Computer Science Department, University of Malaga,

Campus de Teatinos s/n, 29071, Malaga, Spain

Keywords:

Multi-Signature, Blockchain, Trust, and Critical Infrastructures.

Abstract:

Blockchain technology plays a crucial role in securing and streamlining transactions across various critical

domains. For that reason, this paper presents a Blockchain-based multi-signature system designed for high-

stakes scenarios, where both user and Blockchain-generated signatures are required to authorize transactions.

By integrating smart contracts, multi-signature coordination, and Blockchain validation, the proposed architec-

ture enhances security, accountability, and resilience. The framework is applied to two key sectors: Mobility

and energy. In mobility, it addresses two distinct use cases: Ambulance services, where secure and veriﬁable

authorization of emergency access is required, and insurance claim processing, ensuring transparent, tamper-

proof validations. In the energy sector, the system facilitates decentralized, trust-enhanced peer-to-peer energy

trading by guaranteeing transaction integrity and compliance. The architecture leverages smart contracts to en-

force transaction policies, aggregate multi-signatures, and validate operations while maintaining transparency

and reliability. This work highlights the importance of decentralized decision-making and immutable records

in securing critical infrastructures. Future research will focus on optimizing performance and evaluating the

system’s integration with existing Blockchain platforms such as Ethereum and Hyperledger.

1 INTRODUCTION

In the evolving landscape of Blockchain technol-

ogy, security and control over digital assets re-

main paramount concerns (Narayanan, 2016). Multi-

signature (or multisig) mechanisms, which require

multiple parties to sign a transaction before it can be

executed, have emerged as a robust solution to en-

hance security and trust (Buhler, 2025). Traditionally,

multisig implementations involve multiple user signa-

tures to authorize a transaction (Roy and Karforma,

2012). However, an innovative paradigm introduces

the Blockchain itself as an active participant in the

signing process, thereby broadening the scope and

utility of multi-signature schemes (Buhler, 2025) and

its applicability to heterogeneous scenarios in which

the criterion of transparency is a primary requirement.

Thus, this paper explores the concept of multisig in

a Blockchain context where Blockchain technology

operates as one of the signatories. This approach in-

tegrates the decentralized nature of Blockchain sys-

tems with user-centric controls to secure transactions

https://orcid.org/0000-0003-0545-3191

https://orcid.org/0000-0003-3035-3774

https://orcid.org/0000-0001-8066-9991

(Zhang et al., 2025). The Blockchain’s signature can

be viewed as a form of automated governance or pro-

grammatic approval, where predeﬁned rules and con-

ditions are met before the system’s implicit authoriza-

tion is granted (Saurabh et al., 2024). By incorpo-

rating the Blockchain as a signatory, a novel inter-

play is created between system automation and user

authorization (Kuznetsov et al., 2024). For example,

the Blockchain may enforce rules such as compliance

with Smart Contract (SmC) conditions, veriﬁcation

of user identity through decentralized identity proto-

cols, or adherence to community-governed policies.

Once these criteria are satisﬁed, the user must con-

ﬁrm the transaction with their signature to complete

the process. This model not only strengthens trans-

action security but also ensures a higher degree of

transparency and accountability. Thus, the integration

of Blockchain-signed multi-signature schemes intro-

duces several potential applications, including se-

cure multi-party computation, Decentralized Finance

(DeFi) transactions, cross-chain interoperability, and

enhanced fraud prevention mechanisms (Dohler et al.,

2024). Additionally, it opens possibilities for regula-

tory compliance where automated checks can ensure

adherence to legal requirements before the user autho-

rizes the ﬁnal step (Zhuk, 2025). For all these reasons,

Alcaraz, C., Ferraris, D., Guzman, H. and Lopez, J.

Blockchain-Based Multi-Signature System for Critical Scenarios.

DOI: 10.5220/0013559000003979

In Proceedings of the 22nd International Conference on Security and Cryptography (SECRYPT 2025), pages 221-232

ISBN: 978-989-758-760-3; ISSN: 2184-7711

221

the main contribution of this paper is (i) to provide an

analysis of the theoretical foundations, (ii) the tech-

nical implementation and (iii) the practical implica-

tions of Blockchain-assisted multi-signature systems,

especially for those deployed in certain critical con-

texts (Alcaraz et al., 2011; Lopez et al., 2013) such

as energy and mobility. In order to achieve this task,

we will delve into the core principles of multisig, the

role of the Blockchain as a transaction signatory, and

potential challenges and opportunities associated with

this paradigm. The paper also reveals a relevant set of

requirements, which are key to the design of the ap-

proach with applicability in critical scenarios, as well

as a validation methodology based on the “matching”

of such requirements to operations (ﬁrst by layers of

functionality and then by services). The idea is to pro-

vide the literature with the mechanism by which (i) to

demonstrate the usefulness of the approach in critical

scenarios and (ii) to identify which services of the ap-

proach should be optimized, considered or even pri-

oritized in the future.

The paper is organized as follows. Section 2 adds

the related work to provide later on the requirements

we want to satisfy with our solution in Section 3. In

Section 4, we provide the general design of the pro-

posed architecture and how it is matching the pro-

posed requirements is presented; whereas the map-

ping among the proposed architecture, requirements

and functionalities to use case scenarios related to the

mobility and energy sectors is analyzed in Section

5. In the following Section 6, we present in more

detail each of the scenarios, introducing the role of

the JavaScript Object Notation (JSON) and a Solidity

code implemented for the presented use cases. In sec-

tion 7, the paper concludes and outlines future work.

2 RELATED WORK

Multi-signature schemes have been widely studied

and applied in various Blockchain contexts, contribut-

ing to enhanced security and functionality. This sec-

tion summarizes key advancements in this ﬁeld based

on signiﬁcant contributions from existing literature.

For example, Lin et al. (Lin et al., 2019) intro-

duced a Blockchain-based mobile, ticketing system

that leverages SCs and multisig to securely execute

and authorize transactions. Their system ensures the

authenticity and security of mobile tickets through

Blockchain veriﬁcation and the use of an immutable

ledger. The proposed approach demonstrates high ef-

ﬁciency with minimal costs, positioning it as a viable

solution for secure and cost-effective ticketing sys-

tems. Also, Boneh et al. (Boneh et al., 2018) devel-

oped novel multisig schemes designed to reduce the

size of the Bitcoin Blockchain while maintaining ver-

satility for other multisig applications. Their schemes

support signature compression and public-key aggre-

gation, enabling veriﬁers to authenticate a multi-party

signature using a compact representation. Addition-

ally, they introduced an Accountable Subgroup Multi-

signature (ASM) scheme, where the signature size is

independent of the number of signers, enhancing scal-

ability and practicality for applications such as Bit-

coin multisig addresses.

Xiao et al. (Xiao et al., 2020) focused on

improving the efﬁciency of transactions in enter-

prise Blockchain platforms by proposing two mul-

tisig schemes: Gamma MultiSignature (GMS) and

Advanced Gamma MultiSignature (AGMS). Their

schemes are designed to address the complexities

and inefﬁciencies of traditional multisig processes.

Through implementation on Hyperledger Fabric, they

demonstrated that AGMS achieves high transaction

efﬁciency, low storage complexity, and robust secu-

rity against rogue-key and k-sum problem attacks,

making it a strong candidate for enterprise-level appli-

cations. Also, Aitzhan et al. (Aitzhan and Svetinovic,

2016) addressed the challenge of securing transac-

tions in decentralized smart grid energy trading sys-

tems. They proposed a Blockchain-based solution in-

corporating multisigs and anonymous encrypted mes-

saging to enable secure and private energy trading

without relying on trusted third parties. Their proof-

of-concept demonstrated robust security and privacy

mechanisms while ensuring efﬁcient performance in

decentralized energy markets.

Kara et al. (Kara et al., 2023) introduced a

multisig scheme based on RSA aimed at reducing

Blockchain size and improving resistance to known

attacks. Their scheme operates in the plain public key

model, simplifying implementation by avoiding the

need for key possession proofs. The proposed ASM

model discloses the subset of signers responsible for

a valid signature and employs a two-round protocol

for public-key aggregation. This scheme enhances

Blockchain efﬁciency and security while maintaining

scalability. Similarly, Gai et al. (Gai et al., 2022)

proposed a Blockchain-based Multi-Signature Lock

(BMSL-UAC) to address security challenges in the

metaverse’s Ubiquitous Access Control (UAC) set-

tings. Their scheme enables secure and traceable ac-

cess to data in consortium Blockchain systems, en-

suring that only authorized users can interact with the

system. The experimental evaluation on Hyperledger

demonstrated that their approach achieves reasonable

performance in terms of resource consumption, de-

lay, and throughput, making it a suitable framework

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

222

for managing access control in the metaverse.

The body of work discussed here highlights the

versatility and innovation in multi-signature appli-

cations, ranging from ticketing systems and energy

trading to Blockchain compression and access con-

trol. These advancements collectively inform the de-

velopment of Blockchain-integrated multi-signature

schemes and their potential to address challenges in

security, efﬁciency, and scalability. Based on these

works and their progress, and particularly in the ﬁeld

of Blockchain and multi-signature, we now explore

in the following section how to go one step beyond

the state of the art by providing a Blockchain-based

multi-signature architecture. The architecture has the

proposal of combining Blockchain and multisig un-

der the pragmatic vision of integrating four layers of

functionality. This perspective not only simpliﬁes the

use of the technique in decentralised systems, but also

favours its application in heterogeneous and dynamic

contexts where it is relevant to intensify principles of

accountability, but also to provide guarantees of mod-

ularity and performance.

3 REQUIREMENTS

Any Blockchain-based multi-signature system with

application in critical scenarios must satisfy a min-

imum set of security, efﬁciency and reliability re-

quirements in order to generate trust and better use

of its utility. In that regard, this section estab-

lishes the key requirements, categorized into: (i)

Blockchain Infrastructure-speciﬁc Requirements (IR)

and its deployment in real contexts; (ii) the Mul-

tisignature mechanism Requirements (MR) for trust

and accountability management; and (iii) Applica-

tion Requirements (AR) associated with the ﬁnal use

of Blockchain for real-world scenarios. Considering

these three sets of requirements and based on (Alcaraz

and Lopez, 2012; Alcaraz et al., 2020), we now iden-

tify a subset of control and trust conditions. Start-

ing with the deployment of the Blockchain infrastruc-

ture and attending the features of a Distributed Ledger

Technology (DLT), IR comprises:

• Traceability (IR-1): Transactions must be fully

traceable, allowing all stakeholders to verify the

ﬂow of assets or approvals. Blockchain provides

an immutable record of signatures and transaction

steps by design, ensuring visibility throughout the

system.

• Immutability (IR-2): Once recorded, transactions

cannot be altered or deleted. This ensures that past

signatures and approvals remain intact, preventing

unauthorized modiﬁcations to digital records.

• Veriﬁability (IR-3): All transactions should

be independently veriﬁable by any stakeholder.

Cryptographic proofs and publicly accessible

Blockchain records allow third parties to conﬁrm

the validity of transactions without reliance on a

central authority.

• Sustainability (IR-4): Energy-efﬁcient crypto-

graphic techniques and Blockchain protocols

should be considered to minimize the en-

vironmental impact of transaction processing.

Proof-of-Stake (PoS) or delegated PoS (DPoS)

Blockchains may provide more sustainable alter-

natives (Saad et al., 2021).

Trust can also be managed through the multisig

system integrated into Blockchain. The resulting sys-

tem adheres the beneﬁcial technical characteristics to

intensify the properties of trust, such as the use of

hashes and signatures. Thus, within MR, we consider:

• Accountability (MR-1): Each participant of the

Blockchain network must be accountable for

their actions, particularly in multisig transactions

where multiple parties sign a transaction. The

Blockchain ensures that each transaction is ex-

plicitly linked to authorized signers.

• Auditing (MR-2): DLTs should provide a veri-

ﬁable record of all transactions for auditing and

compliance purposes. The distributed ledger of

the Blockchain offers a transparent and automated

accounting mechanism, reducing the risk of fraud.

• Lightweight (MR-3): Given resource constraints,

particularly in mobile and (Industrial) IoT envi-

ronments (Alcaraz and Lopez, 2014), the mul-

tisig mechanism should be computationally efﬁ-

cient. Optimized cryptographic algorithms and

minimal on-chain storage requirements ensure a

lightweight design.

• Non-repudiation (MR-4): A signer cannot later

deny their participation in a transaction. Crypto-

graphic signatures stored on the Blockchain pro-

vide undeniable proof of participation, ensuring

that all actions are veriﬁable.

Regarding AR and its related requirements for the

protection of critical infrastructures and the preser-

vation of their performance when using Blockchain-

based multisig approaches:

• Performance (AR-1): DLTs must support fast

transaction processing to enable real-time applica-

tions such as mobility and energy trading. SC op-

timizations and off-chain scaling solutions (Gupta

et al., 2023) may be necessary to meet this re-

quirement.

Blockchain-Based Multi-Signature System for Critical Scenarios

223

• Decoupling (AR-2): DLTs should minimize

dependencies between different components,

enabling ﬂexible integration with various

Blockchain networks and external services. This

allows seamless interoperability with multiple

applications and industries.

• Resilience (AR-3): DLTs must withstand mali-

cious attacks, software bugs, and external dis-

ruptions. By decentralizing control and using

fault-tolerant consensus algorithms, Blockchain

ensures resilience against system-wide failures, in

addition to guaranteeing the availability and ac-

cessibility of the data at all times.

• Survivability (AR-4): DLTs must remain opera-

tional even in the presence of attacks, failures, or

disruptions. Thus, Blockchain should ensure the

management of multiple copies of transactions,

enhancing the system’s resilience, under suitable

immutability and authentication approaches.

All these requirements will not only form the ba-

sis of the general design of the architecture proposed

below, but will also lay the foundations for the con-

struction of future multisig approaches. In this case,

the special combination of Blockchain and a multisig

strategy adds a “trust wrapper” of at least two digi-

tal signatures: (i) one performed by the Blockchain,

which acts as a third trusted entity, and (ii) another by

the participant(s), who is the owner of the transaction.

4 LAYERED ARCHITECTURE

To comply with IR, MR and AR, multisig approaches

must not only consider the DLT as a key element

within their construction, but also associate security

services according to layers of functionality:

1. Application Layer (AL): Handles user interac-

tions and interfaces, where all the requirements

application-level should widely be considered.

2. Smart Contract Layer (SCL): Manages business

logic, rules, and transaction authorization criteria.

3. Multi-Signature Coordination Layer (MSCL):

Guarantees the correct signature both by the user

and by the Blockchain.

4. Blockchain Layer (BL): Veriﬁes and records

transactions and participates as an elementary sig-

natory within the proposed architecture.

In turn, these layers are divided into sub-

components of functionality in order to (i) modularize

services and (ii) intensify operational performance,

such that AL deals with:

• User Interface (UI): A web or mobile application

enabling users to initiate transactions, view status,

and provide their signatures.

• Client Wallets (CW): Secure wallets where users

store their private keys to sign transactions.

• Transaction Module (TM): Allows users to create

transactions by specifying details (e.g., recipient,

amount).

On the contrary, SCL contains the following three

sub-components:

• Transaction Validation Contract (TVC): Deﬁnes

rules for when the Blockchain can authorize a

transaction (e.g., compliance checks, precondi-

tions). It also veriﬁes that all required conditions

are met before the Blockchain signs.

• Multi-Signature Execution Contract (MSEC): Co-

ordinates the process of collecting both the user

and Blockchain’s signatures. It also ensures

atomic execution, where transactions are only

valid if both parties sign.

About MSCL, it is based on three subcomponents:

• Key Management Module (KM): Generates and

stores the Blockchain’s private key securely (e.g.,

HW security modules or threshold cryptography).

• Signature Aggregator (SA): Collects user and

Blockchain signatures and combines them into a

single multisig.

• Transaction Veriﬁer (TV): Validates the aggre-

gated signature before broadcasting the transac-

tion to the Blockchain.

Finally, the BL contains:

• Consensus Mechanism (CM): Ensures decentral-

ized agreement on the validity of transactions be-

fore the Blockchain signs. Participates as a sig-

natory by generating a Blockchain-level signature

using a system-controlled private key.

• Immutable Ledger (IL): Records transactions,

their signatures, and metadata for auditing and

transparency.

To clarify the workﬂow taken by the multisig

procedure within the approach, the user ﬁrst initi-

ates a transaction in AL, corresponding to («stage-

1») in Figure 1. The details of the transaction are

sent to SCL («stage-2»), where a Blockchain vali-

dation process checks predeﬁned rules (e.g., thresh-

olds, compliance, conditions). All entities involved

in the signature process interact with the SCL, result-

ing in the generation of a SC transaction that serves

as veriﬁable evidence of the signature. At the MSCL

(«stage-3»), all collected signatures are validated, and

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

224

Figure 1: Layered Blockchain-based multisig.

a blockchain-based signature is appended. This signa-

ture does not represent a traditional cryptographic sig-

nature but the deterministic outcome of the SC valida-

tion process. It ensures the validity of the entire pro-

cedure, is publicly veriﬁable, and remains immutable.

Once ﬁnalised this process, the system requires user

veriﬁcation by sending the transaction back to the user

for ﬁnal conﬁrmation and signature using his/her pri-

vate key. After this stage, the procedure for adding

multiple signatures begins. The signature aggregator

combines the Blockchain and user signatures into a

single valid multisig, and the aggregated signature is

appended to the transaction. The following stage is

dedicated to the transmission of the transaction to the

Blockchain, «stage-4». This means that the ﬁnalized

transaction, with its multisig, is sent to BL for con-

sensus and inclusion in the ledger. This feature al-

lows the possibility for audit and feedback, because

the immutable ledger records the transaction for fu-

ture reference. As the ﬁnal stage in the workﬂow of

the proposed approach, the system returns to «stage-

1» to notify the user. To achieve this task, AL informs

the user about the status of the transaction. As shown

in the ﬁgure, the architecture emphasizes modularity

and scalability, but also the security of the user and the

organizations involved in the application. Each layer

is responsible for a speciﬁc activity and interacts with

the user to provide guarantees of non-repudiation and

trust. The mapping of these security properties with

the requirements of Section 3 is analyzed in the fol-

lowing section to validate the approach as a whole and

to show its ﬁnal utility.

4.1 Mapping Requirements to

Architecture Layers

The Blockchain-based multisig system proposed in

Section 4 is now extended to map the requirements es-

Figure 2: Mapping requirements to functionality layers.

tablished in Section 3 to functionality layers. The idea

is to verify that all the requirements are widely ad-

dressed in accordance with the critical characteristics

of the application context. Precisely, Figure 2 charac-

terizes the aforementioned assignment and highlights

how the different layers of the architecture can work

together to fulﬁll critical aspects. In fact, by verifying

that IR, MR and AR are covered by speciﬁc subcom-

ponents, we can also be more conﬁdent that the sys-

tem will be able to meet the necessary conditions of

trust, transparency and usability.

More in details, we consider for the A-L sub-

components the following requirements:

• UI: Must allow users to track their transactions

and verify approvals (IR-1); each user action

(transaction initiation, approval) should be linked

to an identiﬁable entity (MR-1); UI should pro-

vide access to past transaction logs for compliance

veriﬁcation (MR-2); UI must offer real-time trans-

action status updates with minimal latency (AR-

1); and UI should be ﬂexible enough to support

different Blockchain networks (AR-2).

• CW: Ensures that private keys remain unchanged

and cannot be altered maliciously (IR-2); wal-

lets should be optimized for low-resource envi-

ronments such as mobile or (I)IoT scenarios (MR-

3); CW guarantees that once a signature is ap-

plied, the user cannot deny signing (MR-4); and

CW must support key recovery mechanisms for

resilience against user key loss (AR-4).

• TM: Transactions must be logged with identiﬁ-

able metadata (IR-1); users should be able to con-

ﬁrm the details before submission (IR-3); TM

should prevent incorrect or incomplete transac-

tions from being signed (MR-4); and TM should

allow seamless transaction creation without un-

necessary delays (AR-1).

Blockchain-Based Multi-Signature System for Critical Scenarios

225

About the SC-L requirements, each sub-

component guarantees the following:

• TVC: Once deployed, contract rules cannot be

altered to ensure consistency (IR-2); SC execu-

tion should be provable and independently au-

ditable (IR-3); transactions should only proceed

if all necessary conditions are cryptographically

validated (MR-4); and the contract must be resis-

tant to tampering and external attacks (AR-3).

• MSEC: Approvals must be logged transparently

on-chain (IR-1); each transaction should include

a record of both user and Blockchain signatures

(MR-1); ensures that transactions cannot be ex-

ecuted unless all required signatures are present,

Ipso Facto (MR-2); and signature aggregation

must be optimized for minimal gas costs (AR-1).

Thirdly, for the MSC-L, the matching require-

ments for each subcomponent are:

• KM: Secure storage prevents unauthorized key

modiﬁcations (IR-2); cryptographic key owner-

ship must be provable and auditable (MR-1); pri-

vate keys must be protected from attacks and

hardware failures (AR-3); and KM must imple-

ment backup and recovery mechanisms (AR-4).

• SA: Ensures that all aggregated signatures are cor-

rect and tamper-proof (IR-3); SA must efﬁciently

combine multiple signatures without excessive

computational overhead (AR-1); SA should sup-

port different multisig schemes and cryptographic

standards (AR-2)

• TV: Must log veriﬁcation steps for future au-

dits (IR-1); TV has to verify the multi-signatures

against stored public keys to conﬁrm authenticity

(MR-2); and TV ensures that an approved trans-

action cannot be disputed (MR-4).

As for the requirements of the B-L subcompo-

nents are as follows:

• CM: Must ensure that the transaction lifecycle

is fully recorded and veriﬁable (IR-1); it should

optimize resource usage while maintaining secu-

rity (IR-4). Moreover, each validated transaction

should be linked to a responsible signing entity

(MR-1); and CM should be resistant to Sybil at-

tacks and collusion (AR-3);

• IL: Ensures that once recorded, transactions can-

not be altered or removed (IR-2); IL must allow

all stakeholders to independently conﬁrm transac-

tion authenticity (IR-3); IL should support foren-

sic analysis and compliance auditing (MR-2); and

IL ensures transaction data remains available even

in case of network failures (AR-4).

If off-chain processing techniques are additionally

implemented outside the chain, it is also possible to

improve performance and scalability, reducing trans-

action costs and delays. All this also indicates that the

matching shown in Figure 2 can serve as an attractive

tool to guide future multi-signature approaches.

5 MAPPING TO SCENARIOS

After exploring the capabilities of DLTs and the

multi-signature service for trust, it is important to con-

sider how the approach is applied in real-world sce-

narios. Thus, the following subsections focus on delv-

ing into some examples of how these technologies can

be utilized in different scenarios (hereon as SC).

5.1 SC1 - Mobility

In mobility applications, DLT can be used for con-

gestion avoidance, trafﬁc safety, car leasing or sell-

ing, parking services, and insurance. Data shared by

vehicles can even facilitate the development of intel-

ligent trafﬁc lights for smart city approach (Elassy

et al., 2024). Energy management is another cru-

cial area where Blockchain can play a signiﬁcant role

in mobility scenarios, particularly with the rise of

electric and autonomous vehicles (Rana et al., 2024).

Proposed applications include managing access to

charging stations and controlling battery cycles in au-

tonomous cars. Likewise, Blockchain’s immutabil-

ity also allows for the secure recording of events re-

lated to vehicle use, such as driver identity and vis-

ited locations, which can aid in the development of

smart public transport systems (Jabbar et al., 2022).

Blockchain’s payment capabilities can also be used in

the mobility sector for services, such as payment at

charging stations and SC-based rental car platforms

(Dey et al., 2024). However, traditional database sys-

tems currently surpass Blockchains in terms of perfor-

mance due to their distributed nature and the immense

quantity of data produced by the context of applica-

tion itself, for example for consumption, user data,

charging, trafﬁc, control. The best-known current

Blockchain applications are capable of processing a

very low number of transactions compared to non-

distributed systems. Reducing this latency is there-

fore necessary to achieve compliance with AR-1 (Jab-

bar et al., 2022). In order to verify the applicability of

the approach proposed throughout this paper, we ex-

tend the scenario to two particular use cases for mo-

bility: (i) The ﬁrst one is related to ambulance coordi-

nation, and the (ii) the second one to insurance claim

processing.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

226

5.1.1 SC1a: Ambulance Coordination

In this ﬁrst case, a Blockchain-based multi-signature

system can be used for ambulance dispatch and route

authorization. The system ensures secure, transpar-

ent, and real-time decision-making among emergency

responders, hospitals, and trafﬁc control authorities.

In this subsection, we consider how the requirements

presented above are prioritized according to the char-

acteristics of this scenario and its level of criticality.

This means that the availability of control and coor-

dination operations takes precedence over other secu-

rity measures such as authentication or conﬁdential-

ity. For the sake of simplicity and space, we limit

the study to those requirements that have a higher or

medium impact in the context of application.

• Performance (AR-1) → High Priority: Am-

bulance dispatch requires real-time approval of

emergency routes, ensuring low-latency transac-

tion validation. The Blockchain must support fast

execution of SCs to approve emergency passages

through restricted areas.

• Decoupling (AR-2) → High Priority: The

Blockchain should be able to integrate with mul-

tiple health providers and regulatory frameworks

in order to be available for all the different actors

involved in such scenario.

• Survivability (AR-4) → High Priority: The system

must operate even during network failures to guar-

antee continuous emergency service availability.

Decentralized architecture ensures multiple nodes

retain transaction data, preventing data loss.

• Veriﬁability (IR-3) → High Priority: Authorities

(police, hospitals) must be able to verify route ap-

provals without relying on a central entity. The

system should provide tamper-proof proof of au-

thorization to prevent fraud.

• Accountability (MR-1) → Medium Priority: Ev-

ery signed transaction (e.g., dispatch approval,

route modiﬁcation) should be linked to an iden-

tiﬁable entity.

• Resilience (AR-3) → Medium Priority: The sys-

tem should be fault-tolerant against cyber-attacks

or system overloads during crises.

5.1.2 SC1b: Insurance Claim Processing

In this second case, we can state that a Blockchain

multisig system can be implemented for automating

and verifying insurance claim processing. SCs vali-

date accident reports, driver liability, and policy cov-

erage, ensuring secure and transparent processing. As

discussed for the ﬁrst case, we now explore the re-

quirements and priorities for the scenario.

• Non-Repudiation (MR-4) → High Priority:

Drivers, insurance companies, and law enforce-

ment must sign transactions related to accident re-

ports. A cryptographic proof of signatures ensures

no party can later deny involvement.

• Traceability (IR-1) → High Priority: Every step

of the claim process (accident reporting, damage

assessment, claim approval) should be logged and

veriﬁable. Prevents fraud by ensuring immutable

transaction history.

• Auditing (MR-2) → High Priority: Regulators and

auditors must be able to verify all claims to pre-

vent fraudulent insurance payouts.

• Decoupling (AR-2) → Medium Priority: The sys-

tem should be ﬂexible to integrate with different

insurance providers and governmental authorities.

• Performance (AR-1) → Medium Priority: While

real-time performance is not as critical as in emer-

gency response, the system must process claims

efﬁciently to reduce delays.

5.2 SC2: ENERGY

As the focus on the renewable energy sources has

increased, the energy market has also shifted into a

distributed market where renewable energy is traded.

Due to this effect, the number of Blockchain-based

solutions designed for the energy sector has grown

in the last years (Ma et al., 2024). In addition, car-

bon emission trading systems and green certiﬁcates

rely on Blockchain attributes, such as transparency

and immutable data recording, to establish a reliable

market (Prawitasari et al., 2024). In this scenario,

Blockchain can be useful to control the decentral-

ized grid and effectively solve the problem of control

the output power reasonably to avoid unstable volt-

age on the grid produced by the excess of power in

different nodes of the grid. Smart contracts can also

be a solution to detect the real power consumption

of users and evaluate the agreed contracts, automat-

ically giving incentives or punishments to the users

(Su et al., 2024). Nevertheless, despite the leverage

of recording the data consumption in the distributed

ledger for the study of the real consumption, the pub-

lic nature of the Blockchain brings privacy concerns

about consumer’s daily activity patterns (Joshi et al.,

2018). Another approach is the implementation of

distributed auction systems permit buyers and sell-

ers complete reliable, safe and transparent auctions.

Moreover, the auction payments process can be au-

tomatized by the deployment of smart contracts and

Blockchain-Based Multi-Signature System for Critical Scenarios

227

electricity ﬂows can be detected to verify that the

transactions are completed successfully (Chitra et al.,

2023). Back to the privacy concerns, a distributed en-

ergy system based on tokens is proposed (Mehdine-

jad et al., 2022). Therefore, consumers can nego-

tiate electricity prices anonymously, protecting their

personal information during the transactions. To sum

up, Blockchain’s transparency and immutable record

beneﬁt carbon emission trading and green certiﬁcates

and also offers solutions for grid control, power con-

sumption monitoring, and decentralized energy auc-

tions. However, privacy concerns arise due to the

public nature of Blockchain (Hewa et al., 2021). As

addressed for mobility, we now discuss how the re-

quirements presented earlier can be prioritized in the

energy sector case. In this case, a Blockchain-based

multi-signature system is deployed for energy trading

and decentralized grid management. The system fa-

cilitates peer-to-peer energy transactions, while guar-

anteeing secure, auditable and sustainable operations

without a signiﬁcant impact on control. Here, the con-

sidered requirements are the following.

• Sustainability (IR-4) → High Priority:

Blockchain technology should use energy-

efﬁcient consensus mechanisms to align with

green energy goals.

• Resilience (AR-3) → High Priority: The system

must withstand cyberattacks or technical failures

to maintain continuous energy distribution. More-

over, the decentralized grid must operate even if

individual nodes fail.

• Immutability (IR-2) → High Priority: Energy

transactions must be tamper-proof to prevent

fraud or unauthorized modiﬁcations.

• Auditing (MR-2) → High Priority: Regulators and

consumers should be able to verify transactions

for transparency in energy pricing and distribu-

tion.

• Performance (AR-1) → Medium Priority: While

real-time execution is not as critical as in mobility,

energy trading systems should still process trans-

actions efﬁciently to avoid delays.

• Decoupling (AR-2) → Medium Priority: The

Blockchain should be able to integrate with multi-

ple energy providers and regulatory frameworks.

5.3 Final Discussions

Previous studies state that the most relevant require-

ments for critical scenarios (SC1a and SC2) are those

related to AR-1, AR-2 and AR-3 (see Table 1), and

therefore related to performance, decoupling and re-

silience, as also stated in (Alcaraz and Lopez, 2012);

whereas for the rest of scenarios (and beyond AR-1,

AR-2 and AR-3), MR-2 (audit) is the most prominent.

In addition, looking at the most prominent require-

ments, we also note that the majority fall under the

“AR” requirement class, which once again indicates

that the type and nature of the scenario are fundamen-

tal when designing DLT-assisted approaches. In fact,

the deployment of DLT and its respective solutions

must be solutions that help improve the operational

functions of each scenario, but not become a burden

that affects the performance and effectiveness of those

scenarios. Therefore, for SC1a and SC2, and prior-

itizing their critical nature, it is recommended that

the following services be optimized for future designs

and implementations.

Table 1: Identifying relevant requirements at layer level.

App

AR-1

AR-2

AR-3

AR-4

MR-1

MR-2

MR-4

IR-1

IR-2

IR-3

IR-4

SC1a X X X X X X

SC1b X X X X X

SC2 X X X X X X

Now, considering AR-[1-3] and MR-2, Table

2 shows the subcomponents or services of the

Blockchain and the multisig systems that should be

optimized in relation to them, giving priority to those

related to the user interface, followed by MSEC and

SA. This result is quite reasonable, since the main use

of the approach is to show its multisig capacity based

on DLT. The approach could lose its real usefulness if

it does not provide attractive interfaces to manage the

signing capabilities, and accessbility to the end user.

Table 2: Identifying relevant requirements at service level.

Reqs

TVC

MSEC

AR-1 X X X X

AR-2 X X

AR-3 X X X

MR-2 X X X X

Beyond this theoretical demonstration, in the fol-

lowing section we show the usefulness of the ap-

proach from a practical point of view and for the three

use case scenarios (SC1a, SC1b, SC2).

6 PRACTICAL VIEW

This section provides the JSON and Solidity codes to

integrate and demonstrate the real applicability of the

approach for automating multi-signatures for critical

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

228

scenarios. The solidity codes are available at Github

because for space limitations we only provide here the

description and a portion of the code. On the other

hand, we have divided this section into three chief

subsections: (i) one devoted to SC1a on emergency

services and its coordination, (ii) SC1b on insurance

management, and (iii) SC2 for energy management

6.1 SC1a: Ambulance Coordination

As mentioned above, emergency medical services can

apply Blockchain systems with multiple signatures

to authorize ambulance movement through restricted

zones (e.g., toll roads, trafﬁc lights, restricted lanes).

The hospital, trafﬁc authority, and Blockchain system

must approve the route before execution.

6.1.1 JSON for Contextual Conditions

Listing 1 represents a piece of JSON code about an

ambulance requesting access to restricted roads, with

multiple signatures required before authorization. Ba-

sically, the JSON represents a structured request for

an emergency vehicle to access restricted routes. In

this system, an ambulance submits a request contain-

ing a unique identiﬁer, along with details about its

origin and destination, specifying the planned route

with multiple checkpoints. Each checkpoint requires

approval from three key entities: the hospital initiat-

ing the request, the trafﬁc authority overseeing road

access, and the Blockchain system that ensures com-

pliance and security. The transaction remains in an

"Awaiting Signatures" state until all required parties

have signed off, ensuring that only authorized emer-

gency vehicles receive clearance. Thus, by leveraging

the Blockchain-based multisig mechanism, it guaran-

tees that all approvals are traceable, immutable, and

veriﬁable, facilitating real-time decision-making for

emergency responses.

Listing 1: JSON for Ambulance Scenario.

{" r e q u e s t _ i d " : " AMB_12345 " ,

" amb u l a n c e _ i d " : "AMB_001 " ,

" h o s p i t a l _ i d " : " HOSP_789 " ,

" r o u t e " : [ { " c h e c k p o i n t " : " T o l l Road 2 3 " ,

" s t a t u s " : " Pend i n g " } ,

{" c h e c k p o i n t " : " R e s t r i c t e d La ne A5 " ,

" s t a t u s " : " Pend i n g " } ] ,

" s i g n a t u r e s " : { " h o s p i t a l " : f a l s e ,

" t r a f f i c _ a u t h o r i t y " : f a l s e ,

" b l o c k c h a i n " : f a l s e } ,

" s t a t u s " : " Awa i t i n g S i g n a t u r e s " ,

" tim e s t a m p " : "2025 −02 −26 T12 : 0 0 : 0 0 Z " }

https://github.com/ferrarisUMA/SECRYPTPaper

6.1.2 Solidity for Smart Contract

In the Github, an example of a Solidity SmC is found,

implementing a multi-signature mechanism for the

ambulance coordination scenario; and Listing 2 illus-

trates a portion of such a speciﬁcation.

Listing 2: Solidity Code for Ambulance Scenario (Portion).

C o n t r a c t A m b u l a n c e A u t h o r i z a t i o n {

a d d r e s s p u b l i c h o s p i t a l ;

a d d r e s s p u b l i c t r a f f i c A u t h o r i t y ;

a d d r e s s p u b l i c b l o c k c h a i n A u t h o r i t y ;

a d d r e s s p u b l i c ambul a n c e ;

s t r u c t R o u t e R e q u e s t {

s t r i n g r e q u e s t I d ; s t r i n g a m b u l a n c e I d ;

b o o l h o s p i t a l A p p r o v e d ; b o o l t r a f f i c A p p r o v e d ;

b o o l b l o c k c h a i n A p p r o v e d ; b o o l e x e c u t e d ; }

mappin g ( s t r i n g => R o u t e R e q u e s t ) p u b l i c r e q u e s t s ;

e v e n t R o u t e R e q u e s t e d ( s t r i n g r e q u e s t I d ,

s t r i n g a m b u l a n c e I d ) ;

e v e n t RouteAppr o v e d ( s t r i n g r e q u e s t I d ,

a d d r e s s a p p r o v e r ) ;

e v e n t R o u t e E x e c u t ed ( s t r i n g r e q u e s t I d ) ; }

/ / F o r + i n f o : I n o u r G i t h u b

The developed Solidity SmC for this scenario is

designed to facilitate and regulate emergency vehi-

cle access in urban environments. This contract de-

ﬁnes a structure for emergency access requests, each

containing an ambulance ID, route details, and the re-

quired multi-signatures from the key entities showed

before in the JSON code: the hospital, the trafﬁc au-

thority, and the Blockchain itself. The contract en-

sures that a transaction remains pending until all nec-

essary parties sign it, guaranteeing compliance and

security. Once the required signatures are collected,

the transaction is executed, granting the ambulance

access to restricted routes. The SmC also maintains

a log of all approved requests, ensuring traceability

and accountability. The use of Blockchain and mul-

tisig validation eliminates unauthorized access while

enabling swift, automated clearance for emergencies.

6.2 SC1b: Insurance Claim Processing

Here, we consider how our approach can be useful

after a car accident, where drivers, police ofﬁcers,

and insurance companies must verify the claim before

compensation is processed. The Blockchain ensures

non-repudiation, traceability, and transparency.

6.2.1 JSON for Contextual Conditions

Listing 3 represents an insurance claim request in

JSON where multiple signatures (from driver, police,

and insurer) are needed to approve the claim. The

JSON code deﬁnes an automated process for han-

Blockchain-Based Multi-Signature System for Critical Scenarios

229

dling vehicle accident claims. When a driver sub-

mits a claim, the request is linked to a unique ID

and includes supporting details such as accident lo-

cation, timestamp, and involved parties. Veriﬁcation

is a multi-step process that requires digital signatures

from the driver, a police ofﬁcer validating the inci-

dent, and the insurance company that must approve

compensation. The Blockchain ensures that no claim

can be altered or repudiated, preventing fraud and en-

suring accountability. The transaction is marked as

"Awaiting Signatures" until all necessary approvals

are recorded. Once fully signed, the claim is executed

and stored on the Blockchain, providing a transparent

and tamper-proof history of insurance transactions.

Listing 3: JSON for Insurance Scenario.

{" c l a i m _ i d " : " CLAIM_98765 " ,

" d e t a i l s " : " D e t a i l s o f t h e e v e n t " ,

" d r i v e r _ i d " : " DRV_456 " ,

" p o l i c e _ r e p o r t " : { " o f f i c e r _ i d " : "POL−789 " ,

" s t a t u s " : " Pend i n g " } ,

" i n s u r a n c e _ a p p r o v a l " : {" i n s u r e r _ i d " : " INS −1 2 3" ,

" s t a t u s " : " Pend i n g " } ,

" b l o c k c h a i n _ v e r i f i c a t i o n " : { " v e r i f i e d " : f a l s e } ,

" s t a t u s " : " Awa i t i n g S i g n a t u r e s " ,

" tim e s t a m p " : "2025 −02 −26 T12 : 0 0 : 0 0 Z " }

6.2.2 Solidity for Smart Contract

Both Listing 4 and the aforementioned Github con-

tain the corresponding SmC (in Solidity), developing

a multisig mechanism for the insurance claims pro-

cessing scenario. The Solidity SmC automates and

secures the vehicle accident claim process. When

a claim is initiated, the contract registers key de-

tails such as the claimant’s identity, accident speciﬁcs,

and the claim amount. The claim must then be ap-

proved by three parties: the driver (who submits the

claim), the police (who veriﬁes the accident’s occur-

rence), and the insurance company (which authorizes

the compensation). The multisig mechanism ensures

that all required entities validate the claim before any

payout is processed, preventing fraudulent submis-

sions and enforcing accountability. Once all signa-

tures are obtained, the contract ﬁnalizes the claim, re-

leasing funds to the claimant and immutably storing

the transaction on the Blockchain. This decentralized

approach enhances transparency, reduces processing

time, and eliminates disputes over claim legitimacy.

Listing 4: Solidity Code for Insurance Scenario (Portion).

C o n t r a c t I n s u r a n c e C l a i m {

a d d r e s s p u b l i c d r i v e r ;

a d d r e s s p u b l i c p o l i c e ;

a d d r e s s p u b l i c i n s u r e r ;

s t r u c t C laim {

s t r i n g c l a i m I d ;

b o o l p o l i c e A p p r o v e d ; b o o l i n s u r e r A p p r o v e d ;

b o o l b l o c k c h a i n V e r i f i e d ; b o o l e x e c u t e d ; }

mappin g ( s t r i n g => Cl aim ) p u b l i c c l a i m s ;

e v e n t C l a i m S u b m i t t e d ( s t r i n g c l a i m I d ,

s t r i n g d r i v e r ) ;

e v e n t Clai m A pprove d ( s t r i n g c l a i m I d ,

a d d r e s s a p p r o v e r ) ;

e v e n t C l a i m P r o c e s s e d ( s t r i n g c l a i m I d ) ; }

/ / F o r + i n f o : I n o u r G i t h u b

6.3 SC2: Energy

In this use case, we consider a peer-to-peer energy

trading system where households with solar panels

sell excess energy to neighbors using a Blockchain-

based platform ensuring secure and transparent trans-

actions. Thus, a household (seller) initiates an energy

trade by specifying the amount of energy and price. A

neighbor (buyer) agrees to the terms. The Blockchain

validates the trade against predeﬁned rules (i.e. en-

ergy availability, grid capacity). It also checks that

the buyer’s payment is deposited into a SmC escrow.

Once validated, the Blockchain signs the transaction.

Then, after the energy is transferred, the buyer con-

ﬁrms receipt by signing the transaction. Following

this scheme, we assure that the signatures of both the

Blockchain and buyer are aggregated, authorizing the

payment to the seller. For auditing, the immutable

ledger logs the transaction for regulatory and billing

purposes. Moreover, this approach increases trans-

parency and accountability in energy markets.

6.3.1 JSON for Contextual Conditions

Listing 5 illustrates the corresponding JSON code,

representing a decentralized energy transaction where

a user buys energy from a peer-to-peer energy trad-

ing platform, applying the multisig concept for trans-

action authorization. Speciﬁcally, the JSON struc-

ture characterizes an energy producer, such as a solar

panel owner, selling surplus electricity to a consumer.

The producer initiates the transaction by specifying

the amount of energy available and the price per unit.

The consumer then places a purchase request, and

the Blockchain validates the agreement before exe-

cuting the trade. Before completion, the transaction

requires multisig approvals from the producer, con-

sumer, and the Blockchain system to ensure compli-

ance with sustainability and accountability standards.

The entire transaction process is recorded immutably,

providing a transparent and auditable history of en-

ergy exchanges. Through Blockchain and multisig

veriﬁcation, this approach guarantees trust, reduces

reliance on centralized intermediaries, and enhances

efﬁciency in decentralized energy markets.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

230

Listing 5: JSON for Ennergy Scenario.

{" t r a n s a c t i o n " : {

" i d " : " ene r gyT x n78 9 0 " ,

" bu y e r " : {

" i d " : " u s e r 1 2 3 " , " name " : " J oh n " ,

" Wa l l e t A d d r e s s " : " 0 x B u y e r W a l l e t A d d r e s s " } ,

" s e l l e r " : {

" i d " : " p r o d u c e r 4 5 6 " , " name " : " S o l a rFarm I n c . " ,

" Wa l l e t A d d r e s s " : " 0 x S e l l e r W a l l e t A d d r e s s " } ,

" e n e r g y D e t a i l s " : {

" q u a n t i t y " : " 5 0 KWh" ,

" p r i n c e P e r U n i t " : " 0 . 0 2 ETH " ,

" m u l t i S i g a t u r e " : {

" r e q u i r e d S i g n a t u r e s " : 2 ,

" s i g n a t u r e s " : [

{" s i g n e r " : " 0 x P l a t f o r m W a l l e t A d d r e s s " ,

" S i g n a t u r e " : " 0 x S i g n a t u r e F r o m P l a t f o r m " } ,

{" s i g n e r " : " 0 x B u y e r W a l l e t A d d r e s s " ,

" S i g n a t u r e " : " 0 x S i g n a t u r e F r o m B u y e r " } ] } ,

" s t a t u s " : " Co mp l ete d " ,

" ti m e s t a m p " : "2025 − 02 −08 T14 :3 0 : 0 0 Z "}}

6.3.2 Solidity for Smart Contract

Both Listing 6 and the Solidity SmC include the

code parts, which integrates the multisig approach for

trading energy between a buyer and a seller through

a Blockchain. The SmC enables a decentralized

peer-to-peer energy market where producers and con-

sumers engage in trustless transactions. The con-

tract records offers from producers specifying energy

availability and pricing, allowing consumers to place

purchase requests. A transaction is executed only

when three signatures are provided: the producer, the

consumer, and the Blockchain, which veriﬁes com-

pliance with predeﬁned regulations (such as sustain-

ability standards or maximum trading limits). The

contract guarantees that energy trades are fair, trans-

parent, and immutable. Upon completion, the energy

transfer is recorded permanently on the Blockchain,

allowing for auditing and regulatory oversight. Cer-

tainly, the multisig mechanism ensures that neither

party can manipulate the transaction, creating a secure

and efﬁcient energy marketplace without the need for

centralized intermediaries.

7 CONCLUSIONS

This paper presented a Blockchain-based multisig

system designed to enhance security, transparency,

and trust in critical scenarios. By integrating user

conﬁrmations with Blockchain-generated signatures,

the proposed architecture has four layers and ensures

several key requirements such as performance, re-

silience, and auditing in transaction processing. Such

system was applied to two key sectors: Mobility and

Energy trading. The ambulance coordination use case

demonstrated how the framework enables real-time

decision-making in emergency services, while the in-

surance claim processing use case highlighted its role

Listing 6: Solidity Code for Energy Scenario (Portion).

C o n t r a c t E n e r g y T r a d i n g M u l t i S i g {

s t r u c t E n e r g y T r a n s a c t i o n {

a d d r e s s b u y e r ; a d d r e s s s e l l e r ;

u i n t 2 5 6 q u a n t i t y ; u i n t 2 5 6 p r i c e P e r U n i t ;

b o o l p l a t f o r m S i g n e d ; b o o l b u y e r S i g n e d ;

b o o l Co mpl ete d ; }

ma pp ing ( u i n t 2 5 6 => E n e r g y T r a n s a c t i o n )

p u b l i c t r a n s a c t i o n ;

a d d r e s s p u b l i c p l a t f o r m ;

u i n t 2 5 6 p u b l i c t r a n s a c t i o n C o u n t e r ;

e v e n t T r a n s a c t i o n C r e a t e d ( u i n t 2 5 6 t r a n s a c t i o n I d ,

a d d r e s s b uye r ,

a d d r e s s s e l l e r ,

u i n t 2 5 6 q u a n t i t y ,

u i n t 2 5 6 p r i c e P e r U n i t ) ;

e v e n t T r a n s a c t i o n S i g n e d ( u i n t 2 5 6 t r a n s a c t i o n I d ,

a d d r e s s s i g n e r ) ;

e v e n t T r a n s a c t i o n C o m p l e t e d ( u i n t 2 5 6 t r a n s a c t i o n I d ,

a d d r e s s s e l l e r ) ;

c o n s t r u c t o r ( a d d r e s s _ p l a t f o r m ) { p l a t f o r m = _ p l a t f o r m ; }

m o d i f i e r o n l y P l a t f o r m ( ) {

r e q u i r e d ( msg . s e n d e r == p l a t f o r m ,

" Only p l a t a f o r m c an p e r f o r m t h i s a c t i o n " ) ; }

f u n c t i o n c r e a t e T r a n s a c t i o n ( a d d r e s s _ b u y e r ,

a d d r e s s _ s e l l e r , u i n t 2 5 6 _ q u a n t i t y ,

u i n t 2 5 6 _ p r i c e P e r U n i t ) }

in fraud prevention and transparent claim veriﬁcation.

Additionally, the energy trading scenario showcased

how the architecture supports decentralized energy

markets. Future work will focus on evaluating the ar-

chitecture across different Blockchain platforms, such

as Ethereum, Solana, and Hyperledger, to identify the

most suitable solution in terms of efﬁciency, scalabil-

ity, and regulatory compliance.

ACKNOWLEDGEMENTS

This work has been partially supported by two

EU projects under GA No: 101086308 (DUCA,

HORIZON-MSCA-2021-SE-01) and 101131292

(AIAS, HORIZON-MSCA-2022-SE-01); and by the

two following national projects: 5G+TACTILE_4

(NEXTGENERATION.UE, Spanish UNICO 5G

I+D) under Grant TSI-063000-2021-26, and SECAI

funded by the MCIN/AEI 10.13039/501100011033

and FSE+ under the Grant PID2022-139268OB-I00.

REFERENCES

Aitzhan, N. Z. and Svetinovic, D. (2016). Security

and privacy in decentralized energy trading through

multi-signatures, blockchain and anonymous messag-

ing streams. IEEE transactions on dependable and

secure computing, 15(5):840–852.

Alcaraz, C., Agudo, I., nez, D. N., and Lopez, J. (2011).

Managing incidents in smart grids à la cloud. In IEEE

CloudCom 2011, pages 527–531, Athens, Greece.

IEEE Computer Society.

Alcaraz, C. and Lopez, J. (2012). Analysis of requirements

Blockchain-Based Multi-Signature System for Critical Scenarios

231

for critical control systems. International journal of

critical infrastructure protection, 5(3-4):137–145.

Alcaraz, C. and Lopez, J. (2014). WASAM: A dynamic

wide-area situational awareness model for critical do-

mains in smart grids. Future Generation Computer

Systems, 30:146–154.

Alcaraz, C., Rubio, J. E., and Lopez, J. (2020). Blockchain-

assisted access for federated smart grid domains: Cou-

pling and features. Journal of Parallel and Distributed

Computing, 144:124–135.

Boneh, D., Drijvers, M., and Neven, G. (2018). Compact

multi-signatures for smaller blockchains. In Interna-

tional Conference on the Theory and Application of

Cryptology and Information Security, pages 435–464.

Springer.

Buhler, M. (2025). Enhancing multi-signature cryptocur-

rency wallets with risk-based authentication.

Chitra, T., Ferreira, M. V., and Kulkarni, K. (2023). Cred-

ible, optimal auctions via blockchains. Cryptology

ePrint Archive.

Dey, A. K., Gope, B., and Mandal, B. K. (2024). Applica-

tions of blockchain for future mobility. In Blockchain

Technology in the Automotive Industry, pages 147–

157. CRC Press.

Dohler, M., Lopez, D. R., and Wang, C. (2024).

Blockchains in 6G: A Standardized Approach to Per-

missioned Distributed Ledgers. CRC Press.

Elassy, M., Al-Hattab, M., Takruri, M., and Badawi, S.

(2024). Intelligent transportation systems for sustain-

able smart cities. Transportation Engineering, page

100252.

Gai, K., Wang, S., Zhao, H., She, Y., Zhang, Z., and Zhu, L.

(2022). Blockchain-based multisignature lock for uac

in metaverse. IEEE Transactions on Computational

Social Systems, 10(5):2201–2213.

Gupta, A., Gupta, R., Jadav, D., Tanwar, S., Kumar, N., and

Shabaz, M. (2023). Proxy smart contracts for zero

trust architecture implementation in decentralised or-

acle networks based applications. Computer Commu-

nications, 206:10–21.

Hewa, T. M., Hu, Y., Liyanage, M., Kanhare, S. S., and

Ylianttila, M. (2021). Survey on blockchain-based

smart contracts: Technical aspects and future re-

search. IEEE Access, 9:87643–87662.

Jabbar, R., Dhib, E., Said, A. B., Krichen, M., Fetais, N.,

Zaidan, E., and Barkaoui, K. (2022). Blockchain tech-

nology for intelligent transportation systems: A sys-

tematic literature review. IEEE Access, 10:20995–

21031.

Joshi, A. P., Han, M., and Wang, Y. (2018). A survey on

security and privacy issues of blockchain technology.

Mathematical foundations of computing, 1(2).

Kara, M., Laouid, A., and Hammoudeh, M. (2023). An ef-

ﬁcient multi-signature scheme for blockchain. Cryp-

tology ePrint Archive.

Kuznetsov, O., Sernani, P., Romeo, L., Frontoni, E., and

Mancini, A. (2024). On the integration of artiﬁcial

intelligence and blockchain technology: a perspective

about security. IEEE Access, 12:3881–3897.

Lin, K.-P., Chang, Y.-W., Wei, Z.-H., Shen, C.-Y., and

Chang, M.-Y. (2019). A smart contract-based mobile

ticketing system with multi-signature and blockchain.

In 2019 IEEE 8th Global Conference on Consumer

Electronics (GCCE), pages 231–232. IEEE.

Lopez, J., Alcaraz, C., and Roman, R. (2013). Smart control

of operational threats in control substations. Comput-

ers & Security, 38:14–27.

Ma, C.-Q., Lei, Y.-T., Ren, Y.-S., Chen, X.-Q., Wang, Y.-

R., and Narayan, S. (2024). Systematic analysis of

the blockchain in the energy sector: Trends, issues,

and future directions. Telecommunications Policy,

48(2):102677.

Mehdinejad, M., Shayanfar, H., and Mohammadi-Ivatloo,

B. (2022). Decentralized blockchain-based peer-

to-peer energy-backed token trading for active pro-

sumers. Energy, 244:122713.

Narayanan, A. (2016). Bitcoin and cryptocurrency tech-

nologies: a comprehensive introduction. Princeton

University Press.

Prawitasari, P. P., Nurmalasari, M. R., and Kumalasari, P. D.

(2024). Blockchain technology in the carbon mar-

ket: Enhancing transparency and trust in emissions

trading. Jurnal Revenue: Jurnal Ilmiah Akuntansi,

5(2):1495–1521.

Rana, M. T., Numan, M., Yousif, M., Hussain, T., Khan,

A. Z., and Zhao, X. (2024). Enhancing sustainabil-

ity in electric mobility: Exploring blockchain applica-

tions for secure ev charging and energy management.

Computers and Electrical Engineering, 119:109503.

Roy, A. and Karforma, S. (2012). A survey on digital sig-

natures and its applications. Journal of Computer and

Information Technology, 3(1):45–69.

Saad, S. M. S., Radzi, R. Z. R. M., and Othman, S. H.

(2021). Comparative analysis of the blockchain con-

sensus algorithm between proof of stake and delegated

proof of stake. In 2021 International Conference on

Data Science and Its Applications (ICoDSA), pages

175–180. IEEE.

Saurabh, K., Rani, N., and Upadhyay, P. (2024). To-

wards novel blockchain decentralised autonomous

organisation (dao) led corporate governance frame-

work. Technological Forecasting and Social Change,

204:123417.

Su, X., Hu, Y., Liu, W., Jiang, Z., Qiu, C., Xiong, J.,

and Sun, J. (2024). A blockchain-based smart con-

tract model for secured energy trading management in

smart microgrids. Security and Privacy, 7(1):e341.

Xiao, Y., Zhang, P., and Liu, Y. (2020). Secure and ef-

ﬁcient multi-signature schemes for fabric: An enter-

prise blockchain platform. IEEE Transactions on In-

formation Forensics and Security, 16:1782–1794.

Zhang, C., Liao, W., Liu, X., Wu, H., and Alenazi, M. J.

(2025). A multi-signature scheme for defending mal-

leability attack on deﬁ. IEEE Access.

Zhuk, A. (2025). Beyond the blockchain hype: addressing

legal and regulatory challenges. SN Social Sciences,

5(2):1–37.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

232