Secure and Practical Cold (and Hot) Staking

Mario Larangeira

1,2 a

Institute of Science Tokyo, School of Computing, Ookayama 2-12-1, Meguro-ku, Tokyo, Japan

Input Output Global (IOG), Singapore

Keywords:

Delegated Proof of Stake, Stake Delegation, Hardware Wallet, Hot Wallet, Cold Wallet.

Abstract:

The stake delegation technique is what turns the general Proof of Stake (PoS) into a practical protocol for a

large number of participants, ensuring the security of the distributed system, in what is known as Delegated

PoS (DPoS). Karakostas et al. (SCN ’20) formalized the delegation method paving the way for a whole

industry of stake pools by proposing a formal deﬁnition for wallet as a universal composable (UC) functionality

and introducing a corresponding protocol. On the other hand, a widely used technique named hot/cold wallet

was formally studied by Das et al. (CCS ’19 and ’21), and Groth and Shoup (Eurocrypt ’22) for different key

derivation methods in the Proof of Work (PoW) setting, but not PoS. Brieﬂy, while hot wallets are exposed

to the risks of the network, the cold wallet is kept ofﬂine, thus more secure. However this may impair some

capabilities given that the cold wallet is kept indeﬁnitely ofﬂine. It is straightforward to observe that this

“double wallet” design is not naturally portable to the setting where delegation is paramount, i.e., DPoS. This

work identiﬁes challenges for PoS Hot/Cold Wallet and proposes a secure and practical protocol.

1 INTRODUCTION

The notion of “addresses” transacting with each other

was popularized by Bitcoin. Each address is the hash

value of the ECDSA veriﬁcation key. In comparison

with Proof of Work (PoW), typically, Proof of Stake

(PoS) systems are more intensive in the use of crypto-

graphic machinery. For example, whereas PoW relies

mostly on signature scheme and hash function, gener-

ally PoS systems rely also in certiﬁcates (for delega-

tion) and Veriﬁable Random Functions for committee

and leader elections. (Karakostas et al., 2020) was the

ﬁrst to propose a universally composable wallet, fol-

lowing the Universally Composability (UC) Frame-

work, for PoS. This development is foundational for

Delegated PoS and it has led to the appearance of a

stake pool economy with thousands of nodes under-

pinning the Cardano Blockchain. An example of the

wallet design framework with its security supported

by thousands of stake pools (Cardano, 2024).

On the other hand, Ethereum has chosen a rather

different approach for its migration from PoW to PoS,

i.e., Ethereum 2.0. It relies on users allocating their

stakes, and blocking them during a period of time,

a signiﬁcant change from (Karakostas et al., 2020),

where the user can freely transact their tokens and the

https://orcid.org/0000-0001-7168-898X

systems acknowledges the amount of stake distribu-

tion during leader election. The DPoS setting is sig-

niﬁcantly different from the PoW one as (Karakostas

et al., 2020) remarks. It seems the wallet security

from one setting could not be trivially adapted to the

other. An example is the hot/cold technique formal-

ized in (Das et al., 2019, Das et al., 2021) which, in a

nutshell, allows the combination of two wallets: one

with network access, hence the hot wallet, and the

cold wallet, isolated and therefore secure. The crucial

point is that the hot wallet can generate new cold wal-

let addresses in an “on demand” fashion, keeping the

cold wallet ofﬂine via key derivation. How the delega-

tion of the cold wallet, deﬁned for PoW, where most

of the funds are stored, works is unclear in DPoS.

This restriction refrains the cold wallet from

spending, or be drained from in the case of an attack,

the stored funds, because the wallet never comes on-

line. However, given the ingenious design of the key

derivation (Das et al., 2019, Das et al., 2021), the per-

manently ofﬂine state does not refrain the cold wallet

of receiving new funds. Furthermore, the cold wal-

let is often a hardware wallet given its typical extra

security features. However it is not a mandatory re-

quirement. That is the cold wallet can be a regular

(ofﬂine) software client.

Such Hot/Cold approach for PoS based wallets,

Larangeira, M.

Secure and Practical Cold (and Hot) Staking.

DOI: 10.5220/0013458200003979

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

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

339

like those in (Karakostas et al., 2020), still remains

unexplored. This literature gap is surprising given

the startling design differences between the wallets

in (Karakostas et al., 2020) and Bitcoin. In the light of

the former, the addresses also encode a richer set of at-

tributes, given is heavy use cryptographic machinery,

and this capability does exist for regular ECDSA PoW

addresses. Therefore it is far from clear whether the

security analysis of (Das et al., 2019, Das et al., 2021),

which is based solely for PoW paradigm, preserves

the security properties for DPoS setting, as shown

in (Karakostas et al., 2020). The very question

“How to perform the hot and

cold wallet technique in DPoS?”

remains not fully answered. This works ﬁlls this gap.

DPoS Cold/Hot Staking Challenges. In the single

wallet setting, a hot wallet setting, it is straightfor-

ward to receive the rewards and perform delegation

