Renounce が嘘になる瞬間

最も誤解され、最も被害が出ている一点をコード視点だけで解剖。
「Renounce（権限放棄）が“嘘”になる瞬間」これは詐欺師のトリックではなく、設計上の抜け道です。

Renounce は「契約1つの権限放棄」にすぎない。以下のどれかが残っていれば、Renounce 済み = 無意味です。

① Proxy / Implementation が別に存在する場合
◇ 何が起きているか
表向きのコントラクト：Renounce 済み
実体ロジック：別コントラクト
Proxy 経由で差し替え可能
〇 なぜ嘘になるか
権限を捨てたのは「入り口」だけ
中身はいつでも変更可能
△ 見抜き方
Proxy パターンの有無
upgradeTo() / setImplementation()
▶ Renounce しても、人格が変えられる

② 別コントラクトに「裏の管理者」がいる
◇ 典型構造
Token は Renounce
FeeManager / TaxController が別契約
そちらは owner 健在
〇 なぜ危険か
価格・税率・制限は外部制御
本体は飾り
△ 見抜き方
外部コントラクト参照
setController() の存在
▶ 首輪は別の場所にある

③ Timelock が「Renounce 前に解除可能」
◇ 何が起きるか
Timelock 付き管理
Renounce 宣言
その前に予約済み操作が実行
〇 なぜ嘘か
未来の操作は止められない
放棄は「今後の操作」だけ
△ 見抜き方
Timelock のキュー
実行待ちトランザクション

④ Multisig が Renounce の外側にある
◇ 構造
owner = Multisig
Renounce = 単独権限放棄
Multisig が実権保持
〇 なぜ嘘か
集団管理＝非管理ではない
数人で即時変更可能
△ 見抜き方
owner アドレスの正体
Multisig の署名閾値
▶ 中央集権が分散しただけ

⑤ 初期 Mint / Allowance が残っている
◇ 典型
Renounce 後でも
大量トークンが運営アドレスに残存
または無制限 Allowance
〇 なぜ嘘か
売却＝実質 Rug
権限ではなく保有量で支配
△ 見抜き方
初期配分
Allowance の設定先

⑥ ブラックリスト・例外権限が owner 以外にある
◇ 危険構造
blacklistManager
exemptAddress
〇 なぜ嘘か
凍結・解放が可能
Renounce は owner のみ
△ 見抜き方
権限ロール一覧
hasRole() の確認

⑦ Factory / Deployer が支配している
◇ 何が起きるか
コントラクト自体は無権限
Factory 経由で挙動制御
〇 なぜ嘘か
実質、外部から操作可能
表面上は「完全分散」
△ 見抜き方
Factory アドレス
初期化関数の制御権
一瞬で見抜くチェック（実戦用）

※Renounce 済みでも以下1つでも YES → 信用しない
Proxy 構造がある
外部コントラクトが制御
Timelock に予約操作あり
Multisig が実権
初期大量保有が残存
owner 以外の特権ロール
Factory が挙動制御

◆ 本質（最重要）
Renounce は「権力を消す操作」ではない「責任を消す操作」になりやすい。
本当に安全なのは、権限が 存在しない変更不能（immutable）外部依存がない
「Renounce 済み」を信用するな。「何ができなくなったか」を確認しろ。それが分からないなら、そのコントラクトは触るべきではない。