Frankenstein Financeの現況｜旧Vault・FRANKと残高確認の注意点

2026年8月29日時点で、旧Frankenstein Financeの公式サイトとdocsは開けず、現行frontendとして利用できる状態を確認できません。 BNB Smart Chain（BSC）とFantom Operaには旧FRANK tokenやMasterChef contractが残っていますが、contractがchain上にあることは、運営、frontend、Vaultのstrategy、出金経路が現在も保守されている証明ではありません。

この記事は、2021年の「EnableしてStakeする」手順を再案内するものではありません。旧Frankenstein Financeを使った可能性がある読者が、chain、account、pool ID、MasterChef、strategy、underlying assetをread-onlyで突き合わせ、署名やtransactionへ進む前に止まるための現況記録です。

検証で行っていないこと

wallet接続、account addressの入力、message署名、approval・revoke、deposit、withdraw、emergencyWithdraw、harvest、swap、bridge、transaction署名・送信、asset移動は行っていません。公開Explorer、Archive、source code、read-only RPCだけを確認しています。

Frankenstein Financeの現在地

確認項目	2026年8月29日の観測	ここから言える範囲
旧公式site / docs	DNSでIP addressを取得できず、ChromeはERR_NAME_NOT_RESOLVED	その時点で旧frontendへ到達できない。終了理由や将来の復旧までは不明
公式GitHub	FrankenDefi/contractsの最終公開commitは2021年6月17日	公開repoの更新履歴。非公開開発や運営主体の現在を証明しない
BSC	旧FRANKとMasterChefにbytecodeがあり、Explorerに過去・現在のcallが表示される	contractが残り、call可能な入口がある。strategyの健全性や出金成功を保証しない
Fantom Opera	chain ID 250の公式RPCが応答し、旧FRANK / MasterChef addressにbytecodeがある	chain stateを読み取れる。旧frontendやFRANKのSonic移行を証明しない
FTMScan	docsがExplorerとAPIのdeprecatedを表示し、旧domain本体へ到達できない	古いExplorer linkを現在のwrite手順に使わない
audit	2021年5月のTechRate PDFが残る	指定commit・5 contractの限定的なreview。現在の全systemの安全証明ではない

Explorerのrecent call、token balance、監査PDFだけで保守・安全・出金成功を決めないでください。いずれも状態を切り分ける証拠の一部であり、運営継続や回収可能性の結論ではありません。

検索結果には同じ「Frankenstein」を名乗る別projectもあります。この記事が扱うのは、旧公式GitHub organizationがFrankenDefiで、BSCとFantom Operaのyield optimizerとして公開されていたFrankenstein Financeです。名前、logo、token symbolだけで別chainのprojectやcontractを同一視しないでください。

2021年のFrankenstein Financeは何だったか

旧公式READMEは、Frankenstein FinanceをSwamp.Financeに着想を得たBSC / Fantom Operaのyield optimizerと説明していました。利用者がassetをVaultへ預け、strategyがfarm rewardを回収・交換・再投資することで、個別利用者が毎回compound transactionを送らずに済むという設計です。独自tokenはFRANK、公開codeではMasterChef、strategy、lottery、referral、timelockなどが組み合わされています。

旧画面の一つの「Vault」を、単一のwallet残高として読むと判断を誤ります。公開sourceでは、概ね次の層を通ります。

1. 利用者がMasterChefへwant tokenをdepositする
2. MasterChefがpool IDごとのstrategyへtokenを渡し、利用者のsharesを記録する
3. strategyがunderlying farmへstakeし、rewardを回収する
4. rewardの一部をfeeやbuybackへ配分し、残りをwant tokenへ戻す
5. withdraw時はsharesTotalとwantLockedTotalから利用者分を計算し、strategyから戻す

したがって、walletにLP tokenが見えないことだけで消失とは判断できません。一方、MasterChefのuserInfoにsharesがあることだけでも、underlying farmから現在取り戻せるとは判断できません。MasterChef、strategy、farm、router、tokenのどこで状態が止まっているかを分ける必要があります。

監査済みという表示の読み方

TechRateの監査PDFは、2021年5月の次の5 fileとcommit 502912d…を対象にしています。

• MasterChef.sol
• NativeToken.sol
• StrategyNative.sol
• StrategyPancake.sol
• Strategy_PCS.sol

報告書はhigh severity 1件とlow severity 3件を記録し、high severityのwithdraw問題、unused code、reentrancy対策について後続commit 3791be5…をfixとして示しました。mass updateのgas上限問題は、長い配列を避けるというrecommendationでした。

ここで重要なのは範囲です。

境界	監査PDFに書かれていること	記事での扱い
source snapshot	audit対象はcommit 502912d…	別commitやdeployed bytecodeを自動で含めない
contract scope	上記5 file	frontend、wallet、router、underlying farm、運用は含めない
product scope	application・operations・product codeはreview対象外	UIが安全、出金できる、運営が継続という結論に使わない
later changes	2021年5月31日にAlpaca strategy、6月17日にCagesを追加	audit対象commitより後の追加codeとして分離する
conclusion	対象contractに未修正のhigh severityはないという当時の結論	現在の安全・価格・流動性・回収可能性の保証にしない

