שדה ה-liquidity של בריכת Uniswap V3 איננו כסף ואיננו עומק החלפה. תן ל-Claude לעבור איתך על כל שדה שקל לקרוא לא נכון.
כל מי שנוגע ב-DeFi מוצא את עצמו במוקדם או במאוחר בוהה בנתוני בריכת Uniswap V3. ובאותו מצבור מספרים בעמוד הבריכה יש לפחות שדה אחד שכמעט כל אחד קורא לא נכון בפעם הראשונה —— קריאה שגויה גדולה מספיק כדי לגרום לך להאמין שבבריכה של 100 מיליון דולר יש 3.2 קווינטיליון דולר של "נזילות" בפנים.
הפוסט הזה קורא בריכה אחת מקצה לקצה תוך חמש דקות, באמצעות smarts MCP יחד עם Claude. נתונים אמיתיים, בריכת USDC/WETH 0.05% במיינ-נט.
אחרי חיבור smarts MCP, Claude קורא ל-get_uniswap_v3_pool עם הסלאג univ3-usdc-weth-eth ומקבל את זה:
protocol: Uniswap V3
pair: USDC/WETH
fee: 0.05%
price:
1 WETH in USDC: 2310.3381
1 USDC in WETH: 0.00043283
tick: 198868
liquidity: 3243712254364037809
liquidity_note: Uniswap V3 sqrt-formula virtual liquidity
at the current tick. Not a USD amount and
not the depth available to swap.
tvl_usd: 100,645,897.62
tokens:
token0: USDC (decimals 6)
token1: WETH (decimals 18)
block_number: 24959248
הנתונים עצמם פשוטים. העניין הוא שלכל שדה יש מלכודת. אחד אחרי השני.
מניחים שבבריכת USDC/WETH ה-USDC הוא "המטבע הראשי" וה-WETH הוא "הנכס שמתומחר". טעות. Uniswap V3 ממיין את token0 ואת token1 בהקפדה לפי הערך המספרי של הכתובות. כתובת USDC 0xa0b8... קטנה מכתובת WETH 0xc02a..., ולכן token0 = USDC ו-token1 = WETH.
הסדר הזה שולט בכל חישוב פנימי: לאיזה כיוון פונה המחיר, לאיזה כיוון נעים ה-ticks, באיזו יחידה מתבטאת הנזילות. תעבור לבריכה אחרת, נניח WETH/DAI, ותפקידי token0/token1 עלולים להתהפך —— כל אינטואיציה של "האם ETH עולה או יורד?" צריכה להיחשב מחדש.
אחד היתרונות של תת ל-Claude לקרוא את הבריכה: הוא מחזיר את המחיר עם תוויות לשני הכיוונים, אז אין צורך לחשב בראש "איזה צד של ה-tick הוא איזה token".
ארבע רמות העמלה הנפוצות ב-Uniswap V3 הן 0.01% / 0.05% / 0.30% / 1.00%.
העובדה ש-USDC/WETH משתמש ב-0.05% ולא ב-0.30% אומרת: עושי שוק מהמרים על נפח, לא על עמלות שמנות לעסקה, כי התנודתיות תחומה והזרימה אדירה.
מתוך ידיעה זו, ברגע שאתה רואה בריכה חדשה ב-fee 1% אתה יכול לנחש: או שזה טוקן חדש לגמרי או שאין לאף אחד עניין בזוג.
מצב הבריכה ב-V3 לא מכיל שדה נפרד של "מחיר עסקה אחרון". המחיר הנוכחי הוא מה ש-slot0.sqrtPriceX96 אומר, וה-tick הוא הביטוי הלוגריתמי שלו. במילים אחרות: כל עוד אף אחד לא סוחר, המחיר פשוט יושב שם, מודל שונה לחלוטין מ"הביצוע האחרון" של בורסה מרכזית.
(לצורך מחירים היסטוריים משתמשים ב-oracle המובנה של V3 —— מצב הבריכה מכיל מערך של מצברי observation שמהם אפשר לגזור TWAP. זה מנגנון נפרד.)
ה-1 WETH = 2310.34 USDC שזה עתה קראנו הוא "הציטוט הנוכחי" של הבריכה; ה-swap הבא יוצא מהמחיר הזה ודוחף אותו לאורך העקומה ל-tick חדש.
tick: 198868 הוא המספר שמבלבל את כולם בפעם הראשונה. מרגיש כמו איזה סוג של מחיר, אבל זה לא דולר.
V3 מבצע דיסקרטיזציה לוגריתמית למחיר: raw_price = 1.0001^tick, כאשר raw_price הוא wei של token1 מחולק ב-wei של token0 —— לא המחיר התצוגתי. כדי להפוך את זה ל-"1 ETH ב-USDC" צריך עוד להכפיל ב-10^(decimals_token0 - decimals_token1). אחרי התיקון הזה, ה-tick 198868 מתאים בערך ל-1 ETH ≈ 2310 USDC.
למה כל הסיבוב הזה? כי ברגע שהמחיר לוגריתמי, עושי השוק יכולים להציב נזילות רק בטווח מחירים מסוים —— למשל "רק בין 2200 ל-2400". ticks דיסקרטיים הם התוויות של הטווחים האלה. זו החדשנות המכוננת של V3 לעומת V2: נזילות מרוכזת.
בפועל אינך צריך לחשב ticks. רק לדעת: tick גדול יותר לא בהכרח אומר מחיר גבוה יותר (תלוי מי הוא token0), וצעד tick אחד הוא שינוי מחיר של 0.01%.
הנה המלכודת הגדולה: liquidity: 3243712254364037809.
19 ספרות, נראה כמו wei. אבל זה לא כסף.
זוהי "הנזילות הווירטואלית" L מהמתמטיקה של Uniswap V3 —— פרמטר פנימי המבטא את שיפוע עקומת עשיית השוק בטווח sqrt-price. היחידות שלו אינן USD ואינו ניתן להשוואה למה שהבריכה מחזיקה בפועל.
תגובת הכלי מתריעה ישירות באמצעות liquidity_note:
Uniswap V3 sqrt-formula virtual liquidity at the current tick. Not a USD amount and not the depth available to swap.
למה החצי השני? כי טעות נפוצה נוספת היא לקרוא liquidity כ"כמה אני יכול להחליף עכשיו בלי slippage". גם לא נכון. עומק ה-swap ב-V3 מחושב במקטעים: בתוך טווח ה-tick הנוכחי משתמשים ב-L הזה עם נוסחת sqrt-price; ברגע שעסקה דוחפת את המחיר אל מעבר לגבול tick, חוצים לטווח הבא ועוברים ל-L שלו. כל גבול שנחצה מחליף L חדש, עד שהעסקה מסתיימת. לכן "כמה ניתן להחליף בלי slippage" תלוי בכמה L יושב בכל טווח לאורך המסלול —— מספר יחיד מה-slot0 לא אומר על זה כלום.
לזכור: אל תשווה את שדה liquidity ל-USD ואל תשתמש בו להשוות "עומק" בין בריכות —— זה מטעה.
tvl_usd: 100,645,897.62. זה הכסף האמיתי של הבריכה.
מאיפה המספר? זו יתרת ה-USDC הממשית של החוזה ועוד יתרת ה-WETH הממשית, כל אחת מוכפלת במחיר הנוכחי בדולרים מ-DefiLlama, ומסוכמת.
בהשוואה לשדה liquidity:
| שדה | ערך | משמעות |
|---|---|---|
| liquidity | 3.24 × 10¹⁸ | פרמטר מתמטי פנימי של V3, ללא יחידה |
| tvl_usd | $100,645,897 | כסף ממשי שהבריכה מחזיקה |
שניהם מתורגמים בדיבור היומיומי כ"נזילות", אבל הם דברים שונים. לסיפור הסתכל על TVL, לחישובים על liquidity, לעולם אל תערבב.
פרט אחרון: block_number: 24959248.
נתונים על-שרשרת מגיעים תמיד עם מספר בלוק. כל שדה ש-Claude משך נקרא באותו בלוק. זה מסיק שני דברים:
ללוגיקת ניטור או ארביטראז' זוהי התכונה המכרעת —— משיכה אחת נותנת לך תמונת עולם עקבית, ואין צורך לחשוש מהפרשי זמן בין שדות.
ברגע שמבינים את כל זה, ארגז הכלים נפתח:
כל אלה דרשו פעם להתקין web3.py, לכתוב סקריפט, לתחזק ABI, לשכור RPC. עכשיו הכל ברמת שיחה עם Claude + MCP —— אתה שואל, הוא קורא.
למודל המתמטי של V3 יש קיר כניסה. sqrtPriceX96, ticks, L, נזילות מרוכזת —— המושגים האלה הרתיעו לא מעט אנשים. אך בפועל 90% ממה שאתה צריך הוא "האם הבריכה הזו בריאה, האם יש בה כסף, מה המחיר?" —— בלי נוסחאות.
תן ל-Claude להיות המתרגם שלך ל-V3, להפוך נזילות וירטואלית וקידוד tick למשפט אנושי פשוט מסוג "1 ETH = 2310 USDC, בבריכה יש 100 מיליון דולר". ההחלטות מנקודה זו והלאה הן עליך.