 Yeah, hi, I'm Jared. I am the main organizer and thought leader on an open-source mobile Ethereum client called Status. Show of hands who's actually heard of us. Amazing. Cool. For those who don't know, Status is something like a hybrid instant messenger and mobile DAP browser. And really, we have one goal, and that's to take Ethereum technologies and put them in the hands of people. What I love about the Ethereum community is we've taken this fervor for crypto, but we've tempered it with pragmatism. And this has made blockchain technology palatable for organizations, banks, and governments alike. However, this pragmatism has been somewhat of a double-edged sword when it comes to taking this technology and putting it in the hands of people. And I'd like to start off with a short story that I think illustrates this point. So on October 1st, an autonomous community of Spain, Catalonia, held a referendum of independence. Leading up to the event, they used a superb decentralized file storage technology called IPFS to organize their votes. However, non-technical people were using a centralized HC proxy and accessed this information through the comfort of their own browsers. Leading up to the events, on the September 26th, I believe it was, Spain issued a blockade of 140 domains, one of which was this gateway. Politics aside, disrupting a vote shouldn't be that easy. At the same time, the Tor project saw a surge in the downloads of their messenger. This is the Catalans hardening their communications. And one of the many things we can applaud the Tor project for is that they understand they need to package and make their sophisticated software easy for the average user to use without compromising on the integrity of that software, because when push comes to shove, decentralization matters. And so how we package, disseminate, and present these technologies to the end user enables them in ways that we haven't been able to do before. And this is really the core problem that we aim to solve at status. So since our last DevCon, we spent a lot of time thinking about the overall user experience and design of the perfect Ethereum client. And nothing matters more than that first run. Together with our community, we've discovered what we think is the typical emotional narrative that a new person coming into the crypto world is likely to experience. And on that first run, we want to make sure they feel safe, in control, not overwhelmed, while at the same time connecting them with their goals and allowing them to explore Ethereum how they wish. While at the same time, we don't want to overwhelm them or demand information from them, unless it's absolutely necessary. For example, we don't need them to back up their key phrase until they actually have real value in their accounts. And at which point backing up their key phrase does become completely vital, and they have a reason to do so. And so that's when we educate them. We're also introducing an omnibar interstatus, which means that you can access anything you want to do with an Ethereum within just a few taps, whether that's accessing dApps, finding your friends, opening new tabs, or signing a transaction. We've also worked together with our community to develop what I think is one of the most visually stunning and intuitive wallet experiences that frames your digital assets perfectly. We've also wanted to make signing transactions as less intimidating as possible, while at the same time bolstering the protection against phishing attacks with a signing phrase of three words. Why were we building out that signing phrase? We actually found out that many of our users want to store sums of value and control them from their mobile phones, which are much larger than what they would fit in their normal analog wallets. And we realized that a software key pair is just not going to cut it. So today, I'd like to introduce you to our new initiative, which is a status hardware wallet. This is an open source Java card that allows you to take the trust, safety, and security of a hardware wallet, but use it on the go. It has two modes of operation, the first of which you can sign transactions directly on the card of arbitrary sizes. However, this requires vendor-specific hardware, namely to support Ketchak 256 and proper EC point multiplication. It is in the 305 spec, but finding a vendor that properly supports it is somewhat an interesting problem. And also to support Bluetooth as another communications protocol aside from NFC and Contact. The second mode of operation of which signs transactions generated off-card, all signing is pin bound. However, we do support key pairs and HD wallets. With the HD wallets having two extra features, the first of which is to store and export your whisper identity, and the second of which is to actually make one derivation path pinless. And therefore, this account becomes balance bound, but allows you to have frictionless transactions. But signing transactions doesn't really mean that much unless you've got someone to send transactions to or something. And so with Discover, we really want to connect you with people, and dApps, and communities. So we're solving the search problem in a decentralized manner. And this is what we do with Discover. Discover is basically a naive epidemic protocol in which users publish public statuses with the use of hashtags. And this is propagated to their friends. Every user then collects a cache of messages that they've seen. And periodically, they generate a preference list and then share that subset with all of their contacts. This preference list is generated by a bunch of different waiting factors. For example, if they're mutual friends, that they're like how recent it is if they're online, there's a bunch of others. Oh, yeah, like if they've been chatting with that person or interacting with that dApp for a long period of time, and if they trust them. And so in status, we're actually going to be building multiple layers of trust. And this is going to be the first layer, which is basically automated. Because when a status is shared, it is signed by the propagator. This allows us to build chains of propagation to see how far something's propagated, who by, and the same with moderation and reporting. So as you may know, status is built entirely on Ethereum protocols. And therefore, we use whisper as our messaging transport. Whisper has amazing privacy features built into it. However, it isn't without its problems. And one of these is essentially both peers need to be online when communicating. In normal usage, a sender will send their message to a recipient. It'll bounce around the network, eventually arrive at its destination. And this recipient will send an acknowledgment of that message. However, if the recipient is offline, the sender will send out a message and periodically resend it. But the recipient is both unaware that they've received a message. And they need to come back online and wait for the sender to rebuild their chat history. So we are introducing status nodes, which act as offline inboxes for whisper, as well as helpers for external services, such as push notifications. It basically works on a promise challenge deposit. And it allows the sender to send these messages out. They get collected in these nodes. The recipient can be then informed, come back online, and rebuild their history with a node, even if the sender is not available. Well, you may be wondering, well, who is going to run these nodes? And of course, if somebody has a server, they can run it in a headless way. But really, we think we can do a bit better than that. And so we actually think you can do it, because we are actually expanding our platform reach. So we're not targeting Android and iOS anymore, but we're also targeting Linux, Mac OS, and Windows. And so with this, we're going to make it dead easy for you to set up a status node and integrate with external services, whether they're other chat protocols or push notifications. And at the moment, we have an internal friendly competition. We do build status on a single code base, and that rests on top of React Native. So the more developed version there is actually using React Native Web. And the other one is another fork of a canonical project where we're actually building React Native from the ground up for desktop based on QT. And currently, we have 60% component coverage on that. So it's hiding times for us. In addition to this, another problem that we've really faced in growing our organization is that the talent pool in the crypto community is exceedingly small. So we want to take the strengths of being an open source project and help incentivize contributions. And this is what we're doing with Open Bounty. This allows you to take any GitHub issue and create a bounty for it that anyone can then contribute to, whether it's F or any ERC-20 tokens. But we're actually taking this a step further from just the general mechanism, which we've had for a while. And we're actually building out our talent scouting and human resources around this so we can help other decentralized organizations build their software just like we are. And in fact, we also have a million dollar bounty coming up to help other organizations get involved. So please come join us at openbounty.status.im if this is interesting to you. In terms of our next steps, now we need to focus on optimization. We're deploying our security audits, which allows us to move into production. We're also supporting identity standards. And we're experimenting with the Swarm Messaging Service PSS for more convenience. So that's it for me. Thank you so much. And I hope you're all using status.