Tỷ lệ funding Bitcoin chỉ thắng lần thanh toán trước trong ba giờ cuối

Tóm tắt. Tỷ lệ funding Bitcoin mà một sàn hiển thị giữa hai lần thanh toán là một trung bình động vẫn tiếp tục dịch chuyển cho tới đúng mốc thanh toán, và nếu đọc sớm thì nó gần như không cho bạn biết thêm điều gì bạn chưa biết. Đo trên Binance, Bybit, OKX và Bitget qua 496 lượt thanh toán theo sàn từ 2026-06-27 00:00 UTC đến 2026-08-08 08:00 UTC, một lần đọc lấy trước bốn giờ mang dấu ngược với tỷ lệ thực sự được thanh toán trong 70 trên 496 trường hợp (14,1%). Mốc so sánh đáng kể không phải là số 0 mà là phương án lười nhất: chỉ cần giả định tỷ lệ vẫn nằm nguyên chỗ nó đã thanh toán lần trước thì sai 79 trên 496 lần (15,9%), và lần đọc trước bốn giờ không thắng được nó (p = 0,33). Màn hình chỉ tách khỏi quy tắc đó trong vòng ba giờ, và khoảng cách sau đó nới ra rất nhanh: 43 so với 23 ở ba giờ (p = 0,019), 55 so với 14 ở hai giờ, 71 so với 5 ở một giờ. Lý do nằm trong chính công thức các sàn công bố, nơi các mẫu phần bù có trọng số càng lớn khi càng gần mốc thanh toán, nên ở thời điểm mở cửa sổ bốn giờ mới chỉ có 25% trọng số của con số cuối cùng được tích lũy. Sai số cũng không trải đều. Chúng nằm gần như trọn vẹn ở những lượt thanh toán kết thúc sát 0, và ở đó một lần đọc chưa phải là tín hiệu cho tới khi được thanh toán.

Con số funding bạn thấy giữa hai lần thanh toán là gì?

Đó là một trung bình động nhắm tới mốc thanh toán kế tiếp, không phải tỷ lệ bạn vừa bị tính lần trước, và hai lần gọi cách nhau hai mươi bảy phút là đủ để thấy nó dịch chuyển. Đọc ẩn danh vào 2026-08-08 lúc 08:37 UTC rồi lại lúc 09:04 UTC, cả hai đều nằm trong chu kỳ thanh toán lúc 16:00 UTC, cả bốn đều đã dịch chuyển: Binance từ +0,006616% lên +0,006820%, OKX từ +0,004511% lên +0,004951%, Bybit từ +0,010000% xuống +0,008352%, và Bitget từ +0,000100% xuyên thẳng qua 0 xuống -0,000200%. Bây giờ hãy đặt tám lần đọc đó cạnh những gì chính các sàn ấy đã thực sự tính ở mốc 08:00 sáng hôm đó, tức là +0,00542% trên Binance, +0,00356% trên OKX, +0,00389% trên Bybit và -0,00010% trên Bitget. Không một lần nào trong tám lần bằng đúng tỷ lệ đã thanh toán của sàn mình, và trên Bitget con số mà một độc giả sẽ trích dẫn đã đảo dấu chỉ trong nửa giờ.

Hai trong bốn sàn nói điều này trong tài liệu của chính họ, và điều đó đáng trích dẫn vì nó có nghĩa bài viết này mô tả hành vi đã được ghi nhận chứ không cáo buộc điều gì. Tài liệu tham chiếu REST API của OKX gọi trường này là tỷ lệ dự báo cho kỳ thanh toán sắp tới, nói thẳng rằng đó là một dự báo và tỷ lệ thanh toán cuối cùng có thể khác, đồng thời đưa giá trị thực sự được thanh toán ra thành một trường riêng trên cùng điểm cuối, settFundingRate, kèm cờ settState; điểm cuối lịch sử mang chính giá trị đã thanh toán đó dưới một tên thứ ba, realizedRate. Kênh WebSocket của cùng sàn lại gọi chính trường đó là tỷ lệ hiện tại, nghĩa là sàn không nhất quán với chính mình, nhưng tài liệu REST mới là nơi ghi nhận sự phân biệt này. Trung tâm trợ giúp của Bybit viết rằng tỷ lệ funding mà nhà giao dịch nhìn thấy dao động theo thời gian thực cho tới mốc funding, rằng nó không cố định và được cập nhật mỗi phút. Trường của Binance mang tên lastFundingRate, nghe như điều ngược lại, và lần đọc ở trên giải quyết sự mơ hồ đó: nó không bằng lần thanh toán 08:00 UTC.

