Secureum Book
  • 🛡️Secureum Bootcamp
    • 🛡️Secureum Bootcamp
    • 🙌Participate
    • 📜History
  • 📚LEARN
    • Introduction
      • 🔷1. Ethereum Basics
        • 1.1 Ethereum: Concept, Infrastructure & Purpose
        • 1.2 Properties of the Ethereum Infrastructure
        • 1.3 Ethereum vs. Bitcoin
        • 1.4 Ethereum Core Components
        • 1.5 Gas Metering: Solving the Halting Problem
        • 1.6 web2 vs. web3: The Paradigm Shift
        • 1.7 Decentralization
        • 1.8 Cryptography, Digital Signature & Keys
        • 1.9 Ethereum State & Account Types
        • 1.10 Transactions: Properties & Components
        • 1.11 Contract Creation
        • 1.12 Transactions, Messages & Blockchain
        • 1.13 EVM (Ethereum Virtual Machine) in Depth
        • 1.14 Transaction Reverts & Data
        • 1.15 Block Explorer
        • 1.16 Mainnet & Testnets
        • 1.17 ERCs & EIPs
        • 1.18 Legal Aspects in web3: Pseudonymity & DAOs
        • 1.19 Security in web3
        • 1.20 web2 Timescales vs. web3 Timescales
        • 1.21 Test-in-Prod. SSLDC vs. Audits
        • Summary: 101 Keypoints
      • 🌀2. Solidity
        • 2.1 Solidity: Influence, Features & Layout
        • 2.2 SPDX & Pragmas
        • 2.3 Imports
        • 2.4 Comments & NatSpec
        • 2.5 Smart Contracts
        • 2.6 State Variables: Definition, Visibility & Mutability
        • 2.7 Data Location
        • 2.8 Functions
        • 2.9 Events
        • 2.10 Solidity Typing
        • 2.11 Solidity Variables
        • 2.12 Address Type
        • 2.13 Conversions
        • 2.14 Keywords & Shorthand Operators
        • 2.15 Solidity Units
        • 2.16 Block & Transaction Properties
        • 2.17 ABI Encoding & Decoding
        • 2.18 Error Handling
        • 2.19 Mathematical & Cryptographic Functions
        • 2.20 Control Structures
        • 2.21 Style & Conventions
        • 2.22 Inheritance
        • 2.23 EVM Storage
        • 2.24 EVM Memory
        • 2.25 Inline Assembly
        • 2.26 Solidity Version Changes
        • 2.27 Security Checks
        • 2.28 OpenZeppelin Libraries
        • 2.29 DAppSys Libraries
        • 2.30 Important Protocols
        • Summary: 201 Keypoints
      • 🔏3. Security Pitfalls & Best Practices
        • 3.1 Solidity Versions
        • 3.2 Access Control
        • 3.3 Modifiers
        • 3.4 Constructor
        • 3.5 Delegatecall
        • 3.6 Reentrancy
        • 3.7 Private Data
        • 3.8 PRNG & Time
        • 3.9 Math & Logic
        • 3.10 Transaction Order Dependence
        • 3.11 ecrecover
        • 3.12 Unexpected Returns
        • 3.13 Ether Accounting
        • 3.14 Transaction Checks
        • 3.15 Delete Mappings
        • 3.16 State Modification
        • 3.17 Shadowing & Pre-declaration
        • 3.18 Gas & Costs
        • 3.19 Events
        • 3.20 Unary Expressions
        • 3.21 Addresses
        • 3.22 Assertions
        • 3.23 Keywords
        • 3.24 Visibility
        • 3.25 Inheritance
        • 3.26 Reference Parameters
        • 3.27 Arbitrary Jumps
        • 3.28 Hash Collisions & Byte Level Issues
        • 3.29 Unicode RTLO
        • 3.30 Variables
        • 3.31 Pointers
        • 3.32 Out-of-range Enum
        • 3.33 Dead Code & Redundant Statements
        • 3.34 Compiler Bugs
        • 3.35 Proxy Pitfalls
        • 3.36 Token Pitfalls
        • 3.37 Special Token Pitfalls
        • 3.38 Guarded Launch Pitfalls
        • 3.39 System Pitfalls
        • 3.40 Access Control Pitfalls
        • 3.41 Testing, Unused & Redundand Code
        • 3.42 Handling Ether
        • 3.43 Application Logic Pitfalls
        • 3.44 Saltzer & Schroeder's Design Principles
        • Summary: 201 Keypoints
      • 🗜️4. Audit Techniques & Tools
        • 4.1 Audit
        • 4.2 Analysis Techniques
        • 4.3 Specification, Documentation & Testing
        • 4.4 False Positives & Negatives
        • 4.5 Security Tools
        • 4.6 Audit Process
        • Summary: 101 Keypoints
      • ☝️5. Audit Findings
        • 5.1 Criticals
        • 5.2 Highs
        • 5.3 Mediums
        • 5.4 Lows
        • 5.5 Informationals
        • Summary: 201 Keypoints
  • 🌱CARE
    • CARE
      • CARE Reports
  • 🚩CTFs
    • A-MAZE-X CTFs
      • Secureum A-MAZE-X
      • Secureum A-MAZE-X Stanford
      • Secureum A-MAZE-X Maison de la Chimie Paris