監査報告が存在することは有用な歴史資料です。ただし、監査対象外のcomponent、admin権限、deployment parameter、underlying protocol、時間経過による停止や流動性低下は別のriskです。

旧FRANK・MasterChefのidentityを確認する

Internet Archiveの旧公式Smart Contractsには、両chainのFRANKとMasterChefが掲載されています。

chain	FRANK	MasterChef	現在のread-only確認
BSC / chain ID 56	0x129e…dab09	0xA07f…2ee4a	BscScanのlabel・source・transactionとRPC bytecode
Fantom Opera / chain ID 250	0xeb86…8ba0	0xd920…F32E3	旧公式ArchiveとFantom公式RPC。FTMScan linkはdeprecated

この表だけからaddressをwalletへ追加したり、tokenを購入したり、contractへ送信したりしないでください。少なくともchain ID、Archiveの旧公式記録、ExplorerまたはRPCのbytecode、sourceとの一致を組み合わせます。token名がFrankenstein Finance、symbolがFRANKと返ることもidentityの一部ですが、同名tokenを排除する十分条件ではありません。

旧Vaultのpositionをread-onlyで探す順番

1. chainとaccountを固定する

最初に、当時使ったchainがBSC（chain ID 56）かFantom Opera（chain ID 250）かを分けます。Sonicはchain ID 146の別chainです。同じEVM address形式でもstateはchainごとに別なので、Sonicへ切り替えてもOpera上のpositionは自動表示されません。

使ったaccountも、現在walletで選択しているaccountと同じとは限りません。addressを公開siteへ入力する前に、自分のwallet historyや保存したtx hashから候補を絞ります。公開addressは秘密ではありませんが、siteへ渡すと閲覧行動とのlinkageが増える点に注意してください。

2. 最初のdeposit transactionを探す

旧UIの記憶ではなく、Explorerやwallet historyのtransaction receiptへ戻ります。確認したいのは、success / failed、chain、from、to、method、block timeです。

• Approveだけならspenderへallowanceを設定した記録で、Vaultへのdeposit証拠ではない
• DepositのreceiptとMasterChefのDeposit eventがあれば、pool IDとamountの手掛かりになる
• tokenのTransferだけでは、farm deposit、swap、spam transferを区別できない

receipt、calldata、eventの読み分けはABI・calldata・event logの確認順、transactionが反映されない場合はreceiptから戻る確認手順も参照できます。

3. pool IDとpoolの中身を照合する

旧公式のemergency withdraw資料も、最初にpool IDを確認するよう案内していました。ただし、0から順番に推測してwriteするのではなく、read functionと自分のreceiptを組み合わせます。

1. poolInfo(pid)でwant tokenとstrategyを読む
2. deposit receiptのpool ID、token、strategyと一致するか確認する
3. userInfo(pid, account)のsharesとrewardDebtを読む
4. 利用可能ならstakedWantTokens(pid, account)も比較する

pool ID、token、MasterChefの三つが一致しない場合は止めます。MasterChefの_pidを照合する方法では、記憶やUI表示からpidを推測しない理由を詳しく説明しています。

4. strategyとunderlying farmを分けて読む

公開sourceのwithdrawはMasterChefだけで完結せず、poolに登録されたstrategyのwithdrawを呼びます。strategy側ではsharesTotal、wantLockedTotal、farm contract、pool ID、want tokenなどが関係します。

次のどれか一つだけで「回収可能」と判断しないでください。

• MasterChefのuserInfoにsharesがある
• strategyにtoken balanceがある
• underlying farmにLPがある
• FRANK tokenがwalletに表示される
• Explorerに最近のcallがある

sharesTotalが0、strategyがpause、underlying farmのwithdrawが失敗、want token自体が移行・停止、routerやpairのliquidityが不足、といった別の要因があり得ます。V2 LP tokenかfarm stakeかを見分けるにはPancakeSwapのV2・V3 position確認も使えます。

5. allowanceはpositionと別に確認する

旧画面のEnableは、公開sourceの流れではMasterChefがtokenをtransferFromできるようにするapproval段階です。

Enable / Approve ≠ Deposit ≠ Vault share ≠ Withdraw

frontendが消えても、過去のallowanceが自動で0になるとは限りません。owner、token、spender、chain、allowance amountを確認します。Spending capとrevokeの確認手順で、disconnectとrevokeの違いを確認できます。

Revokeもon-chain transactionでgasが必要です。検索広告、復旧を名乗るDM、Archiveから複製されたsiteへwalletを接続せず、spenderとtransaction内容を独立に確認してください。

emergencyWithdrawは「必ず救出できる関数」ではない

旧公式Archiveには、frontend障害時にBSC / Fantom OperaのMasterChefへ接続してemergencyWithdrawを呼ぶ資料が残っています。これは、当時の運営が用意した歴史的なrecovery pathを示します。

しかし、公開sourceのemergencyWithdraw(pid)も、現在の成功を保証しません。

