Weighted threshold signatures with ROAST
ROAST (Robust Asynchronous Schnorr Threshold signatures) is a protocol that coordinates multiple participants — each holding a piece of a private key — to jointly produce a valid Schnorr signature. In a typical threshold scheme, it’s enough for any t out of n participants to collaborate in order to sign a message; however, straightforward threshold signing can stall if one or more participants fail to respond. ROAST tackles this by creating a “robust” and “asynchronous” system: it collects partial signatures from responsive participants and can produce a final signature even if some participants are offline or acting maliciously. This design ensures that liveness (the ability to eventually create a signature) is maintained while still preserving the security guarantees of threshold cryptography.
(Participants)
┌───┐ ┌───┐ ┌───┐
│ A │ │ B │ │ C │
└───┘ └───┘ └───┘
\ | /
\ | /
\ | /
┌───────────────┐
│ Partial Sigs │
└───────────────┘
|
v
┌────────────────┐
│ Aggregated Sig │
└────────────────┘
|
v
┌──────────────────┐
│ Blockchain Ledger│
└──────────────────┘ROAST appears particularly useful in the cryptocurrency realm by allowing large groups of signers to jointly secure funds under a single aggregated signature. In expansive multisig scenarios — like corporate treasuries, DAO treasuries, or community-managed funds — ROAST empowers hundreds of stakeholders to collectively own a single wallet. Only a set threshold (for instance, 150 out of 200) must work together to produce a valid transaction, significantly raising the difficulty for attackers to compromise the entire signing group. Meanwhile, on-chain transactions appear as though they came from a single signer, preserving both privacy and cost-efficiency.
Thanks to ROAST, potentially hundreds or thousands of participants can conduct most of their coordination off-chain by merging partial signatures into one final Schnorr signature. Rather than broadcasting separate signatures or transactions for each participant, only a single aggregated signature makes it on-chain. This method drastically reduces data usage, transaction fees, and block space needs, effectively scaling the underlying blockchain by keeping the bulk of multi-party coordination off the main ledger.
Weighted ROAST
In a standard ROAST setup, each participant’s key share carries equal weight. Any valid combination of t shares suffices to produce the signature, regardless of which participants contributed. This “one-share, one-vote” model is straightforward, but it may not fit more complex applications where certain signers hold disproportionately larger stakes, possess unique responsibilities and require a stronger say in collective decision-making.
For example, if one organization shoulders half of a DAO’s overall treasury deposits, it might be reasonable for that entity’s consent to carry a correspondingly higher weight.
Imagine this hypothetical ROAST swarm, ten participants — each identified by a colour — hold different proportions of a governance token. Rather than distributing control equally, the system weights each signer’s influence according to their stake, ensuring fair representation and stronger alignment with their actual investment. Here’s an overview of each signer’s share:
- Red: 2.25%
- Blue: 16.20%
- Orange: 1.47%
- Pink: 10.65%
- Green: 0.58%
- Indigo: 26.00%
- Purple: 5.00%
- Yellow: 18.50%
- Brown: 15.35%
- Gray: 4.00%
The goal is to have fair representation: participants’ influence is tied to their actual stake.
Proof of Ownership and DKG Ceremony
DKG (Distributed Key Generation) in ROAST is a process that lets participants collectively produce a single public/private key pair without exposing their individual key fragments to one another.
In weighted ROAST, before the Distributed Key Generation (DKG) ceremony begins, each participant must demonstrate how many governance tokens they hold. This is usually done via an on-chain proof — such as a signed message — that confirms control over the address with token balance from the relevant ERC20 contract.
“I, 0xA1b2C3D4E5F67890123456789012345678901234, confirm ownership of 15,000 GOVERNANCE tokens.”
Once token ownership is verified for every swarm participant, by every swarm participant, the group initiates the DKG process. But with a twist.
The twist in this weight-modified DKG process is the idea of virtual shares: instead of giving each swarm participant exactly one key fragment (and treating them all equally), the group allocates a total of 1000 shares based on each participant’s stake. For example, if Indigo holds 26% of the governance tokens, Indigo receives about 260 virtual shares, thus gaining correspondingly greater influence in the final signature. To ensure the sum of all shares remains 1000, we employ “round half to even” (Banker’s rounding):
- first multiply each stake by 1000,
- then apply round half to even to each product,
- and finally, verify the total is exactly 1000 before finalizing the distribution.
+----------+-------------+-------------------+
| Particip.| Percentage | Virtual Shares |
+----------+-------------+-------------------+
| Red | 2.25% | 23 |
| Blue | 16.20% | 162 |
| Orange | 1.47% | 15 |
| Pink | 10.65% | 107 |
| Green | 0.58% | 6 |
| Indigo | 26.00% | 260 |
| Purple | 5.00% | 50 |
| Yellow | 18.50% | 185 |
| Brown | 15.35% | 153 |
| Gray | 4.00% | 40 |
+----------+-------------+-------------------+
| TOTAL | 100.00% | 1000 |
+----------+-------------+-------------------+This is just an illustration, each swarm can have its own rules of rounding.
8-of-10 Threshold, Weighted by Stake
In our example, the ten-strong swarm is structured as an 8-of-10 threshold. Because there are 1000 total virtual shares across the participants, this implies that at least 800 of those shares must collectively sign to produce a valid signature. The higher a participant’s governance stake, the more shares they hold, and therefore the more weight they carry in meeting that 800-share requirement.
Potential Use Cases
- Sidechains: A sidechain governance token can act as the basis for allocating stake and deciding membership in a cross-chain bridge. Validators or custodians who own more tokens get a proportionally larger number of virtual shares.
- Oracles: When building an Oracle service with governance tokens, participants who invest more could be given higher voting power. This weighted approach could also tie into profit sharing or other mechanisms.
- DAOs: Many decentralized autonomous organizations rely on multisig setups for treasury and operational decisions. Weighted ROAST can be a drop-in replacement for simpler “n-of-m” multisigs, preserving the asynchronous, robust nature of ROAST while reflecting each member’s governance stake.
Nuisances and Drawbacks
One operational challenge is the need to regenerate the swarm whenever ownership ratios change. If, for example, Pink sells 10% of her tokens to a new participant named Black, the entire distribution of virtual shares must be recalculated so that the weighting remains accurate. This implies:
- Swarm participants must monitor token balances in the relevant contract(s).
- Any change in ownership requires a new DKG ceremony, ensuring everyone’s shares remain up to date.
- New stakeholders only join once a reshuffle is initiated and completed, meaning the group cannot simply “add” them on-the-fly without going through the reconfiguration process.
Despite these coordination overheads, Weighted ROAST can dramatically enhance governance and accountability for multi-party signature schemes. By tying influence to actual stake, participants with larger investments can more effectively safeguard their interests while still benefiting from the robust, asynchronous properties that ROAST provides.
