pump.fun でトークンの作成者を調べるときに表示される creator フィールドは、実は後から書き換えられる可能性がある。本当の作成者を特定したいなら、ブロックチェーン上の作成トランザクションを直接調べる必要がある。
pump.fun の creator フィールドが変更される仕組み
pump.fun で発行されたトークンには「作成者（creator）」という情報が記録されている。ボンディングカーブと呼ばれる初期流動性プールからは creator フィールド、卒業後に作られる AMM プールからは coin_creator フィールドとして取得できる値だ。
このフィールドは多くのツールやスキャナーで「トークンを作った人」として扱われている。しかし2025年1月のアップデートで、この値は 変更可能 になった。クリエイター報酬を複数ウォレットで分割したり、トークンの所有権を別のウォレットに移したりできるようにするためだ。
つまり、creator や coin_creator が指すのは「いま現在の所有者や報酬受取先」であって、必ずしも「最初にトークンをデプロイした人物」ではない。この違いを知らずにデータを読み取ると、作成者を誤認する可能性がある。
実際にどのくらいの頻度で変更されているのか
実際の変更頻度を調べた調査がある。ローンチ直後（1時間未満）のトークン20件では、作成者フィールドが変更されていたケースは 0件（0%） だった。しかしローンチから平均47日経過したトークン38件を調べると、8件（21%） で元の作成者とは異なるウォレットが設定されていた。
この数字は小規模なサンプルにもとづくため、あくまで「2割前後のオーダー」と捉えるのがよい。重要なのは、時間が経つほど所有者移転が増える傾向にあるという点だ。古いトークンほど、creator フィールドだけを見て「このウォレットが作成者だ」と判断するリスクが高まる。
さらに注意が必要なのは、変更後のウォレットが「新規ウォレット」に見えてしまうケースだ。実際の作成者が数十本のトークンを発行していたとしても、フィールドを移されたウォレットの側に履歴がなければ「初めてトークンを作った人」という誤った情報が流通することになる。
真の作成者を特定する具体的な手順
ブロックチェーン上の 作成トランザクション（Create 命令）は不変 だ。このトランザクションを直接調べれば、誰がトークンをデプロイしたのかを確実に特定できる。調査には Solana の RPC（リモートプロシージャコール / 遠隔手続き呼び出し）を使う。RPC とは、ウォレットやツールがブロックチェーンと会話するための電話番号のようなものだ。
ボンディングカーブの PDA を導出する
まずトークンのボンディングカーブアドレスを求める。PDA（プログラム導出アドレス / プログラムが生成する特別なアドレス）と呼ばれる仕組みで計算され、シード値 ["bonding-curve", ミントアドレス] とプログラム ID 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P から導出する。
ミントアドレスとは、そのトークン固有の識別子（アドレス）だ。pump.fun のトークンページ URL や Solscan で確認できる。
最古の署名を取得する
導出したボンディングカーブの PDA に対して getSignaturesForAddress を実行し、トランザクション履歴を取得する。得られた署名リストをページ送りしながら、最も古い署名まで遡る。
ここで重要なのは、ミントアドレスではなくボンディングカーブを歩く ことだ。ボンディングカーブはトークンが卒業（AMM 移行）すると取引の記録が止まるため、履歴が浅く扱いやすい。一方ミントアドレスは卒業後も AMM での取引が無限に積み上がるため、古いトークンほどページ送りが膨大になってしまう。
Create 命令を含むトランザクションを確認する
最古の署名を getTransaction で取得し、トランザクションのログに Instruction: Create が含まれていることを必ず確認する。この確認を怠ると、RPC ノードの履歴がローンチ時点まで遡れなかった場合に、最古として取得できたのが「最初の購入トランザクション」になってしまう。
その場合、購入者のウォレットを「作成者」と誤認することになる。これはトークンが古いほど、そして本物の所有者移転とまったく同じ見た目で発生するため、見分けがつきにくい。
デプロイヤーのアドレスを特定する
Create 命令が確認できたら、そのトランザクションの accountKeys[0] が 真の作成者（デプロイヤー） だ。この値はチェーン上に永続的に刻まれており、決して変わらない。
一度特定したデプロイヤー情報は、データベースなどに 永続的にキャッシュ しておくとよい。同じミントアドレスに対して署名の走査を繰り返す必要がなくなり、RPC コストを大幅に削減できる。
調査時の注意点と落とし穴
RPC ノードの履歴範囲に注意する
無料のパブリック RPC ノードは、過去のトランザクション履歴を十分に保持していないことが多い。古いトークンを調べる際に、ローンチ時の Create トランザクションまで到達できず、中途半端な履歴しか取得できないケースがある。こうした場合は、Helius や QuickNode といった、より深い履歴を持つ RPC プロバイダの利用を検討する必要がある。
所有者移転それ自体に問題があるわけではない
作成者フィールドの変更は、コミュニティによるトークンの引き継ぎ（コミュニティテイクオーバー / CTO）で正当に行われるケースも多い。この仕様変更は悪意ある行為を助長するものではなく、クリエイター報酬の分配や所有権の移転を柔軟にするためのものだ。
問題なのは、変更可能なフィールドを「作成者」として表示するツールの側にある。フィールド名が creator だからといって、それが常にデプロイヤーを指すとは限らない点を理解しておくことが大切だ。
よくある質問
pump.fun 以外のトークンでも creator は変更されるのか
これは pump.fun 固有の仕様であり、具体的にはボンディングカーブコントラクトと pump-amm プールのデータ構造に依存している。他のローンチパッドや、手動でデプロイされた SPL トークンでは、作成者情報が同様に変更可能かどうかはコントラクトの実装次第だ。
変更された creator はいつ誰が書き換えたのかわかるのか
ボンディングカーブのアカウントデータを直接解析すれば、オフセット（バイト位置）から現在の所有者情報を読み取れる。しかし「いつ」「誰が」書き換えたのかを特定するには、そのアカウントに対する過去の全トランザクションを追跡する必要があり、RPC の履歴深度に依存する。
スマホやブラウザのツールだけで真の作成者を調べられるのか
Solscan や Solana Explorer でトークンの作成トランザクションを手動で探すことは可能だが、ボンディングカーブの PDA 導出やページ送りを含む手順をすべて手作業で行うのは現実的ではない。プログラミングなしで済ませたい場合は、Helius の API や Dune ダッシュボードなど、作成者検証に対応した分析ツールを使うのが現実的だ。
creator が変更されたトークンは危険なのか
必ずしも危険とは言えない。コミュニティテイクオーバーによって正当に引き継がれたプロジェクトも多い。ただし、作成者を偽装して「初めてのトークンです」と装うケースも存在するため、投資判断の材料として creator フィールドだけを信用するのは避けたほうがよい。
ボンディングカーブとAMMプールのどちらを調べればいいのか
真の作成者を特定する目的なら、ボンディングカーブの PDA を基点にするのが効率的だ。卒業後に取引が止まるため履歴が浅く、短時間で Create トランザクションまで到達できる。AMM プールは取引履歴が際限なく増えるため、古いトークンでは現実的なページ数でたどり着けないことがある。
この記事のポイント
- pump.fun の creator フィールドは2025年1月以降、変更可能になっている
- 古いトークンでは約2割が元の作成者とは異なるウォレットに変更されている
- 真の作成者はブロックチェーン上の Create トランザクションから特定する
- ボンディングカーブの PDA を基点に、最古の署名を取得して確認する
- RPC ノードの履歴深度によっては Create 命令まで到達できない場合がある
- creator の変更それ自体は悪意の証拠ではなく、CTO など正当なケースも多い
「エミリーズ・クリプト・インサイダー」のリサーチ担当として、暗号資産の現場で日々生まれる疑問や悩みを丹念に追いかける。
Reddit や海外フォーラムに寄せられる声を読み解き、「初心者がつまずきやすいポイント」「経験者でも見落としがちな落とし穴
」を一つずつ記事として整理している。
専門的な話を誰もが理解できる言葉に置き換えることに全力を注ぐ。情報の正確さと読みやすさの両立を信条としている。