// MSG 采用无上限的按需铸造模型，其核心发行逻辑完全与 Wall Clock 解耦。
//
// 1. Economic Seconds:
//    经济时间 = 区块高度 * target_block_seconds。当前默认 5s，但允许通过治理调整 block time schedule。
// 2. 发行减半/递减模型:
//    系统累计经济时间每满 21,000,000 秒，铸造 1 个 MSG 所需的成本(时间间隔)就增加 1 秒。
//    这意味着发行速度随着时间推移自然放缓。
// 3. 宪法层 vs 治理层:
//    target_block_seconds 属于治理层运行参数；round_span_seconds / round_interval_increment / base interval
//    属于更高层发行规则边界，不应被当成普通运行时参数随意改写。
// 4. 当前公式锚点:
//    per_pool_reward_per_block = target_block_seconds / current_interval_seconds
//    per_pool_reward_per_second = 1 / current_interval_seconds
// 5. Reward Debt 与双池结算:
//    节点奖励按 Reward Debt 与双池全局累加器差值结算，不直接按 wall clock 固定发币。

// query_emission_state 请求:
{"query_msg":{"query_emission_state":{}}}

// 注意：
// 旧导航样本曾把 emission_state 写成 interval_seconds = 5。
// 但当前创世部署锚点 / emission_schedule_v2 定向测试显示 base interval = 1。
// 因此旧样本已不再作为“现行真值”继续展示，待补 fresh raw query 锁定 active emission_state。
//
// 代码与测试锚点：
// 1. pkg/genesis/node.go: emission_schedule_v2 instantiate interval_seconds = 1
// 2. emission_schedule_v2 定向测试:
//    reward_for_height_uses_block_time_schedule_and_economic_interval -> 首轮每池奖励 = 5 MSG/块
//    （前提：target_block_seconds = 5, current_interval_seconds = 1）

// query_pending_reward 请求:
{"query_pending_reward":{"pool":"validator","address":"msg58cb04041543b186e9def5d981b8d1c8518e444f6"}}

// pending_reward 成功响应:
{"success":true,"data":{"address":"msg58cb04041543b186e9def5d981b8d1c8518e444f6","amount":"0","pool":"validator"}}

// 错误地址格式会被显式拒绝:
{"success":false,"error":"Contract query error: wasmvm Query contract error: Generic error: addr_validate errored: invalid address: failed converting data to bytes: invalid character not part of charset: 98"}

这说明：
1. pending_reward 已有真实 query 响应，不只是规则说明。
2. 查询接口具备输入约束，错误地址不会被静默吞掉。
3. interval_seconds 的 active 真值，当前必须以 fresh raw query 重新锁定，不能继续沿用旧样本。

// emission 页当前必须明确 4 条边界：
// 1. 经济时间由 block height * target_block_seconds 推导，但这不等于“发行间隔驱动物理出块等待”。
// 2. target_block_seconds 可治理调整，但 per-second reward 的轮次递减规则不应被当成普通运行参数改写。
// 3. registry 提供的是 emission_schedule 的寻址与 active/reserved 状态，不直接负责结算。
// 4. slash 事件会改变 emission_state 中的 burned / slashed / challenger 统计，但处罚规则本身仍归 slashing 页解释。
//
// 所以这页的可信表达应是：
// - 讲经济时间、双池累加器、reward debt、claim 触发结算
// - 明确候选池当前代码链路是“candidate_inflow 先按 qualified_count / candidate_economic_denominator 缩放，
//   再由 qualified seats 做等额派息”
// - 明确 validator / candidate active cap 属于治理参数：validator 默认/最小 100，candidate 默认/最小 10000
// - 不把 registry、consensus、slashing 三个模块混成一个“大经济黑盒”

// emission 页现在明确串起 4 段走廊：
// 1. 寻址上游：
//    registry 负责 resolve emission_schedule active 地址。
// 2. 状态中段：
//    query_emission_state 暴露 interval_seconds / round_span_seconds / pool_balance。
// 3. 触发与下游：
//    claim / role_change / slash 触发结算；slashing 页补充处罚统计语义。
// 4. 证据回跳：
//    pending_reward 成功样本 + invalid address 失败样本都回到 evidence_index。
//
// 因而本页证明的是“发行结算逻辑可查询、可拒错、可串联”，
// 而不是把共识调度、Gas 分账、处罚制度偷换成 emission 单页已全部证明。