自然语言合约

自然语言合约是由AI Agent支持的聪网智能合约类型。合约内容以自然语言协议表达，由AI Agent进行结构化解释、验证和执行建议生成。

自然语言合约遵循智能合约的通用协议。本文只定义自然语言合约的边界和第一阶段要求。

命名

建议命名：

中文名：自然语言合约。
英文名：Natural Language Contract。
技术简称：Agent合约。
代码类型：ContractTypeAgent。

协议文档中使用“自然语言合约”。代码类型和内部实现可以使用Agent。

合约类型

自然语言合约类型为：

ContractTypeAgent

自然语言合约不是EVM合约，不要求用户编写Solidity、ABI或bytecode。

自然语言合约不是模版合约，不要求合约逻辑预先固化在聪网节点源码中。

自然语言合约不是通道合约，不依赖RSMC通道、多方签名或承诺交易。

CoreNode Agent

聪网自然语言合约由协议内置的AI Agent支持。第一阶段可以将整个聪网网络理解为只有一个协议Agent，该Agent由内置CoreNode执行。

CoreNode身份由协议实现内置的CoreNode公钥确定。当前参考实现中，CoreNode公钥对应indexer/common/const.go中的GetCoreNodePubKey()。

CoreNode生成的预测确认结果必须带有CoreNode公钥和CoreNode签名。节点验证confirm时必须检查提交公钥等于协议配置的CoreNode公钥、该公钥推导出的Taproot地址等于协议配置的CoreNode地址，并验证签名覆盖当前合约地址和确认参数。签名不能替代链上canonical Result验证，但用于证明Agent结论确实由协议认可的CoreNode产生。

CoreNode在自然语言合约中同时承担以下角色：

Agent执行者。
合约内容可理解性、可验证性和可执行性的审核者。
协议oracle。
生成自然语言合约执行结论的授权实体。

自然语言合约的普通用户不能替代CoreNode生成协议认可的Agent结论。普通用户可以部署合约、提交材料、请求执行或发起争议，但不能调用只允许CoreNode调用的内置Agent接口。

后续协议可以扩展为多Agent验证模式，例如3个Agent中至少2个给出一致结论才接受执行结果。测试阶段可以先采用单CoreNode Agent模式。

合约内容

自然语言合约内容是一份可执行协议文本。协议文本必须能被AI Agent解析为可验证、可验收、可执行的结构。

协议文本应包含：

合同目的。
参与方和角色。
标的资产。
资产进入合约的方式。
触发条件。
验证数据来源。
验收标准。
执行方式。
超时、失败和争议处理。
可生成的资产转移结果。

合约可以包含结构化辅助字段：

资产列表。
参与方地址列表。
时间或区块高度限制。
允许使用的数据源。
验证器或仲裁器规则。
合约版本。

自然语言正文是合约语义的核心来源。结构化字段只能辅助解析，不得改变正文的核心含义。

部署规则

CONTRACT_DEPLOY用于部署自然语言合约。

部署payload包含：

合约类型。
合约正文。
合约版本。
deployer。
部署随机值。
可选结构化辅助字段。

自然语言合约部署后不会自动进入可执行状态。部署成功只创建一个待确认合约，初始状态为PendingReady。

所有自然语言合约都必须提供一个固定的CoreNode激活接口：

ready

ready接口只能由CoreNode调用，其他地址无权调用。调用者身份仍按通用规则由调用交易最后一个输入解析得到。

CoreNode调用ready接口时，需要检查：

内容是否完整。
条件是否可验证。
验收标准是否明确。
执行结果是否可以映射为Asset Intent。
是否依赖不可验证或不可共识的私有事实。
是否存在矛盾条款、循环条件或无法执行的条款。

如果检查通过，CoreNode交互生成canonical CONTRACT_RESULT，该Result声明合约进入Ready状态。只有进入Ready状态的自然语言合约才能接受普通业务调用。

如果检查不通过，CoreNode交互生成拒绝结果，合约进入Rejected或Invalid状态。未进入Ready状态的合约不得产生资产转移执行结果。

调用规则

CONTRACT_INVOKE用于向自然语言合约提交事件、证明、验收请求、执行请求或争议材料。

调用内容可以包含：

触发动作。
调用者身份。
链上证明。
外部证明。
验收材料。
执行请求。
争议或申诉材料。

调用交易必须输出到被调用合约地址，作为gas/funding输出。调用者身份由调用交易最后一个输入解析得到。

