🪙TOKEN-2022 図解ハンズオンVISUAL HANDS-ON DATA: 2026.06

ルールを内蔵した、お金。Money with the rules built in.

旧来のSPLトークンは「数を数える」だけの最小限の箱でした。手数料も、メタデータも、コンプライアンスも、ぜんぶ外付けの独自実装。Token-2022(Token Extensions)は、その箱に公式の引き出しを足せる新しいトークンプログラムです。全部の引き出しを、図解で開けていきましょう。 The original SPL Token was a minimal box that could only count. Fees, metadata, compliance — all bolted on with custom hacks. Token-2022 (Token Extensions) lets you add official drawers to that box. Let's open every drawer, visually.

00 / WHY

なぜ「第2のトークンプログラム」が必要だったのかWhy Solana needed a second token program

Solanaのトークンは、1つの共有プログラム(SPL Token)が全銘柄を処理する方式です。軽くて速い反面、「全銘柄が同じルール」という制約がありました。手数料を取りたい、譲渡を禁止したい、名前をオンチェーンに置きたい——そのたびに開発者は外付けの回避策を発明してきました。 On Solana, one shared program (SPL Token) processes every token. Light and fast — but it meant every token had the same rules. Want a transfer fee? Soulbound tokens? On-chain names? Developers kept inventing external workarounds.

🤔 まず予想してみようPredict first

旧SPLトークンで「送金のたびに1%の手数料を取る」には、どうすればいい?With the original SPL Token, how do you charge a 1% fee on every transfer?

✅ B. 旧トークンに手数料の概念はありません。だからプロジェクトは「トークンを凍結して専用プログラム経由でしか動かせなくする」「ラッパートークンを被せる」などのハックで実現していました。ウォレットやDEXとの相性問題が頻発し、誰も幸せになりませんでした。Token-2022はこうしたニーズの定番解を、監査済みの公式拡張として提供します。The old token has no concept of fees. Projects resorted to hacks — freezing tokens so they could only move through a proxy program, or wrapping them — causing endless wallet/DEX compatibility pain. Token-2022 ships these common needs as audited, official extensions.

🧩 Before / After:外付けハックから、内蔵の引き出しへBefore / After: from bolted-on hacks to built-in drawers

BEFORE:旧SPL TokenBEFORE: legacy SPL Token 🪙 Mint 数を数えるだけjust counts 🏷️ Metaplex メタデータは別世界metadata elsewhere 🧊 凍結ハックfreeze hack 疑似・譲渡制限pseudo-restrictions 📦 ラッパー独自実装custom wrappers 手数料・ロイヤリティfees & royalties 📋 オフチェーン名簿off-chain lists KYC・許可リストKYC / allowlists ニーズのたびにバラバラの独自実装が乱立a new bespoke hack for every need AFTER:Token-2022AFTER: Token-2022 🪙 Mint 基本部分はbase layout 旧型と同一unchanged 82 bytes 💸 Fee 🪝 Hook 🏷️ Meta 🕶️ Conf. 使う分だけopt-in, オプトインpay-as-you-go 監査済みの「公式の引き出し」をミントに直接追加audited official drawers, attached right to the mint ウォレットやdAppは1つの標準に対応すればOKwallets & dApps integrate one standard
💡
Token-2022は旧トークンを「置き換え」ません。Token-2022 does not replace the legacy token. 2つのプログラムは別アドレスで並存し、既存トークンは旧プログラムのまま動き続けます。既存トークンを後からToken-2022に移行することもできません(新しいミントとして発行し直す必要があります)。The two programs coexist at different addresses; existing tokens keep running on the legacy program. You can't migrate an existing mint — features require issuing a new Token-2022 mint.
Tokenkeg...Q5DA 旧 SPL Tokenlegacy SPL Token
TokenzQd...PxuEb Token-2022

🗺️ このガイドの歩き方How to read this guide

01でデータ構造のしくみ(TLV)と「ミント・ビルダー」を触り、02でミント側の拡張18種をすべて図解、03で保有者側のアカウント拡張、04で最重量級の秘匿送金を深掘り、05で実例と歴史を見ます。上のタブはどこからでも読めますが、初めてなら左から順がおすすめです。01 covers the data structure (TLV) with an interactive Mint Builder, 02 diagrams all 18 mint-side extensions, 03 covers holder-side account extensions, 04 deep-dives confidential transfers, and 05 shows real adopters and the timeline. Tabs work in any order; left-to-right is best for first-timers.

