适用范围与概念入口
这里将“区块链福利模式”限定为利用链上程序记录或分配权益的应用场景，不指向某个具体项目。理解这类应用，需要分别看权益如何表示、分配条件如何判断，以及谁有权管理规则。不同应用可能只使用其中部分技术。
智能合约：把分配条件写成程序
以太坊开发者文档将智能合约解释为位于链上地址的代码与状态，用户通过交易调用其功能。合约之间也可以相互调用；部署和执行相关交易需要消耗Gas。
对应权益分配场景，程序可以检查条件并更新领取记录，但前提是这些条件已被明确编码，且执行时有可用数据。自动执行是否符合业务目标，取决于规则设计和实现是否正确。调用其他合约时，也需要理解被调用程序承担什么职责。
ERC-20：表示可互换的数量型权益
OpenZeppelin的ERC-20文档说明，该标准用于记录可互换代币，支持余额查询和转移。其decimals字段用于显示精度，合约内部仍以整数计算。
如果权益按统一单位计量，每个单位具有相同属性，可以考虑用这类数量模型表达。例如，显示为小数的额度，在底层仍对应整数记账。业务层需要另外定义额度有什么用途、如何产生；ERC-20接口本身不能说明线下服务如何兑现。
预言机与多重签名：数据和管理边界
以太坊开发者文档还介绍了两种机制：预言机将链外数据提供给合约；多重签名要求达到约定数量的有效签名后才执行操作。
当资格取决于线下活动是否完成时，关键问题是由谁确认并提交结果，合约无法独立观察线下过程。当管理操作需要多人共同决定时，多重签名可以分散控制权，但签名门槛与参与者安排仍需明确。
常见问题：技术能证明什么
有代币是否就有福利？代币余额能够表示链上记录，实际对应的服务或权益仍需有明确规则。合约公开是否意味着规则公平？公开有助于检查程序，但公平性还涉及资格条件与管理权限。
所有福利应用都需要预言机吗？只有规则依赖链外信息时，才需要相应的数据接入机制。理解具体模式时，应把链上可验证的记录、外部提供的数据和业务方承担的兑现责任分别说明。