Hãy giới hạn điều này ở các sàn được đo, vì quy ước không phải là phổ quát. BitMEX ghi nhận cách sắp xếp ngược lại, lấy giá trị chỉ số phần bù ở cuối cửa sổ tám giờ TRƯỚC ĐÓ, nghĩa là khoản thanh toán sắp tới đã được ấn định trước cả khi kỳ mà nó áp dụng bắt đầu. BitMEX vẫn lấy trung bình, nên thứ bị đảo là độ trễ chứ không phải phép trung bình. Tài liệu lý thuyết về hợp đồng vĩnh cửu phần lớn cũng giả định thiết kế đó và coi khoản funding là đã biết ngay đầu kỳ. Chính vì vậy mà câu hỏi này đáng được đo trên những sàn người ta thực sự giao dịch thay vì được mặc định.

Bản thân cơ chế không mới và chúng tôi đã từng viết về nó. Thành phần phần bù được lấy mẫu nhiều lần rồi lấy trung bình trên toàn chu kỳ, nên con số phản ánh một cửa sổ mẫu chứ không phải khoảnh khắc hiện tại, đúng như bài giải thích của Athenum về cách chỉ số phần bù giữ hợp đồng vĩnh cửu bám vào giá giao ngay trình bày, và bài phân tích của Athenum về chính công thức funding mổ xẻ phần số học. Những gì tiếp theo không phải là kể lại cơ chế đó. Đó là phép đo xem nó khiến một độc giả hành động sớm phải trả giá bao nhiêu.

Bốn sàn này có chung một đồng hồ thanh toán không?

Với hợp đồng vĩnh cửu Bitcoin, vào ngày được đo thì có, và mỗi sàn đều nói vậy trên điểm cuối công khai của chính mình. Mọi trường bên dưới đều được đọc ẩn danh vào 2026-08-08, và chúng thống nhất ở chu kỳ tám giờ với các mốc lúc 00:00, 08:00 và 16:00 UTC. Điều này quan trọng vì một khoảng thời gian đọc trước chỉ so sánh được giữa những sàn thanh toán trên cùng một đồng hồ, và đó là điều đầu tiên cần xác nhận trước khi đặt bất kỳ hai con số funding nào cạnh nhau.

Ba lưu ý cho bảng này. Đây là hợp đồng vĩnh cửu Bitcoin của từng sàn chứ không phải mọi hợp đồng họ niêm yết, trong đó một số chạy chu kỳ bốn giờ và một giờ. Từ mà các sàn dùng là mặc định, nên tám giờ là trường hợp thông thường chứ không phải một bảo đảm: OKX và Bybit đều ghi nhận việc tự động chuyển sang thanh toán dày hơn khi tỷ lệ chạm trần hoặc sàn của nó, trong đó OKX hạ từng bậc một qua bốn giờ và hai giờ xuống một giờ, còn Bybit chuyển thẳng sang hằng giờ. Và Hyperliquid là đối chứng hữu ích trong bảng này, vì phản hồi của nó còn mang cả chu kỳ của các sàn khác, trả về một giờ cho chính nó và tám giờ cho cả Binance lẫn Bybit trong cùng một phản hồi, nên đồng hồ được một bên thứ ba xác nhận chứ không chỉ do mỗi sàn tự nói về mình. Một lưu ý cho dòng đó: trường chu kỳ có mặt trong phản hồi trực tiếp nhưng không xuất hiện trong tài liệu đã công bố của Hyperliquid, vậy nên hãy coi nó là quan sát lúc chạy chứ không phải một cam kết đã ghi nhận, và hãy đọc mọi chu kỳ từ API thay vì mặc định rằng nó cố định.

