Apex 最佳实践

​

保持连接预热

import threading

import requests

session = requests.Session()  # reuse this session for every send

def keep_warm(stop: threading.Event, url="http://fra.apex.orbitflare.com/ping"):
    while not stop.wait(5):
        session.get(url, timeout=2)

stop = threading.Event()
threading.Thread(target=keep_warm, args=(stop,), daemon=True).start()

​

从靠近 Apex 端点的位置发送

​

根据交易价值确定小费

• 小费为您的 Jito 出价提供资金：出价等于小费减去 5,000 lamports 基础费用。在竞争激烈的区块中，仅达到下限的出价可能会在拍卖中落败。质押加权路径和 TPU 路径仍会运行，但您放弃了三条路径中的一条。
• 您只在交易上链时支付小费，因此为重要交易设置更高的小费，在未上链时不会产生任何费用。
• 让小费与上链的价值成比例。常规转账可以保持在下限。竞争性交易的小费应与抢先上链对您的价值成正比。

​

为每笔交易设置计算预算

• 计算单元上限：在您的常规 RPC 上模拟交易，取其消耗的单元数，再加上约 10% 到 20% 的余量。未设置时的默认上限远高于大多数交易的需要，这会浪费您的优先级。
• 计算单元价格：跟随您所写入账户的市场行情。以您的可写账户调用 getRecentPrioritizationFees 是一个合理的起始参考。
• 将 ComputeBudget 指令放在交易的最前面。
• 以上适用于 legacy 和 v0 交易。交易 v1 改为在消息的 TransactionConfig 中设置预算，ComputeBudget 指令在那里不起作用。

​

确认每一次发送

• 在 Solana RPC 上轮询 getSignatureStatuses，或使用 signatureSubscribe 订阅，直到状态为 confirmed 或 finalized。
• 检查 err 字段。交易可能上链但仍在链上执行失败。小费是交易的一部分，因此执行期间失败的交易也会回滚小费转账，您只需支付网络费用。
• blockhash 过期后停止等待。跟踪 getLatestBlockhash 返回的 lastValidBlockHeight。一旦链超过该高度，交易就永远无法上链。

​

让 Apex 重试，然后重新构建

• 不要循环重发已接受的交易。 这没有任何帮助，还会消耗您的速率限制。
• 使用新的 blockhash。 在签名前一刻以 confirmed 承诺级别获取。一个已经存在一分钟的 blockhash 留给 Apex 的时间非常少。
• blockhash 过期后，重新构建。 获取新的 blockhash，重新签名，并发送新交易。在此之前请确保第一笔交易已无法上链，或者使用即使两笔都执行也安全的逻辑。
• 重试传输失败。 如果发送在收到响应之前失败，请再次发送相同的字节。端点按签名去重。
• 遇到 rate limited 和 busy 时退避。 参见哪些错误可以重试。

​

集成时使用反馈，运行时无需反馈

​

让每笔交易都唯一

​

检查清单