How to Assess Web3 Project Risks: A Practical User Checklist

In Web3, users often hold their own keys and sign transactions directly. A useful review therefore starts not with “How much can I earn?” but with: What am I signing, which code will gain access to my assets, and who can change the rules?

どのチェックリストでも、プロジェクトの安全性を証明することはできません。目的は、不明点を明らかにし、主張を検証可能な証拠と照合し、潜在的な損害を抑えることです。

この記事は教育目的でのみ提供され、金融、投資、法律に関する助言ではありません。Web3 トランザクションにより、送信した資産をすべて失う可能性があります。

1. ソースを確認する

• 保存したブックマーク、または確認済み公式チャネルの URL を使用してください。
• ドメイン名を一文字ずつ確認してください。
• 広告、頼んでいないメッセージ、無作為な検索結果からウォレットを接続しないでください。
• プロジェクトの公式資料間でコントラクトアドレスを照合します。
• シードフレーズや秘密鍵を絶対に開示しないでください。

Stop signal: a site asks you to “synchronize,” “validate,” or “restore” a wallet by entering secret words.

2. ネットワークと資産を確認する

送金前に記録する項目：

• ネットワーク。
• トークンコントラクトアドレス。
• 受取人または呼び出されたコントラクトのアドレス。
• 金額；
• 手数料の支払い資産。
• 意図した操作。

A name such as USDT does not uniquely identify a token. Verify the full token contract address. The same 0x… address format can be used on different EVM networks, but assets and state remain network-specific.

Stop signal: the project gives a ticker but does not publish the network and token address.

3. デプロイ済みコードを確認する

ブロックエクスプローラーでは：

• 公式アドレスを使ってコントラクトを特定する。
• ソース検証を確認する；
• プロキシかどうかを判定する。
• 現在の実装を開く。
• すべてのアドレスをプロジェクト文書と照合する。

On BscScan, Exact Match means published source and constructor parameters were matched to deployed bytecode. This improves transparency but is not a security assessment.

Stop signal: no address is published, source is unverified, and the project still claims “full transparency” without explanation.

4. 管理権限を理解する

次のようなロールや関数を確認します：

• owner、admin、operator、upgrader。
• 一時停止と再開。
• 手数料または上限の変更。
• 関連アドレスの変更。
• トークンのミント。
• 資産の出金；
• 実装のアップグレード。
• アドレスのブロック。

誰がこれらの鍵を管理しているか、マルチシグを使用しているか、変更にタイムロックがあるか、ユーザーへどのように通知するかを確認してください。中央集権的な管理が直ちに不正を意味するわけではありませんが、特定の管理者への依存要素です。

Stop signal: one address holds critical powers while the project claims that nobody can change anything.

5. 監査を正しく読む

次を確認します：

• レポートが監査人によって公開されている。
• リポジトリとコミットハッシュが明記されている。
• 稼働中のコントラクトが監査範囲に含まれている。
• レポートが現在の実装を対象としている。
• 未解決の指摘事項が残っている。
• 修正後に再テストが行われた。
• 重要なコンポーネントが除外されている。

監査は追加の独立レビューです。すべての欠陥を発見できるわけではなく、ウェブサイト、鍵管理、ビジネスモデル、将来のアップグレードが自動的に対象になるわけでもありません。

Stop signal: there is an “Audited” badge but no report or reviewed code version.

6. 説明内容とオンチェーンの動作を比較する

複数のトランザクションで確認する項目：

• ステータス。
• From and To / Interacted With;
• BEP-20 の移動；
• 内部呼び出し。
• ログ。
• 手数料。
• 残高とコントラクト状態の変化。

Compare the actual path of funds with the published architecture. Do not draw a system-wide conclusion from one demonstration transaction. Success means the code executed without reverting; it does not mean the operation was safe or beneficial.

Stop signal: observable fund flows differ from the stated process and no clear explanation is provided.

7. 資産と負債を分けて確認する

表示されるアドレス残高は一つの事実にすぎません。次を確認してください：

• 関連するすべてのアドレスが開示されているか；
• 誰が資産を管理しているか。
• 出金できるか；
• 他のユーザーに対してどのような義務があるか。
• 外部価格の決定方法。
• アクセスがブリッジ、DEX、オラクル、または取引相手に依存しているか。

トークン残高が大きくても、流動性があるとは限りません。単位数が多くても、実際に換金できる価値がほとんどない場合があります。