Sau đó Hyperliquid bị loại khỏi nghiên cứu vì một lý do kỹ thuật: mọi khoảng đọc trước được kiểm ở đây, từ một giờ tới bảy giờ, đều bằng hoặc vượt toàn bộ chu kỳ funding của nó, nên "bốn giờ trước khi thanh toán" không phải là câu hỏi đặt ra được trên đồng hồ một giờ. Deribit bị loại vì lý do mà một bài viết trước đây của Athenum về chi phí hợp đồng vĩnh cửu đã nêu, rằng funding của nó cập nhật liên tục chứ không theo một đồng hồ cố định. Chúng tôi cũng đã bàn riêng chuyện các con số niêm yết thô không so sánh được giữa những đồng hồ khác nhau, và hướng dẫn của Athenum về chu kỳ funding trình bày điều đó. Bài này làm sắc thêm hướng dẫn ấy thay vì lặp lại nó: tỷ lệ không chỉ thay đổi ở mốc thanh toán, nó trôi suốt cả quãng đường tới đó, nghĩa là một lần đọc giữa chu kỳ như loại mà hướng dẫn kia lập bảng vẫn chưa phải là tỷ lệ sẽ bị tính cho bất kỳ ai.

Đọc sớm có hơn việc chỉ giả định không có gì thay đổi không?

Chỉ trong vòng ba giờ, tức là lần đọc ba giờ trở đi, và đó là phát hiện. Một tỷ lệ sai dấu trần trụi tự nó là kết quả yếu, vì phép so sánh trung thực không phải là với tung đồng xu mà là với quy tắc lười nhất có thể: bỏ qua hoàn toàn màn hình và giả định tỷ lệ sẽ thanh toán đúng chỗ nó đã thanh toán lần trước. Trên cùng 496 lượt thanh toán ấy, quy tắc đó sai 79 lần, tức 15,9%. Mọi lần đọc từ bốn giờ trở về trước đều nằm ngang bằng nó về mặt thống kê.

Chỉ những lượt thanh toán mà màn hình và quy tắc lần thanh toán trước bất đồng, để các trường hợp trùng khớp không thổi phồng bên nào. Trong vòng ba giờ, màn hình thắng các bất đồng một cách dứt khoát. Từ bốn giờ trở về trước, hai bên hòa nhau về mặt thống kê, và tới bảy giờ thì quy tắc nhỉnh hơn trên danh nghĩa, 22 so với 19.

Kiểm theo cặp trên cùng những lượt thanh toán ấy, sự phân tách rất sạch. Trong giờ cuối, màn hình đúng còn quy tắc sai 71 lần, so với 5 lần theo chiều ngược lại, một kiểm định dấu hai phía chính xác với p dưới 0,001. Ở hai giờ là 55 so với 14, cũng dưới 0,001. Ở ba giờ là 43 so với 23, p = 0,019, vẫn còn tách. Ở bốn giờ là 38 so với 29, p = 0,33, không còn tách nữa. Ở bảy giờ, quy tắc nhỉnh hơn trên danh nghĩa, 22 so với 19.

Thứ giúp ích chính là đọc muộn hơn, và chiều hướng chỉ có một. Số lượt thanh toán sai ở bốn giờ trước nhưng đúng trong giờ cuối là 57. Theo chiều ngược lại, đúng ở bốn giờ và sai ở một giờ, không có trường hợp nào. Kiểm định theo cặp trên phép so sánh đó trả về p dưới 0,001. Trong cửa sổ này không có lấy một trường hợp nào mà chờ đợi khiến bạn mất dấu.

Một lần đọc sớm mang dấu sai thường xuyên đến mức nào?

Trong 70 trên 496 lượt thanh toán ở bốn giờ trước, và 13 trên 496 khi đọc trong giờ cuối. Bảng dữ liệu gồm bốn sàn được theo dõi tại cùng 124 mốc thanh toán, giới hạn ở những mốc có một lần đọc dùng được tại mọi khoảng đọc trước từ một tới bảy giờ và có một lần thanh toán trước đó để đối chiếu, nên mọi dòng bên dưới đều có cùng mẫu số 496.

