In our last public update, we discussed why we're providing a simple self-custody product that puts customers in control. We also covered one of the core technologies we're using to help people keep their funds safe while providing a seamless experience for saving, sending, and spending.
We're building hardware, software, and services that together will provide easy to use, robust self-custody for our customers. We're currently designing the product, with a focus on the hardware component - we’re working through the industrial design (how it looks and feels), the user experience (how people use it), and the technical architecture (what internals make it work). We're approaching the many choices involved with a focus on keeping costs low, including the cost of the hardware itself, the time required to set it up and use it, and what secrets customers need to remember.
In designing a system like this, we have a broad set of choices to make: how the phone and hardware communicate, how the hardware is powered, what chips the hardware is based on, how the owner accesses it, and many more. We're still finalizing our choices in a number of these areas, so for today, we'll share just one: we've chosen to rely on near-field communication (NFC) for the link between the hardware and software components of the product. NFC is a wireless technology that allows two devices to communicate with each other at close range, and powers many payment, identification, and access cards, as well as smartphone-based technologies like Apple Pay.
Our choice was guided by a range of factors: we focused heavily on user experience, ubiquity, hardware cost, and security. Compared with alternative mobile communication methods like Bluetooth, NFC will help us keep interaction with the device simple and the hardware as streamlined and low power as possible, enabling us to provide a low cost, seamless experience. And, including a wireless method aligns with our focus on mobile usage and keeps people from needing a cable just to communicate with the hardware. Finally, while well-designed QR codes could also provide a smooth user experience, choosing NFC instead will result in less expensive, more reliable hardware -- and people will still be able to use QR codes for payment applications via the mobile application that makes up part of the product.
Furthermore, with both NFC and a robust way for the hardware to authenticate its owner, we will be able to provide a strong security perimeter for the hardware. Unlike most alternatives, NFC requires the two devices communicating to be very close to each other, which is ideal for a hardware wallet that should communicate only with its owner, not the neighbors. And while NFC involves plenty of implementation complexity, the hardware and software on each side of the link will still bring less attack surface into the product than Bluetooth and USB. There’s a long list of additional aspects we’ve considered here; security is a complicated topic and we look forward to sharing a comprehensive look at our threat modeling and mitigations in future posts.
As with all product and technical tradeoffs, our choice of NFC comes with some drawbacks, too. While keeping the cost down with NFC will help us reach a wider audience, not all smartphones can support it - and amongst the ones that do, some support it better than others. Fortunately, we see this counterbalanced; a strong majority of smartphones in the world already have NFC capability (more than 70% in 2018, and 80% in 2019), and we see a strong trend of adoption of this technology in new phones.
Alongside designing the hardware, we’re also diving into how we’ll build an intuitive, forgiving recovery experience that people can use when they lose their phone, hardware wallet, or both. With our underlying use of a multisignature wallet, people will be able to recover easily from losing just one item, but there are some big design and implementation questions on the best ways to get there and how to handle loss of more than one item. Does recovering always mean moving everything to a new wallet, requiring a transaction on the blockchain - or are there any safe ways to store backups of existing keys? If so, which ones, and how? In what ways might customers need to trust Square during the recovery process, if at all? If we are there to help, how much (or how little) does Square need to know about you to make sure recovery requests are coming from you and not someone pretending to be you? How can we best make sure customers have access to the details that are important to them, but that they are protected, by good product design, from fumbling with details all the time? We look forward to sharing some of our thoughts on these as we continue our investigations.
Finally, we're continuing to add to our talented team as we build simple self-custody for a global audience. We've recently brought in new team members in several areas. First, firmware engineering - writing the software that runs on the hardware portion of the product. Second, hardware engineering program management - our EPMs are central hardware development leaders who bring together people from a wide array of disciplines to deliver our hardware products. Third, software engineering leadership - a broad role responsible for building the team that will deliver the mobile, backend and web components, and for guiding our architectural decisions. And with such a wide range of disciplines involved in providing a seamless experience for mainstream customers, we’re continuing to expand in the following areas:
As always, if you have questions, feedback, or know someone we should be talking to about our open roles, you can reach us at bitkey@block.xyz.
