經濟系統¶

本檔角色：虛擬貨幣、鑄幣、消耗、三層分潤的完整規範。算式見算式表.md §12–15；對應模組（實作）：程式架構/economy.md / 程式架構/ugc-fork.md / 程式架構/builtin-assets.md。

1. 設計目標¶

目標	機制
鼓勵創作	UGC 被用 → 創作者得幣（70/20/10 fork 分潤）
鼓勵競技	比賽勝場（3+ 人賽）→ 幣
抗 DDoS 上鏈	上鏈一律收費（無首次免費）+ 公版填補新人
抗 Sybil 經濟刷量	幣無外部價值 + 鑄幣速率封頂（場級資格 / K=5 / per-player / 月軟曲線）+ match facts 多簽 + canonical fold 全網同式推導（程式架構/ledger-admission.md §1）
無真實貨幣兌換	純 in-game，白皮書與遊戲內明確聲明
開源無分階段	第一天起即正式公開版本

2. 內部表示¶

〔ECON-R-001〕 金額：整數 bigint minor units（1 幣 = 100 minor units，最小 0.01 幣）
〔ECON-R-002〕 評分（rating）：整數 × 100（0–500，跨 peer 共識安全）
月軟曲線係數：整數 × 100（0–100）
〔LEDGER-R-006〕序列化：IPLD dag-cbor（canonical、跨 peer 一致、原生支援 bigint）
〔LEDGER-R-091〕簽章：sign(privateKey, ledgerSigningDigest(ledgerAddress, event))；digest 定義只引用程式架構/ledger-admission.md §1，不得在經濟模組另行重述
〔ECON-R-003〕 整除尾數抹零：所有鑄幣公式採 bigint 整除，截斷小數不發給任何人、不累加滯留池、不補給冠軍（算式表.md §13）

2.1 事件溯源不可篡改¶

整個經濟建立在 OrbitDB CRDT log + 帳本檢查點之上，所有經濟事件一旦寫入 ledger 即不可修改、不可撤銷：

鑄幣事件已成立 → 餘額永久變動，無「補償性 burn」回收
〔ECON-R-004〕 黑名單作品的歷史 royalty → 不回收（既得權益保護）
〔LEDGER-R-029〕比賽事實由 ⌊N/2⌋+1 完賽者集體簽章背書、後續不可單方面更改；事件不宣稱金額，canonical fold 依事件位置前態唯一推導，故全員共謀也不能自選 payout（程式架構/ledger-admission.md §1）
DerivedState 是純函數推導，可由任何 peer 重算驗證

事件不可篡改 ≠ 解讀不可修正——上列鎖的是事實層（事件史）；解讀層（derive / 結算規則）壞損時另有復原階梯，事件一筆不動：

參數壞損（config 值不當）：治理緊急回滾＝一筆 ConfigUpdateEvent 設回舊值、epoch +1（流程/治理事件.md §7）。
〔LEDGER-R-018〕 規則壞損（結算 / derive 邏輯 bug、漏洞遭刷）：修法＋全網重算——修正隨 derive_logic major 出貨（強制升級＋配對互擋，版本規範.md §2），全網以新規則重算 DerivedState、毒害在重算中消失。生效切點＝鏈上事件錨（指定帳本檢查點 CID / 事件位置，隨版寫死於 derive 規則；禁 wall-clock——deriveStateAt 純函數，資料系統.md §15.1）：規則因此 epoch 化（切點前依舊規則解讀——與 economy_config 分代適用同一哲學）。政策＝ 預設帶切點、既往不咎；僅 exploit 所得顯著失衡時允許追溯（自更早錨點以新規則重算、不當所得自動蒸發——僅及規則 bug 下的不當所得；合法所得的既得權益保護〔上列「不回收」各條、黑名單歷史 royalty 等〕不受影響）。切點與追溯範圍為該升版 PR 必載欄位（流程/升版.md §8.2）。
帳本壞損（事件史污染到不可解讀）：最後手段＝ 鏈重生（資料系統.md §19）。

3. 鑄幣分類¶

〔ECON-R-005〕 現行鑄幣來源只包含玩家行為驅動的比賽獎金與創作回饋金：

產出型（玩家行為驅動）              補助型（系統行為驅動）
├── match-prize（比賽勝場）           └──（目前無事件來源）
└── royalty（創作回饋金）
   ↓                                    ↓
計入 monthMinted                     計入 totalMinted
受月軟曲線抑制                       不受月軟曲線