and redelegation as it is a matter of issuing a new

certiﬁcate with a new signature. In the case of dou-

ble wallet setting, forwarding the rewards would be

straightforward since it is trivial to assign the rewards

target, in the certiﬁcate, to the address of the cold wal-

let, i.e., a cold address. On the other hand, it is un-

clear how the funds of the cold wallet can be staked

since the signature in the certiﬁcate corresponds to

the hot wallet. The early cited limitations suggest a

major rework on the delegation framework proposed

in (Karakostas et al., 2020) to accommodate hot/cold

wallet setting is necessary. It is also paramount that a

novel design does not void the security guarantees of-

fered by that work. Thus, our early outlined research

question can be translated to the following questions

• Cold Stake Delegation. How the stake of the cold

wallet is delegated, if the hot wallet signs the cer-

tiﬁcate?

• Rewards Payment. How rewards are payed to the

cold wallet?

• Cold Stake Redelegation. How redelegation is

done? Does it require the cold wallet to be online?

• Composable Security. Does a new hot/cold wal-

let construction design realizes the functionality

in (Karakostas et al., 2020)?

Related Works. As brieﬂy described, (Karakostas

et al., 2020) proposed a thorough formalization of

the addresses syntax and delegation method for PoS

ledgers. In particular, its addresses system supports

attributes embedded into the address strings. More-

over, it introduces two types of keys for (1) signing

transactions and (2) performing stake delegation. In

the PoW setting, the hot/cold wallet was ﬁrst studied

by Das et al. (Das et al., 2019) in the setting of de-

terministic wallets (Maxwell et al., 2014), and their

work focused on the key derivation of the ECDSA

signature scheme which is widely employed for trans-

actions in blockchain systems and, in particular, their

stateful deterministic wallet design. In a follow up

work, Das et al. (Das et al., 2021) presented a formal

security analysis of the BIP32 wallet standard as it is.

This work build upon the security model intro-

duced in (Das et al., 2019). Despite of not mandatory,

the cold wallet is often a hardware wallet, i.e., piece

of hardware with extra countermeasures against side-

channels. Such class of wallets also received a formal

treatment in (Arapinis et al., 2019) by Arapinis et al.

in the UC Framework. Finally a spendable cold wal-

let was, in fact, proposed with hardware aid (Dowsley

et al., 2022), i.e., optical channel, and is based in (Das

et al., 2019). Unfortunately it is not designed for the

DPoS setting. Nonetheless, the hardware aid could be

adapted for the use in DPoS.

Our Contribution. In a nutshell, this work inves-

tigates the feasibility of relying on a similar design

to the Hot/Cold Wallet in the DPoS setting. As a

main requirement in this investigation, it is neces-

sary to identify possible shortcomings in porting the

Hot/Cold design from PoW to DPoS in current de-

signs. Given this ﬁrst step, we proceed in constructing

a possible wallet/delegation framework to overcame

such shortcomings. Our contribution is three fold

• to identify limitations of the current Hot/Cold Wal-

let design (Das et al., 2019) from the PoW setting

to the DPoS (Karakostas et al., 2020), i.e., perform

stake delegation with a hot/cold wallet in PoS;

• to introduce a novel wallet design, i.e., the proto-

col π

and the functionality F

, in order to sup-

port stake delegation, at the same time is offers en-

hanced security guarantees based on cold storage;

• to present a formal and thorough security analy-

sis in the UC Framework, and prove that our PoS

Hot/Cold Wallet Protocol π

UC realizes the UC

Functionality F

2 PRELIMINARIES

In the next deﬁnitions, we consider negl to be a neg-

ligible function with respect to the security parameter

κ. Moreover, in general we also assume that the ad-

versary is Probabilistic Polynomial Time (PPT) also

with respect to κ, and an EUF-CMA secure digital sig-

nature scheme Σ = ⟨Gen, Verify, Sign⟩.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

340

2.1 The Stake Delegation in PoS

One of the key points in the of the core wallet design

Wallet

of (Karakostas et al., 2020), is that the address

system relies on two pairs of keys: one for spend-

ing transactions while the other is for the delegation.

That is, (sk

pay

,pk

pay

) for payment, i.e., signing regu-

lar transactions, and (sk

stk

,pk

stk

) for delegation, i.e.,

signing of the delegation certiﬁcate.

Attributes and Addresses. Along with both pairs

of keys, for staking and paying, (Karakostas et al.,

2020) relies on collision resistance hash function, and

introduces procedures to generate addresses α and as-

signment attributes to them: GenAddr and HKeyGen.

For completeness, now we review these properties.

Deﬁnition 1 (Collision resistance). A function H is

collision resistant if, given h ← {0, 1}

ℓ

, it is computa-

tionally infeasible for a PPT algorithm to ﬁnd a value

x such that h = H (x ) for some size ℓ.

We now review the properties speciﬁc for the

framework in (Karakostas et al., 2020) with respect to

the address generation. Intuitively, they are designed

