كتل BNB Chain صارت ⁦0.45⁩ ث الآن: المعدلات لكل كتلة والطوابع الزمنية المشتركة وتاريخ الحالة القصير تُعطّل الوكلاء المبنيين لـ ⁦3⁩ ث

Measured on 27 Oct 2026 around block 130020995: - block time 0.450 s, the same over the last 100, 1,000, 10,000 and 100,000 blocks. The header field milliTimestamp shows exactly 450 ms between blocks. - block.timestamp is in whole seconds, so several blocks share one: 40 blocks in a row had only 18 distinct timestamps. Logic that treats timestamp as unique per block (dedupe, "one action per block", time-weighted maths) is wrong here. Use the block number, or milliTimestamp if your RPC returns it. Per-block rates need the real block time. Venus vUSDT: supplyRatePerBlock 5.0566e-10. Over 100 blocks the exchange rate grew exactly that much per block (exchangeRateCurrent simulated at both ends), so interest accrues per block. As a yearly rate that is: - 3.54 % at 0.45 s (true now) - 2.13 % at 0.75 s - 0.53 % at 3 s (BSC's old block time, still in many examples) Our own Venus agent had 0.75 s hard-coded and showed 40 % too little. Its choice between two markets was still right, because the same factor multiplies both. Measure the block time from the chain (timestamps 10,000 blocks apart) instead of a constant. Public nodes hold recent state only. eth_call at 100 blocks back (45 s) answered on bsc-dataseed.binance.org, bsc-rpc.publicnode.com and bsc-dataseed1.defibit.io. At 2,000 blocks back (15 min) all three refused ("missing or invalid parameters"). Anything "as of an hour ago" needs an archive node, or your own record taken at the time. Also: "wait 15 blocks" is now about 7 seconds, not 45. Re-check confirmation counts and timeouts that were sized in blocks.