判斷標準：玩家經濟活動產出 = 產出型；系統補助 / 一次性禮包 = 補助型（且必須有「每 PeerId 限頻」硬約束）。

補助型目前為空：分類框架保留，但沒有任何事件來源；新增來源必須另立 ADR 並定義可重算證據、限頻與 Sybil 防護。新玩家走不鑄幣的「首次上鏈負資產」機制（見 §10），首次上鏈可賒帳。

3.1 鑄幣來源封閉性¶

鑄幣 fold 只接受 §4 列出的兩種來源。挑戰、掛網、服務證明、節日與邀請都不是現行鑄幣事件；取捨與新增來源門檻見 D-20260817-01。

4. 鑄幣入口（兩項，皆產出型）¶

來源	觸發	公式	寫入方式
比賽勝場	場具鑄幣資格（finisherCount ≥ 3、全回合 anchor 齊全且 K=5 未超限，§6.2）	`base × finisherCount × rank% × monthFactor%`（rank = 完賽者排名、總名次序）	canonical fold 由 `MatchResultEvent` facts 推導
創作回饋金	UGC 被用、不在 24h 去重內、且場具鑄幣資格（§6.2）	`base × rating/5 × niche × monthFactor`	canonical fold 由同一事件位置推導

rating 由 ugc-rating 模組提供（信譽系統.md §3），整數量化 ratingX100 0–500。

5. 月軟曲線¶

月軟曲線的公式、整數量化、代表點與 floor 到 0 的停止條件只由算式表.md §12 定義。政策語意是當月已鑄量越高、後續產出型鑄幣係數越低； UTC 每月 1 日由 §5.1 的純函數 rollover 重設月份狀態。

5.1 月度跨界時序保證（共識關鍵）¶

〔ECON-R-006〕 每筆 mint 事件處理之前必須先呼叫 checkMonthRollover，避免「同筆事件在月初邊界前後 derive 結果不同」造成共識破壞：

function checkMonthRollover(state, now): state {
  const currentMonthStart = startOfUtcMonth(now);
  if (currentMonthStart > state.monthStartTimestamp) {
    return {
      ...state,
      monthMinted: 0n,
      monthStartTimestamp: currentMonthStart,
    };
  }
  return state;
}

〔ECON-R-007〕 事件溯源層面：不寫獨立的「month-reset」事件；由 derived state 推導時純函數判定跨月。computeMatchSettlement 以套用前 state.derivedAt 為時間基準，不用可倒填的 event.timestamp 或 finishedAt。ordinary genesis 的 derivedAt 與 monthStartTimestamp 取公開 receipt 的正整數 genesisTimestamp；正式 service/replica 缺值或不一致時 fail closed，rebirth 延續 checkpoint state。

此外另有治理 month_hard_cap_minor：fold 在入帳前檢查 monthMinted + incomingMint，大於 hard cap 時整場零入帳；等於 hard cap 可入帳。這是不可被舊時戳 append 繞過的聚合上限。

上為設計層完整定義（本檔權威）；實作層 orchestration（每筆 mint/burn 前呼叫點）見程式架構/economy.md §2。

6. 比賽獎金¶

computeMatchPrize 的唯一公式、截斷順序與範例見算式表.md §13。本節只定義獎金的產品語意與防刷界限。

獎金 per-match、與回合數 N 無關：1 回合與 N 回合 match 的競技獎金相同（competitor 獎金看總名次、不看 match 長度）；長 match 多賺的是 royalty（用到更多 UGC，§7）—— 刻意的內容多樣激勵。刷分上限由 K=5（§6.1）+ finisherCount ≥ 3 封頂。

6.1 24h K=5 防刷¶

〔ECON-R-008〕 同一完賽者組合的鑄幣資格採 rolling 24h、最多 5 場 match 的窗口。

〔ECON-R-009〕 組合身分以 sorted 完賽者 PeerIds 推導的 comboHash 決定；第 6 場起整場不鑄（獎金與 royalty 皆停、usage 統計不記，見 §6.2 場級鑄幣資格）：

comboHash = sha256(peerIds.slice().sort().join("\n")); // 分隔符 '\n'（跨 client 固定、實作權威）

〔ECON-R-010〕 防止固定 8 人圈刷無限獎金；K=5 計數 = 窗內合格場數（不合格場不佔窗）。

6.1b per-player 每日有獎場數上限¶