to capture (and avoid) adversarial attempts to derivate

malicious address strings from honest ones.

Deﬁnition 2 (Address collision resistance). Analo-

gously to hash functions, GenAddr is collision resis-

tant when it is infeasible to produce two different at-

tribute lists l

= (δ

,...,δ

) for i ∈ {1,2}, i.e., they

differ in at least one attribute like ∃ j ∈ [1,g]: δ

̸= δ

such that GenAddr(l

) = GenAddr(l

), after running

GenAddr(·) a polynomial number of times.

Deﬁnition 3 (Hierarchical Key Generation). For a

key generation function HKeyGen(·) and signature

scheme Σ = ⟨Gen,Verify,Sign⟩, HKeyGen(·) is hier-

archical for Σ if, for all w, the key distribution pro-

duced by HKeyGen(w) is computationally indistin-

guishable from the key distribution produced by Gen.

The address generation depends on the key and

meta information attributes (Karakostas et al., 2020).

For completeness, we recall the following deﬁnition.

Deﬁnition 4 (Non-malleable attribute address genera-

tion). Let L be a distribution of attribute lists and l ←

DOM(L) an attribute list, such that DOM(L) = ∆

... × ∆

. Let the ﬁrst attributes of l δ

,...,δ

relate

to a property over which we deﬁne non-malleability.

Given an address α, it is infeasible for an adversary A

to produce valid forgeries, i.e., acceptable addresses

with the same payment key as α, without access to α’s

private attributes, even with access to the address’s

metadata, i.e., its semi-public attributes. Concretely,

with Addrs the list of addresses queried by A to the

oracle GenAddr

(·), it holds that





l = (δ

,...,δ

), α ← GenAddr(l),

GenAddr(·),GenMeta(·)

(δ

,...,δ

) →

(α

′

,δ

′

,...,δ

′

)

(GenAddr(δ

′

,...,δ

′

) = α

′

)∧ (α

′

̸= α)∧

(α

′

/∈ Addrs)



≤ negl

for probabilities over the random coins of GenAddr

and the PPT adversary A, and choices of l.

The access to the oracles GenAddr

and

GenMeta

captures the scenario where the adversary

has access to a source of well formatted addresses and

metadata which may contain useful information.

PoS Wallet Interface and Stake Pool. As men-

tioned earlier, the PoS design requires more cryptog-

raphy machinery than the PoW approach, therefore

the wallet π

Wallet

, as devised in (Karakostas et al.,

2020), introduces separate actions for payment, del-

egation (by putting forward PAY and STAKE inter-

faces), and also stake pool registration. For the lat-

ter, their design introduces space for metadata meta

and makes use of a regular payment transaction whose

syntax we introduce next for completeness.

Payment. It is the transfer of Θ assets from a

sender’s to receiver’s addresses α

and α

via transac-

tion tx = (Θ, α

,α

,meta), with metadata meta, i.e.,

fee amount. Next it accesses the PAY interface of

Wallet

, retrieves the signed (by the payment secret key

pay

) tx, and publishes it on the ledger.

Stake Pool Registration. Every pool is identiﬁed

by a registered staking key. That is, the pool op-

erator relies on π

Wallet

to produce a new staking

key pair (sk

stk

pool

, pk

stk

pool

), which the operator receives

stk

pool

. It, then, creates a registration certiﬁcate C

reg

(pk

stk

pool

,meta), where meta is the pool’s metadata,

e.g., the name of the pool’s operator. The certiﬁcate is

signed by π

Wallet

with sk

stk

pool

, and the signature is re-

turned. The certiﬁcate C

reg

and the received signature

are published on the ledger (in a payment transaction),

thus registering pk

stk

pool

on behalf of the pool.

Delegation/Redelegation. The stake delegation en-

ables a wallet to assign a stake pool to perform stak-

ing on its behalf. It is based on delegation certiﬁcates

like C

del

= (pk

stk

user

,⟨pk

stk

pool

,meta⟩). Namely, pk

stk

user

the staking key to which the certiﬁcate applies, i.e.,

the key which controls the stake of an address, pk

stk

pool

is the delegate’s key, i.e., the registered key of a stake

pool, and meta is the certiﬁcate’s metadata. The wal-

let gives C

del

to π

Wallet

to be signed with sk

stk

user

, then it

publishes C

del

and the signature via a payment trans-

action (as in the stake pool registration).

Secure and Practical Cold (and Hot) Staking

341

2.2 The Stateful Hot/Cold Wallet

For completeness, we review (Das et al., 2019). The

following deﬁnition is important because we rely on

it in order to keep the key in the cold storage synchro-

nized with the hot wallet via key derivation.

Deﬁnition 5 (Stateful Hot/Cold Wallet Scheme (Das

et al., 2019)). For a security parameter κ, a Stateful

Hot/Cold Wallet is deﬁned by the algorithms Σ

(MGen,SKDer,PKDer,WSign,WVer) such that

• MGen(1

,ρ) → (st

,msk,mpk):The probabilistic

