Background

Security researchers at Halborn have disclosed an instance where a Secret Recovery Phrase used by web based wallets like MetaMask could be extracted from the disk of a compromised computer under some conditions. The following does not impact MetaMask Mobile users, and impacts a small segment of MetaMask Extension users as well as users of other browser/extension wallets. We felt this violated the user expectations of our password lock feature, and could therefore put some users at risk. We have since implemented mitigations for these issues, so these should not be problems for users of the MetaMask Extension versions 10.11.3 and later. If all of the following three conditions apply to you, you may be at risk, and you should read below for next steps:

• Your hard drive was unencrypted
• You imported your Secret Recovery Phrase into a MetaMask extension on a device that is in possession of someone you do not trust, or your computer is compromised
• You used the “Show Secret Recovery Phrase” checkbox to view your Secret Recovery Phrase on-screen during that import process. (see image)

Impact

This affects:

• All desktop operating systems and browsers that we have tested.
• We tested on Windows, macOS, and Linux, with Google Chrome, Chromium, and Firefox browsers.
• All versions of the MetaMask extension (prior to v10.11.3) on all browser versions.

This does not affect MetaMask Mobile.

The Secret Recovery Phrase does get cleared eventually, but we cannot make guarantees about when at this time.

This vulnerability is most likely to affect users who had a device compromised or stolen soon after importing their Secret Recovery Phrase into MetaMask.

If all of the above conditions apply to you, then your Secret Recovery Phrase may be accessible to someone with access to the computer you imported your Secret Recovery Phrase on, and you may want to consider migrating funds from those accounts to be safe. We have prepared a guide to migrating account funds here. Use of any third party migration tools must be used at your own risk.

This vulnerability could be exploited either by a person with physical access to your machine or by malware. However, if your device is compromised by malware, there are already many other attacks we cannot protect against (like keyloggers, direct memory access, and program control).

If you think you are vulnerable to this

If your computer is not physically secure from people you do not trust, we recommend you enable full disk encryption on your system. Additionally, you are not affected by this if your funds are managed by a hardware wallet. You can learn more about our hardware wallet support here.

Affected users should consider migrating the funds from the accounts generated by that Secret Recovery Phrase to new accounts generated by a new Secret Recovery Phrase. We’ve set up a guide to help you do this if needed, and assembled a few software options that can help make it easier.

The rest of this document will provide some additional details, and suggestions about how to best keep your wallet safe. At a later date we will disclose more specifics about the nature of the issue, so that other software developers can avoid these issues themselves, but for now we are first disclosing recommended user actions to minimize the risks of theft.

How secure am I?

As stated before, if a computer is compromised–either outside of your physical control, or has malicious software on it–you can’t be sure of the security of any program running on it.

This is a problem that has been acknowledged and discussed by the 1Password team, a popular password manager. Explaining the difficulties in solving it, Jeffrey Goldberg, a Principal Security Architect at 1Password, stated: “This is a well-known issue that’s been publicly discussed many times before, but any plausible cure may be worse than the disease.”

If you’re using a password manager, you’re likely more secure than those who aren’t — yet even password managers aren’t immune to flaws.

Conclusion

Ultimately we’ve learned that our password encryption feature’s security was partially undermined by browser behavior. Since browsers themselves consider physical access attacks to be outside of their threat model, and our current wallet is built on top of the browser, it has proven labor-intensive to reduce the size of this attack surface, and it may be impossible to fully eliminate it. Ultimately it is likely that only full disk encryption can provide your computer strong safety against physical computer access.

Is this something that you should have expected? It depends whether you thought your Secret Recovery Phrase could be recovered on disk or not. If you assumed your computer needed to be kept secure, you should be fine. If you believed the MetaMask password implied that no one with access to your computer was able to extract your accounts, then this may be a surprise to you.

At a high level, it should generally be expected for computers/browsers/etc. to store text inputs on some level, whether temporarily or permanently. However, due to the nature of how significant it is to keep your Secret Recovery Phrase secure, this specific scenario needs attention brought to it so users can act accordingly.

Fortunately, it seems that the password is still providing some level of security. We’ve only found that the Secret Recovery Phrase could be extracted under very specific circumstances, and we’ve been able to introduce new protections over the period that Halborn has waited to disclose, and have a few more we plan to implement. We will continue to introduce additional security mechanisms that reduce this risk even more. This means it is still good practice to lock your wallet if you’re not using it (or passing your computer to someone else).

A few important things:

1. Please take the time to enable full disk encryption on your computer. It’s the only way to be sure that someone with physical access to your computer isn’t able to extract all of its contents. We also recommend the usage of hardware wallets as an additional security measure.
2. Clear your browser cache data (our research shows this may help some users in some cases)
3. Remember that it’s your responsibility to keep your computer secure. No wallet or software can keep itself safe if the system it runs on is compromised. Take time to learn how to avoid installing a virus on your computer.

Here are a few guides for keeping different operating systems secure:

• Windows
• Mac
• iOS
• Android
• Linux

Conclusion

We’d like to express our thanks to the team at Halborn for responsibly disclosing this, and for all of their hard work helping to protect this space. See more of their work.

We’ve awarded Halborn $50,000 USD for this discovery.

Have concerns, want to learn more, or have a bug you’d like to disclose? Please reach out to us at security@metamask.io.

MetaMask is hiring! If you’re someone who can help make our products and this industry safer and more secure, consider joining our team.

Security Notice: Extension Disk Encryption Issue was originally published in MetaMask on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve seen a lot of wallets come and go during my time building MetaMask, and none are quite like MyCrypto. Eminently configurable (regularly adding every obscure configuration, hardware wallet, or new protocol feature ahead of basically everyone else) while staying friendly, usable, and maintaining a communications channel full of colorful education, smart security alerts, and nuanced analyses of the current climate.