Powered by GitBook
On this page
  • WETH
  • Uniswap V2
  • Uniswap V3
  • Chainlink
  1. LEARN
  2. Introduction
  3. 2. Solidity

2.30 Important Protocols

Previous2.29 DAppSys LibrariesNextSummary: 201 Keypoints

Last updated 1 year ago

There are many protocols currently living in the EVM. The protocols presented here are few of the most important protocols that an auditor must be familiar with.

WETH

Protocols often work with one or many ERC20 tokens, be it either their own or of other protocols. They also work with the Ether that is sent to their smart contracts via msg.value. Instead of having two separate sets of logic and two separate sets of control flow within their contracts (one to deal with Ether, the other to deal with ERC20 tokens), it would be very convenient if we could have a single logic, a single control flow to deal with both Ether and ERC20 tokens.

The WETH concept provides this capability: it allows smart contracts to convert Ether that's been sent to their contracts to its ERC20 equivalent which is known as WETH. This conversion is a process called wrapping, while the other direction of converting the ERC20 equivalent of WETH back to Ether is called unwrapping.

This is made possible by sending the Ether to a WETH contract which converts it into its ERC20 equivalent at a 1:11:11:1 ratio. There are multiple versions of WETH contracts the most popular right now, is the which holds anywhere between 6.5 to 7 million Ether as of this point.

There are also some improvements being done: there is WETH10 that is more Gas efficient than the version 9. This version also supports flash loans as per the EIP3156 standard. So this WETH concept is something that we often come across in smart contact applications.

Uniswap V2

Uniswap is an automated market making protocol on Ethereum. That's powered by what is known as a constant product formula:

xy=kxy=kxy=k

where xxx and yyy are token balances of two different tokens and kkk is their constant product.

Uniswap allows liquidity providers to create pools of token pairs, and whenever anyone provides liquidity to either of the two tokens of the token pair, new tokens known as LP tokens liquidity provided tokens are minted and sent back to the liquidity provider. This represents their share of the liquidity in the tokens.

Uniswap is the most popular protocol on Ethereum currently for swapping between tokens belonging to a token pair, and a big part of that is because of the simplicity of the constant product formula as determined by the curve xy=kxy=kxy=k.

Uniswap also provides support for on-chain Oracles. A price Oracle is a tool that allows smart contracts to determine the price information about a given asset on the blockchain. In the case of Uniswap V2, every token pair measures the price of further tokens at the beginning of each block.

So, in effect this is measuring the price at the end of the previous block that is maintained within a cumulative price variable that's weighted by the amount of time this price has existed for the token pair. This particular variable can be used by different contracts on the Ethereum blockchain to track what is known as "time weighted average prices" (TWAPs) across any particular time interval.

Uniswap V3

Uniswap recently introduced their version 3 of the protocol, which is considered as a big improvement over their version 2. This improvement is specifically around the concept of concentrated liquidity. What this means is it allows liquidity providers to provide liquidity for the token pair, across custom price ranges instead of across the entire constant product curve.

This brings about a big improvement to their capital efficiency. This version of the protocol also introduces flexible fees across different values as shown here.

Finally, for Oracle support, version V3 introduces advanced TWAP support where the cumulative sum instead of being maintained and trapped in one variable is now done so in an array. This allows smart contracts to query the TWAP on demand for any period within the last 9 days.

Chainlink

Chainlink is perhaps the most widely used Oracle and source of price feeds for smart contracts on Ethereum. Price data and even other kinds of data are taken from multiple off-chain data providers and they are put on-chain to create these feeds by the decentralized Oracles on the chainlink network.

Chainlink has mechanisms for aggregating this data across the various data providers and itself provides an extensive set of APIs for working with these Oracles and price feeds.

📚
🌀
WETH9 contract