master key generation algorithm MGen takes as in-

put the security parameter 1

and randomness ρ,

then outputs an initial state st

that is given to both

hot and cold wallets, a master public key mpk that is

given to the hot wallet, and a master secret key msk

that is given to the cold wallet;

• SKDer(msk, st, id) → (sk

,st

′

): The determinis-

tic secret key derivation algorithm SKDer is run by

the cold wallet to derive a session secret key. It

takes as input the master secret key msk, the state

st, identiﬁer id, and outputs a session secret key

and the new state st

′

;

• PKDer(mpk, st, id) → (pk

,st

′

): The determinis-

tic public key derivation algorithm PKDer is run by

the hot wallet to derive a session public key. It takes

the master public key mpk, the state st and an iden-

tiﬁer id, and outputs a session public key pk

and

the new state st

′

;

• WSign(m,sk) → σ: The probabilistic signing algo-

rithm WSign is executed by the cold wallet. It takes

as input a message m and a session secret key sk and

outputs a signature σ;

• WVer(m,σ,pk) → {0, 1} : The deterministic veriﬁ-

cation algorithm WVer is executed by any party that

wants to verify the validity of a signature. It takes

as input a session public key pk, a message m and a

signature σ, and outputs 0 or 1.

We stretch the EUF-CMA security deﬁnition for

signature to Deﬁnition 5 by saying that Σ

EUF-CMA if it shows similar properties.

Correctness of a Stateful Hot/Cold Wallet Scheme.

The correctness requirement guarantees that if the

cold/hot wallets derive session key pairs on the same

set of identiﬁers id

,...,id

and in the same order (de-

parting from the initial state st

), then any signature

created by the cold wallet using one of the session

secret keys sk

should be accepted when the veriﬁ-

cation algorithm is executed with the corresponding

session public key pk

. In other words, all the de-

rived session secret and public keys should match.

Security of the Stateful Hot/Cold Wallet Scheme.

As described by Das et al. (Das et al., 2019), the

Stateful Hot/Cold Wallet Scheme should satisfy two

security properties: Unlinkability and Unforgeabil-

ity. Intuitively, the former protects the privacy of the

transaction receiver and captures the guarantee that it

should be infeasible to link transactions sending funds

to different session public keys that were derived from

the same master public key.

It is required that an adversary that is given the

master public key cannot distinguish between ses-

sion public keys derived from that master public key,

and session public keys that are generated from a

fresh (i.e., independently and randomly chosen) mas-

ter public key. As highlighted in (Das et al., 2019),

such security property cannot be achieved for keys

which the adversary knows the state used to derive

them (the adversary can learn such state if there is a

breach in the hot wallet, for example).

The Unforgeability property captures the feature

that once funds are transferred to the cold wallet, they

remain secure if: (1) the hot wallet is breached; and

(2) the adversary observes transactions signed by the

cold wallet. Even such adversary cannot generate new

valid transactions spending cold wallet funds.

3 PoS HOT/COLD LIMITATIONS

The current design, outlined in Section 2, presented

features that can be used to perform delegation in the

hot/cold wallet setting. On the other hand, some fea-

tures are missing and others are not adequate. We

thoroughly discuss each one of them next.

• Cold Stake Delegation. As pointed in Sec-

tion 2.1, the delegation is crucially dependent

of the publication of the delegation certiﬁcate

del

= (pk

stk

user

,⟨pk

stk

pool

,meta⟩) and σ

del

generated

by sk

stk

user

. The construction to be presented has to

set the cold wallet key pairs, i.e., for staking and

payment, and manage them accordingly;

• Rewards Payment. The delegation certiﬁcate, i.e.,

del

= (pk

stk

user

,⟨pk

stk

pool

,meta⟩), and meta can con-

tain the (see next Cold staking redelegation) cold

wallet address to where the rewards can be moved.

The pool operator uses it to deposit the rewards;

• Cold Stake Redelegation. Every new delegation,

i.e., for redelegation, a new address can be issued

under the control of the cold wallet, i.e., controlled

by sk

stk

user

;

• Composable Security. The protocol π

Wallet

from (Karakostas et al., 2020) seems to be incom-

patible to the Stateful Hot/Wold Wallet, i.e., Deﬁ-

nition 5, in the current form, which suggests a re-

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

342

design of π

Wallet

in order to realize the security def-

inition of (Karakostas et al., 2020);

• Hot Wallet Funds. Given that the delegation is per-

formed by certiﬁcate publication in the ledger via a

regular (payment) transaction, the hot wallet, i.e.,

pay

, must to have some funds in order to pay (and

also stake) regular fees for publication.

In summary, given the earlier discussion, it is not

clear that it is possible to port the current stateful

hot/cold wallet design into DPoS.

4 WALLET PROTOCOL π

The main motivation of our next deﬁnition is to ﬁll the

gaps discussed in Section 3 by introducing our proto-

col π

. We start from the basic intuition.

4.1 Intuition: Four Pairs of Keys

