Gardens V2 Funding 提案达标却没付款：核对 Conviction、池余额、纠纷与执行回执
链小知 · 进阶 · 核验 · 依官方文档整理
从已有Funding提案记录区分支持百分比、累计Conviction、严格执行门槛、Disputed与beneficiary收款，按固定V2错误名定位失败。
开始前准备
- 准备已有提案URL、chain/community/pool/strategy/proposalId、请求token/原整数/decimals、beneficiary、状态/Conviction/阈值与读取时点；有原失败/执行/仲裁回执则一并保存。没有实时数据只整理核对表。
- 方法依官方V2文档及a38ed104固定代码，实际部署/ABI必须匹配。只读已有记录，不点Execute/Dispute/rule、投票/修改参数，不请求Graph/RPC、发送交易或领取押金。
1. 先确认是 Funding，再核请求与收款身份
打开原提案记录，按页面Author、beneficiary、request amount、Status保存完整字段。Funding、Signaling、Streaming不能混用：Signaling不自带资金执行，文档仍标Streaming comingsoon而固定源码已含分支，本教程不解释该版本Streaming结算。
固定请求金额是pooltoken的原整数，不是支持点数；用已核token地址/decimals换算，例1000000且decimals6为1token。前端缺decimals会fallback18，所以仅页面四舍五入金额不够。beneficiary和Author/submitter是不同地址，不能默认付给发起者。
检查结果：Funding类型、链/proposal身份、原金额精度与完整beneficiary均可对应。
2. 把 Support、Conviction 和门槛分别记录
在Progress/已有快照分列分配支持权重、累计Conviction与threshold。官方示例7天half-life下，持续10%支持14天约得7.5%Conviction，不是投票支持10%立即有10%Conviction，也不是到第14天自动付款。图注2.96只是示例。
同时记录ConvictionGrowth、MinimumConviction、SpendingLimit和FixedMinimumThreshold。前两类百分比/half-life与固定权重点不同，SpendingLimit是请求占池资金上限不是费用。固定计算时间用blocks；不知道本链区块转换/版本时不自行拿Unix秒套公式。
检查结果：三条指标及参数单位分离，示例时间/阈值未推作所有池规则。
3. 用同一时点的池余额和原值判门槛
Funding阈值随requestedAmount相对可用poolfunds、有效点数和参数变化；固定getPoolAmount取实际池余额并可能含SuperToken换算，不是历史募集总额。保存原读取区块/时间，缺余额或token精度记未知，不能拿昨天的图表证明现在可执行。
固定D=10000000用于decay/weight/maxRatio原参数，不能把原maxRatio数字直接当百分比。正请求达到或超过ratio边界会AmountOverMaxRatio；convictionLast<=threshold仍报ConvictionUnderMinimumThreshold，所以严格大于才通过这项检查。当前代码还用proposal/pool平滑阈值快照，不能仅取瞬时totalPointsActivated替代。
检查结果：同版本/时点的余额、参数、快照和严格大于比较清楚；rounded相等不推通过。
4. 先排查状态和纠纷，再看按钮失败
Status原码按匹配接口解读：Inactive0、Active1、Paused2、Cancelled3、Executed4、Disputed5、Rejected6。固定Funding distribute需要Active；UI不足poolfunds、未到threshold或disputed会禁用Execute。记录已有NOT EXECUTABLE后的具体error，不为测试而点按钮。
如果原记录是Disputed，保存arbitrableConfigVersion、arbitrator/tribunalSafe、disputeTimestamp、defaultRulingTimeout和已有ruling。文档oneweek不是所有池固定期限；源码仅时间严格超过timeout走default规则，仍需rule动作。ruling1恢复Active，2Rejected，0/超时取配置default；裁决不自动等执行或付款。
检查结果：状态、原失败名及仲裁时点/版本分别核，超时或纠纷结束未当自动到账。
5. 对照原错误与执行事件，核资金目标
按已有失败回执定位：PoolIsEmpty、PoolAmountNotEnough、AmountOverMaxRatio、NoActiveGovernancePoints、ConvictionUnderMinimumThreshold或ProposalNotActive各有不同输入。正请求不存在有效点数、余额不足或未超过门槛时，单纯继续等并不保证通过；缺原error不补具体失败原因。
已有成功执行记录时核匹配Allo/pool/strategy及proposalId，保存Distributed(proposalId,beneficiary,amount)和token转账结果。固定facet只接受Allo转入分发，UI Execute是有Gas的状态改变；“anyone can execute”的文档不代表任意地址可直接调用facet或按钮无需钱包。事件/Executed/页面Funded仍要和实际beneficiary同链收款对账。
检查结果：失败原因对应原输入；执行事件、目标与实际收款没有合并。
6. 把项目款、押金和待核项分别结案
Funding请求金额是给beneficiary的pooltoken；提交/纠纷collateral和仲裁fee是另一个资金范围。固定纠纷函数把msg.value余量交arbitrationFee，rule可能emit CollateralPayoutFailed而裁决仍成功，所以不能用ruling成功推押金已退。文档败诉可能没收押金，不用宽泛“自动退款”保证。
最终分别写：Funding提案仍等待/失败/已执行、beneficiary收款已核或未知、仲裁状态、collateral退款已核或未知。保留chain/版本/原金额/错误和时间，缺当前部署、回执或余额时停在静态排查；不执行提案、修改threshold或动用资金完成本教程。
检查结果：提案状态、受款资金和仲裁/押金有各自证据与未核边界。
怎样确认完成
- 形成原提案类型/身份、金额单位、同一时点指标、状态/纠纷、具体错误或Distributed及收款对照。
- documentation：未调用Graph/RPC、执行/仲裁/交易或核实际收款；缺证据字段保持未知。
常见错误与边界
- 支持权重达到目标不等累计Conviction超过门槛，显示四舍五入相等也不够。
- Funding与Signaling/Streaming不同；旧文档与新固定源码分支冲突保留，不保证当前streaming部署。
- 默认仲裁超时不是自动timer执行，ruling、押金退回和提案付款分开。