01 / ANATOMY

しくみ:TLVという「後ろに伸びる引き出し」Anatomy: TLV, the drawers that grow at the back

Token-2022の互換性の秘密はデータ配置にあります。ミントの先頭82バイト、トークン口座の先頭165バイトは旧型とまったく同じ。拡張のデータはその後ろに TLV(Type-Length-Value)形式——「種類・長さ・中身」のラベル付き引き出し——として積まれていきます。だから旧型を読めるツールは基本部分をそのまま読めるのです。 The compatibility secret is in the layout. The first 82 bytes of a mint and 165 bytes of a token account are identical to the legacy program. Extension data is appended after them in TLV (Type-Length-Value) form — labeled drawers of "kind, size, contents." Tools that read the old format can still read the base.

基本データ(旧型と同一)base data (legacy-identical) mint: 82 B / account: 165 B type T: TransferFee L: 108 V: 料率・権限…rate, auth… T: MetadataPointer L: 64 V: 参照先…address… + … 旧ツールはここだけ読んでも動くlegacy tools can read just this 対応ツールはラベルを見て必要な引き出しだけ開けるaware tools open only the drawers they need

DEMOミント・ビルダー:自分のトークンを設計してみようMint Builder: design your own token

拡張をONにするたびに、ミントアカウントが実際にどう伸びるかを見てみましょう。衝突する組み合わせは赤く点灯します。最後に「初期化」を押すと——もう引き出しは追加できません。 Toggle extensions and watch the mint account physically grow. Conflicting combos light up red. Then press "Initialize" — and no more drawers can ever be added.

82bytes
アカウントサイズ(概算)account size (approx.)
0.0015SOL
レント預託(概算)rent deposit (approx.)
0ext
有効な拡張extensions on
💡
数値は概算です。Numbers are approximate.バイト数は各拡張のデータ構造から、レントは「(サイズ+128)×約6,960 lamports」から算出した目安で、実測値ではありません。またミント拡張は初期化後に追加不可ですが、アカウント拡張(タブ03)はReallocate命令で後付けできるという違いがあります。Byte counts come from each extension's struct and rent from "(size+128) × ~6,960 lamports" — estimates, not measurements. Also: mint extensions can't be added after init, but account extensions (tab 03) can be added later via the Reallocate instruction.

⚖️ なぜ「組み合わせ不可」があるの?Why are some combos forbidden?

ルールには2つの階層があります。ソースコード(初期化時のチェック関数)で確認した正確な区分です:There are two tiers of rules — verified directly in the source (the init-time check function):

① プログラムが拒否する5パターンFive combos the program rejects — (1) 秘匿手数料は「手数料+秘匿送金」の両方が前提 (2) 逆に、手数料+秘匿送金を併用するなら秘匿手数料が必須 (3) 秘匿発行・焼却は秘匿送金が前提 (4) 表示倍率×利付は不可(表示の二重定義) (5) 譲渡不可×秘匿送金は不可——ただし秘匿発行・焼却も足せば「発行と焼却だけ秘匿のソウルバウンド」として通ります。初期化がInvalidExtensionCombinationで失敗します。(1) Confidential Fee requires both TransferFee and ConfidentialTransfer; (2) conversely, TransferFee + ConfidentialTransfer demand Confidential Fee; (3) Confidential Mint-Burn requires ConfidentialTransfer; (4) ScaledUiAmount × InterestBearing is out (double display redefinition); (5) NonTransferable × ConfidentialTransfer is out — unless Confidential Mint-Burn joins, making a soulbound token with confidential mint/burn valid. These fail at init with InvalidExtensionCombination.

② 通るけれど無意味な組み合わせCombos that pass but make no sense — 「譲渡不可×手数料」「譲渡不可×フック」は発動する送金が存在しません。初期化チェックでは拒否されませんが、公式ドキュメントも非互換の例として挙げています。Non-Transferable with fees or hooks: no transfer ever fires them. The init check lets them through, but official docs list them as incompatibilities.

