适用范围：用合约管理预售规则
这里讨论的是通过智能合约记录预售参与情况、管理链上资金或分配数字权益的通用技术条件。技术上可以实现某种流程，并不等于某项预售已经具备交付能力或符合相关法律要求。
以太坊智能合约介绍说明，合约是运行在链上的程序，用户通过交易调用其功能；它能够执行编码规则，但无法独立获取链外事实。这决定了预售模式的适用边界。
条件一：规则清楚且可以验证
适合写入合约的规则，需要具有明确的输入、判断条件和执行结果。例如，预售何时结束、额度如何计算、什么情况下形成领取资格，都应当能够确定地判断。依赖临时解释或主观认可的条款，很难仅靠代码执行。
还需要明确哪些操作由用户发起，哪些需要管理方或其他执行者提交交易。写入截止时间，并不意味着合约会在时间到达时自行完成所有后续操作。
条件二：交付与退款有完整路径
链上数字权益较容易通过合约状态核验；实物发货、服务完成或线下验收则需要外部信息支持。预言机能够把链外数据提供给合约，但数据是否准确、由谁确认，仍然需要单独设计。
预售流程还应覆盖未满足条件、延期或终止等情况。退款触发条件、可退金额和资金可用性需要相互匹配；如果资金已被提前转出，仅有退款条款并不能保证合约有能力退款。
条件三：管理权限与责任相匹配
OpenZeppelin 的访问控制文档介绍了所有者管理、按角色授权和最小权限原则，并提示管理员权限本身具有风险。这些机制可用于区分预售中的资金管理、权益发行和规则维护职责。
适用的权限设计需要说清楚谁能修改参数、转移资金或分配权限，以及这些操作受到什么限制。多重签名可以降低对单个密钥的依赖，但不能替代对授权范围和管理责任的约束。
常见问题：公开合约是否就足够可靠
合约公开是否代表预售可靠？公开代码有助于检查规则，却不能证明代码没有缺陷，也不能证明链外承诺能够兑现。判断技术适用性仍需检查正常流程和失败流程是否完整。
所有预售都适合上链吗？如果关键交付高度依赖人工裁量，或无法提供可靠的链外验证方式，合约能够自动执行的范围就有限。此外，部署和交互需要支付链上费用，流程设计应考虑这些成本。