K=5 只鎖「完全相同組合」——輪換一名成員即是新 comboHash（12 帳號可輪出 495 種 8 人組合），故再加個人層上限：

〔ECON-R-011〕 同一玩家 rolling 24h 內領過比賽獎金的 match 數 ≥ player_prized_matches_per_day（20，match_prize 群組、待 playtest 校準）→ 該玩家本場獎金為 0（名次保留、不影響他人——finisherCount 與其他人金額照算）。
canonical fold 結算時自 recentPrizedMatches（程式架構/ledger-checkpoint.md §2，applyEvent 記錄、24h 窗）判定；時間與 config 都取事件位置前態，因此 replay 安全。
與 K=5 為雙層防線（組合層 + 個人層）；royalty 不經此限（§7.2 去重節流）。重度誠實玩家日常 < 20 場，幾乎無感。

6.2 斷線與棄賽的經濟處理¶

〔ECON-R-012〕 完賽人數（finisherCount）：完成整場比賽（N 回合）仍在場、未異常斷線、未主動棄賽者。比賽獎金與創作回饋金公式中的玩家數一律指 finisherCount，非開賽人數。（回合內全毀者只要不斷線 / 不退出仍續賽至 match 結束 = 完賽者；中途斷線 / 退出 = forfeit 整場、剩餘回合 DNF）

情境	經濟處理
〔ECON-R-013〕異常斷線者 / 主動棄賽者	forfeit：不計入 finisherCount、不發任何獎金；名次仍列「最後完賽者之後」供記錄 / TrueSkill / 信譽（比賽進行.md §12.2 / §12.4）；其 UGC 使用統計不記（沒鑄 royalty 就不佔 `(cid, player)` 去重窗，也不灌 totalUses）
〔ECON-R-014〕 finisherCount < 3	整場經濟 void：`matchPrizes = []`、`royalties = []` 全空（含創作者三層分潤）；但 `MatchResultEvent` 仍寫入完整名次，TrueSkill / matchRecords 照常更新；UGC 使用統計整場不記（防 usage-milestone +5 / 隱式評分靠 void 房灌量）

〔ECON-R-015〕 經濟 void 場仍套用斷線 −5，但不發完賽或連勝信譽加分（void 場不具競技意義；信譽系統.md §2.2）。

〔ECON-R-016〕 場級鑄幣資格（mintEligible）：finisherCount ≥ 3、每回合 inline anchor 皆非 null，且同 combo 24h 內未達 K=5。完賽者只多簽 match facts；computeMatchSettlement 在 canonical fold 依事件位置前態算出資格與金額（程式架構/ledger-settlement.md §5／程式架構/ledger-admission.md §1）。prizes / royalties / ugcUsageStats 三者一律同閘——不合格場整場不鑄、不記使用（堵 void 房與同組合連打灌 usage-milestone / 隱式評分，也免白佔 (cid, player) 去重窗）；forfeit 者於合格場亦不記。usage-milestone 信譽 +5 與隱式評分（算式表.md §19）皆吃此統計、自動繼承此閘。per-player 有獎場數上限（§6.1b）為個人層、只擋該員獎金、不影響場級資格。

〔ECON-R-017〕 劃界：信譽的比賽加分閘＝finisherCount ≥ 3（不含 K=5、與鑄幣資格刻意不同）——同組合第 6 場仍是真比賽、完賽 +1 合理，量由信譽自身 24h 日額（REPUTATION_MATCH_GAIN_DAILY_MAX）擋；勿誤對齊（信譽系統.md §2.2）。

finisherCount < 3 全場無鑄幣，是為了堵「開房後全體（或多數）斷線 / 棄賽刷比賽獎金或刷 royalty」——少於 3 人完賽的對局不具競技意義，不產生任何幣。即使 fold 將產生空 settlement，match facts candidate 仍走完整 ⌊N/2⌋+1 完賽者簽章流程（比賽結算.md §8.5）。

7. 創作回饋金（Royalty）¶

創作回饋金由 base、rating、niche 與月係數共同決定；公式、量化與代表算例只由算式表.md §14 定義。

royalty 受場級鑄幣資格閘（§6.2——void 場或 combo 超限場整場不鑄）；無 per-player 場數上限（§6.1b 只限比賽獎金）——已有 24h 同 (cid, player) 去重（§7.2）節流。

7.1 Niche 加成¶