自然语言合约默认调用不携带自然语言材料或结构化动作。第一阶段可作为向合约地址转入资产的普通链上行为，除非合约协议明确规定默认行为，否则不改变自然语言合约业务状态。

自然语言合约调用分为两类：

CoreNode内置调用：包括ready以及后续协议定义的Agent专用接口，只允许CoreNode调用。
普通业务调用：由参与方或其他授权地址提交事件、证明、验收、执行请求或争议材料。

除ready外，普通业务调用只能在合约状态为Ready后生效。

AI Agent执行规则

AI Agent根据合约正文、合约状态、触发条件、证明材料和链上环境生成结构化执行结论。

第一阶段Agent由CoreNode执行。CoreNode生成的Agent结论进入聪网合约执行流程，并通过canonical CONTRACT_RESULT表达。Agent不能只输出自由文本，必须输出可验证、可比较、可重放的结构化结论。

执行结论必须包含：

触发条件是否满足。
使用的验证材料。
验收是否通过。
需要生成的Asset Intent。
是否需要等待更多材料。
是否进入失败、超时或争议状态。
结论摘要。

AI Agent不能直接花费UTXO。资产转移必须通过canonical CONTRACT_RESULT结算。

Agent具体执行方式仍需后续明确，至少包括：

模型版本或Agent实现版本。
固定提示词和解释规则。
结构化输出schema。
输出签名或CoreNode身份验证方式。
单Agent模式和多Agent阈值模式的切换规则。
失败、超时、争议和重试规则。

可验证性

自然语言合约必须避免依赖无法形成共识的事实。

允许的数据来源包括：

聪网链上交易。
合约自身状态。
指定链上合约或预言机结果。
部署时指定的外部证明。
多方签署的验收材料。
协议允许的AI Agent验证结果。
CoreNode作为协议oracle给出的验证结果。

如果多个节点的AI Agent可能对同一材料得出不同结论，协议必须提供约束机制：

固定模型版本。
固定提示词和解释规则。
固定结构化输出格式。
多Agent共识。
仲裁器或挑战期。
只接受可独立校验的证明材料。

Result TX和状态

自然语言合约不接受外部提交的CONTRACT_RESULT进入mempool。

出块节点根据AI Agent执行结论构造canonical CONTRACT_RESULT。验证节点必须根据协议规定的Agent验证方式复核执行结论，并比较Result TX。

自然语言合约结果进入聪网合约结果流程。无论是ready激活结果、拒绝结果、普通执行结果、失败结果还是争议结果，都必须通过canonical CONTRACT_RESULT表达，不能由外部用户直接提交非canonical Result TX。

自然语言合约状态至少包含：

合约正文hash。
合约版本。
当前执行状态。
已提交证明。
已验收事项。
待执行事项。
已生成结果。
争议或失败状态。

自然语言合约状态应尽量使用统一状态定义。不同合约可以只使用其中一部分状态，但相同状态名称在不同自然语言合约中必须表达相同含义。

基础状态包括：

PendingReady：合约已部署，等待CoreNode调用ready审核。
Ready：CoreNode已确认合约内容可理解、可验证、可执行，可以接受普通业务调用。
Rejected：CoreNode拒绝激活，合约不能执行普通业务调用。
Invalid：合约内容、结构或调用材料无效，不能进入后续执行流程。
PendingEvidence：合约等待参与方提交证明或验收材料。
PendingExecution：触发条件已满足，等待Agent生成执行结论或等待Result结算。
Completed：合约主要义务已完成，相关资产转移已经结算。
Failed：合约因失败条件、超时或不可执行原因结束。
Disputed：合约进入争议状态，等待CoreNode、仲裁器或协议定义的争议流程处理。
Expired：合约超过有效期且未满足继续执行条件。

Agent合约state root必须进入统一contract state root。

预测型自然语言合约

第一阶段优先支持预测型自然语言合约。预测型自然语言合约是ContractTypeAgent下的固定子类型：

prediction

预测型自然语言合约用于表达一个可验证事件的多个候选结果。用户向合约地址投注，Agent在事件结束后根据部署时指定的数据来源确认最终结果，合约根据确认结果自动分配奖金或退款。

预测型自然语言合约的Agent只负责：

ready：审核合约内容是否可以被理解、验证和执行。
confirm：根据指定数据来源提交最终结果。

下注记录、手续费、奖金分配、退款和合约关闭都由预测合约runtime确定性处理。

部署payload

预测型自然语言合约的部署payload包含：