Taylor and her team have grown to be absolute cornerstones of the Ethereum ecosystem. Whether it’s Jordan’s relentless community engagement, Harry’s tireless anti-phishing initiatives, or the constant slew of open source libraries and experiments coming from their team, they have become an important part of what Ethereum is today.

For years our teams have collaborated. We’ve helped each other report scammers so they’ve been taken down faster, but also our wallets have literally inter-operated for years. It’s a weird thought, whilemany treat wallet development as a zero-sum game, MyCrypto found a wallet niche where they have been able to bridge so many signers and essential features for Ethereum users to have access to. I think it reflects their unique understanding of the way that web3 allows each component to interoperate, not just compete.

Our roles in the ecosystem are so aligned that I barely feel like I need to point them out: MyCrypto will help MetaMask become safer, more stable, and even more feature-rich. Together, we will continue to buld increasingly user-centric, extensible, and decentralized products. And now, with their web product and desktop application and our mobile apps and browser extensions, we will be able to connect people to the world of web3 in even more ways.

MyCrypto joins MetaMask at a moment of historic growth. Our team has never been larger, and we’re taking the opportunity to kick off several new teams: A security and anti-phishing team to ensure we are increasingly responsive to our increasingly dangerous environment. A core libraries team to ensure that our wallet is maximally small, robust, and portable across platforms. An API-focused team, to ensure that developers are able to make better dapps more easily, and a developer education team that helps make sure that builders know what’s possible.

For me, this represents a particularly powerful moment in our team’s history. When I helped start MetaMask with Kumavis, I was a fast-iterating coder. I added features quickly (sometimes too quickly), but so much of what I feel I brought to the project was always being close to the metal, caring about interoperability and iterating on our APIs. As our team has scaled I’ve needed to step into a larger product-vision and user-experience type of role. With Taylor joining the team, we’re going to have a product leader with unprecedented experience and passion for keeping users safe. I expect her to be able to be able to much of that work better than I’ve been able to, and free me up to focus on some of the work that I’m better suited to.

It’s clear that the wallet has a challenging but special role to play in the next iteration of the web, and with our powers combined, I’m confident we’ll be helping usher it in better than ever.

From all of us at MetaMask to all of you building the next web: We hear you, we’re working hard to give you the experience you deserve.

To everyone on the MyCrypto team who is just joining now: Thanks for making us a part of your journey. Let’s take the wallet to new heights.

Welcoming MyCrypto to MetaMask was originally published in MetaMask on Medium, where people are continuing the conversation by highlighting and responding to this story.

Moxie Marlinspike on Twitter: "Wrote some notes summarizing my first impressions of web3: https://t.co/16MoPROOGc / Twitter"

Wrote some notes summarizing my first impressions of web3: https://t.co/16MoPROOGc

I'll start by briefly noting the irony that he wrote his thoughts on a self-hosted blog. I am replying from a centralized blogging provider with a history of censoring crypto content (yes, I feel the shame, but I'm being pragmatic).

Edit: I’ve now learned that Mirror no longer requires an invite. It would’ve been cooler for me to write this from there.

Things Moxie Got Right

The way Ethereum dapps today rely on hosted providers feels shy of the original promise, and if they continue this trend, it would seem to imply there was no advantage to having a full node in the first place.

NFTs should be ashamed for how often they are mutable, and as suzuha writes, wallets should help users become aware of when they are (issue opened).

The way wallets today rely on services like OpenSea for indexed data is not decentralized (although I disagree that this is the inevitable course of action, or a good direction to head).

What Moxie Missed

The Presence of Client Friendly Protocols

Moxie makes a big point of how modern wallets are doing nearly no validation of blockchain state, and are just trusting servers. This is basically needed for Ethereum in its current state, but it doesn’t need to always be so.

There are spaces in-between; protocols that are more friendly to running on-client. At MetaMask we pursued a light-client called Mustekala (now surviving in parts of TurboGeth and Laconic), and both Vitalik and Suzuha discuss other protocols that give longer term hope in that direction , so I’ll leave it at that for now.

HTTPS is signed data

I know Moxie knows this well. Maybe he’s imagining some kind of HTTPS-downgrading attack on Infura, but for a user’s wallet that is requesting Infura information via HTTPS, the information coming from it is absolutely signed. Not in a way that enables p2p gossip of that data (the way I presume Laconic will), but still I think some of his points about just how bad the status quo is were slight exaggerations.

The Right of Exit

Even nerds do not want to run their own servers at this point. Even organizations building software full time do not want to run their own servers at this point. If there’s one thing I hope we’ve learned about the world, it’s that people do not want to run their own servers. — Moxie Marlinspike

One of MetaMask’s first design differentiators from the dominant player before us (Mist) was something that Moxie described: the introduction of a trusted source of blockchain data (Infura) instead of requiring every user to self-host an Ethereum “client”. This allowed users to get started right away and without constantly draining their laptop batteries. It was a game changer for adoption, and it kind of demonstrated what Moxie said here: People don’t really want to host their own server (certainly not one that is designed to consume a full laptop of capacity).

I think this revealed a fundamental truth about what wallets are, and it’s that wallets are portable. If a full-node isn’t portable, then a full node is not part of a wallet. If no full node is portable, then a wallet is just a tool for trusting somebody else. If a wallet is just a tool for trusting someone else, then who needs a blockchain? Why not just have a bank?

I think part of the answer is “right of exit”.

The right of exit doesn’t matter when you can fully trust your provider, forever. Maybe your bank is fine, and credit cards serve you, so the notion of digital money is unbelievably stupid sounding to you. If you’ve had your account frozen because the bank didn’t like where your money was coming from, you might have a different perspective on it.

