[WIP edit] Weth edit

[corwintines]

Description

Related Issue

[gatsby-cloud[bot]]

:white_check_mark: ethereum-org-website-dev deploy preview ready

• Deploy preview
• Build logs · 30m build time

[konopkja]

added some notes as i was reading the article, overall much better than original @corwintines. These are just some thoughts I had when reading through it. Dont see all of them as must haves

1. Do we know who or when created WETH?
2. How do we know WETH is safe? Original article mentioned how much it is used to give it some sense of trustworthiness - i think this still should be somehow added here.
3. the article talks about other ERC-20 tokens but doesnt give example, i think it would be usefull to say that most tokens today are ERC-20 compatible.. such as polygon, USDC, BNB ... etc.
4. maybe we should not use "dapps" and use just ethereum applications instead 5.the table is high level, instead of specific (ownership section could state specific rules)
5. transfer section in table doesnt clarify or speciffy why user should care
6. zero admin control could be shorter and simpler
7. hyphothetical security risks should be removed - i dont see value in these given the fact that anything in the world has hyphothetical risks and we dont talk about them normally

[emmanuel-awosika]

Hey guys. Stumbled on this draft while searching for the original WETH page in the repository. If @corwintines could give write access to the page, I can pick up from where he left off and work to rework the content based on @konopkja's feedback. In the meantime, I'll leave comments/feedback on @konopkja's questions/comments:

1. Do we know who or when created WETH?

The original draft provided some historical context on WETH’s creation (but I think it was considered too much detail and we removed it): “WETH was created to make Ether compatible with applications implementing ERC-20 token interfaces.” I should note that the link points to the article announcing the launch of the original WETH contract created by Ox, but the currently used version lists Dapphub as the contract creator. We might want to clarify this distinction.

In any case, I'm open to any suggestions you have on the best way to present the information to readers.

2. How do we know WETH is safe? Original article mentioned how much it is used to give it some sense of trustworthiness - I think this still should be somehow added here.

The new page by @corwintines mentions the key details around WETH’s safety from the original (simple design, non-upgradeability, audits/formal verification, etc); however, it’s not immediately apparent because of the way the information is presented here. To illustrate, here’s the original version of the Security considerations for using WETH section:

As Ethereum's native asset, the security of ETH is guaranteed by the protocol—no one can steal your funds unless they have access to your private keys; even in a 51% attack, attackers cannot create forged transactions to transfer ETH from your address without approval. In comparison, Wrapped Ether (WETH) is not issued and secured by the Ethereum network and using it may involve certain risks. Still, WETH is considered a safe asset to own and use (compared to similar wrapped tokens) due to its unique qualities:

• Simplistic design: The canonical WETH smart contract has less than 60 lines of code and lacks complexities that can produce unintended bugs or exploitable vulnerabilities.
• Zero admin controls: Your interaction with WETH is fully trustless as no one has administrative control of the WETH token contract. As such, you don't have to worry about a malicious admin arbitrarily minting or burning tokens, censoring attempts to withdraw your ETH, or blacklisting transfers.
• Non-upgradeable: The WETH contract is non-upgradeable (unlike many variants) and has remained the same since its launch many years ago.
• Extensively audited and tested: Members of the Ethereum community (including auditors, developers, and security researchers) have tested the security of the WETH contract before and after its launch. The WETH contract has also passed formal verification, which is considered the highest security standard for Ethereum-based applications.