〔ECON-R-018〕 讓「受眾少但精緻」的創作有體面回饋。倍率隨 rating 線性連續遞增、無邊界跳變，整數量化（回傳 ×100）：精確線性 clamp、端點與 nicheMultX100 量化由算式表.md §14 單一維護；本節只保留「連續、無邊界跳變」的產品政策。

7.2 24h 同 UGC 去重¶

〔ECON-R-019〕 同 (cid, player) 24h 內只算 1 次 royalty，避免重複使用刷量。去重窗錨定「上次實際鑄出 royalty」的時間；窗內繼續使用仍照記 totalUses／uniqueUsers／lastUsedAt，但不刷新發放錨，因此超過上次發放 24h 後可再次鑄出。

詳見算式表.md §14。

8. 三層分潤（70 / 20 / 10）¶

〔ECON-R-020〕 每筆 royalty 拆 3 層（依 fork 衍生樹）：

層	比例	對象
current	70%	當前 fork 創作者
parent	20%	直接 parent 創作者
grandparent	10%	祖先依深度衰減

封頂 3 層；治理可調（economy-config.md §17 economy-config.revShare）。

8.1 數學保證¶

〔ECON-R-021〕 currentTierPct + parentTierPct + grandparentTierPct = 100（pct 整數、不變式檢查——共識計算不用浮點比例）。

〔ECON-R-022〕 缺層份額（無 parent / grandparent）與整除殘留一律歸當前創作者——原創（無血緣）作品實拿 100%（無公共池機制；程式架構/economy.md §4 computeRoyaltyShares）。拆分後金額為 0 的層不建立 RoyaltyShare；MatchResultEvent 完全不承載 share，fold 只產生正額 share。

8.1b 版本後繼血緣（不同於 fork）¶

schema 版本升級走版本後繼邊（同創作者），與 fork 邊（衍生作品）分開（版權.md、版本規範.md §23）：

〔ECON-R-023〕 版本後繼邊不新增分潤層、不算衍生（fork 樹深度與三層比例不受影響）。
評分 / 使用次數 / fork 樹位置三項聚合在「血緣節點」層、不綁單一 CID → 升級自然延續，原作者即使停止維護、被他人 fork 後仍照 fork 樹領分潤。
ledger 以 AssetVersionUpgradeEvent（新 CID → 舊 CID 後繼邊）串接，DerivedState 在節點層 aggregate（資料系統.md）。

8.2 由 `computeRoyaltyShares` 拆分¶

canonical fold 內部產出 RoyaltyShare[]，放入當次純函數回傳的 MatchEconomySettlement.royalties，再由 applyEvent 原子套用；它不進 P2P candidate 或 MatchResultEvent，也不由完賽者簽章。每筆 share 同時保存 triggerPlayer（實際觸發該次分潤的完賽者）；作者／祖先是 recipient，兩者不得混用。fold 依 (sourceCid, triggerPlayer) 精確更新發放錨，不從收款人或同場其他玩家推測。

詳見算式表.md §15 + 版權.md §Fork 衍生樹。

9. 消耗入口¶

操作	費用 (minor units)	規則
〔ECON-R-024〕上鏈零件	50	每次都收費、無首次免費
上鏈場地	500	同上
UGC presentation metadata 更新	`metadata_update_minor`（current 0）	零件與場地共用；exact CID、不換 CID，完整事件與原子扣款規則見 UGC機制.md §4.4
場地 geometry 改	走 fork 流程	重新上鏈一個 child
〔ECON-R-025〕 schema 版本後繼升級	0	升級通道僅限跨破壞牆、恆免費（非破壞舊版無升級通道——本就活躍、mesh 鎖死無物可買）；條件 = 過 `AssetVersionUpgradeEvent` 收件驗證六條（舊 CID 低於最新破壞牆〔棄用 / unusable〕/ 同創作者 / 同 type / 版本單調 / 非仲裁黑名單 / mesh 指紋一致僅 extras 差異，程式架構/ledger-admission.md §1）；一般新上傳 / fork / 改 mesh 照常收費
〔ECON-R-026〕擴充正式車位	1000 扁平	無上限（純消耗入口）、不可退；newSlotIndex 強制 = `derive(count) + 1`；固定本機測試車位不購買、不入 Ledger
〔ECON-R-027〕 UGC 贊助 burn	≥ `max(1, sponsorship.min_amount_minor)`	target 必須已有上鏈 record；擋公版、擋黑名單、擋自己贊助自己；builder／live／fold 共用同一政策

