经济模型综合：双币、积分与池子
本节要回答的问题
- 同一应用里 多种资产 如何分工：可交易主币、不可外转积分、池内流动性？
Coin+Token+ 嵌入式Balance如何组合而不互相污染口径？- 上线前 审计与产品 应共同过哪些检查项？
前置：§15.5、§15.9–§15.10。
模式 A：主链上币 + 闭环积分
| 资产 | 技术形态 | 典型约束 |
|---|---|---|
主币 GOLD | Coin<GOLD> | 开放环路；TreasuryCap 多签；可上 DEX |
积分 PTS | Token<PTS> + TokenPolicy | transfer / spend 受 Rule 约束；默认关闭 to_coin 或仅对白名单开放 |
衔接：活动期若允许 充积分，可对 from_coin 配置 额度上限 + 时间窗；退场时若开放 to_coin，必须单独审计 供应与套利。
模式 B：双 Coin 与 AMM
两种 Coin（如本书 SILVER 与另一 GOLD）通过 共享对象 AMM 兑换：池对象内 两个 Balance 记账，价格与手续费 由 AMM 模块定义。
关键：这里的 Balance 在 池子对象 内，不是 §15.7 的 地址 accumulator；产品文档应写清 「池内储备」≠「用户钱包 Coin 列表」。
模式 C：公会/赛季金库
GuildVault 持有 Balance<GOLD>，仅 GuildCap 或 治理多签 可 take/put。
玩家钱包仍持 Coin；公会国库 是 合约内账本，转移需 显式调用。
上线检查清单（建议）
- 供应：
TreasuryCap保管方案；是否make_supply_fixed/ burn-only；误铸 应急预案。 - 展示：
decimals与前端换算；多Coin合并展示 是否一致。 - 合规：是否
make_regulated；DenyList 运营流程与 epoch 提示。 - 闭环：
TokenPolicy是否已share_policy；to_coin/from_coin是否收窄。 - 口径：是否使用
send_funds；若使用，用户可见余额 是否包含 accumulator。
小结
没有万能模板；用 三层工具（Coin / Token / 嵌入式 Balance）拼出业务故事，并在文档里 写清每一种余额的定义。实战步骤见 hands-on.md。