Cột trọng số là tính ra chứ không phải đo được, và nó đến từ chính công thức các sàn công bố. Cả bốn, đối với hợp đồng tám giờ được đo ở đây, đều công bố một trung bình chỉ số phần bù có trọng số theo thời gian, trong đó mẫu càng gần mốc thanh toán càng nặng, và cả bốn đều công bố thẳng các hệ số: mẫu đầu tiên tính một lần, mẫu thứ hai hai lần, mẫu cuối cùng n lần. Phạm vi áp dụng rất quan trọng: Binance chỉ áp trọng số đó cho các chu kỳ dài hơn một giờ và dùng trung bình cộng không trọng số cho các mã một giờ của mình, nên cột bên dưới là một khẳng định về hợp đồng tám giờ chứ không phải về funding nói chung. Số mẫu cũng không giống nhau: Binance và Bitget lấy trung bình 5.760 mẫu cách nhau năm giây, còn Bybit và OKX lấy trung bình 480 mẫu mỗi phút một lần. Khác biệt đó không quan trọng ở đây, vì phần đã cố định của con số cuối cùng bằng tổng các trọng số tới thời điểm hiện tại chia cho tổng chung, và với trọng số tuyến tính thì con số đó rất gần bình phương của tỷ lệ chu kỳ đã trôi qua. Đi được nửa đường thì một phần tư con số đã được viết: 25,05% với 480 mẫu và 25,00% với 5.760 mẫu, giống nhau tới hàng phần trăm nguyên. Trước bảy giờ thì dưới 2%. Một con số mà ba phần tư còn chưa được viết ra thì không phải là dự báo để ai đó hành động, và sai số đo được bám sát đường cong ấy.

Hai giới hạn trung thực với 496 lượt này. Đó là bốn sàn được theo dõi tại cùng 124 mốc, không phải 496 lần rút độc lập. Ở khoảng bốn giờ, các lần đảo dấu phân bố theo mốc như sau: 73 mốc không có lần nào, 34 mốc có một sàn, 16 mốc có hai, không mốc nào có ba, và 1 mốc cả bốn cùng đảo; trường hợp cuối gần như bất khả nếu giả định độc lập, nên các khoảng ở trên là lạc quan chứ không phải thận trọng. Và chuỗi theo giờ có hai lỗ hổng trong cửa sổ: sáu giá trị theo giờ bị thiếu vào 2026-07-01 ở ba trong bốn sàn và bảy giá trị ở Bitget, nơi lỗ hổng mở sớm hơn một giờ, và hai mươi mốt giá trị bị thiếu trong một đoạn gián đoạn hai mươi hai giờ từ 2026-07-31 03:00 UTC đến 2026-08-01 01:00 UTC. Hai lỗ hổng đó cùng nhau làm mất bốn mốc thanh toán. Mốc thứ năm mất ở ngay đầu nguồn dữ liệu, mà dòng theo giờ sớm nhất là 2026-06-26 14:00 UTC, nên mốc lúc 16:00 hôm ấy không có bảy giờ lịch sử phía sau. Vì vậy có 129 mốc rơi vào phạm vi nguồn dữ liệu và 124 mốc còn lại trong bảng.

Sai dấu tập trung ở đâu?

Gần như trọn vẹn ở những lượt thanh toán kết thúc sát 0, và đây là điều hữu ích nhất trong cả bài. Chia cùng 496 lượt đó tại trung vị của tỷ lệ thanh toán tuyệt đối, 0,0048% mỗi tám giờ, và hai nửa hành xử hoàn toàn khác nhau. Ở nửa lớn, dấu đúng trong cả 248 trường hợp đọc trong giờ cuối và cả 248 trường hợp đọc ở hai giờ. Ở nửa nhỏ, dấu sai 13 lần ở một giờ và 65 lần ở bốn giờ.

Cùng 496 lượt thanh toán, chia tại trung vị của độ lớn đã thanh toán. Ở nửa lớn, dấu đúng trong cả 248 trường hợp ở một giờ và cả 248 ở hai giờ. Tới bảy giờ thì ngay cả nửa lớn cũng sai 13 lần, nên đây là một dốc chuyển chứ không phải một bảo đảm.

Ở khoảng bốn giờ, con số là 26,2% so với 2,0%, tách nhau với p hai phía chính xác dưới 0,001. Khoảng cách này giữ nguyên ở mọi khoảng đọc trước được kiểm và vẫn còn ở giờ cuối, nơi 13 trên 248 so với 0 trên 248 cho p = 0,0002.