💡 意外な事実:「秘匿送金×フック」は併用可能です。秘匿送金時もフックは呼ばれますが、金額は見えません(慣例としてu64::MAXが渡される)。実際、PYUSDは両方を初期化しています。Surprise: ConfidentialTransfer × TransferHook is allowed. The hook fires on confidential transfers too — it just can't see the amount (it receives u64::MAX by convention). PYUSD initializes both, in fact.

02 / MINT EXTENSIONS

ミント拡張 全18種 図鑑The complete field guide: all 18 mint extensions

ミント拡張は発行者が決める「そのトークンの法律」です。全保有者に等しく適用されます。まず代表選手2つ(手数料とフック)を動くデモで体感し、そのあと18種すべてをカードで開いていきましょう。カードをタップすると図解が出ます。 Mint extensions are the token's laws, set by the issuer and applied to every holder. First, feel the two stars (fees & hooks) in motion — then open all 18 cards. Tap a card for its diagram.

DEMO💸 手数料の旅:お金はどこに「たまる」?The fee's journey: where does it pile up?

🤔 まず予想してみようPredict first

Alice が Bob に100枚送ると、手数料1枚はどこへ行く?Alice sends Bob 100 tokens. Where does the 1-token fee go?

✅ B. 意外なことに、手数料は受取人の口座内の「留保ポケット」に入ります。Bobには見えますが使えません。回収(harvest)は誰でも実行でき、ミントに集めてから引き出し権限者だけが金庫へ移せます。下の▶で流れを見てみましょう。Surprisingly, the fee lands in a withheld pocket inside the recipient's account — visible to Bob, unusable by Bob. Anyone can harvest it to the mint; only the withdraw authority moves it to the treasury. Press ▶ below.
👩 Alice 1,000 送信者sender 👨 Bob 0 留保ポケット 🔒withheld pocket 🔒 0 🪙 Mint 0 回収プールharvest pool 🏦 金庫Treasury 0 引出権限者のみauthority only ① 100枚送信 → 99がBobへ① send 100 → Bob gets 99 ② harvest(誰でも可)② harvest (anyone) ③ 💰 ▶ を押すと、1回の送金から金庫到達までの3ステップが流れますPress ▶ to watch the three steps from one transfer to the treasury
💡
細かいけど効くルール3つ。Three small rules that bite.(1) 料率はベーシスポイント+上限額で設定。(2) 料率変更は2エポック後に発効(駆け込み変更の防止)。(3) 留保が残る口座は閉じられない——先にharvestが必要です。(1) Fees are set in basis points plus a max cap. (2) Rate changes take effect two epochs later (no rug-style instant hikes). (3) An account with withheld fees can't be closed until harvested.

DEMO🪝 送金フック:門番にはなれるが、泥棒にはなれないTransfer Hook: a gatekeeper that can't pickpocket

フックは送金のたびにCPI(プログラム間呼び出し)で呼ばれる発行者指定のゲストプログラム。許可/拒否は決められますが、渡される口座はすべて読み取り専用に変換され、送信者の署名権限も剥奪されます。送金先を切り替えて試してみましょう。 A hook is an issuer-chosen guest program invoked via CPI on every transfer. It can approve or reject — but every account it receives is made read-only and the sender's signer privileges are stripped. Try both recipients.

送金先:Recipient:
👩 Alice 送信者sender ↩ 残高は減っていないbalance unchanged ⚙️ Token-2022 送金処理の本体core transfer logic 処理後にフックを呼ぶcalls hook after logic CPI 🪝 フックプログラムhook program 許可リストを照合中…checking allowlist… 🔒 accounts: read-only 🔒 signer privileges: dropped ExtraAccountMetaList → 追加口座を自動解決auto-resolves extra accounts 👨 Bob 0 🧑 Carol 0 💰 ✓

▶ を押すと送金が始まり、フックが判定します。Carol宛てだと送金は最初から成立しません——切り替えて確かめてみてください。Press ▶ to start a transfer and let the hook judge. With Carol, the transfer never happens at all — try it.

💡
フック=安全、ではありません。Hook ≠ automatically safe.フックの仕組み(読み取り専用・署名剥奪)はトークンの横取りを防ぎますが、フックプログラム自体のロジックは発行者の自由です。送金を恣意的にブロックしたり、予期しない動きをすることもあるため、Ledger等のウォレットはフック付きトークンに警告を表示します。The mechanism (read-only accounts, dropped signers) prevents pickpocketing, but the hook's own logic is up to the issuer — it can arbitrarily block transfers or behave unexpectedly, which is why wallets like Ledger show warnings for hooked tokens.