• user shares、strategyのsharesTotalとwantLockedTotalを使ってamountを計算する
• strategyのwithdrawを先に呼び、その後want tokenを利用者へ送る
• pending FRANK rewardを回収する通常withdrawとは別で、source commentもrewardを考慮しないemergency用としている
• pool ID、strategy、underlying farm、token stateが壊れていればrevertや想定外の受取になり得る
• write transactionなので、gas、署名、calldata、chain、recipientの確認が必要

そのため本記事では実行手順を掲載しません。読取結果、tx hash、MasterChef、pool ID、want token、strategy、shares、想定受取assetを保存し、EVM contractを読める第三者へreviewを依頼する段階で止めます。秘密鍵やseed phraseを渡すsupportは利用しないでください。

旧記事の「利益4%」「入金0.1%」を現在値にしない

旧記事は利益の4%とdeposit fee 0.1%を固定値のように紹介していました。公開sourceにはcontrollerFee、buyBackRate、entranceFeeFactor、worker向けのearnFeeFactorがあり、strategyごとに計算とsetterが存在します。

これは、2021年公開sourceの初期値や上限を読む手掛かりです。現在のdeployed state、すべてのpool、underlying farm fee、swap price impact、gas、受取assetを表す一つの「合計手数料」ではありません。

確認するときは、次を分離します。

1. MasterChefが指す実際のstrategy address
2. そのstrategyの現在getter値とverified bytecode
3. deposit時のshare計算
4. harvest時のcontroller / buyback / worker fee
5. underlying farm、DEX、router側のfeeとliquidity
6. withdraw時のactual receiptと受取token

APR、TVL、FRANK価格、表示USD額が見えても、withdrawable amountやslippage後の価値とは同じではありません。

Fantom OperaとSonicを混同しない

Fantom Operaの旧Frankenstein contractはchain ID 250にあります。Sonicはchain ID 146の別chainです。

Sonic Labsの2026年6月23日発表は、それ以前のsunset方針を変更し、Fantom Operaを少なくとも2026年末まで稼働させ、bridgeへ定期的に資金を供給すると述べています。これはOpera network infrastructureの方針です。

Frankenstein FinanceがFRANK、Vault share、LP、reward、strategyをSonicへmigrationしたという根拠は確認していません。FTMからSへのnetwork migrationと、third-party app token・LP・farm positionの移行を同じものとして扱わないでください。

実行せず相談へ回すチェックリスト

次の一つでも不明なら、transactionを止めます。

1. BSC / Fantom Opera / Sonicのどのchainか確定していない
2. account、MasterChef、pool IDをdeposit receiptで結べない
3. poolInfoのwant token / strategyが記録と一致しない
4. userInfo、sharesTotal、wantLockedTotalの関係を説明できない
5. underlying farmとLP tokenの状態を確認していない
6. receiveするtokenとamountを読めない
7. approval、deposit、withdraw、emergencyWithdrawを同じ操作だと思っている
8. source、deployed bytecode、admin / pause状態の一致を確認していない
9. 検索広告、DM、clone site、秘密鍵入力を案内されている
10. transaction失敗時のgas損失やreward放棄を許容できない

よくある質問

Frankenstein Financeは現在も稼働していますか？

旧公式siteとdocsには到達できません。BSC / Fantom Operaのcontractはchain上に残り、BSC MasterChefにはcallも見えますが、それだけで運営・frontend・strategyの保守中とは判断できません。本記事ではmaintenance statusを未確認としています。

FRANKがwalletにあれば価値がありますか？

token contractとbalanceが存在することは、十分なliquidity、信頼できるmarket price、swap可能性、出金可能性を保証しません。chain、token contract、pair、reserve、actual quoteを分け、検索結果の価格だけで判断しないでください。

旧公式のemergencyWithdrawを使えば回収できますか？

保証できません。歴史資料と公開functionはありますが、pool ID、shares、strategy、underlying farm、want tokenの現在stateに依存します。read-onlyで証拠を揃え、実行前にcontract-level reviewへ回してください。

同名のFrankenstein Protocolへ移行したのですか？

その根拠は確認していません。同名project、別chain、別tokenを旧Frankenstein Financeの後継とみなさず、旧公式organization、chain ID、contract address、migration announcementを揃えてください。

frontendがなくても直コンすればよいですか？

frontendがないことは、直接contractを操作すべきという意味ではありません。verified source、ABI、target contract、calldata、simulation、admin / pause状態、受取assetを確認できない場合は止めます。直コン前の安全確認も参照してください。

まとめ

Frankenstein Financeの旧公式siteとdocsは、2026年8月29日時点で開けません。BSCとFantom Operaには旧FRANKとMasterChefが残りますが、存在やrecent callを現在の運営・Vault保守・回収成功と読み替えないことが重要です。

旧positionを確認するときは、chain、account、deposit receipt、MasterChef、pool ID、want token、strategy、underlying farm、shares、allowanceを順に結びます。TechRate監査も対象commit・対象contract・対象外範囲へ戻して読み、旧Archiveのwrite手順を現在の推奨へ変えないでください。証拠が一致しない場所で署名せず、tx hashとread-only stateを保存して人手reviewへ回すのが安全です。