Đó là quy tắc đáng mang theo, và nó hữu ích hơn cái tiêu đề đã sinh ra nó. Một lần đọc funding ở xa 0 có thể dùng được từ nhiều giờ trước; một lần đọc sát 0 chưa phải tín hiệu cho tới khi được thanh toán. Hãy để ý lưu ý này cắt theo chiều nào. Nó làm con số bớt đáng ngại đi chứ không phải đáng ngại hơn, vì những lượt thanh toán mà lần đọc sớm đánh lừa bạn cũng chính là những lượt mà sai lầm tốn ít nhất.

Sàn bạn dùng có làm thay đổi câu trả lời không?

Ở số đếm thô thì có, và câu trả lời trung thực cần hai bước chứ không phải một. Ở khoảng bốn giờ, số đếm là Binance 9 trên 124, OKX 15 trên 124, Bybit 23 trên 124 và Bitget 23 trên 124. Binance tách khỏi cả Bybit lẫn Bitget với p Fisher chính xác bằng 0,013. Khoảng tin cậy chồng lấn không phải là một phép kiểm định, và với 124 lượt thanh toán mỗi sàn thì thứ tự này không phải nhiễu.

Tỷ lệ sai dấu ở khoảng bốn giờ, theo sàn, kèm khoảng Wilson 95 phần trăm. Cột trái của mỗi cặp là toàn bộ 124 lượt thanh toán, cột phải chỉ gồm các lượt sát 0 của sàn đó. Binance thắng Bybit và Bitget trên tập đầy đủ với p = 0,013, và một khi cả hai bị giới hạn ở các lượt sát 0 của mình thì không cặp nào trong sáu cặp còn tách nhau, p nhỏ nhất là 0,073.

Nhưng thứ tự đó không phải là sự thật về màn hình, và đối chứng cho thấy điều này chính là cơ chế sát 0 ở phần trên. Một sàn mà funding hiếm khi tiến gần 0 thì không thể tạo ra nhiều lỗi dấu. Lấy từ chính lịch sử thanh toán của mỗi sàn, không có dữ liệu Athenum nào tham gia: funding Bitcoin của Binance chỉ nằm dưới trung vị gộp trong 42 trên 124 lượt, so với 77 ở Bybit, 66 ở OKX và 63 ở Bitget; và Binance dương ở 123 trên 124 mốc với tỷ lệ tuyệt đối trung vị 0,00585% so với 0,00380% của Bybit. Binance đã có sáu tuần dễ thở hơn, và lặp đi lặp lại.

Vậy hãy điều kiện hóa trên các trường hợp khó. Giới hạn mỗi sàn ở chính các lượt sát 0 của nó rồi so sánh cùng loại với cùng loại: Binance 7 trên 42, OKX 14 trên 66, Bitget 21 trên 63, Bybit 23 trên 77. Không một cặp nào trong sáu cặp so sánh tách nhau, p nhỏ nhất là 0,073. Khoảng cách giữa các sàn là sự thật về chỗ mà funding của mỗi sàn đã nằm, không phải về chất lượng con số nó đưa lên màn hình, và ai xếp hạng bốn sàn này theo cột thô là đang xếp hạng một trạng thái thị trường.

Còn hai điều đo được nữa đẩy về cùng hướng. Cả 124 tỷ lệ đã thanh toán của Bitget ở đây đều là bội số chính xác của 0,000001, tức sáu chữ số thập phân, trong khi Binance và Bybit công bố tám và OKX tới mười hai, nên ở sát 0 một lưới thô hơn có thể đẩy một tỷ lệ qua vạch chỉ nhờ làm tròn. Và các sàn không lấy mẫu giống nhau, nên đây không phải một con số được đo theo bốn cách: Binance và Bitget lấy mẫu mỗi năm giây trong khi Bybit và OKX lấy mỗi phút một lần. Sự phân đôi ấy mới hơn vẻ ngoài của nó. Bitget thông báo vào 2026-07-02 rằng sẽ chuyển từ một phút sang năm giây kể từ 2026-07-10 theo UTC+8, tùy thuộc vào việc triển khai thực tế, và ngày đó rơi vào bên trong cửa sổ này, nên màn hình của nó không hành xử giống nhau trong hai tuần đầu của bảng và trong bốn tuần cuối. Bitget cũng là sàn mà kết quả ba giờ mạnh nhất khi xét riêng, nên hãy đối xử với đúng dòng đó thận trọng hơn so với con số gộp.

