Skip to content

The most optimized ERC20 & Wrapped Ether implementation.

License

Notifications You must be signed in to change notification settings

Philogy/meth-weth

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

METH

A Wrapped Ether implementation so efficient it'll make your teeth fall out 🦷

"METH" is an overall better version of the commonly used WETH9 contract, providing a trustless, immutable and standardized way for smart contracts to abstract away the difference between the native ETH asset and fungible ERC20 tokens.

🪨 Deployed Instances

(pending final implementation and audits)

🏆 Gas Use: METH vs WETH9

STILL A WORK IN PROGRESS, MORE COMPARISONS PENDING

Comparison may improve in favor of METH if more optimizations are found.

Direct Calls

This table contains a comparison of gas costs for limited function calls.

Action WETH9 METH Difference Added Details
deposit() 45,038 44,501 -537 Wrap non-zero amount with no existing balance
transfer(...) 51,534 50,560 -974 Transfer to account with zero balance
receive-fallback 27,631 27,333 -298 Wrap non-zero amount with existing balance
approve(...) 46,364 45,465 -899 Grant infinite allowance (requires truncating calldata for METH)
withdraw(...) 35,144 34,395 -749 Unwrap specific amount
transferFrom(...) 36,965 36,033 -932 Transfer from non-zero to non-zero with infinite approval
transferFrom(...) 35,688 34,158 -1,530 Transfer from non-zero to non-zero with finite approval
withdraw all remaining balance 30,344 29,430 -914 Unwrap all remaining (withdraw(uint) in WETH, withdrawAll() in METH)

✅ Why METH over WETH9?

🔒 Fewer Footguns

WETH9 does not have a permit method but implements a silent fallback method meaning it'll silently accept a call to all methods, even ones it hasn't implemented. This often leads to unforseen vulnerabilities when developers expect their contracts to interact with ERC20 tokens that implement certain methods or at the very least to revert if they do not implement the methods. This was e.g. the cause of Multicoin's $ 1M bridge hack.

METH does not have a silent fallback method and will revert if it's called for a method it hasn't implemented. METH does however implement a payable receive fallback method. Allowing you to wrap ETH if you explicitly send ETH to the contract along with no calldata.

🧩 Backwards Compatible

The previously existing withdraw, deposit and receive fallback method behave like WETH9's methods meaning it's a drop-in replacement.

The only difference that may have to be considered: Calling methods that are not implemented will not silently pass, if you need to wrap ETH to WETH either send it directly with no calldata or use one of the deposit methods. Calling an unimplemented function may consume all gas sent to the contract.

Following (unimplemented) selectors will lead to an exceptional revert, consuming all gas when called:

0x0a000000 - 0x0affffff
0x21000000 - 0x21ffffff
0x24000000 - 0x24ffffff
0x29000000 - 0x29ffffff
0x2f000000 - 0x2fffffff
0x4b000000 - 0x4bffffff
0x86000000 - 0x86ffffff
0xaa000000 - 0xaaffffff
0xae000000 - 0xaeffffff
0xcb000000 - 0xcbffffff

👤 Improved UX

💻 Improved Contract-level Interaction

