# FROSTED: the first step towards a seedless future

**URL:** https://forum.hypercore.one/t/frosted-the-first-step-towards-a-seedless-future/326
**Category:** Development
**Created:** [January 26, 2024, 8:26pm UTC](https://forum.hypercore.one/t/frosted-the-first-step-towards-a-seedless-future/326 "2024-01-26T20:26:59Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![aliencoder](https://forum.hypercore.one/user_avatar/forum.hypercore.one/aliencoder/32/49_2.png) [@aliencoder](https://forum.hypercore.one/u/aliencoder)
#### Post date: [January 26, 2024, 8:26pm UTC](https://forum.hypercore.one/t/frosted-the-first-step-towards-a-seedless-future/326/1 "2024-01-26T20:26:59Z")

</div>

# FROSTED seedless wallet

[FROSTED](https://github.com/alienc0der/frosted) is a Flutter demo application that integrates a Rust-based implementation of the [FROST](https://github.com/ZcashFoundation/frost) (Flexible Round-Optimized Schnorr Threshold) by the Zcash Foundation.

It showcases an interactive demo, primarily focused on building cryptocurrency seedless wallets using threshold signatures, enhancing security and flexibility for blockchain users.

## Why?

Most of you are familiar with [BIP39 cryptocurrency wallets](https://www.blockplate.com/blogs/blockplate/one-seed-phrase-bip39-wallet). The problem with such a wallet is obvious: if your seed is compromised, your funds are gone.

## Can we do better?

- **Distributed Trust** : In seed-based wallets, the entire security hinges on the seed phrase. If this seed is compromised, all associated assets are at risk. In contrast, seedless wallets distribute trust across multiple key shards. An attacker would need to compromise multiple shards to gain control, significantly raising the security bar.
- **Reduced Single Points of Failure** : By avoiding a single seed phrase, seedless wallets eliminate a critical single point of failure. This distributed approach to key management reduces the risk of total asset loss due to single key compromise.

## Key shard security

This is the most important aspect: the key shards must be encrypted and stored separately such that an attacker is unable to perform the `keysign` operation.

Example for 2 out of 3 threshold setup:

- One key shard protected by the secure enclave of the processor
- One key shard backed up on a cloud provider
- One key encrypted using a `PIN` or `passphrase`

In the future, it can be integrated in both Syrius desktop and Syrius mobile wallets.

PS: I’m planning to apply for an AZ grant for this project.

---

<div class="post-metadata">

### Author: ![aliencoder](https://forum.hypercore.one/user_avatar/forum.hypercore.one/aliencoder/32/49_2.png) [@aliencoder](https://forum.hypercore.one/u/aliencoder)
#### Post date: [January 27, 2024, 9:20am UTC](https://forum.hypercore.one/t/frosted-the-first-step-towards-a-seedless-future/326/2 "2024-01-27T09:20:53Z")

</div>

A demo is worth a thousand words:

I invite you to test the [latest release](https://github.com/alienc0der/frosted/releases/tag/master).

---

<div class="post-metadata">

### Author: ![0x3639](https://forum.hypercore.one/user_avatar/forum.hypercore.one/0x3639/32/33_2.png) [@0x3639](https://forum.hypercore.one/u/0x3639)
#### Post date: [January 27, 2024, 11:22am UTC](https://forum.hypercore.one/t/frosted-the-first-step-towards-a-seedless-future/326/3 "2024-01-27T11:22:24Z")

</div>

Very cool. Maybe @Nostromo can use this with the Gravity Wallet?

@aliencoder if you have 2 of 5 required, would you sign a TX in syrius AND would you need to use another device to sign also?

Or, do you map the location of the other seed shards in Syrius and sign all shards right from syrius? If a second device is not needed to sign, can an attacker compromise syrius and download the mapped shards and still sign messages?

 ![Screenshot 2024-01-27 at 5.18.40 AM](https://hypercore.nyc3.digitaloceanspaces.com/original/1X/c24f3826bda4c1887cc19bed87e1152e9602138d.jpeg)  
 ![Screenshot 2024-01-27 at 5.18.30 AM](https://hypercore.nyc3.digitaloceanspaces.com/original/1X/7ab2f7609a2b9e117e70a5df3892c5013e8497e9.png)  
 ![Screenshot 2024-01-27 at 5.18.17 AM](https://hypercore.nyc3.digitaloceanspaces.com/original/1X/5ad6aedc9c3544da1658083ec5ca1ed594837af0.png)

---

<div class="post-metadata">

### Author: ![aliencoder](https://forum.hypercore.one/user_avatar/forum.hypercore.one/aliencoder/32/49_2.png) [@aliencoder](https://forum.hypercore.one/u/aliencoder)
#### Post date: [January 27, 2024, 9:04pm UTC](https://forum.hypercore.one/t/frosted-the-first-step-towards-a-seedless-future/326/4 "2024-01-27T21:04:12Z")

</div>

> [@0x3639](#):
>
> @Nostromo can use this with the Gravity Wallet?

Yes. And Dr. Blaze with the Syrius Mobile Wallet.

> [@0x3639](#):
>
> @aliencoder if you have 2 of 5 required, would you sign a TX in syrius AND would you need to use another device to sign also?

All the operations are performed locally. It is implemented using the `Trusted Dealer` setup that assumes a trusted entity (eg. the non-tampered app on your certified device) to run the `keygen` ceremony.

The security of the `FROSTED` implementation comes from the idea that every key shard should be decrypted only by an authorized party.

> [@0x3639](#):
>
> If a second device is not needed to sign, can an attacker compromise syrius and download the mapped shards and still sign messages?

Think it this way: you can have 2 shards on your mobile device, one encrypted by your `secure enclave processor` and another one by a `passphrase`. The attacker needs _both_ your `FaceID`/`TouchID` _and_ your passphrase in order to be able to perform a successful `keysign` ceremony. The 3rd shard (backup shard) can be safely stored on your `Google Drive` or `iCloud` account.

So the attacker must spoof your passphrase _and_ compromise your `Google Drive` or `iCloud` account (assuming that he is not a nation-state that can break into the `secure enclave`), which is significantly harder than social engineering a user into giving up his `mnemonic`.

---

<div class="post-metadata">

### Author: ![coinselor](https://forum.hypercore.one/letter_avatar_proxy/v4/letter/c/41988e/32.png) [@coinselor](https://forum.hypercore.one/u/coinselor)
#### Post date: [January 28, 2024, 3:16pm UTC](https://forum.hypercore.one/t/frosted-the-first-step-towards-a-seedless-future/326/5 "2024-01-28T15:16:49Z")

</div>

Seedless under the right setup seems to be a lot less stressful than managing the security of a 24 word seedphrase. Backups, social recovery, etc all becomes much more manageable.

I recently came across the concept of ICP’s [Oisy wallet](https://github.com/dfinity/oisy-wallet). I didn’t fully grasp the technical implementation; it appears to involve an embedded contract and some form of ID layer, which already raises some privacy concerns. Nevertheless, it seems to effectively implement a similar seedless multi-party threshold signature.

What I found particularly impressive was the user experience of the wallet, which requires no app or extension installation. If we can replicate this while simultaneously including PoW providers for a truly feeless onboarding experience, that could be something truly amazing.

---

<div class="post-metadata">

### Author: ![aliencoder](https://forum.hypercore.one/user_avatar/forum.hypercore.one/aliencoder/32/49_2.png) [@aliencoder](https://forum.hypercore.one/u/aliencoder)
#### Post date: [January 28, 2024, 10:02pm UTC](https://forum.hypercore.one/t/frosted-the-first-step-towards-a-seedless-future/326/6 "2024-01-28T22:02:54Z")

</div>

> [@coinselor](#):
>
> I didn’t fully grasp the technical implementation

`FROST` is far superior than ICP’s [ECDSA TSS](https://internetcomputer.org/docs/current/developer-docs/integrations/t-ecdsa/).

---

<div class="post-metadata">

### Author: ![coinselor](https://forum.hypercore.one/letter_avatar_proxy/v4/letter/c/41988e/32.png) [@coinselor](https://forum.hypercore.one/u/coinselor)
#### Post date: [January 29, 2024, 6:32am UTC](https://forum.hypercore.one/t/frosted-the-first-step-towards-a-seedless-future/326/7 "2024-01-29T06:32:04Z")

</div>

🥶 🥶
