第29章　資産の移転からプログラム可能な権利義務関係へ

第二十九章　从资产转移到可编程的权利义务关系

区块链最容易被看见的能力，是让一项数字资产的控制状态从一个地址转向另一个地址。然而，利益相关者资本治理面对的并不只是“谁持有一个东西”。共同创造会持续发生：贡献需要核验，组织承担兑现责任，参与者承担约定风险，既有成果随时间投入生产，新的事实又可能改变未来的合作条件。一个静态余额无法充分表达这些关系。

因此，本章提出一个有待设计和检验的方向：在有效的制度授权下，把部分权利义务关系表示为可核验、可执行、可修订的状态。所谓“可编程”，不是把人的判断交给代码，也不是凭一次技术部署创造法律上的权利；它指已经形成的规则可以规定事实怎样进入程序、条件怎样触发、哪些状态可以变动、谁负责履行以及错误如何救济。技术能够提高执行的一致性，但权利的正当来源、链下事实和争议裁决仍要由相应的组织制度承担。

这里必须坚持本书已经建立的区分：贡献记录不自动成为资本，资本记录不自动产生所有权，收益请求不自动附带治理权。可编程关系的价值，恰恰是把这些不同层次分别表达，再说明它们在何种条件下发生联系。

一、权利如何随贡献、责任、风险与时间改变

权利的变化，首先要回答“变化的是什么”。一份交付通过确认，可以使尚待核验的贡献变为已确认的贡献；它未必同时使报酬到期、资本形成或表决资格成立。某项收益请求可能已经成立，但支付日期尚未到来；治理资格可能因任期届满而终止，既已取得的报酬请求却依然存在。把这些状态压成一个可升可降的“权益分数”，既掩盖责任归属，也容易使参与者无从预期。

制度设计可以对每项关系记载权利主体、对应义务主体、标的与范围、取得依据、触发条件、证据来源、生效时间、有效期限、可转让性和救济路径。技术记录的是这些要素的当前状态及其变更依据，而不是给每个人贴上一项无条件的“价值”。同一人可在不同任务中同时处于贡献者、审查者或收益领取者的位置；同一项成果也可能对应多个主体的不同请求。

贡献改变关系，须经过预先说明的确认程序。投入工时、提交成果、成果被使用以及产生经营结果，是不同事实。制度可以约定交付被接受时产生固定报酬，持续使用达到条件时产生后续收益，或者只有组织吸收某项能力并承担相应义务后才进入资本记录。每种安排都需要说明证据、确认者和异议期。不能因贡献容易被链上记录，就推断所有记录均具有相同的经济意义。

责任也会使权利的行使方式变化。担任项目负责人可能附带审批权限、保密义务和对超出权限行为的说明责任；职责解除后，未来审批权限应停止，但此前依法依约完成的劳动或交付不应因此被一并抹去。责任与权利的关联应限于具体职务和事项：没有事先约定和适当程序，不能凭事后评价任意扣减已确认请求。

风险的处理尤其需要克制。承担资金损失、质量担保或履约延期风险的人，可能要求相应回报、风险准备或退出条件；但“共同承担风险”不是把企业经营失败自动分摊给所有贡献者。应区分自愿承担的、可识别的风险与无法由个人控制的系统性风险，明确承担上限、期限、信息取得权及补偿规则。若风险状态由外部数据触发，还要说明数据提供者、复核权与错误输入的纠正办法。

时间可以影响归属，却不应成为含混的剥夺工具。持续服务、分期交付和长期合作可以对应不同的归属进度；归属前的期待与归属后的请求，在稳定性上应受到不同对待。对于已经完成的贡献，是否仍须经过等待期才能行使收益权，应在事前清楚约定。既有请求与未来资格不能只因系统内同属一个账户，就被同一个“离开组织”按钮同时清零。

由此可形成多维状态模型：贡献事实有“待核验—已确认—已修订”，收益请求有“附条件—已归属—到期—已履行”，治理资格有“申请—有效—暂停—终止”。这些状态并非必须排成一条统一的升级阶梯。每次转换都应保留对应证据、规则版本、确认或批准主体，以及变动前后的结果。这样的记录能帮助参与者理解“为什么变”，也为审计和纠错留下依据。

