适用范围：先区分记录与履约
本文讨论通过智能合约记录预售参与情况、处理款项或分配链上权益的技术条件。Ethereum 的智能合约介绍说明，合约依据代码处理交易，但无法自行读取链外事实。因此，链上记录能够证明哪些操作发生过，实际商品或服务是否交付，还需要相应的验证机制。
条件一：预售规则能够明确表达
适用场景需要事先明确参与资格、开放期限、数量限制、分配规则及结束条件。如果设置退款，还应明确触发条件、可退金额和执行权限。这些规则必须能够转化为可检查的状态与操作，才能由合约一致执行。
如果交付标准主要依赖临时协商，或关键条款尚未确定，自动执行就缺少稳定依据。文字约定与合约实际行为也需要一致，避免页面承诺与代码规则脱节。
条件二：交付条件可以验证
链上资产是否已分配，可以通过相应链上状态核对。实物发货、服务完成或质量验收涉及链外信息，需要外部数据或确认机制，并明确由谁提供、如何处理错误与争议。引入预言机能够传递链外数据，但数据来源的可信度仍是独立问题。
条件三：资金与管理权限边界清楚
OpenZeppelin 的访问控制文档区分了单一所有者与按角色授权的管理方式，并强调最小权限原则。应用到预售场景，需要明确谁可以修改规则、释放款项、分配权益，以及谁能够授予或撤销这些权限。
资金释放与退款条件应相互协调：如果款项已经全部转出，保留退款入口并不等于仍有足够资金可退。多签可以让关键操作需要多人同意，但签名人的权限范围与保管安排仍需清楚。
条件四：具备运行与维护能力
合约部署和状态变更需要支付网络费用，流程设计需要考虑参与、领取及退款等操作的成本。由于链上操作通常无法直接撤销，规则测试、异常处理及管理权限交接也属于适用条件，不能仅以成功部署作为流程可靠的依据。
常见问题
预售结束后会自动退款吗？只有合约实现了退款规则、满足触发条件且具备相应资金时，退款才有执行基础；具体设计还可能需要用户或其他账户提交交易。
使用智能合约是否就能保证交付？不能。它能够执行已编码且可验证的条件，线下生产、服务质量与履约争议仍需要链外安排。上述条件用于判断技术适配性，不能单独证明某一预售活动合法或可靠。