We rely on four pairs of keys: (sk

stk

hot

,pk

stk

hot

(sk

pay

hot

,pk

pay

hot

), and (sk

stk

cold

,pk

stk

cold

) are key pairs

from a secure regular (ECDSA) signature, whereas

(msk

pay

cold

,mpk

pay

cold

) is a Stateful Hot/Cold Wallet key

pair in the sense of Deﬁnition 5. Thus the latter is

generated as outlined in Section 2.2:

• ECDSA key pair msk

pay

cold

= x and mpk

pay

cold

= x · G,

for uniformly random x;

• Derivation information generation: w ← H (id,ch),

for a “chaincode” ch and index id;

• Keys derivation: pk

pay

c,id

← mpk

pay

cold

+ w · G and

pay

c,id

← msk

pay

cold

+ w, for a group generator G;

• Existence of a deterministic function I : N →

{0,1}

∗

, such that the cold wallet can check the

equality I (i) = id

= id

∗

for sequential values i.

4.2 Key/Address Basic Procedures

As expected, our protocol is based on the one

from (Karakostas et al., 2020). The main difference

is that here we have to capture two wallets, namely,

the hot and the cold one. Hence, we extend the proto-

col from (Karakostas et al., 2020), with the option of

distinguishing the option between the wallets.

The main idea is that a user U has access to π

for the basic procedures for a wallet: initialize, pay

(signing transaction), verify transaction, staking, gen-

erating address, recovery, etc.

As a preparation to introduce our full construc-

tion for π

, we present the concrete parameters

for the protocol, which were originally proposed

in (Karakostas et al., 2020).

• GenAddr (Algorithm 1): It is the malleable ad-

dress generation function

which generates the ad-

dress strings. Concretely it is given by Algorithm 1,

and it supports three types of addresses

: “base”,

“pointer” and “exile”;

Algorithm 1: (GenAddr). The malleable address generation

function, parameterized by H (·) and the Stateful Hot/Cold

Wallet, i.e., Deﬁnition 5. The input is a tuple l

of the aux-

iliary information aux and attributes for address α.

function GenAddr(l

)

(aux,st,sk

pay

,pk

pay

,wallet) = parse(l

)

switch(“aux

′′

) do

case(“base

′′

) : β = H (st)

case(“pointer

′′

) : β = getPointer(st)

case(“exile

′′

) : β = st

α = H (pk

pay

wallet

||pk

stk

wallet

||H (pk

pay

wallet

))||

β||H (pk

pay

wallet

)

return α

It is not hard to verify the following lemma.

Lemma 1. GenAddr is collision resistant if H is

collision resistant.

• HKeyGen (Algorithm 2): It is the procedure which

is used in combination of the GenAddr. For every

new address generation, the generation relies on a

derivation of a signature public/secret key pair. In

our construction, we use this procedure in addition

to the Stateful Hot/Cold Wallet, i.e., Deﬁnition 5.

Algorithm 2: (HKeyGen). Hierarchical Key Generation, re-

lies on a Pseudorandom Function (PRF), and Pseudoran-

dom Number Generation (PRG). It is designed for label ∈

{“pay”,“stk”} and wallet ∈ {“hot”, “cold”}.

function

HKeyGen(κ,r,⟨label,wallet,index⟩,(mpk,st))

if label=“pay” ∧ wallet =“cold” do

return

PKDer(mpk,st,index) = (pk

pay

c,index

,st

′

)

else

v ← PRF(r||label||wallet||index)

ρ ← PRNG(v)

returnGen(1

,ρ) = (sk

label

wallet

,pk

label

wallet

)

In (Karakostas et al., 2020), this function is referred as

Ex Post Malleability type of address, and it is one of vari-

ous degrees of malleability supported by their framework.

Later the functionality receives an equivalente malleability

predicative.

The extra types of addresses are to support differ-

ent entities like regular user, i.e., “base”, stake pools, i.e.,

“pointer”, not participants of PoS consensus, i.e., “exile”.

Secure and Practical Cold (and Hot) Staking

343

• RTagGen: It is the Recovery Tag Generation algo-

rithm used in the recovery procedure of the wallet.

The tags are generated by hashing the input with the

collision resistant hash function H .

4.3 Cold Storage and the π

Wallet

The cold storage and the wallet π

work in pair.

While the former keeps the cold key msk

cold

, and

therefore sk

pay

cold

, the latter keeps remaining keys, and

can perform the hierarchical key generation for ad-

dress issuing. The initial cold key state, along with

the mpk

cold

and session key id, is passed to π

Concretely, U executes MGen(1

,ρ) →

(st

,msk

pay

cold

,mpk

pay

cold

) for a randomness ρ, pick

a random id, and send (INIT, sid,st

,mpk

pay

cold

,id) to

as it can be seen in the Initialization Interface of

next. The address generation starts by picking

“child attributes” by the jargon of (Karakostas et al.,

2020).

Protocol π

Initialization:

Upon receiving (INIT,sid, st

,mpk

pay

cold

,id) from

U, set r

←− {0, 1}

and return (INITOK,sid).

Address Generation:

-Upon receiving the message

(GENERATEADDRESS, sid,aux,wallet) from

U, compute the index and “child” attributes as

follows: i) pick i ← I ; ii) if wallet=“cold”, set

