钱包每次报价费率时，背后都有一台不停吞确认历史的估算机。多数用户只见过 estimatesmartfee 那张温和的输出，但同一台机器还有一个不加修饰的出口——estimaterawfee。它的帮助文本开头连着两行警告：接口不稳定、可能消失或改变；这是与估算器内部实现紧耦合的高级调用，参数与返回都会随实现演进而变。把这两行警告读完再决定用不用它，是使用这个命令的正确开场。
两个参数，决定你在问什么
第一个参数 conf_target 是确认目标块数，取值范围 1 到 1008——大约一周的区块数，这是估算器能力边界的直接体现：超过这个窗口的”多少块能确认”它答不了。第二个参数 threshold 是判定阈值，默认 0.95，源码里对它的解释相当精确：在某个费率区间内，必须有至少这个比例的历史交易曾在目标块数内被确认，该区间才算”够高”，然后才继续向下检查更低的区间。换句话说，threshold 控制的是估算器的保守程度——调到 0.99 意味着几乎要求全军覆没式的安全，报价会明显变贵；调低则愿意为省钱承担更多等待风险。智能接口把这个旋钮藏在了 estimatesmartfee 的模式参数里，raw 接口把它直接摊开。
输出：short 与 long 两套地平线
返回结构按地平线分成 short 与 long 两个对象——估算器内部同时维护两条预测线，短线服务近几个块的拥堵预测，长线服务更远的目标，最终由智能接口替你选用其一并附上实际可信的目标块数。每个地平线对象里先有三个描述机器状态的数字：feerate 是该地平线下的费率估计（每千虚拟字节计），decay 是历史确认数据滑动平均的逐块指数衰减系数，scale 是当前地平线对确认目标的分辨率。数值本身没有对错，它们描述的是”这台机器此刻用什么样的记忆曲线在做预测”。
真正有信息量的是 pass 与 fail 两个区间对象。pass 记录”满足阈值的最低费率区间”：startrange 与 endrange 是区间端点，withintarget 是历史上这个费率段里在目标内确认的笔数，totalconfirmed 是这段里最终确认的总笔数，inmempool 是当前内存池中在此费率段、且已滞留超过目标块数的笔数，leftmempool 则是历史上在此费率段但最终不确认就离开了内存池的笔数。fail 记录相反端：最高的不达阈值区间。读这一组的诀窍在于对比：pass 与 fail 相邻很近，说明市场费率梯度陡峭，报价失手代价大；leftmempool 数字大，说明历史上这个价位的单子经常白排队；inmempool 高企，则意味着你的目标块数内还压着别人没消化的同类流量。
它和 estimatesmartfee 的真实关系
智能接口做的其实是三层包装：把 conf_target 映射到合适地平线、跑同一套桶统计、再把”估算不出来时给个保守回退值”的策略叠上。raw 接口跳过全部包装，直接暴露桶状态，所以它连”估算失败”都可能返回——智能接口在这种情况下宁可用 mempool 地板价也不说”不知道”，raw 接口则把不确定性原样交还给你。这正是两行警告的由来：字段形状跟着实现走，版本升级时可能改名、可能挪桶。
什么时候值得承受这种不稳定？三类场景。排查”钱包报价离谱”时，直接看桶数据能区分是历史数据被异常时段污染，还是 inmempool 积压导致目标不可达——这两种病因在智能输出里长得一模一样。写费率监控工具时，pass/fail 边界比单点报价更有预警价值。做策略实验时，threshold 与地平线的组合是智能接口不提供的旋钮。
最后提醒一次边界：估算器统计的是这台节点见过的确认历史，它不是全网预言机；数据新鲜度受 fee_estimates.dat 的保质期与节点运行时长支配。一条只在拥堵后开机的节点，它的所有桶都在从零开始积累，读出来的任何区间都要先问一句：这台机器记起了多少过去？
风险提示：费率估算影响交易成本判断，但不构成任何投资、套利或交易时机建议；接口字段以所运行版本的实现为准，升级后请重新校验解析逻辑。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。