We’re building a wallet that will be easy to use for everyone. In our first post, we covered how we’re accomplishing this: we’re building a combination of hardware and a mobile application that will let you choose how you want to balance the convenience of using the app for transfers and the security of requiring the hardware for authorizing higher stakes money movement. This means that the hardware is only one part of the experience - in fact, only a small part. Customers will primarily manage their money by interacting with the mobile application we’re building, and will only need to interact with the hardware in combination with the mobile app to authorize larger, less frequent transactions above an amount of their choosing.

For transactions that require using the wallet hardware, we want our customers to be able to unlock their wallets securely, but with ease - an unlikely combination that historically has not existed in the market. We believe PINs, passwords, and seed phrases are confusing and often not secure given the workarounds normal people have to create given all the friction. This compounds when the need for those passwords are more rare.

Instead, to achieve seamless authentication in practice, we plan to incorporate a fingerprint sensor into the wallet hardware. Every authentication technology comes with tradeoffs. We’re excited about the security against theft or misuse that this will provide, the peace of mind that will come from not needing to remember yet another PIN, and the ease of placing a finger on the sensor rather than manipulating tiny, failure-prone buttons on a difficult-to-read screen. We're aware of limitations we'll need to design around - for example, some customers will want to share access to their money without relying only on their fingerprint. As we build the product, we'll evaluate additional access methods that customers could opt into. And of course, fingerprint sensor data will never leave the hardware device. But don’t take our word for it - listen to the independent community that will be able to inspect and verify our source code. Are there other limitations we should be designing around?

Additionally, as we’ve continued to design the hardware component of the wallet, we recently chose to use a rechargeable lithium polymer battery and USB-C port to power the device. We believe this is the best choice for this product, as it optimizes for the best customer experience and design. We shared our thinking and solicited feedback using a SPADE, a decision document format commonly used within Block. You can read more about our decision here.

We’ve continued to build our team across hardware, software, supply chain, and product. Recently, Lindsey Grossman joined the team as our business lead, the driving force behind the product, marketing, and partnerships strategy and execution that will bring our wallet to the world. Cheng Lin Saw joined as our head of global supply, focused on the inputs, partners, and management we need to manufacture the wallet hardware. Finally, we’ve added three software engineers on Justin Williams’ team: Kirill Zhukov, Allison Moyer, and Scott Robinson, who bring a variety of expertise across mobile application development, backend, and architecture work. And we’re still hiring for software work. Want to build with us? Check out our software postings and let us know if you know a good lawyer!

Finally, we believe focusing on the mobile application as the primary interface will provide a more accessible, safer, and less expensive wallet. We don’t want to force new behaviors on customers with a novel interface on the hardware component of the wallet we’re building. Instead, making the mobile application the center of the experience will lead to familiar, intuitive interactions. As part of this approach, we plan to build the hardware without a display. We’ll get into this in more depth in a future post, including how we’re thinking about security considerations; for now, we’d like to hear from you. What compromises - be them user experience, security or anything else - do you think we’d be making without a display? What mitigations could we incorporate to soften any tradeoffs? Reply on our Twitter thread or to [email protected] – we look forward to hearing from you!

Share this post