{
  "subtype": "prediction",
  "title": "...",
  "description": "...",
  "time_base": "unix",
  "event_time": 1780310400,
  "bet_deadline": 1780306800,
  "confirm_after": 1780396800,
  "source_url": "https://xxx.com",
  "bet_asset": "::",
  "min_bet_unit": "10000",
  "outcomes": [
    {"id": "a", "text": "..."},
    {"id": "b", "text": "..."},
    {"id": "c", "text": "..."}
  ]
}

字段规则：

subtype必须为prediction。
title和description描述预测目标。
time_base指定时间基准，可以为unix或height。
event_time、bet_deadline和confirm_after按time_base解释。
source_url为部署时指定的数据来源站点或入口URL，可以是比赛预告页面、赛事页面或结果查询网站。
bet_asset为投注资产名称，使用聪网资产层的AssetName.String()格式。
min_bet_unit为最小投注份额，使用字符串表达，最终按bet_asset对应资产属性解析为Decimal。
outcomes为候选结果列表，数量不固定，但至少包含2个候选结果。
outcomes.id使用小写字母编号，例如a、b、c，同一个合约内必须唯一。
部署payload不包含手续费比例、Agent策略、bootstrap地址或Agent地址，这些属于协议内置配置。

内置配置

预测型自然语言合约第一阶段使用协议内置配置：

部署者手续费：奖池的6%。
Agent手续费：奖池的3%。
bootstrap node手续费：奖池的1%。
赢家奖池：奖池的90%。

如果后续采用3个Agent的多Agent模式，Agent手续费总额仍为3%，每个参与并形成有效确认结果的Agent获得1%。当前单Agent模式下，CoreNode Agent获得完整3%。

bootstrap node收款地址由协议内置bootstrap公钥推导，当前参考实现可使用indexer/common/btc.go中的GetBootstrapAddress()。Agent收款地址由协议内置Agent/CoreNode公钥推导，后续实现可以增加与GetBootstrapAddress()对应的Agent地址推导函数。

下注规则

预测型自然语言合约进入Ready状态后，内部状态进入Betting，用户可以通过bet调用参与投注。

bet调用参数包含：

{
  "outcome_id": "a"
}

下注规则：

任何地址都可以调用bet。
合约必须处于通用Ready状态，且预测合约内部状态必须为Betting。
当前时间或区块高度必须小于或等于bet_deadline。
outcome_id必须存在于部署payload的outcomes列表中。
下注资产必须为部署payload中的bet_asset。
下注金额以Call TX转入合约地址的funding output为准，不能以调用参数中的金额为准。
下注金额必须大于或等于min_bet_unit。
下注金额必须是min_bet_unit的整数倍。
同一地址可以对多个候选结果下注。
同一地址对同一候选结果多次下注时，状态按地址和候选结果聚合金额，历史记录保留每次调用。

每个候选结果的投注都必须独立满足最小投注份额和整数倍规则。

结果确认

confirm是预测型自然语言合约的Agent结果确认接口，只允许CoreNode Agent调用。第一阶段默认触发器为confirm调用。

confirm调用参数包含：

{
  "result_type": "outcome",
  "outcome_id": "a",
  "source_url": "https://xxx.com",
  "result_url": "https://xxx.com/match/result/123",
  "result_hash": "...",
  "observed_at": 1780314000,
  "agent_version": "agent-v1",
  "model_version": "model-v1",
  "core_node_pubkey": "...",
  "core_node_signature": "..."
}

确认规则：

调用者必须是CoreNode Agent。
合约必须已经进入Ready状态。
当前时间或区块高度必须已经超过bet_deadline。
当前时间或区块高度必须已经到达confirm_after。
result_type必须为outcome、cancelled、invalid或unverifiable之一。
当result_type为outcome时，outcome_id必须存在于部署payload的outcomes列表中。
当result_type为cancelled、invalid或unverifiable时，outcome_id可以为空，合约进入全额退款流程。
source_url必须与部署payload中的source_url一致。
result_url为Agent实际用于确认结果的具体页面URL，可以不同于部署payload中的source_url。
result_url必须属于部署payload中source_url指定的网站范围：scheme必须相同，hostname必须相同或为其子域名；如果发生HTTP跳转，跳转后的最终URL也必须满足同样规则。
result_hash记录Agent解析result_url页面或数据来源时使用的清洗后文本hash。
observed_at记录Agent观察到结果的时间或高度。
agent_version和model_version记录生成确认结果的Agent实现版本和模型版本。
core_node_pubkey必须等于协议配置的CoreNode公钥。
core_node_signature为CoreNode对确认载荷的签名，当前参考实现接受节点钱包消息签名格式，并保留Schnorr签名验证兼容。

