diff --git a/applications/FROST.md b/applications/FROST.md
index 4dd2449e509..f83d12b7c0c 100644
--- a/applications/FROST.md
+++ b/applications/FROST.md
@@ -243,7 +243,8 @@ Future plans may follow one of two directions, depending on the market feedback,
 - Decentralize and strengthen the security model of the protocol further. This includes:
   - Removing the central server that acts as the relayer (either by having multiple fallback servers or none at all, using libp2p for peer-to-peer communication*, for example);
   - Not having a single party acting as the Signature Aggregator. This can be useful for applications where the signers do not trust each other.
-  - Making the protocol robust and asynchronous, guaranteeing that a signing session always terminates in the presence of at least $t$ honest signers and under bad network conditions (https://eprint.iacr.org/2022/550.pdf).
+  - Making the DKG subprotocol robust, removing the need to restart it if a cheater is identified (https://eprint.iacr.org/2021/1658.pdf).
+  - Making the signing subprotocol robust and asynchronous, guaranteeing that it always terminates in the presence of at least $t$ honest signers and under bad network conditions (https://eprint.iacr.org/2022/550.pdf).
 - Add functionality to the protocol. For example:
   - Add support to ECDSA;
   - Optimize the scheme to be weighted, so that different parties have different amounts of shares (https://trust-machines.github.io/wsts/wsts.pdf);