适用范围：判断链上机制能否承接预售规则
讨论区块链预售模式的适用条件，需要区分预售承诺与合约执行。这里聚焦通过智能合约记录规则、管理链上资产及安排释放的技术条件，不涉及具体项目是否具备经营或法律上的适用资格。技术可行也不能直接证明项目能够履约。
条件一：规则明确，触发条件可以验证
Ethereum 的智能合约介绍说明，合约是运行在链上的程序，用户通过交易调用其功能；合约可以按代码执行规则，但无法自行获取链外事实，使用外部信息需要预言机等机制。
因此，预售对象、分配依据、截止条件以及失败后的处理方式，需要被表达为明确规则。如果交付依赖实物到货或服务验收，还需要说明由谁确认、依据什么信息确认，以及确认结果如何进入合约。链上记录本身无法证明线下交付完成。
条件二：释放安排与实际承诺一致
OpenZeppelin 的 VestingWallet 文档说明，该组件可按时间表释放原生资产和 ERC-20 代币；释放开始后补充存入的资产，可能立即有一部分可释放，其所有权也可以转移。
这意味着，预售采用分期释放机制时，应明确起算时间、释放周期和追加资产的处理方式。时间表适合表达按日期释放的安排；若承诺按项目进度交付，仅有时间锁还不足以验证进度。锁定资产与限制相关权益转移，也需要分别理解。
条件三：管理权限和执行成本可承受
预售机制需要清楚界定谁能管理资产、修改参数，以及处理异常。多重签名可以将授权分散到多个签名方，但其作用取决于权限配置，不能替代对合约逻辑的检查。
Ethereum 合约部署和交互需要支付网络费用，链上交互通常不可逆。因此，适用性还取决于费用是否与业务规模相称，以及规则是否已经覆盖重复操作、边界时间和异常状态等情况。
常见问题：自动执行是否等于自动履约
不等于。自动执行能够完成代码定义的资产操作，现实中的产品质量、服务完成情况仍需要外部验证。预售规则中存在无法被链上直接判断的条件时，必须保留明确的确认与争议处理安排。
采用标准释放组件是否就具备完整预售功能？不能据此判断。释放组件只解决资产按计划释放的问题，预售资格、额度、交付和退款等业务规则仍需单独定义，并检查它们之间是否一致。