二、收益、治理、使用与退出条件的分别编排

“获得一份权益”在口语中方便，在制度中却过于笼统。收益权回答可以请求什么经济给付、由谁给付、何时到期以及给付来源；治理权回答谁能提出、审议、表决或监督哪些事项；使用权回答谁能在何种范围内接触资源、数据或基础设施；退出权回答如何结束参与、结清既有请求并处理仍在持续的义务。四者的标的、相对方和生效条件并不相同。

收益规则需要把“有资格参与分配”与“已有确定金额可请求”分开。前者可能取决于年度可分配资源、预定计算方法和身份条件；后者还需经过核算、批准及到期等环节。可以预先编排计算周期、资格快照、扣除事项、对账和支付顺序，但账本中的计算结果仍应与真实资金和有权负责的主体相对应。没有可分配资源时，程序不能凭记账动作制造兑现能力。

治理权更不能由收益权机械推导。治理资格可以依据成员身份、任职关系、代表授权或风险承担确定，并按事项配置提案、表决、回避和复核权限。某人获得收益，并不意味着自动取得企业全部决策权；某人不再承担职务，也不意味着他已形成的收益请求消失。治理程序可把通知期、法定或约定门槛、利益冲突申报、委托有效期编排到执行流程中，但谁有权制定和修改这些程序，仍是先于代码的制度问题。

使用权通常与任务、保密和容量相连。供应商为完成交付取得某些数据接口的限期访问权限，与获得该数据的所有权不同。使用范围应按最小必要原则界定：用途、对象、次数、期限、再授权条件和停止访问的触发事实均可分别规定。权限到期可以由系统关闭入口，但已取得的数据副本、持续保密义务和违法滥用的责任，不会因关闭入口自动消失。

退出是检验制度是否公平的关键场景。退出可以停止未来贡献资格、解除尚未开始的任务或结束受托治理权限；对退出前已确认的贡献、已归属但尚未支付的收益和未完成的保密、担保、纠错义务，则应逐项清算。合理的制度应说明提前通知、交接、估值或结算方式、支付期限、争议期间的临时安排，以及参与者获取自己记录的方式。若系统只能将一个地址“停用”，却不能生成清楚的结算说明，所谓可编程退出并未真正实现。

技术上可以把权利编排为条件与状态转换，但制度上还必须区分三种事件：事前约定条件自然成就，具有权限的人依程序作出决定，以及对既有记录的错误进行更正。第一种可以有较高的自动化程度；第二种需要可核验的授权和理由；第三种还需要保留原记录、标明冲正依据并处理已发生的履行。把三者混为“合约自动执行”，会隐藏重要的裁量和责任。

分期归属是一个直观例子。OpenZeppelin 的 VestingWallet 文档〔1〕展示了按时间表释放资金的技术机制，同时提示合约所有权可能被转移。这说明时间条件可以由程序实现，却不意味着受益人身份、基础权利的可转让性或现实中的给付义务也由程序自动决定。制度须另行约定并核验这些问题。

三、可转让权益与不可转让关系的协同

资产可以转移，不等于围绕资产形成的一切关系都随之转移。一笔已经确定的应收款，在适用规则允许且满足通知或同意等条件时，可以由新主体请求履行；产生这笔请求的历史贡献仍属于原贡献者。某个成员的个人信誉、审议经历或受托代表身份，也不会因转让收益凭证而成为受让人的履历。可编程治理必须允许“权益的某一部分变化”，同时保留“关系的其余部分不变”。

判断一项权益能否转让，至少要依次问：转移的究竟是收款请求、使用许可、治理资格，还是包含多种内容的组合；谁是履行义务人；原安排是否允许转移、是否要求同意或通知；受让人需要具备何种资格；原主体的未履行义务是否继续存在。若只设计一个可发送的通证，却没有回答这些问题，链上持有人变化最多表明技术控制状态变化，不能独自说明全部权利义务已变动。