Còn một lưu ý nữa thuộc về phần này chứ không phải một chú thích cuối trang, vì nó cắt ngược lại tiêu đề. Chân trời ba giờ là một kết quả gộp, và 124 lượt thanh toán của riêng một sàn không thể tự mình thiết lập nó. Ở khoảng ba giờ, màn hình thắng quy tắc lần thanh toán trước 18 trên 7 ở Bitget (p = 0,043), 13 trên 6 ở OKX (p = 0,17) và 12 trên 7 ở Bybit (p = 0,36), còn ở Binance thì nó thua, 0 trên 3. Ở khoảng bốn giờ, quy tắc lười của Binance thắng chính màn hình của nó 7 trên 0 (p = 0,016). Đó chính là điều một giai đoạn một chiều gây ra: khi funding của một sàn gần như không bao giờ vượt qua 0 thì giả định không có gì thay đổi là một quy tắc xuất sắc, và một ước lượng đang trôi chỉ có thể thêm sai sót. Tuy vậy kết quả gộp không dựa vào Binance. Bỏ hẳn nó ra, ba sàn còn lại vẫn tách ở ba giờ, 43 trên 20 với 372 lượt thanh toán (p = 0,005). Hãy đọc chân trời này như một khẳng định về bốn sàn cộng lại, không phải một lời hứa về bất kỳ màn hình đơn lẻ nào.

Mức sai lệch bao nhiêu, chứ không chỉ dấu?

Xa hơn, và nó xấu đi đều đặn. Khoảng cách tuyệt đối trung vị giữa lần đọc và tỷ lệ đã thanh toán là 0,036 điểm cơ bản trong giờ cuối, 0,140 ở ba giờ và 0,180 ở bốn giờ, so với các tỷ lệ đã thanh toán mà độ lớn trung vị của chính chúng là 0,48 điểm cơ bản. Nói cách khác, một lần đọc trước bốn giờ thường lệch hơn một phần ba độ lớn của một tỷ lệ thanh toán điển hình, và đó là một sai lệch lớn trên một con số nhỏ.

Sai số tuyệt đối tính theo điểm cơ bản, trung vị kèm dải từ phân vị 25 đến 75. Cố ý trình bày ở dạng tuyệt đối: nếu tính theo tỷ lệ phần trăm của tỷ lệ đã thanh toán thì cùng sai số ấy trông khổng lồ chỉ vì tỷ lệ đó thường sát 0.

Đây là cố ý dùng số tuyệt đối. Chia sai số cho một tỷ lệ thanh toán thường xuyên sát 0 sẽ tạo ra những con số phần trăm lên tới hàng trăm và tâng bốc luận điểm thay vì kiểm nghiệm nó. Tính theo điểm cơ bản thì cách đọc tỉnh táo hơn: ở khoảng bốn giờ, nửa giữa của các lần đọc lệch trong khoảng 0,065 đến 0,339 điểm cơ bản, và ngay cả trong giờ cuối nửa giữa vẫn lệch trong khoảng 0,013 đến 0,072.

Lượt thanh toán hôm nay thực sự trông thế nào?

Giống như một sàn vượt qua 0 đúng bằng cả bề rộng con số trong ba giờ cuối, một sàn thứ hai chạm nhẹ vào nó, và chỉ một trong bốn sàn không hề tới gần. Tiến tới 2026-08-08 08:00 UTC, tỷ lệ vĩnh cửu Bitcoin đang chạy của Bybit đọc -0,00665% ở bảy giờ trước và vẫn còn -0,00162% ở bốn giờ trước, cả hai đều nói phe short sẽ trả, rồi chuyển sang +0,00009% ở ba giờ trước và thanh toán ở +0,00389%, tức phe long trả. Người nào hành động theo màn hình bốn giờ đã hiểu ngược chiều.

Lượt thanh toán 2026-08-08 08:00 UTC. Mỗi đường là tỷ lệ đang chạy của một sàn, lấy trung bình trên giờ bắt đầu trước mốc thanh toán đúng ngần ấy giờ, còn dấu rỗng lớn là con số sàn thực sự đã tính. Đọc ở bốn giờ trước, chỉ Bybit sai dấu, và sai đúng bằng cả bề rộng con số.