And here’s the new version of the text (the introductory "Still, WETH is considered a safe asset to own and use (compared to similar wrapped tokens)..." part is removed, so it's not immediately obvious we're talking about WETH's security properties):

As Ethereum's native asset, the security of ETH is guaranteed by the protocol—no one can steal your funds unless they have access to your private keys. Even in a 51% attack, attackers cannot create forged transactions to transfer ETH from your address without approval. In comparison, wrapped ether (WETH) is not issued and secured natively by the Ethereum network and using it may involve certain risks. Some unique qualities that WETH has are:

• Simplistic design: The canonical WETH smart contract has less than 60 lines of code and lacks complexities that can produce unintended bugs or exploitable vulnerabilities.
• No centralized control: WETH cannot be changed as no one has administrative control over the WETH token smart contract. As such, you don't have to worry about a malicious admin arbitrarily taking advantage of WETH tokens, censoring or attempts to withdraw your ETH.
• Non-upgradeable: The WETH contract is non-upgradeable (unlike many variants) and has remained the same since its launch many years ago.
• Extensively audited and tested: Members of the Ethereum community (including auditors, developers, and security researchers) have tested the security of the WETH contract before and after its launch. The WETH contract has also passed formal verification, which is used as a high security standard for Ethereum-based applications.

Also, the original draft also had an FAQ on WETH’s security (which is missing from the edited draft):

Question: "Is WETH safe?" Answer: "ETH is the safest asset because it is part of the Ethereum protocol, whereas WETH is defined in a smart contract which could feasibly be hacked. Nevertheless, WETH is generally considered secure because it is based on a simple, battle-tested smart contract. The WETH contract has also beeen formally verified, which is the highest security standard for smart contracts on Ethereum."

3. maybe we should not use "dapps" and use just ethereum applications instead

Sure. That could work.

4. transfer section in table doesnt clarify or speciffy why user should care

I had to dig up the original (unedited) draft to recall why I included this detail in the first place. Here’s the relevant text (before I converted the "ETH vs WETH" section to a table):

“Unlike ETH, the ownership and transfer of WETH tokens is handled by the WETH token contract. Balances of WETH token owners are stored inside the contract as key-value pairs where a key (an address) maps to a value (the total tokens owned by an account). As such, a wallet application cannot automatically track changes in your WETH balance unless you explicitly ask the wallet application to "watch" the WETH token contract (i.e., read the contract's state).”

The idea here was to explain a key UX issue for users of wrapped tokens (ie. difficulty of tracking balances). Here’s a long(ish) quote from the Mastering Ethereum book for some background:

One of the less obvious issues with ERC20 tokens is that they expose subtle differences between tokens and ether itself. Where ether is transferred by a transaction that has a recipient address as its destination, token transfers occur within the specific token contract state and have the token contract as their destination, not the recipient’s address. The token contract tracks balances and issues events. In a token transfer, no transaction is actually sent to the recipient of the token. Instead, the recipient’s address is added to a map within the token contract itself. A transaction sending ether to an address changes the state of an address. A transaction transferring a token to an address only changes the state of the token contract, not the state of the recipient address. Even a wallet that has support for ERC20 tokens does not become aware of a token balance unless the user explicitly adds a specific token contract to "watch." Some wallets watch the most popular token contracts to detect balances held by addresses they control, but that’s limited to a small fraction of existing ERC20 contracts.

In fact, it’s unlikely that a user would want to track all balances in all possible ERC20 token contracts. Many ERC20 tokens are more like email spam than usable tokens. They automatically create balances for accounts that have ether activity, in order to attract users. If you have an Ethereum address with a long history of activity, especially if it was created in the presale, you will find it full of "junk" tokens that appeared out of nowhere. Of course, the address isn’t really full of tokens; it’s the token contracts that have your address in them. You only see these balances if these token contracts are being watched by the block explorer or wallet you use to view your address.

If this is considered unnecessary (eg. because wallets already track the state of popular contracts like WETH by default), we could remove it. Or, if you have any ideas on how we can improve the content, I could work with that.

5. hyphothetical security risks should be removed - i dont see value in these given the fact that anything in the world has hyphothetical risks and we dont talk about them normally

Hmm. If we don’t want to go into too much detail about hypothetical security incidents, could we at least include a disclaimer (of sorts) so that anyone reading understands the risks associated with wrapped tokens like WETH? The edge-case I’m trying to avoid is where it feels like we’re simply asking users to use WETH without giving them basic DYOR advice.

For example, here’s the draft of a short explanation on security information for new crypto users--let me know what you think:

While WETH is considered safe, no smart contract can be truly considered 100% secure. A bug in the WETH contract may affect the safety of WETH assets—for example, if it allows someone to withdraw ETH without burning WETH (or mint WETH without depositing ETH) or prevents users from unwrapping WETH and withdrawing ETH deposits.

Moreover, less technically savvy users may be discouraged by the complexity and potential cost of wrapping and unwrapping WETH tokens. However, relying on blockchain bridges and third-party protocols to wrap tokens presents additional security risks; for example, you must trust the bridge's security and trust the bridge operator(s) won’t freeze or steal your funds.

[emmanuel-awosika]

Also, I see the FAQs aren't included in the edited version, @corwintines. It'd be nice to get some context around that; in the meantime, I'll include some of the reasons the original page had the FAQ section:

• IIRC the original intention was to try and drive SEO performance by ranking for certain terms/keywords by creating resources like the WETH page. Which is why most (or all) of the FAQs were based on popular search queries related to WETH (eg. questions in the "People also ask" bar field on Google). That way, if users entered specific search terms, the page would come up in the search results.

• Another reason I included the FAQs was to to try and make the content more friendly for skimmers/scanners. I think @konopkja mentioned something around some website visitors finding it hard to go through some pages before finding the content they were interested in--the FAQs were supposed to correct this problem (to an extent) by surfacing the most important details about WETH.

  • If the issue is around the number of FAQs, we could decide on which FAQs are absolutely necessary and which ones can go. At the least, it might be worth trying out the FAQ-style content for this page and doing some sort of on-page A/B testing to see if this improves the reader experience (@konopkja could have some input on how we can do this); if it does, we could then see if some of the other Learn pages could benefit from a similar structure (since they're often targeted at beginner-level readers).

[wackerow]

@corwintines, just checking the pulse here... we still have plans to complete this?

[emmanuel-awosika]

@corwintines, just checking the pulse here... we still have plans to complete this?

Hi @wackerow. Thanks for bumping this up. I had it in mind to reach out to @corwintines for word on this PR. I think it's small enough + most of the work is done already, and we should be able to push it across the finish line without further delays.

I'm also looking to bundle work on this PR with the outstanding PR on the public goods funding page: #7732 (that's been open since 2022 IIRC). I'll reach out on Discord to see how we can get things moving on both fronts. Ideally, I'd want to take out the time to wrap both pages up sometime between late January and early February.

[CASABECI]

Description

Related Issue

[coderabbitai[bot]]

[!IMPORTANT]

Auto Review Skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository.

To trigger a single review, invoke the @coderabbitai review command.

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

---

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit-tests for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit tests for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit tests.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• The JSON schema for the configuration file is available here.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

[netlify[bot]]

❌ Deploy Preview for ethereumorg failed.

Name	Link
🔨 Latest commit	01df5db67c672aa76f75b9b0563605369cd6bab7
🔍 Latest deploy log	https://app.netlify.com/sites/ethereumorg/deploys/65ef2510c7b6270008236154