不可转让也有不同理由。有的关系基于个人身份、专业资格或代表信任；有的访问权限仅为执行特定任务；有的贡献记录是对历史事实的署名。它们可以被证明、撤销资格或更正错误，却不适宜像无记名资产那样随意交易。另一方面，“不可转让”不应变成永不纠错。主体失去密钥、更换合法代表、组织合并或身份信息被误记时，应有经授权的恢复与更新程序，并保留连续的责任记录。

第十九章已经讨论身份绑定通证及其转移限制。把某项凭证在协议接口上锁定，只能限制合约所定义的转移操作，不能证明持有人身份真实、没有代持安排，或相关经济利益绝无其他转让路径。相反，可转让的凭证也不能单凭程序设计保证受让人取得所有现实权利。技术状态与制度关系之间需要持续核对。

因此，较稳妥的表达不是为每个人铸造一个包含全部权利的“身份通证”，而是为不同关系设置各自的记录和变更条件：历史贡献与确认者相连；收益请求与权利人、义务人和给付条件相连；治理资格与角色及授权期限相连；访问权限与具体用途相连。需要转移时，只移动允许转移的部分，并在关联记录中说明原权利人、新权利人、变更依据、通知结果和仍由谁承担既有义务。

这种拆分还应防止以形式上的“不转让”掩盖实质控制变化。若持有不可转让凭证的账户由他人实际控制，或可转让的载体把收益与投票权重新打包，制度设计原本保护的身份关联就可能落空。核验不能只看合约能否执行某个函数，还要观察托管、代理、授权委托和链下合同怎样改变实际控制。相应的治理规则可以要求披露、限制特定委托或设置利益冲突处理程序，但必须说明执行成本和隐私边界。

四、动态权益的预期稳定、变更授权与救济

如果权利随事实和时间变化，参与者首先需要知道自己在何种条件下会得到什么、失去什么。动态权益不是让组织拥有随时改写承诺的自由，而是把可预见的变化写入清楚的条件。应特别区分“按照既定公式输入了新事实”与“有人修改了公式”：前者属于原有安排的履行，后者可能改变原安排本身，必须接受更严格的授权和程序审查。

预期稳定要求规则在参与者作出投入之前可获得、可理解，并有明确的生效时间。系统应保存规则版本及其适用范围：某项贡献适用交付时的规则，还是确认时的规则；某次分配适用周期开始时的资格，还是支付时的资格；跨版本任务如何过渡。版本选择应由事前规则确定，不能等结果出现后再选择对一方有利的版本。尤其对于已经归属或到期的请求，若拟作不利变更，应明确其依据、授权范围和可能需要的个别同意；不能靠一次合约升级悄悄追溯改变。

规则变更的授权应与影响范围相匹配。日常参数调整可以交给限定权限的运营者；改变收益计算方法、治理资格或退出清算方式，则可能需要更广泛的提案、审议、通知和表决。利益冲突中的决策者应回避，受明显不利影响的群体应有表达和申诉机会。授权不只是链上多签人数达标，还包括有权主体、议题范围、程序期限和法律或章程约束是否满足。

异常情况下可能必须暂停自动执行，例如外部数据显著错误或合约漏洞正在造成损失。紧急权限应限定触发条件、作用范围和持续时间，要求记录理由、及时通知、事后复核，并安排必要的临时给付或人工处理。暂停不等于否定所有既有权利；恢复也不等于把暂停期间的损失视为从未发生。若没有补偿或责任分配，紧急按钮就可能成为对参与者单方面变更规则的工具。

救济必须进入设计本身。参与者应能查询自己的权利由何种事实和规则形成，谁提供了证据，谁批准或否决，何时发生状态变化；也应能申请更正事实、质疑规则适用、请求暂停争议部分的执行，并取得有理由的答复。链上记录难以直接擦除时，可以通过标注争议、冲正、追加更正记录及线下补偿处理错误。不同救济针对不同问题：事实错误需要重新核验，程序越权需要撤销或重新决定，给付错误需要追回或补偿，规则本身失当则需要制度修订。