📖 全18種を開くOpen all 18

カテゴリは「お金の見え方を変える」「発行者の権限」「つながる・名乗る」「秘匿」の4系統。気になるカードをタップ。Four families: how money looks, issuer powers, identity & connection, and privacy. Tap any card.

🔭
予告:19番目の拡張が準備中です。Coming up: a 19th extension is in the pipeline.公式リポジトリにはPermissionedBurn(焼却に専用権限者の許可を必須にする拡張)が追加済みですが、2026年6月時点で公式ドキュメントには未掲載=展開前の段階とみられます。本ページの「18種」はドキュメント掲載済みのものです。The official repo already contains PermissionedBurn — an extension requiring a designated authority's approval to burn — but as of June 2026 it isn't in the official docs yet, i.e. pre-rollout. The "18" on this page counts the documented ones.
03 / ACCOUNT EXTENSIONS

アカウント拡張:保有者が選ぶ「自衛オプション」Account extensions: self-defense, chosen by the holder

02のミント拡張が「発行者の決める法律」なら、アカウント拡張は保有者が自分の口座に付ける装備です。ユーザーが自分で付けるのは3種。さらに、ミント側の拡張に応じて自動で貼られるステッカー(派生状態)が6種あります。 If mint extensions are the issuer's laws, account extensions are gear holders attach to their own accounts. Three are user-chosen — and six more are stickers applied automatically when the mint has certain extensions.

🏷️ ミントとセットで付く6つのステッカーThe six stickers that come with the mint

「手数料あり」のミントの口座を作ると、自動的に「留保ポケット」が生えます。発行者の法律が、保有者の口座に対応する状態を必要とするからです。ソースコード上、口座作成時に自動で強制されるのは4種(手数料・譲渡不可・フック・停止系)。秘匿系の2種は、保有者が秘匿送金を自分で設定したときに付きます。さらに譲渡不可ミントでは、ImmutableOwner(所有者ロック)も自動で強制されます。銀行にたとえると、ミント=銘柄の約款、ステッカー=通帳に最初から印刷されている専用記入欄。約款が手数料を定めていれば、新しい通帳には必ず「留保額」欄が刷られて出てくる、というイメージです。 Open an account for a fee-enabled mint and a "withheld pocket" grows automatically: the issuer's laws need matching state on holder accounts. Per the source code, four are forced at account creation (fee, non-transferable, hook, pausable); the two confidential ones attach when the holder configures confidential transfers. Non-transferable mints additionally force ImmutableOwner onto every account. Think of the mint as a token’s terms-and-conditions and the stickers as the dedicated columns pre-printed in every new passbook: if the terms define a fee, every passbook comes with a "withheld" column.

🪙 Mint 発行者の法律issuer's laws 💸 Fee / 🪝 Hook / ⛓️ NT / ⏸️ Pause / 🕶️ CT 対応する状態を要求requires matching state 👨 保有者の口座holder's account ① TransferFeeAmount (留保ポケット)(withheld) ② TransferHookAccount (送金中フラグ)(transferring) ③ NonTransferableAccount ④ PausableAccount ⑤ ConfidentialTransferAccount* ⑥ ConfidentialTransferFeeAmount* *は秘匿送金を設定した口座のみonly on confidential-configured accounts 役割:法律の執行に必要なrole: per-account state 口座ごとの帳簿・印the laws need to run 例:送金中フラグ(②)はe.g. the transferring flag (②) フックの再入攻撃を防ぐblocks hook re-entrancy ⛓️ミントでは🔏所有者ロックも⛓️ mints also force 🔏 自動で強制されるImmutable Owner
💡
アカウント拡張は「後付け」できます。Account extensions can be added later.ミント拡張と違い、既存の口座にもReallocate命令でスペースを増やして追加可能。たとえば「最近怪しいdAppが増えたからCPI Guardを今から付ける」ができます。なおImmutable OwnerはToken-2022のATA(関連トークン口座)では最初から強制適用です。Unlike mint extensions, you can grow an existing account with the Reallocate instruction and add them — e.g. "sketchy dApps are multiplying, let me add CPI Guard now." Note Immutable Owner is enforced by default on Token-2022 ATAs.
04 / CONFIDENTIAL

