[Proposal setup] Proposal title

Please provide your proposal title

Distributed Block Production for Cardano

[Proposal Summary] Budget Information

Enter the amount of funding you are requesting in ADA

200000

[Proposal Summary] Time

Please specify how many months you expect your project to last

7

[Proposal Summary] Translation Information

Please indicate if your proposal has been auto-translated

No

Original Language

en

[Proposal Summary] Problem Statement

What is the problem you want to solve?

Cardano staking today relies on trust in a single operator to stay secure and online. If it fails or is hacked, delegators risk missed rewards, downtime, and loss of trust in the pool.

[Proposal Summary] Supporting Documentation

Supporting links

• https://polycry.pt/
,
• https://scispace.com/pdf/efficient-generic-forward-secure-signatures-with-an-1ipp2429nn.pdf
,
• https://eprint.iacr.org/2020/852.pdf
,
• https://github.com/ZcashFoundation/frost
,
• https://eprint.iacr.org/2022/550.pdf

[Proposal Summary] Project Dependencies

Does your project have any dependencies on other organizations, technical or otherwise?

No

Describe any dependencies or write 'No dependencies'

We will try to re-use parts of a well-maintained and audited FROST implementation (https://github.com/ZcashFoundation/frost), and port it as necessary to implement it within distributed block-building nodes. Currently, we do not expect to run into dependency issues regarding FROST. Besides that, our biggest dependency will be the cardano-node project itself.

[Proposal Summary] Project Open Source

Will your project's outputs be fully open source?

Yes

Please provide details on the intellectual property (IP) status of your project outputs, including whether they will be released as open source or retained under another licence.

Our project outputs will be released under an appropriate open-source license (e.g., Apache-2.0).

[Theme Selection] Theme

Please choose the most relevant theme and tag related to the outcomes of your proposal

Security

[Campaign Category] Category Questions

Describe what makes your idea innovative compared to what has been previously launched in the market (whether by you or others).

To the best of our knowledge, there is currently no solution that enables Cardano stake pool operators to run in a fully decentralized manner. Our proposal therefore constitutes the first step toward distributing a core component of Cardano’s staking infrastructure, thereby removing single points of failure and substantially increasing the robustness of the Cardano ecosystem.

Distributed Validator Technology (DVT) was originally proposed for Ethereum (see https://ethereum.org/staking/dvt/)) and is now being actively developed by several companies. However, in contrast to Ethereum’s staking and voting design, Cardano’s protocol is significantly more challenging to distribute. For instance, Ethereum relies on BLS signatures, for which efficient and non-interactive threshold variants are readily available, making DVT integration comparatively straightforward. Cardano, by contrast, uses Ed25519 for its stake pool keys and a Key Evolving Signature (KES) scheme for block production. This introduces substantial complexity: threshold Ed25519 schemes such as FROST and ROAST are inherently interactive, especially when robustness is required, and therefore must be carefully engineered to remain compatible with Cardano’s fast block production schedule. In addition, the time-evolving nature of KES keys adds further coordination challenges in a distributed setting.

As a consequence, our proposal must go significantly beyond the current state of the art in distributed validator technology. We believe that our project will provide an essential foundational step toward improving the security, resilience, and decentralization of Cardano’s staking ecosystem.

Describe what your prototype or MVP will demonstrate, and where it can be accessed.

Our prototype will showcase how a Cardano SPO can run a distributed block producing node, removing the need for an always-online node with full access to the block-signing key.

Our proof of concept implementation will be available on github alongside a demo, and will guide pool operators on how to distribute their block-producing nodes to enhance security and minimize the risk of missed rewards and mass-exits for their pool.

Describe realistic measures of success, ideally with on-chain metrics.

Success will be demonstrated through performance, on-chain validation, and operational reliability:

1. Protocol Performance: Our protocol for distributed signing meets Cardano’s slot time across 3–5 nodes. Under realistic network conditions it achieves >99% of successful block signatures.
2. On-Chain Metrics (Testnet): All blocks are accepted and validated on-chain with correct threshold Ed25519/KES signatures. There are no DVT-induced missed slots.
3. Operational Robustness: The block production continues despite 1-of-3 (or 2-of-5) nodes being offline. This even holds under successful geo-distributed operation (different locations/cloud providers).

[Your Project and Solution] Solution

Please describe your proposed solution and how it addresses the problem

Problem

Cardano stake pool operators (SPOs) currently rely on centralized, single-party keys for producing blocks.

In particular, each block-producing node must hold:

• a VRF secret key (for leader election), and
• an operational Key Evolving Signature (KES) secret key (for signing block headers),

both of which must remain online and accessible on the hot block-producing server.

Because a stake pool must produce blocks throughout an entire epoch (≈ 5 days), and the KES key remains valid for a KES key period (~1.5 days per period, ~180 days per KES key), the operator must keep these cryptographic keys “hot” for extended periods of time to avoid missing slot-leadership opportunities.

This creates the following major problems:

1. Single point of failure
   1. If the single block-producing node is compromised and an attacker gets access to the block-signing keys, this can lead to catastrophic consequences. The attacker could sign blocks in the pool’s name (potentially with a malformed / fake body), or double-sign for slots, creating forks. Similarly, if the block-producing node DoS’d, an attacker could cause the pool to miss its leader slots. All of the above can lead to missed rewards and mass-exit of delegators from the pool.
2. Operational and security risk
   1. Since both VRF and KES keys must live on a machine that is online 24/7, the pool operator faces a difficult trade-off:
      1. prioritize availability (multiple hot backups) → increases key-exposure risk,
      2. or prioritize security (minimal key exposure) → increases the risk of downtime and missed slots.
3. No built-in support for distributed validation
   1. Unlike ecosystems that support threshold signatures or distributed validators (e.g., via DVT), Cardano’s current design expects a single machine to hold the signing authority. In particular, the fact that Cardano uses Ed25519 signatures instead of BLS signatures and the practice of wrapping Ed25519 with KES to achieve forward security make it challenging to securely and efficiently distribute block-producing nodes’ key material in Cardano.
4. No cryptographic resilience against partial compromise
   1. With non-distributed keys, compromising one server is enough to:
      1. steal the KES key (block-signing authority),
      2. steal the VRF key (leadership schedule info),
      3. or disrupt the node exactly when it is the leader.

There is currently no cryptographic mechanism allowing multiple parties or machines to cooperate securely in block production without sharing the private keys.

Solution

We propose to bring Distributed Validator Technology (DVT) to Cardano by replacing the current single-operator Ed25519 block-signing key with a threshold Schnorr signature scheme. Threshold signatures allow a group of n independent nodes to collectively hold a private key in shares, so that any group of at least t nodes can jointly produce a valid signature, while fewer than t nodes learn nothing about the key or cannot sign alone. This removes the single point of failure of today’s stake pool architecture.

Step 1 — Replace Ed25519 with Threshold Schnorr Signatures

Cardano’s KES scheme internally uses Ed25519 signatures. As a first step, we focus on replacing these signatures with a threshold Schnorr signature, which is mathematically compatible with Ed25519 verification. This ensures full compatibility with existing KES verification and requires no changes to Cardano’s consensus protocol.

Cardano’s 1-second slot time requires a highly efficient signing protocol. We propose to use FROST, a state-of-the-art threshold Schnorr scheme that is extremely fast and requires only a single round of interaction during signing (after a message-independent, ahead-of-time, preprocessing stage). However, FROST is not robust: if any signer is offline or malicious, the signing attempt can fail. Fortunately, these failures are identifiable, and thus signing can be re-run without the failing signers to produce a valid signature. However, because Cardano slots are short, we cannot afford too many repeated signing attempts.

To guarantee successful signing in all circumstances, we propose to use ROAST, a robust threshold Schnorr scheme built on top of FROST. ROAST introduces some interaction for signers, but guarantees that as long as at least t honest participants respond, a signature is always produced within the signing session. We will evaluate signer set sizes and thresholds that allow ROAST to complete reliably within Cardano’s 1-second slot window. Our implementation will leave usage of ROAST for robust signing optional, allowing for better performance at the cost of robustness in certain circumstances. Similarly, we will consider a number of engineering tricks to boost the efficiency of ROAST, such as learning reliable signer sets from past slots to produce a valid signature with less interaction.

Note that ROAST is merely a robustness wrapper protocol executed on top of FROST. Thus, both protocols operate with identical key material, which allows us to select the more appropriate signing protocol on a slot-by-slot basis.,

Step 2 — Integrate Threshold Signatures Into Cardano’s KES Workflow

Cardano uses Key Evolving Signatures (KES) for forward security: each stake pool cycles through 128 ephemeral Ed25519 keypairs, one per KES period (~1.5 days), ensuring that compromise of a current key does not allow forging past signatures. (This follows the MMM’01 Key-Evolving Signature construction (see link in supporting material).)

Fully thresholdizing the entire KES tree is out of scope for this initial project. Instead, we propose a practical and backwards-compatible approach:

• During pool setup (in a semi-cold environment), a master node generates 128 threshold key sharings (one for each KES period) using FROST/ROAST with “trusted dealer”. (Recall here that both schemes use the exact same key material.)
• At the start of each KES period, the master node securely delivers that period’s threshold key shares to the nnn shareholders. As an alternative, all 128 per-period share sets could be distributed once during initial provisioning. This allows for the following tradeoff: Distributing all keys at once allows the master node to stay “even colder” since it has to come online less frequently, but then corrupting at least t shareholders during any period will also corrupt all future periods. Distributing at the beginning of each period requires more interaction from the master node, but corrupting t nodes during any period does not necessarily impact security for future periods.
• After receiving their keyshares,, the shareholders run message-independent FROST/ROAST preprocessing for the expected amount of signatures required in the KES period.
• When the pool is elected slot leader, shareholders use FROST/ ROAST signing to jointly produce the KES signature for that period.
• The process is repeated with the next key at the beginning of the next period

This approach, while not yet optimal, preserves the full KES structure and verification logic while drastically reducing the exposure of the “single point of failure” master-node. Under this design, the operator’s central machine only needs to come online once every KES period to distribute that period’s shares, rather than being online for every block production slot.

Potential Follow-Ups

After successful completion of the above steps, we have some plans for potential remaining project time (in case we finish ahead of schedule) or a potential follow-up grant. In particular, we would like to:

• Enhance security by replacing the master-node that acts as a trusted dealer for ROAST with a DKG between shareholders. As a result, the master node would no longer know the block-signing key of the pool, moving it from “trusted but cold” to an “untrusted” state with respect to the signing key.

Thresholdize the VRF component of Cardano consensus: Our initial project will focus on the signing key, as it appears to be a more lucrative target for malicious attackers. As a next step, it is natural to also protect the VRF key for leader election from single-point-of-failure exposure.

[Your Project and Solution] Impact

Please define the positive impact your project will have on the wider Cardano community

Our proposal delivers a tangible and highly realistic improvement to Cardano’s core infrastructure by introducing distributed block production – an approach that directly addresses one of the most security-critical weaknesses identified by SPOs today: the reliance on a single hot machine holding the block-signing keys. By replacing single-party Ed25519 signing with threshold Schnorr signatures and integrating them into Cardano’s KES workflow, we eliminate the single point of failure that currently threatens pool rewards, pool reputation, and overall network liveness.

A successful prototype will meaningfully increase the resilience, reliability, and decentralization of Cardano at the validator layer. Pools gain protection against server compromise, key theft, DoS attacks, and operational downtime. Such issues are repeatedly highlighted by the community as risks for both small and large operators. This strengthens stakeholder trust and reduces churn from missed blocks or catastrophic key-loss events.

The impact is broad and ecosystem-wide:

• Higher protocol security through distributed keys instead of hot single-server keys.
• Lower probability of consensus failures, benefiting all users and dApps relying on stable network performance.
• A future-ready architecture compatible with potential slashing, higher staking participation, and evolving staking economics.
• Open-source, publicly accessible code, enabling adoption by any SPO and integration by infrastructure providers.

The approach is realistic and achievable. The underlying cryptographic schemes (FROST, ROAST) are well-studied, efficient, and implementable within Cardano’s 1-second slot constraints. Our milestones outline a clear, accountable path from distributed node architecture to robust threshold signing within the KES lifecycle. We will maintain transparent, regular reporting with demos, GitHub updates, and ongoing communication, ensuring the community can track progress and evaluate results at each stage.

By delivering a working prototype that SPOs can test and adopt, this project directly contributes measurable improvements to Cardano’s operational security and prepares the ecosystem for future growth.

[Your Project and Solution] Capabilities & Feasibility

What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

The PolyCrypt GmbH is a spin-off of the Technical University of Darmstadt, Germany with former members of the applied cryptography research group. Core areas include the research and development of Layer 2 interoperability and scaling solutions such as Perun State Channels as well as security and privacy solutions for decentralized identities such as threshold cryptography. PolyCrypt is also involved in strengthening the security of Obol’s DVT stack by leveraging trusted execution environments. Currently, PolyCrypt employs 11 people with different backgrounds in cryptography and software engineering. In the project the following team members will be involved:

Hendrik Amler: Project manager and co-founder at PolyCrypt

Jens Winkle: Cryptographic engineer and software developer at PolyCrypt

Jan Bormet: Researcher at Technical University of Darmstadt and PolyCrypt

Sebastian Faust: Professor of Computer Science at Technical University of Darmstadt and research lead at PolyCrypt

We have already successfully completed two projects funded by Cardano, namely “Perun Channels for Cardano” in F8 (https://cardano.ideascale.com/c/idea/400079)))))))) and more recently, “Easily recoverable Identity Wallets for Atala Prism (SSI Threshold Wallets)” in F11 (https://projectcatalyst.io/funds/11/cardano-open-developers/easily-recoverable-identity-wallets-for-atala-prism-ssi-threshold-wallets)..)..))..)..))) Notably, the latter project helped us to deepen our expertise in deploying threshold cryptographic schemes within the Cardano ecosystem.

[Milestones] Project Milestones

Milestone Title

Distributed Block-Producing Node

Milestone Outputs

• A fork of cardano-node capable of operating as a distributed block-producing system.
• Separation of roles into:
• Master node (initial key owner & KES integrator)
• Shareholder nodes (future threshold key holders)
• Message-passing architecture enabling multiple nodes to cooperatively produce a block.
• Prototype aggregator logic where any shareholder node may act as the aggregator that collects signatures and publishes the block.
• Documentation describing node roles, network topology, communication channels, and integration points with KES.

Acceptance Criteria

• Modified cardano-node runs successfully across ≥3 independent machines.
• Signaling & coordination between master and shareholders works reliably (heartbeat messages, block leadership notification, aggregator selection).
• A simulated block-production cycle executes end-to-end with placeholder signatures.
• Documentation clearly describes:
  • How to deploy the distributed architecture
  • Node responsibilities
  • Communication flow & failure handling

Evidence of Completion

• Public GitHub repository with the forked cardano-node, build instructions, and deployment scripts.
• Test logs or screenshots demonstrating successful block-production coordination across multiple machines.
• Architecture documentation (PDF or Markdown) included in the repository.
• Optional demo video showing distributed node operation.

Delivery Month

2

Cost

60000

Progress

30 %

Milestone Title

FROST key generation in the master node

Milestone Outputs

• Master-node implementation that generates 128 FROST key sharings, one for each KES period.
• Secure communication channel for distributing period-specific shares to all shareholders at KES period boundaries.
• Persistence and rotation logic for selecting the correct threshold key for the active period.
• Documentation of the FROST-generation parameters, security assumptions, and share-distribution protocol.

Acceptance Criteria

• Master node produces 128 threshold key sharings using FROST with a trusted-dealer setup.
• Shareholder nodes receive correct shares for at least 3 consecutive simulated KES periods.
• Documentation covers:
  • FROST configuration
  • Security considerations
  • Share distribution protocol & expected operator workflow

Evidence of Completion

• GitHub repository containing:
  • Key-generation code
  • Share-distribution module
  • Test scripts validating correctness of generated keys
• Logged output or screenshots demonstrating successful generation & distribution for multiple KES periods.
• PDF/Markdown document explaining the FROST setup.

Delivery Month

4

Cost

60000

Progress

60 %

Milestone Title

Message-Independent FROST Preprocessing

Milestone Outputs

• Implementation of FROST’s message-independent preprocessing protocol among all shareholder nodes.
• Reliable broadcast mechanism ensuring authenticated and consistent delivery of preprocessing messages.
• Precomputation of signing material for q signatures, where q is a safe upper bound on expected slot-leadership events within a KES period.

Acceptance Criteria

• All shareholders successfully run preprocessing in a single interaction round.
• Reliable broadcast ensures all shareholders receive identical preprocessing commitments.
• Preprocessing for at least q = 500 signatures executes without inconsistencies.
• If a shareholder goes offline mid-protocol, remaining nodes complete preprocessing without deadlock.
• Documentation describes:
  • Preprocessing protocol
  • Reliable broadcast mechanism
  • Expected performance characteristics

Evidence of Completion

• GitHub repository code implementing preprocessing + reliable broadcast.
• Logs or screenshots showing successful preprocessing among ≥5 shareholders.
• Performance report summarizing preprocessing timing under different network conditions.

Delivery Month

5

Cost

30000

Progress

80 %

Milestone Title

Non-Interactive FROST Signing for Slot-Leader Events

Milestone Outputs

• Implementation of non-interactive FROST partial-signature generation whenever the pool becomes slot leader.
• Aggregator logic enabling any shareholder to assemble partial signatures into a final Schnorr signature.
• Integration of threshold signatures into the existing KES signing workflow.
• End-to-end block-production tests using real slot-leader events in a simulated environment.

Acceptance Criteria

• Shareholders can produce correct partial signatures in real time when notified of a slot-leadership event.
• Aggregator successfully combines ≥t partial signatures into a valid Schnorr signature that passes Ed25519-compatible verification.
• Simulated block-production across at least 10 consecutive slots shows no missed signatures due to FROST.
• Documentation:
  • Developer guide for slot-leader signing
  • Aggregator behavior
  • Failure handling (e.g., missing partial signatures)

Evidence of Completion

• GitHub repository containing signing modules and integration code with cardano-node.
• Logs demonstrating:
  • Generation of partial signatures
  • Aggregation
  • Successful validation of block signatures
• Demo video showing a full slot-leadership cycle executed with FROST signing.

Delivery Month

6

Cost

25000

Progress

90 %

Milestone Title

ROAST Integration & Robust Threshold Signing

Milestone Outputs

• Implementation of the ROAST wrapper around FROST, enabling robust threshold signing even with offline/malicious participants.
• Optimized communication schedule adapted for Cardano’s 1-second slot window.
• Benchmarking of signer set sizes, thresholds t, and network delays.
• Recommendation report detailing system parameters required for safe deployment on mainnet.

Acceptance Criteria

• ROAST signing successfully produces a valid signature in all tested scenarios where ≥t honest participants respond.
• Works within Cardano’s 1-second slot limit for at least 4 different configurations of (n, t).
• Benchmarks include:
  • Latency distributions
  • Failure-mode behavior
  • Stress tests with dropped or delayed messages
• Recommendation report explains safe operational bounds and configuration parameters.

Evidence of Completion

• GitHub repository containing full ROAST integration code.
• Benchmark dataset + plots + summary PDF describing performance metrics.
• Logs showing successful ROAST signing under simulated network disruptions.
• Final technical report with parameter recommendations.

Delivery Month

7

Cost

25000

Progress

100 %

[Final Pitch] Budget & Costs

Please provide a cost breakdown of the proposed work and resources

Roles and hourly rates:

• Researcher: 256.4102564 ADA/hr
• Project Manager / DevOps: 179.4871795 ADA/hr
• Cryptographic Engineer / Senior Developer: 217.9487179 ADA/hr

MS1 — Distributed Block-Producing Node (60,000 ADA)

Cryptographic Engineer / Senior Developer:

160h × 217.9487179 ≈ 34,872 ADA → 34,872 ADA

Project Manager / DevOps:

100h × 179.4871795 ≈ 17,949 ADA → 17,949 ADA

Researcher:

30h × 256.4102564 ≈ 7,692 ADA → 7,692 ADA

Total: 60,513 ADA → rounded to 60,000 ADA

MS2 — FROST Key Generation & KES Rotation (60,000 ADA)

Cryptographic Engineer / Senior Developer:

150h × 217.9487179 ≈ 32,692 ADA → 32,692 ADA

Researcher:

80h × 256.4102564 ≈ 20,513 ADA → 20,513 ADA

Project Manager / DevOps:

35h × 179.4871795 ≈ 6,282 ADA → 6,282 ADA

Total: 59,487 ADA → rounded to 60,000 ADA

MS3 — Message-Independent FROST Preprocessing (30,000 ADA)

Cryptographic Engineer / Senior Developer:

80h × 217.9487179 ≈ 17,436 ADA → 17,436 ADA

Researcher:

32h × 256.4102564 ≈ 8,205 ADA → 8,205 ADA

Project Manager / DevOps:

25h × 179.4871795 ≈ 4,487 ADA → 4,487 ADA

Total: 30,128 ADA → rounded to 30,000 ADA

MS4 — Non-Interactive FROST Signing for Slot-Leader Events (25,000 ADA)

Cryptographic Engineer / Senior Developer:

70h × 217.9487179 ≈ 15,256 ADA → 15,256 ADA

Researcher:

28h × 256.4102564 ≈ 7,180 ADA → 7,180 ADA

Project Manager / DevOps:

16h × 179.4871795 ≈ 2,871 ADA → 2,871 ADA

Total: 25,307 ADA → rounded to 25,000 ADA

MS5 — ROAST Integration & Benchmarking (25,000 ADA)

Cryptographic Engineer / Senior Developer:

60h × 217.9487179 ≈ 13,077 ADA → 13,077 ADA

Researcher:

30h × 256.4102564 ≈ 7,692 ADA → 7,692 ADA

Project Manager / DevOps:

22h × 179.4871795 ≈ 3,949 ADA → 3,949 ADA

Total: 24,718 ADA → rounded to 25,000 ADA

Grand Total: 200,000 ADA

[Final Pitch] Value for Money

How does the cost of the project represent value for the Cardano ecosystem?

We see three direct ways of how our project adds value to the Cardano ecosystem:

• Distributed Stake pools can significantly reduce the risk of missed rewards and thus prevent delegates' mass exits due to maliciously introduced consensus failures. Note that protection from such attacks will become even more important with future increase in Cardano’s staking activity, or should Cardano introduce slashing for consensus failures at any time in the future. In fact, introducing distributed SPOs can be seen as a necessary precondition for enhancing Cardano’s consensus guarantees through slashing mechanisms.
• On a higher level, Cardano’s consensus will benefit from the enhanced resilience of SPOs against DoS and key compromise, resulting in a significantly reduced risk of liveness failures. Overall, transactions will be included faster and more reliably in the worst case as well as on average.
• It lets ADA holders stake safely without relying on one operator’s security, giving non-technical users the same protection as professionally run multi-node setups.

[Self-Assessment] Self-Assessment Checklist

I confirm that evidence of prior research, whitepaper, design, or proof-of-concept is provided.

Yes

I confirm that the proposal includes ecosystem research and uses the findings to either (a) justify its uniqueness over existing solutions or (b) demonstrate the value of its novel approach.

Yes

I confirm that the proposal demonstrates technical capability via verifiable in-house talent or a confirmed development partner (GitHub, LinkedIn, portfolio, etc.)

Yes

I confirm that the proposer and all team members are in good standing with prior Catalyst projects.

Yes

I confirm that the proposal clearly defines the problem and the value of the on-chain utility.

Yes

I confirm that the primary goal of the proposal is a working prototype deployed on at least a Cardano testnet.

Yes

I confirm that the proposal outlines a credible and clear technical plan and architecture.

Yes

I confirm that the budget and timeline (≤ 12 months) are realistic for the proposed work.

Yes

I confirm that the proposal includes a community engagement and feedback plan to amplify prototype adoption with the Cardano ecosystem.

Yes

I confirm that the budget is for future development only; excludes retroactive funding, incentives, giveaways, re-granting, or sub-treasuries.

Yes

[Required Acknowledgements] Consent & Confirmation

I Agree

Yes