Hồ sơ token · UNI cập nhật theo bằng chứng
UNI,qua từng lần kiểm chứng.
Các khẳng định BlockPinned đã công bố về UNI được tập hợp tại đây — kèm mốc đo, nguồn, điều có thể làm kết luận thay đổi và trạng thái hiện tại.
Đọc bài viết về UNI5 bài viết↓Audit ruleSửa trạng thái, không xoá lịch sử.→Mở từng claim để thấy chính xác điều gì có thể bác bỏ nó.
READING DESK · 5 INVESTIGATIONS
Bài điều tra về UNI
Bắt đầu từ bài gốc để thấy câu hỏi, đường đo và giới hạn trước khi mở từng claim.
Đang giới thiệu 5 / 5 bài viết · danh mục đầy đủ có tìm kiếm và lọc theo token
REPRODUCTION COVERAGE
Biết ngay phép đo nào mở được ở đâu.
PUBLIC CLAIM LEDGER · 24 ENTRIES
Tủ claim UNI
Đang hiện 24 claim
VẪN ĐỨNG VỮNGTừ block đầu tới Robinhood block 29.174.972, contract Firepit trên Robinhood Chain đã huỷ 170 lượt × 2.000 = 340.000 UNI bản Robinhood. Trên Ethereum, mới 22 lượt × 2.000 = 44.000 UNI gốc tới địa chỉ đốt qua gateway của chain này — 12,9%. Phần chênh là 296.000 UNI.06/08/2026 · C1 · Biểu đồ UNI burn trên Ethereum đang chậm gần một tuần so với Robinhood Chain
GHIM TẠIRobinhood Chain block 1 → 29.174.972 · Firepit 0x7a8f74c2585f84c781f951b7f2ff21337d5b630b · token bản Robinhood 0xf177d86a28b520e3e396e4f3b96cd8e72d7dabd8 · phía Ethereum: gateway 0x85001cc4867c5e1c22da4b79bb8852b9e2a06da0, block 25.671.175 → 25.690.453, 0 range rớt
ĐIỀU GÌ BÁC BỎ CLAIM NÀYQuét log Transfer của token bản Robinhood với from = Firepit và to = address(0) trên toàn dải block: ra khác 170 lượt hoặc khác 340.000 UNI thì claim này sai. Chiều thứ hai, độc lập: đếm Transfer với to = Firepit — vào phải bằng ra, cũng 170 lượt / 340.000. Phía Ethereum: đọc Transfer của UNI tới địa chỉ đốt, lọc địa chỉ gửi là gateway, trong dải block ghim — không ra đúng 22 dòng × 2.000 UNI thì con số 44.000 và tỉ lệ 12,9% sai. Hai đầu này đọc ở hai chain và hai thời điểm nên KHÔNG cộng lại được; cộng 296.000 với 44.000 để ra một lượng đã đốt là đọc sai claim.
KHÔNG ĐO LẠI ĐƯỢC TỪ TRÌNH DUYỆTĐây là phép cộng dồn trên một dải block ở HAI chain, không phải một lời gọi tại một block, nên nút đo lại của trang không dựng được. Nặng hơn: một nửa phép đo nằm trên Robinhood Chain, mà nút của trang chỉ gọi được RPC Ethereum. Đường dựng lại đầy đủ nằm ở phần điều-bác-bỏ và ở script trong hồ sơ.
VẪN ĐỨNG VỮNGĐịa chỉ 0x85001cc4867c5e1c22da4b79bb8852b9e2a06da0 trên Ethereum là gateway của Robinhood Chain. Contract này chưa verify source, nên một bảng quy kết chỉ dựa vào danh sách gateway đã gắn nhãn sẽ xếp nó vào nhóm chưa rõ chain — bảng trước đây của chính BlockPinned cũng vậy.06/08/2026 · C2 · Biểu đồ UNI burn trên Ethereum đang chậm gần một tuần so với Robinhood Chain
GHIM TẠIEthereum block 25.690.453 · counterpartGateway() (selector 0x2db09c1c) trả 0xfd9b17206278c16ddaacf6ac8f05dbf97edcb31e · chiều ngược đọc trên Robinhood Chain block 29.174.972 · outbox 0xf0ce991ea4a0d2400a4ab49b20ae333f6dce3de9
ĐIỀU GÌ BÁC BỎ CLAIM NÀYBốn phép đọc độc lập chống claim này, chỉ cần một phép hỏng là phép gán chain mất giá trị và mọi câu gán 44.000 UNI cho Robinhood Chain phải rút: ⒜ gọi counterpartGateway() trên Ethereum — không trả 0xfd9b1720…b31e thì sai; ⒝ gọi cùng hàm đó trên địa chỉ vừa trả về bằng RPC công khai của Robinhood Chain — không trỏ ngược đúng 0x85001cc4… thì sai; ⒞ đọc một thông điệp L2ToL1Tx do Firepit phát — không ghi đích là 0x85001cc4… hoặc dữ liệu kèm theo không chứa đồng thời địa chỉ UNI trên Ethereum, địa chỉ đốt và số 2.000 × 10¹⁸ thì sai; ⒟ giao dịch đưa 2.000 UNI tới địa chỉ đốt gọi executeTransaction trên outbox — bridge() của outbox không trùng bridge đọc từ inbox() của gateway thì sai. Claim này KHÔNG nói Robinhood Chain là chain đóng góp lớn nhất: còn hai địa chỉ gửi chưa rõ thuộc chain nào, 20.000 và 4.000 UNI; nếu chúng cùng một chain và tổng vượt 44.000 thì thứ hạng ở cấp chain phải viết lại — nhưng 22 lượt và 44.000 UNI từ chính địa chỉ này vẫn đứng.
KHÔNG ĐO LẠI ĐƯỢC TỪ TRÌNH DUYỆTHàm counterpartGateway() trả về một ĐỊA CHỈ, không phải một đại lượng có đơn vị, nên nút đo lại của trang — vốn chỉ biết in một con số kèm đơn vị — sẽ dựng nó thành một số nguyên vô nghĩa. Ba phép đọc còn lại nằm trên Robinhood Chain hoặc trong calldata của một giao dịch, cả hai đều ngoài tầm nút này.
VẪN ĐỨNG VỮNGCả 170 lệnh rút do Firepit phát đều nhắm địa chỉ đốt — đọc từng thông điệp, không suy từ mẫu.06/08/2026 · C3 · Biểu đồ UNI burn trên Ethereum đang chậm gần một tuần so với Robinhood Chain
GHIM TẠIRobinhood Chain block 1 → 29.174.972 · L2ToL1Tx lọc theo đích là gateway 0xfd9b17206278c16ddaacf6ac8f05dbf97edcb31e: 312 thông điệp, 170 chứa đồng thời địa chỉ đốt + UNI trên Ethereum 0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 + số 2.000 × 10¹⁸
ĐIỀU GÌ BÁC BỎ CLAIM NÀYQuét lại L2ToL1Tx với đích là gateway trên toàn dải block, đếm số thông điệp chứa đủ ba dấu hiệu trên. Ra ít hơn 170 thì có lệnh rút không nhắm địa chỉ đốt và câu 'cả 170' sai. Ra nhiều hơn 170 thì phép ghép một-đổi-một với 170 lượt Firepit huỷ token sai. 142 thông điệp còn lại là rút thường của bên khác qua cùng gateway; nếu một thông điệp trong nhóm đó cũng mang đủ ba dấu hiệu thì phép đếm này lẫn và claim sai.
KHÔNG ĐO LẠI ĐƯỢC TỪ TRÌNH DUYỆTPhép đo là quét log trên toàn dải block của Robinhood Chain rồi so khớp nội dung từng thông điệp, không phải một lời gọi tại một block, và chain đó nằm ngoài RPC mà nút của trang gọi được.
VẪN ĐỨNG VỮNGMỗi lệnh rút chờ 6,44–7,41 ngày mới được thực thi trên Ethereum: đo trên cả 22 lượt đã về, min 6,44 · trung vị 6,76 · max 7,41 ngày. Vì vậy lượng UNI đốt hiển thị hôm nay phản ánh các LỆNH RÚT phát khoảng một tuần trước — còn PHÍ tạo ra lượng UNI đó phát sinh sớm hơn nữa.06/08/2026 · C4 · Biểu đồ UNI burn trên Ethereum đang chậm gần một tuần so với Robinhood Chain
GHIM TẠIEthereum block 25.671.175 → 25.690.453 · giải mã trường l2Timestamp trong calldata executeTransaction của cả 22 lượt · hàng chờ thứ nhất (khoảng cách giữa hai lệnh liên tiếp trên Robinhood Chain): min 0 · trung vị 71 phút · max 1.682 phút
ĐIỀU GÌ BÁC BỎ CLAIM NÀYVới mỗi giao dịch đưa 2.000 UNI từ gateway tới địa chỉ đốt, đọc calldata của lời gọi executeTransaction và lấy trường l2Timestamp, rồi trừ khỏi timestamp block Ethereum của chính giao dịch đó. Ra ngoài khoảng 6,44–7,41 ngày ở bất kỳ lượt nào thì claim này sai. Phép ghép cặp này không giả định thứ tự — mỗi lượt tự khai thời điểm nó được phát ở đầu Robinhood — nên nếu ai đó ghép theo thứ tự trước-sau và ra số khác thì đó là phép ghép kia sai, không phải claim này. 🔴 Con số này là độ trễ từ LỆNH RÚT tới lúc thực thi, KHÔNG phải từ lúc phí phát sinh: đoạn phí nằm trong TokenJar trước khi thành UNI chưa được đo, nên tổng độ trễ thực tế chỉ có thể dài hơn.
KHÔNG ĐO LẠI ĐƯỢC TỪ TRÌNH DUYỆTPhép đo là giải mã calldata của 22 giao dịch đã xảy ra rồi lấy phân vị, không phải một lời gọi trả về một con số. Nút của trang gọi eth_call tại một block; nó không đọc được calldata của giao dịch cũ.
VẪN ĐỨNG VỮNGChờ đủ tuổi chưa đủ để một lệnh rút được thực thi — còn phải có người chọn lượt đó. Lệnh rút đầu tiên của Firepit mang số thứ tự 679; quét toàn bộ 601 lượt thực thi của cầu, số thứ tự 0 → 796, thì 679 không có mặt trong khi 678 và 680 đều đã thực thi. Nên 296.000 UNI chưa về không phải đều đang chờ đúng quy trình.06/08/2026 · C5 · Biểu đồ UNI burn trên Ethereum đang chậm gần một tuần so với Robinhood Chain
GHIM TẠILệnh rút đầu: Robinhood block 20.678.587, 10:59:00Z ngày 27/07 · outbox 0xf0ce991ea4a0d2400a4ab49b20ae333f6dce3de9, 601 lượt OutBoxTransactionExecuted, index 0 → 796 · chưa thực thi quanh đó: 679 · 682–687 · 689 · 693 · 699 · cả 22 lượt đã về đều do 0x2cf8e5b175aa29c1fdf0e9fe572735c78eacce43 gọi
ĐIỀU GÌ BÁC BỎ CLAIM NÀYQuét log OutBoxTransactionExecuted của outbox trên toàn dải block và lập danh sách index đã thực thi. Nếu 679 có trong danh sách thì claim này sai. Nếu 678 hoặc 680 KHÔNG có trong danh sách thì phép so sánh 'bị nhảy qua' mất chỗ dựa và claim cũng sai. Chiều thứ hai: nếu mọi index chưa thực thi đều lớn hơn mọi index đã thực thi thì thứ tự là tuần tự và cách đọc của bài sai. 🔴 Chỗ bài chưa với tới: 127/601 lượt thực thi có đích là gateway này nhưng chỉ 22 đưa UNI tới địa chỉ đốt; 105 lượt còn lại đưa tài sản khác đi chỗ khác và bài không đo chúng — nên claim này nói về CÁCH chọn lượt, không nói gì về ý định của người chọn.
KHÔNG ĐO LẠI ĐƯỢC TỪ TRÌNH DUYỆTPhải quét log trên toàn dải block Ethereum rồi so hai tập index, không phải một lời gọi tại một block. Nút của trang chỉ chạy eth_call.
VẪN ĐỨNG VỮNGTrong trọn ngày UTC 29/07/2026 trên Robinhood Chain, người dùng trả tổng $2.521.197 phí swap và Uniswap ghi nhận $369.178 phí giao thức — tức 14,64%, tương đương $14,64 trên mỗi $100.31/07/2026 · C1 · Mỗi $100 phí swap trên Robinhood Chain, Uniswap ghi nhận $14,64
GHIM TẠIRobinhood Chain · block 22.006.019 → 22.867.791 (2026-07-29T00:00:00Z → 23:59:59Z) · factory v2 0x8bceaa40b9acdfaedf85adf4ff01f5ad6517937f · factory v3 0x1f7d7550b1b028f7571e69a784071f0205fd2efa · PoolManager v4 0x8366a39cc670b4001a1121b8f6a443a643e40951 · giá quy đổi cuối ngày UTC 29/07
ĐIỀU GÌ BÁC BỎ CLAIM NÀYDựng lại tập pool từ log tạo pool của ba factory (25.472 pair v2 · 334.102 pool v3 · 209.478 pool v4), quét log Swap của đúng tập đó trong cửa sổ block trên, rồi cộng phí theo tỷ lệ protocol fee của từng pool. Nếu tổng phí lệch quá 0,5% so với $2.521.197, hoặc phần giao thức lệch quá 0,5% so với $369.178, claim này sai.
VẪN ĐỨNG VỮNGPhiên bản v4 lấy tỷ lệ thấp nhất trong ba phiên bản: 7,81% bình quân gia quyền theo phí của các pool v4 đã bật, so với 16,67% ở v2 và 16,78% ở v3.31/07/2026 · C2 · Mỗi $100 phí swap trên Robinhood Chain, Uniswap ghi nhận $14,64
GHIM TẠICùng cửa sổ block. v2 $198.383 phí → $33.064 · v3 $1.723.902 → $289.353 · v4 $598.913 → $46.762. Tỷ lệ v4 tính từ trường fee của từng log Swap và protocolFee của đúng pool.
ĐIỀU GÌ BÁC BỎ CLAIM NÀYMột phép dựng độc lập đọc từng log Swap cùng cấu hình protocol fee của đúng pool tại đúng block. Nếu tỷ lệ v4 lệch quá 2 điểm phần trăm so với 7,81%, claim này sai và câu 'phiên bản mới nhất lấy tỷ lệ thấp nhất' phải sửa công khai.
VẪN ĐỨNG VỮNGCông tắc protocol fee không bật ở mọi pool: tính theo giá trị phí, 92,9% phát sinh ở pool đã bật; $7,15 trên mỗi $100 phát sinh ở pool chưa bật, giao thức nhận $0.31/07/2026 · C3 · Mỗi $100 phí swap trên Robinhood Chain, Uniswap ghi nhận $14,64
GHIM TẠITập pool đã bật dựng từ event SetFeeProtocol (v3) và ProtocolFeeUpdated trên PoolManager (v4), quét từ block 1 tới 22.867.791. v2 là công tắc toàn cục feeTo() trên factory.
ĐIỀU GÌ BÁC BỎ CLAIM NÀYQuét lại hai event trên tới hết block 22.867.791 rồi cân theo giá trị phí của từng pool trong cửa sổ đo. Nếu độ phủ lệch quá 3 điểm phần trăm so với 92,9%, claim này sai.
VẪN ĐỨNG VỮNGTrong 30 pool v4 sinh phí nhiều nhất ngày hôm đó, cả 15 pool gắn hook đều không bật protocol fee. 15 pool còn lại trong nhóm không gắn hook.31/07/2026 · C4 · Mỗi $100 phí swap trên Robinhood Chain, Uniswap ghi nhận $14,64
GHIM TẠICùng cửa sổ block. Trường hook đọc từ event Initialize trên PoolManager v4; trạng thái công tắc đọc từ event ProtocolFeeUpdated.
ĐIỀU GÌ BÁC BỎ CLAIM NÀYLấy 30 pool v4 có phí cao nhất trong cửa sổ, đọc trường hook của từng pool và kiểm từng poolId có trong tập đã bật hay không. Nếu có bất kỳ pool gắn hook nào đã bật, claim này sai.
VẪN ĐỨNG VỮNGPhần chênh giữa phí giao thức ghi nhận và giá trị UNI đem burn trong cùng ngày KHÔNG nằm trong contract giữ tiền: dòng vào và dòng ra khớp nhau tới từng xu trên phần định giá được ($206.158,02 cả hai chiều), tồn ròng bằng 0.31/07/2026 · C5 · Mỗi $100 phí swap trên Robinhood Chain, Uniswap ghi nhận $14,64
GHIM TẠICùng cửa sổ block. TokenJar 0x2ac03e14cfe755426daaee0a4994184ce81482f8 · contract burn 0x7a8f74c2585f84c781f951b7f2ff21337d5b630b · UNI trên Robinhood 0xf177d86a28b520e3e396e4f3b96cd8e72d7dabd8. Giới hạn: 420 trên 472 token vào kho không có trong bộ giá đang dùng, nên $206.158 chỉ là phần định giá được.
ĐIỀU GÌ BÁC BỎ CLAIM NÀYQuét log Transfer có đích là TokenJar và có nguồn là TokenJar trong cùng cửa sổ, cộng theo từng token. Nếu tồn ròng khác 0 trên phần định giá được, claim này sai. Control dương: UNI vào contract burn trong cửa sổ phải đúng 62.000 (31 lượt × 2.000).
VẪN ĐỨNG VỮNGTrên Uniswap v4, protocol fee được cộng vào tổng phí người swap trả chứ không trừ khỏi pool fee của LP: một pool pool-fee 0,30% đã bật protocol fee thu tổng 0,3499%, và cả bốn mức phí chuẩn đều cho tổng lớn hơn pool fee tương ứng.30/07/2026 · C1 · Ai đang trả protocol fee của Uniswap v4, và pool nào vẫn đang trả 0
GHIM TẠIEthereum block 25.643.032, đoạn 400 block, 5.413 lượt swap · V4FeeAdapter 0x89a5d5bf00a27d55c02951e49078a5c5771051db · PoolManager 0x000000000004444c5dc75cb358380d2e3de08a90 · bốn đáp án 0,0125% / 0,0625% / 0,3499% / 1,0990% được ghi ra trước khi mở dữ liệu swap
ĐIỀU GÌ BÁC BỎ CLAIM NÀYLấy bất kỳ pool nào trong 126 pool ghi giá trị 3.499 ở đoạn đó, dựng lại PoolKey của nó và gọi getFee trên V4FeeAdapter tại block 25.643.032. Nếu hợp đồng trả protocol fee bằng 0 thì ở pool đó 3.499 là pool fee của chính pool, không phải phần cộng thêm — claim này phải hạ xuống 'số lượt mang giá trị trùng dự đoán'. Phép kiểm ngược đã chạy trên 8 pool, 8/8 khớp; 118 pool còn lại chưa chạy.
VẪN ĐỨNG VỮNGBốn pool dùng hook DualPool — hook Uniswap Labs công bố live ngày 30/07 — đều trả về protocol fee bằng 0; cùng bộ trường nhưng bỏ địa chỉ hook thì trả về mức của pool không hook tương ứng.30/07/2026 · C2 · Ai đang trả protocol fee của Uniswap v4, và pool nào vẫn đang trả 0
GHIM TẠIEthereum block 25.642.998 · AllowlistedFactory 0x0000000000077769c332e0d3ed8bc8e02a0ce108 (tạo tại block 25.581.749) · hai đường đếm khớp: allDeploymentsLength() = 4 và log Deployed = 4, cùng một tập bốn địa chỉ · 189 log Swap của bốn pool đều mang mức phí đúng bằng pool fee
ĐIỀU GÌ BÁC BỎ CLAIM NÀYGọi defaultFee() và hookFamilyId(hook) trên hợp đồng chính sách 0x1cd822b70a0591420f65e94b9b3a0d0b0fb3a314. Ra khác 0 nghĩa là cấu hình đã đổi và claim về trạng thái hiện tại hết đúng. Ở chiều ngược lại, nếu getFee của một trong bốn pool tại block 25.642.998 trả khác 0 thì phép đo tại block đó sai.
KHÔNG ĐO LẠI ĐƯỢC TỪ TRÌNH DUYỆTCon số 4 là số hook đăng ký tại AllowlistedFactory đó, tại block đo — nó sẽ tăng khi có hook mới. Một hook DualPool dựng ngoài factory này sẽ không nằm trong tập đếm được.
VẪN ĐỨNG VỮNGSáu chain đã bật protocol fee v4 dùng sáu hợp đồng chính sách có địa chỉ khác nhau nhưng đang mang cùng một bộ giá trị: mức mặc định bằng 0 và hook DualPool chưa được gán nhóm có phí.30/07/2026 · C3 · Ai đang trả protocol fee của Uniswap v4, và pool nào vẫn đang trả 0
GHIM TẠIethereum 0x1cd822b7…a314 @ 25.643.933 · arbitrum 0x8f6a5a19…bd0b @ 489.208.042 · optimism 0x13d9d198…2eb8 @ 154.897.430 · base 0xf963bdbe…ab71 @ 49.302.145 · polygon 0x600c29d3…6093 @ 91.125.747 · robinhood 0x6ee98430…3dfc @ 23.107.483 · đọc lại 30/07/2026 06:40:36 UTC
ĐIỀU GÌ BÁC BỎ CLAIM NÀYGọi defaultFee() và isHookedNativeMathFeeOn() trên từng hợp đồng ở trên. Một chain trả khác bộ giá trị này thì câu 'cùng một cấu hình trên sáu chain' sai. Control dương đi kèm: getCode của PoolManager phải trả 24.009 byte trên cả sáu — ra 0 thì phép đo mù và mọi số 0 ở trên vô nghĩa.
VẪN ĐỨNG VỮNGCon số '25% phí của LP' là ngôn ngữ v2/v3 của chính Uniswap — v2 mô tả protocol fee bằng một phần sáu phí LP, v3 có một mức bằng một phần tư — và ở hai cơ chế đó phần protocol được lấy từ khoản phí vốn dành cho LP. Chỗ trượt là mang cách tính đó sang v4.30/07/2026 · C4 · Ai đang trả protocol fee của Uniswap v4, và pool nào vẫn đang trả 0
GHIM TẠITrích tài liệu Uniswap, không phải phép đo trên chain của kênh này. Vế v4 đối chiếu là phép đo tại Ethereum block 25.643.032.
ĐIỀU GÌ BÁC BỎ CLAIM NÀYNếu tài liệu Uniswap mô tả protocol fee v2/v3 bằng một cơ chế khác phân số của phí LP thì vế trích nguồn này sai. Và nếu đo incidence v2/v3 trên chain cho thấy phần protocol cũng được cộng thêm chứ không trừ vào LP thì vế 'hai cơ chế ngược nhau' sai.
KHÔNG ĐO LẠI ĐƯỢC TỪ TRÌNH DUYỆTIncidence của v2 và v3 chưa được đo trên chain. Muốn kiểm, phải chạy phép thử tương tự trên pool v2/v3: so mức phí người swap thực trả với phần LP thực nhận, tại một block cố định.
VẪN ĐỨNG VỮNGChỉ số tích luỹ phí của Uniswap v4 là SỐ DƯ còn nằm trong hợp đồng, không phải bộ đếm cộng dồn — nên mức giảm 53% (ETH) và 61% (USDC) trên Ethereum không đọc được thành phí đã ngừng phát sinh.28/07/2026 · C1 · Uniswap bật thu phí v4 — chỉ số giảm 53% sau một đêm, và nó không phải bộ đếm
GHIM TẠIEthereum · hai lượt đọc protocolFeesAccrued lúc 14:51Z ngày 27/07 và 01:48Z ngày 28/07 · cùng cửa sổ block 25.624.853 → 25.628.131
ĐIỀU GÌ BÁC BỎ CLAIM NÀYCó bằng chứng cho thấy protocolFeesAccrued đã bao gồm cả phần phí đã được chuyển khỏi hợp đồng — khi đó công thức khép cửa sổ trong bài sai, và cả bài phải viết lại. Cách tự kiểm nằm ngay trong bài: đọc chỉ số hai lần cách nhau vài giờ, rồi đối chiếu log FeesCollected trong cùng cửa sổ để xem phần giảm có đúng là số dư đã rời hợp đồng.
gọiprotocolFeesAccrued(address)trên0x00000000…8A90VẪN ĐỨNG VỮNGCửa sổ 10,97 giờ đầu tiên khép được dòng phí v4 trên Ethereum: 4.382,57 đô, tính bằng (số dư sau − số dư trước) + tổng đã chuyển khỏi hợp đồng. Đây là mức sàn — mới định giá được 10 trong 28 loại token, và mới 1 trong 6 chain quy được ra tiền.28/07/2026 · C2 · Uniswap bật thu phí v4 — chỉ số giảm 53% sau một đêm, và nó không phải bộ đếm
GHIM TẠIEthereum · block 25.624.853 → 25.628.131 (21h50 ngày 27/07 → 08h48 ngày 28/07, tức 14:50Z → 01:48Z)
ĐIỀU GÌ BÁC BỎ CLAIM NÀYKhép lại đúng cửa sổ này trên Ethereum, cộng đủ phần đã chuyển, mà ra lệch quá 5% so với 4.382,57 đô ⇒ BlockPinned kiểm lại phía mình trước. Ngưỡng 5% được ghi trước ngay trong bài, thay cho chữ 'khác đáng kể' của bản nháp — một điều bác bỏ phải ghi trước cả ngưỡng lẫn cách tính.
VẪN ĐỨNG VỮNGPhần giá trị cuối cùng quy về UNI vẫn chưa tách được riêng cho v4: phí của v2, v3 và v4 vào chung một kho rồi kho mới được dùng để mua và đốt UNI, và bước đó bài này chưa đo được.28/07/2026 · C3 · Uniswap bật thu phí v4 — chỉ số giảm 53% sau một đêm, và nó không phải bộ đếm
GHIM TẠITrên rổ định giá được, v4 chiếm 17,71% giá trị dòng vào kho trong những giờ đầu · cùng cửa sổ block 25.624.853 → 25.628.131
ĐIỀU GÌ BÁC BỎ CLAIM NÀYAi chỉ ra được một đường tiền từ phí v4 tới cơ chế mua và đốt UNI mà bài chưa đo ⇒ phần 'chưa tách được' phải viết lại. Đây là giới hạn tự khai, không phải kết luận rằng đường tiền đó không tồn tại.
ĐÃ BỊ BÁC BỎNhịp bật pool đã giảm mạnh: đợt đầu bật 36.523 pool trong 7,7 giờ, rồi 23,5 giờ sau chỉ thêm 273 pool và tổng vẫn chưa qua 36.800.28/07/2026 · C4 · Uniswap bật thu phí v4 — chỉ số giảm 53% sau một đêm, và nó không phải bộ đếm
GHIM TẠIEthereum · 15:06Z ngày 27/07 (36.523 pool) → 02:24Z ngày 28/07 (blk 25.628.338) → 14:35Z ngày 28/07 (blk 25.631.951)
ĐIỀU GÌ BÁC BỎ CLAIM NÀYNếu từ 21h05 ngày 28/07 (14:05Z) đến 23h59 ngày 04/08/2026 số pool được bật trên Ethereum tăng thêm từ 5.000 trở lên, BlockPinned rút câu này và sửa tại đây. Điều này không bác bỏ ba claim còn lại của bài.
ĐÃ XÁC NHẬNNgày 16/07, DefiLlama báo phí Uniswap v4 trên Robinhood chain cao hơn 3,9 lần so với phép đếm trực tiếp trên chain ($5.014.570 so với $1.286.386).27/07/2026 · C1 · DefiLlama báo phí Uniswap v4 cao hơn 3,9 lần — và bản sửa mới chỉ chạy một chiều
GHIM TẠIRobinhood chain · block #10.808.643 → #11.671.782 (trọn ngày 16/07 UTC)
ĐIỀU GÌ BÁC BỎ CLAIM NÀYDefiLlama đã nói sẽ tính lại ngày 16/07. Tôi ghi trước con số mục tiêu là $1,286M. Kết quả tính lại rơi trong khoảng $1,157M–$1,415M (±10%) ⇒ phép đo của tôi được chính đối tượng xác nhận. Rơi NGOÀI khoảng đó ⇒ tôi kiểm lại phép đo của mình trước, chưa kết luận bên nào sai.
ĐÃ BỊ BÁC BỎTrong chuỗi phí v4 có một cú tụt do ĐỔI CÁCH TÍNH, không phải do thị trường — ước tính ban đầu khoảng 1,63× sau khi chuẩn hoá theo v3.27/07/2026 · C2 · DefiLlama báo phí Uniswap v4 cao hơn 3,9 lần — và bản sửa mới chỉ chạy một chiều
GHIM TẠISố của DefiLlama, một lần đọc duy nhất 27/07/2026 06:32Z · so 7 ngày trước bản sửa với 2 ngày sau
ĐIỀU GÌ BÁC BỎ CLAIM NÀY🔁 Điều bác bỏ này đã được THAY ngày 28/07 vì bản cũ hỏng — nguyên văn bản cũ và lý do thay nằm trong nhật ký ngay dưới. Bản thay: DefiLlama đã công bố sẽ tính lại 08→24/07. Khi có ít nhất 3 ngày trong nhóm 17–23/07 được tính lại, tôi lấy trung vị của (số cũ ÷ số mới) trên đúng những ngày đó. Trung vị ≤1,1× ⇒ cách tính không phải nguyên nhân ⇒ claim này ĐỔ. Trung vị ≥1,3× ⇒ claim đứng. Rơi giữa 1,1× và 1,3× ⇒ hướng đúng nhưng độ lớn 1,63× của tôi bị thổi ⇒ tôi ghi lại con số đúng và đánh dấu claim này là ĐÃ SỬA. Còn nếu tới 30/09/2026 vẫn chưa đủ 3 ngày, tôi ghi CHỜ SỐ — không ghi là đúng.
ĐÃ SỬABản sửa của DefiLlama chỉ áp dụng cho dữ liệu từ 24/07 trở đi; lịch sử trước đó chưa được tính lại.27/07/2026 · C3 · DefiLlama báo phí Uniswap v4 cao hơn 3,9 lần — và bản sửa mới chỉ chạy một chiều
GHIM TẠIĐọc API 27/07/2026 06:32Z
ĐIỀU GÌ BÁC BỎ CLAIM NÀYCon số ngày 16/07 trong chuỗi công khai của DefiLlama đổi khỏi $5.014.570 ⇒ họ đã tính lại ⇒ claim này chuyển sang ĐÃ SỬA và C1 có kết quả.
ĐÃ SỬATrong khoảng tính lại DefiLlama đã chốt (08→24/07, 17 ngày), tới 28/07 01:57Z đúng MỘT ngày đã đổi số — ngày 16/07. 16 ngày còn lại giống ảnh chụp hôm trước tới từng đơn vị.27/07/2026 · C5 · DefiLlama báo phí Uniswap v4 cao hơn 3,9 lần — và bản sửa mới chỉ chạy một chiều
GHIM TẠIHai lần đọc chuỗi công khai của DefiLlama: 27/07 06:32Z và 28/07 01:57Z · block đối chiếu của ngày 16/07: #10.808.643 → #11.671.782
ĐIỀU GÌ BÁC BỎ CLAIM NÀYĐọc lại chuỗi công khai. Nếu từ 2 ngày trở lên trong khoảng 08→24/07 đổi khỏi con số ghi ở đây, câu 'mới sửa được một ngày' hết hạn ⇒ tôi ghi ngày và sửa dòng này. Nếu tới 30/09/2026 mà 16 ngày kia vẫn y nguyên, tôi ghi rằng khoảng tính lại đã được công bố nhưng chưa chạy — không ghi rằng họ từ chối, vì tôi không biết điều đó.
ĐÃ SỬAĐiều bác bỏ tôi tự viết cho claim C2 bị hỏng: nó có thể được coi là đã chạy trong khi bên kia không làm gì cả.27/07/2026 · C6 · DefiLlama báo phí Uniswap v4 cao hơn 3,9 lần — và bản sửa mới chỉ chạy một chiều
GHIM TẠIBản cũ đăng 27/07 cùng bài này · phát hiện và thay 28/07 01:57Z sau khi so hai lần đọc chuỗi
ĐIỀU GÌ BÁC BỎ CLAIM NÀYKhông có — đây là lỗi của chính tôi trong cách viết một phép thử, không phải một khẳng định về thế giới. Bản thay nằm ngay ở C2 phía trên, và bản thay đó thì có điều bác bỏ thật kèm hạn chót.
ĐÃ SỬATrong issue gốc, tôi gọi sai tên cơ chế bảo vệ adapter v2/v3 — viết từ trí nhớ thay vì tra lại code.27/07/2026 · C4 · DefiLlama báo phí Uniswap v4 cao hơn 3,9 lần — và bản sửa mới chỉ chạy một chiều
GHIM TẠIComment đính chính 26/07/2026 07:19:24Z
ĐIỀU GÌ BÁC BỎ CLAIM NÀYKhông có — đây là lỗi của chính tôi, đã tự nhận và đính chính công khai. Mục này giữ lại để người đọc thấy lỗi, không phải để xoá nó.
Không có claim khớp bộ lọc này.