秘匿送金:金額だけを、そっと隠すConfidential transfers: hide the amount, only the amount

最重量級の拡張ファミリーです。ElGamal暗号とゼロ知識証明で残高と送金額を暗号化します。隠れるのは金額だけ——誰から誰へ送ったか(アドレス)は公開のまま。匿名化ではなく「給与額を同僚に見られない」レベルの秘匿で、監査人キーによる開示にも対応します。 The heavyweight family. ElGamal encryption plus zero-knowledge proofs encrypt balances and amounts. Only amounts are hidden — sender and recipient addresses stay public. Not anonymity, but "coworkers can't see your salary" confidentiality, with optional auditor-key disclosure.

DEMO🕶️ 2段階残高の旅:Pending → AvailableThe two-stage journey: Pending → Available

👩 Alice (口座は公開address public) 公開残高public balance 100 秘匿・保留(pending)confidential pending ▩▩▩▩ 秘匿・利用可能(available)confidential available ▩▩▩▩ ① Deposit ② Apply 🔭 エクスプローラの見え方what explorers see from: Alice ✓ 公開public to: Bob ✓ 公開public amount: ▩▩▩▩ + ZK proof 🕵️ auditor: ▩▩▩▩ 👨 Bob pending ▩▩▩▩ available ▩▩▩▩ ③ 暗号化したまま送金(ZK証明つき)transfer while encrypted (with ZK proof) ▶ で「公開→保留→利用可能→送金」の流れを再生。🔑 で監査人だけが復号できる様子を確認。▶ plays public → pending → available → transfer. 🔑 shows what only the auditor can decrypt.

🤔 なぜ「保留(pending)」を挟むの?Why the pending stage?

秘匿送金では、送る前に手元でゼロ知識証明を作成します。証明は「いまの暗号化残高」を素材に作るため、作成中に着金して残高が変わると証明が無効になってしまう。下のデモで「保留が無い世界🅰」と「実際の設計🅱」を比べてみましょう。Before sending, you build a zero-knowledge proof from your current encrypted balance — so an incoming transfer mid-proof would invalidate it. Compare a world without pending 🅰 against the real design 🅱 below.

🅰 もし「保留」が無かったらif there were no pending 👩 Alice 残高(available)balance (available) enc(100) 📝 ZK証明を作成中…building ZK proof… 素材:input: enc(100) 「40を送る」(数秒かかる)"send 40" (takes seconds) 🧑 Carol +30 👨 Bob ✗ 証明が無効→失敗proof invalid → fails 🅱 実際の設計(保留あり)the actual design (with pending) 👩 Alice available: enc(100) 保留(pending)pending — 📝 ZK証明を作成中…building ZK proof… 素材:input: enc(100) 「40を送る」"send 40" 🧑 Carol +30 👨 Bob 0 ✓ 証明は有効→成功proof valid → success 同じ「+30の着金」が、上では送信を壊し、下では何も壊さないthe same +30 deposit breaks the send above — and nothing below

🧱 支える3つの部品The three moving parts