I think a lot of web3 ethos lives right in here. It springs from a patchwork of deep wounds from a lifetime of being betrayed by seemingly every centralized institution that ever gained our trust. The most extreme stance is that this means the infrastructure must trust nobody, but upon hitting the impracticalities of that approach, I think accountability is a surprisingly strong second-best option.

While MetaMask ships with Infura, we’ve always allowed users to choose their own blockchain connection instead. I would even say that I think ideally the wallet could connect into user-chosen alternatives for all of its services, and the hard-coded exceptions like OpenSea today are mistakes, written to hastily satisfy the demands of the gold-rush crazed user demands, as Moxie described. We’re working to rectify those kinds of decisions, and we keep hiring people who thoughtfully care about getting these kinds of decisions handled right.

You might ask: Why in the hell would a business choose to make it easier to opt-out of themselves? I think we can just think of it as a feature. It may not be a feature that every user demands upfront, but it’s a feature that if we can adhere to, we can try to force ourselves to increasingly make the decisions that keep ourselves honest, and keep delivering the thing that our users wanted as faithfully as possible, which is basically just a shared digital space they can trust.

There Are Viable Alternatives to the Centralized NFT Index

I love the part of the article where Moxie breaks down the exact API calls that are enabling current wallet behaviors. I think this is an excellently lucid way to discuss how it works, and OpenSea is a great example of one (apologies to OpenSea for repeatedly punching at you. It isn’t you, it’s our over-reliance on you that is wrong).

The thing is, we know that “hitting a centralized index for your possessions” is a flawed strategy. In tokens MetaMask has done much better here IMO, while other wallets are highly prone to airdrop scams where an attacker sends an asset “to the user” and it now appears in the user’s wallet (their sanctum!), and the phishing can commence from there.

Today, MetaMask is doing something similar via OpenSea, and this is no secret, and it sucks. Relying on a central detection API means that you are either missing assets you might care about (so much for equal opportunity!), or you are seeing assets you don’t (so much for safety!).

A better solution is to make asset detection a client-centric act of consent. Most wallets allow adding custom tokens. Via EIP-747, MetaMask also allows a site to suggest a custom asset to the user’s wallet, and so the user’s wallet becomes the index of assets, no central server needed. We intend to do something similar for NFTs. For the middle-space between fully user-initiated and community-curated, Uniswap’s token lists standard is another approach to allowing the decentralization of the indexing phase. As more standards like this become widespread, I think we’ll see less and less delisting of fair art projects (like Moxie’s), while actually also improving performance and reducing reliance on external parties.

The Role of the Wallet

The last thing I want to touch on (and it relates to the above points) is the role of the wallet. What the hell is this new piece of technology we’re talking about? Your article’s headline is “web3”, after all, not “Ethereum”, indicating there are other pieces here that make up the system. Until a couple of years ago, I think people didn’t take wallets seriously, and thought of them as super thin software that ideally does nearly nothing, a bit like Moxie describes in his article. I think some of us at MetaMask thought similarly when we started out.

MetaMask doesn’t actually do much, it’s just a view onto data provided by these centralized APIs. This isn’t a problem specific to MetaMask — what other option do they have?
 — Moxie

I’ve come to see the wallet’s role as enormously large, instead. So large that it’s at dangerous risk of bloat and massive re-centralization if it isn’t managed carefully. In particular, while the full node may be “providing all the data”, the wallet is the tool that helps the user give informed consent.

the wallet is a tool that helps the user give informed consent.

Cryptographic consent was historically fairly trivial: You were either signing or encrypting some data, so you’d get data on one side and garbage on the other. Even with basic cryptocurrencies you’re just managing balances and transactions, and this ends up being pretty much “write once, deploy everywhere”.

The challenge for a web3 wallet is that the user can consent to arbitrary actions from turing-complete applications. This makes getting informed consent much harder. Ideally, every sensitive action would initiate a coherent, user-readable confirmation.

This would already make the wallet a significantly more complicated endeavor than Moxie described, but it’s not only the application content but the protocols they are built on are also evolving constantly, with new opportunities to reduce the cost to the user, improve developer experience, or improve cryptographic veracity.

These somewhat combine into a shared concept, the fact that what a wallet lets you do is open-ended. The things we know for sure are:

• It’s cryptographic in nature. The user will have keys, even if they just authenticate to a custodial provider, or are part of a larger multi-sig.
• Our primary purpose is for helping users interact with untrustworthy agents, and make informed decisions around them.

When the kinds of consent a user might give are constantly evolving, there are a few ways a wallet can compete: It can either specialize in a sub-domain of the ecosystem, and try to absolutely master it (Be the best DeFi wallet! Be the best Cosmos wallet!), it could try to be a generalist (what MetaMask does today, which can make many individual use cases feel under-served while facilitating general experimentation), or maybe there is a way to invite our vast community to help expand and define the definition of wallet, in a way that is as permissionless and free as the web itself.

That’s why MetaMask has been working on the Snaps extensibility system, which enables anyone to write scripts that can provide APIs to sites, display confirmations to the user, and perform cryptographic operations. Snaps has been in stealth development for a while (our previous docs are very outdated), but we’ve got some updates related to it coming very soon.

With Snaps, the user (or an application they interact with) is not only able to choose alternatives to Infura, but they’re also able to choose alternatives to the entire relationship of wallet-server. A snap might help a user run light clients, choose alternative runtimes like zk-STARK chains or new friendly languages, or maybe it just lets users connect to their preferred centralized service. The point is that we’re making it easier for developers to iterate and validate approaches to differently distributed applications while holding each approach accountable so that we can explore and converge on what is worth trusting faster.

