トークノミクス分析：供給量・発行・バーン・ベスティング・FDV

供給量は一つではなく、定義と時点を伴う

トークノミクスは、トークンの供給、配分、利用、価値移転、参加者のインセンティブを読む枠組みです。循環供給量は市場で移転可能とみなされる量、総供給量は発行済みからburn等を引いた量、最大供給量はprotocol上の上限または想定希薄化後量として使われます。しかし、locked tokenを循環へ含めるか、失われた鍵を除くか、bridge上のwrapped tokenをどう扱うかはdata providerにより異なります。

最初にblock explorer、公式docs、contract、treasury address、vesting contract、第三者data providerの定義を並べ、as-of timestampを揃えます。tickerが同じ偽tokenや、decimalの読み違いを避けるため、networkとcontract addressを固定します。upgradable contract、mint role、pause、freeze、blacklist等の管理権限も供給リスクの一部です。

必ず単位、decimal、network、contract、確認時刻、sourceを添えます。

価格×供給量で、時価総額とFDVを分ける

時価総額は一般に現在価格×循環供給量、fully diluted valuation（FDV）は現在価格×最大または希薄化後供給量です。価格2.5円、循環4億、最大10億なら時価総額10億円、FDV25億円、循環率40%です。残り60%が明日売られるという意味ではありませんが、将来どの条件で流通するかを調べる入口になります。

FDVは比較用の仮定値で、全tokenを現在価格で売却できることを意味しません。大量供給が市場へ出れば価格、liquidity、demandが変わるため、FDVを「将来の確定時価総額」と呼べません。反対に、低いFDVだけで安全とも言えません。価格発見が薄いpoolや少量取引で決まる価格を全供給へ掛けると、実現不能な大きな数字になります。複数tokenを束ねるbenchmarkやbasketは、株価指数の算出方法とmethodologyを参照し、構成銘柄・weight・rebalance・data sourceを分けて評価します。

新規発行とバーンをgrossではなくnetで追う

validator・staker報酬、liquidity incentive、ecosystem grant、airdrop、treasury支出は流通供給を増やし得ます。fee burn、buyback-and-burn、slash、失効は供給を減らし得ます。年率だけでなく、誰へ配分され、その受取人が売却可能か、報酬の原資が新規発行か利用者feeかを分けます。名目報酬が8%でも供給全体が10%増えれば、報酬を得ない保有者の相対持分は下がります。

burnには、誰も使えないaddressへ送る方式、protocolが供給から差し引く方式、買戻し後に焼却する方式があります。buybackがtreasuryへ移すだけなら循環供給の扱いは変わっても総供給が減らない場合があります。contract eventとsupply function、treasury transactionを確認し、marketing上の「deflationary」を自動的に受け入れません。

cliff・線形解除・受取人・流動性を同じcalendarへ置く

vestingはteamやinvestor等へ配分済みのtokenを時間または条件で移転可能にする仕組みです。cliffは一定期間まで解除せず一度にまとまって開放、linear vestingは期間中に連続または定期的に開放します。unlockは即時売却を意味しませんが、売却可能性とgovernance powerを変えます。release address、vesting contract、受取人分類、既存保有、market liquidityを一つのcalendarへ並べます。

「次回unlockが循環供給の5%」という数字だけでは影響を決められません。受取人が長期保有する、OTCで移転する、stakingへ回す可能性もあれば、薄いorder bookへ売却する可能性もあります。反対にunlock前でもderivativeや貸借で経済的exposureが移転していることがあります。価格予測ではなく、scenarioとevidence gapとして記録します。

将来予定は変更され得るため、実際のon-chain releaseを後から照合します。

top holder比率から取引所・bridge・treasuryを除外せず分類する

holder concentrationを見るとき、最大addressが取引所custody、bridge escrow、burn address、staking contract、treasuryである可能性があります。addressをそのまま一人のwhaleと数えると誤ります。しかし取引所addressでも、内部の実質保有者分布は公開されません。known label、contract code、transaction pattern、official disclosureを使い、分類できないaddressはunknownのまま残します。

governance tokenでは、一単位一票、delegation、quorum、proposal threshold、timelock、veto、guardian、upgrade keyを確認します。投票参加率が低いと、循環量の一部で重要変更が通ることがあります。token holder voteがあっても、frontend、multisig、oracle、legal entityを別主体が管理すれば、実効支配は分散していない場合があります。

snapshot・flow・scenarioの三つの表を更新する

実務では、①特定時点のpriceと各供給量、②期間中のissue・unlock・burn・treasury flow、③将来scheduleと複数scenarioを分けます。snapshotへ将来値を混ぜず、予定と実績を色分けします。sourceが変更された場合は旧値を上書きせず、revision logにreasonとtimestampを残します。contract upgradeやtoken migrationは旧・新contractのsupplyを二重計上しないようにします。

1. 01assetを特定

   network、contract、decimal、official docsを固定する。

2. 02供給snapshotを作る

   循環・総・最大・treasury・lockedを同時点で記録する。

3. 03flowを照合

   mint、burn、unlock、bridge、treasury transactionを分類する。

4. 04calendarを作る

   将来解除とemissionを月次・四半期で並べる。

5. 05反証条件を書く

   mint authority変更、schedule改定、流動性低下等の停止条件を定める。

Financial Templates Hubでsnapshot、source、確認日、unlock、未確認address、反証条件を保存し、必要ならTradingViewのchartとは別に供給flowを管理します。価格だけのbacktestは、現在存在するtoken supplyを過去へ適用するsurvivorship・look-ahead biasを含み得ます。staking報酬とインフレも同じ純供給表へ接続します。