Domingo_gou

四笔加密工资都对上账了，如果第五笔填错，谁来查？
9月1日 @primus_labs 与AllScale在BNB Chain上完成了一次技术验证。4名虚构员工、4笔样例工资，链上结算成功，解密后的金额也与测试文件一致。
这是个不错的开始，但企业发工资是每个月都要重复的事。一次测试成功，离财务敢把整个月的工资交给这套系统，还有一段路。
这次合作有个细节挺重要。AllScale原本就有稳定币Payroll产品，支持周期性发薪、审批、失败通知和账单生成。Primus的FHETransform则负责给单笔工资金额加密。外人依然能看到付款地址、时间和交易记录，却看不到具体金额；员工通过钱包签名，就能免Gas查看自己的工资明细。
麻烦也恰恰从这里开始。以前财务核对工资，金额、审批记录和付款结果都能直接对照。现在金额加密了，谁有权限查看，谁负责批准，出了差错又由谁核对？AllScale原有的普通发薪功能已经提供了一套业务基础，但这些功能在 FHE 加密模式下能否完整协同，目前还缺少公开的生产级验证。
举个假设：一家企业给100名员工发工资，第五笔金额录错了。如果还没发出去，能不能及时发现并重新审批？如果付款失败，重试时怎样避免重复支付？如果错误金额已经完成链上结算，那就不能指望点一下撤销键把钱收回来，还得另外处理差额、协调返还并保留完整记录。整个过程中，财务要能查清楚，又不能因为查一笔错账，把所

合约账本少了30，链上的钱也少了吗？
一个叫withdraw的方法，把balance从100改成 70。
看上去像提走了30，但有个问题不能跳过：交易到底把多少sats付给了谁呢？
Lambit官方How to Deploy & Call示例里，同一个Vault的初始化状态是 balance: 100n，部署UTXO时填的是 satoshis: 1_000n。接着调用withdraw(amount: 30n)，演示的后继状态变成70n。
这是本地教学流程。
文档没有说明balance的业务单位，也没有把这30对应成一笔已确认的用户收款。不能拿100和1000直接相减算缺口，更不能由此断言合约提现失败。
状态账
balance是开发者定义的业务字段，可以代表额度、份额或其他内部计量，具体得看合约怎么定义。Lambit的状态校验会把被花费输入关联的状态承诺与当前状态对应起来，并对后继状态输出施加规则。
这能回答状态是否按合约约定推进，却不能自动回答这个数字是否等于实际可领取的sats。
资产账
ctx.value读取的是当前被花费输入的UTXO金额，单位为 satoshis。它不是钱包里全部的钱，也不是交易所有输入相加的数字。
如果项目对外说balance代表可提取的BTC数量，就需要进一步证明初始化、入金、提款、关闭等路径都有规则把业务余额与实际资产对应起来。如果balance只是别

合约只安排了给A、B 两笔付款。
如果钱包再加笔找零，Lambit为什么可能在广播前拒绝？
@op_catlayer 的Lambit有状态合约，终局可以通过outputs指定多笔付款，这类多输出终局路径使用 SIGHASH_ALL，把整组输出固定在hashOutputs承诺里。
假设原定输出是A+B，钱包出资时又加了Change，实际就成了A+B+Change。多出的找零改变了整组输出。官方文档说明当前funded provider为避免这类冲突，会提前拒绝部分多输出终局路径。
这属于交易准备环节的兼容限制，不代表链上不能分账，写自动结算时，合约确定的收款输出，还得和钱包出资、找零的方式对得上。
@OPCATLayerCN @clawchatglobal #OPCAT #Lambit