Ba sàn còn lại thì bình thường. Binance đọc +0,00434% ở bảy giờ trước và tính +0,00542%, tức đúng dấu suốt cả quãng nhưng thấp hơn một phần năm so với mức đã tính. OKX đọc +0,00210% ở bảy giờ trước, tụt xuống -0,00008% ở năm giờ trước, ở khoảng đó là một lỗi dấu rộng bằng một lần làm tròn, rồi tính +0,00356%. Bitget đọc -0,00226% ở bảy giờ trước và tính -0,00010%, đúng dấu nhưng gần như bằng 0, và đó đúng là chế độ sát 0 nơi dấu mang ít thông tin nhất.

Để có một mốc so sánh ở cùng thời điểm, dòng theo giờ hoàn chỉnh cuối cùng trước mốc đó, 07:00 UTC ngày 2026-08-08, mang giá Bitcoin ở $64.956,24. Chúng tôi cố ý không đặt một con số hợp đồng mở gộp bên cạnh: bài viết của Athenum về việc hợp đồng mở đếm một phía hay cả hai đã cho thấy một tổng thô liên sàn cao hơn khoảng 20%, vì một số sàn đếm cả hai vế của mỗi hợp đồng, và không có chỗ nào trong bài này cần con số đó. Hyperliquid niêm yết +0,00045% ở dòng đó trên đồng hồ một giờ của mình, vốn không cùng thang đo với các sàn kia và không nên xếp cạnh chúng.

Bạn tự kiểm chứng điều này thế nào?

Mọi dữ liệu đầu vào đều công khai và không thứ nào cần tài khoản.

1. Lấy chuỗi đã thanh toán. Binance fapi/v1/fundingRate, Bybit v5/market/funding/history, OKX api/v5/public/funding-rate-history với giá trị đã thanh toán là realizedRate, Bitget api/v2/mix/market/history-fund-rate. Mỗi cái trả về các lượt thanh toán Bitcoin trong cửa sổ của bạn. 2. Theo dõi một con số dịch chuyển. Gọi điểm cuối funding trực tiếp của bất kỳ sàn nào hai lần, cách nhau hai mươi phút, trong cùng một chu kỳ. Nếu hai giá trị khác nhau thì tỷ lệ mà sàn đó hiển thị không phải tỷ lệ nó vừa tính lần trước. 3. Xác nhận đồng hồ trước khi so sánh bất cứ điều gì. Lấy các trường chu kỳ trong bảng ở trên. Một sàn chạy đồng hồ một giờ không thể đặt cạnh một sàn tám giờ nếu không quy đổi cả hai, và công cụ tính tỷ lệ funding miễn phí của Athenum có sẵn bộ chọn tám giờ, bốn giờ và một giờ đúng cho việc đó. 4. Ghi lại khoảng đọc trước cùng mỗi lần đọc. Cột hữu ích nhất không phải là tỷ lệ, mà là còn bao nhiêu giờ nữa tới mốc thanh toán khi bạn ghi lại nó. 5. Đối chiếu với quy tắc lười, đừng đối chiếu với 0. Một phương pháp thắng được "cứ giả định nó nằm nguyên chỗ đã thanh toán lần trước" mới có giá trị. Trong cửa sổ này chỉ những lần đọc trong vòng ba giờ làm được điều đó. 6. Kiểm khoảng cách tới 0 trước khi tin vào dấu. Trên mức 0,0048% mỗi tám giờ về độ lớn, dấu đúng trong cả 248 lần đọc ở một giờ và cả 248 lần ở hai giờ. Dưới mức đó, một phần tư số lần đọc bốn giờ là sai. 7. Điều kiện hóa trước khi xếp hạng. Nếu một sàn trông có vẻ tốt hơn sàn khác, hãy kiểm xem funding của nó có đơn giản là nằm xa 0 hơn trong cửa sổ của bạn hay không. Ở đây điều đó giải thích trọn vẹn khoảng cách.