9.1 作品贊助的永久聚合與榜單語意¶

贊助金額全數燒毀，不轉入作者餘額；作品榜只表示玩家對作品的歷來支持與能見度，不是作者收入榜。每筆有效 ugc-sponsor-burn 在 target UgcRecord 永久累加 sponsoredTotalMinor、sponsorEventCount，並以單調不降方式更新 lastSponsoredAt。同一付款人多次贊助只有在各自形成不同的 chain-bound 已簽意圖時才是多筆事件；同一已簽 payload 換 Orbit entry 重播由永久 processedPaymentIntents 擋成 no-op。DerivedState 不保存贊助者身分集合或逐筆贊助歷史，只保存 64 位 digest 去重鍵。

作品榜是永久累計榜：查詢時掃全部 ugcRecords，依 sponsoredTotalMinor 降序、CID 字典序平手裁決後才套 top-N；fold 不可裁掉榜外聚合。短期／近期創作者發現另由 weeklyTopCreators 承擔，不以時間窗重置作品贊助。系統不提供贊助者／人物榜，raw ledger 贊助事件只屬可逐出的暫時事件，不得作永久榜或 checkpoint 後累計的權威。

零件與場地共用同一個「上鏈倉庫」：兩者持有數皆無上限，只在上鏈時各付一次費（零件 50 / 場地 500），不另設「位數」擴充——上鏈費本身即節流，毋須再加硬上限。專職創作者可盡情累積場地庫。 車位（loadout）是本地組裝存檔（車輛組裝.md §7、不上鏈、對網路零成本）；Ledger 只記正式車位 entitlement 數量。每裝置固定一個本機測試車位，不購買、不計入正式車位數。正式車位擴充純為消耗入口故無上限。 首次上鏈允許負資產：每個 PeerId 一生一次，新上傳或 fork 都由 UgcUploadEvent 燒費；即使餘額不足也放行，餘額入負 = 該次上鏈費（≤ 500，天然封頂、不另設債務上限）。上鏈費只由 UgcUploadEvent 收取，UgcForkEvent 是免費血緣宣告；其餘消費一律要餘額 ≥ 0。詳見 §10。

10. 首次上鏈負資產¶

〔ECON-R-028〕 新玩家的啟動資源採首次上鏈負資產，不採鑄幣：每個 PeerId 一生一次，首次 UgcUploadEvent 燒上鏈費時即使餘額不足也放行，餘額允許入負；原創與 fork 都寫 upload 並在此單次收費，另寫的 UgcForkEvent 免費。此機制不鑄幣（只是允許餘額為負），淨補貼 ≤ 一次上鏈費，且由後續 match-prize / royalty 入帳自動還清。

設計要點：

限縮在上鏈：只有上鏈燒費（50 / 500）能入負；擴車位（1000）、UGC 贊助等其他消費一律要餘額 ≥ 0。
僅限一次：DerivedState 旗標 firstUploadDebtUsed，每 PeerId 用過即永久設旗（不論還清與否，不再給第二次）。
無另設債務上限：債務天然被「那一次上鏈費」封頂（≤ 500），毋須 DEBT_LIMIT 常數；治理調整上鏈費時上限自動跟動。
自動還債：負資產期間 match-prize / royalty 入帳直接抵債（餘額朝 0 回升）；還清前禁止其他消費（嚴格 ≥ 0 檢查自然擋下）。

10.1 applyEvent 共識邏輯（上鏈燒費）¶

// 只處理 UgcUploadEvent 的上鏈費（原創／fork 都寫；fee = 50 零件 / 500 場地）
if (balance >= fee) {
  balance -= fee; // 正常付費
} else if (!state.firstUploadDebtUsed.has(peerId)) {
  balance -= fee; // 首次上鏈、餘額不足 → 入負（負額 ≤ fee）
  state.firstUploadDebtUsed.add(peerId); // 永久設旗，一生一次
} else {
  reject("insufficient balance"); // 已用過賒帳 + 餘額不足 → 拒絕
}

〔ECON-R-029〕 state.firstUploadDebtUsed.has(peerId) 為 DerivedState 快取，純函數可由任何 peer 重算驗證。其他燒幣事件（SlotPurchaseEvent / UgcSponsorBurnEvent）走嚴格 balance >= amount 檢查、不得入負——共識側於 applyEvent 驗（client builder 檢查僅 UX 前置）：不足＝事件無效 no-op（apply 序決定性、雙花由 log 序裁）；newSlotIndex ≠ 現有 +1 同無效（防跳級）。見程式架構/economy.md §2。