The point isn’t “web3”, it isn’t “decentralization” for the word’s sake. The point is developing tools that allow us to leverage computers to collaborate more effectively. It’s about accountability and choosing for ourselves what to trust. It’s about withholding trust from strangers on the internet but holding out the belief that we can build a better way.

I agree that in the end, people want well-curated experiences. But I also think that we’ve seen enough heroes betray us that it’s comforting to maintain a right of exit, and with designs like Snaps, I think we can facilitate more experimentation while improving the accountability of the software that runs our lives. Maybe it’ll converge on a totally trustworthy centralized platform, but until then, I’m excited to be making the tools that make it easier to explore our options.

I hope that adds some depth in the wallet perspective to someone like Moxie. I think most of his criticisms are generally correct, but I also think there are some aspects of this new stack (like the wallet) that are a bit more nuanced than he represented.

One approach that has been growing in popularity lately is what we’re calling “Airdrop scams”. A typical airdrop scam involves minting a new malicious token, sending it to user accounts, and relying on users investigating what this mysterious token is to phish those users.

You can see a video exploration of one such scam here:

Users that rely solely on MetaMask for their token holdings are not prone to this attack, because MetaMask has always held a firm line on not auto-detecting unknown tokens, and we only detect tokens that meet a high bar of credibility, as we’ve long recognized this is a strategy to attack and confuse users.

The problem starts when users are looking around other sites and wallets that show any token on the blockchain by the name that the token’s author has chosen. Sometimes these other wallets or block explorers will even optimistically render a value for that token, based on an easily faked liquidity position on an Automated Market Maker (AMM) exchange. These tokens however do not behave like normal tokens, and when those users try to swap them, they throw an error (whose text is also provided by the malicious contract author), which directs the user to a phishing site for help, where they are phished.

This attack relies on several user behaviors:

• Users checking block explorers for token balances.
• Block explorers auto-detecting and displaying any token that is minted at all (even though anyone can mint a token “named” anything, and the token name imbues no security at all).
• Users expect that a detected token has value, or sites optimistically rendering AMM prices as a price oracle.
• Users investigating automatically detected tokens.
• Users then trust their investigations, and approve transactions, or even give their secret recovery phrases to the sites associated with those tokens.
• Users looking to see why the transaction failed, and believing the error message presented to be representing credible information.

Token auto-detection is a tricky situation. MetaMask has had a conservative approach to token detection, because we’d rather make a user have to add a token themselves than be exposed to a phisher’s token, but if a user relies on even a single mass-detecting token list, they are making themselves prone to this kind of attack.

MetaMask has been working on making token detection more effective and trustworthy, aggregating our auto-detection list from multiple sources, and also proactively blocking known scams, and are working towards also allowing users to more easily subscribe to (and share) their own trusted token lists.

While trusted lists may be a long-term solution, in the meanwhile we have many tools (especially block explorers, and also some wallets) that are extremely eager to detect any token that is air-dropped. This can result in phishing, annoyance, and unsolicited messages. In the short term, it would be valuable if all tool developers took this kind of attack more seriously, and consider the risks that we’re exposing users to when automatically detecting unfiltered blockchain activity.

As the decentralized web scales, auto-detection of all assets will become less and less sustainable, and so there is both a security and scalability problem with the modern expectation. The idea that a single global feed should be perfectly curated is a very Web2 way of thinking, and we think that it’s critical that we start recognizing the ways that unfiltered feeds expose us all to coordinated attacks from untrustworthy sources.

Web3 is all about building better ways of doing things. This can sometimes mean that some of the new ways feel high-friction, like managing account backups, or manually subscribing to tokens, but it’s these acts of user responsibility that enable decentralizing power away from any central party, and across the web of users.

I hope you’ll be careful out there when looking at any source of global data, and always consider “what did it take for someone to produce this?”. Oftentimes, there’s nothing stopping a scammer from putting whatever they want in front of your eyes.

Stay safe out there!

Phisher Watch: Airdrop Scams was originally published in MetaMask on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today the fundamentals of Ethereum are stronger than ever. 1.3 million transactions settle more than $12 billion daily. 74% of all stablecoins are issued on Ethereum, worth $30 billion. More than 5 million unique NFTs have been bought and sold for over $300 million. Amidst the burgeoning demand to access liquidity and activity on Ethereum, the network is straining under the weight of its own success. Moving more computation to Layer 2 networks is the best immediate solution to Ethereum’s high gas fees, and a number of such networks are already live. What’s missing is a simple user interface for switching between Mainnet and the various Layer 2 networks that an application might require.

Our new Custom Networks API is our latest step on the way to seamless cross-chain user experiences in MetaMask. It allows developers to recommend a variety of chains to their users, including Layer 2 networks like Polygon (formerly Matic), Arbitrum, and Optimism; sidechains like SKALE and xDAI; and indeed any EVM-compatible chain, including enterprise networks and testnets. These networks are then added to the user’s network menu with a simple confirmation, and the user is able to switch between networks using the familiar network switching menu.

We are excited to support the growth of Layer 2 networks, and look forward to seeing what the Ethereum community will build with cheaper and faster transactions. Even so, keep in mind that not all networks are created equally, and they make different trade-offs in order to scale. Be sure to understand the security and reliability tradeoffs of any network you add to MetaMask, and ensure that you trust the site recommending a new network. We encourage all users to read our guide to using custom networks in MetaMask.

Check out our docs to start recommending L2 networks to your users. If you’re a wallet developer interested in implementing this method, you will also want to check out the EIP-3085.