Ba giới hạn đáng nói ra thay vì chôn đi. Dòng theo giờ của Athenum là một trung bình trên chính giờ đó chứ không phải một mẫu tức thời, điều chúng tôi xác định bằng cách theo dõi dòng mới nhất dịch chuyển trong khi mọi dòng đã hoàn tất giữ nguyên trong phạm vi nhiễu dấu phẩy động, nên mọi khoảng đọc trước ở trên là một cửa sổ dài một giờ được đặt tên theo lúc nó mở, chứ không phải một lát cắt đúng vào thời điểm đó. Bảy khoảng đọc trước đã được kiểm với cùng một mốc so sánh, và tính đa bội đó có ý nghĩa: giữ sai số toàn họ ở mức 5% theo phương pháp Holm thì kết quả ở một giờ và hai giờ vượt qua thoải mái, còn sự tách biệt ở ba giờ không đạt ngưỡng đã hiệu chỉnh. Hai lần kiểm lại có tính đến sự phân cụm đều khớp với con số chưa hiệu chỉnh: bootstrap ở cấp mốc cho khoảng p = 0,017 và kiểm định hoán vị phân cụm theo mốc cho p = 0,022. Vậy kết quả ba giờ là thật nhưng là yếu nhất trong bảy và nên được đọc như một kết quả danh nghĩa. Sáu tuần của một tài sản trên bốn sàn vẫn là một mẫu hạn chế, và các khoảng in ở trên là bề rộng trung thực của nó. Và các mức ở đây thuộc về cửa sổ này: trung vị tỷ lệ thanh toán tuyệt đối 0,0048% mỗi tám giờ chưa bằng một nửa mức 0,01% nằm trong chính công thức của các sàn với vai trò thành phần lãi suất, nên một giai đoạn có xu hướng rõ hơn nhiều khả năng sẽ cho tỷ lệ đảo dấu thấp hơn. Phần bền là hình dạng chứ không phải cái mốc: trong vòng hai giờ màn hình tốt hơn hẳn việc không làm gì, từ bốn giờ trở về trước thì không phân biệt được, và điểm giao nằm quanh ba giờ. Các con số phần trăm chính xác thuộc về cửa sổ này.

Một ghi chú cuối về vị trí của kết quả này, phát biểu hẹp lại vì bản rộng sẽ không thể bác bỏ. Bản thân sự phân biệt giữa dự báo và thực hiện đã được ghi nhận rõ: Coin Metrics và Amberdata đều bán hai chuỗi riêng biệt, và OKX gọi chúng là fundingRate và realizedRate trong API của chính mình. Thứ chúng tôi không tìm được là ai đó công bố độ lớn của khoảng cách, tức một báo cáo nghiên cứu của sàn, một khảo sát của nhà cung cấp dữ liệu hay một bài báo định lượng xem lần đọc đang chạy của một sàn cách bao xa so với tỷ lệ mà sàn đó sau đó tính. Các công trình học thuật gần nhất nhắm vào những câu hỏi lân cận: một bài dự báo tỷ lệ thanh toán kế tiếp từ lịch sử các tỷ lệ đã thanh toán và tự đối chiếu với mốc không thay đổi, một bài khác đo chênh lệch tỷ lệ funding trên hàng chục sàn với hàng chục triệu quan sát. Không bài nào hỏi con số mà chính sàn hiển thị cách bao xa so với tỷ lệ sàn đó sau đó tính, mà ở đây đó là câu hỏi duy nhất. Nếu phép đo như vậy tồn tại, chúng tôi rất muốn được xem. Các con số ở trên là của chúng tôi, và chúng được đặt ra để tính lại chứ không phải để tin.

Không điều gì ở trên cần một terminal dữ liệu trả phí và không điều gì cần xin phép: mọi tỷ lệ đã thanh toán đều đến từ điểm cuối lịch sử công khai của chính sàn đó, còn đường đi theo giờ giữa các mốc đến từ nguồn dữ liệu phái sinh liên sàn trực tiếp của Athenum, và 34 công cụ tính bên cạnh nó dùng thoải mái, không cần tài khoản, không cần email và không có giới hạn sử dụng. Công cụ tính tỷ lệ funding được dẫn ở trên biến một tỷ lệ theo chu kỳ thành tỷ lệ theo năm; nếu bạn muốn đi chiều ngược lại và gộp lãi một tỷ lệ theo năm thì có công cụ tính APR và APY miễn phí của Athenum. Hoặc dùng bản dùng thử Athenum Pro+ 7 ngày miễn phí và xem mốc thanh toán kế tiếp diễn ra thay vì đọc về mốc vừa qua.