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

Frankenstein Financeの旧公式サイトが開けない現在、BSC・Fantom Operaに残るFRANKとMasterChef、2021年の監査範囲、旧Vaultのpositionをread-onlyで確認する順番を整理します。

正規URL: https://3mikan.com/archives/1104

著者: みかん
公開: 2021-05-28T13:12:51.000Z
更新: 2026-08-28T21:45:19.000Z

**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を同一視しないでください。

<picture>
  <source media="(max-width: 640px)" srcset="/diagrams/frankenstein/1104-status-timeline-mobile.svg" type="image/svg+xml" />
  <img src="/diagrams/frankenstein/1104-status-timeline.svg" alt="2021年のFrankenstein Finance公開・監査・最終commitから、2026年の旧domain到達不能とchain上に残るcontractまでを分ける時系列" width="1120" height="650" loading="lazy" decoding="async" />
</picture>

## 2021年のFrankenstein Financeは何だったか

[旧公式README](https://github.com/FrankenDefi/contracts/blob/master/README.md)は、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](https://github.com/FrankenDefi/contracts/blob/master/audits/FRANKENSTEIN.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](https://web.archive.org/web/20220127074245/https://docs.frankenstein.finance/basics/smart-contracts)には、両chainのFRANKとMasterChefが掲載されています。

| chain | FRANK | MasterChef | 現在のread-only確認 |
| --- | --- | --- | --- |
| BSC / chain ID 56 | [`0x129e…dab09`](https://bscscan.com/token/0x129e6d84c6cab9b0c2f37ad1d14a9fe2e59dab09) | [`0xA07f…2ee4a`](https://bscscan.com/address/0xa07fcb5edf05ea16e681ca7019e696c7dad2ee4a) | 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で探す順番

<picture>
  <source media="(max-width: 640px)" srcset="/diagrams/frankenstein/1104-position-evidence-mobile.svg" type="image/svg+xml" />
  <img src="/diagrams/frankenstein/1104-position-evidence.svg" alt="chainとaccount、deposit receipt、MasterChefのpool IDとuserInfo、strategy、underlying farm、allowanceを順に照合し、write操作の前で止まる図" width="1120" height="650" loading="lazy" decoding="async" />
</picture>

### 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の確認順](/archives/6005)、transactionが反映されない場合は[receiptから戻る確認手順](/archives/6004)も参照できます。

### 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を照合する方法](/archives/1791)では、記憶や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確認](/archives/821)も使えます。

### 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の確認手順](/archives/6007)で、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日発表](https://www.soniclabs.com/blog/the-first-1/)は、それ以前の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を確認できない場合は止めます。[直コン前の安全確認](/archives/1005)も参照してください。

## まとめ

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へ回すのが安全です。

## 確認した一次情報

- [Frankenstein Finance旧公式URL: DNS・browser到達確認](<https://frankenstein.finance/>): 確認日 2026-08-29
- [FrankenDefi公式GitHub organization](<https://github.com/FrankenDefi>): 確認日 2026-08-29
- [FrankenDefi公式contract repository](<https://github.com/FrankenDefi/contracts>): 確認日 2026-08-29
- [Frankenstein Finance旧公式README](<https://github.com/FrankenDefi/contracts/blob/master/README.md>): 確認日 2026-08-29
- [TechRate: Frankenstein smart contract security audit](<https://github.com/FrankenDefi/contracts/blob/master/audits/FRANKENSTEIN.pdf>): 確認日 2026-08-29
- [TechRate監査対象commit](<https://github.com/FrankenDefi/contracts/commit/502912de04483592dfb5e4016a3df75fd6cc725c>): 確認日 2026-08-29
- [監査報告に記載された修正commit](<https://github.com/FrankenDefi/contracts/commit/3791be56f49a9ae55440bf953339c50e16555fb7>): 確認日 2026-08-29
- [Internet Archive: 旧公式Smart Contracts](<https://web.archive.org/web/20220127074245/https://docs.frankenstein.finance/basics/smart-contracts>): 確認日 2026-08-29
- [Internet Archive: 旧公式Emergency Withdraw BSC](<https://web.archive.org/web/20220127075736/https://docs.frankenstein.finance/security/emergency-withdraw-bsc>): 確認日 2026-08-29
- [Internet Archive: 旧公式Emergency Withdraw FTM](<https://web.archive.org/web/20220127084114/https://docs.frankenstein.finance/security/emergency-withdraw-ftm>): 確認日 2026-08-29
- [BscScan: Frankenstein Finance FRANK token](<https://bscscan.com/token/0x129e6d84c6cab9b0c2f37ad1d14a9fe2e59dab09>): 確認日 2026-08-29
- [BscScan: Frankenstein MasterChef](<https://bscscan.com/address/0xa07fcb5edf05ea16e681ca7019e696c7dad2ee4a>): 確認日 2026-08-29
- [FTMScan documentation: Explorer・APIのdeprecated表示](<https://docs.ftmscan.com/>): 確認日 2026-08-29
- [Fantom Opera公式docs: chain ID・public RPC](<https://docs.fantom.foundation/build-on-opera/api/public-endpoints>): 確認日 2026-08-29
- [Sonic Labs: Fantom Opera維持方針の2026年6月更新](<https://www.soniclabs.com/blog/the-first-1/>): 確認日 2026-08-29