pith. sign in

arxiv: 2506.23294 · v4 · submitted 2025-06-29 · 💻 cs.CR

Threshold Signatures for Central Bank Digital Currencies

Mostafa Abdelrahman , Filip Rezabek , Lars Hupel , Kilian Glas , Georg Carle This is my paper

Pith reviewed 2026-05-19 07:40 UTC · model grok-4.3

classification 💻 cs.CR
keywords threshold signaturescentral bank digital currencyECDSAdistributed key managementtransaction securityperformance evaluationkey compromise
0
0 comments X

The pith

Threshold signatures let CBDCs distribute signing keys to cut compromise risks while keeping transaction speeds practical.

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

The paper tests whether threshold signature schemes can fix the single-key failure point that threatens CBDC transaction integrity. By splitting key generation and signing across parties, TSSs ensure no single compromise breaks the system. The authors take the Filia CBDC platform as their test case, focus on ECDSA-compatible TSS libraries, and measure computation time, message sizes, throughput, and end-to-end latency. Results show the security gain comes with overhead low enough for realistic use. Readers care because CBDCs must handle high-value payments where a stolen key could allow large-scale fraud, and distributed signing offers a direct countermeasure.

Core claim

Threshold signature schemes allow distributed key management and signing in CBDCs, reducing the risk of a compromised key. Using the Filia CBDC solution as a base and focusing on ECDSA-based TSS libraries, the performance evaluation measures computational and communication complexity as well as throughput and latency of end-to-end transactions, confirming that TSS can enhance security while maintaining acceptable performance for real-world deployments.

What carries the argument

Threshold signature schemes that split private-key material across multiple independent parties so that a valid signature requires a quorum but no party ever holds the full key.

If this is right

  • CBDC operators can replace single private keys with distributed TSS setups to limit damage from any one breach.
  • Existing ECDSA-based CBDC codebases can adopt TSS libraries without changing the public-key format or transaction format.
  • Measured overhead in key generation, signing rounds, and verification stays small enough that overall transaction rates remain viable for retail payment volumes.
  • Security improvements from TSS apply directly to both issuance and transfer steps inside the same CBDC architecture.

Where Pith is reading between the lines

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

  • The same TSS pattern could be tested on non-CBDC payment rails that already use ECDSA, such as certain stablecoin networks.
  • Regulators might later require a minimum number of signers or geographic separation of TSS parties as a condition for operating large-scale digital currency systems.
  • Hardware security modules could be combined with the software TSS libraries evaluated here to add physical isolation without changing the performance picture much.

Load-bearing premise

That performance numbers recorded on the Filia testbed with chosen ECDSA TSS libraries will remain acceptable once the system faces live network delays, regulatory rules, and real adversaries.

What would settle it

A production CBDC deployment that records end-to-end transaction latencies or throughput values more than double those measured on Filia under similar load would falsify the claim of acceptable real-world performance.

Figures

Figures reproduced from arXiv: 2506.23294 by Filip Rezabek, Georg Carle, Kilian Glas, Lars Hupel, Mostafa Abdelrahman.