CoreNode签名载荷必须使用固定domain：

satoshinet.agent.prediction.confirm.v1

签名覆盖字段包括domain、合约地址、action=confirm、result_type、outcome_id、source_url、result_url、result_hash、observed_at、agent_version和model_version。签名不覆盖core_node_pubkey和core_node_signature自身。

Agent根据部署payload中的source_url确定允许的数据来源范围，并在该网站范围内找到具体结果页面result_url。Agent解析result_url内容，找到预测事件的最终结果，然后通过confirm提交结构化结果。合约runtime只处理结构化结果，不直接依赖非结构化网页内容进行资金分配。

清洗后文本应去除脚本、样式、广告、导航和明显动态噪声，只保留Agent用于判断结果的主体文本。第一阶段共识节点验证CoreNode签名和结构化确认结果，不在区块验证路径重新抓取网页；result_hash作为CoreNode确认时使用材料的链上存证，供索引器、浏览器、审计工具和后续挑战机制复核。

如果采用多Agent模式，多个Agent分别提交confirm结果。合约runtime在相同result_type和相同outcome_id达到协议阈值后确认最终结果，并按该结果自动结算或退款。

自动结算和退款

预测型自然语言合约不提供对外开放的settle或refund接口。正常情况下，confirm触发合约自动结算或退款。

有赢家时，合约按以下顺序分配合约地址中的全部bet_asset资金：

6%发送给deployer。
3%发送给Agent。
1%发送给bootstrap node。
剩余90%按赢家下注金额占全部赢家下注金额的比例分配给赢家。

手续费和赢家分配使用Decimal计算。比例计算产生的余数进入赢家奖池。赢家分配产生的余数按赢家下注金额从大到小分配；下注金额相同时，按地址字典序分配。

没有赢家时，合约不收取手续费，合约地址中的全部bet_asset资金按原下注金额比例退款。

以下情况进入全额退款流程，不收取手续费：

比赛或事件取消。
数据来源可访问但结果不在候选结果列表中。
Agent确认结果为不可验证或无效。
合约内容在ready后发现无法执行且尚未完成结算。

confirm_after是Agent开始检查结果的预期时间或高度。到达confirm_after后，Agent开始检查数据来源并尝试确认结果；如果Agent尚未确认，合约不自动退款，继续等待Agent处理。

只要bet_asset资金进入合约地址，就视为该预测合约的资金池，不再按来源过滤。非bet_asset资产不参与当前预测合约结算。

不提供部署者取消接口

预测型自然语言合约不提供deployer专用的cancel接口。

原因如下：

合约进入Ready前不能接受投注，通常没有需要deployer退款的资金。
合约处于Betting时，允许deployer取消会产生提前终止合约、规避未来结果或影响投注人的风险。
合约处于ClosedForBet或PendingResult时，结果确认权属于Agent，deployer不能替代Agent判断事件结果。
比赛取消、结果无效、数据不可验证或合约无法执行时，应由CoreNode Agent通过confirm提交cancelled、invalid或unverifiable结果，并触发全额退款。
到达confirm_after后Agent尚未确认时，协议选择继续等待Agent处理，不授权deployer绕过Agent触发退款。

内部状态

预测型自然语言合约使用通用Ready状态表示合约已经通过CoreNode审核，可以接受业务调用。预测业务自身维护独立内部状态：

Betting：允许用户下注。
ClosedForBet：下注截止，不再接受新下注。
PendingResult：等待Agent提交最终结果。
Confirmed：结果已经被Agent确认或达到多Agent阈值。
Settled：奖金已经分配，合约关闭。
Refundable：合约进入退款流程。

Betting不是通用合约状态，只是预测型自然语言合约的内部状态。

第一阶段定位

自然语言合约第一阶段允许先以单CoreNode Agent模式进入聪网合约结果流程。合约部署后必须先由CoreNode通过ready接口确认，确认结果通过canonical CONTRACT_RESULT写入链上状态。

第一阶段仍需继续明确Agent执行细节。进入完整主网共识执行前，必须明确模型确定性、验证方式、挑战机制、仲裁机制、多Agent阈值规则和state root承诺规则。

Previous模板合约 NextEVM 合约

Last updated 14 days ago