自动化 NFT 市场交易：账户控制

为什么自动化 NFT 市场交易需要共享状态

单项策略即使内部逻辑一致，仍可能与另一项策略冲突。假设两项策略都检查了一个显示有 1 单位可支出货币的钱包，各自独立批准了一笔 0.7 单位的购买。它们分别进行的检查都通过了，但合并后的意图超过了可用资源。

库存也存在同样的问题。两个进程可能看到同一个 NFT，并准备不同的销售。这些指令能否同时执行，取决于资产类型和结算规则；但把它们视为无关操作，会造成不必要的不确定性，也可能留下仍然有效的旧授权。

共享状态并不要求把所有内容做成一项庞大策略，而是需要一个权威、统一的状态来源，用来查询拥有什么、什么已经被承诺，以及还剩什么可用。入门的 NFT 机器人指南 介绍了更广泛的决策生命周期。这里的重点，是防止那些单独看来合理的决策在账户层面相互矛盾。

区分事实、意图和估计

已确认的所有权记录，是有链上证据支持的事实。购买 NFT 的计划是一种意图。基于地板价的估值是一种估计。把它们放在不同字段中，可以防止某个类别悄悄替代另一个类别。

例如，打算卖出一件资产，并不意味着要把它从持有库存中移除。这种意图可能使该资产无法供存在冲突的策略使用，但在销售得到确认之前，该资产仍承受市场变化的风险。同样，估计的销售收入不能仅仅因为挂单已发布，就变成可支出的资金。

账户模型应保留重要事实的来源和观测时间。当证据不完整时，应明确表示这种不完整。空白字段、测得的零值和不确定的结果，不应都被压成同一个值。这些区别既支持安全执行，也有助于在异常情况发生后作出如实解释。

为每个持仓建立稳定身份

仅凭集合名称，不足以识别资产。在受支持的 EVM 路径中，链、合约和代币标识符构成其身份的重要部分。多份版本资产还需要数量。其他网络和 NFT 标准则需要各自的标识符。

当数据从发现环节传到订单提案，再进入账户日志时，应保持身份完整。后续元数据刷新可以更新图像或描述，而无需替换底层资产记录。这样才能调查更名集合、缺失图像或具有误导性的重复名称。

货币身份也值得同等谨慎。两个都显示为 ETH 的余额可能存在于不同网络，不能自动为彼此的交易提供资金。封装资产与原生资产也有不同用途。跨链自动化 NFT 市场交易需要分开的资源账户，即使界面为方便起见展示了合并的投资组合总值。

在发出财务指令之前使用预留

预留用于记录某个具体提案已经占用账户部分可用资源。它应在其他策略能够使用相同资源之前建立，而不是等交易已经提交后才建立。

假设一个钱包为市场购买分配了 0.9 ETH。某项提案为资产预留 0.32 ETH，并为执行预留最多 0.01 ETH。在该提案结果确定之前，剩余分配额为 0.57 ETH。第二项策略必须依据这个剩余额度评估下一步操作。

预留需要标识符和生命周期。提案在授权之前被放弃时，可以释放预留；结算后，可以用实际支出替代预留；结果仍不确定时，则可以继续保留。如果原始交易仍可能执行，仅凭计时器到期并不足以释放预留。资源可用性应依据证据，而不是依据让策略保持忙碌的愿望。

定义什么属于未结承诺

并非每项财务承诺都表现为待处理的区块链交易。链下签名报价可能在以后仍可执行。挂单可能授权销售，而不会立即转移 NFT。不同市场程序也可能以不同方式托管资源或依赖批准。

因此，账户模型应区分准备好的提案、已签名订单、已提交交易和已确认成交。每个阶段都会产生不同的未来可能结果。未签名草案可能可以直接丢弃；已签名订单则可能需要确认取消后，才能不再考虑。

不要把某个场所的抵押行为硬编码为通用规则。应阅读每条受支持路径的当前文档，并表示其特定机制。用于 NFT 的加密交易机器人 指南解释了为什么同质化代币市场的惯例，不能自动适用于特定代币库存和市场订单。

协调相互重叠的报价

持有者可能创建相互重叠的单品报价、特征报价和广泛集合报价。应用应评估它们合并后的敞口，包括哪些报价可能取得同类资产，以及哪些报价仍可独立执行。

假设三个示例报价每个都可能支出 0.15 单位，第四个可能支出 0.2 单位。除非有可强制执行的机制限制哪些报价能够成交，否则潜在承诺总额为 0.65 单位。在界面中把它们称为备选方案，本身并不会让它们互斥。