store = (mpk

pay

cold

,st

) and index = id,

else set store = ⊥ and index = i iii) set

(pk

chd,pay

wallet

,sk

chd,pay

wallet

) = HKeyGen(κ,r,⟨

“pay”, wallet,index⟩,store); iv) set wrt =

RTagGen(pk

chd,pay

wallet

-If aux = “base”, set (pk

chd,stk

,sk

chd,stk

) =

HKeyGen(κ,r,⟨“stk”,wallet,i⟩,⊥); else,

if aux = (“pointer”,pk

stk

),ﬁnd

(pk

chd,stk

,sk

chd,stk

) ∈ K : pk

stk

= pk

chd,stk

; else if

aux = “exile”, set (pk

chd,stk

,sk

chd,stk

) = (⊥, ⊥).

-Then insert l

= ⟨pk

chd,stk

,wrt,aux,

chd,pay

wallet

,sk

chd,pay

wallet

,sk

chd,stk

wallet

,wallet⟩, gener-

ate new address α as α = GenAddr(⟨aux,

stk

,sk

pay

,wrt⟩), and insert the tuple

⟨α,(pk

pay

,sk

pay

)⟩ to P

wallet

key

-Return (ADDRESS, sid,α) to U. If

aux = “base” also insert (pk

chd,stk

wallet

,sk

chd,stk

wallet

)

to S

wallet

key

and send the message

(STAKINGKEY,sid,pk

chd,stk

wallet

) to U.

Wallet Recovery: // For both cold and hot

Upon receiving the message

(RECOVERWALLET,sid,wallet,i

max

) from U,

∀i ∈ [0, i

max

] set (pk

pay

,sk

pay

) = HKeyGen(κ, r,

⟨“pay”,wallet, i⟩, store), store =

{(mpk

pay

cold

,st

),⊥}, return the message

(TAG,sid, RTagGen(pk

pay

)) to U.

Address Recovery: // For both cold and hot

Upon receiving the message

(RECOVERADDR,sid,wallet,α,i

max

)

from U, parse the address’s attributes

(pk

stk

,wrt,aux) = parsePubAttrs(α). If ex-

ists i ∈ I : i < i

max

, where (pk

pay

,sk

pay

) =

HKeyGen(κ,r,⟨“pay”,wallet,i⟩,store),

for store = {(mpk

pay

cold

,st

),⊥} and

RTagGen(pk

pay

) = wrt, and then return

(RECOVEREDADDR,sid, α).

Issue Hot Transaction: // Only hot payment

Upon receiving the message

(PAY,sid,tx = (Θ, α

,α

,m)) from U, ﬁnd

⟨α

,(pk

pay

,sk

pay

)⟩ ∈ P

hot

key

and return the mes-

sage (TRANSACTION,sid,tx,Sign(sk

pay

,tx)).

Issue Cold Transaction: There is no interface

because sk

pay

cold

is disconnected in cold storage.

Verify Transaction: // For both cold and hot

Upon receiving (VERIFYPAY,sid,tx,σ)

from U, with tx = (Θ,α

,α

,meta)

for some metadata meta, ﬁnd an entry

⟨α

,(pk

pay

,sk

pay

)⟩ in P

wallet

key

, for either wallet ∈

{“hot”,“cold”}, and return o U the message

(VERIFIEDPAY, sid,tx, σ, WVer(tx, σ, pk

pay

)).

Issue Staking: // Staking secret key is accessible

Upon receiving (STAKE, sid,stx, wallet) from

U such that stx = (pk

stk

,meta), for some

metadata meta and ﬁnd (pk

stk

,sk

stk

) ∈ S

wallet

key

for either wallet ∈ {hot,cold}, then return

(STAKED, sid,stx, Sign(sk

stk

,stx)).

Verify Staking: // For both cold and hot

Upon receiving (VERIFYSTAKE,sid, stx,σ)

from party U, where stx = (pk,meta) for some

metadata meta, then ﬁnd (pk

stk

,sk

stk

) ∈

wallet

key

, for wallet ∈ {hot, cold}, return

(VERIFIEDSTAKE, sid,stx, σ, WVer(stx, σ, sk

stk

)).

Remark. The trick is that the cold storage only stores

the cold secret key for payment. When sk

pay

cold

stored, it is in fact storing the new state st

′

to be used

in the new key derivation. In order to perform the on-

line redelegation, we only need the cold secret key for

staking. That is, we do not need the key for signing a

payment transaction (from the cold wallet). Thus the

double key structure, for payment and staking, comes

handy. In order words we can freely do (re)delegation

even with the cold wallet ofﬂine permanently.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

344

5 SECURITY ANALYSIS

In (Karakostas et al., 2020), the main security deﬁni-

tion is the wallet functionality F

Wallet

, which receives,

as a parameter, the malleability predicative

M, in or-

der to propose a ﬂexible deﬁnition for different de-

grees of address malleability. That is, how much the

adversary can reuse the same address with different

staking keys; the so called malleability issue identi-

ﬁed in (Karakostas et al., 2020).

Unfortunately, F

Wallet

does not support hot/cold

design, therefore from now we proposed a redesign

of F

Wallet

into F

in order to analyze the previously

presented wallet protocol π

5.1 The Functionality F

Before presenting our functionality F

, for com-

pleteness, we recall the malleability predicate M

which is a parameter for F

Algorithm 3: The malleability predicate M keeps list of gen-

erated addresses and transactions, L and T, and veriﬁes for

rightfully generated addresses.

function M

L,T,U

(aux,α)

switch(“aux”)

case(“issue”) : return 1

case(“verify” OR “recover” ) : d =

parsePubAttrs(α)

for δ ∈ d do

if ∀α

′

∈ L

∈ ,d

′

= parsePubAttrs(α

′

δ ̸∈ d

′

then return 0

if ∀(Θ,α

,α

,m) ∈ T, d

parsePubAttrs(α

): δ ̸∈ d

then return 0

return 1

return 0

The early predicate M is used as a parameter in

the next functionality. Its role is to specify the level of

address malleability we consider in the functionality.

Now, we present the adapted functionality F

Functionality F

Initialization: On receiving the message

(INIT,sid, st

,mpk

pay

cold

,id) from P ∈ P, forward

it to S and wait for (INITOK, sid). Then ini-

tialize the empty lists L

of addresses and at-

tribute lists and K

of staking keys, return

(INITOK,sid).

(Karakostas et al., 2020) proposed various predicative

parameters for different malleability degrees. We will con-

sider here in this work the “sink” malleable predicate, al-

though we drop the term “sink malleable” for readability.

Address Generation: On receiving the message

(GENERATEADDRESS, sid,aux,wallet) from

P ∈ P, forward it to S . On (ADDRESS,sid, α, l

)

from S , parse l

as (δ

,...,δ

) and ∀P

′

∈ P

check if ∀(α

′

,(δ

′

,...,δ

′

)) ∈ L

′

it holds that

α ̸= α

′

, δ

′

̸= δ

, and ∀ j ∈ [i,...,g] : δ

′

̸= δ

, i.e.,

the address, recovery tag, and private attributes

are unique. If so, then

• if aux = (“base”), check that

∀(α

′

,(δ

′

,...,δ

′

)) ∈ L

: δ

′

̸= δ

• else if aux = (“pointer”,pk

stk

), check that

= pk

stk

• else if aux = (“exile”), check that δ

= ⊥.

If the checks hold or P is corrupted, then insert

(α,l

) to L

and return (ADDRESS,sid, α) to P.

If aux = (“base”) also insert δ

to K

and return

the message (STAKINGKEY,sid,δ

) to P.

Wallet Recovery: Upon receiving the message

(RECOVERWALLET,sid,wallet,i) from P ∈ P,

for the ﬁrst i elements in L

return (TAG, sid,δ

Address Recovery: Upon receiving the mes-

sage ( RECOVERADDR,sid,wallet,α,i) from

P, if (α,l) is one of the ﬁrst i elements

of L

or M(L

,“recover”,α) = 1, return

(RECOVEREDADDR,sid, α).

Issue Hot Transaction: Upon receiving

(PAY,sid,tx = (Θ,α

,α

,m)) from P ∈ P, if

∃l

: (α

) ∈ L

forward it to S . Upon

receiving (TRANSACTION,sid,tx, σ) from S ,

check if ∀(tx

′

,σ

′

) ∈ T : σ

′

̸= σ, (tx,σ,0) ̸∈

T , and M(L

,“issue”,α

) = 1. If all checks

hold, then insert (tx,σ,1) to T , return

(TRANSACTION,sid,tx,σ).

Verify Transaction: Upon receiving

(VERIFYPAY,sid,tx,σ) from P ∈ P,

with tx = (Θ, α

,α

,m) for a metadata

string m, forward it to S and wait for

(VERIFIEDPAY, sid,tx, σ, φ). Then

• if M(L

,“verify”,α

) = 0, set f = 0

• else if (tx, σ, 1) ∈ T , set f = 1

• else, if P is not corrupted and (tx,σ,1) ̸∈ T ,

set f = 0 and insert (tx, σ, 0) to T

• else, if (Θ,α

,α

,m,σ,b) ∈ T , set f = b

• else, set f = φ.

Finally, send (VERIFIEDPAY,sid,tx,σ, f ) to P.

Issue Staking: Upon receiving the message

(STAKE,sid, stx,wallet) from P, such that stx =

(pk

stk

,m) for a metadata string m, forward the

message to S . On (STAKED,sid,stx, σ) from

S, if ∀(stx

′

,σ

′

) ∈ S : σ

′

̸= σ, (stx, σ, 0) ̸∈ S,

and pk

stk

∈ K

, add (stx, σ, 1) to S and return the

message (STAKED, sid,stx, σ) to P.

Verify Staking: Upon receiving

Secure and Practical Cold (and Hot) Staking

345

(VERIFYSTAKE,sid, stx,σ) from P ∈ P,

forward it to S and wait for the mes-

sage (VERIFIEDSTAKE, sid,stx, σ, φ), with

stx = (pk

stk

,m). Then ﬁnd P

such that

stk

∈ K

. Then

• if (stx, σ, 1) ∈ S, set f = 1

• else if P

is not corrupted and (stx, σ, 1) ̸∈ S,

set f = 0 and insert (stx, σ, 0) to S

• else if exists an entry (stx, σ, f

′

) ∈ S, set f = f

′

• else set f = φ and insert (stx,σ,φ) to S.

Finally, return (VERIFIEDSTAKE,sid,stx, σ, f )

to P.

We are ﬁnally ready to present our main theorem.

5.2 Main Theorem

Theorem 1. Let the protocol π

be parameterized

by a Stateful Hot/Cold Wallet Σ

(Deﬁnition 5)

and the HKeyGen, GenAddr (Algorithms 2 and 1),

and RTagGen Functions. Then π

securely real-

izes the ideal functionality F

if and only if Σ

is EUF-CMA, GenAddr is collision resistant and at-

tribute non-malleable (Deﬁnitions 2 and 4), RTagGen

is collision resistant (Deﬁnition 1), and HKeyGen is

hierarchical for Σ

(Deﬁnition 3).

We refer the reader the full version of the paper

for the complete proof.

5.3 Addressing Cold/Hot Limitations

Our proof directly shows that it is possible to ful-

ﬁll all the items from Section 3. In particular, three

items, namely 1) Composable security, 2) Cold

stake redelegation and 3) Cold stake delegation