Common patterns are made more efficient by packing them into single calls. Beyond saving on call overhead the methods are also more efficient because they don't need to update intermediary storage variables. Certain methods also allow contracts to avoid otherwise unused receive / payable fallback methods.

  • METH.depositTo{ value: amount }(recipient); replaces:
    WETH9.deposit{ value: amount}();
    WETH9.transfer(recipient, amount);
  • METH.depositAndApprove{ value: amount }(spender, amount); replaces:
    WETH9.deposit{ value: amount}();
    WETH9.approve(spender, amount);
  • METH.withdrawTo(recipient, amount); replaces:
    receive() external payable {
        require(msg.sender == address(WETH));
    }
    // ...
    WETH9.withdraw(amount);
    SafeTransferLib.safeTransferETH(recipient, amount);
  • METH.withdrawFrom(account, amount); replaces:
    WETH9.transferFrom(account, address(this), amount);
    WETH9.withdraw(amount);
  • METH.withdrawFromTo(from, recipient, amount); replaces:
    receive() external payable {
        require(msg.sender == address(WETH));
    }
    // ...
    WETH9.transferFrom(from, address(this), amount);
    WETH9.withdraw(amount);
    SafeTransferLib.safeTransferETH(recipient, amount);
  • METH.withdrawAll(); replaces:
    WETH9.withdraw(WETH9.balanceOf(address(this)));
  • METH.withdrawAllTo(recipient); replaces:
    receive() external payable {
        require(msg.sender == address(WETH));
    }
    // ...
    uint amount = WETH9.balanceOf(address(this));
    WETH9.withdraw(amount);
    SafeTransferLib.safeTransferETH(recipient, amount);

⚡ Highly Optimized

METH is written directly in bytecode-level assembly using the Huff language, ensuring its implementation is as efficient as possible.

⚙️ "METH" under the hood

Storage Layout

To save gas a non-standard storage layout is used:

Slot Name Slot Determination Values Stored (Bits)
Main Data of account slot = account_address (255-128: nonce, 127-0: balance)
Allowance from spender for owner slot = keccak256(abi.encode(owner, spender)) (255-0: allowance)

The layout ensures minimal overhead when storing balances. The layout however also makes it possible for an allowance and balance slot to collide. Making it possible for someone to destroy WETH or mint unsusable WETH by finding an allowance slot with 12 leading zero bytes (96-bit bruteforce). For more details on the implications of this view the Security doc.

Function Dispatcher

METH uses a constant gas function dispatcher that jumps to any function in its ABI in only 34-gas:

Step gas cost Cumulative gas cost Op-Code Stack Explanation
2 2 PUSH0 [0] Push 0 using 2 gas (EIP-3855 included in the Shangai upgrade)
3 5 CALLDATALOAD [calldata[0:32]] Load calldata (including selector)
3 8 PUSH1 0xE0 [0xe0 (224); calldata[0:32]] Push selector offset
3 11 SHR [selector] Bitshift right to get 4 upper most bytes of calldata i.e. selector
3 14 DUP1 [selector; selector] Duplicate selector on stack for jump table
3 17 PUSH1 0x12 [0x12 (18), selector; selector] Push unique selector bits offset
3 20 SHR [unique_bits; selector] Bitshift right to get the 14 uppermost bits of the selector
3 23 PUSH1 0x3F [0x3f (0b111111); unique_bits; selector] Push lower bit mask
3 26 OR [jump_destination; selector] Masks lower bits to ensure there's sufficient space between destinations
8 34 JUMP [selector] Jump to function.

Each function verifies whether the selector matches its function selector as whole, this is done to ensure that the contract actually reverts if it's called with a selector where the identifying 8-bits match with an existing function but the full selector does not e.g. (from name()):

Step gas cost Cumulative gas cost Op-Code Stack Explanation
1 1 JUMPDEST [selector] "Landing pad" of function from dispatcher
3 4 PUSH4 0x06fdde03 [name.selector, selector] Pushes expected selector to stack
3 7 SUB [selector_diff] Use subtraction operator as inequality check
2 9 CALLVALUE [msg.value, selector_diff] Push msg.value
3 12 OR [invalid_call] Bitwise OR results in non-zero value if either selector didn't match or ETH was sent
3 15 PUSH2 0x40e1 [revert_dest, invalid_call] Pushes revert destination to stack
10 25 JUMPI [] Jumps to a revert if invalid_call is non-zero

Due to the cost of the JUMPI opcode some functions that have more conditions defer the actual branching instruction until it can bundle together the check of multiple conditions e.g. withdraw(uint) uses only 1 JUMPI to check both the selector and that the caller has sufficient balance.