取消请求会先改变意图，却未必立即改变仍可执行的授权集合。在这段时间内，账户可能需要同时为现有报价及其预期替换报价预留资金。具体处理取决于替换是否会使旧订单失效，以及如何验证这一结果。这是需要理解的状态转换，而不是应对用户隐藏的麻烦。

确保库存只被使用一次

自动化 NFT 市场交易的库存控制，应跟踪每件持有资产在其获准用途之间的状态。为待处理销售预留的代币，不应同时被当作自由抵押品，或安排用于无关转账。

对于多份版本资产，必须明确处理数量。拥有五份并挂出两份，不会把全部五份都从账户中移除，但确实会产生涉及两份的承诺。部分成交的订单会同时改变剩余订单数量和持有数量。

还要考虑手动活动。机器人离线时，持有者可能通过钱包界面转出资产。下次核对时，机器人必须更新库存，并调查依赖先前所有权的任何授权。假定所有账户变化都来自应用，会形成脆弱的现实视图。

保留一份持久化日志

日志将意图与尝试相连，再将尝试与结果相连。它应在应用重启后继续存在，并保留足够的标识符，以便向外部来源查询发生了什么。没有日志，恢复就只能依靠当前余额重建意图，而这往往不可能。

有用的记录包括策略版本、选定资产、支出上限、预留、已签名订单标识符、交易标识符和观测结果。财务调整应回指这些记录，而不是用没有解释的汇总替代它们。

日志也有助于区分重复通知与不同交易。重复的市场事件应更新或确认同一个底层事件，而不是在账户历史中创建另一笔购买。若来源标识符不足，系统需要有文档说明的去重方法，并能标记未解决的歧义，而不是默默制造确定性。

将事件流视为观测信息

实时连接可以改善感知，但它不是完整的账户账本。事件可能迟到、乱序到达，或在中断期间完全没有到达。系统应保留事件发生时间与接收时间之间的区别。

OpenSea 的 Stream API 文档 描述了尽力交付机制，并警告丢失的消息不会重放。由此产生的实际要求是，重新连接后应通过适当快照或历史来源进行核对，而不是假定当前事件流包含了所有错过的内容。

不要仅仅因为旧挂单事件后到，就让它覆盖更新的已确认销售。状态更新应考虑事件的含义和证据，而不仅仅考虑到达顺序。适当的核对方法取决于来源和资产类型，但推理事件顺序是共同要求。

明确表示订单替换

更改预期价格可能涉及多个操作：准备新订单、发布新订单、取消旧授权，以及更新本地显示。这些操作并不总是原子化发生。

工作流程应为中间状态命名。如果新订单已生效，而旧订单仍可执行，账户必须理解二者。如果取消成功，但替换订单发布失败，该资产可能没有当前挂单。这些是不同的结果，不应共用一个笼统的“已更新”标签。

应保留足够信息，以便撤回运行计划，同时不要假定财务影响也可以逆转。用户可以停止替换活动，但这不会撤销已经结算的交易。良好的自动化会展示中间状态，让操作人员能够在知情的情况下选择应对方式。

核对现金，不要虚构利润

现金增加可能来自销售、存入资金、账户间转账或其他来源。财务报告需要先对这些事件分类，再计算策略表现。

假设一个账户起初有 1 ETH，花费 0.2 ETH 购买 NFT，并支付 0.005 ETH 的买入成本，之后又收到一笔独立的 0.3 ETH 存款。在考虑其他承诺之前，可用现金变成 1.095 ETH。余额高于起始值并不能证明有交易利润；账户还持有一个 NFT，并收到了外部资本。

如果该 NFT 后来卖出，净收入为 0.23 ETH，相对于 0.205 ETH 的取得成本，其已实现结果为 0.025 ETH。存款仍属于资本流动。连贯的市场账户模型会保留这些类别，避免多策略活动因无关原因而让整体仪表盘看起来变好或变差。

先独立核算各条链，再合并报告

跨链投资组合可以用共同报告币种汇总，但执行资源仍然具有链的特定性。一条网络上看起来充足的余额，不会自动提供另一条网络上可支出的原生 gas，转移资金还可能带来延迟、成本和额外风险。

在报告转换后价值的同时，也要报告原生数量。记录历史支出所用的转换时间和方法。按今天的汇率重估旧购买，可能悄悄改写原始交易看起来的盈利情况。

运行时，应为每条路径所需的资产和支出维持独立预留。报告时，则应在底层记录完成核对之后再合并。这种顺序可以防止把较大的投资组合估值误认为执行某笔具体交易所需的充足即时可用资金。

按明确顺序恢复

自动化 NFT 市场交易恢复应先暂停新的承诺，并加载持久化日志。然后解决待处理尝试，刷新所有权和余额，检查有效订单，再重建可用资源。