Connect Users to Layer 2 networks with the MetaMask Custom Networks API was originally published in MetaMask on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today we created a public Dune Analytics dashboard so that you can view real-time data on token swaps happening through MetaMask’s new swap feature. We include cumulative volume (USD), the cumulative number of swaps, the number of unique accounts (users), daily volume (USD), daily swaps, average swap size, and the volume distribution across liquidity sources. The MetaMask Swaps feature aims to leverage Web3 innovations by allowing users to directly compare offerings from a multitude of decentralized protocols, giving them better insight, while transacting in a non-custodial manner through those protocols. To this end — you can think of Swaps as similar to Expedia for travel quotes — except entirely non-custodial and the user transacts directly with these decentralized protocols.

The MetaSwap software currently aggregates information from Uniswap, AirSwap, 0x API, 1inch.exchange, Paraswap, Totle, and private market makers. The outcome is that users now have more information available to them in one place, allowing them to have access to a united decentralized exchange system at the most competitive prices, all with fewer token approvals and a seamless user experience.

As you can see from the Volume Distribution chart in our dashboard, users are finding that each trading experience is unique. The pricing offered through decentralized protocols depends on factors such as the size of a swap and the tokens the user is attempting to swap. Certain decentralized exchange protocols appear to perform better for certain types of trades — and this is why we were thrilled to build the Swaps software. For instance, AMMs appear to provide users the best quotes in smaller trades, whereas RFQ based protocols appear to perform better for larger trades. MetaMask has always been about providing users access and autonomy in Web3 — and with the addition of Swaps, we’re providing a user interface for previously unconnected decentralized protocols.

To date MetaMask has provided an essential and free community service — one that remains largely open source. With the addition of the Swap services, we introduced a fee to those availing themselves of the Swaps feature. We are enthusiastically reinvesting in development to make MetaMask even better.

Check out our new dashboard here and let us know what you’d like to see added. Or fork it and build your own! That’s the power of open source software.

We think you’ll like what’s coming next with MetaMask. In the meantime, we are hiring a Javascript Engineer, a Designer, and a QA Engineer.

Real Time Data on MetaMask Swaps was originally published in MetaMask on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you have a phone, television, car, or a washing machine, it’s likely that you use free or open source software dozens of times before lunch. Thanks to the thousands of individuals that contribute to Linux, Firefox, Git, Node.js, v8, and many more projects, open source software development has fast become a critical feature of the Internet. Ethereum is no different. Open source development enables public participation and keeps Ethereum resilient. Despite open source software solving critical shared problems, fair compensation for the maintenance of these community goods remains a problem, with many different sustainability attempts — from donations, to grants, to copyleft licenses.

Since the first release of MetaMask, we’ve provided a browser extension to connect more than 4 million individuals to Ethereum with a permissive MIT license. However, in order to compete with products that exist upstream of our wallet in the web3 tech stack, such as web browsers, and to continue providing the most resilient and secure browser and wallet experience on Ethereum for the next wave of users, we need to evolve our approach and set parameters around how developers can distribute versions of MetaMask and be fairly compensated.

Going forward, MetaMask will be published under a new license. For all end users and most application developers and non-profits, this will not have any impact: MetaMask will continue to be free. Developers will have the same access to the MetaMask APIs that they’ve had in the past, enabling the same kinds of applications as before. MetaMask will continue publishing and iterating upon the wallet provider API in the public sphere, to ensure a widely cross-compatible ecosystem of applications. MetaMask remains committed to publishing all code in a public repository, so you are welcome to review and audit the codebase, or compete in our bug bounties (and more bounties coming soon on HackerOne).

Developers can still copy, modify, and distribute versions of MetaMask. Yet for developers that copy, modify, or fork the MetaMask codebase for commercial use, we invite you to start a conversation with us to see how we can find a path forward together. For example, if you’ve copied MetaMask and offer it commercially to an audience larger than 10,000 monthly active users, we would like to enter into a formal commercial agreement.

MetaMask has provided an essential and free community service to this point, and to continue to do so, we need a sustainable future for what we see as a public good: a safe wallet.

To contribute to more adoptable standards and secure practices, the MetaMask team will continue to publish many of its internal modules as permissive open-source licensed modules. These include code related to key management, the provider API, our permissions system, and much more. We hope that through cross-project reuse, we can help build stronger foundations for our collective projects.

FAQ

Why do you need to migrate from an MIT open source license to a tiered proprietary license?

Currently, the status quo for compensating open source maintenance is not tenable. Here is a good article about travails of funding open source software. The bottom line is that a developer shouldn’t have to decide between making proprietary software or continuing open source licenses. We also need to be on a fair playing field with other products in the ecosystem that exist upstream of MetaMask in the web3 tech stack. We decided to keep to the principles of open source development with auditable code, but reserve the right to come to enterprise agreements with distributors whose version of MetaMask serves more than 10,000 users. This protects MetaMask from free-riders or upstream competitors from exerting monopolistic control.

If I’m not a developer, will this change my experience of MetaMask?

No. This will not affect end-users of MetaMask.

If I’m a developer and copied a version of MetaMask, will this affect me?

Not necessarily. We encourage developers to inspect our code, submit requests, and copy it for the purpose of integrating a secure wallet experience for your application. Many projects, from Bitcoin’s Lightning Network to POA Network, have forked versions of MetaMask. However, if your wallet starts commercially serving more than 10,000 monthly active users, we now reserve the right to establish a proprietary license agreement.

What is a tiered proprietary license?

MetaMask’s entire codebase is now owned by ConsenSys. We publish code in a public repository for view/inspection. We permit distributing, copying, modifying and creating derivative works non-commercially, or commercially so long as the number of monthly active users of the Resulting Program across all versions thereof and platforms globally do not exceed 10,000 at any time. Any derivative works must also follow this same license restriction.

This post was written in partnership with James Beck of ConsenSys.

Evolving our License for the Next Wave of MetaMask Users was originally published in MetaMask on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today, we’re rolling out MetaMask Version 8. This represents a major upgrade to MetaMask and offers a number of new features that no wallet has delivered before.