这类制度设计是否比传统账户和合同管理更有价值，不能仅凭构想判断。可检验的命题包括：参与者能否更准确地预测未来请求；多方是否更容易核对权利依据；争议发生后能否更快查明变更链条；退出时是否更容易结清请求；自动执行有没有把错误或权力不对称扩大。应在相近的组织条件下比较不同技术方案，并把规则质量与技术效果分别评价。

五、动态权益状态机与不可越过的约束

要把上述原则转化为可检查设计，需要把“权益”拆成多个相互关联却不互相替代的状态机。状态机不是为了把人的关系机械化，而是强迫制度说明：哪一项事实正在变化，谁有权确认，变化影响哪一种请求，什么事项必须保持不变。

这个模型至少应满足五项制度不变量。第一，没有可识别的义务主体，系统不得把一项期待显示为可立即兑现的请求。第二，没有相应授权，任何人不得因掌握升级密钥而改变他人的权利状态。第三，事实更正可以改变依赖错误事实的结果，却不能无说明地覆盖历史。第四，转移只能作用于制度允许转移的部分，不能把人格、代表关系或持续义务一并打包。第五，争议应当冻结或标记受影响范围，不能借局部争议清空全部无争议请求。

还要区分三种看似相同的“状态变化”。新事实进入既定公式，是规则的正常适用；有权主体对开放性标准作出判断，是受程序约束的裁量；改变公式、权限或标准本身，则是制度修订。三者的日志形式可以相似，授权强度和救济方式却不同。系统若只记录“参数从A变成B”，而不记录变化属于哪一类，就无法判断参与者原先的预期是否受到不当改变。

动态权益的最小试验，可以选择一个边界清楚、周期有限的共同项目：使用一套普通业务系统保存原始证据，以版本化规则模型同步生成贡献、收益、治理和退出状态；另以现有合同与数据库流程作为对照。试验只处理事前明确的有限请求，不发行可自由交易的通证，也不把实验状态包装为正式财产权。任何无法说明依据的状态变化、无法完成的退出清算或超过预定损失上限的错误，都应触发暂停。

六、未来命题卡：受约束的可编程关系

这项命题若成立，区块链提供的新增价值不是让权利“天然可编程”，而是使多个主体能够围绕同一版本和变更链核验关系状态。若集中数据库在相同制度条件下已经提供更低成本、更好救济的结果，就没有必要为形式上的链上表达增加复杂性。

从资产转移迈向权利义务关系的编排，区块链才可能进入共同创造更复杂的时间结构。但这条路径的前提始终是：权利有可识别的来源，义务有可追究的承担者，变更有有效授权，错误有实际救济。下一章将进一步讨论，当协作主体包含人工智能体时，贡献证据、代理权限与责任归属会面临怎样的新问题。

定稿补强：动态权益中的稳定承诺

可编程不意味着可以随意追溯改变。动态权益需要区分已经完成并取得的结果、仍在持续满足的条件和只适用于未来的规则。既得结果原则上不因普通规则更新被重新计算；确需调整时，应有明确授权、重大理由、受影响者陈述、过渡、补偿、申诉和退出安排。

基本权利、禁止歧视、程序参与、救济和已经明确承担的义务，应构成制度演化的边界。规则可以改进，承诺的稳定性也必须能够被参与者合理信赖。每次变更应说明是否追溯、影响哪些群体、为何没有更温和替代方案，以及谁承担变更成本。

本章注释

1. [SRC-017] OpenZeppelin：OpenZeppelin 的 VestingWallet 文档。原文或官方页面
   • 本章引证：OpenZeppelin 的 VestingWallet 文档。
   • 支持范围：用于展示具体实现方式、工具接口或实践中的可行安排，本书引用主题包括：OpenZeppelin：归属钱包及时间安排、OpenZeppelin 的 VestingWallet 文档。
   • 使用边界：实现资料用于说明可行技术路径，不等同于独立安全审计、法律效力或经营效果证明。
   • 证据等级：C（实现层或第三方技术资料，用于说明具体工具与实践）；链接状态：已完成可访问性核验，核验日：2026-10-08。