From a9320067bff0299749268df026cb11f368b4c6e0 Mon Sep 17 00:00:00 2001
From: ant <0xdevant@gmail.com>
Date: Fri, 20 Sep 2024 11:44:18 +0800
Subject: [PATCH] complement to v4 concepts: erc6909 (#772)

Co-authored-by: saucepoint <98790946+saucepoint@users.noreply.github.com>
---
 docs/contracts/v4/concepts/03-erc6909.mdx | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/docs/contracts/v4/concepts/03-erc6909.mdx b/docs/contracts/v4/concepts/03-erc6909.mdx
index b702a373f..3a7b14674 100644
--- a/docs/contracts/v4/concepts/03-erc6909.mdx
+++ b/docs/contracts/v4/concepts/03-erc6909.mdx
@@ -4,14 +4,24 @@ title: ERC-6909
 
 Uniswap v4 uses [ERC-6909](https://eips.ethereum.org/EIPS/eip-6909) to further improve gas-efficiency on token claims and redemptions.
 
-ERC-6909 is a simple multi-token contract standard. The token standard is analogous to managing multiple ERC-20 tokens from a single smart contract - similar to ERC-1155. The major difference between ERC-6909 vs. ERC-1155 is granular approvals and the removal of inefficient safe transfer callbacks.
+ERC-6909 is a minimal and gas-efficient standard for managing multiple ERC-20 tokens from a single contract. It provides a simplified alternative to the more complex ERC-1155 multi-token standard. 
+
+### ERC-6909 vs ERC-1155
+
+ERC-6909 offers several advantages over ERC-1155:
+1. Simplified interface: ERC-6909 removes unnecessary safe transfer callbacks and batching constraints presented in ERC-1155.
+2. Improved transfer delegation: ERC-6909 provides a more efficient system for transfer delegation.
+3. Gas efficiency: ERC-6909 reduces gas costs for deployment, transfers, and burning operations.
+4. Reduced code size: Implementing ERC-6909 results in smaller contract sizes compared to ERC-1155.
+
+However, it's worth noting that ERC-6909 does introduce a `totalSupply` variable, which leads to an additional disk write on mint and burn operations.
 
 # How it works
 
 Instead of choosing to move tokens in/out of the `PoolManager`, developers can opt-in and leave the ERC-20 tokens within the `PoolManager`. In exchange, the `PoolManager` can **mint them an ERC-6909 token representing their claim**. In subsequent interactions requiring _paying_ tokens, users will not need to transfer ERC-20 tokens into the `PoolManager` - users can simply _burn_ some (or all) of their claim tokens they have
 
 
-Doing _real_ ERC-20 token transfers requires calls to external smart contracts - incurring gas overhead compared to internal accounting. Secondly, these external smart contracts have their own custom logic within their transfer functions - for example USDC's blocked-address list - which is a further gas overhead. Thus, minting and burning ERC-6909 tokens are more gas-efficient because they don't require external function calls and have a constant-size gas overhead regardless of the underlying ERC-20 token.
+Doing _real_ ERC-20 token transfers requires calls to external smart contracts - incurring gas overhead compared to internal accounting. Secondly, these external smart contracts have their own custom logic within their `transfer` functions - for example USDC's blocked-address list - which is a further gas overhead. Thus, minting and burning ERC-6909 tokens are more gas-efficient because they don't require external function calls and have a constant-size gas overhead regardless of the underlying ERC-20 token.
 
 This mechanism therefore helps further reduce gas costs. All these gas cost reductions overall make pools much more competitive based on the fees they charge.