Unparalleled Privacy Control

Most wallets today either manage a single account, or expose the currently selected user current account to all connected sites — broadly revealing users’ private information.

In MetaMask V8, when you connect to a website, you have the option to select one or more accounts to associate with that website or create a new account just for that site. You decide what each site has access to.

This new feature enables you to easily switch between accounts, so you can control which accounts interact with different sites across the decentralized web.

If you open a site that is not connected to the selected account, MetaMask will alert you and allow you to connect.

A new connection indicator (seen here with “Not connected” shows your connection status and opens a menu with your account connections and site permissions.

These site permissions reflect our EIP-2255 permissions system, which will become more rich over time. These new and enhanced permissions will enable powerful features like decryption, access to wallet information (like your favorite tokens or contacts), and paves the way for MetaMask Snaps extensibility.

A Slick, New UI

Perhaps the most obvious change to version 8 is a refreshed MetaMask UI. Our team has focused on delivering these new features with a cohesive experience. When opening MetaMask version 8 for the first time, you’ll be introduced to our new features through helpful UI hints.

The home screen, asset page, and transaction history have been redesigned with your assets now easier to access. Instead of tapping a hamburger icon to view your assets, you now access them via the ‘Assets’ tab on the home screen.

The ‘Assets’ tab contains a list of the assets you currently hold and are tracking in MetaMask. Click each asset to view a details page with the transaction history of that asset.

The new ‘Activity’ tab is a redesigned transaction history view. With new iconography, each type of transaction is more easily recognizable.

More Features For Developers!

Introducing Web3 Encryption

Thanks to a huge community contribution, MetaMask now ships with two new methods that allow websites to encrypt and decrypt messages intended for Web3 users.

For now, these decryption requests each require user confirmation, so it’s mostly ideal for decrypting infrequent, important messages, like emails. Later on we have an opportunity to make this same decryption strategy available with the permissions system described above.

You can read more about the new decryption API here.

Removing Friction From Your App Onboarding

In the past, we’ve received feedback from developers that on-boarding users is a source friction in their funnel.

We want to make it as easy as possible for your users to interact with your application through their MetaMask account and make sure users who land on your site stay on your site.

To help, we’ve created a new onboarding library which enables applications to implement their own connect button. It allows a user to seamlessly land on your site, install MetaMask, and be automatically redirected back to your application so they can continue their journey. Learn more about using our new on-boarding library here.

Developers: Introducing the ERC-1193 Provider API

The Ethereum provider just got a non-breaking upgrade! This EIP formalizes a JavaScript Ethereum Provider API for consistency across clients and applications.

The Provider’s interface is designed to be minimal, preferring that features are introduced in the API layer (see e.g. eth_requestAccounts) and agnostic of transport and RPC protocols.

Instead of using the old ethereum.sendAsync(options, callback) pattern everywhere, you now get a nice and simple const result = await ethereum.request({ method, params }).

It’s designed to be ergonomic and extensible API, friendlier to use than sending a full RPC object for each request, and perhaps best of all, it supports returning Promises and registering subscriptions.

Read more about it here.

Upcoming changes for web3 site developers

If you’re a developer that relies on the window.web3 object injected by MetaMask, you’ll need to implement changes before we remove the injected web3 object or your site will break. We recommend migrating to using window.ethereum or ethers.js, ASAP. We will announce a deprecation date as soon as we’re willing to commit to a firm date.

If you’re a developer that only relies on your own version of ethers or web3, you won’t need to take any action — just keep it up to date. If you are choosing a new convenience library, we recommend ethers.

Read our documentation to learn more. Our docs site has recently been revamped, thanks in part to amazing contributions from the MetaMask community (shout out to Austin Akers!).

Cutting Edge Security

LavaMoat is Live and in Production!

Nothing is more important than your security at MetaMask. Our new LavaMoat tool helps raise the bar of security for nearly any JavaScript project.

MetaMask is a web and JavaScript-based wallet. JavaScript often gets a bad reputation because untrusted code is often pulled into production environments. For a wallet, this is more dangerous than ever.

LavaMoat is a set of tools we’re building that uses Secure EcmaScript to confine every third-party dependency in a piece of JavaScript code at build time. We hope to eventually confine every dependency in our entire wallet, greatly protecting us and our users from the category of “supply chain attacks”.

We’re happy to announce that we now have the first LavaMoat protected process live and in production! We now have our ropsten test-network faucet secured with this new build security system!

You can:

• Read the faucet code here
• Watch a video to learn more about the goals of LavaMoat
• Get started with LavaMoat for webpack
• Get started with LavaMoat for browserify

That’s Version 8!

We hope you enjoy this new release of MetaMask. Learn more about MetaMask or download it at metamask.io. If you’ve spotted a bug or have other feedback, please drop an email to our support team.

Announcing MetaMask Version 8 was originally published in MetaMask on Medium, where people are continuing the conversation by highlighting and responding to this story.

We began this contest with the goal of engaging community participation around the formation of a standard that could benefit a wide variety of wallets with the smallest effort on the part of developers and end users, and we couldn’t be happier with the results.

We knew this was not an easy task, which is why we posted what was the largest prize for the hackathon. After posting our 20 eth bounty, GitCoin raised the prize by 1000 DAI, bringing the total prize pool to around ~$4500 equivalent at today’s rates. We were hoping to get even a few people to take a shot, but what we got was so much more.

• 28 participants registered and began work.
• 12 participants submitted work.
• 7 participants submitted work correctly by the deadline.
• 4 participants satisfied every one of our suggested ideal criteria of a general purpose framework that allows any smart contract to support MetaTransactions for any user (even normal key-based accounts), along with interactive demos that work today. 🤯
• Bloxis wrote a wonderful blog post advocating for the value of this goal.
• We got a big thread on ethereum-magicians discussing the initiative.

Maybe most importantly, we saw a lot of incredibly talented Ethereum developers come together to share ideas and refine their approaches on our metamask.developers keybase channel.

On to the Entries!

Before we discuss the finalists, I’d like to take a moment to mention a couple outstanding features from some of our runners-up.

Adamzolla’s Lava Protocol created a global smart contract that would allow adding MetaTransactions to any ERC-20 token today. However, since it relies on setting the allowance for those tokens first, we felt it was not as truly gas-free as we wanted from a winner, but it still stands out as a totally unique contribution that could absolutely have use on the main-net today. It even includes a working demo!

Chris Buckland and Patrick McCorry submitted some excellent research towards a MetaTransaction standard, and included three replay protection strategy proposals, which include features totally unique to all the entries, like supporting various degrees of concurrency. The judges had to rule this one out from the finalists because it wasn’t quite oriented at developers being able to use it immediately, nor did it have a demo, but this one makes important contributions to our understanding of what we can achieve with replay protection, so we had to give it a big nod.

The Finalists

We were incredibly lucky to have three MetaTransaction-celebrity judges volunteer to help evaluate our submissions:

• Mariano Conti of Maker, which recently shipped a MetaTransaction permit() method on its new DAI contract.
• Mark Beylin, Founder of Bounties.network and the StandardBounties framework, which included a MetaTransaction method on its latest contract.
• Austin Griffith, who popularized MetaTransactions with many developers.

Upon reviewing the entries, we quickly realized we had enough high-quality entries that we were forced to hold a very high standard for the winner.

As MetaMask’s first hackathon prize ever (we’ve done mostly word of mouth!) we hadn’t considered that we’d get tons of great submissions, and so we hadn’t announced any runner-up prizes, so we were preparing to make a very hard decision.

At the time of judging, we had three finalists who had satisfied what we were calling “the high water mark”:

• A new standard that only requires inheriting a solidity class and replacing all calls to msg.sender to an internal method that is aware of the new MetaTransaction method, like _messageSender().
• Adds a new method that allows anyone to submit transactions on behalf of other users to this contract.
• Has support for batches of transactions.
• Allows the original transaction signer to include a fee to the submitter.
• Features a clean working demo that you can try right now.

Those finalists were:

• GMTX by Hadrien Croubois
• EIP-1776 by wighawag
• MetaMask-friendly GSN by OpenEth
• Biconomy’s Metatx-Standard

Each of these entries stood out in big ways:

• Working demos
• EIP-712 compatible signatures, making for more readable signatures (with a possibility of being standardized and rendered better later)
• A generic solidity class that can be inherited from on any solidity contract to add support for MetaTransactions for all of its methods.

The judges were so impressed, that we decided we wanted to take more time to more deeply understand the entries, and so each judge took a different finalist entry to review in more detail, perhaps try building with, and report back to the group, so that we could have a more informed perspective on the submissions.

Let’s review some of the key features that distinguished our finalists:

Community Engagement

We never said this would be a judging criteria, so we didn’t weigh it too heavily, but we did say that likelihood of getting widespread adoption was a goal, and we believe that in a decentralized ecosystem, community engagement is an important strategy! So we gave extra credit to contestants who started conversations, sought out the best ideas, and shared their own ideas freely during the contest. Amxx was particularly active during our contest, but wighawag and Yoav had each built on EIPs, highlighting a long-running commitment to community standards.

Developer Documentation

Widespread adoption isn’t just about having a great proposal, it’s about communicating it in a way that gets developers to quickly understand what it is, how to use it, and building it into their own contracts. Amxx and wighawag both stood out as having very developer-friendly introductions, as if they were writing to future devs, and not just hackathon judges.

Simplicity

This contest was already asking for a lot of complexity, and asking devs to add some new code to their contracts is a scary thing to ask already, so making the smallest and most easily audited contribution possible has serious impact on how likely people are to adopt it. yavw took a slight hit here, because by using GSN, they took the complicated issue of fee repayment, and added a whole additional crypto-economic game on top of it. We found evaluating the game theory of the GSN to be slightly out of scope for this contest, and so we preferred proposals that had the option of integrating with GSN, like Amxx’s.

Fee Repayment

We did not require submissions to include a method to repay the transaction relayer, since we believed there was already a lot of value to be had by accounts that were willing to relay each others’ transactions. That said, the submissions by amxx, wighawag, and yavw all had methods to optionally repay the relayer in an arbitrary token. That opens those submissions to a whole category of extra usage.

Replay protection

In our intro post we mentioned that replay protection was a looser suggestion, but when all the other criteria were met so well by all the front-runners, it became a valuable way to stand out. As it was, of the four finalists, three used a classic Ethereum-style nonce for replay protection, and one (wighawag) implemented a two-dimensional nonce, which allows transaction parallelization and batching.

Amxx also took a small hit in this category, because his replay protection scheme involved writing each transaction hash to blockchain state, which increases the gas price of these transactions. Reducing state bloat over time is a valuable property that we’d like to see more contracts value.

Batch Processing

We did not list this as a requirement, but there are big blockchain throughput gains to be had by batching transactions together. Both amxx and wighawag had batching mechanisms in their submissions, but wighawag’s included the ability for the batch to share a signature, slightly improving performance, which is always valuable on a blockchain.

Finally, the Winner

For drafting a simple yet flexible EIP, making a working demo and code that any developer could try out today, all with replay protection that stood out from all other working submissions, we have decided to award our one prize to wighawag.

Some other stand-out details from wighawag’s entry included heavy reuse of existing EIPs, thoughtful consideration of handling gas limits and failed transactions, using the solc 0.6.1 compiler (very forward-looking), and a UI that is both simple but also allows exploring the more advanced parameters of the protocol. Also by using a global singleton proxy contract, contracts using this standard re-use deployed code (making them cheaper), and transactions are able to be refunded in other tokens than the contract being called.

Next we’re hoping to help see wighawag’s EIP-1776 proposal get more experimentation, some security auditing and bug bounties, and then some broader proliferation, with hope of eventually rendering messages like this like normal transactions in web3 wallets like MetaMask.

At MetaMask, we loved the top entries so much that we decided the other three finalists deserved prizes too, so they will be receiving bonus prizes of 500 DAI each, and in future hackathons we’ll be sure to include dedicated runner-up prizes.

This hackathon absolutely exceeded our expectations, and has really forced us to rethink what contests can achieve in this space.

We’d like to thank GitCoin, our judges, and all the contestants for moving the needle and making Ethereum get just a little more usable.

What do you think we should do for our next hackathon contest? What do you think would take these entries to the next level? Leave a reply below and let us know!

Our MetaTransaction Hackathon Winner! was originally published in MetaMask on Medium, where people are continuing the conversation by highlighting and responding to this story.

At MetaMask, we strive to enable the best possible user experience for building and interacting with decentralized applications. This means reducing user friction wherever we can, and we believe we have a way that requires a new Ethereum interface-layer EIP, which we would like to invite the wider developer community to help define, with our new GitCoin Take Back The Web Hackathon bounty: The Generalized MetaTransaction Contest.

Today, our users have to hold ether in every account to pay transaction fees for even the smallest interaction, to prevent them from spamming the network. This is a lot of overhead, especially when in many cases, a third party may be willing to pay a user’s transaction fees. This pattern of third-party transaction fee payment is known as Meta-Transactions, as popularized by Austin Thomas Griffith.

There are two major ways that MetaTransactions can become available to users, and we are working towards both, but this bounty will focus on the latter.

The Contract Account Approach

We look forward to allowing every user to have a contract-based account, and these accounts could support MetaTransactions natively. We are currently facilitating this goal with our Snaps plugin system, which will eventually support any number of different account types, such as the Gnosis Safe wallet, which already supports this type of MetaTransaction today.

The Contract Based Approach

The second major approach to allowing MetaTransactions is for contracts to expose a MetaTransaction processing method on themselves. We have seen some projects recently begin driving this forward, with Bounties Network (code) and Dai Stablecoin‘s permit method each exposing methods to facilitate third-party gas payment.

These approaches stand out because they do not require widespread adoption of a single type of account: Your dapp doesn’t need to handle each kind of contract account a user has, and it works out of the box today, and will continue to work for any key-authenticated method in the future.

Even once we support contract accounts, we expect there will still be some normal, external-key-based accounts, either to reduce the cost of publishing a contract for the account, or because a key may be used to manage a very small quantity of funds or permissions.

For these reasons, we’d like to see methods like Bounties and Maker have pioneered not only succeed, but to stand as the basis for new standards going forward.

Towards a Generalized Standard

One thing you’ll notice if you refer to either of the Bounties or Maker examples above, is that these MetaTransaction methods are all written bespoke to specific methods: Each method has its own MetaTransaction method handler. This is a lot of developer overhead!

At MetaMask, we were looking at these different methods, and considering which ones we could support and render more beautifully, and it occurred to us that it would be much nicer if we simply had a standard way of defining any method as MetaTransaction enabled, so that any contract could include a single function, and their users could now interact without gas payment (provided someone is willing to pay the tx fee).

Furthermore, wallets would be able to render these gas-free transactions the same way they render their normal Ethereum transactions today, and would benefit from all the many improvements they add in the future.

Rather than waiting for someone to define this standard specification, we’d like to encourage broader creativity on this issue, and so we’re opening a bounty on the Gitcoin Take Back the Web Virtual Hackathon. If you’d like to see this happen, we encourage you to contribute to the prize, or to strive to earn it!

The Gas Station Network has made efforts at a generalized standard, but it is currently oriented at totally ephemeral accounts, and not the portable, user-held keys that MetaMask makes possible, and so it’s possible their standard could be used or extended for this purpose.

Strong Suggestions

We’d like to see a standard that leverages the signTypedData_v4 method, which is what the Maker permit() method does. You can see some sample JS usage of the permit signature here.

This method should be able to call any method on the contract, probably using that method’s 4-byte method identifier, which would allow wallets like MetaMask to render nice confirmations for users using this method.

Looser Suggestions

This method may allow some mechanism for repaying the submitter/relayer (to allow paying them back in an asset other than Ether, for example). This may be more than we should strive for in a first spec, but it would definitely make a proposal stand out!

This method may make use of a nonce, but for some use cases, allowing these messages to be submitted in any order may be an advantage, and so another replay-protection measure may be preferable!

If you want to get deeper into the mad science, there is a thread of speculation where a standard like this could evolve here.

Conclusion

All bounty submissions must be received no later than 11:59 PM EDT on Jan 23 2020 to be considered.

The winner will be announced no more than 24 hours after the contest ending time, no later than 11:59 PM EDT on Jan 24 2020.

The entries will be judged by a number of pioneering developers of MetaTransactions across the Ethereum ecosystem.

We’ll be available for support during the hackathon on our Keybase team metamask.developers.

We hope this has gotten you EVM developers’ imaginations flowing. With a generalized contract MetaTransaction format, we believe we can elevate the entire ecosystem dramatically, together.

Add to the bounty, or sign up to earn it on GitCoin.

Announcing a Generalized MetaTransaction Contest was originally published in MetaMask on Medium, where people are continuing the conversation by highlighting and responding to this story.