⚙️ Token-2022 残高・口座のロジックbalance & account logic 秘匿系の拡張3兄弟を提供hosts the 3 confidential exts 🧮 ZK ElGamal Proof 検証専用のネイティブプログラムnative proof-verifier program ZkE1Gama1Proof1111… 🔑 鍵と証明(手元)keys & proofs (client) ElGamal鍵で暗号化・復号encrypt/decrypt with ElGamal keys + 任意の監査人キー+ optional auditor key 「同じトランザクション内で証明を検証→残高更新」の2人3脚で動くthe two programs run in lock-step: verify the proof, then update balances — in one transaction
💡
正直ポイント:秘匿送金は波乱の歴史を歩んでいます。Honesty note: confidential transfers have had a turbulent ride. 2025年4月と6月、検証側のZK ElGamal Proofプログラムに「偽の証明が通ってしまう」脆弱性が相次いで報告されました(実被害ゼロ)。2025年6月にはエポック805でプログラム自体が無効化され、2025年8月に公開監査(Code4rena)を実施。修正と公開監査は完了し、Agave 4.0自体は展開済み。再有効化は4.0リリースサイクル内のfeature gate有効化として予定されていますが、2026年6月時点では公式ドキュメントに「一時無効化中」の注記が残っています(=スイッチはまだ入っていない、あるいは直前の段階)。PYUSD・AUSD・USDGなどは秘匿送金を「初期化済み・未開放」のまま待機しています。本ページ公開時には最新ステータスの再確認を。 In April and June 2025, vulnerabilities allowing forged proofs were reported in the ZK ElGamal Proof program (zero real-world losses). The program was disabled at epoch 805 in June 2025, publicly audited via Code4rena in August 2025, and the fixes shipped. Agave 4.0 itself has rolled out; reactivation is queued as a feature-gate activation within the 4.0 cycle — but as of June 2026 the official docs still carry the \u201ctemporarily disabled\u201d notice, i.e. the switch isn\u2019t flipped yet (or is just about to be). PYUSD, AUSD, and USDG have it initialized but not yet user-facing. Re-verify the latest status before publishing.
⚠️
いまの制約も2つ。Two current limits.(1) 秘匿口座を操作できるのは通常のウォレット(EOA)だけで、スマートコントラクトからは扱えない=秘匿DeFiはまだできない。(2) 受取人が先に秘匿口座を設定していないと送れない。この穴を埋めるC-SPLのような外部プロジェクトも動いています。(1) Only regular wallets (EOAs) can operate confidential accounts — programs can't, so confidential DeFi isn't possible yet. (2) Recipients must pre-configure a confidential account before you can send. External projects like C-SPL aim to fill these gaps.
05 / ADOPTION & TIMELINE

誰が使っている? そして、ここまでの道Who's using it — and the road so far

Token-2022の主戦場は規制対応ステーブルコイン・RWA・新世代NFTです。実在のプロジェクトが、どの引き出しを開けているかを見てみましょう。 Token-2022's home turf is regulated stablecoins, RWAs, and next-gen NFTs. Here's which drawers real projects have opened.

💵 PYUSD PayPal / Paxos

PayPalのステーブルコイン。2025年後半にはSolana上の流通量が3ヶ月で約2.5億→10億ドル超へ急成長。注目はその設計:「ミント拡張は後から追加できない」ため、手数料(0%に設定)・フック(無効値)・秘匿送金(未開放)まで将来に備えて初期化だけしてあります。タブ01の教訓のお手本です。PayPal's stablecoin; on-Solana supply grew ~$250M → $1B+ in three months in late 2025. The design is the star: since mint extensions can't be added later, fees (set to 0%), a hook (null) and confidential transfers (not yet open) are all initialized ahead of time — a textbook case of tab 01's lesson.

🛡️ PermanentDelegate🏷️ Metadata💸 Fee 0%🪝 Hook*🕶️ Confidential*
💵 USDP Paxos

NY州金融サービス局(NYDFS)規制下のステーブルコイン。規制要件を満たすため永久委任を有効化し、不正資金のクローバックを可能に。秘匿送金も有効化した規制×プライバシーの代表例。An NYDFS-regulated stablecoin. Enables Permanent Delegate for regulatory clawback of illicit funds, plus confidential transfers — the flagship "regulation × privacy" example.

🛡️ PermanentDelegate🕶️ Confidential*
🖼️ WNS Wen New Standard

Token-2022の拡張だけで組み上げられたオープンソースNFT標準。メタデータ・グループ/メンバー・送金フック・Immutable Ownerを組み合わせ、外部依存のない「素のNFT」を実現。An open-source NFT standard built purely from Token-2022 extensions — metadata, group/member, transfer hooks, immutable owner — NFTs with zero external dependencies.

🏷️ Metadata📁 Group/Member🪝 Hook
🏦 そのほかの波The wider wave

AgoraのAUSD、PaxosのUSDG(Global Dollar)などの新興ステーブルコインがToken-2022を採用。日本勢ではGMOトラストが規制準拠ステーブルコインでの活用を表明した経緯も。RWA(トークン化国債など)ではScaled UI Amountが定番化しつつあります。Newer stablecoins like Agora's AUSD and Paxos's USDG adopted Token-2022; Japan's GMO Trust signaled plans for a regulated stablecoin. In RWAs (tokenized treasuries), Scaled UI Amount is becoming standard kit.

✖️ ScaledUiAmount⏸️ Pausable🧊 DefaultState