which seemed more challenging. To that purpose, our

proposed protocol π

crucially exploits the design of

the delegation framework: keys for staking and pay-

ment. The address issuing and delegation certiﬁcate

signing require only the cold wallet staking secret key,

which can be managed by the hot wallet.

6 FINAL REMARKS

We introduced the ﬁrst Hold/Cold DPoS wallet pro-

tocol π

and the respective security deﬁnition, i.e.,

Functionality F

. We further showed that π

is se-

cure under this security deﬁnition in the UC Frame-

work. Our protocol addresses the limitations we

have found, however it relies on less restrictive mal-

leability level (as in (Karakostas et al., 2020)). For

more restrictive levels, note that our protocol supports

hardware based solutions in the spirit of (Dowsley

et al., 2022). Our protocol was shown to allow Cold

stake delegation and Rewards payment, in addition

to Composable security and the trivially achievable

Hot wallet funds criteria from Section 3.

Even more crucially, our protocol is shown to per-

form Cold stake redelegation even with a (perma-

nently) off-line wallet, i.e., the cold wallet. It is worth

to highlight that our technique exploits the double key

design of (Karakostas et al., 2020): a key pair for stak-

ing alone and the other for payment transactions for

each wallet, with a total of four key pairs.

We leave for future work extending this study

to the framework which models hardware wallets,