Stop signal: one address balance is presented as proof of solvency without disclosing obligations or control rights.

8. 経済モデルを分かりやすく説明する

次の質問への明確な回答を確認します：

• 支払いの原資は何か。
• 誰が手数料を支払うか。
• 新しいユーザーが参加しない場合にどうなるか。
• 退出条件とロックアップ。
• どこで損失が発生し得るか。
• 管理者が変更できるパラメータは何か。
• トークン価格を左右する要因。

結果が市場、新規参加者、流動性、チームの判断に左右される場合は、その依存関係を明示する必要があります。

Stop signal: a fixed outcome is promised without a verifiable source of funds or loss scenario.

9. 管理署名とトークン利用許可

確定前に、ウォレットの表示内容を確認してください：

• ネットワーク。
• 呼び出し先アドレス；
• 関数または判読可能な操作内容。
• ネイティブトークンの価値。
• トークンと allowance の金額。
• 想定される資産の変化。

An approve call does not immediately transfer a token. It may authorize a spender contract to call transferFrom up to an allowance. An unlimited allowance increases potential loss if the spender is compromised or flawed.

データが不明確な場合や、確認済みのものとアドレスが異なる場合は署名を拒否してください。利用後は、信頼できるツールで不要になった権限を確認し、取り消します。

Stop signal: you are pressured to sign unreadable data or told that a signature “does nothing.”

10. オフチェーンのリスクも含める

十分にレビューされたコードでも、次のすべてを防げるわけではありません：

• ウェブサイトまたは DNS の侵害。
• 悪意のあるブラウザー拡張機能。
• 鍵の盗難。
• 侵害されたプロジェクトアカウント；
• バックエンド障害；
• ソーシャルエンジニアリング攻撃。
• 法的制限。
• サポートまたは運用上の障害。

ドキュメント、インシデント対応手順、通知チャネル、変更履歴を確認してください。法的な主張は、実際の文書と自分の法域に照らして評価します。

11. 潜在的な損害を限定する

レビュー完了後も：

• 実用上可能な最小のテスト金額から始める；
• 不慣れな dApp には別のウォレットを使用する。
• 接続したウォレットにすべての資産を保管しない。
• 時間を急かされた状態で署名しない。
• トランザクションハッシュとアドレスを保存する。
• トークンの allowance を定期的に確認する。
• 全額を失っても対処可能な範囲で、最大エクスポージャーを設定する。

Solidity の公式セキュリティガイダンスでは、コントラクトが保有する資産量を制限することを推奨しています。コード、コンパイラー、プラットフォームにバグがある場合でも、エクスポージャーを制限すれば損失を抑えられるためです。

トランザクション前チェックリスト

Answer yes, no, or unknown:

• ドメインを確認した。
• 正確なネットワークを把握している。
• トークンコントラクトアドレスを確認した。
• 呼び出されたコントラクトアドレスを確認した。
• ソースコードの検証状況を把握している。
• プロキシと実装を確認した。
• 管理者権限を理解している。
• 監査対象が稼働中のバージョンと一致している。
• 実際のトランザクションを確認した。
• 支払いの原資と損失シナリオを理解している。
• 署名要求の内容を理解している。
• allowance が適切な範囲に制限されている。
• フロントエンド、鍵、法的リスクを検討した。
• テスト金額で重大な損害が発生しない。

For a critical question, unknown is not a neutral answer—it is an unassessed risk. Pausing for verification is usually cheaper than an irreversible transaction.

慎重なユーザーが確認すべき質問

Is a project safe if its code is open and audited?
No. Those are useful signals, but unknown bugs and administrative, operational, economic, and external risks remain.

If assets are visible on-chain, can they definitely be returned?
No. Return depends on code, current state, control rights, and external dependencies.

Does a small successful test prove a larger transaction will work?
No. It tests one path at one moment. Limits, liquidity, state, and implementation may later differ.

What if I do not understand the signature?
Reject it. Identify the function, called address, asset changes, and permissions before trying again.

情報源と参考資料

1. Solidity Documentation — セキュリティ上の注意事項
2. Ethereum.org — スマートコントラクトのセキュリティ
3. Ethereum.org — スマートコントラクトのテスト
4. BscScan Information Center — トランザクションの表示
5. BscScan Information Center — コントラクト検証の種類
6. BscScan Information Center — アドレスとは？
7. OpenZeppelin Docs — プロキシアップグレードパターン