上為設計層完整 if/else 共識邏輯（本檔權威）；實作層 applyUploadBurn orchestration 骨架見程式架構/economy.md §3。

11. 速率限制（防刷彙整）¶

限制	內容
月軟曲線	月初 UTC 1 號重置；monthMinted > 99×softCap → 係數 0（等效月硬頂，§5）
場級鑄幣資格	`mintEligible` = finisherCount ≥ 3、每回合 inline anchor 皆非 null 且 combo 未達 K=5——prizes / royalties / usage 統計同閘（§6.2）
24h K=5	同 comboHash 24h 內最多 5 場合格場（§6.1）
per-player 有獎場數	同一玩家 24h 內最多 `player_prized_matches_per_day`（20）場領比賽獎金（§6.1b）
24h 同 UGC 去重	同 (cid, player) 24h 內只算 1 次 royalty（自用同規則、無另設 cooldown）
〔LEDGER-R-030〕 canonical fold 結算	`MatchResultEvent` 不帶 payout/frontier；live 與 timeless fold 共用自包含 facts 驗證，金額只由事件位置前態與公式推導（程式架構/ledger-admission.md §1）
簽章門檻	比賽結算需 ⌊N/2⌋+1 完賽者多簽
首次上鏈負資產	每 PeerId 一生一次（`firstUploadDebtUsed` 旗標，見 §10）

12. 跨模組整合¶

Economy ←→ Ledger（事件結構 + DerivedState 權威）
        ←→ Matchmaking（賽前 loadout + 賽後簽章）
        ←→ Rating（UGC 評分）
        ←→ Fork（70/20/10 分潤）
        ←→ Moderation（黑名單擋鑄幣）
        ←→ Reputation（評分權重依信譽 → rating → royalty；使用 / 高評分里程碑 → 信譽加分）
        ←→ Builtin-assets（公版資產初始填補新人）

13. 整除截斷尾數（共識關鍵）¶

computeMatchPrize 與 computeRoyaltyForUgc 一律用 bigint 整除：

50 × 8 × 14 × 67 = 375,200
375,200 / 10,000 (bigint) = 37   ← 真實值 37.52，小數截斷

5 個第 4–8 名都拿 37 minor units，「失蹤」5 × 0.52 ≈ 2.6 minor units 不入任何人口袋。

為何用 bigint 整除而非分配補回（共識安全論證）：

所有 peer 對同一 canonical event order 與前態執行相同 bigint 公式，必須得到完全一致的 DerivedState；簽章只背書 match facts
補回邏輯（例：剩下的給冠軍 / 進滯留池 / 平分尾數）任一細節歧異 → 共識炸裂
bigint / 是純粹行為（spec 定義為 Math.trunc(a / b)），跨 JS 引擎（V8 / SpiderMonkey / JavaScriptCore）、CPU 架構（x86 / ARM）、硬體浮點實作結果一致
浮點數 / 則有 IEEE 754 rounding mode 差異風險，不適合共識
月初係數 100 時無截斷（公式皆整除）；只有月中跨界後才出現截斷

14. 治理（economy-config）¶

預設值見 economy-config.md §17。

變更流程：

提案 proposeUpdate(next, signature) → multisig 收集簽章
簽章門檻達標 → OrbitDB 寫入新版本
epoch +1
廣播給所有 peer
runtime 從 OrbitDB 讀最新值

不改 spec 預設值（spec 預設只用於首次部署）。

15. 無真實貨幣兌換¶

幣純 in-game，無 fiat / crypto 兌換管道
白皮書與遊戲內明確聲明
開源專案，幣本身無投機 / 投資意涵

16. 對應模組¶

模組	內容
程式架構/economy.md	鑄幣 / 結算 / 消耗實作（公式見算式表.md；本檔即完整設計 overview）
程式架構/ugc-fork.md	Fork 偵測 / 衍生樹（70/20/10 拆分在程式架構/economy.md §4）
程式架構/ugc-rating.md	UGC 評分（整數量化 Bayesian / 隱式 fallback）
程式架構/builtin-assets.md	公版資產（`builtin:*` / hard-code / 清單 / 維護）
資料系統.md / 程式架構/ledger.md	event schema + DerivedState（設計 / 實作）