* 初期化済み・未稼働(秘匿送金はタブ04参照)initialized, not active (for confidential transfers see tab 04)

🗓️ 年表Timeline

2022
開発スタートDevelopment begins — 名前の由来となった年。旧トークンの「全銘柄同じルール」問題を解くため、別アドレスの新プログラムとして設計が始まる。 — the year in the name. Work starts on a new program at a separate address to escape the "same rules for every token" limit.
2023
土台づくりLaying foundations — バリデータ側(v1.16)にZK検証の下地が入り、複数の監査が走る。 — validator-side ZK groundwork lands (v1.16); multiple audits run.
2024.01
「Token Extensions」として正式展開Official launch as "Token Extensions" — 大手機関と連携した形でブランド化。PaxosやGMOトラストなど規制プレイヤーの採用表明が続く。 — branded and launched with institutional partners; regulated players like Paxos and GMO Trust announce adoption.
2024
WNS & PYUSD — 拡張だけで作るNFT標準WNSが登場。PYUSDのSolana展開が拡大。 — the extensions-only NFT standard WNS arrives; PYUSD's Solana footprint expands.
2025
新拡張:Scaled UI Amount / PausableNew extensions: Scaled UI Amount / Pausable — RWA・機関ニーズに応える2拡張が追加され、計18種に。 — two institution-driven extensions bring the mint-side total to 18.
2025.04-06
ZK証明プログラムの脆弱性ZK proof program vulnerabilities — 偽の証明が通る不具合が2件報告(実被害ゼロ)。6月、エポック805で証明プログラムを無効化し秘匿送金を停止。 — two forged-proof bugs reported (zero losses). In June the proof program is disabled at epoch 805, pausing confidential transfers.
2025.08
公開監査Public audit — Code4renaで秘匿送金コンポーネントの競争型監査を実施。 — a competitive Code4rena audit covers the confidential components.
2025.12
PYUSDがSolanaで急成長PYUSD surges on Solana — Solana上の流通量が10億ドルを突破。Token-2022発行の資産として最大級に。 — on-Solana supply tops $1B, among the largest Token-2022 assets.
2026
現在地Today — Agave 4.0が展開され、ZK証明プログラムの再有効化はfeature gate有効化待ち(公式docsには無効化注記が残存)。規制ステーブルコイン×RWAの土台として、2つのトークンプログラム並存時代が定着。 — Agave 4.0 has rolled out; the ZK proof program awaits its feature-gate activation (official docs still note the disable). The two-program era is the settled norm beneath regulated stablecoins and RWAs.

📚 出典・参考(2026年6月時点)Sources & references (as of June 2026)

  • Solana 公式ドキュメントofficial docs (solana.com/docs/tokens/extensions) — ExtensionType一覧・各拡張ガイド・秘匿送金の無効化注記ExtensionType enum, per-extension guides, confidential-transfer disable notice
  • Solana Foundation ポストモーテムpost-mortems (2025.05 / 2025.06) — ZK ElGamal脆弱性の経緯・エポック805・主要ステーブルの初期化状況ZK ElGamal incidents, epoch 805, stablecoin initialization status
  • Helius — Agave 4.0 解説(ZK証明プログラム再有効化予定)explainer (proof program reactivation) / Code4rena 2025-08 監査リポジトリaudit repo
  • Neodyme「Don't shoot yourself in the foot with extensions」 — 各拡張のセキュリティ注意点security footguns per extension
  • RareSkills「The Solana Token 2022 Specification」 — TLV構造・命令一覧・互換性TLV layout, instruction list, incompatibilities
  • QuickNode / Chainstack / Phantom / Ledger 各ガイドguides — 手数料・フック・Scaled UI Amount・ウォレット警告fees, hooks, Scaled UI Amount, wallet warnings
  • solana.com Token Extensions ソリューションページsolutions page — USDP・GMOトラスト・組み合わせFAQUSDP, GMO Trust, combination FAQ

本サイトは教育目的の非公式ファンメイド解説です。デモの数値・アニメーションは概念説明のための例であり、実測値ではありません。バイト数・レントは概算です。投資助言ではありません。An unofficial, fan-made educational guide. Demo numbers and animations are illustrative, not measurements; byte sizes and rent are approximate. Not investment advice.