顺序很重要。在重建预留之前就开始新的购买，可能重复承诺资金。在理解当前所有权之前取消一切，可能产生不必要支出，或掩盖已经成交的交易。恢复程序应遵循证据，而不是对每次中断都实施同样的破坏性重置。

自动化 NFT 机器人运行指南 更广泛地介绍了无人值守控制。在市场账户层面，主要要求是：重启后形成的财务理解应与不中断运行时一致，只有明确识别、仍需调查的缺口除外。

构建有用的操作提醒

提醒应告诉持有者发生了什么变化、哪些资产或资金受到影响，以及可以采取什么行动。“出了点问题”提供的信息太少，而原始技术调用栈可能提供太多无关细节。

优先处理那些改变账户安全操作能力的情况：未解决的提交、意外的所有权变化、运行资金耗尽、取消失败和来源数据过时。例行事件可以保留在日志中，不必每次都打断持有者。

为底层事件提供稳定引用。如果同一笔未解决交易触发了多个通知，它们应指向同一个案例，而不是看起来像多个独立故障。这样可以保持监控实用，并帮助客服或持有者调查，而无需交换钱包秘密。

在并发条件下测试自动化 NFT 市场交易

购买按钮单独使用时可能正常，但账户模型在并发条件下却可能失败。应测试两项策略尝试预留同一笔剩余预算、销售与转账竞争，以及取消在成交之后到达的情况。

每次演练之前，先定义预期账户状态。例如，如果两个提案各需要 0.4 单位，而只有 0.6 可用，那么在全额预留策略下，最多只能有一个成功预留。未成功的一方应收到容易理解的拒绝，而不是没有文档说明的部分授权。

还要测试重复事件，以及状态变化之间的重启。重复通知不应使持仓或成本倍增。写入中断不应在已签名订单仍有效时抹去预留。这些检查针对的是协调问题，而成功的一键演示无法揭示这类问题。

将协调质量与回报分开衡量

账户可能在存在运行错误时赚钱，也可能在遵守所有预期规则时亏损。应分别跟踪这两个维度。

协调指标包括无法解释的余额差异、处于不确定状态的时间、已处理的重复事件、被拒绝的过时观测，以及被阻止的冲突。交易指标包括净已实现结果、未售库存、持有期和敞口集中度。一个合并的醒目数字会掩盖究竟哪个问题需要关注。

除了已完成操作，还要审查被拒绝的操作。一次被正确阻止的购买，可能说明账户预算按预期发挥了作用。为了让执行统计看起来更整洁而移除这份记录，会牺牲有关系统边界的证据。良好的报告会同时解释采取的行动和有意不采取的行动。

在复用库存前解决跨市场挂单

同一件资产可能出现在多个市场视图中，也可能保留不止一份已签名挂单。这些展示不会创造多个持有资产。共享账户应将它们关联到同一个底层持仓，并分别跟踪每份挂单对应的授权。

假设一个 NFT 通过一条路径卖出，而别处仍有一份较旧的已签名挂单。销售改变了当前所有权，却未必抹去了每项历史授权。如果该资产之后回到原始钱包，旧订单可能按照自身规则再次变得相关。因此，库存恢复应检查未结授权，而不是假定销售永久关闭了所有相关记录。

降价也会造成类似的记录问题。最近显示的价格可能并不是唯一可执行的指令。应用应知道先前订单究竟是已失效、已过期、已成交，还是仅仅被界面隐藏。这些状态对持有者接下来可以安全采取什么行动，有不同影响。

这也是不应把市场界面作为账户唯一事实依据的原因之一。市场界面是有价值的观测来源，但底层资产身份、保留的订单记录和当前结算证据才决定账户状态。如果软件能够解释旧指令为什么不再重要，而不只是没有显示它，跨市场协调就能更好地工作。

让账户模型比界面更精简

人们很容易想把每个界面和策略都映射到底层财务状态中。更简单的方法是保留一小组持久化概念：资产、余额、承诺、尝试、结果和调整。各项功能再按照明确规则读取和更新这些概念。

这样可以降低应用中两个部分对同一资产产生分歧的可能性，也让新的市场集成更容易推理：集成必须解释自身特定机制如何映射到共享模型，而不是另造一个无关账本。

当每项决策都尊重共同的账户现实，自动化 NFT 市场交易就会更加可靠。更多市场和策略会带来更多冲突机会，并不会自动带来更多利润。明确的资源归属、持久化记录和基于证据的恢复，让用户在扩大活动时，仍能够解释账户拥有什么，以及还能承担哪些操作。