i.e., (Arapinis et al., 2019), to more restrictive levels

of address malleability, i.e., (Karakostas et al., 2020),

and designs with hardware aid to access the cold wal-

let (Dowsley et al., 2022).

ACKNOWLEDGEMENTS

This work was supported by JSPS KAKENHI under

Grant JP21K11882.

REFERENCES

Arapinis, M., Gkaniatsou, A., Karakostas, D., and Kiayias,

A. (2019). A formal treatment of hardware wallets. In

Goldberg, I. and Moore, T., editors, FC 2019, volume

11598 of LNCS, pages 426–445. Springer, Cham.

Cardano (2024). Cardano explorer. https://https://

cexplorer.io/.

Das, P., Erwig, A., Faust, S., Loss, J., and Riahi, S. (2021).

The exact security of BIP32 wallets. In Vigna, G. and

Shi, E., editors, ACM CCS 2021, pages 1020–1042.

ACM Press.

Das, P., Faust, S., and Loss, J. (2019). A formal treatment

of deterministic wallets. In Cavallaro, L., Kinder, J.,

Wang, X., and Katz, J., editors, ACM CCS 2019, pages

651–668. ACM Press.

Dowsley, R. B., Farias, M. C., Larangeira, M., Nasci-

mento, A. C., and Virdee, J. (2022). A spendable

cold wallet from qr video. In International Conference

on Security and Cryptography 2022, pages 283–290.

Scitepress.

Karakostas, D., Kiayias, A., and Larangeira, M. (2020). Ac-

count management in proof of stake ledgers. In Galdi,

C. and Kolesnikov, V., editors, SCN 20, volume 12238

of LNCS, pages 3–23. Springer, Cham.

Maxwell, G. et al. (2014). Deterministic wallets.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

346