第一次认真看狙击交易的耗时，是因为结果和预期差得有些远。
我们在 Solana Devnet 上创建一个新的流动性池，让两个钱包提前进入监听状态。池子出现，机器人发现机会，随后买入。流程跑通了，但页面上的时间是 13 秒左右。
对于普通交易，这个等待未必难以接受。对于新池狙击，它意味着机器人已经看到了机会，却过了很久才把买单发出去。
于是我们开始一层一层地优化：先改执行流程，再改监听信号，然后去主网验证，最后研究更早的 Preprocessed 和 Raw Shreds。这个过程中，最有意思的发现是：把一个环节从十几秒压到几毫秒，并不代表交易就能在几毫秒内成交。
最初的执行模式叫 Standard。它沿用了比较通用的交易思路：发现机会后，准备信息，完成检查，构造交易，再提交。
几次成功测试里，页面记录的“检测到提交”分别是 13.230 秒、14.098 秒和 9.629 秒，对应的 slot 差分别是 91、139 和 77。早期没有记录完整的分段耗时，所以我们无法把这十几秒全部归到某一次 RPC 查询或数据库操作上。但优化方向已经很清楚：太多工作留到了机会出现以后。
新池狙击有一个有利条件：目标代币、使用哪个钱包、买入多少、能接受多高的价格，往往可以提前确定。既然如此，就没有必要等池子出现，再从头准备。
我们据此做了 Fast 模式。钱包进入监听之前，先完成解锁和授权，检查余额预算，准备代币与账户参数。监听期间，后台持续刷新 blockhash 和优先费。等真正可执行的信号到达，前台路径就只剩下完成交易构造、签名和广播。
发送之前的模拟也被跳过。Solana 广播使用 skipPreflight: true，不再为了预先模拟多等一次处理。价格上限、费用上限和授权约束继续保留，只是尽量使用已经准备好的数据在本地判断。
数据库同样要让出发送路径。监听开始前，可以先建立操作记录；信号触发后，发送不能再排在结果写入之后。交易结果和计时信息放到后台异步保存。
这也让“提前构造交易”有了更具体的含义。能够提前确定的部分尽量准备好，但新池地址、账户组合和最新 blockhash 等内容可能尚未齐备，因此实际仍需要在触发后补齐消息并签名。预热的目标，是让最后这一步尽可能短。
改完以后，最早的 Fast 成功样本显示，检测到开始广播只用了 4ms。随后两只钱包同时测试，分别是 5ms 和 5ms。
从秒级看到毫秒级，确实是明显进步。但继续看链上结果，两笔买单仍然在建池后 29 slots、约 5 秒才进入区块。
这里第一次暴露了测量上的陷阱。页面上的 5ms，只计算机器人已经具备执行条件之后，多久开始发送。它没有包含信号抵达前的等待，也没有包含交易发出后的落块时间。旧版“检测到提交”和新版“检测到开始广播”的边界也不同，不能直接相除，宣称整个交易快了几千倍。
应用里的等待缩短后，下一段等待才变得清楚：我们究竟多早知道池子已经出现？
最初，监听使用 Confirmed 状态。它会等待更强的链上确认。Processed 则在节点已经处理到对应状态时，就可以提供更新。
对于争取新池最早买入的场景，很自然会想到：用 Processed 触发交易，Confirmed 留给后台观察和对账。
这里有两个不同的开关。Fast 决定收到信号后怎么执行，Processed 和 Confirmed 决定什么时候触发。把后者换早，并不会自动消除前者的等待；同样，Fast 也完全可以配合 Confirmed 使用。
我们改成 Processed，再跑了一轮。结果却有点反直觉。
之前单钱包页面曾出现过 11 slots，这次两只 Processed 钱包却都到了 34 slots。如果只看这两个数字，很容易怀疑：信号提前了，为什么交易反而更晚？
继续拆时间线，才发现系统里“看见池子”的时刻并不只有一个。
独立观测流在大约 16:38:47.72 就记录到了池子，但真正用于交易的账号订阅，到 16:38:52.440 才收到对应更新。两者之间相差约 4.72 秒。之后满足执行条件，只用了约 42ms 就开始广播，而 RPC 请求耗时约 76～82ms。
原来，监测模块早看到了，并不意味着执行模块也及时拿到了数据。这一轮最大的已知等待，发生在执行信号到达之前。仅凭这些记录，还不能把全部原因都判给上游推送或本地处理，但至少可以排除“这几秒全花在 RPC 广播上”的解释。
于是优化开始深入监听本身。我们把真正用于交易的订阅接收时间记下来，把“收到更新”和“满足执行条件”分开，再分别记录 Processed、Confirmed 的到达时间，同时检查订阅生命周期、重连和调度。
接下来做对照时，不再只比较不同轮次的总 slot 差，而是让两个钱包监听同一个新池：一个使用 Processed，一个使用 Confirmed。
其中一次优化后的对照，Processed 的执行账号更新比 Confirmed 早到 259ms。最后，Processed 钱包在建池后 28 slots 买入，Confirmed 钱包是 30 slots；应用收到前者买单的 Processed 回执，也比后者早 208ms。
这轮终于看到了从信号领先到买入领先的完整对应关系。
但后面的测试没有一直保持这个结果。另一次同池对照，两单都在建池后 13 slots 买入，Confirmed 买单还排在同一块更靠前的位置。又一次双 Processed 测试，触发到广播只有 11～13ms，建池到买入却用了 54 slots、约 9 秒。
这些结果让我们逐渐接受一个事实：Processed 给了更早执行的机会，最终能不能更早成交，还要看信号实际抵达、应用处理和落块过程。单次最好成绩，不能代表稳定表现。
在 Devnet 上反复测试以后，我们把相同思路带到主网。两只钱包都使用 Fast + Processed，每笔买入 0.001 SOL，先进入监听，再创建新池。
有一轮成功了。池子创建于 slot 447510659，两笔买单都进入 slot 447510667，差 8 slots。按照链上的秒级时间，建池到买入约 3 秒。
这个结果比一些 Devnet 样本更好，但还不足以说明主网更快。真正值得注意的，是这一轮的分段数据。
从账号更新到达，到满足执行条件，花了 1005ms。之后检测到开始广播，又分别用了 198ms 和 199ms。RPC 请求耗时则接近 1.2 秒。
在 Devnet 上已经出现过个位数毫秒的应用路径，到了这一轮主网测试，却出现了接近 200ms 的触发后处理。更前面还有约 1 秒的执行条件等待。下一步应该拆解的，就是这些已经测出来的时间，而不是笼统地把一切解释成主网竞争更激烈。
RPC 的耗时也需要单独看。调用返回并不意味着交易刚刚成交，买单状态通知可能通过另一个订阅通道并行到达。因此，不能把所有字段相加当作总延迟。最终还是要回到买单实际进入哪个 slot，再用分段记录解释它为什么出现在那里。
优先费也是在这时变得更值得讨论。它有助于参与交易调度竞争，但不会替我们缩短本地构造，也不会让一条迟到的监听消息提前抵达。我们的处理方式是后台采样费用，准备好下限和总费用上限，触发时直接使用缓存参数。否则，为了得到一个更“准确”的费用，反而临时等待查询，就可能吃掉信号领先的时间。
不过，主网给我们的下一课并不是费用，而是稳定性。
成功轮之后，又连续两轮出现了相同情况：池子建好了，任务也已经进入监听，两只钱包却都在广播前失败，报授权过期。
深入日志后发现，其中一轮触发时，内部授权租约只剩约 494ms，而构造和签名用了约 792～793ms。等到广播前检查，授权已经过期了将近 300ms。此时交易机会窗口其实还剩约 14.2 秒。
问题出在续租逻辑：任务一触发，旧实现就把它视为已经不需要继续续租；但交易此时还在构造和签名，尚未发出去。续租又依赖完整的后台任务循环，容易被其他工作推迟。
后续本地实现把续租独立出来，让它持续覆盖构造和签名阶段，并预留了 1.5 秒的构造余量。不过，在本文记录范围内，还没有修复后的主网成功复测，所以不能把这个本地修复直接算成已经验证的线上成果。
到这里，评价速度的方式也变了。我们开始同时看成功率和耗时。一次 8 slots、约 3 秒的成功很有价值，但一个偶尔能跑得很快、另一些时候根本发不出去的系统，还远没有完成优化。
做完这些测试，自然会继续往前问：Processed 已经是节点处理后的状态，能不能在它之前就看到建池交易？
这就到了 Preprocessed。
从接收节点的角度看，交易数据会经历接收 shreds、重组与解码、执行或回放、生成状态等过程。Processed 账号订阅要等相应状态出现；Preprocessed 可以在交易内容已经被解码、接收节点尚未完成执行结果生成时交付数据。
对于狙击新池，这意味着有机会先看到建池指令，不必一直等到池子账号状态推送出来。这里的“执行前”描述的是接收节点的处理阶段，不能理解成交易还没被 leader 排序，也不等同于监听以太坊式公共 mempool。
代价是，拿到的数据变了。账号订阅直接给出状态，Preprocessed 给出的是交易内容，通常还没有执行结果、余额变化或完整账号更新。要利用这段提前量，程序需要自己识别建池指令、解析账户和协议参数，再结合预先准备的信息构造买单。这个改动已经超出了切换确认级别的范围。Helius 的接口说明明确区分了这两类数据。
研究服务商时，我们发现，价格和接口版本也需要一起看。截至 2026 年 9 月 17 日，Helius 的 Preprocessed WebSocket 处于 Public Beta，面向所有付费套餐开放，Developer 套餐从 49 美元/月起，按 每条消息 0.1 credits计量。旧的 gRPC 版本则已经提示将弃用。因此，不能继续笼统地说，使用 Helius Preprocessed 就必须买 999 美元的套餐。Helius 定价
另一个选择是 Shyft RabbitStream。它把从 shreds 提取的交易通过 gRPC 交付，Build 套餐为 199 美元/月，更高的 Grow 和 Accelerate 分别为 349 和 649 美元/月。Shyft 定价
QuickNode 的 Blazar 也提供 shredTransactionSubscribe，通过 WebSocket 交付执行前的交易流。不过，我们查阅的产品公告没有给出能够确认的独立价格，实际使用前还需要核实套餐和计费。QuickNode 产品公告
这一阶段最容易引起疑问的数字是：只早 8ms，值得吗？
这个 8ms 来自 Helius 旧 gRPC 文档，含义是相对 Processed 平均提前约 8ms。它不是整个狙击交易的成交改善，也不是新版接口或所有服务商的速度上限。Shyft 则在自己的 Pump.fun 检测测试中给出约 15～100ms 的领先范围。两者条件不同，不能直接排出谁更快。Helius 旧 gRPC 说明、RabbitStream 测速说明
提前几毫秒，可能正好赶上更早的处理机会，也可能仍然进入同一个块。我们还没有完成这类信号的实测，所以不能把服务商的数字写成自己的交易收益。
尤其回头看主网那一轮，前面还有约 1 秒的执行条件等待，后面还有接近 200ms 的触发后处理。如果这些时间没有处理好，新信号争取到的几毫秒，很容易消失在后续流程里。
沿着信号继续往前，下一步就是 Raw Shreds。
Preprocessed 通常已经替用户完成了 shreds 的重组和交易提取。Raw Shreds 则把原始传播碎片直接交付过来，让接收方自己处理。这样一来，服务商在解码、封装和分发上花费的时间，就变成了自己可以争取的空间。
但这也意味着，原本由提供商承担的工作，现在需要自己完成。
需要有持续接收 UDP 的服务，处理重复包和乱序，完成必要的数据恢复，再重组交易、识别建池指令。地址表、交易版本和协议依赖也不能遗漏。最关键的是，从收到第一个包到策略真正能够生成买单，这一整段都要足够快。
否则，可能出现一种尴尬结果：原始包比别人先收到，交易却比使用现成 Preprocessed 服务更晚解析出来。
公开服务中，Helius Raw Shreds 通常是 1000 美元/月/IP，Professional 用户为 800 美元/月/IP。这个费用是 Raw feed 的费用；如果为了优惠新购 999 美元的 Professional，再加一个 Raw seat，总额就是 1799 美元/月。仅购买 Raw 则可以从 Free 套餐加购。Helius Raw Shreds 文档、价格表
DoubleZero Edge 的定价则与接入地区有关，按每台机器每月计算：法兰克福和阿姆斯特丹为 1500 美元，伦敦、纽约、新加坡和东京为 900 美元，其他地区为 450 美元。除了订阅，还需要安装客户端并配置相应网络接入。DoubleZero 订阅说明
过去经常被提到的 Jito ShredStream，也不能直接照搬旧资料。官方公告写明该服务于 2026 年 9 月 5 日关闭，因此在本文整理时已不应作为新的接入选项。Jito 公告
这些都是数据订阅费用，还没有算自有服务器、网络和开发维护。Raw feed 也不负责发送买单，交易广播仍然需要自己的发送路径。
那么，花这笔钱究竟能快多少？
我们还没有 Raw Shreds 实测，因此没有一个可以直接报出的毫秒数，更不能承诺一定减少几个 slots。决定收益的量，是“现在的 Processed 信号已经可用”与“Raw 被自己解码到策略可用”之间的差值。只比较收包时刻，会漏掉后半段成本。
即使策略确实提前了，最终落块还受发送路径、leader 调度、优先费和账户竞争影响。不同提供商之间更大的差距，也可能来自地区、路由和覆盖范围，而非 Raw 这种形式本身。
更合适的下一步，是先不交易，在同一机器上同时接收 Processed、Preprocessed 和 Raw，按同一建池交易对齐。记录策略可用的时刻，观察常见情况和最慢的一批样本，再看是否漏报、断线后多久恢复。这样才能决定，购买更早的信号究竟值不值得。
信号产品本身也在继续演进。Helius 当前还列有可能早于 shreds 的 Preconfirmations，但覆盖依赖参与验证者。它再次提醒我们，“最快”需要带上条件：在哪个地区、覆盖哪些交易、比较哪个处理阶段。官方信号层级说明
回看这段过程，最初面对的是十几秒的应用等待。把准备工作前移、跳过发送前模拟、让数据库退出关键路径，就能带来很明显的改善。
之后，问题变成了信号什么时候真正进入执行模块。Processed 在一次同池对照中带来了约 208ms 的买单回执领先，但也有进入同一块、甚至跨轮结果变差的情况。
到了主网，我们得到过 8 slots、约 3 秒的成功结果，同时发现了新的处理延迟和授权竞态。更早的 Preprocessed、Raw Shreds 仍然值得研究，但它们无法自动修复这些已经存在的等待。
还有一个数字习惯需要改掉：slot 不是固定秒表，也不等于必然产出的区块数量。这些测试里，Devnet 的 34 slots 约为 6 秒，54 slots 约为 9 秒，主网的 8 slots 约为 3 秒。应该使用对应交易的真实时间，而不是统一乘以 400ms。链上的 blockTime 又只有秒级精度，分析几毫秒的领先，还得依靠精确的接收和执行计时。
下一轮优化，我们会先盯住主网里那段约 1 秒的执行条件等待，以及接近 200ms 的触发后处理。把它们解释清楚、缩短，并确认任务能够稳定发出交易之后，再去测量新的信号源究竟还能争取多少时间。