Figure 1
Figure 1. Figure 1: Filia Architecture and Protocol Overview. Figures outline the involved [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: The results show that increasing the number of nodes and the threshold [PITH_FULL_IMAGE:figures/full_fig_p011_2.png] view at source ↗
Figure 2
Figure 2. Figure 2: DKG Time vs Number of Nodes 5 10 15 20 25 30 Threshold t 0 20 40 60 Computation Time [s] (a) Computation Time 5 10 15 20 25 30 Threshold t 1 2 3 IO Time [s] (b) I/O Computation Time [PITH_FULL_IMAGE:figures/full_fig_p012_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Pre-signing Time vs Threshold directly impacts the time required for DKG. As shown in Figure 2a, the time increases quadratically with the number of nodes and threshold. This is also the case for the I/O time when each node has to wait to proceed, as shown in Figure 2b. We observe that for a smaller number of nodes, the I/O time exceeds computation time, likely due to communication delay among nodes. Howev… view at source ↗
Figure 4
Figure 4. Figure 4: Signing Time vs Threshold 1, 2, 3 10, 20, 30 100, 200, 300 Concurrent Users 2 4 6 8 10 Throughput [cnt/s] 0.00 0.05 0.10 0.15 Error rate [%] UC1 Throughput UC2 Throughput UC1 Error rate UC2 Error rate (a) Total throughput w/ increasing con￾current users 1, 2, 3 10, 20, 30 100, 200, 300 Concurrent Users 0 25000 50000 75000 100000 125000 Average Latency [ms] UC1 Latency UC2 Latency (b) E2E latency with incre… view at source ↗
Figure 5
Figure 5. Figure 5: E2E transactions latency and throughput environment and the challenges of porting the code to external infrastructure. The setup includes two KMNs (t = 2, n = 3), two FSPs hosting PPs, and a central Verifier hosted in a Docker container to validate transactions. We test two use cases (UCs): UC1 transfers between customers of the same FSP, whereas UC2 emulates transfers between different FSPs. The evaluatio… view at source ↗
read the original abstract

Digital signatures are crucial for securing Central Bank Digital Currencies (CBDCs) transactions. Like most forms of digital currencies, CBDC solutions rely on signatures for transaction authenticity and integrity, leading to major issues in the case of private key compromise. Our work explores threshold signature schemes (TSSs) in the context of CBDCs. TSSs allow distributed key management and signing, reducing the risk of a compromised key. We analyze CBDC-specific requirements, considering the applicability of TSSs, and use Filia CBDC solution as a base for a detailed evaluation. As most of the current solutions rely on ECDSA for compatibility, we focus on ECDSA-based TSSs and their supporting libraries. Our performance evaluation measured the computational and communication complexity across key processes, as well as the throughput and latency of end-to-end transactions. The results confirm that TSS can enhance the security of CBDC implementations while maintaining acceptable performance for real-world deployments.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 2 minor

Summary. The manuscript explores threshold signature schemes (TSS) for Central Bank Digital Currencies (CBDCs) to mitigate risks from single private-key compromise. It analyzes CBDC requirements, focuses on ECDSA-based TSS libraries, uses the Filia CBDC solution as the evaluation platform, and reports measurements of computational/communication complexity, throughput, and latency, concluding that TSS enhances security while preserving acceptable performance for real-world deployments.

Significance. If the reported performance figures hold under production-like conditions, the work supplies concrete empirical data on integrating distributed signing into CBDC transaction flows, thereby offering implementers a practical reference for trading off key-management security against latency and throughput.

major comments (3)
  1. [Abstract and §5] Abstract and §5 (Performance Evaluation): the central claim that TSS 'maintain[s] acceptable performance for real-world deployments' is not supported by any concrete latency, throughput, or end-to-end transaction numbers, nor by any comparison against a baseline single-key ECDSA implementation on the same testbed.
  2. [§5] §5: the Filia testbed results are presented without reported network latency, fault-injection, or adversarial-share-refresh scenarios; therefore the measurements do not establish robustness once the system encounters typical CBDC-scale WAN delays or partial synchrony.
  3. [§4–5] §4–5: no quantitative overhead figures (e.g., signing time ratio or communication volume ratio) relative to non-threshold ECDSA are supplied, leaving the magnitude of the performance penalty unquantified.
minor comments (2)
  1. [§5] Table captions and axis labels in the performance figures should explicitly state the number of participating nodes and the network topology used.
  2. [§3] A short paragraph comparing the chosen ECDSA TSS libraries (e.g., key-generation round complexity) would help readers assess why particular implementations were selected.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the detailed and constructive comments. We agree that strengthening the empirical support and clarifying the evaluation scope will improve the manuscript. We address each major comment below and indicate the planned revisions.

read point-by-point responses

  1. Referee: [Abstract and §5] Abstract and §5 (Performance Evaluation): the central claim that TSS 'maintain[s] acceptable performance for real-world deployments' is not supported by any concrete latency, throughput, or end-to-end transaction numbers, nor by any comparison against a baseline single-key ECDSA implementation on the same testbed.

    Authors: We acknowledge that the abstract and §5 would be strengthened by explicit numerical values and a direct baseline comparison. The full manuscript does report throughput and latency for end-to-end transactions along with computational and communication measurements, but we agree these should be presented more prominently with concrete figures and a side-by-side comparison to single-key ECDSA on the identical testbed. We will revise the abstract and §5 to include these details. revision: yes

  2. Referee: [§5] §5: the Filia testbed results are presented without reported network latency, fault-injection, or adversarial-share-refresh scenarios; therefore the measurements do not establish robustness once the system encounters typical CBDC-scale WAN delays or partial synchrony.

    Authors: The current evaluation focuses on computational and communication overhead within the Filia testbed under controlled conditions. We recognize that WAN delays, partial synchrony, and fault scenarios are relevant for production CBDC deployments. In the revision we will add an explicit discussion of these limitations and, where feasible, include additional measurements or analysis for network latency and basic fault tolerance. Full adversarial share-refresh experiments would require substantial new implementation and are beyond the scope of the present study. revision: partial

  3. Referee: [§4–5] §4–5: no quantitative overhead figures (e.g., signing time ratio or communication volume ratio) relative to non-threshold ECDSA are supplied, leaving the magnitude of the performance penalty unquantified.

    Authors: We will revise §§4 and 5 to supply explicit quantitative overhead ratios, including signing-time and communication-volume comparisons between the threshold ECDSA implementation and a standard single-key ECDSA baseline on the same platform. revision: yes

Circularity Check

0 steps flagged

No circularity in empirical evaluation of TSS for CBDC

full rationale

The paper reports direct experimental measurements of computational and communication costs, throughput, and latency for ECDSA-based threshold signature schemes integrated with the Filia CBDC prototype. No mathematical derivation chain, equations, or predictions are present that reduce reported results to parameters fitted or defined inside the paper itself. Security enhancement claims follow from standard TSS properties (distributed key shares), while performance numbers are observed outputs from the testbed rather than constructed equivalences. The work is therefore self-contained against external benchmarks with no load-bearing self-citation or self-definitional steps.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The evaluation rests on standard cryptographic assumptions for ECDSA and threshold signature security models plus the modeling choice that the Filia testbed represents realistic CBDC workloads.

axioms (2)
  • domain assumption Security of the underlying ECDSA threshold signature scheme holds under standard assumptions (e.g., honest majority or dishonest majority model depending on the library).
    Invoked when claiming that distributed signing reduces compromise risk without introducing new attack surfaces.
  • domain assumption The Filia CBDC architecture and chosen network conditions are representative of production deployments.
    Used to extrapolate measured latency and throughput to real-world acceptability.

pith-pipeline@v0.9.0 · 5696 in / 1290 out tokens · 37792 ms · 2026-05-19T07:40:36.031381+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

38 extracted references · 38 canonical work pages

  1. [1]

    Low-Bandwidth Threshold ECDSA via Pseudoran- dom Correlation Generators

    Damiano Abram et al. Low-Bandwidth Threshold ECDSA via Pseudoran- dom Correlation Generators. 2021. url: https : / / eprint . iacr . org / 2021/1587. 16 M. Abdelrahman et al

    work page 2021

  2. [2]

    A Framework for Resilient, Transparent, High-throughput, Privacy-Enabled Central Bank Digital Currencies

    ElliAndroulakietal. A Framework for Resilient, Transparent, High-throughput, Privacy-Enabled Central Bank Digital Currencies. 2023. url: https:// eprint.iacr.org/2023/1717

    work page 2023

  3. [3]

    2020.url: https://eprint.iacr.org/ 2020/1390

    Jean-Philippe Aumasson, Adrian Hamelink, and Omer Shlomovits.A Sur- vey of ECDSA Threshold Signing. 2020.url: https://eprint.iacr.org/ 2020/1390

    work page 2020

  4. [4]

    Central Bank Digital Currencies: System Design

    Bank of Canada et al. Central Bank Digital Currencies: System Design. Nov. 2024. url: https://www.bis.org/publ/othp88_system_design. pdf

    work page 2024

  5. [5]

    Universally Composable Security: A New Paradigm for Cryp- tographic Protocols

    Ran Canetti. Universally Composable Security: A New Paradigm for Cryp- tographic Protocols. 2000. url: https://eprint.iacr.org/2000/067

    work page 2000

  6. [6]

    Maintaining Authenti- cated Communication in the Presence of Break-ins

    Ran Canetti, Shai Halevi, and Amir Herzberg. Maintaining Authenti- cated Communication in the Presence of Break-ins. 1998. url: https : //eprint.iacr.org/1998/012

    work page 1998

  7. [7]

    Ran Canetti, Nikolaos Makriyannis, and Udi Peled.UC Non-Interactive, Proactive, Threshold ECDSA. 2020. url: https://eprint.iacr.org/ 2020/492

    work page 2020

  8. [8]

    Ran Canetti et al.UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts. 2021. doi: 10.1145/3372297.3423367

    work page doi:10.1145/3372297.3423367 2021

  9. [9]

    Fairness versus Guaranteed Output De- livery in Secure Multiparty Computation

    Ran Cohen and Yehuda Lindell. Fairness versus Guaranteed Output De- livery in Secure Multiparty Computation. 2014. url: https://eprint. iacr.org/2014/668

    work page 2014

  10. [10]

    Consultative Group on Risk Management.Central Bank Digital Currency (CBDC) Information Security and Operational Risks to Central Banks. Nov. 2023. url: https://www.bis.org/publ/othp81.pdf

    work page 2023

  11. [11]

    In: International Conference on Social Robotics

    Ronald Cramer, Ivan Damgård, and Yuval Ishai. “Share conversion, pseu- dorandom secret-sharing and applications to secure computation”. In:Pro- ceedings of the Second International Conference on Theory of Cryptogra- phy. TCC’05. Cambridge, MA: Springer-Verlag, 2005, pp. 342–362.doi: 10.1007/978- 3- 540- 30576- 7_19 . url: https://doi.org/10.1007/ 978-3-54...

    work page doi:10.1007/978- 2005

  12. [12]

    In:url: https://github.com/dfns/cggmp21

    “dfns”. In:url: https://github.com/dfns/cggmp21

    work page

  13. [13]

    Jack Doerner, Yashvanth Kondi, Eysa Lee, and abhi shelat.Secure Two- party Threshold ECDSA from ECDSA Assumptions. 2018. doi: 10.1109/ SP.2018.00036. url: https://eprint.iacr.org/2018/499

    work page arXiv 2018

  14. [14]

    Threshold ECDSA from ECDSA Assumptions: The Multiparty Case

    Jack Doerner, Yashvanth Kondi, Eysa Lee, and abhi shelat. Threshold ECDSA from ECDSA Assumptions: The Multiparty Case. 2019. doi: 10. 1109/SP.2019.00024. url: https://eprint.iacr.org/2019/523

    work page arXiv 2019

  15. [15]

    Threshold ECDSA in Three Rounds

    Jack Doerner, Yashvanth Kondi, Eysa Lee, and abhi shelat. Threshold ECDSA in Three Rounds. 2023. url: https://eprint.iacr.org/2023/ 765

    work page 2023

  16. [16]

    SoK: Design, Vulnerabilities, and Security Measures of Cryptocurrency Wallets

    Yimika Erinle,YathinKethepalli, YeboFeng, andJiahuaXu. SoK: Design, Vulnerabilities, and Security Measures of Cryptocurrency Wallets. 2025. url: https://arxiv.org/abs/2307.12874. Threshold Signatures for Central Bank Digital Currencies 17

    work page arXiv 2025

  17. [17]

    An Introduction to Secret-Sharing-Based Secure Multi- party Computation

    Daniel Escudero. An Introduction to Secret-Sharing-Based Secure Multi- party Computation. 2022. url: https://eprint.iacr.org/2022/062

    work page 2022

  18. [18]

    Qi Feng et al.Stateless Deterministic Multi-Party EdDSA Signatures with Low Communication. 2024. url: https://eprint.iacr.org/2024/358

    work page 2024

  19. [19]

    Fireblocks - #1 Institutional Digital Asset Custody, Settlement & Issuance

    Fireblocks. Fireblocks - #1 Institutional Digital Asset Custody, Settlement & Issuance. [Online]. Available: https : / / www . fireblocks . com/. [Ac- cessed: Nov. 12, 2024]. 2024

    work page 2024

  20. [20]

    Rosario Gennaro and Steven Goldfeder.Fast Multiparty Threshold ECDSA with Fast Trustless Setup. 2019. url: https://eprint.iacr.org/2019/ 114

    work page 2019

  21. [21]

    One Round Threshold ECDSA with Identifiable Abort

    Rosario Gennaro and Steven Goldfeder. One Round Threshold ECDSA with Identifiable Abort. 2020.url: https://eprint.iacr.org/2020/540

    work page 2020

  22. [22]

    Central Bank Digital Currency G+D Filia Whitepa- per

    Giesecke+Devrient. Central Bank Digital Currency G+D Filia Whitepa- per. 2024. url: https://pages.gi-de.com/whitepaper-filia

    work page 2024

  23. [23]

    Evaluation of Distributed Key Generation Approaches for Threshold ECDSA Signature Systems

    Kilian Glas. “Evaluation of Distributed Key Generation Approaches for Threshold ECDSA Signature Systems”. Master’s Thesis. Technical Uni- versity of Munich, May 2022

    work page 2022

  24. [24]

    The knowledge complexity of interactive proof-systems

    S Goldwasser, S Micali, and C Rackoff. “The knowledge complexity of interactive proof-systems”. In:Proceedings of the Seventeenth Annual ACM Symposium on Theory of Computing.STOC’85.Providence,RhodeIsland, USA: Association for Computing Machinery, 1985, pp. 291–304.doi: 10. 1145/22145.22178. url: https://doi.org/10.1145/22145.22178

    work page doi:10.1145/22145.22178 1985

  25. [25]

    Fast Secure Multiparty ECDSA with Practical Distributed Key Generation and Applications to Cryptocurrency Custody

    Iftach Haitner, Yehuda Lindell, Ariel Nof, and Samuel Ranellucci. Fast Secure Multiparty ECDSA with Practical Distributed Key Generation and Applications to Cryptocurrency Custody. 2018. doi: 10.1145/3243734. 3243788. url: https://eprint.iacr.org/2018/987

    work page doi:10.1145/3243734 2018

  26. [26]

    FROST: Flexible Round-Optimized Schnorr Threshold Signatures

    ChelseaKomloandIanGoldberg. FROST: Flexible Round-Optimized Schnorr Threshold Signatures. 2020. url: https://eprint.iacr.org/2020/852

    work page 2020

  27. [27]

    Simple Three-Round Multiparty Schnorr Signing with Full Simulatability

    Yehuda Lindell. Simple Three-Round Multiparty Schnorr Signing with Full Simulatability. 2022. url: https://eprint.iacr.org/2022/374

    work page 2022

  28. [28]

    MPC Alliance. 2024. url: https://www.mpcalliance.org/

    work page 2024

  29. [29]

    Public-keycryptosystemsbasedoncompositedegreeresid- uosity classes

    PascalPaillier.“Public-keycryptosystemsbasedoncompositedegreeresid- uosity classes”. In:Proceedings of the 17th International Conference on Theory and Application of Cryptographic Techniques. EUROCRYPT’99. Prague, Czech Republic: Springer-Verlag, 1999, pp. 223–238

    work page 1999

  30. [30]

    libp2p: A modular network stack for peer-to-peer protocols in Rust

    libp2p Project. libp2p: A modular network stack for peer-to-peer protocols in Rust. https://libp2p.io. Accessed: 2023-09-14. 2023

    work page 2023

  31. [31]

    EnGINE: Flexible Research Infrastructure for Reli- able and Scalable Time Sensitive Networks

    Filip Rezabek et al. “EnGINE: Flexible Research Infrastructure for Reli- able and Scalable Time Sensitive Networks”. In:Journal of Network and Systems Management 30.4 (Sept. 2022), p. 74. doi: 10 . 1007 / s10922 - 022-09686-0

    work page 2022

  32. [32]

    Multilayer Environment and Toolchain for Holistic NetwOrk Design and Analysis

    Filip Rezabek et al. “Multilayer Environment and Toolchain for Holistic NetwOrk Design and Analysis”. In: Nov. 2023. 18 M. Abdelrahman et al

    work page 2023

  33. [33]

    ROAST: Robust Asynchronous Schnorr Threshold Sig- natures

    Tim Ruffing et al. ROAST: Robust Asynchronous Schnorr Threshold Sig- natures. 2022. doi: 10.1145/3548606.3560583 . url: https://eprint. iacr.org/2022/550

    work page doi:10.1145/3548606.3560583 2022

  34. [34]

    PEReDi: Privacy-Enhanced, Regulated and Distributed Central Bank Digital Cur- rencies

    Amirreza Sarencheh, Aggelos Kiayias, and Markulf Kohlweiss. PEReDi: Privacy-Enhanced, Regulated and Distributed Central Bank Digital Cur- rencies. 2022. url: https://eprint.iacr.org/2022/974

    work page 2022

  35. [35]

    Kiarash Sedghighadikolaei and Attila Altay Yavuz.A Comprehensive Sur- vey of Threshold Signatures: NIST Standards, Post-Quantum Cryptogra- phy, Exotic Techniques, and Real-World Applications. 2024. url: https: //arxiv.org/abs/2311.05514

    work page arXiv 2024

  36. [36]

    How to share a secret

    Adi Shamir. “How to share a secret”. In:Commun. ACM 22.11 (Nov. 1979), pp. 612–613.doi: 10.1145/359168.359176 . url: https://doi. org/10.1145/359168.359176

    work page doi:10.1145/359168.359176 1979

  37. [37]

    silence-laboratories

    “silence-laboratories”.In:url: https://github.com/silence-laboratories/ silent-shard-dkls23-ll

    work page

  38. [38]

    Dmitry Varlakov and Jonathan Katz.CGGMP21 In Rust, At Last. Dfns. [Online]. Available:https://www.dfns.co/article/cggmp21-in-rust- at-last. Mar. 2024

    work page 2024