Firefly — IOTA’s Next Generation Wallet

IOTA 1.5 is fast approaching…

With it come a range of improvements that will transform IOTA from an exploratory research project into a mature, enterprise-ready protocol. Experimental features like trinary encoding and Winternitz One-Time Signatures (W-OTS) have been removed and replaced with carefully-selected, tried-and-tested standards. These changes will allow IOTA to realize the original promise of a DAG-based DLT protocol without the technical baggage and entry barriers introduced by early design choices.

For most of us, our primary gateway to a DLT protocol is a wallet. Wallets allow users to manage their cryptocurrency holdings and secure their private key when sending and receiving tokens. Conventionally wallets have limited their functionality to basic payments. But increasingly, wallets are expanding their feature sets and becoming platforms for the many innovations of DLT.  

Until now, IOTA’s primary wallet has been Trinity. Trinity set a high standard in the industry, with a slick design and simplified user experience that few other wallets could match. Trinity was IOTA’s first stateful wallet, successfully making one-time signatures safe for human use. But Trinity, like the number system it owes its etymology to, will remain in IOTA 1.0.

We have taken IOTA 1.5 as an opportunity to rethink the wallet from the ground up, from transactional logic to user experience to design. We have drawn on everything we have learned over a three year period and built an app that will serve as a platform for IOTA’s current and future ecosystem. Our wallet for IOTA 1.5 and beyond will be called Firefly.

Firefly has been built with the future in mind — the wallet’s technical architecture and user interface were designed in the context of later additions like tokenized assets, chat and contact management. Over the following year we will see a number of additional features join the wallet’s stack.

The major steps forward in Firefly’s first version are security, core user experience and an expandable architecture. If you want an app to become an extensible platform, your primary focus should be on perfecting your core. With attention on the core, the initial features build on Trinity’s existing feature set. However, there are some key differences:

• We have introduced the concept of profiles and accounts. Profiles mean multiple people can use the app on the same device without access to each other’s wallets. While accounts mean that a user can separate their funds across, for example, a main account, a spending account and a Ledger Nano account.
• Throughout the app, common UX hiccups have been resolved and other minor features have been added. For example, your pin will open your wallet without ever decrypting your seed, allowing you to check balances securely. Meanwhile, we have added a network indicator to give users information on the current health of the IOTA network.
• Firefly also enjoys the many benefits of Chrysalis, including reusable addresses, 24-word recovery phrases and improved network performance.

A key limitation in Trinity was its tight coupling between the logic and application itself. With Firefly we are following an approach where everything should be reusable by other developers in other applications. As a result, we already have a useful set of tools for other devs to build with.

Stronghold is perhaps the most significant innovation in the first version of Firefly, vastly improving the security of the wallet. Sensitive operations like address generation and transaction signing take place in isolated application memory, keeping the seed away from would-be attackers. Stronghold also serves as a key-value store and is used for app storage. What this means is that your wallet becomes entirely portable. You only need a recent Stronghold backup to take your seed and transaction history to another device or another wallet app altogether.  

All transactional logic in Firefly is provided by wallet.rs — a comprehensive IOTA wallet library written in Rust. The library provides all the functionality needed to build wallets and exchange integrations, from account creation to initiating transfers, to state management and backup. Wallet.rs targets Chrysalis, meaning that when the upcoming Chrysalis testnet is deployed, wallet.rs will become available for use. The first version will come with Neon bindings for Node JS, with Python and WASM following, and others planned later on.  

Thanks to wallet.rs and stronghold.rs, developers can easily integrate secure wallet and payment functionalities within a variety of use cases and environments. We anticipate a range of community projects that build wallets and other applications with this tooling.  

We have also applied the mentality of reusability to the user interface design and plan to expose a component library for developers to restyle and use in their own projects. Meanwhile, we are working in parallel on a plugin system with an access-control API to give users control over what features they activate in their wallet.

We have big plans for Firefly. As the entry-point to IOTA’s ecosystem, Firefly will integrate many of the upcoming features of the IOTA protocol, from tokenized assets and dApp interaction to mana delegation and Identity. Firefly will also see new features that enhance IOTA’s user experience as a payment protocol, such as a contact system and an accompanying browser extension. Our priority is first on releasing the desktop version, before attention turns to mobile, and later, the contact system and chat.

Firefly’s desktop version is currently in advanced stages of development and we are aiming for our first alpha in December. We will be looking for wallet testers and translators in the coming weeks. Look out for the X-Team applications on Twitter and Discord.

If you want to join the discussion about Firefly or have any questions for the developers and designers then join #firefly-discussion on our Discord server.