# 3MIKAN 公開記事全文 記事ごとの正規URLを引用元とし、公開・更新・確認日を区別してください。 # ERC-20の数量計算でNumberを使わない：BigInt・decimals・端数の扱い ERC-20の数量をNumberへ変換すると桁が失われる理由を解説します。入力文字列とBigIntを使った最小単位への変換、decimals未取得、小数桁の超過、表示とJSON保存を実行例で確認します。 正規URL: https://3mikan.com/archives/6070 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z 「入力した数量と、コントラクトへ渡す数量が少し違う」。この問題を調べるとき、最初に確認したいのはRPCやウォレットではなく、**入力文字列を途中でJavaScriptの`Number`に変換していないか**です。 本記事では、トークン数量を「入力の文字列」「計算用の整数」「表示用の文字列」に分けます。使うのは架空の数量とローカルのNode.jsだけです。ウォレット接続、APIキー、送金は必要ありません。 掲載例はNode.js 22以降で実行できます。各節のコードを`example.mjs`へ保存し、同じ節で使う関数定義と呼び出しを合わせてから`node example.mjs`を実行してください。再利用できる関数は[token-amount.mjs](/examples/offline-web3/token-amount.mjs)から取得できます。 ## decimalsは計算結果ではなく、単位を解釈する情報 ERC-20の`balanceOf`が返すのは`uint256`の整数です。人に見せる小数点の位置を決める情報が`decimals`であり、たとえば`decimals = 6`なら、整数の`1250000`を`1.25`として表示します。[^erc20] ```text 表示数量 decimals 最小単位の整数 1.25 6 1250000 1.25 18 1250000000000000000 ``` 同じ「1.25」でも、コントラクトへ渡す整数は異なります。OpenZeppelinの説明でも、`decimals`は表示上の解釈に使うもので、コントラクトの残高計算を浮動小数点へ変える設定ではありません。[^oz] また、ERC-20原仕様では`decimals()`は任意のメタデータです。取得できなかった場合に「たぶん18」と埋める設計は避けます。表示する単位が確定していない状態と、残高がゼロの状態は別だからです。[^erc20] 実装上は、数量に`chainId`、トークンのコントラクトアドレス、確認済みの`decimals`を対応させます。少なくとも、この3つを決めずに表示値を最小単位へ換算しない設計にします。 ## BigIntへ変える前にNumberを通すと、失った桁は戻らない JavaScriptの`Number`で安全な整数として扱える範囲の上限は、`2^53 - 1`、つまり`9007199254740991`です。上限を超えた数がすべて不正確になるわけではありませんが、隣り合う整数を区別できなくなる場合があります。[^number] 次の入力を考えます。 ```js const input = '0.100000000000000001'; const wrong = BigInt(Number(input) * 10 ** 18); console.log(wrong.toString()); // 100000000000000000 ``` 18桁の小数として解釈した正しい整数は`100000000000000001`です。しかし、この例では最後の1が失われます。実際にNode.js v22.16.0で上記の結果を確認しました。 `BigInt`を使っていても、**その前段階で精度が失われれば修復できません**。`parseFloat(input)`を使ってから掛け算する実装にも、同じ問題が残ります。 必要なのは、入力を最初から最後まで文字列として読み、整数部と小数部を連結して整数へ変換する方法です。 ## 小数を丸めずに、最小単位の整数へ変換する ここでは入力方針を明確に限定します。非負の10進文字列だけを受け付け、指数表記、桁区切り、前後の空白、余分な先頭ゼロは拒否します。小数部分が`decimals`を超えた場合も、自動で丸めずにエラーにします。 ```js const UINT256_MAX = (1n << 256n) - 1n; function parseTokenAmount(text, decimals) { if (!Number.isInteger(decimals) || decimals < 0 || decimals > 255) { throw new RangeError('invalid decimals'); } if (typeof text !== 'string' || text.length > 400) { throw new TypeError('invalid amount string'); } const match = /^(0|[1-9][0-9]*)(?:\.([0-9]+))?$/.exec(text); if (!match || match[0] !== text) throw new TypeError('invalid decimal amount'); const whole = match[1]; const fraction = match[2] ?? ''; if (fraction.length > decimals) { throw new RangeError('too many fractional digits'); } const raw = BigInt(whole + fraction.padEnd(decimals, '0')); if (raw > UINT256_MAX) throw new RangeError('amount exceeds uint256'); return raw; } ``` この正規表現は`m`フラグを使わないため、`$`は入力末尾にだけ一致します。JavaScriptで改行の直前にも一致するのは`m`を指定した場合です。`match[0] === text`は、将来パターンを変えても入力の一部分だけを受け入れない意図を明示しています。末尾改行は補正せず拒否します。[^regexp] このコードは、汎用の小数ライブラリではなく、非負のERC-20数量を読むためのサンプルです。400文字という上限や先頭ゼロの禁止は、この記事で決めた入力ポリシーであり、ERC-20の要件ではありません。 ```js parseTokenAmount('1.25', 6); // 1250000n parseTokenAmount('0.000001', 6); // 1n parseTokenAmount('0.100000000000000001', 18); // 100000000000000001n parseTokenAmount('0.0000001', 6); // RangeError ``` 最後の入力は、6桁の最小単位より細かい数量です。勝手にゼロへ切り捨てたり、1単位へ切り上げたりしません。 なお、この実装は`1.2500000`も6桁指定では拒否します。末尾のゼロを削れば表現できますが、「入力の補正をしない」という方針を優先しています。末尾ゼロを許容するUIにするなら、検証前の正規化として明示的に追加してください。 ## 表示の丸めと、計算に使う値を分離する 最小単位の整数を表示へ戻すときも、途中で`Number(raw)`へ変換しない設計にします。整数を10進文字列へ変換し、末尾から`decimals`桁の位置へ小数点を入れれば、元の数量を保てます。 次の`formatTokenAmount`はこの方針です。`UINT256_MAX`は前のサンプルで定義した値を使います。 ```js function formatTokenAmount(raw, decimals) { if (!Number.isInteger(decimals) || decimals < 0 || decimals > 255) { throw new RangeError('invalid decimals'); } if (typeof raw !== 'bigint') throw new TypeError('raw must be bigint'); if (raw < 0n || raw > UINT256_MAX) throw new RangeError('outside uint256'); if (decimals === 0) return raw.toString(); const digits = raw.toString().padStart(decimals + 1, '0'); const whole = digits.slice(0, -decimals); const fraction = digits.slice(-decimals).replace(/0+$/, ''); return fraction ? `${whole}.${fraction}` : whole; } ``` ```text formatTokenAmount(1250000n, 6) → "1.25" formatTokenAmount(1n, 6) → "0.000001" formatTokenAmount(0n, 18) → "0" ``` 画面上では「1.23」のように短く表示しても構いません。ただし、表示用に丸めた文字列を、そのまま比較や送信データの計算へ戻さないようにします。計算の正本は整数、表示はその派生値という関係を保ちます。 既存ライブラリを使う場合、ethers v6には10進文字列を`bigint`へ変換する`parseUnits`と、整数から表示文字列を作る`formatUnits`があります。採用時は、過剰な小数桁や許容する入力表記の扱いも、使うバージョンでテストします。[^ethers] ## BigIntでも端数の扱いは決める必要がある `BigInt`は整数の計算用です。整数同士の除算では、割り切れない部分が保持されるわけではありません。[^bigint] ```js 5n / 2n; // 2n (1n * 3n) / 2n; // 1n (1n / 2n) * 3n; // 0n ``` 本例のように非負の値を扱う場合、除算の端数は切り捨てになります。一般にはゼロ方向への切り捨てです。 手数料や比率を計算するなら、「どの単位で」「どの段階に」「どちら向きの丸めを入れるか」を別途決めます。単にNumberをBigIntへ置き換えても、計算順序や丸めの仕様は自動では決まりません。上の2つの式は、実数として同じでも整数演算では結果が違います。 ## JSONへ保存するときは、数量を文字列として定義する 変換処理を指定せずに`BigInt`を`JSON.stringify`へ渡すと、`TypeError`になります。[^json] ```js JSON.stringify({ amount: 1n }); // TypeError const saved = JSON.stringify({ amountRaw: '100000000000000001', decimals: 18 }); ``` 保存スキーマでは`amountRaw`を10進文字列と定義します。読み戻す側でも、このフィールドだけを文字列として検証し、整数へ変換します。すべての数字らしい文字列を一括でBigIntへ変える必要はありません。 実際のアプリでは、ここへチェーンIDとトークンアドレスも追加します。表示済みの「1.25」だけでは、どの単位の数量を保存したのか復元できないためです。 ## まとめ 数量処理で守るべき境界は、**入力は文字列、計算は最小単位の整数、表示は別の文字列**です。 `decimals`未確認のまま換算しない、Numberを経由しない、小数桁の超過を勝手に丸めない、BigIntの除算規則を決める。この4点を、0、最小単位、上限、桁超過のテストで固定すると、RPCへ接続する前に数量バグを減らせます。 ### 検証メモ 例はNode.js v22.16.0とv24.14.0で確認しました。整数を表示文字列へ変換しても、同じ`decimals`で読み戻せば元の整数に戻ること、桁超過や不正入力を拒否することを確かめています。実トークンの取得・送信は行っていません。 関連記事：[ABIから関数識別子・入力データ・イベントログを読む方法](/archives/6005) [^erc20]: [ERC-20: Token Standard — decimals / balanceOf](https://eips.ethereum.org/EIPS/eip-20)。参照日：2026-09-05。 [^oz]: [OpenZeppelin Contracts 5.x — ERC-20 / A Note on decimals](https://docs.openzeppelin.com/contracts/5.x/erc20)。参照日：2026-09-05。 [^number]: [ECMAScript — Number.MAX_SAFE_INTEGER](https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-number.max_safe_integer)。参照日：2026-09-05。 [^bigint]: [ECMAScript — BigInt numeric type](https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-numeric-types-bigint)。参照日：2026-09-05。 [^json]: [ECMAScript — SerializeJSONProperty](https://tc39.es/ecma262/multipage/structured-data.html#sec-serializejsonproperty)。参照日：2026-09-05。 [^ethers]: [ethers v6 — Unit Conversion](https://docs.ethers.org/v6/api/utils/#about-units)。仕様参照のみ。本稿の実行検証はethersに依存しません。参照日：2026-09-05。 [^regexp]: [ECMAScript 2025：正規表現の入力境界](https://tc39.es/ecma262/2025/multipage/text-processing.html#sec-assertion)。参照日：2026-09-06。 ## 確認した一次情報 - [ERC-20: Token Standard — decimals / balanceOf](): 確認日 2026-09-05 - [OpenZeppelin Contracts 5.x — ERC-20 / A Note on decimals](): 確認日 2026-09-05 - [ECMAScript — Number.MAX\_SAFE\_INTEGER](): 確認日 2026-09-05 - [ECMAScript — BigInt numeric type](): 確認日 2026-09-05 - [ECMAScript — SerializeJSONProperty](): 確認日 2026-09-05 - [ethers v6 — Unit Conversion](): 確認日 2026-09-05 - [ECMAScript 2025：正規表現の入力境界](): 確認日 2026-09-06 --- # Ethereum RPCの0x・0x0・0x00は別物：QUANTITYとDATAの見分け方 Ethereum RPCの0x、0x0、0x00は同じゼロではありません。QUANTITYとDATAの形式、ABIの返り値、先頭ゼロ、空応答とnullを小さなパーサーで区別します。 正規URL: https://3mikan.com/archives/6071 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z Ethereum RPCの入力や応答には、`0x`で始まる文字列が多く登場します。しかし、見た目が似ていても、すべてを同じ16進数として処理してよいわけではありません。 **数量は整数の値を、DATAはバイト列とその長さを表します。** 数量の先頭ゼロを取り除く処理を、アドレスや呼び出しデータへそのまま適用すると、必要なバイトが失われます。[^eip1474] 本記事では、RPCへ実際に接続せず、ローカルの文字列だけでこの違いを確認します。 掲載例はNode.js 22以降で実行できます。各節のコードを`example.mjs`へ保存し、同じ節で使う関数定義と呼び出しを合わせてから`node example.mjs`を実行してください。再利用できる関数は[rpc-hex.mjs](/examples/offline-web3/rpc-hex.mjs)から取得できます。 ## QUANTITYは数値、DATAはバイト列 EthereumのJSON-RPCでは、数量を表す`QUANTITY`と、バイト列を表す`DATA`を分けます。数量は余分な先頭ゼロを省き、ゼロは`0x0`です。一方、DATAは1バイトを16進数2桁で表すため、空なら`0x`、ゼロの1バイトなら`0x00`になります。[^eip1474] | 表記 | QUANTITYとして | DATAとして | | --- | --- | --- | | `0x` | 不正。整数がない | 正しい。0バイト | | `0x0` | 正しい。数量の0 | 不正。1桁しかない | | `0x00` | 不正。余分な先頭ゼロ | 正しい。ゼロの1バイト | | `0x1` | 正しい。数量の1 | 不正。奇数桁 | | `0x01` | 不正。余分な先頭ゼロ | 正しい。値1の1バイト | | `0x41` | 正しい。数量の65 | 正しい。値0x41の1バイト | この表で重要なのは、`0x41`が両方の形式として成立することです。文字列を見るだけで型を確定することはできません。**どのRPCメソッドの、どのフィールドか**を先に決めます。 ここで参照するEIP-1474の状態はStagnantであり、Finalの仕様とは呼びません。現在のExecution APIの公開スキーマにも、数量、任意長バイト列、20バイトや32バイトの値を区別したスキーマがあります。実装では、対象メソッドのスキーマも合わせて確認します。なお、確認時点のExecution APIの汎用`bytes`パターン自体は偶数桁まで制限していません。本記事のパーサーはEIP-1474の1バイト2桁という方針を明示的に検証する例であり、スキーマをそのまま写したものではありません。[^eip1474][^schemas] ## eth_getBalanceの結果とeth_callの結果を同じパーサーへ入れない 代表的な違いは、`eth_getBalance`と`eth_call`です。前者の返り値はwei単位の数量ですが、後者の返り値はコントラクトの実行が返したDATAです。`eth_getCode`の結果もバイト列です。[^rpc] たとえば、ABIで`uint256`を1つ返す関数がゼロを返した場合、ABI形式の返り値は32バイトのゼロになります。`0x0`という数量表現をそのまま返すわけではありません。[^abi] ```text 数量の0 → 0x0 空の返り値 → 0x uint256(0)のABI表現 → 0x の後ろにゼロ64桁 ``` `uint256`が返ることを期待しているのに`0x`だった場合、ゼロ残高として補完するのは避けます。「期待する32バイトがない」という別の問題として扱います。 アドレス、呼び出し先、ABI、取得したブロックなどを確認する余地はありますが、空データだけで原因を決めつける必要もありません。まず、応答形式と期待する型の不一致を保存します。 ## 汎用のhex整形関数を作らず、型ごとに分ける 数量をBigIntへ変換する関数と、DATAをバイト列へ変換する関数を分離します。以下のサンプルは、入力表記を小文字の`0x`形式に統一する方針です。 ```js function readQuantity(value) { if (typeof value !== 'string' || !/^0x(?:0|[1-9a-f][0-9a-f]*)(?![\s\S])/.test(value)) { throw new TypeError('invalid lowercase QUANTITY'); } return BigInt(value); } function readData(value, expectedBytes) { if (typeof value !== 'string' || !/^0x(?:[0-9a-f]{2})*(?![\s\S])/.test(value)) { throw new TypeError('invalid lowercase DATA'); } if (expectedBytes !== undefined && (!Number.isSafeInteger(expectedBytes) || expectedBytes < 0)) { throw new RangeError('invalid expected byte length'); } const length = (value.length - 2) / 2; if (expectedBytes !== undefined && length !== expectedBytes) { throw new RangeError('unexpected byte length'); } return Buffer.from(value.slice(2), 'hex'); } ``` `(?![\s\S])`は、その位置より後に文字が残っていないことを確認する末尾条件です。JavaScriptでは`m`フラグなしの`$`も入力末尾だけに一致しますが、この例ではフラグに依存しない形で全体一致を表しています。末尾改行は受け入れません。[^regexp] この検証は値全体を正規表現で確認してから変換します。Node.jsの`Buffer.from(value, 'hex')`は、不正な文字や途中の半バイトに対して、入力を途中までで解釈することがあります。そのため、変換処理に入力検証を兼ねさせていません。[^buffer] ```js readQuantity('0x41'); // 65n readQuantity('0x01'); // TypeError readData('0x').length; // 0 readData('0x00').length; // 1 readData('0x0001').length; // 2 ``` 本稿のパーサーは形式と任意の長さを検査する小さな例です。数量のフィールド固有の上限、JSON-RPC応答全体の構造、許容サイズ、アドレスのチェックサムまで検証するものではありません。 ## DATAを数値へ変えると、先頭ゼロと長さが消える 整数としては、次の2つは同じです。 ```js BigInt('0x0001') === BigInt('0x01'); // true ``` しかし、バイト列としては違います。 ```text 0x0001 → 00 01 → 2バイト 0x01 → 01 → 1バイト ``` したがって、いったんBigIntへ変換し、`toString(16)`で戻す処理は、任意のDATAを保存する方法にはなりません。 この違いをアドレスへ当てはめると、20バイトの先頭がゼロだった場合にも、そのゼロはアドレス表現の一部として必要です。32バイトのハッシュも、数量のように短くする対象ではありません。Execution APIのスキーマでは、これらの長さを別々に指定しています。[^schemas] 「ゼロを消すと短くなって見やすい」という表示上の都合と、プロトコルへ渡すバイト列の保存は分けて考えます。 ## nullはゼロでも、空のバイト列でもない `eth_getTransactionReceipt`は、レシートが見つからない場合に`null`を返すことがあります。これは`status`が失敗を表すレシートとは異なります。[^rpc] ```json {"jsonrpc":"2.0","id":1,"result":null} ``` この応答を`0x`へ置き換えてからデコードしたり、`0x0`へ変換して失敗扱いにしたりすると、「見つかっていない」と「失敗して記録された」を混同します。 アプリ側では、応答エラー、`result: null`、空DATA、数量ゼロを別の状態として保存するのがよい設計です。異常系を一律にゼロへ落とすと、後から原因を追えなくなります。 ## まとめ RPCの16進文字列は、次の順に読みます。 1. メソッドとフィールドを確認する。 2. QUANTITYかDATAかを決め、形式を検証する。 3. 必要な長さや範囲を確かめてから変換する。 数量にはBigInt、バイト列にはバイト列の型を使い、どちらも`null`と混同しません。`0x`、`0x0`、`0x00`を別のテストケースにするだけでも、空応答や先頭ゼロを誤処理する経路を見つけやすくなります。 ### 検証メモ 例はNode.js v22.16.0とv24.14.0で確認しました。空のバイト列、ゼロ数量、先頭ゼロを持つバイト列を区別し、不正な表記を拒否します。実RPCへの要求や、各プロバイダー独自の許容表記は確認していません。 関連記事：[Ethereum RPCのlatestがずれる理由](/archives/6024)、[ABIから関数識別子・入力データ・イベントログを読む方法](/archives/6005) [^eip1474]: [EIP-1474 — Value encoding](https://eips.ethereum.org/EIPS/eip-1474#value-encoding)。参照日：2026-09-05。状態：Stagnant。 [^schemas]: [Ethereum Execution APIs — base-types.yaml](https://github.com/ethereum/execution-apis/blob/main/src/schemas/base-types.yaml)。参照日：2026-09-05。 [^rpc]: [Ethereum.org — JSON-RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/)。参照日：2026-09-05。 [^abi]: [Solidity — Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html)。参照日：2026-09-05。 [^buffer]: [Node.js — Buffer / hexadecimal encoding](https://nodejs.org/api/buffer.html)。参照日：2026-09-05。 [^regexp]: [ECMAScript 2025：正規表現の入力境界](https://tc39.es/ecma262/2025/multipage/text-processing.html#sec-assertion)。参照日：2026-09-06。 ## 確認した一次情報 - [EIP-1474 — Value encoding](): 確認日 2026-09-05 - [Ethereum Execution APIs — base-types.yaml](): 確認日 2026-09-05 - [Ethereum.org — JSON-RPC API](): 確認日 2026-09-05 - [Solidity — Contract ABI Specification](): 確認日 2026-09-05 - [Node.js — Buffer / hexadecimal encoding](): 確認日 2026-09-05 - [ECMAScript 2025：正規表現の入力境界](): 確認日 2026-09-06 --- # abi.encodePackedの衝突はハッシュ前に起きる：abi.encodeとの違いを確認する abi.encodePackedで複数の文字列を連結すると区切りが消える理由を解説します。同じバイト列になる例、abi.encodeとの違い、区切り文字や署名で残る注意点を確認します。 正規URL: https://3mikan.com/archives/6072 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z `keccak256`でハッシュしているから、異なる入力は区別できる。Solidityでデータの識別子を作るとき、この考え方だけでは不十分です。 **ハッシュする前に異なる入力が同じバイト列へ変わっていれば、ハッシュ値も同じになります。** `abi.encodePacked`へ複数の可変長データを渡す場面では、この「連結時に境界が消える問題」を先に確認する必要があります。SolidityのABI仕様にも、この注意が明記されています。[^abi] 本記事では、文字列のバイト列をローカルで比較します。署名、ウォレット接続、コントラクトのデプロイは行いません。 掲載例はNode.js 22以降で実行できます。各節のコードを`example.mjs`へ保存し、同じ節で使う関数定義と呼び出しを合わせてから`node example.mjs`を実行してください。再利用できる関数は[packed-strings.mjs](/examples/offline-web3/packed-strings.mjs)から取得できます。 ## 2つの文字列でも、区切りが違えば別の入力 部署と権限のように、2つの文字列を独立した項目として扱うとします。 ```text 入力A：( "teamA", "read" ) 入力B：( "team", "Aread" ) ``` 2つの組み合わせは異なります。しかし、文字列を境界なしで連結すると、どちらも`teamAread`です。 ```text teamA | read → teamAread team | Aread → teamAread ``` `abi.encodePacked`で直接渡した`string`は、長さの情報を付けずにその内容を符号化します。この例では、Solidity側でも項目の区切りを失います。[^abi] ```solidity // 違う2組の入力が、同じバイト列になる説明用の式 abi.encodePacked("teamA", "read"); abi.encodePacked("team", "Aread"); ``` この現象は、異なるバイト列から同じハッシュ値を探し当てた話ではありません。**ハッシュへの入力が、すでに同一だった**という話です。問題の場所をハッシュ関数と取り違えると、修正する箇所もずれてしまいます。 ## まずはハッシュせず、連結後のバイト列を比べる 次のNode.jsコードは、上のASCII文字列について、長さ情報なしの連結を再現します。 ```js import assert from 'node:assert/strict'; const a = Buffer.concat([ Buffer.from('teamA', 'utf8'), Buffer.from('read', 'utf8') ]); const b = Buffer.concat([ Buffer.from('team', 'utf8'), Buffer.from('Aread', 'utf8') ]); assert.deepEqual(a, b); console.log(a.toString('hex')); console.log(a.equals(b)); ``` 実行結果は次のとおりです。 ```text 7465616d4172656164 true ``` Node.jsの`Buffer`を使い、文字列から作ったバイト列を連結・比較しています。[^buffer] 確認したのは、この2組の入力が同一の9バイトになることです。SolidityコンパイラやEVMの実行結果として報告しているわけではありません。 同じバイト列へ同じハッシュ関数を適用すれば、結果は同じです。そのため、この問題の再現に実アカウントや署名は要りません。ハッシュ値だけを見る前に、ハッシュ直前のバイト列をテストするのが分かりやすい方法です。 ## abi.encodeは項目の境界を残すが、型名まで埋め込むわけではない `abi.encode`の通常のABI符号化では、動的型のオフセットや長さを使ってデータを配置します。同じ`(string, string)`という型の組を前提にすると、先ほどの入力AとBは異なる符号化になります。[^abi] ```solidity // 同じ(string, string)型の入力を区別するための説明用の式 keccak256(abi.encode("teamA", "read")); keccak256(abi.encode("team", "Aread")); ``` ここで「abi.encodeなら、あらゆる意味の違いが自動で区別される」と広げないことが重要です。ABI符号化は自己記述的な形式ではありません。デコード側には、対応する型情報が必要です。[^abi] たとえば、`uint8(1)`と`uint256(1)`は、通常のABIでそれぞれ単独の引数として符号化すると同じ32バイトの値になります。「数量の1」と「権限レベルの1」といった業務上の意味も、値だけでは区別されません。 そのため、異なる用途で識別子を共有する設計なら、入力の型だけでなく、用途やバージョンを表す項目も固定するのが一つの設計方針です。まず「何と何を別物として扱いたいか」を定義し、それを符号化の入力へ反映します。 ## 区切り文字を1個足すだけでは解決しない 「間に`|`を入れればよい」と考えることもできます。しかし、入力自体に`|`を許すなら、次の2組が再び一致します。 ```text ("team|alpha", "read") → team|alpha|read ("team", "alpha|read") → team|alpha|read ``` これは本記事のローカルテストでも一致を確認した例です。区切り文字方式を採用するなら、文字の禁止、エスケープ、長さ情報などを含めた形式の定義が必要になります。 単なる文字列連結の問題を解決するために、独自の符号化規則を増やしすぎないことも大切です。すでにABIで型と順序を決められるなら、その構造を使うほうがレビューの対象を絞れます。 ## 関数の呼び出しデータと、識別用の符号化も分ける `abi.encode`や`abi.encodePacked`で値をバイト列にすることと、呼び出す関数を含むcalldataを作ることは別です。 Solidityには、関数セレクターを指定する`abi.encodeWithSelector`や、関数ポインターと引数の型を検査する`abi.encodeCall`があります。通常の関数呼び出しデータが必要な場面で、単にpacked形式へ変更するべきではありません。[^globals] この違いは、「短くなったから同じ意味の効率的な形式だ」と考えないために重要です。データ長を変えると、受け取る側が想定する形式との互換性も検討する必要があります。本記事ではガス削減量や実行性能の比較はしていません。 ## 署名に使う場合は、符号化とは別の確認も残る `abi.encode`へ変更して項目の境界を保存しても、署名の再利用や対象コントラクトの取り違えが自動で防げるわけではありません。 EIP-712は型付きデータとドメイン分離のための標準ですが、標準自体は再利用防止を含まないと明記しています。ノンスや期限を使う設計では、それらを署名対象へ入れるだけでなく、アプリケーション側で検証・消費する仕組みが必要です。[^eip712] ここでは署名の実装手順へ広げず、役割を分けます。符号化は「どの情報を同じデータとみなすか」、ドメイン分離は「どの文脈のデータか」、ノンス等の検証は「その操作を再び認めるか」という異なる課題です。 ## まとめ `abi.encodePacked`を見たら、最初にハッシュ関数ではなく、**入力の型・長さ・項目の境界**を確認します。 複数の可変長項目を境界なしで連結しない。通常のABI符号化でも型と用途の取り決めを省略しない。呼び出しデータや署名では、それぞれの形式と再利用防止を別に確認する。この整理をしてから、短さやガスコストを比較します。 ### 検証メモ 例はNode.js v22.16.0とv24.14.0で確認しました。ASCII文字列の区切り位置だけを変えても、連結後は同じバイト列になることを確かめています。Solidityの式は仕様を説明するためのもので、コンパイル、EVM実行、Keccak-256計算、署名検証、ガス計測は行っていません。付属のモデルは汎用ABIエンコーダーではありません。 関連記事：[ABIから関数識別子・入力データ・イベントログを読む方法](/archives/6005)、[EIP-712署名の読み方](/archives/6010) [^abi]: [Solidity — Contract ABI Specification / Non-standard Packed Mode](https://docs.soliditylang.org/en/latest/abi-spec.html#non-standard-packed-mode)。参照日：2026-09-05。 [^globals]: [Solidity — ABI Encoding and Decoding Functions](https://docs.soliditylang.org/en/latest/units-and-global-variables.html#abi-encoding-and-decoding-functions)。参照日：2026-09-05。 [^eip712]: [EIP-712 — Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712)。参照日：2026-09-05。 [^buffer]: [Node.js — Buffer](https://nodejs.org/api/buffer.html)。参照日：2026-09-05。 ## 確認した一次情報 - [Solidity — Contract ABI Specification / Non-standard Packed Mode](): 確認日 2026-09-05 - [Solidity — ABI Encoding and Decoding Functions](): 確認日 2026-09-05 - [EIP-712 — Typed structured data hashing and signing](): 確認日 2026-09-05 - [Node.js — Buffer](): 確認日 2026-09-05 --- # 整数除算はどこで丸める？BigIntで検算するSolidityの計算順序 整数の割り算では、掛ける順序と丸める単位で結果が変わります。BigIntのゼロ方向への丸め、切り上げ、Solidityの演算幅、個別計算と合計計算の違いを実行例で整理します。 正規URL: https://3mikan.com/archives/6073 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z 手数料や持分の計算式を、電卓では合っているのにコードでは再現できない。そんなときは小数点の表示を直す前に、**途中の割り算で端数を捨てていないか**を確認します。 実数として等しい式でも、整数演算では結果が変わります。この記事ではNode.jsのBigIntで小さな反例を実行し、Solidityの整数型へ移すときに残る上限・符号・中間積の違いまで整理します。アカウント、ブラウザ、RPC、デプロイは使いません。Solidityの挙動は一次仕様を参照し、掲載した結果はNode.jsでの実行結果と区別します。 掲載例はNode.js 22以降で実行できます。各節のコードを`example.mjs`へ保存し、同じ節で使う関数定義と呼び出しを合わせてから`node example.mjs`を実行してください。再利用できる関数は[integer-rounding.mjs](/examples/offline-web3/integer-rounding.mjs)から取得できます。 ## 同じ式に見えても、割る位置で結果が変わる 次のコードは、そのままNode.jsで実行できます。 ```js console.log((1n * 3n) / 2n); // 1n console.log((1n / 2n) * 3n); // 0n ``` 最初の式は3を2で割り、整数の1を残します。後の式は最初に1を2で割って0にするため、その後で3を掛けても1には戻りません。 これはBigIntの精度が足りない問題ではありません。整数の除算が、ゼロ方向へ丸めた整数を返すためです。小数部分を保持する処理ではないので、後から掛け算をしても、途中で捨てた情報は復元しません。[^bigint] ```text 掛けてから割る：1 × 3 = 3 → 3 ÷ 2 = 1 割ってから掛ける：1 ÷ 2 = 0 → 0 × 3 = 0 ``` 実装では、元の式だけでなく、どの演算がどの単位の整数を返すかを書き出します。数量を最小単位の整数に直す方法は、[ERC-20数量計算の記事](/archives/6070)で扱っています。単位変換と、その後の比率計算の丸めは別の仕様です。 ## 「切り捨て」は負数まで含めると曖昧になる 非負の値では、ゼロ方向への丸めと、数学でいう床関数による切り下げが一致します。しかし、負数では一致しません。 ```js console.log(-5n / 2n); // -2n console.log(Math.floor(-5 / 2)); // -3 console.log(-5n % 2n); // -1n ``` `-2.5`から小数部分を取り除いてゼロへ近づけると`-2`です。負の無限大へ向けて切り下げると`-3`です。「端数切り捨て」とだけ書くと、どちらを求める仕様なのか分かりません。[^bigint] Solidityの型付き整数の除算もゼロ方向へ丸めます。一方、`5 / 2`のような数値リテラル同士の式では、型付き整数の実行時演算とは異なり、有理数としての精度を保持することがあります。Solidityを確認する際は、`int256(-5) / int256(2)`のように型を明示した例と、リテラルだけの式を混同しないようにします。[^solidity] 以下の参照実装では、符号付きの丸め問題を混ぜないために、入力を非負の整数に限定します。 ## 切り上げは、商と余りを見て決める 非負の`a × b ÷ denominator`を考えます。商を`q`、余りを`r`とすると、次の関係を満たします。 ```text a × b = q × denominator + r 0 ≤ r < denominator ``` 切り下げなら`q`、切り上げなら余りがあるときだけ`q + 1`です。この規則をそのままコードにすると、割り切れる値やゼロを余分に1増やすことも防げます。 ```js function mulDivUnsigned(a, b, denominator, rounding = 'down') { const max = (1n << 256n) - 1n; for (const value of [a, b, denominator]) { if (typeof value !== 'bigint') throw new TypeError('expected bigint'); if (value < 0n || value > max) throw new RangeError('outside uint256'); } if (denominator === 0n) throw new RangeError('division by zero'); if (rounding !== 'down' && rounding !== 'up') { throw new TypeError('rounding must be down or up'); } const product = a * b; const quotient = product / denominator; const remainder = product % denominator; const result = quotient + (rounding === 'up' && remainder !== 0n ? 1n : 0n); if (result > max) throw new RangeError('result exceeds uint256'); return result; } console.log(mulDivUnsigned(5n, 3n, 2n)); // 7n console.log(mulDivUnsigned(5n, 3n, 2n, 'up')); // 8n console.log(mulDivUnsigned(6n, 3n, 2n, 'up')); // 9n console.log(mulDivUnsigned(0n, 3n, 2n, 'up')); // 0n ``` これはBigIntを使う**検算用の参照実装**です。入力と最終結果をuint256の範囲へ制限していますが、中間積まで256ビットに制限してはいません。 切り上げのために`(product + denominator - 1) / denominator`と書く方法も、非負かつ正の除数という条件では数学的に成立します。ただし、固定幅整数へ移すと、その足し算でも上限を超える可能性があります。参照実装では商と余りを使い、条件を読み取りやすくしています。 ## 「掛け算を先にする」だけではSolidity側の解決にならない 最大値を`M = 2^256 - 1`とすると、`M × 2 ÷ 2`の最終結果は`M`です。しかし、中間の`M × 2`はuint256の上限を超えます。 ```js const max = (1n << 256n) - 1n; console.log(mulDivUnsigned(max, 2n, 2n) === max); // true console.log(max * 2n > max); // true ``` BigIntはこの中間積を保持できます。Solidityの通常の`uint256`乗算ではオーバーフローを検査するため、中間結果が範囲を外れると処理が取り消されます。`unchecked`に変えても、元の精度を維持するのではなく、オーバーフロー時の扱いが変わるだけです。[^solidity] OpenZeppelinには、中間精度を保持して乗除算する`Math.mulDiv`が用意されています。採用時には使用バージョン、丸め方向、除数ゼロ、最終結果が範囲を超える場合の挙動を確認します。[^math] この記事のBigInt関数は、そのSolidity実装をコンパイル・実行して検証したものではありません。任意精度で求めた期待値と、コントラクトの実装結果を別々に照合するための基準です。 ## 個別計算の合計と、合計してからの計算は別の結果になる 1単位ずつの入力が10件あり、それぞれに`3 / 2`を掛けて切り下げるとします。 ```text 個別に計算：floor(1 × 3 ÷ 2) × 10 = 10 合計後に計算：floor(10 × 3 ÷ 2) = 15 ``` 差の5単位は、計算機の不具合ではありません。10回の除算で端数を捨てるか、最後の1回だけで捨てるかの違いです。 どちらを採用すべきかは、計算の用途によります。請求単位が1件ごとなのか、期間内の合計なのか、余りを次回へ持ち越すのか。その仕様を先に決めます。「精度が高そうだから合計してから計算する」と置き換えると、1件ごとの上限や契約上の丸め規則を変えてしまうことがあります。 小さな入力を何度も処理する場合は、1回だけの誤差ではなく、繰り返しによる差もテストへ含めます。持分の丸めが状態変化へ影響する例は、[状態保持型ファジングの比較記事](/archives/6053)にもつながります。 ## テストでは期待値だけでなく、不等式も確認する 非負の`a`・`b`と正の除数について、切り下げ結果`lo`が次の関係を満たすかを確認します。結果と除数を掛け戻せば元の積を超えず、結果を1増やして掛ければ元の積を超える、という関係です。 ```text lo × denominator ≤ a × b < (lo + 1) × denominator ``` 切り上げと切り下げの差は、割り切れる場合に0、それ以外に1です。これなら、特定の数値を並べたテストだけに依存しません。 そのうえで、0、1、割り切れる値、1単位の余り、uint256の最大値、最大値を超える最終結果、除数ゼロ、負数、Numberの誤入力を個別に確認します。全組合せテストも有限の入力範囲の検証であり、すべての業務要件の正しさを証明するものではありません。 ## まとめ 整数演算では、**単位、符号、丸め方向、丸める時点、中間積と最終結果の上限**をセットで決めます。 先に掛ければ途中の端数損失を減らせますが、固定幅整数のオーバーフローは別に残ります。BigIntを検算の正本にしながら、Solidity側では型と演算幅を明示し、ゼロ・境界値・繰り返し処理を確認するのが出発点です。 [^bigint]: [ECMAScript：BigIntの除算・剰余](https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-numeric-types-bigint-divide)。2026-09-05確認。 [^solidity]: [Solidity：整数型・除算・checked arithmetic](https://docs.soliditylang.org/en/v0.8.36/types.html#division)。2026-09-05確認。記事内のSolidity説明は仕様参照であり、本検証ではコンパイル・EVM実行をしていません。 [^math]: [OpenZeppelin Contracts 5.x：Math.mulDiv](https://docs.openzeppelin.com/contracts/5.x/api/utils#Math-mulDiv-uint256-uint256-uint256-)。2026-09-05確認。 ## 確認した一次情報 - [ECMAScript：BigIntの除算・剰余](): 確認日 2026-09-05 - [Solidity：整数型・除算・checked arithmetic](): 確認日 2026-09-05 - [OpenZeppelin Contracts 5.x：Math.mulDiv](): 確認日 2026-09-05 --- # JavaScriptの文字数とバイト数は違う：UTF-16・UTF-8・絵文字をローカルで確認する JavaScriptの文字数とUTF-8のバイト数が違う理由を、絵文字や結合文字で確認します。UTF-16、コードポイント、書記素クラスタ、正規化、壊さずに短くする処理を解説します。 正規URL: https://3mikan.com/archives/6074 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z 「32文字以下のはずなのに、保存先の32バイト制限に引っかかる」。反対に、「1文字だけ残したつもりなのに、絵文字が壊れる」。こうした問題では、文字列の内容より先に、**何を1として数えているか**を確認します。 JavaScriptの`length`、Unicodeのコードポイント、見た目に近いまとまり、UTF-8のバイト数は、同じ値になりません。この記事ではNode.jsの標準機能だけで違いを再現します。ウォレット、APIキー、外部サービス、ブラウザ操作は不要です。 掲載例はNode.js 22以降で実行できます。各節のコードを`example.mjs`へ保存し、同じ節で使う関数定義と呼び出しを合わせてから`node example.mjs`を実行してください。再利用できる関数は[text-length.mjs](/examples/offline-web3/text-length.mjs)から取得できます。 ## 「文字数」を四つの物差しに分ける JavaScriptの文字列の`length`はUTF-16のコード単位数です。1コード単位は16ビットで、基本多言語面（BMP：U+0000〜U+FFFF）の外側にあるコードポイントはサロゲートペアの2単位で表現されます。`[...text]`で数えられるのは、これとは別のコードポイント単位です。[^string] さらに、アクセント付きの文字や複数の絵文字が結合した表示では、複数のコードポイントが一つのまとまりになります。このまとまりを扱うのが書記素クラスタです。`Intl.Segmenter`は`granularity: 'grapheme'`でその境界を求めます。ただし、書記素数をフォント上の字形数や表示幅の完全な測定と同一視しません。[^segmenter][^grapheme] 最後のUTF-8バイト数は、実際にUTF-8へ符号化したデータの長さです。`TextEncoder`はUTF-8のバイト列を返します。[^encoding] | 値 | UTF-16コード単位 | コードポイント | 書記素クラスタ | UTF-8バイト | | --- | ---: | ---: | ---: | ---: | | `A` | 1 | 1 | 1 | 1 | | `あ` | 1 | 1 | 1 | 3 | | `😀` | 2 | 1 | 1 | 4 | | `é`（U+00E9） | 1 | 1 | 1 | 2 | | `e` + U+0301 | 2 | 2 | 1 | 3 | | `👨‍👩‍👧‍👦` | 11 | 7 | 1 | 25 | 上表はNode.js v22.16.0、ICU 77.1、Unicode 16.0で実行確認した値です。書記素分割の結果は実装が使うUnicodeデータにも依存するため、再現用にはNodeだけでなくICUとUnicodeのバージョンも残します。 ## 四種類の長さを一度に出してみる 次のコードは、そのままNode.jsで実行できます。 ```js const encoder = new TextEncoder(); const segmenter = new Intl.Segmenter('ja', { granularity: 'grapheme' }); function measureText(text) { if (typeof text !== 'string') throw new TypeError('expected string'); if (!text.isWellFormed()) throw new TypeError('unpaired surrogate'); return { codeUnits: text.length, codePoints: [...text].length, graphemes: [...segmenter.segment(text)].length, utf8Bytes: encoder.encode(text).length, }; } console.log(measureText('😀')); // { codeUnits: 2, codePoints: 1, graphemes: 1, utf8Bytes: 4 } ``` コード内でどれか一つを`length`という曖昧な名前にまとめず、`codeUnits`、`graphemes`、`utf8Bytes`のように単位を変数名へ残しています。入力欄の見た目の制約と、保存先のバイト制限を同じ値で判定しないためです。 たとえば表示名を「20書記素まで」とする規則と、送信データを「64 UTF-8バイトまで」とする規則は別々に判定します。前者を満たしても、後者を満たすとは限りません。 ## 同じ見た目でも、バイト列が一致するとは限らない `é`は、単独のU+00E9でも、`e`と結合アクセントU+0301の組でも表せます。次のコードでは、文字列もバイト列も異なります。 ```js const a = '\u00e9'; const b = 'e\u0301'; console.log(a === b); // false console.log(new TextEncoder().encode(a)); // Uint8Array(2) [195, 169] console.log(new TextEncoder().encode(b)); // Uint8Array(3) [101, 204, 129] console.log(b.normalize('NFC') === a); // true ``` Unicode正規化は、定義された関係にある表現を一定の形式へ揃える処理です。NFCとNFKCなどの形式には意味の違いがあり、何でも同じ文字列へまとめる機能ではありません。[^normalization] 検索や表示名の照合で正規化することはあっても、受け取ったバイト列の保存やハッシュ計算の直前で勝手に文字列を変更しないようにします。送信側と受信側で正規化の時点が違えば、同じ表示でも異なるデータを対象にできます。 「正規化すれば見た目が似た名前をすべて見抜ける」という意味でもありません。正規化、文字の同形性、本人性の確認は別の課題です。ここでは名前の安全性を判定するのではなく、文字列とバイト列の境界だけを検証します。 ## sliceでサロゲートペアを切ると文字列が壊れる JavaScriptの`slice`はコード単位のインデックスで切り出します。`😀`は2コード単位なので、1単位だけ残すと不対サロゲートになります。[^string] ```js const broken = '😀'.slice(0, 1); console.log(broken.isWellFormed()); // false console.log(new TextEncoder().encode(broken)); // Uint8Array(3) [239, 191, 189] ``` この3バイトは置換文字U+FFFDのUTF-8表現です。`TextEncoder`が元の絵文字を途中まで保存した結果ではありません。入力がUnicodeスカラー値として扱われる過程で、不対サロゲートが置換されます。[^encoding] そのため、この記事の`measureText`は`isWellFormed()`を先に確認し、意図しない置換を黙って受け入れません。置換して表示を継続することが適切な用途もありますが、元の入力を正確に保存する目的とは分けます。 ## バイト制限内で短くするなら、分割の単位も決める UTF-8のバイト配列を任意の位置で切ると、複数バイトで表されるコードポイントの途中を切る可能性があります。コードポイントを壊さないだけでは、結合アクセントやZWJ絵文字のまとまりを壊す場合も残ります。[^encoding][^grapheme] 次の例は、書記素のまとまりを保ったまま、UTF-8の予算内に収まる先頭部分を返します。先ほどの`encoder`と`segmenter`を使います。 ```js function fitUtf8Prefix(text, maxBytes) { if (typeof text !== 'string') throw new TypeError('expected string'); if (!text.isWellFormed()) throw new TypeError('unpaired surrogate'); if (!Number.isSafeInteger(maxBytes) || maxBytes < 0) { throw new RangeError('invalid byte budget'); } let result = ''; let bytes = 0; for (const { segment } of segmenter.segment(text)) { const width = encoder.encode(segment).length; if (bytes + width > maxBytes) break; result += segment; bytes += width; } return result; } console.log(fitUtf8Prefix('あ😀B', 6)); // あ console.log(fitUtf8Prefix('あ😀B', 7)); // あ😀 console.log(fitUtf8Prefix('あ😀B', 8)); // あ😀B ``` 6バイトの予算では、最初の`あ`の3バイトしか入りません。次の`😀`を加えると7バイトになるからです。収まらない書記素を飛ばして後の`B`を入れる処理ではなく、あくまで入力の先頭部分を返します。 家族絵文字1つが25バイトある場合、24バイトの予算では空文字列を返します。このような結果を許すか、入力をエラーにするかもアプリ側の仕様です。識別名や署名対象を短くする用途に、この表示用の切り詰めを自動適用してはいけません。 ## バイト列の長さと、ABI符号化後の長さも同じではない Solidityの`string`を`bytes(s).length`で見ると、バイト単位の長さを扱います。JavaScriptのUTF-16コード単位数と置き換えることはできません。UTF-8として同じ内容を渡す場合でも、その後にABIの動的型として符号化すると、オフセット、長さ、パディングなどが加わります。[^solidity][^abi] したがって、「元の文字列が3バイトだからcalldataも3バイト増える」とは限りません。文字列の長さ、UTF-8の長さ、ABIの符号化サイズを別々に記録します。ABIそのものの構造は[関数識別子・入力データ・イベントログの読み方](/archives/6005)で確認できます。 本記事は文字列の単位を切り分ける説明で、Solidityのコンパイル、デプロイ、ガス計測は実施していません。 ## まとめ 文字列の長さを扱う前に、**コード単位、コードポイント、書記素、UTF-8バイトのどれを制限するか**を決めます。 さらに、正規化するか、不対サロゲートを拒否するか、長すぎる入力を拒否するか表示だけ短くするかを明示します。ASCII、日本語、BMP外の絵文字、結合文字、ZWJ、空文字列を並べると、英数字だけのテストでは見えなかった境界を確認できます。 [^string]: [ECMAScript：文字列処理](https://tc39.es/ecma262/multipage/text-processing.html)。2026-09-05確認。 [^segmenter]: [ECMA-402：Intl.Segmenter](https://tc39.es/ecma402/#segmenter-objects)。2026-09-05確認。 [^grapheme]: [Unicode Standard Annex #29：Text Segmentation](https://unicode.org/reports/tr29/)。2026-09-05確認。 [^encoding]: [WHATWG Encoding Standard：TextEncoder](https://encoding.spec.whatwg.org/#interface-textencoder)。2026-09-05確認。 [^normalization]: [Unicode Standard Annex #15：Normalization Forms](https://www.unicode.org/reports/tr15/)。2026-09-05確認。 [^solidity]: [Solidity：bytesとstring](https://docs.soliditylang.org/en/latest/types.html#bytes-and-string-as-arrays)。2026-09-05確認。 [^abi]: [Solidity Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html)。2026-09-05確認。 ## 確認した一次情報 - [ECMAScript：文字列処理](): 確認日 2026-09-05 - [ECMA-402：Intl.Segmenter](): 確認日 2026-09-05 - [Unicode Standard Annex #29：Text Segmentation](): 確認日 2026-09-05 - [WHATWG Encoding Standard：TextEncoder](): 確認日 2026-09-05 - [Unicode Standard Annex #15：Normalization Forms](): 確認日 2026-09-05 - [Solidity：bytesとstring](): 確認日 2026-09-05 - [Solidity Contract ABI Specification](): 確認日 2026-09-05 --- # Ethereumのハッシュが合わないときは？Keccak-256・SHA3-256・文字列とバイト列 同じつもりの入力でハッシュが違う原因を、アルゴリズム、16進数の解釈、改行、Unicode正規化、関数シグネチャへ分け、アカウントなしで検算します。 正規URL: https://3mikan.com/archives/6075 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z ハッシュ値がコントラクト側と一致しない。そんなとき、いきなりネットワークやライブラリーの不具合を疑う前に、**同じ計算方法へ、同じバイト列を渡しているか**を確認します。 この記事は、関数の識別子やイベントのトピックを計算するときに値が合わず困っている開発者向けです。Keccak-256とSHA3-256の違い、16進表記と文字列、末尾の改行を順に切り分けます。外部RPC、ウォレット、APIキーは使いません。 掲載例はNode.js 22以降で実行できます。[hash-inputs.mjs](/examples/offline-protocol-reading/hash-inputs.mjs)を同じフォルダーへ保存し、各節のJavaScriptを別の`example.mjs`へ写して`node example.mjs`を実行してください。 ## 32バイトの出力でも、同じハッシュ関数とは限らない EthereumのABIで関数の識別子やイベントの識別に使うのはKeccak-256です。一方、SHA3-256は別の計算です。OpenSSLも`KECCAK-256`と`SHA3-256`を別の名前で提供しており、片方をもう片方の代用品にはできません。[^source1] [^source2] [^source3] 違いを確かめる最小の入力は、空のバイト列です。入力の文字コードやABIの組み立てを考える必要がないため、最初の動作確認に向いています。 ```text 空入力のKeccak-256 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 空入力のSHA3-256 0xa7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a ``` 上の値は、今回のローカル環境で計算して照合しました。どちらも出力の長さは32バイトですが、内容は一致しません。長さだけでアルゴリズムを判定しないことが大切です。 ## まず実行環境の対応を確認する 原稿の検算はNode.js v22.16.0とOpenSSL CLI 3.5.5で行い、公開準備ではNode.js v24.14.0とOpenSSL CLI 3.6.2でも同じ結果を確認しました。これは実行した環境であり、最新版の案内ではありません。 ```bash command -v openssl openssl version openssl list -digest-algorithms printf '%s' '' | openssl dgst -keccak-256 printf '%s' '' | openssl dgst -sha3-256 ``` `KECCAK-256`が使えることを確認してから進みます。Macでは`openssl`という名前でもLibreSSLが選ばれる場合があり、今回のMac標準のLibreSSL 3.3.6ではこの計算を実行できませんでした。対応するOpenSSLの実行ファイルがあるフォルダーを`PATH`の先頭へ追加し、上の確認をやり直します。 たとえばHomebrewの`openssl@3`を導入済みなら、同じ端末で`export PATH="$(brew --prefix openssl@3)/bin:$PATH"`を実行して選択できます。導入方法や場所は環境で異なるため、バージョン表示と空入力の結果で確認してください。`hash-inputs.mjs`も`PATH`から選ばれるコマンドを使います。エラーを消すために`sha3-256`へ置き換えてはいけません。[^source2] [^source3] なお、OSの`openssl`コマンドと、Node.jsが使うOpenSSLのバージョンは同じとは限りません。今回もNode.js側は3.0.16、CLI側は3.5.5でした。Node.jsの利用可能なハッシュ名は`getHashes()`で調べられます。[^source4] ```js import { getHashes } from 'node:crypto'; console.log(process.version); console.log(process.versions.openssl); console.log(getHashes().filter((name) => /keccak|sha3/i.test(name))); ``` ## 「0x1234」は2バイトにも6バイトにもなる 同じ画面に`0x1234`と表示されていても、関数へ渡すものは二通り考えられます。 | 入力としての意味 | 実際のバイト列 | 長さ | | --- | --- | --- | | 16進数を読み取ったDATA | `12 34` | 2バイト | | 文字列そのもののUTF-8 | `30 78 31 32 33 34` | 6バイト | 後者には、文字の`0`と`x`も含まれます。ハッシュ関数が間違っていなくても、ここが違えば結果は合いません。 次のコードは付属の`hash-inputs.mjs`と同じフォルダーで実行できます。`fromHex`は偶数桁の16進表記を検証してバイト列へ変換し、`utf8`は文字列をUTF-8へ変換します。どちらも不正な入力を黙って補正しません。 ```js import { fromHex, utf8, keccak256 } from './hash-inputs.mjs'; const bytes = fromHex('0x1234'); const text = utf8('0x1234'); console.log(bytes.length, text.length); // 2 6 console.log(keccak256(bytes)); console.log(keccak256(text)); ``` ```text 2バイトをハッシュ 0x56570de287d73cd1cb6092bb8fdee6173974955fdef345ae579ee9f475ea7432 6バイトの文字列をハッシュ 0x1ac7d1b81b7ba1025b36ccb86723da6ee5a87259f1c2fd5abe69d3200b512ec8 ``` ライブラリーの関数が何を入力として扱うかも確認します。たとえばethersの`keccak256`はバイト表現を受け取り、UTF-8の文章を扱う`id`とは入口が違います。[^source5] ## 改行や正規化は、ハッシュの前に決める `abc`と`abc`の後ろに改行があるデータは別物です。シェルで短い検算をする場合は、出力が一見同じでも、末尾のLFが加わっていないか確認します。 ```bash printf '%s' 'abc' | openssl dgst -keccak-256 printf '%s\n' 'abc' | openssl dgst -keccak-256 ``` 文字列を`trim()`して値が合ったとしても、それが正しい修正とは限りません。改行や空白を許す仕様なら、それもデータの一部だからです。まず入力の16進表記とバイト長を残し、どこで違いが生じたかを見ます。 見た目が同じ文字も同様です。このサンプルでは、`é`を一つのコードポイントで書いた値と、`e`に結合アクセントを続けた値は、UTF-8のバイト列もハッシュも異なりました。NFCで明示的に正規化した後は一致します。 ```js import { utf8, keccak256 } from './hash-inputs.mjs'; const a = '\u00e9'; const b = 'e\u0301'; console.log(keccak256(utf8(a)) === keccak256(utf8(b))); // false console.log(keccak256(utf8(a)) === keccak256(utf8(b.normalize('NFC')))); // true ``` 正規化をするかどうかは、ハッシュ関数ではなく入力仕様で決めます。この比較のために、既存プロトコルが定義するデータへ勝手な変換を追加しないようにします。 ## 関数名が同じでも、シグネチャの文字列を省略しない 関数の識別子は、ABIが定める正規形のシグネチャをKeccak-256へ渡し、その先頭4バイトを取ります。引数名や戻り値は含めず、`uint`の正規形は`uint256`です。[^source1] ```text transfer(address,uint256) → 先頭4バイトは 0xa9059cbb transfer(address,uint) → 上と同じ文字列ではない ``` この2つをそのままハッシュすると、先頭4バイトも異なります。文字列を直接ハッシュする関数が、Solidityの型の省略形を自動展開してくれるとは考えないでください。 ただし、識別子が一致することと、呼び出し先の正当性は別の確認です。4バイトだけを見て、相手の実装や権限まで判断する用途には広げません。全体の読み方は[ABIから関数識別子・入力データ・イベントログを読む方法](/archives/6005)で整理しています。 ## 不一致を調べるときに残すもの まずアルゴリズム名を固定し、次にハッシュ直前のバイト列を16進表記と長さで比べます。その後に、文字コード、正規化、ABIの型と順序を確認します。 入力が一致しているのに出力が違う場合にはじめて、実装やバージョンの差を調べます。確認用の空入力と既知の関数シグネチャを一緒に残しておくと、「データの作り方」と「ハッシュ処理」を切り分けやすくなります。 ここで使ったのは公開してよい架空データだけです。実システムの入力を記録するときも、秘密鍵、署名前の機密情報、個人情報をログへ残す必要はありません。 ## 参考資料 確認日：2026年9月5日。本文の計算例はローカル実行。Solidityのコンパイル、EVM実行、実ネットワークとの照合は行っていません。 [^source1]: [Solidity Contract ABI Specification: Function Selector](https://docs.soliditylang.org/en/v0.8.36/abi-spec.html) [^source2]: [OpenSSL KECCAK implementations](https://docs.openssl.org/3.5/man7/EVP_MD-KECCAK/) [^source3]: [OpenSSL SHA3 implementations](https://docs.openssl.org/3.5/man7/EVP_MD-SHA3/) [^source4]: [Node.js Crypto: getHashes / createHash](https://nodejs.org/docs/latest-v22.x/api/crypto.html) [^source5]: [ethers v6 Cryptographic Functions](https://docs.ethers.org/v6/api/crypto/) ## 確認した一次情報 - [Solidity Contract ABI Specification: Function Selector](): 確認日 2026-09-05 - [OpenSSL KECCAK implementations](): 確認日 2026-09-05 - [OpenSSL SHA3 implementations](): 確認日 2026-09-05 - [Node.js Crypto: getHashes / createHash](): 確認日 2026-09-05 - [ethers v6 Cryptographic Functions](): 確認日 2026-09-05 --- # indexed stringはなぜログから読めない？検索用トピックと原文を分ける イベントのindexed文字列がハッシュになる理由を、topicsとdataの違い、候補値の照合、通常のABI符号化との違いから説明します。実アカウントを使わず合成ログで検算します。 正規URL: https://3mikan.com/archives/6076 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z イベントに文字列を渡したのに、ログを読むと長い16進数しか出てこない。ABIを渡しても元の文章へ戻らない。まず確認したいのは、その引数に**`indexed`が付いているか**です。 この記事は、イベントを読む開発者と、検索しやすいイベントを設計したい人向けです。検索用のトピックと、文字列を残すデータ領域の役割を分けます。使うログはローカルで作った合成データで、実コントラクトが出力したレシートではありません。 掲載例はNode.js 22以降で実行できます。[hash-inputs.mjs](/examples/offline-protocol-reading/hash-inputs.mjs)と[event-string.mjs](/examples/offline-protocol-reading/event-string.mjs)を同じフォルダーへ保存し、各節のJavaScriptを別の`example.mjs`へ写して`node example.mjs`を実行してください。ハッシュ計算にはKECCAK-256対応のOpenSSLコマンドも必要です。[ハッシュ計算の実行環境を確かめる手順](/archives/6075)で、実際に使うコマンドを先に確認します。 ## indexedは検索用の場所へ値を置く指定 通常の、`anonymous`ではないイベントを考えます。 ```solidity // 宣言の説明例。この記事ではコンパイル・emitを実行しない。 event Message(string indexed tag, string body); ``` この宣言では`tag`と`body`の保存のされ方が異なります。Solidityのイベント仕様[^source1]では、`indexed`の引数はトピックへ、それ以外の引数はABI符号化された`data`へ配置します。 | ログの場所 | この宣言での内容 | | --- | --- | | `topics[0]` | `Message(string,string)`のKeccak-256 | | `topics[1]` | `tag`のUTF-8内容をKeccak-256へ渡した値 | | `data` | `body`を一つの`string`引数としてABI符号化した値 | ここで対象にしているのは、イベントへ直接渡す`string`です。配列や構造体の索引化に使う符号化を、同じ単純な文字列連結だとは考えないでください。[^source2] ## 短い文字列でも、stringならハッシュになる トピックの1枠は32バイトですが、4文字の`memo`だから原文がそのまま入る、という動作にはなりません。`string`は動的型なので、`indexed`なら原文ではなくハッシュが入ります。一方、たとえば`bytes32`という固定長型には別の符号化規則があります。[^source1] [^source2] この違いを、`tag = "memo"`、`body = "hello"`で確認します。付属の`event-string.mjs`を使うと、実ネットワークに接続せずに三つの欄を組み立てられます。 ```js import { syntheticMessageLog, decodeOneString } from './event-string.mjs'; const log = syntheticMessageLog('memo', 'hello'); console.log(log.evidenceType); console.log(log.topics[1]); console.log(decodeOneString(log.data)); ``` ```text synthetic-abi-log-not-a-receipt 0xeb687308225e4cab27dd7768e7f14b81f97eab5ac3aedeb0e1ce58fc4a31c7de hello ``` `hello`は`data`側から読めます。しかし、`topics[1]`を文字コードとして解釈しても、そこに`memo`のUTF-8原文が保存されているわけではありません。 この合成ログはバイト配置を学ぶためのものです。発行元アドレス、ブロック、トランザクション、実行結果を証明しません。 ## 候補を照合することと、元へ戻すことは違う 元の文字列が分からない状態でハッシュから文章を読み戻すことと、「この値はmemoか」と候補を計算して比べることは別です。 ```js import { syntheticMessageLog, candidateMatchesStringTopic } from './event-string.mjs'; const topic = syntheticMessageLog('memo', 'hello').topics[1]; console.log(candidateMatchesStringTopic('memo', topic)); // true console.log(candidateMatchesStringTopic('other', topic)); // false ``` 索引化された動的型は、候補を既に知っている検索には使えます。ただし、そのトピックだけで任意の原文をデコードできるわけではありません。[^source1] また、ハッシュで残したから秘密になったとも考えません。たとえば候補が`memo`と`other`の二つしかなければ、上のように両方を試せます。個人情報や秘密の文字列を入れるかどうかは、検索しやすさとは別に判断します。 ## keccak256(abi.encode(tag))とは入力が違う ここは間違えやすい箇所です。直接の`indexed string`は、文字列の内容を長さやパディングなしで符号化します。通常の`abi.encode(string)`では、動的型のオフセット、バイト長、パディングが関係するため、同じ文字列でもハッシュ前のバイト列が異なります。[^source2] [^source3] ```js import { keccak256, utf8, fromHex } from './hash-inputs.mjs'; import { encodeOneString } from './event-string.mjs'; const contentHash = keccak256(utf8('memo')); const abiHash = keccak256(fromHex(encodeOneString('memo'))); console.log(contentHash === abiHash); // false ``` 一つの`string`として`hello`をABI符号化すると、今回の例は96バイトになります。最初の32バイトがオフセット32、次の32バイトがUTF-8の長さ5、その後が`68 65 6c 6c 6f`と27バイトのゼロ埋めです。 付属の`decodeOneString`は、この単一文字列の配置だけを読む学習用コードです。オフセット、長さ、末尾のゼロ埋め、不正なUTF-8を検査しますが、タプルや配列まで扱う汎用ABIデコーダーではありません。 ## 原文も必要なら、別の非indexed引数へ残す 検索と原文表示の両方が要る場合は、同じ値を索引化する引数と、原文を保存する引数を分ける設計が考えられます。SolidityのABI仕様にも、この分離が示されています。[^source1] ```solidity // 宣言の設計例。送信・デプロイ用の手順ではない。 event MessageRecorded( string indexed tag, string tagPlain, string body ); ``` この宣言だけでは、`tag`と`tagPlain`が同じになる保証はありません。実装側で同じ値を渡し、読む側でも「原文をハッシュし直した結果が検索用トピックと一致するか」を確認するのが検証方法になります。 原文を追加すれば保存するデータも増えます。この記事ではガス使用量を測っていないため、安くなる、何円増えるといった比較はしません。原文を公開する必要性と、保存する情報の範囲を先に決めます。 ## `topics[0]`だけで、イベントの型を断定しない イベントの識別文字列には、名前と正規形の引数型が入ります。`indexed`の有無や引数名自体は入りません。そのため、索引化する引数の位置が違っても、名前と型の並びが同じなら同じ識別トピックになります。[^source1] さらに`anonymous`イベントでは、通常のイベント識別用トピックがありません。実際のログを解釈するときは、発行元、対応するABI、`indexed`の位置、`anonymous`の指定をそろえる必要があります。[^source4] 既知のトピック文字列が見つかったという理由だけで、特定の実装や操作結果まで決めつけないようにします。ABI全体の読み方は[入力データとイベントログの解説](/archives/6005)へつながります。 ## まとめ `indexed string`で残るのは、原文ではなく検索用のハッシュです。候補をハッシュして一致を確かめることはできますが、任意の原文をその欄から読むこととは違います。 トピックの計算が合わないときは、まず直接の文字列をハッシュしているか、通常のABI符号化まで入れていないかを確認します。原文表示も要る場合は、別の非索引引数へ残す設計を検討します。 ## 参考資料 確認日：2026年9月5日。Node.js v22.16.0とOpenSSL CLI 3.5.5でハッシュ・合成ABIデータを検算しました。Solidityコンパイル、EVM、実ログ取得は未実施です。 [^source1]: [Solidity ABI: Events](https://docs.soliditylang.org/en/v0.8.36/abi-spec.html#events) [^source2]: [Solidity ABI: Encoding of Indexed Event Parameters](https://docs.soliditylang.org/en/v0.8.36/abi-spec.html#encoding-of-indexed-event-parameters) [^source3]: [Solidity ABI: Formal Specification of the Encoding](https://docs.soliditylang.org/en/v0.8.36/abi-spec.html#formal-specification-of-the-encoding) [^source4]: [Solidity Contracts: Events](https://docs.soliditylang.org/en/v0.8.36/contracts.html#events) ## 確認した一次情報 - [Solidity ABI: Events](): 確認日 2026-09-05 - [Solidity ABI: Encoding of Indexed Event Parameters](): 確認日 2026-09-05 - [Solidity ABI: Formal Specification of the Encoding](): 確認日 2026-09-05 - [Solidity Contracts: Events](): 確認日 2026-09-05 --- # JSON-RPCの一括応答を配列順で読まない：id・部分失敗・欠損の検証 JSON-RPCのバッチ応答を送信順に対応付けるバグを、逆順の合成応答で再現。idの型、重複、未知id、部分失敗、null、通知を分けて検証します。 正規URL: https://3mikan.com/archives/6077 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z 複数のRPCをまとめたら、残高の欄に別の値が入った。どの値も16進数としては正しいので、形式チェックにも引っかからない。こうしたバグでは、**応答配列の順番と、送信した要求の順番を同じだと思っていないか**を確認します。 この記事は、Ethereum RPCなどの一括処理を実装する開発者向けです。外部RPCへは接続せず、ローカルのJSONから要求と応答を正しく照合する方法を確かめます。速度比較やプロバイダー選びではなく、応答を取り違えないことが目的です。 掲載例はNode.js 22以降で実行できます。[rpc-batch.mjs](/examples/offline-protocol-reading/rpc-batch.mjs)を同じフォルダーへ保存し、各節のJavaScriptを別の`example.mjs`へ写して`node example.mjs`を実行してください。 ## バッチ応答の順番は保証されない JSON-RPC 2.0では、バッチに対する応答の順番は任意です。要求との対応は配列の位置ではなく、それぞれの`id`で確認します。[^source1] 次の二つの要求を送ったとします。 ```json [ {"jsonrpc":"2.0","id":"chain","method":"eth_chainId","params":[]}, {"jsonrpc":"2.0","id":"height","method":"eth_blockNumber","params":[]} ] ``` 説明用の応答は、意図的に逆順へ並べています。下のブロック番号は架空の値で、現在のチェーンの観測ではありません。 ```json [ {"jsonrpc":"2.0","id":"height","result":"0x41"}, {"jsonrpc":"2.0","id":"chain","result":"0x1"} ] ``` これを`responses[0].result`からチェーンIDへ代入すると、架空のブロック番号65をチェーンIDとして扱ってしまいます。両方とも数量として正しい16進表記なので、値の形式だけを確認しても取り違えは検出できません。 ## 受信後にidで対応付け、最後に必要な順へ並べる 付属の`rpc-batch.mjs`は、要求から期待するIDの集合を作り、各応答を照合した後、要求順に結果を返します。 ```js import { matchBatch } from './rpc-batch.mjs'; const requests = [ { jsonrpc: '2.0', id: 'chain', method: 'eth_chainId', params: [] }, { jsonrpc: '2.0', id: 'height', method: 'eth_blockNumber', params: [] }, ]; const responses = [ { jsonrpc: '2.0', id: 'height', result: '0x41' }, { jsonrpc: '2.0', id: 'chain', result: '0x1' }, ]; console.log(matchBatch(requests, responses)); ``` ```text [ { id: 'chain', ok: true, result: '0x1' }, { id: 'height', ok: true, result: '0x41' } ] ``` 内部で大切なのは、Mapに入れる前に「送ったIDか」「同じIDが既に返っていないか」を確認することです。単に`new Map(responses.map(...))`とすると、重複したキーを後の値で上書きしてしまいます。 ```js const expected = new Set(['chain', 'height']); const found = new Map(); for (const response of responses) { if (!expected.has(response.id)) throw new Error('unknown response id'); if (found.has(response.id)) throw new Error('duplicate response id'); found.set(response.id, response); } if (found.size !== expected.size) throw new Error('missing response id'); ``` 直前の例で定義した`responses`へ続ける、対応確認部分だけを抜き出した例です。完全なサンプルでは、その前に要求・応答の形式とIDの型を確認し、後で成功・エラーを分けています。 ## 数値の7と文字列の"7"を一緒にしない JSON-RPCのIDは文字列または数値などを取れますが、応答は要求のIDと同じ値を返します。受信側で勝手に文字列へ変換してから照合する設計は避けます。[^source1] ```js const byId = new Map([[7, 'numeric'], ['7', 'string']]); console.log(byId.size); // 2 console.log(byId.get(7)); // numeric console.log(byId.get('7')); // string ``` このサンプルの入力方針は、文字列か、非負の安全な整数だけを許可するものです。`null`、小数、負数、`-0`、安全な整数の範囲外の値は使いません。これは取り違えを減らすための実装上の制約であり、JSON-RPCがそのすべてを一律に禁止しているという意味ではありません。 特に巨大なIDをJSONの数値として渡すと、JavaScriptで読み込む段階の精度が問題になります。長い通し番号や外部で付けた識別子には、最初から文字列を使う方針が扱いやすくなります。 ## 一件の失敗と、応答全体の不正を分ける JSON-RPC応答には`result`か`error`のどちらかが入り、両方は入りません。バッチの中には、成功した応答と個別のエラー応答が混在できます。[^source1] ここでは個別エラーを`ok: false`の結果として残します。一方、未知IDや重複、欠損は、対応付け自体を信頼できないため、例外として止めます。 | 状態 | サンプルでの扱い | 理由 | | --- | --- | --- | | 逆順だがIDは対応している | 要求順へ並べ直す | 並び順は意味ではない | | 既知IDの`error` | 個別の失敗として残す | 別の要求の成功を消さない | | 同じIDが2回ある | 全体の照合を停止 | どちらを採用するか決めない | | 送っていないIDがある | 全体の照合を停止 | 別の要求へ割り当てない | | 期待したIDがない | 全体の照合を停止 | 欠損をゼロで補わない | | `result`と`error`が両方ある | 形式不正として停止 | 成功か失敗かを推測しない | エラーの分類によって、何を保存するかが変わります。`-32601`のような個別エラーコードと、JSONとして読めなかった問題は、同じ「RPC失敗」の一言にまとめないようにします。 ## result:nullを「結果なし」と判定しない `if (response.result)`のような真偽値による確認では、`null`、`false`、0、空文字列を、プロパティそのものがない状態と混同します。 ```js const a = { jsonrpc: '2.0', id: 'receipt', result: null }; const b = { jsonrpc: '2.0', id: 'receipt' }; console.log(Object.hasOwn(a, 'result')); // true console.log(Object.hasOwn(b, 'result')); // false ``` ここでの`ok: true`は、JSON-RPCの成功側の形式で返った、という意味に限定します。たとえば`eth_getTransactionReceipt`の`null`はレシートが見つからない状態であり、トランザクションの成功を表すわけではありません。[^source2] 対応付けが成功した後に、メソッドごとの値の意味を別途確認します。 ## 通知と、バッチ全体のエラーは別の経路にする `id`を省略した要求は通知で、応答を返す対象ではありません。通知だけのバッチにも、空配列の応答を期待するべきではありません。[^source1] サンプルでは通常の要求に混ざった通知は応答数から外します。一方、通知だけの送信は`matchBatch`へ渡さず、応答を照合しない処理へ分けます。今回は受信結果を扱う読み取り例に限定し、送信や再送の実装は扱いません。 また、不正JSONや空の要求配列など、バッチ自体が認識されない場合には、単一のエラーオブジェクトが返る場合があります。これを無理に一要素配列へ包んで、最初の要求の失敗と決めつけないようにします。[^source1] ## IDが一致しても、同じ時点のデータとは限らない この検証で解決するのは「どの要求への返答か」です。全件を同じブロックで読んだことや、一つの原子的な操作として実行されたことまで保証するものではありません。 時点をそろえる課題は、[Ethereum RPCの固定ブロック・履歴状態・Multicallの解説](/archives/6024)へ分けます。本記事のID照合を、スナップショットの保証として使わないことが重要です。 ## まとめ 一括応答は、配列順ではなくIDで照合します。その際、型、未知ID、重複、欠損を検査し、個別エラーと応答全体の不正を分けます。 付属コードが扱うのは、JSONとして読み込んだ後の要求と応答です。HTTPの失敗、タイムアウト、応答サイズ、重複したJSONプロパティ名、メソッドごとの結果型は別途検証が必要です。この境界を明確にしておくと、形式が正しい値を別の用途へ割り当てるバグを見つけやすくなります。 ## 参考資料 確認日：2026年9月5日。Node.js v22.16.0で、外部通信なしの合成要求・応答を使って検証しました。 [^source1]: [JSON-RPC 2.0 Specification: Request / Response / Batch](https://www.jsonrpc.org/specification) [^source2]: [Ethereum JSON-RPC API: eth_getTransactionReceipt](https://ethereum.org/en/developers/docs/apis/json-rpc/) ## 確認した一次情報 - [JSON-RPC 2.0 Specification: Request / Response / Batch](): 確認日 2026-09-05 - [Ethereum JSON-RPC API: eth\_getTransactionReceipt](): 確認日 2026-09-05 --- # Solidityのmemory・storage・calldata：配列の代入はコピーか参照か memoryへ代入した配列が一緒に変わる理由を、保存先と代入先から整理します。独立したコピー、状態の書き換え、calldataの変更禁止を小さなSolidityコードで確かめます。 正規URL: https://3mikan.com/archives/6078 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z Solidityで配列を別の変数へ代入してから書き換えたら、元の配列まで変わった。反対に、変更したはずの値がコントラクトへ保存されなかった。この二つは、どちらもデータの置き場所と代入の意味を取り違えると起きます。 この記事は、`memory`・`storage`・`calldata`を「一時的か永続的か」だけで覚えている開発者向けです。小さな整数配列を使い、**別の名前で同じデータを指す場合と、独立したコピーを作る場合**を見分けます。 扱うのは言語の挙動だけです。ウォレット接続、アカウント登録、外部RPC、送金は必要ありません。 ## 保存期間と、代入の意味を分ける `storage`はコントラクトの状態を保存する場所、`memory`は一回の外部呼び出しの実行中に使う一時領域、`calldata`は変更できない入力領域です。ただし、置き場所の説明だけでは、代入後に元の値が変わるかを判断できません。 たとえば、机の書類に別の付箋を貼ることと、書類をコピーして別の机へ置くことは違います。変数名が二つあるからといって、データ本体も二つあるとは限りません。 [Solidityの代入規則](https://docs.soliditylang.org/en/v0.8.36/types.html#data-location-and-assignment-behavior)に沿って、まず次の区別を使います。 | 代入するもの | 代入後の関係 | 書き換えたとき | | --- | --- | --- | | `memory`の配列を別の`memory`変数へ | 同じ配列への参照 | 両方の名前から変更が見える | | 状態配列をローカルの`storage`変数へ | 同じ状態配列への参照 | コントラクトの状態が変わる | | 状態配列を`memory`変数へ | 独立したコピー | コピーの編集だけでは状態は変わらない | | `memory`配列を状態変数へ | 状態側へコピー | 元の一時配列を後で編集しても状態には反映されない | | `calldata`の配列を`memory`変数へ | 編集できるコピー | 入力領域は変わらない | この表は配列などの参照型についてのものです。`uint256`や`bool`を変数へ代入する値型の話と混ぜないでください。また、「`storage`への代入はすべて参照」とも覚えないようにします。**ローカル変数の参照を作るのか、状態変数そのものへ値を代入するのか**が違います。 ## 一つのコントラクトで六つの違いを見る 次のコードは、最初の状態配列を`[10, 20]`にします。各関数を新しく作ったコントラクトで試すと、前の例による状態変更を混ぜずに比較できます。 `DataLocations.sol`という名前で保存してください。 ```solidity // SPDX-License-Identifier: MIT pragma solidity 0.8.36; contract DataLocations { uint256[] private stored; constructor() { stored.push(10); stored.push(20); } function memoryAlias() external pure returns (uint256, uint256) { uint256[] memory a = new uint256[](1); a[0] = 10; uint256[] memory b = a; b[0] = 99; return (a[0], b[0]); } function independentMemory() external pure returns (uint256, uint256) { uint256[] memory a = new uint256[](1); a[0] = 10; uint256[] memory b = new uint256[](a.length); for (uint256 i; i < a.length; ++i) b[i] = a[i]; b[0] = 99; return (a[0], b[0]); } function storageToMemory() external view returns (uint256, uint256) { uint256[] memory copy = stored; copy[0] = 99; return (stored[0], copy[0]); } function storageAlias() external returns (uint256) { uint256[] storage ref = stored; ref[0] = 99; return stored[0]; } function memoryToStorage() external returns (uint256, uint256) { uint256[] memory input = new uint256[](1); input[0] = 7; stored = input; input[0] = 99; return (stored[0], input[0]); } function calldataToMemory(uint256[] calldata input) external pure returns (uint256, uint256) { require(input.length > 0, "empty input"); uint256[] memory copy = input; copy[0] = 99; return (input[0], copy[0]); } function first() external view returns (uint256) { return stored[0]; } } ``` 最初に見るのは`memoryAlias`です。`b = a`は新しい配列を作らないため、`b[0] = 99`の後は`a[0]`も99です。返り値は`(99, 99)`になります。 `independentMemory`では、先に`new`で別の配列を確保し、整数を一つずつ移しています。そのため返り値は`(10, 99)`で、元の配列は変わりません。 このコピーは`uint256[]`に対する例です。要素がさらに参照型になっている入れ子の配列へ、同じ一重のループをそのまま「深いコピー」として適用しないでください。各階層で独立させたいデータを確保する必要があります。 ## memoryの編集は、状態への保存とは違う `storageToMemory`は、状態配列を一時領域へコピーしてから編集します。返り値は`(10, 99)`であり、続けて`first()`を読んでも状態側は10です。 一方、`storageAlias`が作る`ref`は、状態配列につけた別名です。そこへ99を書けば、続く`first()`も99になります。ローカル変数として宣言していても、参照先がローカルな一時データになるわけではありません。 `memoryToStorage`は別の方向です。まず`[7]`を状態変数へ代入し、その後で元の一時配列を99に変えます。返り値は`(7, 99)`となり、保存した7は後からの変更に追従しません。 状態更新のレビューでは、変数名の印象よりも、`storage`参照への書き込みがどこにあるかを追うと判断しやすくなります。 ## calldataは「変更する前にコピーする」 `calldataToMemory([10])`は`(10, 99)`を返します。読み取り専用の入力から、編集できる一時配列を作ったためです。 コピーを省いて`input[0] = 99`と書いたコードは、Solidity 0.8.36ではコンパイル時に拒否されます。実行時に失敗したり、状態へ保存されなかったりする話ではなく、そもそも有効なコードになりません。 空配列は、別の条件です。この例では添字0を読む前に`require`で拒否します。「どの領域か」と「その添字が存在するか」は別々に検査します。 ## 小さなテストで判断を固定する Foundryを導入したうえで、空の作業フォルダーに`src`と`test`という名前のフォルダーを作ります。上の`DataLocations.sol`は`src`の中へ、次のコードは`test`の中に`DataLocations.t.sol`として保存してください。外部ライブラリーは使いません。 ```solidity // SPDX-License-Identifier: MIT pragma solidity 0.8.36; import {DataLocations} from "../src/DataLocations.sol"; contract DataLocationsSmokeTest { function testCopyAndReference() public { DataLocations example = new DataLocations(); (uint256 a, uint256 b) = example.memoryAlias(); assert(a == 99 && b == 99); (a, b) = example.storageToMemory(); assert(a == 10 && b == 99); assert(example.storageAlias() == 99); assert(example.first() == 99); } } ``` ```sh forge test --use 0.8.36 --evm-version prague --optimize --optimizer-runs 200 ``` コンパイラーの初回取得にはネットワークを使う場合がありますが、例の実行にチェーンへの接続は不要です。導入済みのコンパイラーを使う場合は、`--use`へ実行ファイルのパスを渡して`--offline`を指定します。 ## 確認した環境と範囲 | 項目 | 使用した条件 | | --- | --- | | 確認日 | 2026年9月5日 | | コンパイラー | Solidity 0.8.36、ビルド識別子`8a079791` | | テスト実行 | Foundry 1.8.0 | | EVM設定 | Prague | | 最適化 | 有効、200 runs | | OS | Ubuntu 24.04.4、x86_64 | 例のコントラクトはコンパイルし、隔離したEVM上で返り値と失敗条件を検証しています。公開チェーンへの接続、実ウォレットの操作、送信はしていません。表示されたガス値の優劣や実運用の安全性を比較する記事ではありません。 ## まとめ 代入を読んだら、元と先のデータ領域を確認し、さらに代入先がローカルの参照変数なのか、状態変数なのかを見ます。 同じ配列へ別名をつけたのか、独立した配列を作ったのか、状態へ書き戻したのか。この三つを区別すれば、「元まで変わった」と「保存されなかった」を同じ原因として扱わずに済みます。 外部から渡された配列がどのバイト列へ符号化されるかは、[ABIと入力データの読み方](/archives/6005)で確認できます。入力の符号化と、実行中のコピー・参照は別の層として整理してください。 ## 確認した一次情報 - [Solidity: Data location and assignment behavior](): 確認日 2026-09-05 - [Solidity: Arrays](): 確認日 2026-09-05 --- # Solidity 0.8でもuint8変換は値を切り捨てる：縮小変換と演算の違い uint256をuint8へ変換したときの切り捨てを、演算オーバーフローと区別します。255・256の境界、変換前の検査、演算前の拡張、bytes型との違いを検証します。 正規URL: https://3mikan.com/archives/6079 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z Solidity 0.8以降は、通常の整数演算で範囲を超えると失敗します。しかし、その知識だけで`uint8(value)`のような型変換まで安全だと判断すると、値を失うことがあります。 この記事は、小さい整数型で値を保存したり、APIの入力を別の型へ変換したりする開発者向けです。**演算のオーバーフロー検査と、明示的な縮小変換は別の規則**だと整理し、変換前に何を確かめるべきかを示します。 使うのは整数とローカルのEVMだけです。ウォレット、送金、外部RPC、サービスのアカウントは使いません。 ## 256をuint8へ変えると、どうなるか `uint8`の範囲は0から255です。8ビットでは256通りしか表現できないため、256をそのまま保存することはできません。 次の`narrow`は、引数を明示的に`uint8`へ変換します。Solidityの[型変換仕様](https://docs.soliditylang.org/en/v0.8.36/types.html#explicit-conversions)では、大きい整数型から小さい整数型へ変換すると、上位のビットが切り捨てられます。 このコントラクトを`Narrowing.sol`として保存してください。 ```solidity // SPDX-License-Identifier: MIT pragma solidity 0.8.36; contract Narrowing { error OutOfRange(uint256 value); function narrow(uint256 value) external pure returns (uint8) { return uint8(value); } function checkedNarrow(uint256 value) external pure returns (uint8) { if (value > type(uint8).max) revert OutOfRange(value); return uint8(value); } function addSmall(uint8 a, uint8 b) external pure returns (uint8) { return a + b; } function castAfterAdd(uint8 a, uint8 b) external pure returns (uint256) { return uint256(a + b); } function widenBeforeAdd(uint8 a, uint8 b) external pure returns (uint256) { return uint256(a) + uint256(b); } function integerAndBytes(uint16 value) external pure returns (uint8, bytes1) { return (uint8(value), bytes1(bytes2(value))); } function reinterpretSign(int8 value) external pure returns (uint8) { return uint8(value); } } ``` `narrow`へ渡す値と結果は、次のように対応します。 | 引数のuint256 | 下位8ビットだけを残した結果 | | --- | --- | | 0 | 0 | | 255 | 255 | | 256 | 0 | | 257 | 1 | | 1000 | 232 | | `type(uint256).max` | 255 | これは「255を超えたら255へ丸める」処理ではありません。非負の整数について、256で割った余りと同じ結果になります。値の上限を検査する用途には使えません。 ## checkedNarrowは、値を失う前に止める 同じコントラクトの`checkedNarrow`は、元の`uint256`のまま上限を比較します。255以下なら変換し、256以上なら`OutOfRange`で失敗します。 比較する順序が大切です。先に`uint8`へ変換してから「255以下か」を調べても、切り捨て前の情報は残っていません。`uint8`の値はすでに0から255なので、その比較は元の範囲超過を検出できません。 独自の検査を各所へ書きたくない場合は、[OpenZeppelinのSafeCast](https://docs.openzeppelin.com/contracts/5.x/api/utils#SafeCast)にも、範囲外なら失敗する`toUint8`などがあります。ここで実行する最小例はそのライブラリーを使わず、検査する位置を見える形にしています。 また、型の範囲に収まることと、業務上の上限に収まることは別です。許容値が100までなら、255以下という条件だけでは足りません。 ## 「足してから大きい型へ」では間に合わない `addSmall(255, 1)`は、`uint8`の加算として範囲を超え、通常の検査付き演算では失敗します。これは`narrow(256)`が0を返す挙動とは違います。 `castAfterAdd(200, 100)`も失敗します。先に計算される`a + b`の型が`uint8`だからです。結果を`uint256`へ変換する前に、加算の範囲超過が起きます。 対して`widenBeforeAdd(200, 100)`は300を返します。両方の入力を大きい型へ変えてから計算しているためです。 ```text uint256(a + b) → 小さい型で足す。その後で変換 uint256(a) + uint256(b) → 先に変換する。大きい型で足す ``` この例で分かるのは、計算結果の変数型だけでは演算途中の型を決められない、ということです。式の内側から、どの型で計算されるかを確認します。 ## 定数が拒否されたから、変数も拒否されるとは限らない `uint8(256)`という範囲外の数値リテラルは、Solidity 0.8.36ではコンパイル時に拒否されます。また、`uint256`から`uint8`へ暗黙に代入するコードも拒否されます。 一方、引数として受け取った`uint256 value`を`uint8(value)`と明示的に変換するコードは、有効です。256を渡すと下位8ビットだけが残ります。 エディターで定数の例がエラーになったことを、実行時の入力検査の代わりにしないでください。**リテラルの適合性、暗黙の変換、明示的な変換、演算中の検査**を分けてテストする必要があります。 ## 整数とbytesでは、残る側が違う `integerAndBytes(0x1234)`は、整数側が`0x34`、バイト列側が`0x12`になります。 整数の縮小変換は下位ビットを残しますが、固定長バイト列の縮小変換は先頭側を残すためです。どちらも短い型へ変えているからといって、同じ切り取り操作ではありません。 `reinterpretSign(-1)`も注意例です。同じ8ビットを符号なしとして扱うと255になります。負数をゼロに補正する処理ではないので、非負の値だけを許す用途では、符号付きの元の値を先に検査します。 ## 再現するときは境界と失敗の種類を見る Foundryでは、上のコントラクトを作成し、返り値を`assert`で確認できます。失敗が必要な例は、単に失敗したことだけでなく、期待したエラーかを確認します。 ```solidity // SPDX-License-Identifier: MIT pragma solidity 0.8.36; import {Narrowing} from "../src/Narrowing.sol"; contract NarrowingSmokeTest { function testBoundary() public { Narrowing example = new Narrowing(); assert(example.narrow(255) == 255); assert(example.narrow(256) == 0); assert(example.widenBeforeAdd(200, 100) == 300); try example.addSmall(255, 1) returns (uint8) { revert("expected arithmetic panic"); } catch Panic(uint256 code) { assert(code == 0x11); } } } ``` Foundryを導入したうえで、空の作業フォルダーに`src`と`test`という名前のフォルダーを作ります。`Narrowing.sol`は`src`の中へ、上のテストは`test`の中に`Narrowing.t.sol`として保存します。作業フォルダーで`forge test --use 0.8.36 --evm-version prague --optimize --optimizer-runs 200`を実行してください。コンパイラーを初めて取得するとき以外、チェーンへの接続は不要です。 ## 確認した環境と範囲 | 項目 | 使用した条件 | | --- | --- | | 確認日 | 2026年9月5日 | | コンパイラー | Solidity 0.8.36、ビルド識別子`8a079791` | | テスト実行 | Foundry 1.8.0 | | EVM設定 | Prague | | 最適化 | 有効、200 runs | | OS | Ubuntu 24.04.4、x86_64 | 例のコントラクトはコンパイルし、隔離したEVM上で返り値と失敗条件を検証しています。公開チェーンへの接続、実ウォレットの操作、送信はしていません。表示されたガス値の優劣や実運用の安全性を比較する記事ではありません。 ## まとめ 整数型を小さくするなら、変換前の値で範囲を確認します。大きい型で計算したいなら、計算前に入力を変換します。 「Solidity 0.8だから」という一つの理由で、暗黙の変換、明示的な縮小変換、演算、固定長バイト列の切り取りを同じ扱いにしないことが、値を失わない実装への出発点です。失敗した呼び出しの`Panic`と独自エラーの違いは、[エラーデータの読み方](/archives/6002)で整理できます。 ## 確認した一次情報 - [Solidity: Explicit Conversions](): 確認日 2026-09-05 - [Solidity: Integers](): 確認日 2026-09-05 - [OpenZeppelin: SafeCast](): 確認日 2026-09-05 --- # Solidityのdeleteでmappingは消えない？配列再利用とキー削除を確認する 構造体や配列をdeleteしてもmappingの値が残る理由を、再割り当てとpopの例で解説します。既知キーの削除、世代による分離、初期値と未登録の違いを確認します。 正規URL: https://3mikan.com/archives/6080 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z Solidityで配列を`delete`し、長さが0になったことを確認した。それなのに、同じ位置へ要素を作り直すと以前の値が読める。この現象は、配列の要素に`mapping`が含まれると起こり得ます。 この記事は、登録情報、設定、期間ごとの記録を配列とマッピングで管理する開発者向けです。**配列からアクセスできないこと、現在の値を消すこと、過去の記録がなくなること**を分け、再利用してよい領域かを判断できるようにします。 整数だけの例を隔離したEVMで扱います。実在サービスへの操作、送金、秘密鍵、外部RPCは不要です。 ## deleteは、何でも完全消去する命令ではない [Solidityのdeleteの規則](https://docs.soliditylang.org/en/v0.8.36/types.html#delete)では、通常の整数は初期値の0へ戻ります。動的配列なら長さが0になり、配列の要素一つに対する`delete`は配列長を変えません。 ただし、`mapping`は書き込んだキーの一覧を内部に保持していません。そのため、構造体や配列を削除するときに、含まれるマッピングのすべてのキーをたどって消すことはできません。 「構造体を削除すれば、その内側まで無条件に空になる」と考えないようにします。[SolidityのClearing Mappings](https://docs.soliditylang.org/en/v0.8.36/security-considerations.html#clearing-mappings)でも、配列の削除や`pop`がマッピングの要素を消さない点が説明されています。 ## 整数のラベルと、キーごとの値を持つ例 次の`MappingDeletion`は、一つの行に整数の`label`と、キーごとの整数値を持たせています。誰でも呼べる学習用コードであり、実運用の権限管理やデータ管理を実装したものではありません。 後半の`GenerationLedger`は、消去する代わりに世代を分ける例です。まずは前半だけを見てください。 ```solidity // SPDX-License-Identifier: MIT pragma solidity 0.8.36; // Teaching example: no authorization or production lifecycle policy. contract MappingDeletion { struct Row { uint256 label; mapping(uint256 => uint256) values; } Row[] private rows; function allocate(uint256 label) external { rows.push(); rows[rows.length - 1].label = label; } function write(uint256 index, uint256 key, uint256 value) external { rows[index].values[key] = value; } function read(uint256 index, uint256 key) external view returns (uint256 label, uint256 value) { return (rows[index].label, rows[index].values[key]); } function deleteRow(uint256 index) external { delete rows[index]; } function clearArray() external { delete rows; } function popLast() external { rows.pop(); } function deleteKey(uint256 index, uint256 key) external { delete rows[index].values[key]; } function length() external view returns (uint256) { return rows.length; } } // Demonstrates logical separation, not physical erasure or access control. contract GenerationLedger { uint256 public generation; mapping(uint256 => mapping(uint256 => uint256)) private values; function write(uint256 key, uint256 value) external { values[generation][key] = value; } function current(uint256 key) external view returns (uint256) { return values[generation][key]; } function historical(uint256 oldGeneration, uint256 key) external view returns (uint256) { return values[oldGeneration][key]; } function nextGeneration() external { ++generation; } } ``` 新しいコントラクトで`allocate(1)`、`write(0, 7, 99)`を実行すると、0番目の行のキー7に99が入ります。`read(0, 7)`の返り値は`(1, 99)`です。 そこから、削除する対象ごとの違いを確認します。 ## 構造体をdeleteしても、キー7の99は残る `deleteRow(0)`を実行すると、整数の`label`は0へ戻ります。しかし、`read(0, 7)`は`(0, 99)`を返します。マッピングの値は変わっていません。 このとき配列長は1のままです。要素一つを初期化したのであって、後ろの行を前へ詰めたり、行番号を取り除いたりする操作ではありません。 ラベルが0だから未登録だと判断する設計では、マッピング側の値まで未登録とみなしてよいかを別に検討する必要があります。 ## 配列長0は、マッピング消去の証明にならない 次は、新しく用意した同じ初期状態から`clearArray()`を呼びます。配列長は0になるため、直後の`read(0, 7)`は添字の範囲外で失敗します。 しかし、続いて`allocate(2)`を呼ぶと、0番目の位置が再び使われます。そこで`read(0, 7)`を実行すると、返り値は`(2, 99)`です。キー7へ書き直していないのに、以前の99が読めます。 ```text allocate(1) → write(0, 7, 99) → clearArray() 配列長は0。0番目の読み取りは範囲外。 allocate(2) → read(0, 7) 結果は (2, 99)。新しいラベルと以前の値が並ぶ。 ``` 同じ初期状態から`popLast()`で末尾を除き、`allocate(3)`で作り直す場合も、結果は`(3, 99)`です。`pop`へ置き換えるだけでは、この例のマッピング値は消えません。 ## キーが分かっているなら、その値を削除する キー7を消したいなら、`deleteKey(0, 7)`で対象を指定できます。値型が整数なので、削除後の読み取りは0になります。 同時にキー8へ55を書いておけば、キー7の削除後もキー8は55のままです。特定のキーの削除と、マッピング全体の削除を区別できます。 ただし、マッピングの値がさらにマッピングを含む構造体なら、その内側にも同じ注意が必要です。また、整数の0は未登録の初期値でも、明示的に保存した値でもあり得ます。登録の有無が必要な設計なら、値だけでなく別の存在フラグなどを用意します。 キーを一覧として別管理し、順に消す方式も考えられますが、一度に処理する件数を無制限に増やさないでください。処理がガスの上限に収まらない可能性は、[ループに関する公式の注意](https://docs.soliditylang.org/en/v0.8.36/security-considerations.html#gas-limit-and-loops)で確認できます。 ## 世代を変える方法は、消去ではなく別の領域の参照 後半の`GenerationLedger`は、`values[generation][key]`という二段階のキーを使います。世代0でキー7へ99を保存してから世代1へ進むと、`current(7)`は0です。 ただし、`historical(0, 7)`は99を返します。古い値を消したのではなく、現在の読み取り先を変えただけだからです。世代1へ12を書いた後も、世代0の99は残ります。 この方法を使う場合は、読み取り・書き込み・権限判定のすべてで、どの世代を見るかを揃えます。世代を巻き戻したり、古い世代を再利用したりすれば、隔離したつもりの値へ再び到達します。 例の世代番号は通常の検査付き加算で増やしています。ここへ安易に`unchecked`を付けたり、誰でも世代を切り替えられる学習用の関数を実運用へそのまま持ち込んだりしないでください。 ## 検証は「消した直後」だけで終えない 削除を検証するときは、初期状態から書き込み、削除、その後の再割り当てまで確認します。今回の違いをまとめると、次のようになります。 | 操作 | 配列長 | キー7の99 | | --- | --- | --- | | `deleteRow(0)` | 1のまま | そのまま読める | | `clearArray()`直後 | 0 | 配列の添字が範囲外で読めない | | その後の`allocate(2)` | 1 | 再び読める | | `popLast()`後に`allocate(3)` | 1 | 再び読める | | `deleteKey(0, 7)` | 1のまま | 整数の初期値0へ戻る | Foundryでは`MappingDeletion`を作り直して各ケースを分離し、返り値と配列長、範囲外の`Panic(0x32)`を確かめます。コンパイラーをSolidity 0.8.36、EVM設定をPragueへ固定すれば、同じ条件で比較できます。 Foundryを導入したうえで、空の作業フォルダーに`src`と`test`という名前のフォルダーを作ります。先ほどの`MappingDeletion.sol`は`src`の中へ、次のコードは`test`の中に`MappingDeletion.t.sol`として保存してください。削除後の再利用と既知キーの削除を確認できます。 ```solidity // SPDX-License-Identifier: MIT pragma solidity 0.8.36; import {MappingDeletion} from "../src/MappingDeletion.sol"; contract MappingDeletionSmokeTest { function testReuseAfterDelete() public { MappingDeletion example = new MappingDeletion(); example.allocate(1); example.write(0, 7, 99); example.clearArray(); assert(example.length() == 0); example.allocate(2); (uint256 label, uint256 value) = example.read(0, 7); assert(label == 2 && value == 99); example.deleteKey(0, 7); (, value) = example.read(0, 7); assert(value == 0); } } ``` ```sh forge test --use 0.8.36 --evm-version prague --optimize --optimizer-runs 200 ``` 初回のツールやコンパイラー取得を除き、外部のチェーンへの接続は不要です。取得済みのコンパイラーを使うなら、`--use`へ実行ファイルのパスを渡して`--offline`を指定します。 ## 確認した環境と範囲 | 項目 | 使用した条件 | | --- | --- | | 確認日 | 2026年9月5日 | | コンパイラー | Solidity 0.8.36、ビルド識別子`8a079791` | | テスト実行 | Foundry 1.8.0 | | EVM設定 | Prague | | 最適化 | 有効、200 runs | | OS | Ubuntu 24.04.4、x86_64 | 例のコントラクトはコンパイルし、隔離したEVM上で返り値と失敗条件を検証しています。公開チェーンへの接続、実ウォレットの操作、送信はしていません。表示されたガス値の優劣や実運用の安全性を比較する記事ではありません。 ## まとめ 削除処理を読むときは、配列長、構造体の通常メンバー、マッピングの既知キー、再利用した領域を別々に確認します。長さが0になったことだけでは、内側の値の消去を確認できません。 既知キーの削除と、世代による論理的な分離も別の操作です。そして、現在の値を0へ戻す処理を、公開チェーンの過去の記録まで消す機能として説明しないでください。 より大きいコントラクトで操作順による問題を探す場合は、[状態保持型ファジングの比較](/archives/6053)で、単一の呼び出しでは見つからない状態変化をどのように検証するかを確認できます。 ## 確認した一次情報 - [Solidity: Clearing Mappings](): 確認日 2026-09-05 - [Solidity: delete](): 確認日 2026-09-05 - [Solidity: Gas Limit and Loops](): 確認日 2026-09-05 --- # Ethereumの時刻が1970年になるのはなぜ？timestampの秒・ミリ秒・日本時間を整理する EthereumのtimestampをJavaScriptのDateへ渡すと1970年になる原因を、小さな実行例で解説します。秒とミリ秒の変換、BigIntからの範囲検査、日本時間の表示、期限ちょうどの判定を分けて確認します。 正規URL: https://3mikan.com/archives/6081 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z ブロックの時刻を画面に出したら、2023年のはずが1970年になった。日本時間へ直そうと9時間を足したら、別の画面ではさらに9時間ずれた。こうした不具合では、時刻そのものよりも、**値の単位と表示方法を混ぜていないか**を先に確認します。 この記事は、Ethereumのブロック時刻や期限をJavaScriptで表示する開発者向けです。秒をミリ秒へ変える場所、`BigInt`から`Number`へ変換してよい条件、タイムゾーンの指定、期限ちょうどの判定を分けて整理します。 以下の日時と数値は説明用に固定した値です。実在する取引の実行時刻を測ったものではなく、コードの実行にウォレット、アカウント、外部RPCは必要ありません。 掲載例はNode.js 22以降を使い、この記事のJavaScriptを上から順に同じ`example.mjs`へ保存して、`node example.mjs`で実行できます。テキスト形式で示す出力や表は、ファイルへ含めません。 ## 同じ「時刻」でも数える単位が違う Ethereum JSON-RPCのブロックには`timestamp`があります。Solidityの`block.timestamp`も、Unix epochからの**秒数**を表します。一方、数値を一つ渡す`new Date(value)`が扱う単位は**ミリ秒**です。[^rpc] [^solidity] [^date] | 値 | 単位・役割 | 取り違えやすい点 | | --- | --- | --- | | ブロックの`timestamp` | 秒 | そのまま`Date`へ渡さない | | `Date.now()` | ミリ秒 | ブロック時刻ではなく、実行環境の現在時刻 | | `Date`の`getTime()` | ミリ秒 | 秒へ戻すなら端数の扱いを決める | | 日本時間で整形した文字列 | 表示 | 時刻の比較や保存の正本にしない | まず、変数名にも単位を入れます。`time`だけより、`blockTimestampSeconds`や`receivedAtMs`のほうが、値を受け渡すときに確認しやすくなります。 ## 1970年になる例を、接続せずに再現する 次の`1700000000`を、秒として解釈したい場面を考えます。 ```js const seconds = 1_700_000_000n; console.log(new Date(Number(seconds)).toISOString()); console.log(new Date(Number(seconds * 1000n)).toISOString()); ``` 実行結果は次のとおりです。 ```text 1970-01-20T16:13:20.000Z 2023-11-14T22:13:20.000Z ``` 最初の行は、17億「秒」を17億「ミリ秒」として読んでいます。2行目は、1秒が1000ミリ秒であることを反映した変換です。この例では、タイムゾーンを変えても最初の単位の間違いは直りません。 `0x6553f100`という形式で取得した数量を、検証後に`BigInt('0x6553f100')`へ変換しても値は`1700000000n`です。**16進数から整数に直すことと、秒からミリ秒に直すことは別の工程**として扱います。RPCの形式は取得元のメソッド定義で確認します。[^rpc] 16進表記そのものの検査は、[QUANTITYとDATAの区別](/archives/6071)で説明しています。 ## 範囲を確かめてからDateへ渡す 前の例は固定した小さな値でした。外部から受け取る値に使うなら、型と範囲を検査する関数へ分けます。 ```js function secondsToDate(seconds) { if (typeof seconds !== 'bigint') { throw new TypeError('seconds must be a bigint'); } if (seconds < 0n) { throw new RangeError('seconds must be non-negative'); } const milliseconds = seconds * 1000n; if (milliseconds > 8_640_000_000_000_000n) { throw new RangeError('timestamp exceeds the Date range'); } return new Date(Number(milliseconds)); } ``` ECMAScriptの`Date`が扱う範囲は、epochの前後それぞれ8.64×10の15乗ミリ秒までです。この関数はブロック時刻を読む目的で、非負の整数秒だけを受け付けます。負のUnix時刻が一般に不正という意味ではありません。[^date] `Number`への変換は、乗算と範囲検査の後に一度だけ行います。検査後の整数ミリ秒は`Number`の安全な整数範囲内に収まるため、この変換では整数の桁を失いません。任意の`uint256`を先に`Number`へ変えてよい、という一般化はできません。[^date] 確認すべき結果は次のようになります。 | 入力 | 結果 | | --- | --- | | `0n` | `1970-01-01T00:00:00.000Z` | | `1700000000n` | `2023-11-14T22:13:20.000Z` | | `-1n` | この関数の入力方針により`RangeError` | | `'1700000000'` | 文字列なので`TypeError` | | `null` | 未取得をゼロへ補完せず`TypeError` | | `8640000000001n` | `Date`の範囲を超えるため`RangeError` | ここで重要なのは、**範囲検査だけでは単位の正しさを証明できない**ことです。たとえば、すでにミリ秒になっている`1700000000000n`を秒として渡しても、非常に遠い未来の有効な日付になる場合があります。桁数で自動判定せず、APIとデータ形式の取り決めで単位を固定します。 ## 日本時間は9時間を足すのではなく、表示へ指定する UTCの日時と日本時間の日時は、同じ瞬間を別の表示で表したものです。保存したミリ秒へ9時間分を足すと、表示設定を変えるのではなく、別の瞬間へ移動してしまいます。 次のように、`Intl.DateTimeFormat`へ`timeZone`を指定します。省略した場合は実行環境のタイムゾーンが使われるため、サーバーと手元のPCで表示が違う原因になります。[^intl] ```js const instant = secondsToDate(1_700_000_000n); const tokyoFormatter = new Intl.DateTimeFormat('ja-JP', { timeZone: 'Asia/Tokyo', dateStyle: 'medium', timeStyle: 'medium', hourCycle: 'h23', }); console.log(instant.toISOString()); console.log(tokyoFormatter.format(instant)); ``` 今回確認した環境では、次の表示になりました。 ```text 2023-11-14T22:13:20.000Z 2023/11/15 7:13:20 ``` 同じ`instant`を使っています。日付が翌日に変わっても、元の時刻を足し引きしていません。表示の区切りや細部は国際化データに依存するため、機械が読み戻す保存形式には`getTime()`の値やUTCのISO文字列を使い、人向け表示と分けます。[^intl] 日時文字列を入力として受け取る場合も、オフセットを明示します。次の2つが同じ値になることを確認できます。 ```js console.log( Date.parse('2023-11-14T22:13:20Z') === Date.parse('2023-11-15T07:13:20+09:00') ); // true ``` ## 期限判定は表示文字列ではなく、同じ単位で比較する 「締切の時刻になったら無効」と「締切の時刻までは有効」は、等号の扱いが違います。文章だけで決めず、実装が`<`と`<=`のどちらを使っているかを確認します。 | 比較する秒 | `blockTime < deadline` | `blockTime <= deadline` | | --- | --- | --- | | 期限の1秒前 | 有効 | 有効 | | 期限と同じ | 無効 | 有効 | | 期限の1秒後 | 無効 | 無効 | これは比較演算の違いを示す表であり、特定のサービスの有効期限を保証するものではありません。`Date.now()`から作った画面上の残り時間だけで、将来のコントラクト実行を保証しないようにします。画面の時計と、処理が評価するブロック時刻は別の入力です。[^solidity] 手元のミリ秒を非負の整数秒へ変える場合は、たとえば次のように端数を落とします。 ```js function epochMsToSeconds(milliseconds) { if (typeof milliseconds !== 'number' || !Number.isSafeInteger(milliseconds) || milliseconds < 0 || milliseconds > 8_640_000_000_000_000) { throw new RangeError('milliseconds must be a non-negative Date-range integer'); } return BigInt(milliseconds) / 1000n; } console.log(epochMsToSeconds(1_700_000_000_123).toString()); // 1700000000 ``` この関数は、末尾の123ミリ秒を切り捨てます。四捨五入にすると、999ミリ秒の段階で次の秒へ進んでしまうため、同じ意味の変換にはなりません。 ## まとめ：単位・表示・判定を別々に直す 1970年が出たら、まず秒をミリ秒として読んでいないか確認します。日本時間への変換では保存値へ9時間を足さず、表示側のタイムゾーンを指定します。期限では両辺の単位と等号の扱いを揃えます。 保存する値に単位を明記し、未取得をゼロへ変えず、変換を一か所へまとめる。この設計なら、見た目だけを直して別の時刻を保存してしまう経路を減らせます。ブロックを選んだ条件や取引との対応を調べる場合は、[取引情報と実行結果を分けて確認する手順](/archives/6001)も参照してください。 ## 実行環境と出典 コードはNode.js v22.16.0、ICU 77.1で2026-09-06に確認しました。UTC、日本時間、米国東部時間を既定値とする3環境でも、明示したUTC・日本時間の出力が同じになることを確認しています。ネットワーク上の実時刻や取引は取得していません。 [^rpc]: [Ethereum JSON-RPC API：ブロックのtimestampと数量表現](https://ethereum.org/developers/docs/apis/json-rpc/)。確認日：2026-09-06。 [^solidity]: [Solidity：Block and Transaction Properties](https://docs.soliditylang.org/en/latest/units-and-global-variables.html#block-and-transaction-properties)。`block.timestamp`の単位を確認。確認日：2026-09-06。参照ページの開発版表示をコンパイラーの実行履歴とは扱っていません。 [^date]: [ECMAScript 2025：Date Objects、TimeClip、Numberの安全な整数範囲](https://tc39.es/ecma262/2025/multipage/numbers-and-dates.html#sec-date-objects)。確認日：2026-09-06。 [^intl]: [ECMAScript Internationalization API：Intl.DateTimeFormat](https://tc39.es/ecma402/2025/#sec-intl-datetimeformat-constructor)。確認日：2026-09-06。 ## 確認した一次情報 - [Ethereum JSON-RPC: block timestamp](): 確認日 2026-09-06 - [Solidity: block.timestamp in seconds](): 確認日 2026-09-06 - [ECMAScript 2025: Date and TimeClip](): 確認日 2026-09-06 - [ECMA-402: explicit timeZone](): 確認日 2026-09-06 --- # BigIntの配列をsortすると失敗する？数値順の比較と元配列を変えない並べ替え BigInt配列が文字列順になる原因と、a-bを比較関数に使うと例外になる理由を実行例で解説します。精度を落とさない比較、toSorted、欠損値、同順位の扱いまで確認します。 正規URL: https://3mikan.com/archives/6082 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z ブロック番号や大きな整数を`BigInt`の配列へ入れ、`sort()`したのに数値順にならない。いつもの`(a, b) => a - b`へ変えると、今度は`TypeError`になる。この問題では、保存している値の型と、比較関数が返す値の型を分けて考えます。 この記事では、普通のJavaScript配列を対象に、精度を落とさない比較と、元配列を変えない並べ替えを作ります。続いて、値の欠損と同順位の扱いを確認します。扱う番号やログはすべて説明用で、外部RPCやアカウントは使いません。 掲載例はNode.js 22以降を使い、この記事のJavaScriptを上から順に同じ`example.mjs`へ保存して、`node example.mjs`で実行できます。テキスト形式で示す出力や表は、ファイルへ含めません。 ## 引数なしのsortは、BigIntでも数値順ではない まず、次の3要素を並べます。 ```js console.log([3n, 20n, 100n].sort()); // [ 100n, 20n, 3n ] ``` 期待した数値順は`3, 20, 100`ですが、実行結果は逆です。通常の`Array`で比較関数を省略すると、値を文字列として比べるためです。今回の入力では`"100"`、`"20"`、`"3"`という順に並びます。[^sort] 元の要素が文字列へ書き換わるわけではありません。並べ終わっても要素は`BigInt`ですが、並べる基準が数値の大小になっていません。 なお、ここで説明しているのは普通の`Array`です。`BigInt64Array`などの型付き配列は別のメソッド定義を持つため、同じ省略時の規則だと広げないでください。[^sort] ## a-bは計算できても、その戻り値をsortが使えない 次の比較も、よくある修正です。 ```js try { [3n, 1n].sort((a, b) => a - b); } catch (error) { console.log(error.name); } // TypeError ``` `3n - 1n`という引き算自体は有効で、結果は`2n`です。しかし、配列の比較処理は比較関数の戻り値に数値変換を行い、`BigInt`の戻り値では例外になります。**比較対象がBigIntでも、比較結果までBigIntにする必要はありません。**[^compare] 並べ替えに必要なのは、差の正確な大きさではなく、「前へ」「同順位」「後ろへ」という3通りです。 | 比較関数が返す値 | 意味 | | --- | --- | | 負の`Number` | `a`を`b`より前へ | | `0` | この比較では同順位 | | 正の`Number` | `a`を`b`より後ろへ | そこで、次のように大小だけを返します。 ```js function compareBigInts(a, b) { if (typeof a !== 'bigint' || typeof b !== 'bigint') { throw new TypeError('both values must be bigint'); } return a < b ? -1 : a > b ? 1 : 0; } console.log([3n, 20n, 100n].sort(compareBigInts)); // [ 3n, 20n, 100n ] ``` 最後の`-1`、`1`、`0`には、`n`を付けません。元の大きな整数を保ったまま大小を調べ、比較結果だけを小さな`Number`として返しています。 `(a, b) => a > b`のように真偽値だけを返す方法も避けます。小さい場合に負の値を返さず、同順位との区別が付かないため、ここで必要な比較規則を満たしません。 ## Numberへ変えてから比べると、隣の整数が同じになる 例外を消すために、比較する二つの値をそれぞれ`Number`へ変えてはいけません。次の2つは異なる整数ですが、この変換では区別を失います。[^number] ```js const bigger = 9_007_199_254_740_993n; const smaller = 9_007_199_254_740_992n; console.log(Number(bigger) === Number(smaller)); // true console.log([bigger, smaller].sort((a, b) => Number(a) - Number(b))); // [ 9007199254740993n, 9007199254740992n ] console.log([bigger, smaller].sort(compareBigInts)); // [ 9007199254740992n, 9007199254740993n ] ``` 真ん中の式では比較結果が0となり、この入力順が残っています。例外が出ないことと、数値順が正しいことは別です。 ここで問題にしているのは`Number(a) - Number(b)`です。`Number(a - b)`は引き算の時点ではBigIntを保つため、同じ理由で壊れると説明してはいけません。ただし、大小だけで足りる処理なら、大きな差を作らない`compareBigInts`のほうが意図を直接表せます。 ## 元の配列を残すならtoSortedを使う `sort()`は元配列の順序を書き換えます。別の変数へ返り値を入れても、元配列を残すコピーにはなりません。一方、`toSorted()`は新しい配列を作ります。[^sort] [^copy] ```js const original = [3n, 1n, 2n]; const sorted = original.toSorted(compareBigInts); console.log(original); // [ 3n, 1n, 2n ] console.log(sorted); // [ 1n, 2n, 3n ] console.log(original === sorted); // false ``` `toSorted`を使わない環境では、今回のような要素が詰まった普通の配列なら、`[...original].sort(compareBigInts)`で先に配列を複製する方法もあります。 ただし、新しくなるのは配列の入れ物です。要素がオブジェクトなら、中身のオブジェクトを深く複製する操作ではありません。以下はその違いを確かめる例です。 ```js const records = [{ name: 'A', value: 2n }, { name: 'B', value: 1n }]; const ordered = records.toSorted( (a, b) => compareBigInts(a.value, b.value) ); ordered[0].name = 'changed'; console.log(records[1].name); // changed ``` 「並べ替えても元の順序は残る」と「結果の中身を編集しても元のデータは変わらない」を分けます。後者も必要なら、並べ替えとは別に、どこまで複製するかを決めます。 ## 入力検査を比較関数だけに任せない 比較関数に型検査を書けば、配列全体の検証になるとは限りません。空配列や要素が一つの配列では比較が発生しないことがあり、`undefined`には比較関数を呼ばない扱いもあります。[^compare] そのため、「すべての要素がBigIntである」という入力契約は、並べ替える前に検査します。 ```js function sortBigInts(values) { if (!Array.isArray(values)) { throw new TypeError('values must be an array'); } for (let index = 0; index < values.length; index += 1) { if (!Object.hasOwn(values, index) || typeof values[index] !== 'bigint') { throw new TypeError(`values[${index}] must be a bigint element`); } } return values.toSorted(compareBigInts); } ``` この関数は、空配列は認めますが、途中の要素がない配列、`null`、文字列、`Number`との混在は拒否します。これはこの記事で採用した入力方針であり、JavaScriptがそれらの並べ替えをすべて禁止しているという意味ではありません。 ```js console.log(sortBigInts([5n, -1n, 0n, 5n])); // [ -1n, 0n, 5n, 5n ] try { sortBigInts([1n, undefined]); } catch (error) { console.log(error.name); } // TypeError ``` `Object.hasOwn`の確認は、配列の長さだけ存在して実際の要素が抜けている箇所も拒否するためです。欠損を自動でゼロへ変えて並べると、「データがない」と「値が0」を見分けられなくなります。 ## 同順位をどう並べるかは、別の規則として決める 安定した並べ替えでは、比較結果が0になる要素同士は入力時の順序を保ちます。しかし、これは「正しい取引順へ復元される」という意味ではありません。入力の到着順が変われば、同順位の並びも変わります。[^sort] たとえば、同一チェーンの採用した履歴に属するログを扱うなら、ブロック番号だけでなく、ブロック内でのログ位置も比較できます。RPCには`blockNumber`と`logIndex`という項目があります。[^rpc] 次は、その2項目を検証・整数化済みとした合成例です。 ```js const logs = [ { id: 'C', blockNumber: 11n, logIndex: 0n }, { id: 'B', blockNumber: 10n, logIndex: 2n }, { id: 'A', blockNumber: 10n, logIndex: 0n }, ]; const orderedLogs = logs.toSorted((a, b) => compareBigInts(a.blockNumber, b.blockNumber) || compareBigInts(a.logIndex, b.logIndex) ); console.log(orderedLogs.map(log => log.id)); // [ 'A', 'B', 'C' ] ``` 最初の比較が0のときだけ、2番目の比較へ進みます。ブロック番号とログ位置が両方とも同じなら、このコードでは入力順を維持します。 異なるチェーンや、同じ高さの別ブロックを混ぜてよいという意味ではありません。ブロックハッシュや削除されたログの扱いは、並べ替えより前に決める必要があります。順序を整える関数だけで、採用すべき履歴の正しさまでは判定しません。 ## まとめ：元の整数は保ち、比較結果だけ小さく返す BigInt配列を数値順へ並べるなら、大小を`BigInt`のまま比較し、`-1`・`0`・`1`を`Number`として返します。元配列を残す場合は`toSorted`を使い、要素の型と欠損は比較関数の外で検査します。 最後に、同順位の扱いを決めます。計算の精度、配列の変更、同順位の基準は別の論点です。ログ自体の項目や意味を確認するときは、[ABIとイベントログの読み方](/archives/6005)を参照してください。 ## 実行環境と出典 コードはNode.js v22.16.0で2026-09-06に確認しました。小さな整数、負数、重複、`Number`の安全な整数範囲を超える隣接値、欠損、元配列の保持を確認しています。RPCから取得した実ログの並べ替えや速度比較は行っていません。 [^sort]: [ECMAScript 2025：Array.prototype.sortとSortIndexedProperties](https://tc39.es/ecma262/2025/multipage/indexed-collections.html#sec-array.prototype.sort)。通常配列、安定性、比較規則を確認。確認日：2026-09-06。 [^compare]: [ECMAScript 2025：CompareArrayElements](https://tc39.es/ecma262/2025/multipage/indexed-collections.html#sec-comparearrayelements)。比較結果の数値変換と`undefined`の扱い。確認日：2026-09-06。 [^copy]: [ECMAScript 2025：Array.prototype.toSorted](https://tc39.es/ecma262/2025/multipage/indexed-collections.html#sec-array.prototype.tosorted)。確認日：2026-09-06。 [^number]: [ECMAScript 2025：Number.MAX_SAFE_INTEGER](https://tc39.es/ecma262/2025/multipage/numbers-and-dates.html#sec-number.max_safe_integer)。確認日：2026-09-06。 [^rpc]: [Ethereum JSON-RPC API：eth_getLogs](https://ethereum.org/developers/docs/apis/json-rpc/#eth_getlogs)。確認日：2026-09-06。 ## 確認した一次情報 - [ECMAScript 2025: Array.prototype.sort](): 確認日 2026-09-06 - [ECMAScript 2025: CompareArrayElements](): 確認日 2026-09-06 - [ECMAScript 2025: Array.prototype.toSorted](): 確認日 2026-09-06 - [ECMAScript 2025: Number.MAX\_SAFE\_INTEGER](): 確認日 2026-09-06 - [Ethereum JSON-RPC: log blockNumber and logIndex](): 確認日 2026-09-06 --- # Promise.allが失敗しても処理は止まらない：部分成功・中断・同時実行数を分ける Promise.allの例外を捕まえた後も処理が続く理由を、手元で動く例から確認します。allSettledによる部分成功、AbortControllerによる中断、開始数を制限する実装を分けて解説します。 正規URL: https://3mikan.com/archives/6083 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z 複数のデータを同時に取得し、`Promise.all()`の失敗を`catch`で受け取った。それなのに、別の処理から結果が届き続ける。これは「全体が失敗した」という通知と、「開始済みの処理を止める」という操作を混同すると起きます。 この記事は、RPCやAPIの読み取りをまとめるJavaScriptを書いている人向けです。**結果をまとめること、部分成功を残すこと、処理を中断すること、同時に開始する数を抑えること**を分けます。 例はNode.js v22.16.0で確認しました。通信の代わりに手動で完了させるPromiseとタイマーを使うので、アカウント、APIキー、外部RPCは不要です。各例を`.mjs`ファイルへ保存し、`node ファイル名.mjs`で実行できます。 ## 失敗を受け取った後にも、別の処理は完了する `Promise.all()`が返すのは、渡された複数の結果を一つにまとめたPromiseです。すべて成功すれば結果の配列を返し、一つが失敗すれば、その拒否理由で全体も失敗します。他の処理へ自動的に中断を通知する機能ではありません。[1] 次の例では、処理Bを手動で完了させます。タイマーの速さに依存せず、「全体の失敗を受け取った後にBが続く」ことを確かめるためです。 ```js const events = []; const gate = Promise.withResolvers(); const taskA = Promise.reject(new Error('A failed')); const taskB = gate.promise.then(() => { events.push('B finished'); return 'B'; }); try { await Promise.all([taskA, taskB]); } catch { events.push('all failed'); } console.log(events.join(' -> ')); gate.resolve(); await taskB; console.log(events.join(' -> ')); ``` 実行結果は次のとおりです。 ```text all failed all failed -> B finished ``` `Promise.withResolvers()`は、Promiseと、その完了・失敗を外から通知する関数をまとめて作ります。この例では、Bを終わらせる合図だけに使っています。[1] つまり、`catch`へ進んだ時点で「Bはもう動かない」と考えることはできません。実際の取得処理なら、後から届いた結果を古い画面へ反映しないか、別の処理と同じ記録を書き換えないかも考える必要があります。 ## 部分成功を残すなら、失敗をゼロへ置き換えない 独立した読み取り結果を一覧に出す場合、どれか一つが失敗したからといって、ほかの成功結果まで捨てる必要はないかもしれません。その判断には、すべての成功・失敗を集める`Promise.allSettled()`を使えます。[1] この関数が返す配列は、完了した順ではなく、入力した順に対応します。次の例では、2番目を先に完了させても、結果は1番目、2番目の順です。 ```js const first = Promise.withResolvers(); const second = Promise.withResolvers(); const pending = Promise.allSettled([first.promise, second.promise]); second.resolve(0n); first.reject(new Error('read unavailable')); const results = await pending; console.log(results.map((result) => result.status === 'fulfilled' ? `ok:${result.value.toString()}` : 'unavailable' ).join(', ')); // unavailable, ok:0 ``` ここでは「取得できなかった」と「正常に0を取得した」を残しています。失敗を一律に`0n`へ置き換えると、その区別がなくなります。 たとえば残高を表示する設計なら、0は取得結果の一つであって、通信に失敗した印ではありません。表示する項目名と入力順の対応も保存し、結果の配列だけを別の順番で並べ替えないようにします。 ただし、`allSettled()`は全件が決着するまで待ちます。終わらない処理が一つあれば、集約も終わりません。タイムアウトや中断への対応は、別に設計します。[1] ## 本当に止めるには、処理側も中断に対応する `AbortController`は、中断の合図を送るための仕組みです。合図を受け取る`signal`を、対応するAPIへ渡しておきます。任意のPromiseへ後から強制停止をかける機能ではありません。[3] Node.jsのPromise版タイマーは、この合図に対応しています。次の例では、Aが失敗したら60秒のタイマーBを中断し、両方の最終状態まで確認します。[2] ```js import { setTimeout as delay } from 'node:timers/promises'; const controller = new AbortController(); const jobs = [ Promise.reject(new Error('A failed')), delay(60_000, 'B', { signal: controller.signal }), ]; try { await Promise.all(jobs); } catch (error) { controller.abort(error); const settled = await Promise.allSettled(jobs); console.log(settled.map((result) => result.status === 'rejected' ? result.reason.name : result.value ).join(', ')); } // Error, AbortError ``` この例で確認しているのは、Aの失敗とBのタイマー中断です。60秒待ってから失敗する例ではありません。また、タイマーに渡した`signal`を省略すれば、同じ`abort()`を呼んでも、そのタイマーを中断できません。 `allSettled()`を最後に置くのは、中断を通知した直後に、すべての後始末が完了したと決めつけないためです。ただし、合図を無視する処理まで混ぜれば、そこを待ち続ける可能性は残ります。 外部サービスへ送った要求については、手元で待つのをやめても、相手側の処理や書き込みまで取り消されたとは限りません。**中断は、完了済みの変更を巻き戻す操作とは別**と考えます。 中断済みの`signal`は元へ戻せません。次の独立した処理を始めるときは、新しい`AbortController`を作ります。[3] ## 同時実行数は、Promiseを作り終わる前に制限する `Promise.all(items.map(readItem))`という形では、通常の配列の`map()`が`readItem`を各要素について呼び出します。その関数内で取得を開始するなら、`Promise.all()`へ配列を渡す時点で、すでに開始しています。[4] 開始済みのPromiseを後から2件ずつ待っても、同時に開始した数は減りません。上限を決めたいなら、**入力と、これから呼ぶ関数を渡す**形にします。 以下は、指定した数だけ処理を動かし、成功・失敗を入力順で返す小さな実装です。1件失敗しても残りを続ける方針で、先ほどの「失敗したら全体を中断する」例とは目的が違います。 ```js async function mapSettledWithLimit(items, limit, worker) { if (!Array.isArray(items)) throw new TypeError('items must be an array'); if (!Number.isSafeInteger(limit) || limit < 1) { throw new RangeError('limit must be a positive safe integer'); } if (typeof worker !== 'function') throw new TypeError('worker required'); for (let i = 0; i < items.length; i += 1) { if (!Object.hasOwn(items, i)) throw new TypeError('sparse array rejected'); } const input = items.slice(); const results = new Array(input.length); let cursor = 0; async function run() { while (cursor < input.length) { const index = cursor++; try { results[index] = { status: 'fulfilled', value: await worker(input[index], index), }; } catch (reason) { results[index] = { status: 'rejected', reason }; } } } await Promise.all(Array.from( { length: Math.min(limit, input.length) }, () => run(), )); return results; } ``` 通常の密な配列を入力とし、上限0、小数の上限、途中に要素がない配列は拒否しています。入力配列の並びは浅くコピーしますが、要素がオブジェクトなら、そのオブジェクトの内容まで複製するわけではありません。 各処理が`await`で待機する前に、担当する位置を一つ確保します。単一のJavaScript実行環境内での制御であり、複数プロセス間の実行数をまとめて制御するものではありません。 上の関数に続けて、次のコードを置きます。通信の代わりに短いタイマーを待ち、一つだけ意図的に失敗させます。 ```js import { setTimeout as delay } from 'node:timers/promises'; let active = 0; let maximum = 0; const results = await mapSettledWithLimit([10, 20, 30, 40], 2, async (value) => { active += 1; maximum = Math.max(maximum, active); try { await delay(5); if (value === 20) throw new Error('sample failure'); return value * 2; } finally { active -= 1; } }); console.log(maximum); console.log(results.map((result) => result.status === 'fulfilled' ? result.value : 'failed' ).join(', ')); // 2 // 20, failed, 60, 80 ``` この例では、同時に実行中の数の最大値が2になり、失敗した要素の後も処理が続きました。数値2は説明用の設定であり、特定のRPCサービスに適した上限や、リクエスト制限を保証する値ではありません。 この関数には、毎秒の要求数制限、再試行、外部からの中断は組み込んでいません。処理がすぐ完了すれば、同時実行数が2でも短時間に多数を開始できます。「同時に2件」と「毎秒2件」は違う条件です。 ## タイムアウトと、要求の再送も別に考える `Promise.race()`で本処理とタイマーを競わせても、勝たなかった側の処理が自動で止まるわけではありません。必要なら、合図に対応する処理へ中断を伝え、不要になったタイマーも片付けます。[1][2] 読み取りの再試行を設計するときも、入力、対象ブロック、試行回数を管理します。現在の値を毎回取り直すなら、同じ入力でも結果が変わる可能性があるためです。固定ブロックでの読み取りは、[RPCのブロック指定を整理した記事](/archives/6024)を参照してください。 送信や書き込みでは、応答が得られなかったことだけを理由に再送しない設計が必要です。待機の失敗と、相手が要求を受理していないことは同じではありません。この記事の中断例を、送信済み取引の取り消しへ流用しないでください。 ## まとめ：四つの判断を一つにしない | 決めたいこと | この記事で使ったもの | それだけでは決まらないこと | | --- | --- | --- | | 全件成功したか | `Promise.all()` | 開始済み処理の中断 | | どれが成功し、どれが失敗したか | `Promise.allSettled()` | 終わらない処理の終了 | | 対応する処理へ中断を伝える | `AbortController` | 完了済み変更の巻き戻し | | 同時に開始・実行する数を抑える | 開始前に呼び出しを制御する関数 | 毎秒の制限、再試行方針 | 最初に決めるのは「全体の成功が必要か、それとも部分成功を残すか」です。そのうえで、中断に対応する処理か、開始数を制限する必要があるかを別々に確認します。 ### 一次情報 確認日：2026年9月6日。表示している版と、手元で実行したNode.jsの版は区別しています。 [1] [ECMAScript 2025 — Promise.all / allSettled / race / withResolvers](https://tc39.es/ecma262/2025/multipage/control-abstraction-objects.html#sec-promise.all) [2] [Node.js — Cancelling timers / Timers Promises API](https://nodejs.org/api/timers.html#cancelling-timers) [3] [Node.js 22.16.0 — AbortController / AbortSignal](https://nodejs.org/download/release/v22.16.0/docs/api/globals.html#class-abortcontroller) [4] [ECMAScript 2025 — Array.prototype.map](https://tc39.es/ecma262/2025/multipage/indexed-collections.html#sec-array.prototype.map) ## 確認した一次情報 - [ECMAScript 2025: Promise.all / allSettled / race](): 確認日 2026-09-06 - [Node.js: Cancelling timers](): 確認日 2026-09-06 - [Node.js 22.16.0: AbortController](): 確認日 2026-09-06 - [ECMAScript 2025: Array.prototype.map](): 確認日 2026-09-06 --- # JSON.stringifyで値が消えるのはなぜ？undefined・NaN・Mapと保存形式の決め方 JSONへ保存したらプロパティが消えた、Mapが空になった、Dateが文字列になった。JavaScriptの値とJSONの違いを実行例で確認し、未取得・ゼロ・大きな整数を区別する保存形式を考えます。 正規URL: https://3mikan.com/archives/6084 著者: みかん 公開: 2026-09-06T00:00:00.000Z 更新: 2026-09-06T00:00:00.000Z 取得結果を`JSON.stringify()`で保存し、読み戻したら項目が消えていた。エラーは出ていないのに、`Map`が空のオブジェクトになり、日付の型も変わっている。こうした変化は、保存処理の不具合とは限らず、JSONへ変換する規則によって起きます。 この記事は、RPCの取得結果やアプリの状態をJavaScriptから保存する人向けです。**文字列化に成功したことと、必要な情報を復元できることは別**として、保存前後の値を確認します。 コードはNode.js v22.16.0で確認しました。使うのは手元の合成データだけで、外部サービスやアカウントは不要です。変換規則を変更する`replacer`や独自の`toJSON`がない状態を基本にします。 各節のJavaScriptを別の`example.mjs`へ保存し、`node example.mjs`で実行できます。「上の関数へ続ける」とした箇所は、関数定義と呼び出しを同じファイルへ置きます。 ## エラーが出なくても、保存前と同じ内容にはならない まず、未取得の数量、不正な計算結果、ラベルの対応表、確認時刻を一つのオブジェクトへ入れます。 ```js const observation = { amount: undefined, ratio: NaN, labels: new Map([['network', 'sample']]), checkedAt: new Date('2026-01-01T00:00:00.000Z'), }; const text = JSON.stringify(observation); console.log(text); const restored = JSON.parse(text); console.log(Object.hasOwn(restored, 'amount')); console.log(restored.checkedAt instanceof Date); ``` 結果は次のとおりです。 ```text {"ratio":null,"labels":{},"checkedAt":"2026-01-01T00:00:00.000Z"} false false ``` `amount`は省かれ、`NaN`は`null`へ変わりました。`labels`の対応関係も残らず、日付は文字列として戻ってきます。[1][2] ここで必要なのは、すべてを強引に元の型へ戻すことではありません。後で「未取得だった」「計算結果が有効でなかった」「どのラベルが付いていた」を判断したいなら、その情報を保存形式に含めることです。 ## undefinedは、置く場所によって扱いが違う `undefined`は、オブジェクトのプロパティでは省略され、配列の要素では`null`になります。最上位でそのまま渡したときは、JSON文字列ではなくJavaScriptの`undefined`が返ります。[1] ```js console.log(JSON.stringify({ value: undefined })); console.log(JSON.stringify([undefined])); console.log(JSON.stringify(undefined) === undefined); // {} // [null] // true ``` つまり、`JSON.stringify()`の戻り値が常に文字列であるとは限りません。戻り値をそのまま別の保存APIへ渡すコードでは、この点も確認します。 通常の変換で、間違えやすい値を表へまとめます。独自の変換関数やプロトタイプの変更によって挙動を変えていない場合の整理です。[1] | JavaScript側の値 | オブジェクトの値として保存 | 配列の要素として保存 | | --- | --- | --- | | `undefined` | そのプロパティを省略 | `null` | | 関数・Symbolの値 | そのプロパティを省略 | `null` | | `NaN`・`Infinity`・`-Infinity` | `null` | `null` | | `null` | `null` | `null` | | `0`・`false`・空文字列 | その値を残す | その値を残す | | `BigInt` | `TypeError` | `TypeError` | 同じ`null`になっても、変換前の意味は同じとは限りません。変換後のJSONだけを見て、元が`NaN`だったのか、最初から`null`だったのかを判別することはできません。 ## Mapは空かどうかではなく、保存されるプロパティを見る 追加のプロパティを持たない通常の`Map`は、値が入っていても`{}`へ変換されます。JSONへの標準変換が見るのは、列挙可能な自身の文字列キープロパティであり、`Map`の内部の対応表ではないためです。[1][3] 文字列キーのラベル表なら、キーと値の組を配列へ取り出す方法があります。 ```js const labels = new Map([['network', 'sample'], ['mode', 'offline']]); const text = JSON.stringify({ labels: [...labels] }); const restored = new Map(JSON.parse(text).labels); console.log(text); console.log(restored.get('network')); // {"labels":[["network","sample"],["mode","offline"]]} // sample ``` この例は、自分で作った「文字列キーと文字列値の組」を読み戻しています。外部から受け取るJSONへそのまま適用するなら、配列の形、各組の長さ、キーと値の型、重複キーの方針を先に検査します。 また、オブジェクトをキーにする`Map`では、文字列化だけで元のオブジェクトの同一性を保存できません。ラベルのようなデータへ変換する例と、任意の`Map`を完全復元する仕組みは区別してください。 ## Dateは文字列になり、BigIntはそのままでは例外になる 有効な`Date`は、通常、`toJSON()`によってUTCの日時文字列へ変わります。`JSON.parse()`は、その文字列を自動で`Date`に戻しません。不正な日時を持つ`Date`では、`toJSON()`は`null`を返します。[2] 一方、通常の`BigInt`はそのままではJSONへ変換できません。保存側で10進文字列と決め、読み取り側もその決め方へ合わせます。[1] ```js try { JSON.stringify({ blockNumber: 9_007_199_254_740_993n }); } catch (error) { console.log(error.name); } const saved = JSON.stringify({ blockNumber: '9007199254740993', checkedAt: '2026-01-01T00:00:00.000Z', }); const record = JSON.parse(saved); console.log(typeof record.blockNumber, typeof record.checkedAt); // TypeError // string string ``` 数字に見える文字列をすべて整数へ戻すと、識別子や先頭ゼロを持つコードまで変えてしまいます。日付に見える文字列も同様です。**フィールドの名前と保存形式を決め、必要な場所だけ検証して変換する**方針にします。 `replacer`を使えば万能、というわけでもありません。標準の処理では、`toJSON()`が先に呼ばれ、その結果が`replacer`へ渡ります。`value instanceof Date`だけで元の日付を検出しようとすると、すでに文字列になっている場合があります。[1][2] ```js let observedType; JSON.stringify( { checkedAt: new Date('2026-01-01T00:00:00.000Z') }, (key, value) => { if (key === 'checkedAt') observedType = typeof value; return value; }, ); console.log(observedType); // string ``` ## 未取得とゼロを、保存形式で明確に分ける ここでは、小さなカウンターの読み取り結果を保存する形式を決めます。実際の残高取得やブロック取得ではなく、状態の保存方法を説明するための例です。 ```json {"schemaVersion":1,"state":"ok","value":"0"} ``` ```json {"schemaVersion":1,"state":"unavailable"} ``` 成功なら`value`を非負整数の10進文字列で持ち、未取得なら値を持たせません。形式の版を表す`schemaVersion`も入れます。これはこの記事の設計例であり、JSONやEthereumの標準形式ではありません。 読み戻しでは、版、状態、値、余分なフィールドを検査します。次の関数は、この二つの形だけを受け入れます。 ```js function readCounterSnapshot(text) { if (typeof text !== 'string' || text.length > 4096) { throw new TypeError('snapshot must be a short JSON string'); } const record = JSON.parse(text); if (record === null || typeof record !== 'object' || Array.isArray(record)) { throw new TypeError('snapshot must be an object'); } if (record.schemaVersion !== 1) throw new TypeError('unsupported version'); const keys = Object.keys(record).sort().join(','); if (record.state === 'unavailable' && keys === 'schemaVersion,state') { return { state: 'unavailable' }; } if (record.state !== 'ok' || keys !== 'schemaVersion,state,value') { throw new TypeError('invalid snapshot fields'); } if (typeof record.value !== 'string' || record.value.length > 78) { throw new TypeError('value must be a bounded decimal string'); } const match = /^(0|[1-9][0-9]*)$/.exec(record.value); if (!match || match[0] !== record.value) throw new TypeError('invalid integer'); const value = BigInt(record.value); if (value > (1n << 256n) - 1n) throw new RangeError('value exceeds sample limit'); return { state: 'ok', value }; } ``` 入力文字列の`length`を4096以下とする条件、最大78桁、256ビットの上限は、このサンプルの入力方針です。`length`はUTF-16のコード単位で数えます。HTTP本文のバイト数制限や、保存先での容量制限を代わりに実施するものではありません。 末尾の改行、符号、指数表記、余分な先頭ゼロも許容していません。この正規表現は`m`フラグを使わず、入力全体を対象にしています。JavaScriptの`$`が行末にも一致するのは`m`を指定した場合なので、他言語の正規表現と混同しないでください。[6] 一致部分と入力全体の比較も残しています。将来フラグやパターンを変更した場合でも、文字列の一部分だけが一致した入力を受け入れない意図です。 上の関数へ、次を続けます。 ```js const zero = readCounterSnapshot('{"schemaVersion":1,"state":"ok","value":"0"}'); const missing = readCounterSnapshot('{"schemaVersion":1,"state":"unavailable"}'); console.log(zero.state, zero.value === 0n); console.log(missing.state, Object.hasOwn(missing, 'value')); // ok true // unavailable false ``` 成功の0と未取得は、読み戻した後も異なる状態として残ります。`ok`なのに値がない入力や、未取得なのに値が付いた入力は拒否します。 ただし、`JSON.parse()`後の検証には限界があります。同じキーがJSON本文に重複していれば、通常の解析後には最後の値が残り、ここでは重複自体を検出しません。重複キーを禁止する契約が必要な場合は、それを検出できる解析方法も必要です。[1] また、`schemaVersion: 1`と書かれているだけで内容の正しさが保証されるわけではありません。版は「どの規則で読むか」を選ぶ入口で、各フィールドの検査を省略する印ではありません。 ## メモリー内のコピーなら、JSONを経由しない選択肢もある 別の変数として編集したいだけなら、文字列として保存する必要はないかもしれません。`structuredClone()`は、対応する型について構造化複製を行います。次の例では`BigInt`、`Map`、`Date`、自身への参照を含めて複製します。[4][5] ```js const original = { count: 1n, labels: new Map([['mode', 'offline']]), checkedAt: new Date('2026-01-01T00:00:00.000Z'), }; original.self = original; const copy = structuredClone(original); copy.labels.set('mode', 'edited'); console.log(copy.count === 1n, copy.checkedAt instanceof Date, copy.self === copy); console.log(original.labels.get('mode')); // true true true // offline ``` これでJSON文字列を作ったことにはなりません。複製できた値を改めて`JSON.stringify()`すれば、BigIntなどの変換問題は残ります。 `structuredClone()`も、すべての値を複製する仕組みではありません。たとえば関数を含めると`DataCloneError`になります。対応する型、転送の指定、独自クラスの扱いなどは、用途に応じて確認します。[4] ## まとめ：保存後に必要な判断から逆算する 保存の前に、「後で何を区別したいか」を決めます。未取得とゼロ、日時の文字列と日時オブジェクト、対応表と普通のオブジェクトは、それぞれ別の意味です。 JSONへ変換するなら、フィールドの型、欠損の表現、大きな整数の表記、形式の版を決め、読み戻しも一緒に検証します。単なるメモリー内の複製なら、文字列化とは別の仕組みを選びます。 **例外が出ないことだけでなく、保存前後で必要な情報が残ること**を確認してください。 トークン数量の入力・計算・保存を一緒に設計する場合は、[BigIntとdecimalsを使う数量計算](/archives/6070)へ進めます。日時の単位やタイムゾーンを取り違えている場合は、[秒・ミリ秒・日本時間の区別](/archives/6081)も確認してください。 ### 一次情報 確認日：2026年9月6日。実行環境はNode.js v22.16.0です。 [1] [ECMAScript 2025 — JSON.parse / JSON.stringifyと内部の変換規則](https://tc39.es/ecma262/2025/multipage/structured-data.html#sec-json.stringify) [2] [ECMAScript 2025 — Date.prototype.toJSON](https://tc39.es/ecma262/2025/multipage/numbers-and-dates.html#sec-date.prototype.tojson) [3] [ECMAScript 2025 — Map Objects](https://tc39.es/ecma262/2025/multipage/keyed-collections.html#sec-map-objects) [4] [WHATWG HTML — Structured cloning](https://html.spec.whatwg.org/multipage/structured-data.html#structured-cloning) [5] [Node.js 22.16.0 — structuredClone](https://nodejs.org/download/release/v22.16.0/docs/api/globals.html#structuredclonevalue-options) [6] [ECMAScript 2025 — Assertions](https://tc39.es/ecma262/2025/multipage/text-processing.html#sec-assertion) ## 確認した一次情報 - [ECMAScript 2025: JSON serialization](): 確認日 2026-09-06 - [ECMAScript 2025: Date.prototype.toJSON](): 確認日 2026-09-06 - [WHATWG HTML: Structured cloning](): 確認日 2026-09-06 - [Node.js 22.16.0: structuredClone](): 確認日 2026-09-06 - [ECMAScript 2025: Map](): 確認日 2026-09-06 - [ECMAScript 2025: regular expression assertions](): 確認日 2026-09-06 --- # viemで失敗トランザクションを調べる｜取引結果・入力データ・エラーの確認順 失敗したトランザクションを、取引結果、入力データ、シミュレーション、ノンスの順に調べる方法を、viemのコードと具体例で解説します。 正規URL: https://3mikan.com/archives/6001 著者: みかん 公開: 2026-08-27T12:30:00.000Z 更新: 2026-09-05T14:10:34.553Z 送金やコントラクト操作が失敗したとき、最初から難しいエラー名だけを探すと、かえって原因を見失いやすくなります。 まずは、**取引がブロックに入ったか、何を実行しようとしたか、同じ条件で試すと何が起きるか**を順番に確認します。 イメージは荷物の追跡です。伝票番号から「受付済みか」「届け先と内容は正しいか」「途中で止まった理由は何か」「同じ受付番号の別便がないか」を確認するのと似ています。 この記事では、**実行結果 → 入力データ → シミュレーション → ノンス**の順で調べます。秘密鍵をコードへ貼り付ける必要はありません。viemの読み取り専用クライアント（Public Client）とトランザクションハッシュがあれば進められます。 ## 先に用語を普通の言葉で確認する | 用語 | 普通の言葉でいうと | 主に分かること | | --- | --- | --- | | 取引情報（`transaction`） | 何を実行しようとしたかを書いた注文票 | 送信元、送信先、入力内容、ノンス、手数料条件 | | 実行結果（トランザクションの実行結果） | ブロックチェーンが返す受領票 | 確定したブロック、成功・失敗、使用したガス、発生したログ | | 入力データ（呼び出しデータ） | コントラクトへ渡した指示書 | 呼び出した関数と引数 | | シミュレーション | 実際には送信せず、同じ条件で行う試運転 | 権限不足、残高不足、期限切れなどのエラー | | ノンス（`nonce`） | 同じアカウントから送る取引の整理番号 | 保留中、置換済み、別ハッシュの可能性 | 英語の名前は、コードやブロックエクスプローラーの表示と照合するために残しています。最初は「注文票・受領票・指示書・試運転・整理番号」と考えれば十分です。 ![取引の解析を実行結果、入力データ、シミュレーション、ノンスの順に進める流れ](/diagrams/evm-debugging/6001-receipt-analysis.svg) ## まず確認する4項目 | 項目 | 確認できること | 次に判断すること | | --- | --- | --- | | 取引情報 | `from`、`to`、`input`、`nonce`、手数料条件 | 呼び出した関数と送信条件が正しいか | | 実行結果 | ブロック、`status`、`gasUsed`、ログ | 確定済みか、実行途中で取り消されたか | | シミュレーション | 現在または指定ブロックでの試運転結果 | 権限、残高、利用許可額、期限などに問題がないか | | ノンス | `latest`と`pending`の取引数 | 未確定、置換、別ハッシュの可能性があるか | 実行結果が取得できない場合、すぐに「失敗した」とは断定できません。まだ未確定、参照しているチェーンが違う、ノードがそのハッシュを知らない、同じノンスの別取引へ置き換わった、という可能性も残ります。 ### 具体例：ガスの問題に見えても、原因が利用許可額の場合がある たとえば、ウォレットでトークン交換をしようとして「ガスを見積もれません」と表示されたとします。 この場合、ガス代を上げれば直るとは限りません。同じ送信元・送信先・数量でシミュレーションすると、「このコントラクトが使えるトークン量の許可が足りない」と分かることがあります。 そのとき確認すべきなのはガス代ではなく、トークンの利用許可額（利用許可額）です。このように、画面上の短いエラーと本当の原因が違うことがあるため、順番に証拠を確認します。 ## 1. 取引情報と実行結果を分けて取得する 取引情報には「何を送ろうとしたか」が入り、実行結果には「実際にどうなったか」が入ります。まず、この2つを分けて取得します。 ```ts const transaction = await publicClient.getTransaction({ hash }) const receipt = await publicClient.getTransactionReceipt({ hash }) console.log({ from: transaction.from, to: transaction.to, nonce: transaction.nonce, input: transaction.input, blockNumber: receipt.blockNumber, status: receipt.status, gasUsed: receipt.gasUsed, }) ``` `receipt.status`が`reverted`なら、取引はブロックに取り込まれましたが、コントラクトの処理は途中で取り消されています。 ただし、実行結果だけでは具体的なエラー名まで分からない場合があります。次に、取引情報の`input`へ入っている入力データを確認します。 ## 2. 入力データから呼び出した関数を特定する 入力データ（呼び出しデータ）は、コントラクトへ渡した指示書です。先頭4バイトには呼び出す関数の目印が入り、その後ろに引数が続きます。 正しいABIがある場合は、`decodeFunctionData`で関数名と引数を復元できます。 ```ts import { decodeFunctionData } from 'viem' const decoded = decodeFunctionData({ abi, data: transaction.input, }) console.log(decoded.functionName, decoded.args) ``` 復元できない場合は、次の可能性があります。 - ABIが呼び出し先と一致していない - プロキシの実装側ABIを使っていない - 通常の関数ではなくフォールバック関数へ送られた - 先頭4バイトだけでは候補を一つに決められない 関数名の候補だけで断定せず、検証済みソースコードやプロキシの実装アドレスと照合してください。 ABIと入力データの構造は[ABI・関数識別子・イベントログを手で読む方法](/archives/6005)で詳しく扱います。 ## 3. 同じ条件でシミュレーションする シミュレーションは、実際に取引を送信せずに行う試運転です。送信元、送信先、送るETH量、関数、引数を元の取引と揃えて`simulateContract`を実行します。 ```ts const result = await publicClient.simulateContract({ address: transaction.to, abi, functionName: decoded.functionName, args: decoded.args, account: transaction.from, value: transaction.value, }) ``` この方法なら、秘密鍵を使わずに、権限不足、残高不足、利用許可額不足、期限切れなどを調べられます。 ただし、**元の取引が実行された時点と現在では、チェーンの状態が違う場合があります**。残高、利用許可額、価格、停止状態、期限などが変わっていれば、現在のシミュレーション結果も変わります。 過去の状態を取得できても、**元のブロック番号を指定するだけで、対象取引の実行直前を再現したとはいえません**。同じブロック内の先行取引が残高や許可額を書き換えている場合、親ブロックの状態とも、ブロック全体の処理後の状態とも異なります。 たとえば、ある値が親ブロックでは0、先行取引の後では1、その後の別取引で2になる場合を考えます。値が1であることを前提とする処理は、0や2の状態へ同じ入力を渡すだけでは再現できません。 当時の失敗を追うには、同じブロック内の先行取引も含めて再実行する方法が必要です。[Gethの取引トレース](https://geth.ethereum.org/docs/developers/evm-tracing#state-availability)や`debug_traceTransaction`では、この実行前の状態を準備して対象取引を追跡します。利用するノードの対応と履歴状態の取得可否を確認し、現在のシミュレーションと当時の再実行結果を区別してください。 独自エラー、`Error(string)`、`Panic(uint256)`の読み分けは[実行が取り消されたと独自エラーをviemでデコードする方法](/archives/6002)へ進んでください。ガス見積もりの段階で止まる場合は[`estimateGas`が失敗する理由](/archives/6003)が対応します。 ## 4. 実行結果がない場合はノンスを確認する ノンスは、同じアカウントから送る取引の順番を示す整理番号です。番号が同じ取引は両方とも確定できないため、手数料を上げた別取引へ置き換わることがあります。 ```ts const [latestNonce, pendingNonce] = await Promise.all([ publicClient.getTransactionCount({ address: transaction.from, blockTag: 'latest', }), publicClient.getTransactionCount({ address: transaction.from, blockTag: 'pending', }), ]) ``` - `latest`は、確定済みの取引だけを基準にした次の番号です。 - `pending`は、そのノードが把握している保留中の取引も含めた番号です。 - 送信した番号が`latest`より小さいのに元のハッシュへ実行結果がない場合は、同じ番号を使った別ハッシュも確認します。 ウォレットとブロックエクスプローラーの表示が違うときは、チェーンID、送信元、ノンス、トランザクションハッシュを同じ条件で照合します。 ノンスによる置換と`nonce too low`は[`nonce too low`・置換手数料不足の原因と直し方](/archives/6004)で整理しています。送金先サービスへ反映されない問題は、チェーン上の状態と受取側の処理を分けて[MetaMaskの送金が反映されないときの確認](/archives/3708)も参照してください。 ## 調査結果を残すテンプレート ```text チェーンID（chainId）: トランザクションハッシュ: 送信元 / 送信先: ノンス（nonce）: ブロック番号: 実行結果のstatus: 関数名 / 引数: シミュレーションしたブロック: エラー名 / 引数: 同じnonceを使った別ハッシュ: ``` この形で記録すると、「チェーン上で失敗した」「まだ未確定」「別取引へ置き換わった」「受取側だけ未反映」を混同しにくくなります。 最初からすべての16進数を読めなくても問題ありません。まずは実行結果の有無、`status`、呼び出した関数、シミュレーションのエラー、ノンスの5点を揃えるだけでも、原因をかなり狭められます。 ERC-4337では一括処理トランザクションの実行結果と個別操作の結果が分かれます。[UserOperationをバンドラー・ペイマスター・実行へ分ける解析手順](/archives/6013)で、トランザクションハッシュがない受付拒否から理由イベントまで、同じ`userOpHash`に対応付けられます。 送信前後の失敗をウォレットプロバイダー、HTTP、JSON-RPC、ノード、トランザクション検証、EVMへ切り分ける場合は、[Ethereum RPCエラーの層別診断](/archives/6032)でコード、未加工の応答、viemが保持する原因の連鎖を対応させてください。 ## 確認した一次情報 - [Geth: transaction replay and preceding transactions](): 確認日 2026-09-05 - [viem getTransactionReceipt](): 確認日 2026-08-28 - [viem decodeFunctionData](): 確認日 2026-08-28 - [viem simulateContract](): 確認日 2026-08-28 - [ethereum.org トランザクション](): 確認日 2026-08-28 --- # execution revertedと独自エラーをviemでデコードする方法 execution revertedが返すエラーデータをABIとviemで読み解き、Error(string)・Panic・独自エラーを切り分ける方法を解説します。 正規URL: https://3mikan.com/archives/6002 著者: みかん 公開: 2026-08-27T12:34:00.000Z 更新: 2026-09-05T14:10:34.553Z `execution reverted`は、**コントラクトの処理が条件を満たせず、途中までの変更も取り消された**という意味です。 たとえば、残高が足りない、利用許可額が足りない、期限を過ぎた、操作する権限がない、といった場合に発生します。ただし、この表示だけではどの条件に引っかかったかまでは分かりません。 そこで、返されたエラーの中身を表すデータ（`revert`データ）をABIと照合します。 ![エラーデータを目印と引数へ分け、Error・Panic・独自エラーを判定する流れ](/diagrams/evm-debugging/6002-revert-data.svg) ## エラーデータは関数呼び出しと似た形で読める 独自エラーのデータは、先頭4バイトの目印（識別子）と、ABI形式で並べた引数で構成されます。 ```text 0x | 4-byte error selector | 32-byte word | 32-byte word | ... ``` これは、封筒の先頭に「どの種類の通知か」を示す番号があり、その後ろに詳細情報が続くイメージです。 エラー定義を含むABIがあれば、`decodeErrorResult`でエラー名と引数を復元できます。 ```ts import { decodeErrorResult } from 'viem' const decoded = decodeErrorResult({ abi, data: revertData, }) console.log(decoded.errorName, decoded.args) ``` **独自エラーを名前と引数まで読みたい場合は、そのエラー定義を含むABIが必要です。** 実装コントラクトがプロキシの背後にある場合、プロキシ側のABIだけでは独自エラーを解決できないことがあります。 一方、viemでは標準の`Error(string)`と`Panic(uint256)`の定義が組み込まれています。今回確認したviem 2.56.0では、`decodeErrorResult`へ`abi: []`を渡しても、この2形式をデコードできました。独自エラーのABI要件を、すべてのエラー形式へ広げないでください。 これは正しい形式のエラーデータがある場合の話です。空の`0x`や未知の識別子を、標準エラーとして補完するわけではありません。デコードできた名前だけで発生元を証明できない点も、後述のとおり変わりません。 ## 3種類のエラーを分けて考える ### Error(文字列) `revert("message")`や文字列付き`require`で使われる形式です。識別子は`0x08c379a0`で、その後ろにABI形式の文字列が続きます。 人が読めるメッセージを返せますが、メッセージが短すぎる場合や、途中の外部呼び出しからそのまま返ってきた場合は、追加の確認が必要です。 ### `Panic(uint256)` `assert`の失敗、ゼロ除算、配列の範囲外など、Solidityが定義する内部的な異常を番号で返す形式です。識別子は`0x4e487b71`です。 番号だけで判断せず、使用しているSolidityのバージョンに対応する`Panic`コードの表と、失敗した処理を照合します。 ### 独自エラー ```solidity error InsufficientBalance(uint256 available, uint256 required); ``` 独自エラーは、開発者がエラー名と引数を定義する形式です。上の例なら、「利用できる残高」と「必要な残高」を数値で返せます。 文字列より少ないデータ量で詳しい情報を返せる一方、正しいABIがなければ元のエラー名へ戻せません。 ## `simulateContract`の例外から読む viemでは、`simulateContract`でシミュレーションしたときの例外から`ContractFunctionRevertedError`を探し、デコード済みの情報を参照できます。 ```ts import { BaseError, ContractFunctionRevertedError } from 'viem' try { await publicClient.simulateContract({ address, abi, functionName: 'transfer', args: [to, amount], account, }) } catch (error) { if (error instanceof BaseError) { const reverted = error.walk( (cause) => cause instanceof ContractFunctionRevertedError, ) if (reverted instanceof ContractFunctionRevertedError) { console.log(reverted.data?.errorName, reverted.data?.args) } } } ``` シミュレーションは実際の取引を送信しないため、まず原因を調べる用途に向いています。送信元、送る数量、関数、引数、ブロック条件を元の取引と揃えることが重要です。 ## デコードできないときの確認順 1. `data`が空ではないか 2. `0x`を含む完全なエラーデータか 3. 呼び出し先がプロキシなら、実装アドレスと実装側ABIを確認したか 4. `delegatecall`先や外部呼び出し先のエラーもABIへ含めたか 5. 同じ`account`、`value`、ブロック条件でシミュレーションしたか 6. ノードやRPCがエラーデータを省略していないか 関数入力のABI確認は[ABI・関数識別子・呼び出しデータ・イベントログを手で読む方法](/archives/6005)、トランザクション全体の入口は[viemで失敗トランザクションを調べる](/archives/6001)を参照してください。 ## エラー名だけを信用しない エラーデータは外部呼び出しからそのまま返ってくることがあり、任意のコントラクトが同じ形のバイト列を返すこともできます。そのため、表示されたエラー名だけで送信元や安全性を証明することはできません。 次の情報も合わせて確認します。 - 実行結果に記録された送信先 - プロキシの実装アドレス - 検証済みソースコードとABI - シミュレーションや実行履歴で実際に呼び出されたコントラクト [直コンの基本](/archives/1005)を使う場合も、署名画面だけで判断せず、対象アドレスと入力データを先に検証してください。 ERC-4337 EntryPointの`FailedOpWithRevert.inner`、`UserOperationRevertReason`、`PostOpRevertReason`をどのABIで読むかは、[UserOperation失敗の段階別解析](/archives/6013)でアカウント・ペイマスター・対象ごとに分けています。 `revert`データへ到達する前のプロバイダー拒否、HTTP 429、JSON-RPCコード、ノード制限も含めて入口から分ける場合は、[Ethereum RPCエラーの層別診断](/archives/6032)を参照してください。 ## 確認した一次情報 - [viem decodeErrorResult](): 確認日 2026-09-05 - [viem simulateContract](): 確認日 2026-08-28 - [Solidity Contract ABI Specification](): 確認日 2026-08-28 - [Solidity エラーハンドリング](): 確認日 2026-08-28 --- # ABIから関数識別子・入力データ・イベントログを読む方法 ABI、4バイトの関数識別子、入力データ、イベントトピック、ログの構造を、ERC-20のtransferを使った例とviem APIで解説します。 正規URL: https://3mikan.com/archives/6005 著者: みかん 公開: 2026-08-27T12:46:00.000Z 更新: 2026-09-05T14:10:34.553Z ブロックエクスプローラーで`Input Data`や`Logs`を開くと、長い16進数が並びます。最初は意味のない文字列に見えますが、区切り方を知れば「どの関数を、誰に対して、どの数量で実行したか」を確認できます。 イメージは、宛名や金額が決まった書類を、コンピュータが読める決まった幅へ並べ直したものです。ABIは、その書類の各欄をどう読むか示す説明書です。 ![ERC-20送金の入力データとTransferイベントログを関数セレクター、トピック、データへ分解した図](/diagrams/evm-debugging/6005-abi-calldata-logs.svg) ## ABIはデータを読むための型情報 ABI形式のデータは、それだけでは各値の意味を説明してくれません。同じ32バイト列でも、`uint256`、`address`、`bytes32`のどれとして読むかで意味が変わります。 その読み方を決めるのがABIです。関数の目印を検索した結果だけで断定せず、コントラクトの検証済みソースコードや、現在の実装に対応するABIと照合します。 ## 関数識別子は先頭4バイトの目印 関数名と引数の型を決められた書式で並べ、Keccak-256ハッシュの先頭4バイトを使います。この4バイトが、呼び出す関数の目印（関数識別子）です。 ```text transfer(address,uint256) ↓ Keccak-256 0xa9059cbb... ↓ first 4 bytes 0xa9059cbb ``` ERC-20の`transfer(address,uint256)`を呼び出す入力データ（呼び出しデータ）は、次の形になります。 ```text 0xa9059cbb 0000000000000000000000001111111111111111111111111111111111111111 000000000000000000000000000000000000000000000000000000000001e240 ``` - `0xa9059cbb`: 呼び出す関数の目印 - 1つ目の32バイト: 送金先の`address`。20バイトの値を左側からゼロで埋めている - 2つ目の32バイト: 送る数量。この例では`0x1e240 = 123456` つまり、この例は「`0x1111...1111`へ123456単位を送る」という指示です。小数点以下の桁数はトークンごとに違うため、人が見る数量へ直すときは`decimals`も確認します。 ## viemで入力データをデコードする ```ts import { decodeFunctionData } from 'viem' const decoded = decodeFunctionData({ abi: erc20Abi, data, }) console.log(decoded.functionName, decoded.args) ``` 手で読む方法は検算に向いています。ただし、タプル、配列、文字列、バイト列などの可変長データでは、別の位置を指すオフセットとデータ長も追う必要があります。 実装ではABIライブラリを使い、手読みは「関数の目印、32バイトの境界、アドレス、整数が不自然でないか」を確認する用途に限定します。 ## 動的型は先頭と後半に分かれる `string`や可変長`bytes`は、その位置に実データを直接置きません。最初の部分（ヘッド）には実データの位置を示すオフセットを置き、後ろの部分（テール）へ長さとデータを置きます。 ```text head: offset to tail ... tail: length | data | padding ``` たとえば、申込書の欄へ長い文章を直接書かず、「詳細は別紙のこの位置」と示すイメージです。 関数の引数を一番外側から読むとき、オフセットの基準は先頭4バイトの関数識別子を除いたABI引数ブロックの先頭です。入れ子のタプルでは、そのタプルを符号化した部分の先頭へ基準が移ります。 動的配列の要素がさらに動的型なら、要素のオフセットは、配列長を表す32バイトの直後にある要素のヘッド部分の先頭から数えます。すべてのオフセットを入力データ全体から数えず、[ABIの再帰的な符号化規則](https://docs.soliditylang.org/en/v0.8.36/abi-spec.html#formal-specification-of-the-encoding)に沿って、今読んでいる階層の基準位置を確認してください。 ## イベントログは「処理中に発行された記録」 イベントログは、コントラクトが処理中に発行する記録です。送金や交換が行われたときに、関係するアドレスや数量を後から検索しやすい形で残します。 匿名でないイベントでは、`topics[0]`にイベント署名のKeccak-256ハッシュが入り、`indexed`に指定された引数が続きます。索引付きでない引数は`data`へABI形式で格納されます。 ERC-20の`Transfer(address indexed from, address indexed to, uint256 value)`なら、次の形です。 ```text topics[0] = keccak256("Transfer(address,address,uint256)") topics[1] = from topics[2] = to data = value ``` ```ts import { parseEventLogs } from 'viem' const transfers = parseEventLogs({ abi: erc20Abi, logs: receipt.logs, eventName: 'Transfer', }) ``` ### 索引付きの文字列・配列・構造体は元データへ戻せない `string`や可変長`bytes`だけでなく、**固定長配列を含むすべての配列と構造体**も、索引付きにすると特殊な符号化のKeccakハッシュがトピックへ入ります。たとえば`uint256[1]`は、要素が一つで通常のABIでは静的型に分類されても、その索引値を整数1個として直接読むことはできません。 これに対して、単独の`uint256`や`address`などは、値を32バイトへ揃えたものが索引に入ります。[イベント引数の符号化規則](https://docs.soliditylang.org/en/v0.8.36/abi-spec.html#events)に沿って型を確認してください。ハッシュになった索引は、既知の候補値を同じ方法で符号化して照合できますが、トピックだけから未知の原文や配列を復元するデコードとは別です。 ## ログだけで成功を断定しない ログが見つかっただけで、取引全体の成功を断定しないでください。最終的には、実行結果（トランザクションの実行結果）の`status`、コントラクトアドレス、ブロック番号、ログ索引も確認します。 別コントラクトが同名のイベントを発行している、プロキシ経由で実行された、誤ったABIで読んでいる、といった可能性があるためです。 プロキシの`Upgraded`、`AdminChanged`、`BeaconUpgraded`を実装 / 管理者 / ビーコンスロットと同じブロックへ対応させる場合は、[ERC-1967 Proxyを未加工ストレージとイベント履歴から読む方法](/archives/6020)へ進んでください。 1つのアドレスが識別子ごとに別ファセットへ`delegatecall`する場合は、[EIP-2535 Diamondの識別子・参照機能・DiamondCutを読む手順](/archives/6047)で、4バイト識別子から現在ファセット、変更イベント、共有ストレージまで対応させています。 トランザクション全体の解析は[実行結果・入力データ・エラーの確認順](/archives/6001)、エラーの目印は[独自エラーのデコード](/archives/6002)へ進んでください。[直コン](/archives/1005)で書き込みを行う前にも、送信先、関数の目印、引数を確認する習慣が役立ちます。 ## 小さな例で検算する 上のERC-20送金例では、次の4点が一致すれば読み方は合っています。 1. 先頭4バイトが`transfer(address,uint256)`の目印である 2. 1つ目の32バイトから送金先`0x1111...1111`を復元できる 3. 2つ目の32バイトが10進数の`123456`になる 4. `Transfer`ログの送信先と数量が、実行結果の内容と矛盾しない 最初から長いデータをすべて手で読む必要はありません。まず、関数の目印、アドレス、数量の3点だけをライブラリのデコード結果と見比べると、入力先や桁数の間違いに気づきやすくなります。 ABIの根拠になったソース自体を確認するときは、[検証済みソースをコンパイラー・コンストラクター・ライブラリー・メタデータから再ビルドする手順](/archives/6033)で、公開ABIとチェーン上実行時がどのビルド条件に対応するかを照合してください。 トランザクションの呼び出しデータではなく、EIP-712署名の`types`、ドメイン区切り、構造体ハッシュ、最終ダイジェストを追う場合は、[EIP-712署名をノンス・有効期限まで検証する方法](/archives/6010)へ進んでください。 `isValidSignature(bytes32,bytes)`の戻り値データ、マジック値、`revert`をEOAのECDSA経路と分ける場合は、[ERC-1271でコントラクトアカウント署名を検証する方法](/archives/6011)を参照してください。 `approve`、ERC-2612 Permit、Permit2、ERC-7674で権限状態の保存先と失効方法を比べる場合は、[ERC-20権限4方式の比較](/archives/6012)で同じ所有者・トークン・利用先の再現例を確認できます。 ERC-4337の`PackedUserOperation`、`UserOperationEvent`、内部の`revert`を同じハッシュへ対応させる場合は、[UserOperationをバンドラー・ペイマスター・実行へ分ける方法](/archives/6013)でRPC項目とチェーン上ABIをつなげて確認できます。 ## 確認した一次情報 - [Solidity: indexed arrays and structs](): 確認日 2026-09-05 - [Solidity Contract ABI Specification](): 確認日 2026-08-28 - [Solidity ABI: recursive encoding and relative offsets](): 確認日 2026-09-05 - [viem decodeFunctionData](): 確認日 2026-08-28 - [viem parseEventLogs](): 確認日 2026-08-28 - [ethereum.org トランザクション](): 確認日 2026-08-28 --- # estimateGasが失敗する理由｜シミュレーションとエラーデータの確認方法 estimateGasの失敗を、入力、送信元、送金額、権限、利用許可額、期限、シミュレーション、エラーデータの順に切り分ける方法を解説します。 正規URL: https://3mikan.com/archives/6003 著者: みかん 公開: 2026-08-27T12:38:00.000Z 更新: 2026-09-02T05:35:00.000Z `estimateGas`が失敗したとき、ガス上限を増やすだけでは直らないことがあります。 `eth_estimateGas`は、実際には取引を送信せず、「この処理を実行するにはどれくらいのガスが必要か」を試算する仕組みです。試算の途中でコントラクトが処理を拒否すると、必要量を計算する前に止まります。 たとえば、トークン残高や利用許可額が足りない場合です。このとき表示は「ガスを見積もれない」でも、本当の原因はガス不足ではありません。 ![ガス見積もりの失敗を送信内容、シミュレーション、コントラクトの状態、RPCの順に切り分ける図](/diagrams/evm-debugging/6003-estimate-gas.svg) ## ガス上限不足と処理の取り消しを分ける - **ガス上限不足**: 処理できる内容だが、許可したガス量が足りない - **処理の取り消し（`revert`）**: 権限、残高、利用許可額、期限、価格条件、停止状態などにより、コントラクトが処理を拒否する - **RPCへの入力不備**: 送信元、送信先、送金額、入力データ、チェーンが実際の送信条件と違う エラー文に`estimateGas`と書かれていても、根本原因がコントラクトの独自エラーであることは珍しくありません。 ## 1. 実際に送る条件を揃える まず、次の値を確認します。 ```text チェーンID（chainId） 送信元（account / from） コントラクトアドレス（address / to） 関数名と引数（function name + args / data） 送るネイティブトークン量（value） access list（利用時） 対象ブロックまたはblockTag ``` `account`を省略すると、`msg.sender`に依存する権限や残高の確認結果が、実際の送信時と変わる可能性があります。ETHなどを同時に送る`payable`関数では`value`も必要です。 ## 2. `simulateContract`で試運転する `simulateContract`は、実際には取引を送らず、同じ条件でコントラクトを試運転する関数です。 ```ts const { request, result } = await publicClient.simulateContract({ address, abi, functionName, args, account, value, }) ``` シミュレーションが成功した場合は、返された`request`をWallet Clientへ渡すと、確認した条件と実際の送信条件のずれを減らせます。 失敗した場合は、返されたエラーデータを確認します。具体的な読み方は[独自エラーのデコード手順](/archives/6002)で扱っています。 ## 3. 時間や残高で変わる条件を確認する 同じコードでも、次の状態が変わると結果が変わります。 - トークン残高とネイティブトークン残高 - 利用許可額（利用許可額）と承認先 - 役割、所有者、許可一覧などの権限 - 一時停止状態、販売の開始・終了 - 期限とブロック時刻 - DEXの予備と最低出力 - プロキシの実装と更新後のABI たとえば、昨日は十分な残高があったとしても、現在の残高が減っていれば同じ取引は失敗します。過去に成功した取引を比較するときは、入力値だけでなくブロック番号も一緒に残してください。 ## 4. ガス量とガス単価を分ける `estimateGas`が扱うのは、実行に必要なガスの量です。`estimateFeesPerGas`などが扱うのは、ガス1単位あたりの手数料です。 コントラクトが処理を拒否している段階で優先度手数料だけを上げても、残高不足や権限不足は解消しません。 保留中の取引や置換の問題は[`nonce too low`・置換手数料不足の原因と直し方](/archives/6004)へ分けます。 ## よくある修正ミス ### ガス上限を大きくすれば直ると思う 処理を取り消す条件は、ガス量を増やしても変わりません。まずエラーデータと入力条件を確認します。 ### 送信元を省略した読み取りだけで判断する 権限、残高、利用許可額が送信者によって変わる場合は、本番と同じ`account`を指定してシミュレーションします。 ### 実装側ではなくプロキシ側のABIだけを使う 関数や独自エラーを復元できない場合があります。プロキシの実装アドレスと検証済みソースコードを確認します。 ### メインネットで試し送信する 原因調査のために実資産を送る必要はありません。最初にシミュレーションを行い、必要ならテストネットを使います。[直コン](/archives/1005)も同様に、読み取りとシミュレーションから始めてください。 ## 最小チェックリスト 1. チェーンとコントラクトアドレスは正しいか 2. `account`、`value`、引数を実際の送信条件と揃えたか 3. ABIは現在の実装と一致するか 4. 残高、利用許可額、権限、期限を確認したか 5. シミュレーションで返ったエラーデータを保存したか 6. 別のRPCでも同じ結果か 7. 対象ブロックと確認日時を記録したか トランザクションハッシュがすでにある場合は、[実行結果から始める解析フロー](/archives/6001)へ戻ると、送信前のエラーと確定後の処理取り消しを分けて考えられます。 `eth_estimateUserOperationGas`の失敗では、バンドラー受付、アカウント検証、ペイマスター、内部実行を同じエラーにまとめないことが重要です。[ERC-4337 UserOperationの失敗解析](/archives/6013)でRPCコード、`AAxx`、組み込み後のイベントへ分岐できます。 `estimateGas`の`revert`とHTTPタイムアウト、JSON-RPC無効引数、ノード側の制限を混同しないための全体図は、[Ethereum RPCエラーの層別診断](/archives/6032)で確認できます。 ## 確認した一次情報 - [ethereum.org JSON-RPC eth\_estimateGas](): 確認日 2026-08-28 - [viem simulateContract](): 確認日 2026-08-28 - [ethereum.org ガスと手数料](): 確認日 2026-08-28 --- # トランザクションの保留・破棄・置換を判定する方法 トランザクションハッシュ、実行結果、状態、ブロック、送信元、ノンス、置換後のハッシュを照合し、保留・確定・失敗・破棄候補・置換を安全に判定する手順です。 正規URL: https://3mikan.com/archives/6004 著者: みかん 公開: 2026-08-27T12:42:00.000Z 更新: 2026-09-02T05:35:00.000Z ウォレットに`pending`と出ている、ブロックエクスプローラーでトランザクションハッシュが見つからない、受取先の残高に反映されない。この3つは同じ状態とは限りません。**実行結果があれば保留中ではない**ため、ウォレットの表示より先にチェーン上の証拠を確認します。 ## 結論：実行結果から順に判定する | 判定 | 必要な証拠 | 読み方 | | --- | --- | --- | | 確定済み・成功 | 元ハッシュの実行結果があり、ブロックに含まれ、`status = success` | チェーン上では成功。受取側の反映待ちは別問題 | | 確定済み・失敗 | 元ハッシュの実行結果があり、`status = reverted`またはブロックエクスプローラーの`Fail` | ブロックには含まれたが処理は失敗。保留中ではない | | 保留中（観測済み） | 実行結果はなく、ブロックエクスプローラーまたはRPCが未採掘トランザクションを観測 | その観測元では保留中。ネットワーク全体の保証ではない | | 置換済み | 別ハッシュが同じ`from + nonce`で確定 | 元ハッシュは同じノンスを使えず、置換済み | | 破棄候補 | 実行結果なし、複数の観測元でハッシュなし、ノンスも未消費 | 破棄の候補。再送信で再出現し得る | | ノンス消費済み・置換不明 | 実行結果なし、`latest nonce > tx nonce`だが置換ハッシュ未特定 | 何かがノンスを消費済み。置換済みと断定せず別ハッシュを探す | ブロックエクスプローラーで`not found`になっただけでは破棄を確定できません。RPC障害、索引遅延、別チェーン、別ノードのトランザクションプール、ウォレット内だけの履歴も切り分けます。 ![トランザクションハッシュから実行結果、保留中観測、同一送信元・ノンスの別ハッシュ、複数RPCを順に確認し、確定済み成功、失敗、保留中観測済み、置換済み、破棄候補へ分岐する図](/diagrams/evm-debugging/6004-nonce.svg) ## 最初に記録する9項目 画面を更新したりウォレット履歴を消したりする前に、次をテキストで保存します。 ```text チェーンID / ネットワーク 元のトランザクションハッシュ 送信元（from） 送信先（to） ノンス ブロック番号（あれば） 実行結果の状態（あれば） 置換後のトランザクションハッシュ（あれば） 確認したブロックエクスプローラー・RPC・日時 ``` `hash`だけでは、別チェーンで同じ文字列を検索しているミスを除外できません。`from`と`nonce`だけでは、どの呼び出しが実行されたか分かりません。`to`、`value`、呼び出しデータ、トークン送金ログも必要に応じて保存します。 ## 1. 実行結果があれば成功か失敗に分ける [Ethereum Execution API](https://ethereum.github.io/execution-apis/api-documentation/)の`eth_getTransactionReceipt`は、トランザクションがブロックへ含まれるまでは実行結果を返しません。実行結果が得られたら、`blockNumber`と`status`を確認します。 ```ts const transaction = await publicClient.getTransaction({ hash }) const receipt = await publicClient.getTransactionReceipt({ hash }) console.table({ hash: transaction.hash, from: transaction.from, to: transaction.to, nonce: transaction.nonce, blockNumber: receipt.blockNumber, status: receipt.status, // 'success' | 'reverted' }) ``` 未検出とRPC障害を同じ`catch`で握りつぶさないでください。viemの`TransactionNotFoundError`や`TransactionReceiptNotFoundError`だけを「未検出」として扱い、タイムアウト、利用制限、チェーン不一致は調査エラーとして止めます。 ### 失敗もブロックには含まれている
EtherscanのEthereumトランザクション詳細にFail、ブロック番号、送信元、送信先、実行が取り消されたが表示された公開画面
2026年8月28日に確認したEtherscan公開画面。Ethereumメインネットの公開ハッシュで、StatusはFail、ブロックは25853564、実行結果は実行が取り消されていました。個人ウォレットは使用していません。
`Fail`でもブロック番号と実行結果は存在します。状態変更は`revert`しますが、実行に使われたガスは支払われます。`revert`の理由、呼び出しデータ、ログの読み方は[viemで失敗トランザクションを解析する](/archives/6001)へ分けています。 ## 2. 実行結果がなければ保留中の観測を探す
EtherscanのPending Transactions一覧にトランザクションハッシュ、ノンス、最終確認時刻、ガス、送信元、送信先が並ぶ公開画面
2026年8月28日のEtherscan Pending Transactions公開画面。表示中のハッシュは一時的な観測で、撮影後に確定済み、失敗、置換済み、破棄のいずれかへ変わる可能性があります。
保留中一覧や`eth_getTransactionByHash`でトランザクションが見え、`blockNumber`と実行結果がまだなければ、そのブロックエクスプローラーまたはノードでは保留中として観測されています。ただしメモリープールは全ノードで完全に同じではありません。 同じ`from`について、確定済みと保留中を別々に取得します。 ```ts const [latestNonce, pendingNonce] = await Promise.all([ publicClient.getTransactionCount({ address: from, blockTag: 'latest' }), publicClient.getTransactionCount({ address: from, blockTag: 'pending' }), ]) ``` - `latest`: 最新の確定状態から見た次のノンス - `pending`: 接続ノードが認識する保留中も考慮した値 - `latest > transaction nonce`: そのノンスは確定チェーン上ですでに消費済み - `pending > latest`: そのノードが未確定のノンス列を観測している手掛かり `pending`値は接続ノードの見え方です。別RPC、ブロックエクスプローラー、ウォレットのActivityを時刻付きで照合します。 ## 3. 同じ送信元・ノンスの別ハッシュが確定したら置換済み ノンスは同じアカウントから送るトランザクションの実行順です。同一チェーンで、**別ハッシュが同じ`from + nonce`を使って実行結果を持つ**なら、元ハッシュは置換済みと判断できます。置換側が`revert`していてもノンスは消費されるため、元ハッシュは後から同じノンスで確定できません。
Etherscan公式例で元トランザクションがDropped and Replacedとなり、別ハッシュが同じFromとノンス7でSuccessになった比較画面
Etherscan公式解説に掲載された2020年の実画面例。左の元ハッシュと右の確定ハッシュは同じFrom・ノンス7で、元ハッシュにはDropped & Replacedと置換後のハッシュが表示されています。現在のUIとはレイアウトが異なります。
`latest nonce`が進んだだけでは、元ハッシュが確定したのか、別ハッシュへ置換されたのかまでは分かりません。送信アカウントのトランザクション履歴、ウォレット/プロバイダーのActivity、置換後のハッシュを探し、両ハッシュの実行結果を保存します。 ## 4. ハッシュ未検出は破棄確定ではない
Etherscanでトランザクションハッシュ未検出と表示され、別ノードのTX Poolに残る可能性や索引待ちを案内する公開画面
2026年8月28日のEtherscan公開画面。元ハッシュは現在未検出ですが、画面自身も別ノードのTX Pool、ネットワークへの送信待ち、索引遅延の可能性を案内しています。
[Etherscanの破棄解説](https://info.etherscan.com/transaction-dropped-replaced/)でも、ノードごとに保留中のトランザクションプールの上限や設定があり、いったん落ちたトランザクションが再送信されると保留中へ戻り得ると説明されています。 そのため本記事では、次をすべて満たしても`dropped-candidate`と呼びます。 1. 元ハッシュの実行結果がない 2. 時間を空けて複数の独立したRPC・ブロックエクスプローラーでトランザクションを観測できない 3. `latest nonce <= transaction nonce`で、対象ノンスが確定チェーン上では未消費 4. 同じ`from + nonce`の確定済み別ハッシュが見つからない 5. RPCエラーや別チェーン検索を除外した 送信元サービスが非公開リレーや独自プールを使う場合もあります。取引所、ウォレット、RPCプロバイダーが送信主体なら、送信記録と置換後のハッシュをその提供元へ確認します。 ## 優先処理と取り消しは同じノンスの置換試行
MetaMask公式HelpのSepolia Activity画面でSentがPendingとなりCancelとSpeed upボタンが表示されたExtension UI
MetaMask公式Help掲載のExtension実画面。サンプルのSepoliaトランザクションにPending、Cancel、Speed upが表示されています。3MIKANでは個人ウォレットを開かず、公式掲載画像だけを確認しました。
[MetaMask公式Help](https://support.metamask.io/manage-crypto/transactions/how-to-speed-up-or-cancel-a-pending-transaction)の説明では、どちらも元トランザクションがネットワーク上で保留中の間に行う操作です。 - **Speed up**: 同じ内容・同じノンスを、より高い手数料条件で再送する - **Cancel**: 同じノンスで自分宛て0 ETHなどを送り、元トランザクションより先に確定させることを試みる 取り消しはチェーン上の取り消し命令ではありません。元トランザクションと置換トランザクションのどちらが先に採用されるかを競うため、**すでに確定済みのトランザクションは戻せず、保留中でも成功保証はありません**。 ### 置換に失敗しやすい条件 - 元トランザクションが先に確定した - 置換ノンスが元ノンスと違う - 手数料の上げ幅が接続ノードの置換条件を満たさず、`replacement transaction underpriced`になった - より古い保留中ノンスが前に詰まっている - `from`またはチェーンが違う - 手数料を払うネイティブトークン残高が不足している - MetaMask Smart Transactionsやプロバイダー独自の送信経路を通常メモリープールと同じ前提で扱った 必要な手数料上昇幅はクライアント、RPC、ネットワーク条件で変わります。固定率をプロトコル保証として扱わず、ウォレットの現在提案、元トランザクションの`maxFeePerGas`と`maxPriorityFeePerGas`、ネットワーク状況を確認します。手動ノンスを使う場合は、MetaMask公式の案内どおり最も古い保留中から解消し、Smart Transactionsの制約も確認してください。 ## 受取側に反映されない問題はチェーン状態と分ける 実行結果が`success`でブロックに含まれているなら、トランザクションはもう保留中ではありません。次を受取側の問題として調べます。 - 送ったチェーンと受取サービスが対応する入金ネットワークは同じか - `to`は案内された入金アドレスか - ERC-20ならTransferログのトークンアドレス、`from`、`to`、数量は正しいか - 取引所が必要とする承認数を満たしたか - メモ / タグなど別項目が必要なチェーンでは入力が正しいか - 最低入金、メンテナンス、トークンコントラクト変更、サービス側索引遅延がないか 反対に実行結果が`reverted`なら、受取側へ問い合わせる前に失敗原因を確認します。送金操作そのものの確認は[MetaMaskの送金が反映されないときの確認](/archives/3708)へ戻れます。実行結果が`success`でも誤ったネットワーク・アドレスを疑う場合は、[送信チェーンと送金先の管理主体を確認する手順](/archives/6009)で分けます。 誤送金の回収可否はチェーンと受取主体で異なり、どちらの記事も回収を保証しません。 ブリッジ送金ではソース実行結果の`success`が送信先実行を意味しません。[送信元トランザクション、メッセージ識別子、プロトコル段階、送信先トランザクションを分ける手順](/archives/6027)で、同じチェーン間メッセージを追跡してください。 ## 実装でも証拠の優先順位を固定する アプリや調査用スクリプトへ組み込む場合も、RPCの表示順ではなく、実行結果とノンスの証拠を明示的な入力にします。 ```ts const state = classifyTransactionEvidence({ originalReceiptStatus: receipt?.status ?? null, replacementReceiptStatus: replacementReceipt?.status ?? null, replacementMatchesSenderAndNonce: replacement != null && replacement.hash !== original.hash && replacement.from === original.from && replacement.nonce === original.nonce, pendingObserved: transaction != null && transaction.blockNumber == null, latestNonce: Number(latestNonce), transactionNonce: Number(original.nonce), missingSourceCount: 0, }) ``` 判定の優先順位は`元receipt → 確定replacement → nonce消費 → pending観測 → 複数ソース未検出`です。`latest nonce`が進んでいるのにハッシュを見つけられないケースを、都合よく破棄へ分類しません。 型3トランザクションでは、通常の実行ガスに加えてBlobガスも実行結果へ記録されます。[Fusaka・PeerDASとBlob手数料の記事](/archives/6023)では、同じブロックへ固定したトランザクション、実行結果、Beaconサイドカーを照合し、2種類の手数料を別計算しています。 ## 調査を終える前のチェックリスト - [ ] `chainId`、ハッシュ、送信元、送信先、ノンスを保存した - [ ] 元ハッシュのトランザクションと実行結果を別々に確認した - [ ] ブロックと実行結果の状態を確認した - [ ] `latest`と`pending`のノンスを同じ送信元で比較した - [ ] 同じ送信元・ノンスの別ハッシュと実行結果を探した - [ ] 未検出とRPCエラーを区別した - [ ] 受取側の未反映をチェーン未確定と混同していない - [ ] 優先処理 / 取り消し後も両ハッシュの実行結果を確認した - [ ] ウォレット履歴の初期化や再送前に証拠を保存した 最短ルートは、ウォレットのラベルを信じ切ることではなく、**実行結果、ブロック、状態、送信元、ノンス、置換後のハッシュを順番に固定すること**です。結論が出ない場合は`unknown`のまま記録し、送信元プロバイダーの情報を追加してから再判定します。 ERC-4337のノンスは192ビットキーと64ビット連番へ分かれ、バンドラーのプール状態も関係します。[UserOperationのAA25と実行結果を調べる手順](/archives/6013)では、EntryPointの`getNonce`、受付時エラー、個別イベントを別の証拠として扱います。 `nonce too low`や`replacement underpriced`をプロバイダー、HTTP、JSON-RPC、EVMの失敗と分けて再試行条件を決める場合は、[Ethereum RPCエラーの層別診断](/archives/6032)へ進んでください。 ## 確認した一次情報 - [Ethereum Execution API](): 確認日 2026-08-28 - [ethereum.org トランザクション](): 確認日 2026-08-28 - [viem getTransaction](): 確認日 2026-08-28 - [viem getTransactionReceipt](): 確認日 2026-08-28 - [viem getTransactionCount](): 確認日 2026-08-28 - [MetaMask pending transactionのspeed up・cancel](): 確認日 2026-08-28 - [MetaMask pending transactionを置換できない理由](): 確認日 2026-08-28 - [MetaMask Smart Transactions](): 確認日 2026-08-28 - [Etherscanでtransactionを確認する方法](): 確認日 2026-08-28 - [Etherscan Transaction Dropped & Replaced](): 確認日 2026-08-28 - [Etherscan dropped transactionのreplacement例](): 確認日 2026-08-28 --- # EIP-7702でEOAはどう変わる？tx.origin・msg.senderをFoundryで確認する EIP-7702でEOAへ委任コードを設定したとき、アドレス・残高・保存領域・msg.sender・tx.originがどう扱われるかを、Foundryの再現テストで確認します。 正規URL: https://3mikan.com/archives/6006 著者: みかん 公開: 2026-08-28T00:45:00.000Z 更新: 2026-09-02T05:35:00.000Z EIP-7702を一言でいうと、**普段使っているウォレットアドレスのまま、処理だけを別のコントラクトへ任せられる仕組み**です。 たとえば、店舗の住所、残高、帳簿はそのままにして、「この受付手順を使って処理してください」という案内を店頭へ置くイメージです。住所そのものが別店舗へ変わるわけではありません。 Ethereumでは、EIP-7702がPectraアップグレードの一部として2025年5月7日に有効化されました。これにより、EOAでも複数操作の一括実行や、別の送信者によるガス代の立て替えなどを実装しやすくなっています。 一方で、これまでの「EOAにはコードがない」「`tx.origin == msg.sender`なら最初の呼び出し階層である」という前提は、そのまま使えなくなりました。 この記事では、EOAのどの部分が残り、どの部分を委任先が担当するのかを整理した後、Foundryで保存領域と呼び出し元を確認します。 ## 先に用語を普通の言葉で確認する | 用語 | 普通の言葉でいうと | EIP-7702での役割 | | --- | --- | --- | | EOA | 秘密鍵で署名して取引を送る通常のウォレットアドレス | アドレス、残高、送信順番号、保存領域を持つ | | 委任先（実装） | 実際の処理手順を書いたコントラクト | EOAが実行する関数のロジックを提供する | | 委任を示すコード | 「この委任先の処理を使う」という案内 | `0xef0100`と委任先アドレスを組み合わせた23バイト | | 委任許可（認可） | EOA本人が委任を認めた署名 | チェーンID、委任先、ノンス、署名を含む | | `msg.sender` | 今の関数を直接呼んだアドレス | 呼び出し階層ごとに変わる | | `tx.origin` | 取引全体を開始したEOA | 取引の途中でも同じアドレスが続く | 専門用語をすべて暗記する必要はありません。まずは、**住所と帳簿はEOA、処理手順は委任先**と考えると追いやすくなります。 ![EOAの住所・残高・保存領域と、委任先コントラクトの処理ロジックを分けて示す図](/diagrams/account-abstraction/6006-eip-7702-context.svg) ## EOAへ置かれるのは実装コードではなく23バイトの案内 EIP-7702では、EOAへ委任先コントラクトの全コードをコピーしません。EOAのコード欄へ、次の形の短いデータを設定します。 ```text 0xef0100 | 20-byte implementation address ``` `0xef0100`が3バイト、アドレスが20バイトなので、合計は23バイトです。このデータは委任を示すコード（委任指標）と呼ばれます。 EOAが呼び出されると、EVMはこの案内を見て委任先のコードを取得します。ただし、処理は委任先自身のアドレスではなく、**委任を設定したEOAの実行文脈**で動きます。 | 実行時の要素 | 使われるもの | | --- | --- | | `address(this)` | 委任を設定したEOAのアドレス | | ETH残高 | EOAの残高 | | 保存領域 | EOAの保存領域 | | 関数のロジック | 委任先コントラクトのコード | | 委任先自身の保存領域 | 通常は変更されない | 動き方は`delegatecall`に近いものの、通常の`delegatecall`をEOAが自分で実行するわけではありません。EVMが23バイトの案内を解決し、委任先コードをEOAの文脈で実行します。 ## 委任は取引が終わっても残る EIP-7702は新しい取引形式`0x04`を追加し、その取引へ委任許可の一覧を添付します。許可が正しければ、EOAのコード欄へ委任を示すコードが設定されます。 この設定は、その取引だけで消える一時的なものではありません。別の委任先へ置き換えるか、ゼロアドレスを指定して解除するまで残ります。 特に注意したいのは、**委任を設定した後の関数実行が取り消されても（`revert`）、処理済みの委任設定は元に戻らない**点です。アプリ側で「呼び出しに失敗したから委任も失敗した」と判断しないようにします。 また、委任を解除してもEOAの保存領域は自動では消えません。次の委任先が同じ保存場所を別の意味で読むと、権限や数値を誤って解釈する可能性があります。 ## FoundryでEOAの実行文脈を確認する 今回は次の環境で確認します。 | 項目 | バージョン・設定 | | --- | --- | | Foundry | v1.8.0 | | Solidity | v0.8.36 | | EVM | Prague | | 外部RPC | 不要 | | 実資産 | 不要 | EIP-7702のチートコードを使うには、EVMのバージョンを`prague`以上にします。 ```toml [profile.default] solc_version = "0.8.36" evm_version = "prague" optimizer = true optimizer_runs = 200 ``` 検証では、委任先の`DelegatedAccount`と、呼び出し元を記録する`ContextTarget`を使います。 ```solidity contract ContextTarget { address public lastSender; address public lastOrigin; bool public senderEqualsOrigin; function capture() external { lastSender = msg.sender; lastOrigin = tx.origin; senderEqualsOrigin = msg.sender == tx.origin; } } contract DelegatedAccount { uint256 public number; address public executionAddress; function setNumberAndCapture(uint256 newNumber, address target) external { require(msg.sender == address(this), "only self"); number = newNumber; executionAddress = address(this); ContextTarget(target).capture(); } } ``` `number`と`executionAddress`は委任先コントラクトに宣言されています。ただし、委任実行時に書き込まれる場所はEOA側です。 ## 委任を設定してEOA自身から呼び出す Foundryの`signAndAttachDelegation`は、指定した秘密鍵で委任許可へ署名し、テスト内の次の取引へ添付します。ここで使う鍵はローカルテスト専用です。 ```solidity vm.signAndAttachDelegation(address(implementation), ALICE_PRIVATE_KEY); require(alice.code.length == 23, "delegation indicator must be 23 bytes"); vm.prank(alice, alice); DelegatedAccount(alice).setNumberAndCapture(42, address(target)); ``` この呼び出しでは、取引の開始元と直接の呼び出し元をどちらも`alice`にしています。委任先のコードは動きますが、`address(this)`は実装コントラクトではなく`alice`です。 確認する結果は次の通りです。 ```solidity require(DelegatedAccount(alice).number() == 42); require(DelegatedAccount(alice).executionAddress() == alice); require(implementation.number() == 0); require(target.lastSender() == alice); require(target.lastOrigin() == alice); require(target.senderEqualsOrigin()); ``` | 確認結果 | 意味 | | --- | --- | | `alice.code.length == 23` | EOAへ委任を示す短いコードが設定された | | `DelegatedAccount(alice).number() == 42` | 値はEOA側の保存領域へ書かれた | | `implementation.number() == 0` | 委任先自身の保存領域は変わっていない | | `executionAddress() == alice` | 委任先コードがEOAのアドレスで実行された | | `target.lastSender() == alice` | 次のコントラクトから見る直接の呼び出し元はEOA | | `target.lastOrigin() == alice` | 取引全体の開始元も同じEOA | 最後の2項目が、従来の前提を見直す必要がある理由です。`ContextTarget`は入れ子になった次の呼び出し階層ですが、`msg.sender == tx.origin`が成立しています。 ## `tx.origin`と`msg.sender`の等値だけでは最上位の呼び出しと断定できない EIP-7702以前は、`msg.sender == tx.origin`なら「途中にコントラクトの処理を挟んでいない最初の呼び出し」と考えるコードがありました。 委任されたEOAは、自分の文脈で複数のコントラクトを順番に呼び出せます。そのため、2つ目以降の呼び出し先でも、直接の呼び出し元と取引開始元が同じEOAになる場合があります。 ```solidity require(msg.sender == tx.origin, "contracts not allowed"); ``` この条件だけでは、次のことを証明できません。 - 途中でプログラム可能な処理が動いていない - 1回の取引で前後に別の状態変更が行われない - 再入可能な経路がない - フラッシュローンなどの原子的な一連処理を使っていない ただし、「`msg.sender == tx.origin`を使うすべてのコードが同じ形で壊れる」という意味でもありません。何を保証する目的で比較しているのかを確認し、最上位の呼び出しや再入防止の代わりに使っている場合は修正します。 再入防止には専用のガード、状態更新の順序、必要に応じた一時保存領域など、目的に合った仕組みを使います。 ## 誰がEOAを呼ぶかで`msg.sender`は変わる 委任先のコードがEOAの文脈で動くことと、`msg.sender`が常にEOAになることは別です。 今回のテストは、`alice`が`alice`自身を呼び出しています。そのため、委任先コードの中では次の関係になります。 ```text address(this) = alice msg.sender = alice tx.origin = alice ``` 一方、別の送信者やリレイヤーが`alice`を呼べば、委任先コード内の`msg.sender`はその呼び出し元になります。 ```text address(this) = alice msg.sender = relayer tx.origin = relayer ``` 委任先の関数を誰でも呼べる状態にすると、EOAの残高や保存領域を第三者が操作できる危険があります。実装側で署名、権限、ノンス、期限、呼び出し対象を検証する必要があります。 ## 安全な委任先を確認する7項目 ### 1. 委任先アドレスとコードを確認する 署名対象のアドレスが、監査・検証した実装と一致するか確認します。プロキシ（プロキシ）を使う場合は、実装の変更権限も含めて評価します。 ### 2. 初期化を第三者へ取られないようにする 委任だけを先に設定し、誰でも呼べる初期化関数を後から実行する設計は危険です。初期化を同じ流れで行うか、EOA本人だけが実行できる条件を入れます。 ### 3. 保存領域の配置を固定する 委任先を変更しても、EOA側の保存領域は残ります。新旧実装が同じスロットを違う意味で使わないように、保存領域の設計と移行手順を決めます。 ### 4. 操作署名へ必要な条件を含める 委任先が署名付き操作を受け付ける場合は、少なくともチェーンID、呼び出し先、入力データ、送るETH量、ノンス、期限を署名対象へ含めます。 EIP-712で構造化する場合は、[ドメイン区切り・ノンス・有効期限から署名ダイジェストを検証する手順](/archives/6010)で、クライアントとコントラクトのハッシュが一致すること、別チェーン・別コントラクトでは失敗することまで確認できます。 委任コードを持つアカウントが署名者になる場合のECDSA / コントラクト分岐、ERC-1271マジック値、所有者状態変更は、[ERC-1271でコントラクトアカウント署名を検証する方法](/archives/6011)で確認できます。 ### 5. 2種類のノンスを混同しない EIP-7702の委任許可には、同じ委任署名の再利用を防ぐEOAのノンスがあります。それとは別に、委任先が受け付ける操作署名にも再利用防止のノンスが必要です。 送信順番号の確認方法は[`nonce too low`・置換手数料不足の原因と直し方](/archives/6004)でも説明しています。 ### 6. 失敗後も委任状態を確認する 後続処理が取り消されても（`revert`）、委任設定が残る場合があります。トランザクション全体の調査では、実行結果だけでなくEOAのコードと委任先も確認します。[失敗トランザクションの確認順](/archives/6001)と合わせると切り分けやすくなります。 ### 7. 解除後の保存領域も確認する ゼロアドレスへの委任でコードを解除しても、保存領域は消えません。再委任する前に、残っている権限、ノンス、許可リスト、残高管理の値を確認します。 [同じEOAで委任をAへ設定し、Bへ変更して解除する検証](/archives/6017)では、23バイトコード、ストレージ、アカウントノンス、残高、ERC-20利用許可額を段階ごとに読み、誤ったチェーン・再利用・`revert`も分けています。 委任先から複数呼び出しを実行する場合は、ウォレットへ一括処理を依頼するEIP-5792と、アカウント内で呼び出し列を実行するERC-7821を分けます。[`wallet_sendCalls`とERC-7821の実装・検証](/archives/6014)では、EIP-7702自己呼び出しを含む経路、アトミック実行の要件、途中の`revert`、最終状態を同じローカル条件で確認しています。 ブラウザーに複数の注入型ウォレットがある場合は、委任を確認する前に、どのプロバイダーへ要求するかを固定します。[EIP-6963で複数ウォレットを検出・選択する実装](/archives/6015)では、`window.ethereum`の競合、プロバイダーのメタデータの境界、選択切替時のリスナーの後片付けを模擬で確認できます。 端末のPasskeyをアカウント署名へ使う場合は、生体情報ではなくWebAuthn認証結果を検証します。[PasskeyスマートアカウントのWebAuthn・P-256検証](/archives/6016)で、チャレンジ、オリジン、RP IDハッシュ、EIP-7951、ERC-1271、復旧を同じ公開検証入力例から確認できます。 ## まとめ EIP-7702では、EOAへ実装コントラクトの全コードをコピーするのではなく、委任先を示す23バイトの案内を設定します。 その結果、**アドレス、残高、保存領域はEOAのものを使い、関数のロジックだけを委任先から取得する**形になります。 Foundryのテストでは、値がEOA側へ保存され、委任先自身の保存領域は変わらないことを確認できました。また、委任されたEOAが別のコントラクトを呼ぶと、入れ子の階層でも`msg.sender == tx.origin`が成立する場合があります。 実装を確認するときは、委任先コードだけでなく、初期化、保存領域、操作署名、2種類のノンス、失敗後の委任状態、解除後に残るデータまで確認してください。 ## 確認した一次情報 - [EIP-7702 Set Code for EOAs](): 確認日 2026-08-28 - [Ethereum Foundation Pectra Mainnet Announcement](): 確認日 2026-08-28 - [Foundry signDelegation](): 確認日 2026-08-28 - [Foundry v1.8.0](): 確認日 2026-08-28 - [Solidity 0.8.36](): 確認日 2026-08-28 --- # MetaMaskの利用上限（Spending cap）とは？approve・revoke・Permitを安全に確認 MetaMaskの利用上限（Spending cap）とERC-20のapprove、利用許可額、revoke、Permitを区別し、トークン・利用先・数量・チェーンを確認する手順です。 正規URL: https://3mikan.com/archives/6007 著者: みかん 公開: 2026-08-28T12:40:00.000Z 更新: 2026-09-02T05:35:00.000Z MetaMaskに`Spending cap request`と表示されたら、送金額だけを見る画面ではありません。多くの場合は、**特定のトークンを、特定の利用先が、いくらまで使えるか**をERC-20トークンコントラクトへ記録する`approve`の確認画面です。 先に記録するのは、アカウント、チェーン、トークンコントラクト、利用先、数量の5項目です。サイト名やボタン名だけでは、この5項目を確定できません。 > DAppのDisconnectと取り消しは別 > > Disconnectはサイトからアカウント情報を切り離す操作です。すでにチェーン上へ記録された利用許可額は消えません。トークンを動かす権限を止めるには、対象の利用許可額を別に確認して取り消しします。 この記事ではERC-20のトークンの利用許可を対象に、署名前、既存権限の確認、取り消し後の確認までを順に整理します。コントラクトアドレスやABIから確認したい場合は、先に[直コンの安全確認手順](/archives/1005)を参照してください。 ## 利用許可・Spending上限・利用許可額・取り消しの違い | 表示・用語 | 何を指すか | 確認する場所 | | --- | --- | --- | | 利用許可 / `approve` | 利用先へ利用上限を設定するチェーン上トランザクション | ウォレットの関数詳細、トークンコントラクト、実行結果 | | Spending上限 | MetaMaskが表示する利用上限。通常は`approve`の数量に対応する | MetaMaskのEstimated変更、Spender、Method | | 利用許可額 | トークンコントラクトが保持する`owner → spender`の残り上限 | `allowance(owner, spender)`、Approval Checker | | 取り消し | 同じトークン・利用先の上限を0などへ更新するチェーン上トランザクション | 取り消し画面、実行結果、更新後の利用許可額 | [ERC-20](https://eips.ethereum.org/EIPS/eip-20)では、`approve(spender, value)`を再度実行すると、その所有者・利用先の利用許可額を`value`へ更新します。利用先は`transferFrom`を使い、利用許可額の範囲で所有者のトークンを移動できます。 ![所有者がトークンコントラクトへapproveを送り、利用先が利用許可額の範囲でtransferFromを実行し、取り消しで同じ組み合わせを0へ更新する図](/diagrams/token-approvals/6007-owner-token-spender.svg) 利用許可は「サイト全体への包括的な許可」ではありません。少なくとも次の組み合わせごとに別の状態です。 ```text chain + token contract + owner + spender = allowance ``` 同じDAppでもルーターのバージョンやチェーンが変われば利用先は別アドレスになり得ます。反対に、画面上のサイト名が違っても、共通の利用先コントラクトを使う場合があります。 ## 署名前に固定する5項目 ### 1. アカウント 利用許可を出す所有者アカウントです。複数アカウントを使っている場合、別アカウントの利用許可額を見ても署名対象の確認にはなりません。 ### 2. チェーン Ethereum、Base、Arbitrumなど、現在のネットワークを記録します。同じ形式のアドレスでも、チェーンが違えば別の状態です。取り消しに必要なネットワーク手数料用のネイティブトークンもチェーンごとに異なります。 ### 3. トークンコントラクト トークン名やシンボルだけでなくコントラクトアドレスを確認します。偽トークンや同名トークンを避けるため、プロジェクト公式資料とブロックエクスプローラーの両方で照合します。 ### 4. 利用先 実際に`transferFrom`を呼べるアドレスです。DAppのドメイン、トランザクションの`to`、利用先は同じとは限りません。通常のERC-20 `approve`では、トランザクションの`to`はトークンコントラクト、呼び出しデータの引数が利用先です。 ### 5. 数量 人が読むトークン数量と、`decimals()`を反映した未加工値を分けます。`Max`やサイト提案値が、今使う予定量と同じとは限りません。 関数と引数をさらに確認する場合は、[ABI・呼び出しデータ・イベントログの読み方](/archives/6005)で`to`と引数を分けてください。 ## MetaMaskのSpending上限要求を読む
MetaMask公式HelpのSepoliaサンプルでSpending上限、Spender、Request送信元、Interacting with、Method Approveが表示された確認画面
MetaMask公式HelpのExtensionサンプル。Sepoliaの説明用アカウントで、Spending上限、Spender、Methodが分かれて表示されています。3MIKANのウォレットを接続した画面ではありません。
画面では、少なくとも次を照合します。 - 上部のアカウントとネットワーク - `Spending cap`の数量 - `Spender`のアドレス - `Request from`のドメイン - `Interacting with`のトークンコントラクト - `Method`が`Approve`か - Estimated変更やセキュリティ警告 `Request from`は「どのWebサイトが要求を開いたか」の手掛かりです。権限を持つ主体は、チェーン上の利用先アドレスで確認します。ドメインが正しく見えても、利用先のコードや更新権限まで安全と証明するものではありません。 ## 無制限利用許可は即時被害ではないが、将来残高も範囲に入る ブロックエクスプローラーやウォレットが`Unlimited`と表示する利用許可は、非常に大きな上限を設定している状態です。承認した瞬間にトークンが移動するとは限りませんが、利用先が呼び出せる状態なら、新しい署名なしで利用許可額の範囲を利用できます。 リスクを判断するときは、現在残高だけでなく次を確認します。 - 今後同じアドレスへ入るトークンも対象になり得るか - 利用先がプロキシか、実装を変更できるか - DAppを今も使うか - 必要量に対して上限が過大ではないか - 利用許可額に期限がある仕組みか - トークン・利用先の両方を公式情報で照合できるか 無制限利用許可は正規DAppでも使われます。一方で、利用先の脆弱性、鍵の侵害、悪意ある更新があれば影響範囲が大きくなります。「Unlimitedだから詐欺」「有名DAppだから無条件に安全」のどちらにも決めつけません。 ## 既存利用許可額をPortfolioとブロックエクスプローラーで確認する MetaMask PortfolioのSpending Caps画面では、トークン、アカウント、利用先、Spending Capを同じ行で確認し、対象ごとにRevokeへ進めます。
MetaMask公式HelpのPortfolio Spending Caps画面でUSDC、アカウント、利用先、10 USDCの上限、Revokeボタンが並ぶサンプル
MetaMask公式HelpのPortfolioサンプル。対応ネットワークや画面配置は変更される場合があるため、実際のチェーン識別子とアカウントを確認してください。
ブロックエクスプローラーのApproval Checkerは、ウォレットを接続しなくても公開アドレスを検索できます。読み取りだけなら署名は不要です。
Etherscan Token Approval Checkerで公式寄付アドレスのトランザクションハッシュ、資産、承認済み利用先、元利用許可額が表示された公開画面
2026年8月28日のEtherscan公開画面。Etherscanサイト下部に掲載された寄付アドレスを読み取り専用検索した例で、3MIKANのウォレットは接続していません。金額や利用許可件数は撮影時点の表示です。
一覧では、表示名だけでなく次を記録します。 1. チェーンと所有者アドレス 2. トークンコントラクト 3. 承認済み利用先アドレス 4. 現在利用許可額と元利用許可額の区別 5. 最後に更新したトランザクションハッシュと時刻 6. 利用先の検証、プロキシ、現在の実装 ブロックエクスプローラーの名前タグは便利ですが、それだけで公式性や安全性は確定しません。プロジェクト公式資料のアドレスと照合します。 ## 取り消しは同じトークン・利用先の利用許可額を更新する 通常のERC-20では、取り消しUIが`approve(spender, 0)`を送る形が一般的です。実行前後を次の順で確認します。 1. 対象アカウントとチェーンを固定する 2. トークンコントラクトと正確な利用先を記録する 3. 現在の`allowance(owner, spender)`を読む 4. 取り消しの呼び出しが同じトークン・利用先と0を対象にしているか確認する 5. ネットワーク手数料とシミュレーション結果を確認する 6. 署名・送信後に実行結果の`status`を見る 7. 更新後の`allowance(owner, spender)`を読み、0になったか確認する 現在値は次のように読み取り専用で確認できます。 ```ts import { erc20Abi, formatUnits } from 'viem' const [allowance, decimals] = await Promise.all([ publicClient.readContract({ address: token, abi: erc20Abi, functionName: 'allowance', args: [owner, spender], }), publicClient.readContract({ address: token, abi: erc20Abi, functionName: 'decimals', }), ]) console.log({ chainId: await publicClient.getChainId(), token, owner, spender, rawAllowance: allowance.toString(), displayAllowance: formatUnits(allowance, decimals), }) ``` この読み取りは取り消しトランザクションを送りません。実際に書き込む場合は、トークン固有の実装、0へ変更してから別数量へ更新する必要性、プロキシの現在ABIも確認します。シミュレーションが成功しても、コントラクトの安全性や本番成功を保証しません。 実行結果の確認は[実行結果・呼び出しデータ・ログを追う手順](/archives/6001)へ進みます。取り消しが保留中・失敗・置換済みのどれか分からない場合は、[トランザクション状態の判定フロー](/archives/6004)で元ハッシュと置換後のハッシュの両方を残してください。 ## 取り消しが反映されないときの確認順 | 症状 | 最初に確認すること | 次に見る証拠 | | --- | --- | --- | | Revokeボタンを押せない | ウォレット接続、アカウント、チェーン、ネイティブトークン残高 | 対応ネットワーク、ウォレットのエラー | | 送信したが一覧に残る | 実行結果.状態、ブロック、トランザクションハッシュ | 索引遅延を避けて`allowance`を直接読む | | 利用許可額が0にならない | トークン、所有者、利用先の組み合わせ | 呼び出しデータ、Approvalイベント、別利用先 | | トランザクションが保留中 | ノンス、ガス、同じノンスの別ハッシュ | 保留中 / 置換済み / 破棄候補を分ける | | トランザクションが失敗 | `revert`の理由、トークン固有制約 | シミュレーション、現在実装 | | DAppをDisconnectしたのに残る | Disconnectと取り消しの取り違え | チェーン上利用許可額を確認する | | 1件消しても権限が見える | ルーターやバージョンごとの複数利用先 | すべてのトークン・利用先行を確認する | Revokeは将来の利用上限を変える操作です。すでに移動したトークンを取り戻す処理ではありません。被害が疑われる場合は、追加署名を止め、ハッシュ、署名要求、トークン、利用先、時刻を保存します。 不審な操作履歴が利用許可だけなのか、シード / 秘密鍵、Permit、DAppセッション、委任、端末まで疑うべきなのか分からない場合は、変更前の証拠を保存して[ウォレット侵害時の7層初動ガイド](/archives/6026)から切り分けてください。 EIP-7702アカウントの委任をゼロアドレスで解除しても、トークンコントラクト側の利用許可額は自動で0になりません。[委任の設定・変更・解除後に残る状態の検証](/archives/6017)で、アカウントコードと外部利用許可を別々に確認できます。 ## PermitとPermit2は通常の`approve`と分ける ガス手数料が表示されない署名でも、トークン利用権限に関係する場合があります。 | 方式 | 署名・トランザクション | 確認する主な値 | | --- | --- | --- | | ERC-20 `approve` | 所有者がトークンコントラクトへチェーン上トランザクション | チェーン、トークン、利用先、値 | | ERC-2612 `permit` | 所有者がEIP-712型付きデータへ署名し、別アカウントでもトークンコントラクトへ提出可能 | ドメイン、`chainId`、`verifyingContract`、所有者、利用先、値、ノンス、有効期限 | | Permit2 AllowanceTransfer | トークンからPermit2への利用許可に加え、指定利用先・数量・失効時刻の権限 | トークン、Permit2アドレス、後段利用先、数量、失効時刻、ノンス | | Permit2 SignatureTransfer | 署名を使う1回の送金。Uniswap実装では使用トランザクションの間だけ有効 | トークン、数量、利用先、ノンス、有効期限。受取先などを拘束する証明データの有無 | [ERC-2612](https://eips.ethereum.org/EIPS/eip-2612)の許可は、署名が正しく、ノンスと有効期限が条件を満たすと利用許可額を更新します。トークンがERC-2612を実装しているか、同名の独自許可ではないかも確認が必要です。 [Permit2](https://github.com/Uniswap/permit2)は`AllowanceTransfer`と`SignatureTransfer`を持ちます。統合前には、トークン側からPermit2コントラクトへ利用許可する層もあります。そのため、通常のApproval Checkerで利用先がPermit2と表示されても、実際のDApp側利用先や署名の期限まで一行で分かるとは限りません。 署名だけでチェーン上にトランザクションが残らない場合もあります。署名画面では、少なくともドメイン、検証コントラクト、利用先、トークン、数量、ノンス、有効期限を読み、理解できない型付きデータは拒否します。 これらの項目が最終ダイジェストへどう入るか、ノンス再利用・期限切れ・別チェーン・別コントラクトをどう拒否するかは、[EIP-712署名のドメイン・ノンス・有効期限検証](/archives/6010)でローカルコードと一緒に確認できます。 開発者向けに、ERC-2612の提出有効期限と作成後利用許可額、Permit2の二層権限、ERC-7674のトランザクション境界まで比較する場合は、[`approve`・Permit・Permit2・ERC-7674の実装比較](/archives/6012)を参照してください。 ウォレットの接続済みサイト、SIWEセッション、ERC-20 / Permit2、スマートアカウントモジュール、EIP-7702委任を一つの調査で洗い出す場合は、[DApp切断と各権限の失効を保存場所から比較する手順](/archives/6031)へ進んでください。切断で変わる層とチェーン上トランザクションが必要な層を分けています。 突然開いたウォレット確認画面を`eth_sign`、`personal_sign`、EIP-712、SIWE、Permit、EIP-7702へ分け、署名せず止まる判断から確認する場合は、[ウォレット署名要求の見分け方と9項目チェックリスト](/archives/6025)へ進んでください。 ## 最終チェックリスト - [ ] 署名アカウントとチェーンを確認した - [ ] トークン名ではなくコントラクトアドレスを照合した - [ ] DAppのドメインと利用先アドレスを分けた - [ ] Spending上限の人間向け数量と未加工値を確認した - [ ] Maxやサイト提案値をそのまま選んでいない - [ ] 無制限利用許可の対象トークンと将来残高を確認した - [ ] Disconnectと取り消しを混同していない - [ ] 取り消し前の利用許可額を記録した - [ ] 取り消しトランザクションのトークン、利用先、0、手数料を確認した - [ ] 実行結果成功後に利用許可額を読み直した - [ ] Permitならドメイン、ノンス、有効期限を確認した - [ ] Permit2ならトークン→Permit2とPermit2→利用先の層を分けた 最短の確認方法は、画面の「Approve」「Revoke」という動詞を信じ切ることではありません。**チェーン、トークン、所有者、利用先、利用許可額を同じ組み合わせで署名前後に読み直すこと**です。 ## 確認した一次情報 - [MetaMask What is a token approval](): 確認日 2026-08-28 - [MetaMask Customize token approvals](): 確認日 2026-08-28 - [MetaMask Portfolio Spending Caps](): 確認日 2026-08-28 - [MetaMask Revoke token approvals](): 確認日 2026-08-28 - [MetaMask Signature phishing](): 確認日 2026-08-28 - [ERC-20 Token Standard](): 確認日 2026-08-28 - [ERC-2612 Permit Extension](): 確認日 2026-08-28 - [Uniswap Permit2](): 確認日 2026-08-28 - [Etherscan Token Approvals](): 確認日 2026-08-28 - [Etherscan Safe Contract Interaction](): 確認日 2026-08-28 --- # 取引所への入金が反映されないときの確認手順｜TxID・承認数・メモ 取引所への暗号資産入金が反映されない原因を、TxID、チェーン上の状態、承認数、ネットワーク、アドレス、メモ・タグ、最低入金額、取引所の状態に分けて確認します。 正規URL: https://3mikan.com/archives/6008 著者: みかん 公開: 2026-08-28T13:25:00.000Z 更新: 2026-09-02T05:35:00.000Z ウォレットや送信元取引所に「完了」と表示されても、受取取引所の残高へすぐ反映されるとは限りません。先に、**チェーン上のトランザクション**と**取引所内の入金処理**を別の状態として確認します。 最初に保存するのは、TxID、資産、ネットワーク、入金アドレス、数量、Memo・Tag、確認時刻です。画面を更新する前にテキストで記録し、同じ送金を推測だけで再実行しないでください。 > 追加送金より先に証拠を保存 > > 未反映の原因が分からないまま少額を追加送金しても、誤ネットワークやMemo漏れを繰り返す可能性があります。秘密鍵、シードフレーズ、パスワード、2段階認証コード、API秘密情報は、取引所サポートにも共有しません。 MetaMask側で保留中・失敗・置換済みを判定する場合は、先に[トランザクション状態の確認フロー](/archives/6004)を使ってください。送金操作全体は[MetaMaskの送金が反映されないときの確認](/archives/3708)へ分けています。 ## 結論：5段階を順番に分ける ![TxID、チェーン上の状態、承認数、入金条件、取引所状態を順に確認して残高反映までを分ける図](/diagrams/deposit-troubleshooting/6008-deposit-flow.svg) | 段階 | 確認する証拠 | 次の判断 | | --- | --- | --- | | 1. 送信元 | TxIDが発行されたか | 未発行なら、チェーンへ送信されていない可能性を送信元で確認 | | 2. チェーン | ブロックエクスプローラーの状態、ブロック、実行結果 | 保留中・失敗・成功を分ける | | 3. 確定度 | 承認数、確定性、取引所の必要条件 | 現在の承認数と取引所の必要承認数を混同しない | | 4. 入金条件 | 資産、ネットワーク、アドレス、Memo・Tag、最低、入金停止 | 送金内容と現在の入金画面を照合 | | 5. 取引所 | 未検出、処理中、審査中、残高反映済み | チェーンではなく取引所内の処理として追う | チェーンで`Success`でも、取引所がその入金を検知し、アカウントへ割り当て、審査し、残高へ計上したことまでは証明しません。 ## 最初に記録する8項目 ```text 確認日時とタイムゾーン 資産名とトークンコントラクト（トークンの場合） ネットワーク / チェーン TxID / トランザクションハッシュ 送信元アドレス 入金アドレス 数量（ネットワーク手数料控除後も確認） Memo / Tag / Messageと取引所履歴の状態 ``` TxIDと取引所の受付番号は同じとは限りません。たとえば[bitFlyerの現行FAQ](https://bitflyer.com/ja-jp/faq/5-9)では、ログイン後の「お取引レポート」から入出金のTXIDを確認する案内があります。送信元の「注文ID」「出庫申請ID」しかない場合は、ネットワークへ送信済みかを送信元サービスで確認します。 アドレスやTxIDは公開チェーン上の情報ですが、アカウント名、メール、残高、QRコードを含む画面を公開投稿しないでください。サポートへ提出する場合も、取引所の公式ドメインにある安全な問い合わせ画面だけを使います。 ## 1. TxIDを正しいブロックエクスプローラーで検索する TxIDがある場合、送ったネットワークに対応する公式または信頼できるブロックエクスプローラーで検索します。Ethereumのハッシュを別チェーンのブロックエクスプローラーへ貼り、`not found`だけで未送信と判断しないでください。 | ブロックエクスプローラーの表示 | チェーン上の意味 | 取引所側で見る前にすること | | --- | --- | --- | | 未検出 | 別チェーン、未ネットワークへの送信、索引遅延、破棄候補など | ネットワーク、送信元履歴、複数の観測元を確認 | | 保留中 | まだブロックへ含まれていない観測 | 実行結果が出るまで元ハッシュを追う | | 失敗 / `reverted` | ブロックへ含まれたが処理失敗 | EVMでは状態変更は`revert`。受取側未反映とは分ける | | 成功 | ブロックへ含まれ、実行結果が成功 | `to`、トークン送金、数量、確定数へ進む | EVMのトークン送金では、トランザクションの`to`がトークンコントラクトや別コントラクトになる場合があります。ブロックエクスプローラーの`Success`だけでなく、Transferログのトークンコントラクト、送信元、送信先、数量を照合します。実行結果とログの読み方は[失敗トランザクションを解析する手順](/archives/6001)で確認できます。 正しい受取先へTransfer済みなのにウォレット一覧だけへ出ない場合は、[チェーン・コントラクト・`balanceOf`・小数桁からトークン表示を確認する手順](/archives/6029)へ進みます。
Etherscanの公開トランザクション詳細でStatus Success、ブロック番号、7265 Block Confirmations、タイムスタンプが表示された部分
2026年8月28日のEtherscan公開画面。公式サイト下部に掲載された寄付アドレスへの公開トランザクションを読み取り専用で確認し、ハッシュ、アドレス、残高を含まない部分だけを掲載しています。7265承認数は撮影時点の値で、現在値ではありません。
## 2. 承認数と確定性を取引所の必要承認数から分ける ethereum.orgのトランザクションライフサイクル資料では、トランザクションはプールからブロックへ入り、そのブロックが`justified`、確定済みへ進みます。ブロックエクスプローラーの承認数は、トランザクションを含むブロックの後ろへブロックが積み重なった深さを表す表示です。プロトコルの確定性や、取引所が残高反映に使う必要承認数とは同じ用語ではありません。 EVM RPCで現在のブロック深度を読む例は次のとおりです。 ```ts const [receipt, latestBlock] = await Promise.all([ publicClient.getTransactionReceipt({ hash }), publicClient.getBlockNumber(), ]) const blockDepth = latestBlock >= receipt.blockNumber ? latestBlock - receipt.blockNumber + 1n : 0n console.table({ status: receipt.status, transactionBlock: receipt.blockNumber, latestBlock, blockDepth, }) ``` これは選択したEVM RPCから見た現在のブロック深度です。取引所の必要承認数、Ethereumの確定済み判定、別チェーンの確定条件を置き換えません。 L2一括処理のBlobを追う場合は実行ブロックだけでなくBeaconスロットとデータ保存期間も関係します。[Fusaka・PeerDASとL2手数料の解説](/archives/6023)で、確定済みブロック、バージョン付きハッシュ、サイドカーを別の証拠として確認できます。 取引所へ入る前のブリッジ区間が止まっている場合は、チェーン承認数と取引所状態を調べる前に、[ブリッジの送信元トランザクション、メッセージ、送信先を分ける手順](/archives/6027)で送信先トランザクションが存在するか確認します。 [bitFlyerの暗号資産預入FAQ](https://bitflyer.com/ja-jp/faq/send_bitcoin)は、一定数以上の承認後に手続きし、必要承認回数を変更する可能性や、安全確認で遅れる場合があると案内しています。[Krakenの処理時間](https://support.kraken.com/articles/203325283-cryptocurrency-deposit-processing-times)も資産ごとに必要承認数と推定時間を分けています。 そのため、「平均ブロック時間 × 必要承認数」を到着保証にしません。次の3つを確認日時付きで記録します。 1. ブロックエクスプローラーの現在承認数または確定性 2. 取引所が**現在の資産・ネットワーク**に示す必要条件 3. 取引所入金履歴の現在の状態 ## 3. 資産・ネットワーク・アドレスを現在の入金画面と照合する 同じティッカーシンボルや同じ`0x`形式でも、資産とネットワークの組み合わせが違えば取引所が受け付けるとは限りません。`ERC-20`はトークン規格であり、すべてのEVMネットワークを受け付けるという意味ではありません。 | 項目 | 照合する内容 | 未反映につながる例 | | --- | --- | --- | | 資産 | トークン名だけでなくコントラクトアドレス | 同名トークン、旧コントラクト、非対応資産 | | ネットワーク | 送信チェーンと入金画面の対応ネットワーク | Ethereum向けへ別EVMチェーンから送信 | | アドレス | 送信時の`to`と、発行された入金アドレス | 古いアドレス、別資産のアドレス、入力違い | | 送金形式 | ネイティブ送金、トークン送金、コントラクト経由への対応 | 取引所が特定の入金形式へ非対応 | | 入金受付 | 入金有効、メンテナンス、取扱終了 | 受付停止中に送信 | [Coincheckの現行受取FAQ](https://faq.coincheck.com/answer/685bcc1ed6e3ed45acbe6324/)は、資産ごとに対応ネットワークを示し、異なるチェーンでは残高反映や変換に対応できない場合があると説明しています。同じページでも対応資産やネットワークは変更されるため、過去のスクリーンショットではなく送信時と確認時の入金画面を保存します。 誤ネットワークでも、取引所が秘密鍵を管理するアドレスなのか、対象チェーンと資産を技術的・運用上扱えるのかで状況が変わります。[誤ったネットワーク・アドレスの確認順](/archives/6009)で送信チェーンと管理主体を固定し、回収可否、手数料、所要時間を外部記事だけで断定せず、追加送金を止めて公式サポートへ確認します。 過去の入金先を再利用するときも、ウォレットやブロックエクスプローラーの履歴からアドレスをコピーしません。[似た送金履歴・ゼロ送金・クリップボード差し替えの確認手順](/archives/6056)に沿って、取引所の現在の入金画面を確認元にし、チェーンとアドレス全文を貼り付け後まで照合してください。 ## 4. Memo・Tag・Messageはアドレスとは別の割当情報 取引所が一つの受取アドレスを複数アカウントで使うチェーンでは、Memo、Destination Tag、Messageなどをアカウントの識別に使う場合があります。 XRP Ledgerの公式資料は、Destination Tagを、取引所などが入金をどの利用者へ割り当てるか示す情報として説明しています。Tagはアドレスの一部と決めつけず、トランザクションに記録された値と取引所が発行した値を照合します。 2026年8月28日に確認したCoincheckの受取FAQでは、XRPに宛先Tag、XLMにMemoなど、資産別の追加項目が示されています。必要項目は取引所・資産・ネットワークで異なるため、「XRPなら常に同じTag」「以前使ったMemoを再利用」と一般化しません。 Memo・Tagを忘れた、または値が違う場合は、次を保存して公式サポートの案内へ進みます。 - TxIDとブロックエクスプローラー URL - 送信先アドレス - トランザクションに記録されたMemo・Tagの有無と値 - 取引所がその入金用に発行したMemo・Tag - 資産、ネットワーク、数量、送信日時 返還やアカウントへの割当が可能とは限りません。SNSの返信や検索広告にある「復旧サポート」へ秘密鍵や追加送金を渡さないでください。 ## 5. 最低入金と受取数量を確認する 最低入金額は、送信元で入力した数量ではなく、取引所が対象ネットワークで認識する受取数量を基準にする場合があります。送信手数料が差し引かれるサービスでは、受取額が最低を下回る可能性も確認します。 [Krakenの手数料と最低額](https://support.kraken.com/articles/360000292886-cryptocurrency-deposit-fees-and-minimums)は、資産ごとに最低が異なり、ネットワーク手数料控除後の数量を確認するよう案内しています。同ページの条件を他取引所へ当てはめず、送信した取引所の資産・ネットワーク別条件を確認してください。 最低未満の入金を後から別入金と合算するか、保留するか、反映しないかはサービスごとに異なります。「追加送金すれば必ず合算される」と推測しません。 ## 6. 取引所の入金状態をチェーン上の状態と分ける 取引所履歴に表示があれば、少なくとも取引所システムが入金候補を検知した手掛かりになります。ただし、`Processing`、`Credited`、`Successful`、`On hold`などの意味はサービスごとに異なります。
Kraken公式Helpの入金状態表でPending Processing、Credited、Successful、On保留の意味と対応が並ぶ画面
2026年8月28日に確認したKraken公式Help。ページの最終更新日は2026年5月5日で、Kraken内の状態定義です。他取引所へ同じ意味を当てはめないでください。アカウントへログインせず公開Helpだけを確認しました。
Krakenの例では、`Pending/Processing`はネットワークで承認待ち中、`Credited`は取引に使えても出金はまだ使えない段階、`On hold`はサポートによる個別確認が必要な状態です。すべての資産が同じ遷移を通るわけではないとも明記されています。 国内取引所でも、チェーン確定後に送金元情報の登録や審査が入る場合があります。Coincheckの現行FAQでは、未反映入金の送金元情報を登録し、審査後に受取完了へ進む流れが案内されています。チェーン上で成功していても、取引所画面の「要回答」「審査中」「メールをご確認ください」を見落とさないでください。 ## 状態別の確認先 | 現在の状態 | 次に確認すること | 避けること | | --- | --- | --- | | TxIDがない | 送信元の出庫状態、ネットワークへの送信有無 | 同じ送金を即時に繰り返す | | ブロックエクスプローラーで未検出 | チェーン、ハッシュ、送信元、別RPC・ブロックエクスプローラー | 未検出だけで資産消失と断定 | | 保留中 | ブロック未収録、手数料条件、ネットワーク混雑 | 確定済みと思って取引所へだけ問い合わせる | | 失敗 / `reverted` | 実行結果、エラー、送信元残高、手数料 | 受取取引所の残高反映待ちと扱う | | 成功・必要承認数未満 | 現在の承認数と取引所の現行条件 | 固定時刻で到着を保証する | | 成功・必要承認数到達・履歴なし | 資産、ネットワーク、アドレス、Memo・Tag、最低入金額、受付状態 | 回収を約束する非公式窓口へ連絡 | | 取引所で処理中 | 取引所状態、更新時刻、メンテナンス | チェーン上のトランザクションを再送する | | 取引所で保留・要回答 | 公式画面の必要情報、サポート問い合わせ番号 | 公開SNSへアカウント情報を投稿する | ## 問い合わせ前に用意する証拠 取引所へ問い合わせる場合は、次を一つのメモへまとめます。 1. 資産名、トークンコントラクト、ネットワーク 2. TxIDと対応ブロックエクスプローラー URL 3. ブロックエクスプローラーの状態、ブロック、承認数または確定性、確認日時 4. 送信元アドレスと入金アドレス 5. 送信数量、受取数量、ネットワーク手数料 6. Memo・Tag・Messageの有無と値 7. 送信元サービスの出庫IDと状態 8. 取引所の入金履歴状態と最終更新時刻 9. 送信時に表示されていた最低、対応ネットワーク、メンテナンス情報 スクリーンショットは、アカウント名、メール、残高、他の履歴、QRコードをマスクします。公式の安全な問い合わせ画面で必要とされた場合だけ、該当トランザクションの全体アドレスを提出します。 サポート担当者が必要とするのはトランザクションを特定する証拠です。シードフレーズ、秘密鍵、パスワード、2段階認証コード、遠隔操作、追加送金は必要ありません。 ## 最終チェックリスト - [ ] TxIDと送信元の出庫IDを分けた - [ ] 正しいチェーンのブロックエクスプローラーで状態とブロックを確認した - [ ] トークン送金のコントラクト、送信先、数量を確認した - [ ] 現在の承認数と取引所の必要承認数を分けた - [ ] 資産とネットワークを現在の入金画面で照合した - [ ] 入金アドレスを送信時のトランザクションと照合した - [ ] Memo・Tag・Messageの必要性と実際の値を確認した - [ ] 最低入金と手数料控除後の数量を確認した - [ ] 入金停止、メンテナンス、審査・要回答を確認した - [ ] 公式サポート用の証拠を保存した - [ ] 秘密鍵や認証情報を共有していない 最短の確認方法は、「送信済み」「Success」「Processing」という一つの表示だけで待つことではありません。**TxID、チェーン上の状態、承認数、入金条件、取引所状態を同じ時刻で記録すること**です。 ## 確認した一次情報 - [ethereum.org Transactions](): 確認日 2026-08-28 - [ethereum.org Proof-of-Stake finality](): 確認日 2026-08-28 - [XRP Ledger Source and Destination Tags](): 確認日 2026-08-28 - [Coincheck 暗号資産を受け取る方法](): 確認日 2026-08-28 - [bitFlyer 暗号資産の預入・送付](): 確認日 2026-08-28 - [bitFlyer トランザクションIDの確認方法](): 確認日 2026-08-28 - [Kraken Cryptocurrency deposit statuses](): 確認日 2026-08-28 - [Kraken Cryptocurrency deposit processing times](): 確認日 2026-08-28 - [Kraken Cryptocurrency deposit fees and minimums](): 確認日 2026-08-28 - [Etherscan public transaction example](): 確認日 2026-08-28 --- # 誤ったネットワーク・アドレスへ送金したときの確認順 暗号資産の誤送金を疑ったとき、トランザクションハッシュ、状態、チェーンID、送金先、トークンコントラクト、管理主体を確認し、自己管理・取引所・第三者・コントラクトごとの境界を整理します。 正規URL: https://3mikan.com/archives/6009 著者: みかん 公開: 2026-08-28T17:35:00.000Z 更新: 2026-09-02T05:35:00.000Z 誤ったネットワークやアドレスへ送ったかもしれない。そう思ったら、**追加送金、ブリッジ、知らないネットワークの追加、回収代行への連絡をいったん止めます。** 最初にするのは、トランザクションハッシュと送信したチェーンを固定することです。 同じ`0x`から始まるアドレスでも、Ethereum、Base、Arbitrum、BNB Smart Chainなどの状態は別です。一方で、別ネットワークに見えても同じ秘密鍵で管理するEOAアドレスなら、送ったチェーン上で残高を確認できる場合があります。アドレスの形だけで「紛失」「回収可能」のどちらにも決められません。 この記事は、個別の資産回収を保証しません。ウォレット接続、署名、トランザクション、ブリッジ、追加送金は行わず、読み取り専用の証拠から確認先を分けます。 まだ署名・ネットワークへの送信前で、履歴に似たアドレスやゼロ値送金が見えている場合は、履歴から受取先を選ばず[アドレスポイズニングとクリップボード差し替えの送金前確認](/archives/6056)へ戻ってください。 ## 結論：状態 → チェーン → 送金先の管理主体
誤送金を疑ったときにトランザクションの状態、送信チェーン、送金先の管理主体、資産の証拠、次の確認先へ進む5段階フロー
| 現在の状態 | チェーン上で分かること | 次に見る場所 | | --- | --- | --- | | ネットワークへの送信前 | チェーン上のトランザクションはまだない | 署名前画面のチェーン、送信先、資産、数量を再確認して止める | | 保留中 | その観測元では未確定。元ハッシュが確定・置換される可能性がある | 実行結果、送信元、ノンス、置換後のハッシュ | | 確定済み・失敗 | ブロックには入ったがEVMの状態変更は`revert`。ネットワーク手数料は使われ得る | 実行結果、失敗データ、同一ノンスの別ハッシュ | | 確定済み・成功 | 送ったチェーンで状態変更が成功 | ネイティブ送金なら`to`、トークンならTransferログの受取先とコントラクト | `Success`は「意図したネットワーク・相手・トークンへ正しく届いた」という総合判定ではありません。**送ったチェーンで、そのトランザクションの処理が成功した**という証拠です。 保留中、破棄候補、置換済みの詳しい判定は[トランザクション状態の確認フロー](/archives/6004)へ分けています。MetaMaskの送信画面や基本操作から確認する場合は[MetaMaskの送金が反映されないときの確認](/archives/3708)、すでに取引所へ送って残高だけが未反映なら[TxID・承認数・Memoの確認手順](/archives/6008)も使ってください。 ## 最初に保存する10項目 ウォレットの履歴を消したり、同じ送金を繰り返したりする前に、次をテキストで保存します。 ```text 確認日時とタイムゾーン トランザクションハッシュ / TxID（なければ未発行と記録） 送信したネットワーク / チェーンID 意図していたネットワーク / チェーンID 実行結果の状態とブロック番号 送信元アドレス（from） ネイティブ送金の送信先（to）、またはトークンのTransferログにある受取先 資産名と送信したチェーン上のトークンコントラクト 未加工の数量 / 表示数量 送金先の種類と、送信したチェーン上の鍵・アカウントを管理する主体 ``` スクリーンショットだけでなく文字列も残します。ただし、Secret Recovery Phrase、秘密鍵、パスワード、2段階認証コード、QRコード、ウォレット全体の残高は保存・共有しません。 ## 1. ネットワークへの送信前・保留中・確定済みを分ける MetaMaskの公式案内も、誤ったネットワークや誤ったアドレスの前に、トランザクションが確定済みかを確認する順番です。 ### トランザクションハッシュが発行されていない 署名前、シミュレーション失敗、ウォレット内で拒否した状態など、ネットワークへ送信していないならチェーン上の誤送金はまだ成立していません。チェーン、送信先、資産、数量に疑問がある状態で、新しいトランザクションを作らないでください。 ### 保留中 保留中は確定済みではありません。優先処理や取り消しは、同じノンスを使う置換をネットワークへ採用してもらう試みです。元トランザクションが先に確定する場合もあり、成功は保証されません。 MetaMaskの現行Helpでも、取り消しはネットワーク上で保留中の間だけ試せ、確定後は取り消せないと説明しています。本記事では手数料やノンスを手入力する手順へ進まず、元ハッシュ、送信元、送信先、ノンス、観測時刻を保存して[実行結果・ノンスの判定手順](/archives/6004)へ移ります。 ### 確定済み・失敗 EVMの実行結果が`reverted`なら、トランザクションは保留中ではありません。通常、その呼び出しによる状態変更は`revert`しますが、実行に使われたネットワーク手数料は戻らない場合があります。単純な送金とコントラクト呼び出しを混同せず、実行結果とログを保存します。 ### 確定済み・成功 ここから誤ったネットワークと誤ったアドレスを分けます。ネイティブ資産の送金ならトランザクションの`to`と値、ERC-20等のトークンなら対象トークンコントラクトのTransferログにある受取先と数量を見ます。トークン送金ではトランザクションの`to`がトークンコントラクトになり得るため、トランザクション欄だけで受取人を決めません。 ## 2. 誤ったネットワークと誤ったアドレスは別の事故 EIP-155ではチェーンIDをトランザクション署名へ含め、別チェーンで同じトランザクションがそのまま再生されることを防ぐ仕組みが定義されています。**アドレス文字列だけでは、どのチェーンへ送ったか分かりません。** トランザクションハッシュを送信済みチェーンのブロックエクスプローラーで開き、チェーンIDと実行結果を固定します。 | 分類 | 例 | 確認の焦点 | | --- | --- | --- | | 誤ったネットワーク | 受取先文字列は意図どおりだが、Baseへ送る予定をEthereumで送った | 送信済みチェーン上で同じ受取先を誰が管理するか | | 誤ったアドレス | チェーンは意図どおりだが、受取先文字列が別人・別コントラクト | その送信先の管理主体と返送可能性 | | 誤った資産 | チェーンと受取先は合うが、同名の別トークンコントラクトを送った | 送信済みチェーン上のトークンコントラクトとTransferログ | | 表示のみ | チェーン・受取先・資産は合うがウォレット一覧に表示されない | ブロックエクスプローラー上の残高、トークンコントラクト、ウォレットの表示設定 | | 複合 | ネットワークもアドレスも違う、または送金先の管理主体が不明 | 分かった項目だけ記録し`unknown`を残す | 「BEP-20」「ERC-20」という表示だけでも不十分です。トークン規格、送信チェーン、トークンコントラクト、受取サービスの対応ネットワークは別項目です。 ## 3. 誰が送信先を管理するかで境界が変わる
送金先を自己管理、管理サービス、第三者、コントラクトまたは不明に分け、確認先とできないことを示す図
### 自己管理のEOA候補 自分または相手が同じ秘密鍵で送信済みチェーン上のEOAアドレスを管理しているなら、送信済みチェーンのブロックエクスプローラーでそのアドレスと資産残高を確認できる場合があります。MetaMaskの送金先誤り案内も、EVM互換ネットワーク間では同じアドレスを使う例を説明しています。 ただし、次を確認するまで回収可能とは書けません。 - 送信先が本当に同じEOAキーから導出されたアドレスか - ハードウェアウォレット・追加済みキーを含め、受取先が送信済みチェーンで署名権限を持つか - スマートアカウントや未デプロイアドレスではなく、別チェーンでも同じ制御条件か - 送信済みチェーン上に正しいトークンコントラクトと残高があるか - トークン自体に送金制限や悪意ある仕様がないか `0x`形式が同じ、ウォレットへネットワークを追加できた、トークン名が表示された、という事実だけでは署名権限を証明しません。Secret Recovery Phraseを別のウォレットや「復旧ツール」へ入力して確認しないでください。 ### 管理サービス・取引所 入金アドレスの秘密鍵を取引所やサービスが管理している場合、利用者が同じアドレスをウォレットへ追加することはできません。送信済みチェーンと資産をサービスが技術的に扱えても、アカウントへ割り当てるか、返還するか、手数料が必要かはサービスの運用判断です。 次を現在の公式サポートへ提出できる形にします。 1. トランザクションハッシュと送信済みチェーン 2. 実行結果の状態、ブロック、タイムスタンプ 3. 資産名と送信済みチェーン上のトークンコントラクト 4. Transferログの受取先と数量 5. サービスが発行した入金アドレス、Memo・Tag 6. 送信時と確認時の対応ネットワーク表示 7. アカウント内の入出金IDとサポート問い合わせ番号 復旧可否や所要時間を外部記事で断定しません。同じ送金を再実行せず、[取引所入金の確認手順](/archives/6008)でチェーン状態とサービス内処理を分けます。 ブリッジを使った送金なら、送信済みチェーンと送信先チェーンの間にチェーン間メッセージがあります。[ブリッジ未着金の確認手順](/archives/6027)で正規 / 第三者、入金 / 出金、メッセージID、送信先実行結果、トークン対応表を分けてください。 ### 第三者のEOA 意図しない個人・組織が送信先を管理している場合、プロトコルが強制的に返送させる機能はありません。所有者を正当に確認できるなら、返送を依頼する余地はありますが、相手が応じる保証はありません。返送は相手が作る**新しいトランザクション**です。 アドレスから個人情報を推測して公開したり、SNSで資産額をさらしたりしないでください。相手を名乗るDMへ追加送金や秘密情報を渡すことも避けます。 ### コントラクトアドレス・管理主体不明 コントラクトアドレスへネイティブ資産やトークンを送っても、そのコントラクトに返却関数があるとは限りません。検証済みソース、現在実装、管理者・役割、受領したTransferログ、公式プロジェクト情報を読み取り専用で確認します。 関数名が`recoverToken`や`sweep`でも、誰が呼べるか、どのトークンが対象か、プロキシ実装が何かを読まずにWriteしません。[検証済みコントラクト・ABI・シミュレーションの確認順](/archives/1005)は調査方法の参考になりますが、回収手順や成功保証ではありません。 管理主体を分類できない場合は`unknown`のまま止めます。「誰かが鍵を持っているはず」という推測を、回収可能へ読み替えないでください。 ## 4. トークンが見えないだけかを読み取り専用で確認する 確定済み・成功で送信先も自分のアドレスなのにウォレットへトークンが出ない場合、表示設定だけが原因のことがあります。 1. トランザクションハッシュを送信済みチェーンのブロックエクスプローラーで開く 2. Transferログのトークンコントラクト、受取先、未加工数量を確認する 3. 受取先アドレスのトークン残高を送信済みチェーンで確認する 4. プロジェクト公式情報とトークンコントラクトを照合する 5. ウォレットがそのネットワークとトークンを表示できるか公式案内を確認する MetaMaskのトークン表示案内では、自動検出されないトークンをコントラクトアドレスから表示へ追加できます。ただし、**独自トークンの追加は残高の表示設定であり、別チェーンへの移動、トークンの変換、ブリッジではありません。** 偽トークンやエアドロップを表示しても安全性は上がりません。 独自ネットワーク情報も検索広告やDMからコピーしません。チェーンID、RPC、ブロックエクスプローラーをネットワークの公式資料で照合し、追加してもトランザクションを送らず残高だけを確認します。 ## 5. ブリッジは確認ではなく新しい資産移動 送信済みチェーン上で制御と残高を確認できても、意図したチェーンへ移すにはブリッジ等の別トランザクションが必要になる場合があります。これは「表示を直す操作」ではありません。 - ブリッジコントラクト・経路・対応資産・送金先を新たに信頼する - 利用許可や署名が発生し得る - ガス用ネイティブ資産が必要になり得る - ラップ済み資産、正規資産、第三者ブリッジでトークン実体が変わり得る - 手数料、最低、停止、流動性、確定性条件がある したがって、本記事はブリッジ先や操作方法を提示しません。送信済みチェーン上の制御を確認できない段階で、ガス用資産を追加送金したり、検索結果の復旧ブリッジへ接続したりしないでください。 ## 状態別の判定対応表 | 分類 | 確認する証拠と次の境界 | 保証しないこと | | --- | --- | --- | | `pre-broadcast-stop` | トランザクションハッシュなし。署名前のチェーン・送信先・資産を再確認し、トランザクションを作らない | 送信成功 | | `pending-unconfirmed` | 元ハッシュ、実行結果なし、送信元・ノンスを保存し、実行結果と置換を読み取り専用追跡 | 取り消し・優先処理成功 | | `confirmed-failed` | `reverted`の実行結果とブロックを保存し、失敗データと同一ノンスの別ハッシュを確認 | ネットワーク手数料返還 | | `controlled-address-delivery` | 意図したチェーン、制御された送信先、正しい資産を確認し、トークン表示と実体を分ける | ウォレット表示だけで安全判定 | | `self-custody-sent-chain-access-candidate` | 送信済みチェーン上の制御と残高を確認し、ネットワーク・トークンを読み取り専用で照合 | ブリッジ・回収成功 | | `custodial-support-only` | サービス入金アドレス、対応ネットワーク、トランザクション証拠を揃え、公式サポートへ確認 | 残高・返還・所要時間 | | `third-party-return-only` | 第三者送信先と確定済み送金を確認し、管理主体へ正当に連絡 | 強制返送 | | `contract-recovery-unknown` | コード、実装、役割、Transferログを確認し、公式プロジェクトとセキュリティレビューへ分ける | 呼び出し可能な回収関数 | | `control-unverified` | 送信先の管理主体を確定できる証拠が増えるまで停止 | アドレス形式からの回収判定 | これらの分類は、架空のハッシュとアドレスだけを入力する判定例で再現できます。判定結果は状態を返すだけで、書き込み操作を許可しません。 ```js const assessment = assessWrongNetworkTransfer({ transaction: { state: 'confirmed-success', hash: '0x' + '12'.repeat(32), sentChainId: 8453, intendedChainId: 1, from: '0x' + '34'.repeat(20), to: '0x' + '56'.repeat(20), tokenContract: '0x' + '78'.repeat(20), amount: '1000000', }, destination: { kind: 'self-custody', controlOnSentChain: true, receiverSupportsSentChain: null, }, asset: { observedOnSentChain: true, tokenContractVerified: true, }, }) ``` 出力が候補でも、`protocolReversalAvailable`、`recoveryGuaranteed`、`writeActionAuthorized`はすべて`false`です。 ## 公式サポートへ渡すもの・渡さないもの ### 渡す証拠 - トランザクションハッシュと正しいブロックエクスプローラー URL - 送信済みチェーン / チェーンID - 実行結果の状態、ブロック、タイムスタンプ - 送信元、送信先、トークンコントラクト、数量 - 入金アドレス、Memo・Tag、入出金ID - 公式サポートの問い合わせ番号 ### 渡さないもの - Secret Recovery Phrase・シードフレーズ - 秘密鍵・キーストア・パスワード - 2段階認証コード・API秘密情報 - 画面共有・遠隔操作 - 「検証料」「解除料」名目の追加送金 MetaMask公式は、未依頼DMでサポートを申し出ず、Secret Recovery Phraseを要求しないと明記しています。電話、WhatsApp、Telegram、XのDMなどで「必ず回収できる」と持ちかける相手を公式サポートとして扱いません。 誤送信ではなく不審な署名・`transferFrom`・委任・複数アカウントの動きが疑われる場合は、追加操作を止め、[ウォレット侵害時にシード・利用許可・セッション・委任を分ける初動ガイド](/archives/6026)へ証拠を引き継いでください。 ## よくある質問 ### 同じ`0x`アドレスなら別EVMネットワークでも必ず取り出せますか？ 必ずではありません。同じEOA秘密鍵で送信済みチェーン上のアドレスを管理している例はありますが、取引所の入金アドレス、スマートアカウント、コントラクト、別のキー 導出では条件が異なります。送信済みチェーン上の制御と残高を別々に証明します。 ### ネットワークをMetaMaskへ追加すれば資産は戻りますか？ ネットワーク追加はウォレットがそのチェーンを読み取る設定です。資産を移動・変換・返還しません。正しい公式ネットワーク情報を使い、追加後もトランザクションを送らずブロックエクスプローラーと残高を照合します。 ### トークンを追加すれば別チェーンから移動できますか？ できません。独自トークン追加は、選択中のチェーンにあるトークンコントラクトをウォレット一覧へ表示する操作です。トークンコントラクトはチェーンごとに確認し、表示追加をブリッジと混同しません。 追加前にTransferログ、`balanceOf`、小数桁、ウォレット表示を分ける手順は[トークンが表示されない時の確認順](/archives/6029)で扱っています。 ### 確定済み後でも取り消しできますか？ できません。保留中の取り消しは同じノンスの置換を先に確定させる試みです。確定済みトランザクションを取り消す命令ではありません。 ### 取引所が秘密鍵を持つアドレスなら必ず返還できますか？ 保証できません。対応ネットワーク、資産、ウォレット構成、アカウント割当、セキュリティ方針、法令対応、手数料などを取引所が判断します。公式サポートへ証拠を提出し、その回答を記録します。 ### `recoverToken`という関数を見つけました。呼べば戻りますか？ 名前だけでは判断できません。対象トークン、受取先、役割、プロキシ実装、停止、関数本文を確認する必要があります。一般利用者が呼べるとは限らず、不明なWriteは行いません。 ## 最終チェックリスト - [ ] 追加送金、ブリッジ、回収代行への連絡を止めた - [ ] トランザクションハッシュの有無を確認した - [ ] ネットワークへの送信前 / 保留中 / 確定済み・失敗 / 確定済み・成功を分けた - [ ] 送信済みチェーンと意図したチェーンのチェーンIDを記録した - [ ] ネイティブ送金の`to`、またはトークンTransferログの受取先を確認した - [ ] 送信済みチェーン上のトークンコントラクトと数量を確認した - [ ] 送信先を自己管理 / 管理サービス型 / 第三者 / コントラクト・不明へ分けた - [ ] 送信済みチェーン上の制御をアドレス形式だけで断定していない - [ ] トークン表示、ネットワーク追加、ブリッジを別操作として扱った - [ ] 公式サポート用の証拠を一つのメモへまとめた - [ ] シードフレーズ、秘密鍵、認証コード、遠隔操作を渡していない 誤送金を疑ったときの最短ルートは、急いで「取り戻す」操作を探すことではありません。**トランザクション状態、送信済みチェーン、送信先制御、資産証拠を同じ時点で固定し、できないことを先に決めること**です。 ## 確認した一次情報 - [MetaMask: I sent crypto to the wrong place](): 確認日 2026-08-29 - [MetaMask: Wallet vs. account vs. address](): 確認日 2026-08-29 - [MetaMask: How to display tokens](): 確認日 2026-08-29 - [MetaMask: Speed up or cancel a pending transaction](): 確認日 2026-08-29 - [MetaMask official support channels](): 確認日 2026-08-29 - [EIP-155: Simple replay attack protection](): 確認日 2026-08-29 - [ethereum.org: Gas and fees](): 確認日 2026-08-29 - [ethereum.org: Proof-of-Stake FAQ and finality](): 確認日 2026-08-29 - [ethereum.org Support](): 確認日 2026-08-29 --- # EIP-712署名の読み方｜ドメイン・ノンス・期限・再利用対策 EIP-712の型、ドメイン区切り、構造体ハッシュ、最終ダイジェストをviemとSolidityで照合し、ノンス再利用・期限切れ・チェーンID・コントラクト不一致をFoundryとAnvilで検証します。 正規URL: https://3mikan.com/archives/6010 著者: みかん 公開: 2026-08-30T04:00:00.000Z 更新: 2026-09-02T05:35:00.000Z EIP-712は、名前の付いた項目を持つデータへ署名するための標準です。長い16進数だけではなく、「誰が」「どのコントラクトで」「何を許可するか」を構造として扱えます。 ただし、**署名はトランザクションではなくても、後から権限を実行する鍵になり得ます。** ガスが表示されないことや、ウォレットが項目を読みやすく表示したことは、安全の保証ではありません。 この記事では、`types`、`primaryType`、`domain`、`message`から最終ダイジェストを作る順番を確認します。続いて、ノンス再利用、有効期限超過、`chainId`不一致、`verifyingContract`不一致をFoundry・Anvil・viemのローカル環境で失敗させます。 外部RPC、実在ウォレット、メインネット署名、実資産は使いません。掲載するアドレスと秘密鍵は、Anvilの公開済みローカルテスト値または架空値だけです。 ## 署名前に固定する7項目 まずはウォレットの文章を読む前に、署名要求を次の7項目へ分けます。 | 項目 | 確認する内容 | ずれた場合 | | --- | --- | --- | | 署名者 | どのアカウントが署名するか | 別アカウントの権限になる | | 名前 / バージョン | どのプロトコル・どの署名仕様か | 互換でないドメインになる | | `chainId` | どのチェーン向けか | 別チェーンのダイジェストになる | | `verifyingContract` | どのアドレスが検証するか | 別コントラクトのダイジェストになる | | `primaryType` / 型 | どの構造体と項目順を使うか | `typeHash`が変わる | | メッセージ | 誰に何をいくら許すか | 意図しない状態更新になる | | ノンス / 有効期限 | 何回、いつまで使えるか | 再利用または長期利用の余地が残る | 許可、注文、投票、ログインでは、同じEIP-712でもメッセージの意味が違います。項目名だけで判断せず、その署名を提出した後に**どの状態が変わるか**まで追います。 ## EIP-712が構造化するもの・保証しないもの [EIP-712](https://eips.ethereum.org/EIPS/eip-712)は、Solidityの構造体に近い型付きデータを決まった手順でハッシュし、署名対象へ変換します。 主な役割は次の3つです。 - 項目名と型を含めてメッセージをハッシュする - プロトコル、チェーン、検証コントラクトなどをドメインで分離する - 同じ入力から同じダイジェストを決定的に作る 一方、EIP-712の仕様は再利用対策を自動では提供しません。仕様のSecurity Considerationsにも、同じメッセージを2回見たときに拒否するか、同じ結果だけを返す設計はアプリケーション側の責任だとあります。 つまり、「EIP-712形式だから安全」ではありません。**何へ署名したかを読みやすくする標準**と、**署名を何回使えるか決めるアプリケーション状態**を分けて考えます。 ## 型付きデータは4つの入力に分ける viemの`signTypedData`へ渡す基本形は、次の4つです。 ```ts const domain = { name: '3MIKAN Typed Authorization', version: '1', chainId: 31337, verifyingContract, } const types = { Authorization: [ { name: 'signer', type: 'address' }, { name: 'delegate', type: 'address' }, { name: 'value', type: 'uint256' }, { name: 'nonce', type: 'uint256' }, { name: 'deadline', type: 'uint256' }, ], } const primaryType = 'Authorization' const message = { signer, delegate, value: 123n, nonce: 0n, deadline, } ``` - `types`: 構造体名、項目名、型、並び順 - `primaryType`: 今回ハッシュする中心の構造体 - `domain`: 署名を使うプロトコル・チェーン・コントラクトの境界 - `message`: 実際のアドレス、数量、ノンス、期限 `types`は画面の見出しではなく、ハッシュの入力です。項目の並び順や型が変われば、同じ値を入れても別のダイジェストになります。 `message`では、`delegate`や`value`という名前だけを信用しません。検証コントラクトのソースを読み、最終的にその値が送金、利用許可額、注文、投票、ログインセッションのどれへ使われるか確認します。 ## `typeHash`から最終ダイジェストまでを追う EIP-712の最終ダイジェストは、次の形です。 ```text digest = keccak256( 0x1901 || domainSeparator || hashStruct(message) ) ``` ここで`0x1901`はEIP-191と組み合わせるための接頭辞です。後ろへドメインのハッシュとメッセージのハッシュを32バイトずつ並べ、最後にKeccak-256を取ります。
EIP-712の型とメッセージから構造体ハッシュ、ドメインからドメイン区切りを作り、0x1901と結合して最終ダイジェストへ進む流れ
ドメインとメッセージは別々にハッシュします。ウォレットの表示だけでなく、最終ダイジェストがクライアントとコントラクトで一致するか確認します。
### `typeHash`は構造体の設計図のハッシュ 今回の構造体は、次の文字列へ正規化されます。 ```text Authorization(address signer,address delegate,uint256 value,uint256 nonce,uint256 deadline) ``` この文字列のKeccak-256が`AUTHORIZATION_TYPEHASH`です。`uint`のような別名ではなく`uint256`を使い、参照する別構造体があれば、その定義も決められた順に追加します。 ### 構造体ハッシュは`typeHash`と各値のハッシュ Solidityでは、固定長項目を次のようにABIエンコードしてハッシュできます。 ```solidity bytes32 structHash = keccak256( abi.encode( AUTHORIZATION_TYPEHASH, authorization.signer, authorization.delegate, authorization.value, authorization.nonce, authorization.deadline ) ); ``` `string`や可変長`bytes`は、そのままABIエンコードするのではなく、内容のKeccak-256を32バイト値として入れます。入れ子構造体は、その構造体の`hashStruct`を入れます。 ABIの32バイト境界を先に確認したい場合は、[ABI・呼び出しデータ・イベントログを手で読む方法](/archives/6005)へ戻ると対応しやすくなります。 ### viemで3段階を照合する viemでは、ドメイン区切り、構造体ハッシュ、最終ダイジェストを別々に計算できます。 ```ts import { concat, hashDomain, hashStruct, hashTypedData, keccak256, } from 'viem' const domainSeparator = hashDomain({ domain, types: typesWithDomain }) const messageHash = hashStruct({ data: message, primaryType: 'Authorization', types: typesWithDomain, }) const reconstructed = keccak256( concat(['0x1901', domainSeparator, messageHash]), ) const digest = hashTypedData({ domain, types, primaryType: 'Authorization', message, }) console.assert(reconstructed === digest) ``` この再構成値と`hashTypedData`を同じ入力で計算し、一致することを確認します。クライアント側で使ったJSONと、コントラクト側で使う構造体・項目順が一つでも違えば一致しません。 ## ドメイン区切りでチェーンとコントラクトを分ける 今回のドメインは、次の4項目を使います。 ```text name version chainId verifyingContract ``` EIP-712では、必要に応じて`salt`も使えます。使わない項目はドメイン型から省略します。独自項目を勝手に足すのではなく、標準のドメイン設計に合わせます。 ### `chainId` `chainId`が変わるとドメイン区切りが変わります。そのため、チェーン31337向けの署名をチェーン31338のドメインで検証すると、復元される署名者が一致しません。 ただし、ドメインへ`chainId`を入れなければ、この分離は得られません。ウォレットが現在のネットワークとドメインの`chainId`不一致を警告・拒否する場合もありますが、最終的には検証側でも期待するドメインを固定します。 ### `verifyingContract` `verifyingContract`は、署名を検証するコントラクトアドレスです。別アドレスへ同じメッセージを渡しても、ドメイン区切りが変わるため同じ署名では通りません。 プロキシ構成では、通常は利用者が呼び出し、状態を保持するプロキシアドレスをドメインに使います。実装を更新してもプロキシアドレスとドメインバージョンを変えなければ、未使用署名が新しい実装でも有効なままになる可能性があります。 署名の意味や検証条件を変える更新では、ドメインバージョンの変更、ノンスの移行、既存署名の無効化方針を先に決めます。プロキシの仕組みは[直コンでプロキシと実装を確認する順番](/archives/1005)で分けて説明しています。 ### 名前とバージョン `name`は署名ドメインを人が識別する名前、`version`は互換性の境界です。UI上の飾りではなくハッシュへ入ります。 小さな文言修正のたびにバージョンを変える必要はありません。一方で、同じ型名でも権限の意味や検証コントラクトの挙動が変わるなら、古い署名と互換にするかを明示的に判断します。 ## ノンス・有効期限・使用済み状態で再利用を止める 同じダイジェストへ同じ鍵で作った署名は、何度検証しても暗号学的には同じ署名者を復元できます。そのため、実行回数はコントラクト状態で制限します。
EIP-712署名を`chainId`、`verifyingContract`、ノンス、有効期限、署名者の順に検証し、一度だけ実行する5つの条件
署名検証だけで終わらず、状態更新の実行と同じトランザクションでノンスまたは使用済み状態を更新します。
### 連番ノンス アドレスごとに次の未使用ノンスを保存し、メッセージのノンスと一致したときだけ実行します。 ```solidity uint256 expectedNonce = nonces[authorization.signer]; if (authorization.nonce != expectedNonce) { revert InvalidNonce(expectedNonce, authorization.nonce); } nonces[authorization.signer] = expectedNonce + 1; ``` [OpenZeppelin Contracts 5.xの`Nonces`](https://docs.openzeppelin.com/contracts/5.x/api/utils#Nonces)も、アドレスごとに次の未使用ノンスを返し、消費時に増やす実装です。 連番ノンスでは、先のノンスを使うと前の未使用署名が通らなくなる設計になります。注文を順不同で使いたい場合は、ダイジェストごとの`used`マッピング、ビットマップ、個別取り消し状態などを検討します。 ### 有効期限 有効期限は、「この時刻を過ぎたら使えない」という境界です。今回の検証例は次の条件にしています。 ```solidity if (block.timestamp > authorization.deadline) { revert AuthorizationExpired(authorization.deadline, block.timestamp); } ``` この実装では有効期限と同じ秒は有効で、1秒でも超えれば失敗します。`>=`と`>`のどちらを使うかを曖昧にせず、クライアントとコントラクトで同じ条件にします。 有効期限がない署名は、ノンスを消費するか取り消すまで長期間使える可能性があります。有効期限が極端に遠い場合も、実質的な有効期間を人が読める日時へ直します。 ### 状態更新より前に状態を更新する 署名が外部呼び出しやトークン移動を許可する場合、再利用防止状態を更新する位置も重要です。検証後、外部呼び出しより前にノンスや使用済み状態を更新し、必要なら再入対策を入れます。 今回の検証用コントラクトは外部呼び出しも資産移動も行わず、利用済みイベントとノンス更新だけを再現します。本番環境コントラクトの安全性を保証するサンプルではありません。 ## Foundryで5つの例を失敗させる 下の再現例はSolidity 0.8.36で完結し、Foundry v1.8.0、EVM Pragueで実行します。外部RPCは使いません。 | テスト | 署名したドメイン / メッセージ | コントラクト側の結果 | | --- | --- | --- | | 成功 | 現在チェーン、現在コントラクト、ノンス0、期限内 | 実行しノンスを1へ更新 | | 使用済みノンス | 成功時と同じ署名を再提出 | `InvalidNonce` | | 期限切れ有効期限 | 現在時刻より前の有効期限 | `AuthorizationExpired` | | 誤った`chainId` | `chainId`だけを`+1`して署名 | `InvalidSigner` | | 誤った`verifyingContract` | 別アドレスのドメインで署名 | `InvalidSigner` | この検証では、正常な署名に加えて、使用済みノンス、期限切れ、別チェーン、別コントラクトの各条件を同じコントラクトへ与えました。正常な署名だけが受理され、それ以外は表に示した独自エラーで拒否されます。 `chainId`とコントラクトが違う例では、署名バイト自体が壊れているわけではありません。**別ドメインのダイジェストには正しい署名**ですが、現在のコントラクトが作るダイジェストとは一致しないため拒否されます。 ## Anvil上でviemとSolidityのダイジェストを一致させる Foundryでの確認に加え、空いているローカルポートでAnvilを起動します。viem 2.56.0から検証用コントラクトをデプロイし、同じ型付きデータをクライアントとコントラクトでハッシュします。 ```ts const signature = await walletClient.signTypedData({ domain, types, primaryType: 'Authorization', message, }) const viemDigest = hashTypedData({ domain, types, primaryType: 'Authorization', message, }) const solidityDigest = await publicClient.readContract({ address: verifyingContract, abi, functionName: 'digest', args: [message], }) console.assert(viemDigest === solidityDigest) ``` 一致を確認した後だけ、ローカル認可を1回実行します。その後、同じノンス、期限切れ、別チェーン、別コントラクトを`simulateContract`し、すべて`revert`することを確認します。 照合はローカルのAnvilだけで行い、検証後に停止しました。メインネットやテストネットには接続していません。 ## EOAとERC-1271コントラクトウォレットは検証経路が違う EOAは秘密鍵で署名し、ダイジェストと署名から`ecrecover`したアドレスを期待する署名者と比較できます。 viemの実用版`verifyTypedData`はEOA署名向けです。コントラクトアカウントを含めて検証する場合は、Public Clientの`verifyTypedData`操作など、ERC-1271を扱う経路を使います。 [ERC-1271](https://eips.ethereum.org/EIPS/eip-1271)では、コントラクトウォレットが次の関数を実装し、有効ならマジック値`0x1626ba7e`を返します。 ```solidity function isValidSignature(bytes32 hash, bytes memory signature) external view returns (bytes4 magicValue); ``` コントラクトは秘密鍵を持たず、所有者、必要署名数、セッション鍵、時刻など独自状態で有効性を判断できます。そのため、同じ署名がブロックNでは有効でも、所有者変更や取り消し後のブロックN+1では無効になる場合があります。 OpenZeppelinの`SignatureChecker.isValidSignatureNow`は、署名者にコードがあればERC-1271、なければECDSAとして検証します。過去時点の有効性が必要なら、確認ブロックとコントラクト状態も固定します。 1-of-1・2-of-3の必要署名数、誤ったマジック値、`revert`、所有者変更後の再検証は、[ERC-1271でコントラクトアカウント署名を検証する方法](/archives/6011)でFoundryの失敗例まで確認できます。 ウェブログインの署名ではEIP-712へ置き換えず、ERC-4361のドメイン、URI、チェーンID、一度だけ使えるノンスを検証します。[SIWEをノンスからセッションまで安全に実装する方法](/archives/6019)で、EOA / ERC-1271とCSRF・ログアウトまで確認できます。 EIP-7702でコードを持つアカウントの実行文脈は、[EIP-7702のEOA・`msg.sender`・`tx.origin`検証](/archives/6006)で確認できます。アカウントのコード有無だけを、権限や安全性の結論にしないでください。 複数のブラウザーウォレットから署名先を選ぶ画面では、表示名やアイコンだけでプロバイダーを決めないことも必要です。[EIP-6963で複数ウォレットを検出・選択する実装](/archives/6015)で、通知されたプロバイダーと実際に要求を送るプロバイダーを一つに対応させてから、この記事のドメインとメッセージ確認へ進んでください。 ## コードレビューで止める署名要求 次のどれかが説明できない場合は、署名せずに止めます。 | 確認できないもの | なぜ止めるか | | --- | --- | | `verifyingContract`のソース / プロキシ | 署名がどの状態更新へ使われるか不明 | | `chainId` | 別チェーンとのドメイン分離を確認できない | | ノンスまたは使用済み状態 | 同じ署名の再利用条件が不明 | | 有効期限 | いつまで提出できるか不明 | | 利用先 / 委任先 / 受取先 | 誰が何を実行できるか不明 | | 値 / 数量 / トークン | 権限の数量と対象資産が不明 | | `primaryType`と全項目 | ウォレット表示が省略した値を確認できない | | EOA / ERC-1271の検証方法 | 署名者判定の経路が不明 | 表示された文章が自然でも、ドメインとメッセージの実データが意図通りとは限りません。反対に、見慣れない項目があるだけで危険と断定もできません。ソース、ABI、ドメイン、最終状態更新を同じ入力で照合します。 Permitとトークン利用許可額の関係は[MetaMaskのSpending上限・`approve`・取り消し・Permit](/archives/6007)で扱っています。署名要求では、トークン、利用先、値、ノンス、有効期限をこの記事のドメイン確認へ接続してください。 ERC-2612 Permit、Permit2の順序付き / 順不同ノンス、ERC-7674一時的利用許可を同じ再現例で比べる場合は、[ERC-20権限4方式の署名・状態・失効比較](/archives/6012)へ進んでください。 EIP-712互換の`userOpHash`をEntryPoint、`chainId`、アカウント検証、バンドラー応答まで追う場合は、[ERC-4337 UserOperation失敗の段階別解析](/archives/6013)で`AA24`と実行段階の`revert`を分けて確認できます。 実装を読む前に、ウォレット画面で`personal_sign`、SIWE、Permit、EIP-7702を型付きデータと取り違えず停止判断したい場合は、[ウォレット署名要求の見分け方と9項目チェックリスト](/archives/6025)を入口にしてください。 ## 最終チェックリスト - [ ] 署名アカウントを確認した - [ ] ドメインの名前とバージョンを確認した - [ ] `chainId`が現在の対象チェーンと一致する - [ ] `verifyingContract`を公式ソース・プロキシ構成と照合した - [ ] `primaryType`、項目名、型、並び順を確認した - [ ] メッセージのアドレス、数量、状態更新を説明できる - [ ] ノンスまたは使用済み状態の消費方法を確認した - [ ] 有効期限を人が読める日時へ直した - [ ] クライアントとコントラクトの最終ダイジェストが一致する - [ ] EOAとERC-1271の検証経路を分けた - [ ] 署名成功をトランザクション成功や安全保証と混同していない EIP-712を読むときに大切なのは、ウォレットの見出しを暗記することではありません。**型、ドメイン、メッセージ、アプリケーション状態を同じダイジェストへ対応させ、どの条件で一度だけ実行できるか説明すること**です。 この記事と検証例に広告・アフィリエイトの署名導線はありません。特定ウォレット、RPC、コントラクトの利用を勧めるものではなく、本番環境実装では独立したセキュリティレビューと追加テストが必要です。 ## 確認した一次情報 - [EIP-712 Typed structured data hashing and signing](): 確認日 2026-08-30 - [viem signTypedData](): 確認日 2026-08-30 - [viem hashTypedData](): 確認日 2026-08-30 - [viem verifyTypedData](): 確認日 2026-08-30 - [OpenZeppelin Contracts 5.x EIP712](): 確認日 2026-08-30 - [OpenZeppelin Contracts 5.x Nonces](): 確認日 2026-08-30 - [ERC-1271 Contract Signature Validation](): 確認日 2026-08-30 - [Solidity 0.8.36 documentation](): 確認日 2026-08-30 - [Foundry v1.8.0](): 確認日 2026-08-30 --- # ERC-1271とは？Safeなどのコントラクト署名を正しく検証する ERC-1271のisValidSignature、マジック値、revert、Safe型の必要署名数を整理し、EOA・1-of-1・2-of-3・状態変更をOpenZeppelinとFoundryで検証します。 正規URL: https://3mikan.com/archives/6011 著者: みかん 公開: 2026-08-30T05:05:00.000Z 更新: 2026-09-02T05:35:00.000Z ERC-1271は、**コントラクトアカウント自身へ「このダイジェストと署名は、今このアカウントにとって有効ですか」と問い合わせる標準**です。 EOAは秘密鍵で署名するため、ECDSAで復元したアドレスを期待する署名者と比較できます。一方、Safeのようなコントラクトアカウントはコントラクト自体の秘密鍵を持ちません。複数の所有者、必要署名数（しきい値）、セッション鍵、停止など、その時点の状態を使って有効性を判定します。 そのため、すべての署名者へ`ecrecover`だけを使う実装はコントラクトアカウントの正しい署名を拒否します。反対に、「コントラクトだから有効」と扱うこともできません。ERC-1271の呼び出しが成功し、厳密なマジック値を返したかまで確認します。 この記事ではOpenZeppelin Contracts `5.6.1`の`SignatureChecker`を使い、EOA、1-of-1、2-of-3、誤った所有者、署名数不足、署名順序、誤ったダイジェスト、期限切れ、誤ったマジック値、`revert`、状態変更をFoundryのローカル環境で再現します。実在Safe、外部RPC、ウォレット接続、メインネット署名、実資産は使いません。 ## EOA署名とコントラクト署名の違い 最初に、検証する主体を分けます。 | 署名者 | 誰が署名の有効性を決めるか | 基本の検証 | 結果が後から変わるか | | --- | --- | --- | --- | | EOA | 1つの秘密鍵 | ダイジェストと署名からECDSAでアドレスを復元 | 同じダイジェスト・署名・アドレスなら通常は変わらない | | デプロイ済みコントラクトアカウント | アカウントコントラクトの現在の処理と状態 | `isValidSignature(digest, signature)`を`staticcall` | 所有者、必要署名数、停止などで変わり得る | | 未デプロイのアカウント | 将来デプロイされるアカウントとファクトリー情報 | ERC-1271だけでは直接検証できない | ERC-6492などデプロイ状態を考慮した経路が必要 | ここで検証するのは「この署名者にとって、このダイジェストの署名が有効か」です。署名対象が安全か、同じ署名を再利用できないか、期限内か、処理が成功するかは別の確認です。 ## ERC-1271のインターフェースとマジック値 [ERC-1271](https://eips.ethereum.org/EIPS/eip-1271)の中心は次のインターフェースです。 ```solidity interface IERC1271 { function isValidSignature(bytes32 hash, bytes calldata signature) external view returns (bytes4 magicValue); } ``` 有効なときに返す値は、次の4バイトです。 ```text bytes4(keccak256("isValidSignature(bytes32,bytes)")) = 0x1626ba7e ``` `true`、`1`、空の戻り値データ、似た別の4バイトでは成功になりません。呼び出しが`revert`した場合も、有効な署名として扱いません。 ERC-1271の仕様では、この関数は状態を変更してはいけません。ただし、**状態を読んで判定すること**は禁止されていません。たとえば現在の所有者集合、必要署名数、時刻、許可済みハッシュを読めます。 外部呼び出しも許されるため、実装ごとの処理量を想定せず、独自の小さなガス上限を決め打ちしないことも重要です。 署名者のコード有無に応じてEOAのECDSA検証とコントラクトアカウントのERC-1271検証へ分かれる流れ ## OpenZeppelin SignatureCheckerで検証入口を揃える OpenZeppelinの`SignatureChecker`は、`address`型の署名者について次の分岐を行います。 - 署名者にコードがない: ECDSAで復元したアドレスと署名者を比較 - 署名者にコードがある: ERC-1271の`isValidSignature`を`staticcall` 呼び出し側は次のように1つの入口へまとめられます。 ```solidity import {SignatureChecker} from "@openzeppelin/contracts/utils/cryptography/SignatureChecker.sol"; function isValid( address signer, bytes32 digest, bytes calldata signature ) public view returns (bool) { return SignatureChecker.isValidSignatureNowCalldata( signer, digest, signature ); } ``` この記事の例は`@openzeppelin/contracts`を正確なバージョンの`5.6.1`へ固定しています。主要バージョンだけ、`^5.6.1`、`latest`ではありません。署名検証はセキュリティ境界になるため、更新時は変更履歴とテスト結果を別途確認します。 `SignatureChecker`はコントラクト呼び出しが`revert`した場合、戻り値データが短い場合、返り値が`0x1626ba7e`でない場合を`false`へまとめます。利用APIを`bool`に揃えられますが、バックエンドで障害を調べるときは、低水準呼び出しの成功、戻り値データ、対象ブロックも別に記録すると原因を分けられます。 ### `code.length == 0`はEOAの証明ではない この分岐は便利ですが、「今コードがないアドレスは必ずEOA」という身元証明ではありません。 - まだデプロイされていない未デプロイアカウント - コンストラクター実行中のコントラクト - 将来同じアドレスへデプロイされる前の状態 なども、その時点ではコードが見えない場合があります。さらにEIP-7702で委任コードを持つEOAは、従来の「EOAにはコードがない」という前提から外れます。 したがって、`code.length`は**検証方法を選ぶ、その時点の状態**として扱い、アカウント種別や永続的な本人性の結論にはしません。 ## ローカル例で1-of-1を検証する 再現環境は次の通りです。 | 項目 | バージョン・設定 | | --- | --- | | OpenZeppelin Contracts | `5.6.1`へ正確に固定 | | Solidity | `0.8.36` | | Foundry | `1.8.0` | | チェーン / RPC | Foundry内のローカルEVMのみ | | キー / アカウント | 決定的ローカルテストキーとデプロイした検証用コントラクトだけ | | 資産送金 | なし | `Threshold1271Wallet`は所有者アドレスと必要署名数を保存し、署名ペイロードを次の独自形式で受け取ります。 ```solidity abi.encode( address[] signers, bytes[] ownerSignatures ) ``` 1-of-1では、1人の所有者が同じダイジェストへ署名し、ウォレットコントラクトが所有者所属とECDSA署名を確認します。条件を満たせば`0x1626ba7e`を返し、外側の`SignatureChecker`も`true`になります。 ```solidity bytes memory signature = abi.encode(signers, ownerSignatures); require( wallet.isValidSignature(digest, signature) == IERC1271.isValidSignature.selector ); require(verifier.isValid(address(wallet), digest, signature)); ``` このペイロードは学習用例の形式で、Safe固有の連結署名形式ではありません。本番環境のアカウントへそのまま渡せる互換形式だとは考えないでください。 ## 2-of-3の必要署名数と署名順序を確認する 2-of-3では3人の所有者のうち2人以上が、**同じダイジェスト**へ署名する必要があります。例は次を順番に確認します。 1. 署名数が必要署名数以上か 2. 署名者数と署名数が一致するか 3. 署名者が現在の所有者か 4. 署名者アドレスが厳密な昇順か 5. 各署名が同じダイジェストに対して有効か Safe本体も必要署名数を確認し、所有者アドレスが前の所有者より大きいことを要求して、無効な所有者と重複を拒否します。Safeの`GS020`は署名データ不足、`GS026`は無効・重複所有者や順序などを調べる手掛かりです。 ただし、この記事の`Threshold1271Wallet`は**所有者・必要署名数・順序・状態依存だけを切り出したSafe型の最小再現**です。Safeのコントラクト署名、承認済みハッシュ、P-256、モジュール、実行者の文脈、実際の署名符号化を再実装したものではありません。資産管理には使えません。 3人の所有者から2署名を検証し、所有者状態変更後に同じ署名が無効になる流れ ## 正常系と失敗系をFoundryで再現する ローカル例は、成功だけでなく同じ入口から次の失敗を作ります。 | テスト | 入力・状態 | 期待結果 | 主に分かること | | --- | --- | --- | --- | | EOA成功 | 所有者のキーで正しいダイジェストへ署名 | `true` | ECDSA経路 | | EOA誤った署名者 | 別所有者として検証 | `false` | アドレス一致が必要 | | 1-of-1 | 現所有者1人の正しい署名 | マジック値 / `true` | ERC-1271正常系 | | 2-of-3 | 現所有者2人を昇順で提出 | マジック値 / `true` | 必要署名数を満たす正常系 | | 署名数不足 | 2-of-3へ1署名だけ提出 | `false` | 署名数不足 | | 誤った所有者 | 外部者を含める | `false` | 所有者所属 | | 並び順が不正 | 正しい2人を降順で提出 | `false` | 順序・重複防止 | | 誤ったダイジェスト | 署名後にダイジェストを変更 | `false` | 全所有者が同じダイジェストへ署名する必要 | | 期限切れ | アプリケーション有効期限後に検証 | `false` | 期限はアプリケーション側の条件 | | 誤ったマジック値 | コントラクト呼び出し成功、`0xffffffff`を返す | `false` | 呼び出し成功だけでは不足 | | `revert` | `isValidSignature`が`revert` | `false` | `revert`を承認にしない | | 所有者変更 | 所有者を外して同じ署名を再検証 | `false` | 状態依存 | | 検証停止 | ウォレットを停止して同じ署名を再検証 | `false` | ブロック間で結果が変わる | | 未デプロイアカウント | コードのない予定アドレス | `false` | ERC-6492境界 | 検証はローカルチェーンだけで行い、表の各入力に対する戻り値と状態変化を確認しました。メインネットやテストネットのRPC、実在する鍵、実資産は使っていません。 ### 有効期限はERC-1271の自動機能ではない ローカル例の期限確認は、統一検証役側へ明示的に追加しています。 ```solidity function isValidBefore( address signer, bytes32 digest, bytes calldata signature, uint256 deadline ) external view returns (bool) { return block.timestamp <= deadline && SignatureChecker.isValidSignatureNowCalldata( signer, digest, signature ); } ``` ERC-1271へ`deadline`引数はありません。有効期限を署名対象へ含めず、別入力としてだけ受け取ると、提出者が値を変えられる設計になり得ます。実際のアプリケーションでは有効期限、ノンス、操作、チェーン、検証先をダイジェストへ結びつけたうえで、その時点の状態も確認します。 ## コントラクト署名は「今」の答え OpenZeppelinの説明にある通り、コントラクト署名はブロックNで`true`、ブロックN+1で`false`になる場合があります。逆に、所有者が追加されたり事前承認状態が変わったりして、後から有効になる実装も考えられます。 `view`は「この呼び出し自身が状態を変更しない」という意味です。返り値が永続的に固定される意味ではありません。 チェーン外バックエンドで検証結果を証拠として残す場合は、少なくとも次を一緒に記録します。 - `chainId` - 署名者コントラクトアドレス - ブロック番号またはブロックタグ - ダイジェスト - 署名またはその安全な参照 - 低水準呼び出しの成功・`revert` - 戻り値 - 検証時点のアカウント実装 / コードを追える情報 長期セッションや注文を有効にする場合は、所有者変更、アカウント更新、停止、ノンス消費などの後に再検証する条件も決めます。「一度`true`だった署名」を無期限の本人証明としてキャッシュしません。 ERC-1271をウェブ認証へ使う場合は、[SIWEのノンス・オリジン項目・セッション失効までの実装](/archives/6019)で、指定チェーンのコントラクト状態とアドレスに紐づくセッションをどう対応させるか確認できます。 ## EIP-712はダイジェスト、ERC-1271は署名者を担当する ERC-1271へ渡す最初の引数は`bytes32 hash`であり、その値自体に用途の説明はありません。ERC-1271だけでは、注文、投票、ログイン、Permitのどれを表すか分かりません。`chainId`、`verifyingContract`、ノンス、有効期限が入っている保証もありません。 役割を分けると次のようになります。 | 層 | 主な役割 | 自動では保証しないもの | | --- | --- | --- | | EIP-712 | 型、ドメイン、メッセージから最終ダイジェストを作る | ノンス消費、有効期限判定、状態更新の正当性 | | ERC-1271 | コントラクトアカウントがダイジェストと署名の現在有効性を答える | ダイジェストの意味、再利用防止、トランザクション成功 | | アプリケーション | ノンス、有効期限、権限、状態更新、状態遷移を検証する | アカウント内部の所有者判定 | ドメイン区切り、`hashStruct(message)`、ノンス、有効期限を同じダイジェストへ結びつける手順は、[EIP-712署名の読み方と再利用対策](/archives/6010)でローカルコードと一緒に確認できます。 ABIから`isValidSignature`の識別子、引数、戻り値データを追う場合は、[ABI・関数識別子・イベントログの確認方法](/archives/6005)を参照してください。 ## EIP-7702と未デプロイアカウントの境界 EIP-7702ではEOAアドレスが委任コードを持てます。そのアドレスを`SignatureChecker`へ渡すと、現在コードがあるためERC-1271側へ進みます。委任済み実装がアカウントの文脈でERC-1271を正しく提供しているかが必要です。 アドレス、保存領域、委任コード、`msg.sender`の境界は、[EIP-7702でEOAはどう変わるか](/archives/6006)でFoundryテストを使って確認できます。 反対に、未デプロイアカウントがまだデプロイされていなければ`isValidSignature`を呼び出せません。[ERC-6492](https://eips.ethereum.org/EIPS/eip-6492)は、ファクトリーとデプロイ呼び出しデータを署名へ包み、必要ならデプロイ処理を考慮してからERC-1271を試す検証順を定義します。 ERC-6492はデプロイ副作用、ラッパー解析、再入など追加の境界を持つため、この記事の例には混ぜていません。[ERC-6492で未デプロイスマートアカウントの署名を検証する方法](/archives/6018)では、末尾から先頭へ読む順序、CREATE2予定アドレス、巻き戻し、信頼するファクトリーの方針、デプロイ後のラッパーまで確認できます。 ERC-4337アカウントの署名不一致、検証時の`revert`、ノンス、事前資金をEntryPointの結果へ対応させる場合は、[UserOperationのバンドラー・ペイマスター・実行解析](/archives/6013)で`AA23`と`AA24`を別経路として確認できます。 コントラクトアカウントの署名者にPasskeyを使う場合は、ERC-1271マジック値の前にWebAuthn項目とP-256を検査します。[PasskeyスマートアカウントのWebAuthn・P-256検証](/archives/6016)で、オリジン、RP IDハッシュ、DER `r,s`、EIP-7951、複数認証情報の境界を確認できます。 Safeの2-of-3トランザクションでコントラクト署名、所有者の承認数、Safeノンス、チェーン上の実行を一件の調査へ対応させる場合は、[Safeの取引が進まない時の確認手順](/archives/6030)へ進んでください。署名が有効で必要署名数に達していても、対象処理の成功までは証明しないことをローカル再現で分けています。 ## バックエンド・コントラクトレビューチェックリスト - [ ] 期待する署名者アドレスをダイジェスト外の入力と混同していない - [ ] EOAはECDSA、デプロイコントラクトはERC-1271で検証する - [ ] ERC-1271呼び出し成功だけでなく`0x1626ba7e`を厳密に確認する - [ ] 誤ったマジック値、短い戻り値、`revert`を有効として扱わない - [ ] `code.length == 0`を永続的なEOA証明にしない - [ ] 使用する署名ライブラリーのバージョンを正確に固定した - [ ] アカウント固有の署名符号化と必要署名数の規則を公式ソースで確認した - [ ] Safe型署名では所有者順序と重複を確認した - [ ] EIP-712などでチェーン、コントラクト、操作、ノンス、有効期限をダイジェストへ結びつけた - [ ] ノンス消費と有効期限判定をアプリケーション状態で行う - [ ] 検証ブロックとアカウント状態を記録し、変更後の再検証条件を決めた - [ ] 未デプロイアカウントはERC-6492等の別経路として扱う - [ ] 署名有効をトランザクション成功、安全性、監査済みの証明にしない ERC-1271対応で大切なのは、「コントラクトウォレットも受け付ける」という一行を足すことではありません。**EOAのECDSA、コントラクトアカウントの現在の状態、ダイジェストを作るアプリケーション規則を同じ認可フローの別レイヤーとして照合すること**です。 この記事にスポンサー、アフィリエイト、ウォレット作成、資産移動の販売誘導はありません。将来、署名基盤の開発相談やスポンサー表示を置く場合も、広告であることを明示し、上の仕様・テスト結果・レビュー結論から独立させます。本番環境実装には、この例とは別の設計レビュー、アカウント固有テスト、脅威分析が必要です。 ## 確認した一次情報 - [ERC-1271 Standard Signature Validation Method for Contracts](): 確認日 2026-08-30 - [OpenZeppelin Contracts 5.x SignatureChecker](): 確認日 2026-08-30 - [OpenZeppelin Contracts v5.6.1](): 確認日 2026-08-30 - [Safe Smart Account Safe.sol](): 確認日 2026-08-30 - [Safe Smart Account error codes](): 確認日 2026-08-30 - [EIP-712 Typed structured data hashing and signing](): 確認日 2026-08-30 - [ERC-6492 Signature Validation for Predeploy Contracts](): 確認日 2026-08-30 - [EIP-7702 Set Code for EOAs](): 確認日 2026-08-30 - [Solidity 0.8.36 documentation](): 確認日 2026-08-30 - [Foundry v1.8.0](): 確認日 2026-08-30 --- # ERC-20の権限方式を比較｜approve・Permit・Permit2・ERC-7674 ERC-20のapprove、ERC-2612 Permit、Permit2、ERC-7674を、署名、ノンス、有効期限、利用先、状態の保存先、失効方法、ローカルテストで比較します。 正規URL: https://3mikan.com/archives/6012 著者: みかん 公開: 2026-08-30T06:20:00.000Z 更新: 2026-09-02T05:35:00.000Z ERC-20の権限方式を選ぶときは、**誰が、どのトークンを、どの利用先へ、いくら、いつまで使わせるか**を同じ順序で確認します。 `approve`、ERC-2612 Permit、Permit2、ERC-7674は、どれもトークンを第三者が使う権限に関係します。ただし、署名の有無だけでなく、権限状態の保存先、ノンス、期限、止め方が違います。 特に「署名だからガス不要で安全」「Permit2ならトークンの利用許可は不要」「一時的利用許可なら既存利用許可額を無視できる」という理解は正しくありません。この記事では4方式を同じ比較軸へ置き、OpenZeppelin Contracts `5.6.1`、Solidity `0.8.36`、Foundry `1.8.0`のローカル再現例で正常系と失敗系を確認します。 外部RPC、実在ウォレット、正規Permit2コントラクト、メインネットトークン、実資産は使いません。 ## まず4方式を同じ表で分ける | 方式 | 所有者の起点 | 署名 | 権限状態の保存先 | ノンス・期限 | 対応条件 | | --- | --- | --- | --- | --- | --- | | ERC-20 `approve` | トークンへのトランザクション | 不要 | トークンの永続利用許可額 | ERC-20標準にはノンス・期限なし | ERC-20トークン | | ERC-2612 Permit | 型付きデータ署名 + 提出トランザクション | EIP-712 | トークンの永続利用許可額 | 所有者ごとの連番ノンス、提出有効期限 | トークン自身がERC-2612を実装 | | Permit2 AllowanceTransfer | トークン→Permit2利用許可 + Permit2署名またはトランザクション | EIP-712 | トークン利用許可額とPermit2内の後段利用許可額 | 順序付きノンス、`sigDeadline`、`expiration` | トークンの利用許可とPermit2対応利用先 | | Permit2 SignatureTransfer | トークン→Permit2利用許可 + 1回の署名送金 | EIP-712 | 後段利用許可額は保存しない。トークン利用許可額は別に残る | 順不同ノンスビットマップ、有効期限 | トークンの利用許可とPermit2対応利用先 | | ERC-7674 | 同じトランザクション内の`temporaryApprove` | 仕様上は不要 | トークンの一時利用許可額 | トランザクション境界で解除 | トークン実装、EIP-1153対応EVM、同一トランザクション内の呼び出し経路 | 「ガス代不要」は、所有者が`approve`トランザクションを直接送らなくてもよい、という意味で使われます。署名をチェーン上で使うトランザクションと、そのガスを支払う主体まで消えるわけではありません。 次の図では、権限がどのコントラクトへ残るかを先に分けます。
同じ所有者とトークンから利用先へ進む`approve`、ERC-2612、Permit2、ERC-7674で、権限状態を保存するコントラクトが異なる流れ
Permit2だけは、トークンからPermit2への利用許可と、Permit2から実際の利用先への権限を二層に分けます。
## ERC-20 `approve`はトークンへ永続利用許可額を保存する [ERC-20](https://eips.ethereum.org/EIPS/eip-20)の`approve(spender, value)`は、`msg.sender`を所有者として、トークンコントラクト内の所有者・利用先組み合わせへ値を保存します。 ```solidity token.approve(spender, 100 ether); token.transferFrom(owner, recipient, 40 ether); // 標準的な有限allowanceなら残りは60 token.allowance(owner, spender); ``` 基本仕様には有効期限もノンスもありません。有限利用許可額なら`transferFrom`のたびに減り、`approve`を再実行すると新しい値へ上書きされます。使い切らず、上書きも取り消しもしなければ、別トランザクションへ持ち越されます。 権限を止める一般的な形は`approve(spender, 0)`です。ただし、0から別の値へ変更する必要があるトークンなど、標準外の挙動もあります。本番環境では対象トークンの実装と現在利用許可額を先に読みます。 `approve`は、権限を設定するトランザクションと、利用先が使うトランザクションの二段階です。最初のトランザクションを署名へ置き換えるのがERC-2612です。 ## ERC-2612 Permitは署名でトークン利用許可額を更新する [ERC-2612](https://eips.ethereum.org/EIPS/eip-2612)は、次のメッセージをEIP-712で署名します。 ```text Permit( address owner, address spender, uint256 value, uint256 nonce, uint256 deadline ) ``` ドメインには一般にトークン名、バージョン、`chainId`、検証コントラクトであるトークンアドレスを入れます。同じメッセージでもチェーンまたはトークンコントラクトが違えば別ダイジェストです。 署名を受け取ったリレイヤーやDAppコントラクトは、トークンの`permit`をトランザクションで呼び出せます。条件を満たすとトークンは所有者のノンスを1つ進め、通常の永続利用許可額を更新します。 ### 有効期限は署名提出の期限 ここは誤解しやすいところです。 ERC-2612の`deadline`は、**その署名を`permit`へ提出できる期限**です。期限内に`permit`が成功して作られた利用許可額が、有効期限到達時に自動で0になるわけではありません。 たとえば18時まで有効な署名を17時に提出し、100トークンの利用許可額が作られた場合、その残りは18時以降もトークン状態に残り得ます。止めるには、利用許可額を使い切るか、上書きするか、0へ変更します。 ### ノンスは署名の再利用を止める OpenZeppelin Contracts `5.6.1`の`ERC20Permit`は、現在の`nonces(owner)`をダイジェストへ入れます。成功時にノンスを消費するため、同じ署名をもう一度出すと、現在ノンスで作るダイジェストと一致せず失敗します。 一方、許可は誰でも提出できます。第三者が先に同じ署名を提出しても、署名が表すのは利用許可額であり、その後の操作まで独占的に表すとは限りません。許可失敗だけを理由に全体を止めるか、すでに作成済みの利用許可額を使って処理を続けるかは、アプリケーション側で設計します。 ドメイン、型、メッセージ、ノンス、有効期限から最終ダイジェストを作る順序は、[EIP-712署名のドメイン・ノンス・有効期限検証](/archives/6010)で段階ごとに確認できます。 ## Permit2はトークンの利用許可と後段権限を分ける Permit2は1つのコントラクトで、`AllowanceTransfer`と`SignatureTransfer`を提供します。どちらも、先に所有者がトークンコントラクトで**Permit2自身を利用先として`approve`**していることが前提です。 ```text layer 1: token allowance owner ── approve ──> Permit2 layer 2: Permit2 permission owner + token ── permit ──> downstream spender ``` つまり、Permit2署名が失効しても、層1のトークン→Permit2利用許可額まで自動で0になるとは限りません。通常のApproval CheckerでPermit2が利用先として見える状態と、Permit2内部の実際のDApp利用先・数量・失効時刻は別々に確認します。 2026-08-30に確認した公式公開ソースでは、`0x000000000022D473030F116dDEE9F6B43aC78BA3`のデプロイ先を示すタグがコミット`cc306b601f172c51bc04334a109e98340456620b`を指していました。この記事はこのコミットへソースを固定して照合し、どの公開チェーンのデプロイも呼び出していません。 ### AllowanceTransferは数量・失効時刻・順序付きノンスを保存する `AllowanceTransfer`は所有者・トークン・利用先ごとに、次の値を詰め込み済み状態へ保存します。 ```text amount uint160 expiration uint48 nonce uint48 ``` 署名する`PermitSingle`には、トークン、数量、失効時刻、ノンス、利用先、`sigDeadline`が入ります。 - `sigDeadline`: 署名をPermit2へ提出できる期限 - `expiration`: 作成された後段利用許可額を使える期限 - `nonce`: 同じ所有者・トークン・利用先で次に受け付ける連番 ERC-2612と違い、署名の提出期限と保存利用許可額の期限が別項目です。フロントエンドで片方だけを表示すると、署名がいつまで提出できるか、作成後の権限がいつ切れるかを区別できません。 ### SignatureTransferは後段利用許可額を残さない `SignatureTransfer`は、署名済み最大数量の範囲でトークンを1回移動し、Permit2内に後段利用許可額を残しません。 再利用防止には順不同ノンスビットマップを使います。連番の次だけを待つのではなく、ノンスを語位置とビット位置へ分け、使ったビットを立てます。そのため、複数の未使用署名を順不同で実行できます。 基本の`PermitTransferFrom`が署名へ含める主な値は、トークン、最大数量、利用先、ノンス、有効期限です。利用先は呼び出し時の`msg.sender`へ結びつきます。 一方、送金内容の受取先と実際の要求数量は、基本形の署名構造体へそのまま入る項目ではありません。要求数量は署名済みの上限以下か検証されます。受取先や注文内容も署名へ固定したい場合は、`permitWitnessTransferFrom`の証明データ設計を含めて確認します。 「1回だけ」は、トークンからPermit2への層1利用許可が消える意味ではありません。また、署名を見ただけで受取先、経路、最終状態更新がすべて拘束されているとも限りません。 ## ERC-7674はトランザクション内だけの一時的利用許可額 [ERC-7674](https://eips.ethereum.org/EIPS/eip-7674)は、2026-08-30時点で**Review** 状態です。Finalではなく、接続相手レビュー中の仕様として扱います。 追加する中心の関数は次の1つです。 ```solidity function temporaryApprove(address spender, uint256 value) public returns (bool success); ``` 一時的利用許可額は、作成した同じトランザクションの間だけ有効です。複数回の`transferFrom`で合計値まで使えますが、未使用分を含めてトランザクション終了時に解除されます。 OpenZeppelin Contracts `5.6.1`では、実装パスも`draft-ERC20TemporaryApproval.sol`です。EIP-1153の`TSTORE` / `TLOAD`を使い、一時的利用許可額を永続利用許可額とは別の一時スロットへ保存します。 ### 利用許可額は一時的と永続の合計を返す ERC-7674対応トークンの`allowance(owner, spender)`は、同じトランザクション内では次の合計を返します。 ```text visible allowance = temporary allowance + persistent allowance ``` `transferFrom`は一時的分を先に消費し、不足分だけ永続利用許可額から引くのが仕様の推奨順です。そのため、一時的を設定しても、以前から残る永続利用許可額が無効になるわけではありません。 OpenZeppelinの`SafeERC20`も、一時的利用許可額が非0の状態で`safeIncreaseAllowance`や`safeDecreaseAllowance`を使うと、合計値を永続利用許可額として書き戻して予想外になる危険を説明しています。一時的対応トークンでは、表示された合計と永続状態を混同しないでください。 ### 通常のなEOAは2つの呼び出しを別トランザクションへ分けられない EOAが`temporaryApprove`だけを1トランザクションとして送り、次のトランザクションで利用先が`transferFrom`しても、一時的利用許可額はすでに解除されています。 付与と支出を同じトランザクションへまとめるには、コントラクト所有者、スマートアカウントの一括処理、または同じ所有者の文脈でまとめて呼ぶ仕組みが必要です。ローカルAnvil再現例はトークンを持つコントラクト所有者が`temporaryApprove`し、その呼び出しの途中で引き出し役に`transferFrom`させます。次のRPC読み取りでは利用許可額が0へ戻ることも確認します。 ここまでの期限と状態を並べると、次の違いになります。
`approve`、ERC-2612 Permit、Permit2 AllowanceTransfer、Permit2 SignatureTransfer、ERC-7674の有効期間と失効条件
署名を提出できる期限と、提出後に作られた利用許可額の期限は別の値です。
## 同じ再現例で正常系と失敗系を比較する ローカル再現例は次の環境へ固定しています。 | 項目 | バージョン・設定 | | --- | --- | | OpenZeppelin Contracts | `5.6.1`へ正確に固定 | | Solidity | `0.8.36` | | Foundry | `1.8.0` | | EVM | Prague | | チェーン / RPC | FoundryとAnvilのローカルチェーンだけ | | トークン | ローカルで発行できる`PermissionToken` | | キー / アカウント | 決定的ローカルテストキーとデプロイしたコントラクトだけ | | 資産 | ローカルテストトークンのみ。市場価値なし | `PermissionToken`はOpenZeppelinの`ERC20Permit`と`draft-ERC20TemporaryApproval`を継承します。そのため`approve`、ERC-2612、ERC-7674はライブラリーの実装を直接テストします。 Permit2は、公式ソースからこの記事で検証する境界だけを切り出した`LocalPermit2`です。本番環境Permit2の複製ではなく、一括処理、証明データ、ERC-1271、`lockdown` API、ノンス無効化API、ガス最適化、特殊トークン互換処理を省いています。 ```solidity // layer 1: token contractのpersistent allowance token.approve(address(permit2), 100 ether); // layer 2: owner・token・spender・amount・expiration・nonce permit2.permit(owner, permission, signature); // downstream spenderがPermit2を通してpullする permit2.transferFrom(owner, recipient, 25 ether, address(token)); ``` ローカルモデルの結果を、正規デプロイの監査結果や互換性保証として使わないでください。統合時は公式インターフェース、デプロイ、チェーン、SDKバージョン、対象トークンの挙動を改めて確認します。 ### テスト対応表 | 機構 | 例 | ローカル入力 | 想定した結果 | | --- | --- | --- | --- | | `approve` | 成功 | 100を`approve`し40を引き出し | 受取先40、残り60 | | `approve` | 不足 | 10に対して11を引き出し | `ERC20InsufficientAllowance` | | ERC-2612 | 成功 | ノンス0、期限内、正しいトークンドメイン | 利用許可額作成、ノンス1 | | ERC-2612 | 期限切れ | 有効期限 + 1秒 | `ERC2612ExpiredSignature` | | ERC-2612 | 再利用済み | 同じ署名を2回提出 | `ERC2612InvalidSigner` | | ERC-2612 | 誤ったドメイン | 別トークンドメインで署名 | `ERC2612InvalidSigner` | | Permit2 AllowanceTransfer | 成功 | トークンの利用許可 + 後段許可 | 両方の利用許可額が減る | | Permit2 AllowanceTransfer | 期限切れ | `sigDeadline`超過 | `Permit2SignatureExpired` | | Permit2 AllowanceTransfer | 再利用済み | 順序付きノンス0を再提出 | `Permit2InvalidNonce` | | Permit2 AllowanceTransfer | 誤ったドメイン | 別検証コントラクトで署名 | `Permit2InvalidSigner` | | Permit2 AllowanceTransfer | 不足 | 後段20に対して21 | `Permit2InsufficientAllowance` | | Permit2 SignatureTransfer | 成功 | 順不同ノンス513、最大40、要求35 | ビットを使用済みにして35を移動 | | Permit2 SignatureTransfer | 再利用済み | ノンス513を再利用 | `Permit2InvalidNonce` | | ERC-7674 | 成功 | 一時的40、同じトランザクションで40引き出し | 成功し、境界後0 | | ERC-7674 | 組み合わせ | 永続30 + 一時的20で35引き出し | 一時的20を先に消費、永続15 | | ERC-7674 | 不足 | 一時的10に対して11 | `ERC20InsufficientAllowance` | 4つのFoundry再現例と2つのAnvil統合例をローカルで確認しました。Anvilの例では別トランザクションから利用許可額を読み、未使用の一時的利用許可額も0へ戻ることを確認しています。メインネットやテストネットのRPC、実在する鍵、実資産は使っていません。 ERC-7674の下層にある一時状態そのものを追う場合は、[EIP-1153のTSTORE・TLOAD、CALL / DELEGATECALL、`revert`、残留ロックを検証する記事](/archives/6021)で、トランザクション終了と通常呼び出し戻り値の違いを確認できます。 ## 取り消し・失効時刻・一度だけの使用を分ける | 方式 | 署名・付与を止める | 作成済み権限を止める | 別に残り得るもの | | --- | --- | --- | --- | | `approve` | 署名前なら送らない | 上書き、`approve(0)`、支出 | トークン利用許可額 | | ERC-2612 | 有効期限、ノンス変化 | トークン利用許可額を上書き / 0 | 有効期限後も作成済み利用許可額 | | Permit2 AllowanceTransfer | `sigDeadline`、順序付きノンス更新 | 失効時刻、`lockdown`、数量0、支出 | トークン→Permit2利用許可額 | | Permit2 SignatureTransfer | 有効期限、順不同ノンス無効化 | 1回使用でノンスビットを消費 | トークン→Permit2利用許可額 | | ERC-7674 | トランザクションを実行しない | 消費、上書き、トランザクション終了 | 既存永続利用許可額 | EIP-2612のノンスを進めても、すでに作成されたトークン利用許可額は消えません。Permit2の後段権限を止めても、トークンからPermit2への利用許可は別状態です。 反対に、ERC-7674の一時的状態が0へ戻っても、同じ所有者・利用先に永続利用許可額があれば`transferFrom`はそちらを使える場合があります。「画面から一時承認が消えた」だけで最終権限を判断しません。 利用者向けに所有者、トークン、利用先、利用許可額を読み、切断と取り消しを分ける手順は、[MetaMaskのSpending上限・`approve`・取り消し・Permit](/archives/6007)で確認できます。呼び出しデータの`to`と引数の利用先を分ける場合は、[ABI・関数識別子・イベントログの読み方](/archives/6005)へ進んでください。 ## フロントエンドで署名前に表示する項目 方式名だけでなく、次の実データを人が確認できる形へ直します。 - 署名アカウント / 所有者 - `chainId` - トークンシンボルではなくトークンコントラクトアドレス - 検証コントラクト - 後段利用先 - 受取先または証明データで拘束される注文内容 - 未加工数量と小数桁適用後の数量 - トークン→Permit2利用許可額の有無と上限 - 後段数量 - ノンスの方式。順序付きか順不同ビットマップか - 署名有効期限 - 保存済み利用許可額失効時刻 - 実行後にどの状態が残るか - 取り消し、`lockdown`、ノンス無効化、トランザクション境界のどれで止まるか `deadline`という同じ単語でも、署名提出期限なのか、保存権限の期限なのかをラベルで分けます。Permit2では`sigDeadline`と`expiration`を別行にし、層1と層2の利用先アドレスも分けます。 ## 採用判断対応表 | 条件 | 向いている候補 | レビューで止める点 | | --- | --- | --- | | トークンがERC-2612を正しく実装済み | ERC-2612 Permit | ドメイン、プロキシ更新、ノンス、許可フロントラン、作成後利用許可額 | | 複数トークンを共通署名インターフェースで扱いたい | Permit2 AllowanceTransfer | トークン→Permit2利用許可、後段失効時刻、公式デプロイ、利用先コード | | 後段利用許可額を残さず1回引き出ししたい | Permit2 SignatureTransfer | トークンの利用許可は残る、受取先 / 証明データ、順不同ノンス、有効期限 | | コントラクト同士で同じトランザクションだけ貸したい | ERC-7674 | Review状態、トークン実装、EIP-1153、永続利用許可額との合計、同一トランザクション内の呼び出し経路 | | 最小の標準互換性を優先する | ERC-20 `approve` | 追加トランザクション、長期利用許可額、更新競合、取り消しUX | どの方式も、名前だけで常に安全になるわけではありません。許可量を小さくしても利用先コードが悪意ある場合は範囲内を使えます。期限を短くしても、期限内の不正使用を止める保証にはなりません。 複数トークンIDを一つのコントラクトで扱う場合は、ERC-20型利用許可額をそのまま当てはめず、全ID運用者とID別数量権限を分けます。[ERC-6909とERC-1155の運用者・利用許可額・一括処理比較](/archives/6049)では、同じ所有者・利用先・ID・数量で権限範囲と消費順を検証しています。 ## コードレビューチェックリスト - [ ] 所有者、チェーン、トークン、利用先、数量を同じ再現例で固定した - [ ] 署名の検証コントラクトと実際の呼び出し先を照合した - [ ] ERC-2612対応トークンか、同名の独自許可か確認した - [ ] 許可有効期限と作成後利用許可額の寿命を分けた - [ ] Permit2のトークンの利用許可層と後段権限層を分けた - [ ] AllowanceTransferの`sigDeadline`と`expiration`を両方確認した - [ ] SignatureTransferの利用先、受取先、証明データ、要求済み数量を確認した - [ ] 順序付きノンスと順不同ノンスビットマップを取り違えていない - [ ] ERC-7674の仕様策定状況とライブラリーの試験的な実装経路を記録した - [ ] 一時的利用許可額と永続利用許可額の合計・消費順をテストした - [ ] 付与と支出が本当に同じトランザクション・所有者文脈か確認した - [ ] 期限切れ、再利用済み、誤ったドメイン、不足した利用許可額を失敗させた - [ ] ローカルモデルの成功を本番環境の監査・安全性保証にしていない ERC-20権限を比較するときに大切なのは、「トランザクションか署名か」だけではありません。**権限を保存するコントラクト、ノンスを消費する場所、提出期限と利用期限、最後に残る利用許可額まで、一つの所有者・トークン・利用先関係として説明すること**です。 利用者向けに、Permitをログイン署名やEIP-7702委任と分け、オリジン、チェーン、コントラクト、利用先、数量、ノンス、有効期限の順で止まって確認する場合は、[ウォレット署名要求の安全チェック](/archives/6025)を参照してください。 複数の許可・実行呼び出しを一つのウォレット要求へまとめる場合も、権限とアトミック実行は別の責務です。[`wallet_sendCalls`とERC-7821の一括呼び出し検証](/archives/6014)で、対応機能、順序付き呼び出し、アカウント実行者、最終状態を分けて確認できます。 この記事にアフィリエイト、トークン交換、ウォレット接続、無制限利用許可を促す販売誘導はありません。将来開発者ツール対応、監査、スポンサー表示を追加する場合も広告であることを明示し、仕様状態、テスト結果、採用判断から分離します。本番環境実装には、対象トークン・デプロイ・利用先ごとの独立したセキュリティレビューが必要です。 ## 確認した一次情報 - [ERC-20 Token Standard](): 確認日 2026-08-30 - [ERC-2612 Permit Extension](): 確認日 2026-08-30 - [Uniswap Permit2 canonical deployment-address tag](): 確認日 2026-08-30 - [Uniswap Permit2 AllowanceTransfer pinned source](): 確認日 2026-08-30 - [Uniswap Permit2 SignatureTransfer pinned source](): 確認日 2026-08-30 - [ERC-7674 Temporary Approval Extension](): 確認日 2026-08-30 - [EIP-1153 Transient storage opcodes](): 確認日 2026-08-30 - [OpenZeppelin Contracts v5.6.1](): 確認日 2026-08-30 - [OpenZeppelin ERC20Permit v5.6.1](): 確認日 2026-08-30 - [OpenZeppelin draft ERC20TemporaryApproval v5.6.1](): 確認日 2026-08-30 - [Solidity 0.8.36 documentation](): 確認日 2026-08-30 - [Foundry v1.8.0](): 確認日 2026-08-30 --- # ERC-4337 UserOperationの失敗解析｜バンドラー・ペイマスター・実行 ERC-4337 UserOperationの失敗を、バンドラー、アカウント検証、ペイマスター、実行、postOpに分け、AAxx、実行結果、内部のrevertを調べます。 正規URL: https://3mikan.com/archives/6013 著者: みかん 公開: 2026-08-30T07:20:00.000Z 更新: 2026-09-02T05:35:00.000Z ERC-4337の`UserOperation`は、通常のトランザクションハッシュだけでは失敗を追えません。バンドラーのメモリープールへ入る前に拒否される場合と、一括処理へ入った後にアカウントの処理が`revert`する場合では、残る証拠が違うためです。 調査では、**送信時のエラー、検証のAAxx、UserOperationEvent、内部の`revert`を同じ`userOpHash`へ対応**させます。最初から「署名エラー」「ペイマスター障害」と決めず、どの段階まで進んだかを先に固定します。 この記事はERC-4337 Final仕様と、`@account-abstraction/contracts` `0.8.0`のEntryPointを基準にします。ERC-7769のRPC仕様は2026年8月30日時点でDraft、ERC-7677のペイマスター向けウェブサービス仕様はReviewです。利用中のバンドラー、EntryPointバージョン、アカウント実装によって返り値が異なる可能性があります。 外部バンドラー、公開RPC、実在ウォレット、デプロイスマートアカウント、実資産は使いません。最後のローカル再現も、特定プロバイダーのメモリープールや評判規則への互換性を証明するものではありません。 ## まず保存する8つの証拠 送信失敗の画面だけを残しても、後から同じ分岐をたどれません。アプリケーションログでは、認証ヘッダーやRPCキーなどの秘密情報を除き、次を一組として保存します。 1. `chainId` 2. 利用したEntryPointアドレスとバージョン 3. `sender` 4. `nonce` 5. 署名前後で使ったUserOperation項目 6. 計算できた場合は`userOpHash` 7. バンドラー / ペイマスターサービスの未加工JSON-RPCエラー 8. オンチェーン取り込み後なら、一括処理トランザクションハッシュとUserOperation実行結果 `eth_sendUserOperation`がメモリープール受付前に失敗すると、一括処理トランザクションハッシュはありません。ERC-7769では、シミュレーションとプール受付を通った場合にだけ`userOpHash`を返す形です。エラーしかない段階でブロックエクスプローラーを探し続けず、まず未加工RPC応答を読みます。 一方、`userOpHash`を受け取った後は、`eth_getUserOperationByHash`と`eth_getUserOperationReceipt`を調べます。通常トランザクションの実行結果、呼び出しデータ、ログを読む基本順は[viemで失敗トランザクションを解析する](/archives/6001)でも確認できます。 ## UserOperationの項目とハッシュを固定する チェーン外のUserOperationは、次の役割に分けると調べやすくなります。 | 項目 | 役割 | 最初に照合する値 | | --- | --- | --- | | `sender` | 実行主体となるスマートアカウント | アドレス、コードの有無、アカウント実装 | | `nonce` | 再利用防止と並列レーン | EntryPointの`getNonce(sender, key)` | | `factory` / `factoryData` | 未デプロイアカウントの作成 | ファクトリーアドレス、予測送信者、初期化結果 | | `callData` | アカウントへ渡す実行内容 | アカウントABI、識別子、内部対象 / 値 / データ | | `callGasLimit` | アカウント主処理実行のガス上限 | シミュレーション結果と実際の使用量 | | `verificationGasLimit` | アカウント / ファクトリー検証の上限 | 検証時の`revert`とガス超過 | | `preVerificationGas` | 呼び出しデータや一括処理追加負荷を含むバンドラー向け費用 | バンドラーの見積もり | | 手数料項目 | UserOperationが支払えるガス単価 | チェーン手数料、最大手数料、優先度手数料 | | ペイマスター項目 | ガススポンサーのコントラクトと検証データ | アドレス、入金、期限、方針、ガス上限 | | `signature` | アカウントが定義する認可データ | 所有者、ダイジェスト、形式、現在のアカウント状態 | EntryPointへ渡すときは`PackedUserOperation`になり、ファクトリー項目は`initCode`、ガス上限は`accountGasLimits`、手数料項目は`gasFees`、ペイマスター項目は`paymasterAndData`へまとめられます。RPCで見た項目名とチェーン上の呼び出しデータを比べるときは、展開されたRPC形式とパック済み形式を混同しないでください。 ### `userOpHash`は署名以外の内容と実行環境を結ぶ ERC-4337では、`userOpHash`は署名を除くUserOperation、EntryPoint、`chainId`へ結び付けられます。v0.8.0はEIP-712互換のUserOperationハッシュを導入しました。 同じ`callData`でも、EntryPointまたは`chainId`が変われば別の認可対象です。EIP-712の`type`、`domain`、`message`を分けて検算する方法は[EIP-712署名の検証手順](/archives/6010)へつなげられます。 アカウントの署名形式はERC-4337が一律に決めません。EOA所有者のECDSAだけでなく、コントラクト所有者、マルチシグ、セッション鍵などを実装できます。コントラクト署名と現在の状態の関係は[ERC-1271の署名検証](/archives/6011)を参照してください。 Passkey認証結果を`UserOperation.signature`へ入れる場合は、チャレンジへ`userOpHash`を結び付けたうえで、オリジン、RP IDハッシュ、フラグ、P-256公開鍵をアカウント方針へ対応させます。[PasskeyスマートアカウントのWebAuthn・P-256検証](/archives/6016)では、EIP-7951のネイティブ実装とSolidityのフォールバック実装も同じ入力例で比較しています。 ### ノンスは192ビットキーと64ビット連番 EntryPointのノンスは、上位192ビットの`key`と下位64ビットの`sequence`として扱われます。キーごとに連番が進むため、単純な「前回値 + 1」だけでは別レーンを説明できません。 ```ts const nonce = await publicClient.readContract({ address: entryPoint, abi: entryPointAbi, functionName: 'getNonce', args: [sender, nonceKey], }) ``` バンドラーの保留中のトランザクションプールに同じ送信者・キーのUserOperationがあると、チェーン上の値だけでは次の連番を判断できない場合があります。通常トランザクションの保留中・置換とノンスを分ける考え方は[ノンスと置換トランザクションの確認方法](/archives/6004)にも共通します。 ## 失敗を5つの段階へ分ける 一つのUserOperationは、すべての段階で同じ種類のエラーを返すわけではありません。 | 段階 | 主な処理 | 失敗時に残りやすい証拠 | | --- | --- | --- | | バンドラー受付 | 項目形式、対応するEntryPoint、シミュレーション、メモリープール / 評判規則 | JSON-RPCエラーコード、メッセージ、データ。トランザクションハッシュなし | | アカウント検証 | デプロイ、署名、有効性範囲、事前資金、ノンス | `FailedOp` / `FailedOpWithRevert`の`AA2x`、内部バイト | | ペイマスター | ウェブサービス方針、入金、コントラクト検証、期限 | サービスエラー、ERC-7769コード、`AA3x`、ペイマスターアドレス、内部バイト | | 実行 | アカウントの`callData`から対象を実行 | `UserOperationEvent.success`、`UserOperationRevertReason`、内部の`revert` | | `postOp` | ペイマスターが実行結果とガス費用を後処理 | `PostOpRevertReason`、`UserOperationEvent.success=false` |
UserOperationがバンドラー受付、アカウント検証、ペイマスター、実行、postOpを進み、各段階で証拠を残す図
トランザクションハッシュがないRPC拒否と、オンチェーン取り込み後にイベントが残る実行失敗を最初に分けます。
## バンドラーのRPCエラーはメモリープールへ入る前の証拠 ERC-7769の`eth_sendUserOperation`は、成功時に`userOpHash`、失敗時に`code`、`message`、必要に応じて`data`を返します。2026年8月30日時点でDraftなので、実装ごとの差を前提に未加工の応答を保存してください。 | コード | 仕様上の意味 | 次に見る場所 | | --- | --- | --- | | `-32602` | UserOperationの項目・形式が不正 | 16進数形式、空バイトの`0x`、ファクトリー / ペイマスター項目の組 | | `-32500` | ウォレット作成またはEntryPoint検証で拒否 | メッセージ内の`AAxx`、EntryPointバージョン | | `-32501` | ペイマスターコントラクトの検証で拒否 | `data.paymaster`、ペイマスター内部の理由 | | `-32502` | ERC-7562検証規則違反 | 命令コード / ストレージアクセス、バンドラーの規則設定 | | `-32503` | アカウントまたはペイマスターの有効期間外 | `validAfter`、`validUntil`、現在時刻 | | `-32504` | ペイマスターが評判規則で制限対象 / 禁止 | ペイマスターのアドレス、バンドラー方針 | | `-32505` | ペイマスターのステーク / ステーク解除の待機時間が不足 | 最低値と現在のステーク | | `-32507` | ウォレット署名確認失敗 | 署名者、`userOpHash`、署名形式 | | `-32508` | ペイマスター残高が保留中のUserOperationを覆えない | ペイマスター残高、プール内の予約分 | たとえば次の応答は、チェーン上実行の`revert`ではありません。バンドラーが署名検証で受付を止めた段階です。 ```json { "jsonrpc": "2.0", "id": 1, "error": { "code": -32507, "message": "AA24 signature error" } } ``` `eth_estimateUserOperationGas`でも、アカウントの内部呼び出しやペイマスターの`postOp`まで含むエラーが返る場合があります。見積もりの`revert`データを読む基本は[`estimateGas`失敗の切り分け](/archives/6003)、独自エラーのABIデコードは[独自エラーの読み方](/archives/6002)へ分けて確認できます。 ## アカウント検証はAA2xと内部バイトを分ける EntryPoint v0.8.0の代表的なアカウント側エラーは次のとおりです。`AAxx`は原因の入口であり、特に`AA23`では内部バイトが本体です。 | エラー | v0.8.0で示す境界 | 確認項目 | | --- | --- | --- | | `AA20 account not deployed` | 送信者コードがなく作成にも進めない | 送信者、ファクトリー / `initCode`、予測アドレス | | `AA21 didn't pay prefund` | EntryPointへの入金とアカウントからの補填で必要額を満たさない | EntryPoint入金、アカウントETH、ガス項目 | | `AA22 expired or not due` | アカウントの`validationData`の期間外 | `validAfter`、`validUntil` | | `AA23 reverted` | `validateUserOp`が`revert` | `FailedOpWithRevert.inner`をアカウントABIでデコード | | `AA24 signature error` | アカウントが署名失敗を返す | 署名者、ダイジェスト、署名形式、アカウント状態 | | `AA25 invalid account nonce` | EntryPointのキー / 連番不一致 | `getNonce`、保留中のトランザクションプール、利用キー | | `AA26 over verificationGasLimit` | 検証が上限を超える | 見積もり、ファクトリー / アカウント検証費用 | 署名不一致は、仕様上`validateUserOp`から`SIG_VALIDATION_FAILED`を返す経路です。アカウントコード自体が`revert`した`AA23`とは分けます。 `AA23`の内部バイトが`0x`でなければ、先頭4バイトをアカウントABIのエラー識別子と照合します。ABI、識別子、イベントデータを手で検算する場合は[呼び出しデータとイベントログの読み方](/archives/6005)を使えます。 ## ペイマスターはウェブサービス・検証・`postOp`を混ぜない 「ペイマスターエラー」には少なくとも三つの場所があります。 ### 1. ペイマスター向けウェブサービスがスポンサーを断る ERC-7677は、ガス見積もり用の仮データを返す`pm_getPaymasterStubData`と、最終データを返す`pm_getPaymasterData`を定義します。これは2026年8月30日時点でReviewです。 方針ID、対象呼び出し、上限、利用者利用条件などをサービスが確認し、バンドラー送信前に拒否できます。この段階ではEntryPointの`AA3x`も一括処理トランザクションハッシュもありません。HTTP状態、JSON-RPCエラー、サービス文脈を保存します。 ### 2. EntryPointが入金と検証を確認する ペイマスター項目があると、EntryPointはアカウントへ要求する`missingAccountFunds`を0にし、代わりにペイマスターの入金と`validatePaymasterUserOp`を確認します。 | エラー | v0.8.0で示す境界 | 確認項目 | | --- | --- | --- | | `AA30 paymaster not deployed` | ペイマスターのコードがない | アドレス、チェーン、デプロイ | | `AA31 paymaster deposit too low` | EntryPoint入金が事前資金未満 | 入金とステークを分けて読む | | `AA32 paymaster expired or not due` | ペイマスターの`validationData`の期間外 | `validAfter`、`validUntil` | | `AA33 reverted` | ペイマスター検証が`revert` | `FailedOpWithRevert.inner`、方針 / 署名 | | `AA34 signature error` | ペイマスター側の署名確認失敗 | ペイマスターのダイジェストと署名対象項目 | | `AA36 over paymasterVerificationGasLimit` | ペイマスター検証ガス超過 | 見積もりと指定上限 | 入金は将来のUserOperationガスを払う残高、ステークは評判上の制約に使うロックです。`AA31`でステークだけを増やしても、入金不足は解消しません。 ### 3. `postOp`が失敗する ペイマスター検証が空でない`context`を返すと、主処理実行後に`postOp`が呼ばれます。v0.8.0では`postOp`の`revert`を`PostOpRevertReason`へ残し、個別UserOperationを失敗として扱う経路があります。 主処理対象の呼び出しが一度成功して見えても、同じ内側の処理で`postOp`が`revert`すれば、その実行状態は取り消され得ます。対象イベントだけを単独で見ず、最後の`UserOperationEvent`と状態を確認してください。 ## 実行では一括処理実行結果と個別結果を分ける バンドラーは複数のUserOperationを一つの`handleOps`トランザクションへまとめられます。そのため、一括処理トランザクションの実行結果`status=success`は、すべての内部呼び出し成功を意味しません。 v0.8.0の`UserOperationEvent`には次が入ります。 ```solidity event UserOperationEvent( bytes32 indexed userOpHash, address indexed sender, address indexed paymaster, uint256 nonce, bool success, uint256 actualGasCost, uint256 actualGasUsed ); ``` アカウントの実行が理由付きで`revert`すると、`UserOperationRevertReason`へ未加工バイトが残ります。一括処理自体が正常に確定していても、対象イベントの`success`が`false`なら個別処理は失敗です。
一括処理トランザクションの実行結果の内側に複数のUserOperation結果と個別のイベントがある関係
トランザクションの実行結果は一括処理全体、UserOperation実行結果の成功・理由・ログは一つの`userOpHash`に対応します。
ERC-7769のUserOperation実行結果は、個別の`success`、`reason`、`logs`に加え、一括処理全体のトランザクションの実行結果を含みます。次の順に読むと、別UserOperationのログを混ぜにくくなります。 1. `userOpHash`が一致するか 2. `sender`、`nonce`、`paymaster`が送信値と一致するか 3. 個別`success`は何か 4. `reason`または理由イベントがあるか 5. 一括処理の`transactionHash`と実行結果の`status`は何か 6. 対象状態と期待イベントが残ったか ## viemで実行結果と内部の`revert`を読み解く viem `2.56.0`ではバンドラークライアントからUserOperation実行結果を取得できます。プロバイダー固有項目へ依存する前に、標準項目を先に取り出します。 ```ts const userOpReceipt = await bundlerClient.getUserOperationReceipt({ hash: userOpHash, }) if (!userOpReceipt) { // pending、未認識、dropの候補。送信時responseとmempool状態へ戻る return } console.log({ userOpHash: userOpReceipt.userOpHash, success: userOpReceipt.success, reason: userOpReceipt.reason, transactionHash: userOpReceipt.receipt.transactionHash, transactionStatus: userOpReceipt.receipt.status, }) ``` 理由イベントのバイトは、失敗した対象またはアカウントのABIでデコードします。 ```ts import { decodeErrorResult, parseAbi, parseEventLogs } from 'viem' const entryPointEvents = parseAbi([ 'event UserOperationRevertReason(bytes32 indexed userOpHash, address indexed sender, uint256 nonce, bytes revertReason)', ]) const [reasonLog] = parseEventLogs({ abi: entryPointEvents, eventName: 'UserOperationRevertReason', logs: userOpReceipt.logs, strict: true, }) if (reasonLog) { const decoded = decodeErrorResult({ abi: targetAbi, data: reasonLog.args.revertReason, }) console.log(decoded.errorName, decoded.args) } ``` ABIがプロキシの実装と一致していない、理由バイトが空、または途中でラッパーエラーが入る場合はデコードできません。元のバイトを消さず、プロキシ実装、アカウントラッパー、対象の順にABI候補を照合します。 ## ローカル再現で10ケースを比較する `@account-abstraction/contracts@0.8.0`の公式EntryPointをローカルチェーンへデプロイし、Solidity `0.8.36`、Foundry / Anvil `1.8.0`、viem `2.56.0`で同じUserOperationを段階的に変えました。 | 入力 | 段階 | 観測結果 | | --- | --- | --- | | 正しい署名・ノンス・事前資金 | 実行 | 一括処理実行結果成功、`UserOperationEvent.success=true` | | 別キーの署名 | アカウント検証 | `AA24 signature error` | | アカウント方針が`revert` | アカウント検証 | `AA23 reverted`と内部の`AccountPolicyDenied()` | | 連番を1つ先へ変更 | ノンス | `AA25 invalid account nonce` | | アカウント残高と入金を0 | 事前資金 | `AA21 didn't pay prefund` | | ペイマスターの入金を0 | ペイマスターの事前資金 | `AA31 paymaster deposit too low` | | ペイマスター方針が`revert` | ペイマスター検証 | `AA33 reverted`と内部の`PaymasterPolicyDenied()` | | ペイマスター期限を過去へ設定 | ペイマスターの有効性 | `AA32 paymaster expired or not due` | | 対象が独自エラーで`revert` | 実行 | 一括処理の実行結果は成功、個別の成功値は`false`、`TargetFailure(0x4337)` | | `postOp`が独自エラーで`revert` | `postOp` | `PostOpRevertReason`、個別の成功値は`false` | 実行失敗のAnvil実行結果では、一括処理トランザクションは`success`、同じ実行結果内の`UserOperationEvent.success`は`false`でした。`UserOperationRevertReason`のバイトを対象ABIでデコードすると、`TargetFailure(0x4337)`として原因を特定できます。 不正署名はオンチェーン取り込み前のシミュレーションで`FailedOp(0, "AA24 signature error")`になり、ERC-7769上ではウォレット署名失敗の`-32507`へ対応する境界です。これは外部バンドラーを動かした結果ではなく、RPC分類と公式EntryPointエラーを対応させたローカル確認です。 ## 本番環境で使う確認順 最後に、障害対応を次の順へ固定します。 1. `chainId`、EntryPointアドレス、バージョン、バンドラーURLの識別子を固定する 2. RPCへ送信したUserOperationと未加工RPC応答を保存する 3. `userOpHash`がなければ、RPCコードから入力項目、シミュレーション、評判、ペイマスターサービスへ分岐する 4. `AA2x`ならアカウントデプロイ、事前資金、期間、署名、ノンスを分ける 5. `AA3x`ならペイマスターサービス、入金、ステーク、検証、期間を分ける 6. `userOpHash`があればUserOperation実行結果と一括処理トランザクションの実行結果の両方を取る 7. `UserOperationEvent`を`userOpHash`で絞り、個別`success`を読む 8. 理由イベントの未加工バイトを保存してから正しいABIでデコードする 9. `postOp`失敗では対象状態が残ったと決めつけず、最終状態を読む 10. プロバイダー固有エラーは標準コードと分けて記録し、バージョン変更時に再確認する トランザクションハッシュがない段階、検証で一括処理全体が`revert`する段階、一括処理は確定して個別実行だけ失敗する段階では、担当も証拠も違います。`AAxx`だけを検索するより、**どのRPC・コントラクト・イベントがその値を返したか**まで対応させると、次の調査先を早く絞れます。 EIP-7702でEOAにアカウント処理を持たせる場合、認可が使うアカウントノンスと、委任先のアプリケーションノンスやERC-4337ノンスキーは別です。[委任を設定・変更・解除するライフサイクル検証](/archives/6017)で、EOA自身が実行する場合のノンス増加と解除後に残る状態を先に分けられます。 UserOperationとは別のチェーン外メッセージを未デプロイアカウントアドレスで検証する場合は、[ERC-6492の未デプロイ署名検証](/archives/6018)へ進めます。UserOperationの`factory` / `factoryData`と、ERC-6492ラッパーのファクトリー呼び出しは用途が違うため、同じファクトリーを使っても成功証拠を共有しません。 一つのウォレット要求へ複数呼び出しをまとめる入口から調べる場合は、[`wallet_sendCalls`とERC-7821の一括呼び出し検証](/archives/6014)へ進んでください。EIP-5792の状態コード`100` / `200` / `500`、アトミック実行に非対応の`5760`、アカウント実行者の巻き戻しをUserOperationの段階とは分けて確認できます。 ## 確認した一次情報 - [ERC-4337 Account Abstraction Using Alt Mempool](): 確認日 2026-08-30 - [ERC-7769 JSON-RPC API for ERC-4337 (Draft)](): 確認日 2026-08-30 - [ERC-7677 Paymaster Web Service Capability (Review)](): 確認日 2026-08-30 - [eth-infinitism Account Abstraction v0.8.0 release](): 確認日 2026-08-30 - [EntryPoint v0.8.0 source](): 確認日 2026-08-30 - [IEntryPoint v0.8.0 events and errors](): 確認日 2026-08-30 - [PackedUserOperation v0.8.0 source](): 確認日 2026-08-30 - [@account-abstraction/contracts 0.8.0](): 確認日 2026-08-30 - [viem Account Abstraction guide](): 確認日 2026-08-30 - [viem 2.56.0 release](): 確認日 2026-08-30 - [Solidity 0.8.36 documentation](): 確認日 2026-08-30 - [Foundry v1.8.0](): 確認日 2026-08-30 --- # wallet\_sendCallsとERC-7821｜一括呼び出しの実装と検証 EIP-5792のwallet_sendCallsとERC-7821のexecuteを分け、対応機能、処理の一体性、状態、revertをwagmi・viem・Foundryで検証します。 正規URL: https://3mikan.com/archives/6014 著者: みかん 公開: 2026-08-30T08:10:00.000Z 更新: 2026-09-02T05:35:00.000Z 複数のコントラクト呼び出しを一度にウォレットへ渡しても、**一つの確認表示、一つのトランザクション、全体をまとめて成功または巻き戻す実行、ガススポンサーが同時に保証されるわけではありません**。EIP-5792はウォレットへ複数呼び出しを依頼して結果を追うRPCを定め、ERC-7821はアカウントが複数呼び出しを実行する最小インターフェースを定めます。 この記事では、ウォレット側の`wallet_getCapabilities`、`wallet_sendCalls`、`wallet_getCallsStatus`と、アカウント側の`execute(bytes32,bytes)`を分けます。そのうえで、2呼び出し成功、二つ目の呼び出しによる全体`revert`、アトミック実行に非対応のウォレット、チェーン不一致をローカル環境で再現します。 基準日は2026年8月30日です。EIP-5792はFinal、ERC-7821はDraftです。実在ウォレット、公開RPC、デプロイアカウント、実資産は使わず、特定ウォレットの対応状況は断定しません。 ## 最初にウォレットとアカウントの二層へ分ける 同じ「一括呼び出し」でも、入口と実行場所は別です。 | 層 | 標準 | 主な役割 | この層だけでは保証しないこと | | --- | --- | --- | --- | | ウォレットRPC | EIP-5792 | 対応機能を返す、順序付き呼び出しを受け取る、実行経路を選ぶ、状態と実行結果を返す | アカウントがERC-7821を使うこと、一つのトランザクション、ガススポンサー | | アカウント実行者 | ERC-7821 | `mode`と`executionData`を検証し、アカウント文脈から呼び出し列を実行する | ウォレット画面、RPCの対応、どの認可経路で呼ばれたか | EIP-5792対応ウォレットは、EOAから複数トランザクションを送る、EIP-7702の委任先を使う、ERC-4337スマートアカウントへUserOperationを送るなど、アカウントに応じた経路を選べます。EIP-5792は、その内部経路をERC-7821へ固定していません。 ERC-7821も、ウォレットから直接呼ばれることを前提にしません。所有者、アカウント自身、ERC-4337のEntryPointなど、誰に`execute`を許すかはアカウント実装が決めます。
ウォレットRPCが複数呼び出しを受け取り、実行経路を選び、アカウント実行者へ渡して状態を返す流れ
EIP-5792は要求と状態の境界、ERC-7821はアカウント内の実行境界です。
EIP-7702でEOAのアドレスとストレージを保ちながらコードを委任する仕組みは[EIP-7702の委任確認手順](/archives/6006)、ERC-4337のEntryPointとUserOperationの失敗境界は[UserOperationの失敗解析](/archives/6013)で詳しく分けています。 ## アトミック実行は四つの意味を混ぜない `atomic`という語を見たら、次の四つを別々に確認します。 1. ウォレットは要求したチェーンとアカウントでアトミックな一括処理を扱えるか 2. 要求はアトミック実行を必須にしたか 3. 実行された呼び出し列は、一つの呼び出しが失敗したとき全体を戻すか 4. 状態の応答は実際の結果をアトミックとして報告したか `wallet_sendCalls`の`atomicRequired: true`は、ウォレットに「アトミックかつ連続した実行ができなければ要求を拒否する」と求めます。これは、ウォレットが必ず一つのトランザクションを作るという指定ではありません。 また、ガススポンサーは別の対応機能です。`atomicRequired: true`から、ペイマスター利用、手数料無料、利用者以外のガス負担を推測してはいけません。 ERC-7821の単一バッチモードは、途中の呼び出しが失敗すると`revert`データを外へ返し、それまでの状態変更も同じ実行の中で取り消します。アカウント側のこの性質と、ウォレットが返す`atomic`項目を対応させて確認します。 ## 対応機能をチェーンごとに先に取得する 送信前に`wallet_getCapabilities`を呼び、接続アカウントと対象チェーンの組み合わせを固定します。wagmi Core `3.4.0`では`getCapabilities`から取得できます。 ```ts import { getCapabilities } from '@wagmi/core' const capabilities = await getCapabilities(config, { account: smartAccount, chainId: 31337, connector, }) console.log(capabilities.atomic?.status) // "supported"、"ready"、"unsupported"などをwalletのresponseどおり保存する ``` 確認するのは、単に`atomic`キーが存在するかではありません。 | 項目 | 保存する値 | 理由 | | --- | --- | --- | | ウォレット | 製品名、Extension / Mobile、バージョン、確認日 | 対応は更新で変わり得る | | アカウント | アドレスとアカウント種別 | 同じウォレットでもアカウントごとに対応機能が異なり得る | | チェーン | `chainId` | 対応機能はチェーンごとに返る | | アトミック実行 | 未加工オブジェクトと`status` | 真偽値へ丸めると準備状態を失う | | その他 | ペイマスター、権限などの未加工対応機能 | アトミック実行とガススポンサーを分ける | この記事のローカルウォレットは、対応側で`{ atomic: { status: "supported" } }`、非対応側で`{ atomic: { status: "unsupported" } }`を返します。これはRPCの分岐を再現するための値で、実在ウォレットの対応証拠ではありません。 ## `wallet_sendCalls` v2の要求を固定する viem `2.56.0`の`sendCalls`は、`version`を省略すると`2.0.0`を使い、`forceAtomic: true`をRPCの`atomicRequired: true`へ変換します。 ```ts import { sendCalls } from '@wagmi/core' const { id } = await sendCalls(config, { account: smartAccount, chainId: 31337, connector, forceAtomic: true, calls: [ { to: target, data: encodeFunctionData({ abi, functionName: 'add', args: [2n] }) }, { to: target, data: encodeFunctionData({ abi, functionName: 'add', args: [3n] }) }, ], }) ``` ウォレットへ届く主要項目は次の形です。 ```json { "version": "2.0.0", "chainId": "0x7a69", "from": "0xSmartAccount", "atomicRequired": true, "calls": [ { "to": "0xTarget", "data": "0x..." }, { "to": "0xTarget", "data": "0x..." } ] } ``` 呼び出しの順序は意味を持ちます。二つ目が一つ目の状態に依存するなら、並べ替えられない前提をウォレットとアカウントの両方で守る必要があります。 `id`は、後で状態を取得するための識別子です。トランザクションハッシュと同じ文字列になる実装があっても、常にトランザクションハッシュだと決め付けず、不透明なIDとして保存します。 ### 拒否は送信前の証拠になる EIP-5792では、アトミック実行を要求したのにウォレットが対応できない場合は`5760`、要求チェーンに対応しない場合は`5710`で拒否できます。どちらも、対象コントラクトの`revert`ではありません。 | コード | 境界 | 次に直す値 | | --- | --- | --- | | `5700` | 必須対応機能が非対応 | 要求の対応機能と任意指定 | | `5710` | チェーンIDが非対応 | 選択済みチェーン、要求の`chainId`、対応機能対応表 | | `5760` | 一体性が非対応 | `atomicRequired`とウォレット / アカウントの準備状態 | | `4001` | 利用者が要求を拒否 | UIで確認した要求と再試行方針 | `experimental_fallback`で個別トランザクションへ切り替える場合、`forceAtomic: true`かつ複数呼び出しなら同じ保証を保てません。アトミック実行を必須にした処理を、黙って連続する個別トランザクションへ変えないでください。 ## ERC-7821の実行で呼び出し列を実行する ERC-7821は、次の最小インターフェースを定めます。 ```solidity interface IERC7821 { function execute(bytes32 mode, bytes calldata executionData) external payable; function supportsExecutionMode(bytes32 mode) external view returns (bool); } ``` この記事で使う単一呼び出し・一括処理 / 既定実行 / `no-opData`モードは、先頭バイトだけが`0x01`の`bytes32`です。 ```solidity bytes32 constant BATCH_MODE = bytes32(uint256(1) << 248); // 0x0100000000000000000000000000000000000000000000000000000000000000 ``` `executionData`は、ERC-7579の`Execution[]`をABIエンコードした値です。 ```solidity struct Execution { address target; uint256 value; bytes callData; } Execution[] memory calls = new Execution[](2); calls[0] = Execution(address(target), 0, abi.encodeCall(target.add, (2))); calls[1] = Execution(address(target), 0, abi.encodeCall(target.add, (3))); account.execute(BATCH_MODE, abi.encode(calls)); ``` OpenZeppelin Contracts `5.6.1`の`ERC7821`は、この単一呼び出し・一括処理 / `no-opData`モードを実装します。既定では`msg.sender == address(this)`だけを許し、未対応モードを拒否し、途中の呼び出しが失敗すると理由を外へ返します。 所有者やEntryPointから呼ぶアカウントでは、認可フックを明示的に上書きします。 ```solidity function _erc7821AuthorizedExecutor( address caller, bytes32 mode, bytes calldata executionData ) internal view override returns (bool) { return caller == owner || caller == authorizedEntryPoint || super._erc7821AuthorizedExecutor(caller, mode, executionData); } ``` これは最小例です。本番環境のアカウントでは、所有者の交代、マルチシグ、セッション鍵、ノンス、署名ドメイン、更新、EntryPointのバージョンなどの認可条件が別に必要です。トークンの利用許可額と一回限りの署名権限を分ける観点は[`approve`・許可・Permit2・一時的利用許可の比較](/archives/6012)にも共通します。 ## EOA・EIP-7702・ERC-4337で到達経路が変わる 同じ`calls`でも、実行者へ届くまでの経路は同じではありません。 | アカウント形態 | ウォレットからの代表的な経路 | ERC-7821へ届く条件 | 先に確認する証拠 | | --- | --- | --- | --- | | 通常のEOA | 個別トランザクション、またはウォレット独自の一括処理機構 | EOA自体に実行者コードはない | アトミック対応、トランザクション数、最終状態と実行結果 | | EIP-7702委任済みEOA | EOAアドレスの文脈で委任先コードを実行 | 委任先がERC-7821を実装し、自身 / 署名者認可を満たす | 認可、委任指標、実装、ノンス | | ERC-4337スマートアカウント | バンドラーがUserOperationをEntryPointへ入れる | アカウントがEntryPointを認可し、`callData`から実行者へ渡す | EntryPointバージョン、`userOpHash`、アカウント検証、実行結果 | ローカルコントラクトでは、所有者からの呼び出し、認可済みEntryPointアドレスからの呼び出し、EIP-7702委任済みEOAの自己呼び出しを別々に通しました。通常のEOAについては、コードがないため同じ`execute`入口を持つとは扱いません。 この比較は経路の説明です。EIP-7702なら必ずERC-7821、ERC-4337なら必ずEIP-5792という関係ではありません。 ## `wallet_getCallsStatus`で最終結果を確認する 送信がIDを返した時点では、処理は確定していない場合があります。`wallet_getCallsStatus`または`waitForCallsStatus`で、同じIDの最終状態を取得します。 ```ts import { getCallsStatus, waitForCallsStatus } from '@wagmi/core' const immediate = await getCallsStatus(config, { connector, id }) const settled = await waitForCallsStatus(config, { connector, id, pollingInterval: 1_000, timeout: 60_000, }) console.log({ immediate: immediate.statusCode, settled: settled.statusCode, atomic: settled.atomic, receipts: settled.receipts, }) ``` EIP-5792 v2の状態コードは、100番台を保留中、200番台を成功、400〜600番台を失敗として分けます。 | 状態 | 意味 | 状態 / 実行結果の確認 | | --- | --- | --- | | `100` | 保留中 | 同じIDで待つ。再送して別一括処理を作らない | | `200` | 成功 | 実行結果、対象状態、期待イベントを照合 | | `400` | チェーン外失敗 | ウォレット側理由と要求を保存 | | `500` | 全体`revert` | アトミック実行の要件、`reverted`の実行結果、状態の巻き戻しを確認 | | `600` | 一部`revert` | `atomic=false`の可能性と各実行結果を個別確認 |
二つの呼び出しが両方成功する場合、全体が戻る場合、一部だけ戻る場合の違い
要求時の要件だけで終わらせず、最終状態、`atomic`項目、実行結果、対象コントラクトの状態を同じIDへ結び付けます。
`status=200`でも、どのトランザクションが含まれたか、実行結果の`status`は何か、対象状態が期待値かを確認します。通常トランザクションの実行結果を読む基本は[失敗トランザクションの確認手順](/archives/6001)へ戻れます。 ## ローカル再現で4つのRPC結果と7つのコントラクト条件を確認する Solidity `0.8.36`、OpenZeppelin Contracts `5.6.1`、Foundry / Anvil `1.8.0`、viem `2.56.0`、wagmi Core `3.4.0`を固定しました。チェーンIDは`31337`です。 コントラクト側では7条件を確認しました。 | 条件 | 結果 | | --- | --- | | 単一バッチモード | `supportsExecutionMode`が`true` | | 所有者が2呼び出しを実行 | `2 + 3`の順で状態が`5` | | 二つ目が独自エラーで`revert` | 一つ目の`+7`も戻り、状態は`5`のまま | | 未対応モード | `UnsupportedExecutionMode`で`revert` | | 未認可呼び出し元 | `AccountUnauthorized`で`revert` | | 認可済みEntryPoint経路 | 同じ実行者へ到達して成功 | | EIP-7702自己呼び出し経路 | 委任済みEOA文脈で成功 | Anvil上のEIP-1193ウォレット表面をwagmi操作から呼んだ結果は次のとおりです。 ```json { "capabilities": { "supported": "supported", "unsupported": "unsupported" }, "twoCallSuccess": { "immediateStatus": 100, "status": 200, "atomic": true, "receiptStatus": "success", "finalValue": "5" }, "secondCallRevert": { "status": 500, "atomic": true, "receiptStatus": "reverted", "valueAfterRollback": "5" }, "rejectedBeforeSubmission": { "unsupportedWallet": 5760, "chainMismatch": 5710 } } ``` 送信直後は`100`、ブロック採用後は`200`でした。二つ目の呼び出しを失敗させた一括処理は実行結果が`reverted`となり、一つ目の状態変更も残りませんでした。 この結果から言えるのは、固定したローカル実装でウォレットRPCとERC-7821実行者を接続できたことです。実在ウォレットのUI、更新流れ、チェーン対応、バンドラー、ペイマスター、セッション鍵、本番環境認可の互換性までは証明しません。 EIP-7702自己呼び出しを実運用へつなぐ前に、指定変更とアカウント状態移行を分けます。[同じEOAへの委任先設定・変更・解除を追う検証](/archives/6017)では、互換 / 非互換ストレージ、認可ノンス、解除後の利用許可額まで確認しています。 複数のブラウザーウォレットが同時にインストールされた環境では、一括処理の要求を作る前にプロバイダーを選びます。[EIP-6963で複数ウォレットを検出・選択する実装](/archives/6015)では、`window.ethereum`の上書き順へ依存せず、選んだ一つのプロバイダーだけへ要求する境界を確認できます。 ## 実ウォレットで記録する確認項目 実環境へ持ち込むときは、成功画面だけでなく次を一組で残します。アドレス、呼び出しデータ、実行結果を共有する際は、個人情報や秘密情報を除いてください。 1. ウォレット名、Extension / Mobile、バージョン、確認日時 2. チェーン名と`chainId` 3. アカウントアドレスとEOA / EIP-7702 / ERC-4337の区分 4. `wallet_getCapabilities`の未加工の応答 5. `wallet_sendCalls`の`version`、`from`、順序付き呼び出し、`atomicRequired` 6. 返された不透明ID 7. `wallet_getCallsStatus`の未加工の応答、`status`、`atomic` 8. 実行結果ごとのトランザクションハッシュと状態 9. 対象状態と期待イベント 10. EntryPointや実行者を使った場合は、そのアドレス、バージョン、実装 実在ウォレットの対応情報を書く場合は、「2026年8月30日、製品バージョンX、環境Y、チェーンZで確認」のように範囲を限定します。別バージョンや別アカウントへ一般化しません。 ## 実装時の判断順 最後に、実装と障害調査の順序をまとめます。 1. ウォレットRPCとアカウント実行者を別の層として図にする 2. 対象アカウント・チェーンの対応機能を取得する 3. `version`、`chainId`、`from`、順序付き呼び出しを固定する 4. アトミック実行が必要なら`atomicRequired`を明示し、非対応時は送信前に止める 5. アカウントのモード、実行符号化、認可済み実行者を確認する 6. EOA / EIP-7702 / ERC-4337のどの経路かを記録する 7. IDを保存し、終了状態になるまで追う 8. 状態コード、`atomic`項目、実行結果、対象コントラクトの状態を照合する 一つの確認表示を一つのトランザクションとみなさず、要求したアトミック性を実行結果とみなさないことが重要です。EIP-5792で入口と結果を追い、ERC-7821を使う場合はアカウント側のモード・認可・巻き戻しを別に検証すれば、一括呼び出しの責任境界を崩さず実装できます。 ## 広告・スポンサーとの分離 本文のガススポンサーやペイマスターはプロトコル上の技術概念です。3MIKANの広告・アフィリエイトスポンサーとは関係ありません。 この記事にウォレット接続、トランザクション送信の誘導、プロバイダー推奨、アフィリエイト販売誘導はありません。将来プロバイダー広告を追加する場合も、仕様状態、対応機能、検証結果、失敗対応表から明確に分離します。 ## 確認した一次情報 - [EIP-5792 Wallet Call API (Final)](): 確認日 2026-08-30 - [ERC-7821 Minimal Batch Executor Interface (Draft)](): 確認日 2026-08-30 - [EIP-7702 Set EOA account code](): 確認日 2026-08-30 - [ERC-4337 Account Abstraction Using Alt Mempool](): 確認日 2026-08-30 - [OpenZeppelin Contracts 5.6.1 release](): 確認日 2026-08-30 - [OpenZeppelin ERC7821 5.6.1 source](): 確認日 2026-08-30 - [viem getCapabilities](): 確認日 2026-08-30 - [viem sendCalls](): 確認日 2026-08-30 - [viem getCallsStatus](): 確認日 2026-08-30 - [wagmi Core getCapabilities](): 確認日 2026-08-30 - [wagmi Core sendCalls](): 確認日 2026-08-30 - [viem 2.56.0 release](): 確認日 2026-08-30 - [wagmi 3.4.0 release](): 確認日 2026-08-30 - [Foundry v1.8.0](): 確認日 2026-08-30 - [Solidity 0.8.36 documentation](): 確認日 2026-08-30 --- # EIP-6963で複数のウォレットを検出・選択する実装 window.ethereumの競合を避け、EIP-6963の通知・要求イベント、プロバイダー登録、明示選択、再接続、EIP-1193リスナーの解除、従来方式への切り替えを実装します。 正規URL: https://3mikan.com/archives/6015 著者: みかん 公開: 2026-08-30T09:15:00.000Z 更新: 2026-09-02T05:35:00.000Z 複数のブラウザーウォレットをインストールした環境で`window.ethereum`だけを読むと、最後に読み込まれたウォレットが上書きする競合へ戻ります。EIP-6963は、各ウォレットが持つEIP-1193プロバイダーをウィンドウイベントで通知し、DAppが候補を並べて利用者に選ばせる仕組みです。 ただし、複数ウォレットを見つけられたことと、表示された名前が本物だと証明できたことは同じではありません。この記事では、**見つけたプロバイダー、利用者が選んだプロバイダー、RPCを送るプロバイダーを同じ一つへ対応させます**。重複通知、遅い通知、メタデータのなりすまし、前回選択、`accountsChanged`、従来方式へのフォールバックまで、外部ウォレットへ触れない模擬で確認します。 基準日は2026年8月30日です。EIP-6963とEIP-1193はいずれもFinalです。実在拡張機能の対応状況、アカウント、残高、公開RPC、署名、トランザクションは検証対象にしていません。 ## `window.ethereum`はEIP-1193の必須配置ではない EIP-1193が標準化するのは、プロバイダーの`request`メソッドとイベントです。ブラウザー上の`window.ethereum`は歴史的な慣習であり、EIP-1193の仕様には含まれません。 複数拡張機能が同じ性質へ注入すると、読み込み順は不安定です。「先にインストールしたウォレット」「利用者が前回選んだウォレット」「画面に表示したウォレット」と、実際に`window.ethereum`へ残ったプロバイダーが一致する保証はありません。 EIP-6963は、共有性質を奪い合う代わりに二つのイベントを使います。 | イベント | 送信側 | 内容 | 実装上の要点 | | --- | --- | --- | --- | | `eip6963:announceProvider` | ウォレット | `info`とEIP-1193 `provider` | 同じプロバイダーが複数回通知しても候補を増やさない | | `eip6963:requestProvider` | DApp | 詳細なし | 通知リスナーを登録した後で振り分けする | ウォレットとDAppのどちらが先に実行されても、ウォレットは要求を受けて再通知できます。DAppは初期探索が終わったように見えても、通知リスナーをページ存続中は残します。これにより、遅れて注入されたプロバイダーも定期取得なしで追加できます。 ## リスナーを先に登録してから要求する 最小のイベント流れは次の順序です。 ```ts const providers = new Map() window.addEventListener('eip6963:announceProvider', (event) => { const { info, provider } = (event as CustomEvent).detail providers.set(info.uuid, { info, provider }) }) window.dispatchEvent(new Event('eip6963:requestProvider')) ``` 先に要求すると、まだリスナーを持たないDAppは同期的な通知を取りこぼします。また、一定時間後に通知リスナーを外すと、遅い通知を扱えません。 ここで残すのは**検出用のウィンドウイベントリスナー**です。後で選択したプロバイダーへ付ける`accountsChanged`などのリスナーは、プロバイダーの切り替え時に解除します。二種類のリスナーの寿命を混ぜないでください。
複数プロバイダーの通知を一覧へ集め、利用者が選んだ一つだけへ要求を送る流れ
検出は候補を収集し、選択は要求先を一つに固定します。
## プロバイダーの詳細をそのまま信用しない 通知イベントの詳細は、次の二つを持ちます。 ```ts interface EIP6963ProviderInfo { uuid: string name: string icon: string rdns: string } interface EIP6963ProviderDetail { info: EIP6963ProviderInfo provider: EIP1193Provider } ``` 各項目の用途とセキュリティ境界を分けます。 | 項目 | 仕様上の役割 | 信用してよい範囲 | 過信すると起きること | | --- | --- | --- | --- | | `uuid` | ページが開いている間のプロバイダー識別子 | 同じUUIDの重複通知を検出 | 異なるプロバイダーが同じUUIDなら改ざん・衝突候補 | | `name` | 利用者へ表示する別名 | テキストとして表示 | 同名を同一ウォレットだと扱う | | `icon` | データURIの画像 | ``要素の`src`として表示 | SVGをHTMLへ展開してスクリプトを実行させる | | `rdns` | セッションをまたいで安定させる意図の識別子 | 前回選択の候補照合 | 機能検出や真正性保証に使う | | `provider` | EIP-1193要求とイベント | 選択後の実行時オブジェクト | 別プロバイダーへ要求を送る、性質を上書きする | EIP-6963は`rdns`が不明、誤り、他ウォレットの模倣になり得ると説明し、追加の検証なしに機能検出へ使わないよう求めています。`name`や`icon`も同じく自己申告です。 ### UUIDの重複と競合を分ける 同じウォレットは要求へ応答して同じ詳細を再通知します。同じUUID、同じプロバイダーオブジェクト、同じ情報なら単なる重複として無視できます。 一方、同じUUIDなのにプロバイダーオブジェクトかメタデータが変わった場合は、後から届いた方で上書きしません。この記事の候補一覧は既存候補を`conflicted`にし、選択できない状態へ変えます。 ```js const existing = providers.get(info.uuid) if (existing?.provider === provider && sameInfo(existing.info, info)) { return 'duplicate' } if (existing) { providers.set(info.uuid, { ...existing, conflicted: true }) return 'conflict' } providers.set(info.uuid, { info: Object.freeze({ ...info }), provider }) ``` 同じ`rdns`でUUIDが異なる候補は、勝手に一つへまとめません。どちらが本物かをメタデータだけでは決められないため、両方を表示し、自動復元を止めます。 ### アイコンは``としてだけ描画する EIP-6963のアイコンはデータURIです。SVGはJavaScriptを含められるため、文字列を`innerHTML`へ渡さず、許可したデータ画像形式だけを``要素の`src`へ設定します。ウォレット名と`rdns`も`textContent`で描画します。 ```js const allowed = /^data:image\/(png|webp|avif|jpeg|svg\+xml)(;[^,]*)?,/i if (allowed.test(info.icon)) { image.src = info.icon } name.textContent = info.name rdns.textContent = info.rdns ``` プロバイダーオブジェクトをスプレッド構文で新しいオブジェクトへ混ぜたり、プロトタイプを走査してウォレット種別を推測したりもしません。選択した実行時オブジェクトを、そのままEIP-1193境界として保持します。 ## 前回選択は`rdns`を候補として保存する `uuid`はページ存続期間中のセッション識別子なので、再読み込み後の永続キーにはしません。この記事の例は、前回選んだ`rdns`だけをローカルストレージへ保存します。 ```json { "rdns": "dev.example.wallet" } ``` 次回の通知で、競合していない同じ`rdns`が**一件だけ**あれば、その候補を事前選択します。0件または2件以上なら復元しません。 事前選択しても、`eth_requestAccounts`は自動送信しません。利用者が接続ボタンを押した時点で、画面に選択中として示したプロバイダーへだけ要求します。保存値は利用者の好みであり、ウォレットの真正性、インストール状態、認可済みアカウントの証拠ではありません。 広告やスポンサー表示を追加する場合も、通知順や利用者が選んだ状態とは別の領域へ置きます。広告契約を理由に既定選択、先頭固定、自動接続を行わない設計が必要です。 ## プロバイダー選択時にセッションリスナーを付け替える 選択後は、同じプロバイダーへ要求とイベントを対応させます。 ```ts function selectProvider(next: EIP6963ProviderDetail) { cleanupSelectedProvider?.() const onAccountsChanged = (accounts: string[]) => setAccounts(accounts) const onChainChanged = (chainId: string) => setChainId(chainId) const onDisconnect = (error: ProviderRpcError) => setDisconnected(error) next.provider.on('accountsChanged', onAccountsChanged) next.provider.on('chainChanged', onChainChanged) next.provider.on('disconnect', onDisconnect) cleanupSelectedProvider = () => { next.provider.removeListener('accountsChanged', onAccountsChanged) next.provider.removeListener('chainChanged', onChainChanged) next.provider.removeListener('disconnect', onDisconnect) } } ``` `accountsChanged`は、そのプロバイダーが現在DAppへ公開するアカウント配列の変更です。`chainChanged`は16進数チェーンIDを返します。別ウォレットを選んだ後も古いリスナーが残ると、画面のアカウントやチェーンが選択中プロバイダーと食い違います。 ReactやAstroの構成要素破棄、SPA画面遷移、プロバイダー切替では、同じ関数参照を`removeListener`へ渡します。無名の関数を登録して別の無名の関数で外そうとしても解除できません。 ### 切断を三つに分ける 「切断」は少なくとも三つあります。 1. EIP-1193 `disconnect`: プロバイダーが全チェーンへRPCを処理できない状態 2. DAppの選択解除: どのプロバイダーへ送るかをローカルUIから外す操作 3. ウォレット側のサイト権限解除: アカウント公開や接続許可をウォレットで変更する操作 注入型プロバイダーはプログラムによる切断を提供しない場合があります。wagmiの`shimDisconnect`はストレージでDApp側の切断状態を模擬します。DAppの「切断」ボタンを、ウォレット権限の削除やプロバイダー自体のネットワーク切断と表示しないでください。 ## 要求エラーを接続成功と分ける 選択したプロバイダーへ`eth_requestAccounts`を送るときは、EIP-1193エラーコードを保存します。 | コード | 意味 | UIでの扱い | | --- | --- | --- | | `4001` | 利用者が要求を拒否 | 接続済みにせず、再試行は利用者操作から始める | | `4100` | 方法またはアカウントが未認可 | 権限状態を見直す | | `4200` | メソッド非対応 | プロバイダーの対応機能として分ける | | `4900` | 全チェーンから切断済み | プロバイダーの接続回復を待つ | | `4901` | 指定チェーンへ未接続 | 選択済みチェーンと要求先を照合する | `4001`を「ウォレットが見つからない」、`4901`を「アカウントが未認可」と表示すると、直す場所が変わってしまいます。検出、選択、認可、チェーン接続状態を別の状態として持ちます。 ## 従来方式へのフォールバックは通知がない時だけ使う EIP-6963は、検出が失敗した場合だけ`window.ethereum`へフォールバックすることを推奨しています。 ```js window.setTimeout(() => { if (registry.eip6963Count === 0 && isEip1193(window.ethereum)) { registry.addLegacy(window.ethereum) } }, 500) ``` 従来方式プロバイダーを表示するときは、「選ばれたウォレット」ではなく「識別情報が未確定のフォールバック候補」と示します。複数拡張機能環境では、`window.ethereum`が利用者の意図したウォレットである保証は戻りません。 従来方式の候補を表示した後に正しいEIP-6963通知が届いたら、この記事の候補一覧は従来方式の候補を外してEIP-6963候補へ置き換えます。最初のタイムアウトを「探索完了」と決め付けず、ウィンドウイベントのリスナーを維持する理由です。 ## wagmiを使う場合も境界は同じ wagmi Core `3.4.0`の`createConfig`は、`multiInjectedProviderDiscovery`を既定で`true`にし、EIP-6963プロバイダーを注入型コネクターへ変換します。 ```ts const config = createConfig({ chains: [mainnet, sepolia], transports: { [mainnet.id]: http(), [sepolia.id]: http(), }, multiInjectedProviderDiscovery: true, }) ``` ライブラリーへ任せる場合は、コネクター一覧、保存した現在のコネクター、再接続の結果をライブラリーの状態から読みます。未加工のウィンドウイベントから作る候補一覧と、ライブラリーの検出結果を同時に選択元にすると、同じプロバイダーが別IDで二重表示される設計になり得ます。検出と永続化をどちらへ任せるか、一つに決めてください。 `injected({ target })`で`window.ethereum`を直接指定する経路は、EIP-6963の複数候補選択とは別です。フォールバックとして使う場合は、複数ウォレット環境で正しいウォレットを保証しないことをUIへ残します。 ## 模擬実演で8条件を再現する [EIP-6963プロバイダー検出デモ](/demos/eip-6963)は、ページ内の`EventTarget`と架空プロバイダーだけを使います。インストール済み拡張機能を列挙せず、アカウント要求、RPC、署名、トランザクションを外へ送りません。 実演では、次の操作を確認できます。 | 例 | 入力 | 期待結果 | | --- | --- | --- | | 複数プロバイダー | 要求へ2件が応答 | 通知順で2件を保持 | | 重複通知 | 同じUUID・プロバイダー・情報 | 件数を増やさない | | UUID競合 | 同じUUID・異なるプロバイダー | 候補を選択不可にする | | 同じ`rdns` | 異なるUUIDで同じ`rdns` | 両方を残し、自動復元しない | | 遅い通知 | 初期表示後に3件目 | リスナーが追加を受け取る | | 従来方式へのフォールバック | 通知0件 | 待機後に識別情報未確定で一件表示 | | プロバイダー切替 | AからBへ選択変更 | Aの3リスナーを外し、Bへ付ける | | 要求エラー | 模擬で拒否・切断 | `4001`と`4900`を別状態にする | 模擬実演では、表に挙げた条件をそれぞれ再現できます。模擬アドレスとチェーンIDはUI状態の分岐確認用であり、実在アカウントやネットワークの証拠ではありません。 ## 症状から直す層を決める | 症状 | 先に見る証拠 | 修正候補 | | --- | --- | --- | | インストール済みなのに0件 | リスナー登録時刻、要求振り分け、遅い通知 | リスナーを先に付け、ページ中維持する | | 別ウォレットが開く | 選択済みUUID、要求したプロバイダーオブジェクト、従来方式の使用有無 | `window.ethereum`単独依存を外す | | 同じウォレットが複数表示 | UUID、プロバイダーオブジェクト、情報の一致 | 同一通知を重複排除する | | 再読み込み後に別候補を選ぶ | 保存した`rdns`、同じ`rdns`の件数 | 一意でなければ事前選択しない | | アカウントが勝手に戻る | リスナーを付けたプロバイダーと後片付け回数 | 旧プロバイダーのリスナーを解除する | | 接続ボタン後も未接続 | エラーコード、`eth_requestAccounts`結果 | `4001`、`4100`、`4900`を分ける | | フォールバック後に候補が増えない | 通知リスナーが残っているか | タイムアウトでリスナーを外さない | ウォレットの検出は、EIP-7702委任の設定とは別です。アドレスへコードを委任する仕組みは[EIP-7702委任の確認](/archives/6006)、署名前にドメイン・型・メッセージを固定する手順は[EIP-712の実装](/archives/6010)、選択したウォレットへ複数呼び出しを渡す境界は[`wallet_sendCalls`とERC-7821](/archives/6014)で分けています。 ## 本番環境へ入れる前の確認項目 1. 通知リスナーを要求より先に登録したか 2. 検出リスナーをページ存続期間中維持したか 3. UUID v4、名前、データURIアイコン、`rdns`、EIP-1193の方法を検証したか 4. 重複UUIDと競合UUIDを分けたか 5. 名前、アイコン、`rdns`を識別情報や機能検出へ使っていないか 6. アイコンを``要素で描画し、メタデータを`innerHTML`へ渡していないか 7. 前回選択は一意な候補の事前選択に限定したか 8. アカウント要求を利用者の明示操作より前に送っていないか 9. プロバイダー切替と構成要素破棄でリスナーを解除したか 10. 従来方式へのフォールバックを通知0件の時だけ使ったか 11. スポンサーや広告が既定選択と並び順へ影響していないか 12. ブラウザー、OS、ウォレットバージョン、確認日を実機検証の証跡へ残したか EIP-6963が解決するのは、複数プロバイダーを発見して利用者が選べる入口です。表示メタデータだけでウォレットを認証したり、アカウント権限、チェーン一致、署名内容、トランザクション結果まで保証したりはしません。検出の後も、選択・要求・イベント・結果を同じプロバイダーへ結び続けることがフロントエンド実装の責任です。 ## 確認した一次情報 - [EIP-6963 Multi Injected Provider Discovery (Final)](): 確認日 2026-08-30 - [EIP-1193 Ethereum Provider JavaScript API (Final)](): 確認日 2026-08-30 - [EIP-6963 reviewed source commit](): 確認日 2026-08-30 - [EIP-1193 reviewed source commit](): 確認日 2026-08-30 - [wagmi Core createConfig multiInjectedProviderDiscovery](): 確認日 2026-08-30 - [wagmi injected connector](): 確認日 2026-08-30 - [wagmi 3.4.0 release](): 確認日 2026-08-30 - [Astro client-side scripts](): 確認日 2026-08-30 --- # パスキー対応スマートアカウントの仕組み｜WebAuthn・P-256を検証 パスキー対応スマートアカウントをWebAuthnの認証結果、チャレンジ、オリジン、RP ID、P-256、EIP-7951、ERC-1271に分け、正常例・改変例とガス量を検証します。 正規URL: https://3mikan.com/archives/6016 著者: みかん 公開: 2026-08-30T11:30:00.000Z 更新: 2026-09-02T05:35:00.000Z パスキー対応スマートアカウントは、顔や指紋をブロックチェーンへ送るアカウントではありません。端末側の認証器が利用者確認を行い、その認証情報の秘密鍵で作った**公開鍵署名**をアプリケーションとアカウントが検証する仕組みです。 この記事では、認証情報登録と認証を分け、`clientDataJSON`、`authenticatorData`、DER署名、P-256検証処理、ERC-1271までを同じ固定入力例で追います。正常系、オリジン不一致、チャレンジ不一致、RP ID不一致、署名改変、sが大きい署名、複数認証情報のテストもローカルで実行します。 仕様状態は2026年8月30日時点で、WebAuthn Level 3がW3C Recommendation、RIP-7212・EIP-7951・ERC-1271がFinalです。 個人のパスキー、生体認証確認画面、実在ウォレット、公開RPC、デプロイ済みアカウント、トランザクション、実資産は使いません。公開検証入力例の秘密値は誰でも知っているテスト用スカラーなので、アカウントや認証情報へ流用できません。 ## パスキー・WebAuthn・P-256・スマートアカウントを分ける 最初に4つの役割を分けます。 | 用語 | この記事での役割 | それだけでは決まらないもの | | --- | --- | --- | | パスキー | パスワードを公開鍵認証情報へ置き換える利用体験・認証情報 | アカウントコントラクト、チェーン、復旧方針 | | WebAuthn | ブラウザー、RP、認証器間の登録・認証手順とデータ形式 | EVMでの検証費用、アカウントインターフェース | | P-256 / secp256r1 | WebAuthnのES256で使える署名曲線 | オリジン、チャレンジ、RP IDが正しいか | | スマートアカウント | 公開鍵・方針・実行権限を持つコントラクトアカウント | 端末が本当に利用者確認したか、認証情報同期方法 | 端末で顔・指紋・PINを使う場合も、その結果は通常「利用者確認を通過した」というフラグと署名へ反映されます。顔画像や指紋テンプレートそのものをRPやチェーンへ渡す設計ではありません。 ただし、すべてのパスキーが同じハードウェア保護、同期、バックアップ、復旧を持つとは限りません。認証器、OS、ブラウザー、認証情報方針を別に確認します。 ## 認証情報作成時に保存するもの [WebAuthn Level 3](https://www.w3.org/TR/webauthn-3/)では、登録と認証は別の手順です。登録ではRPが一度だけ使うチャレンジを作り、`navigator.credentials.create()`を通して認証器へ認証情報作成を依頼します。 アプリケーションは少なくとも次をアカウントまたは安全な登録簿へ対応させます。 - 認証情報ID - COSE公開鍵とアルゴリズム。ES256ならP-256の`qx`、`qy` - 認証情報を作ったRP IDと許可するオリジン方針 - 利用者確認、バックアップ、証明をどう扱うか - 追加認証情報、削除、端末紛失時の復旧方針 秘密鍵は検証側へ保存しません。公開検証入力例では再現のため公開テストスカラーから鍵を作りますが、本番環境認証情報の秘密鍵をサーバー、コントラクト、ログへ出す手順ではありません。 証明は「その認証情報をどの種類の認証器が作ったか」を評価する別の仕組みです。認証結果のP-256署名が正しいことと、証明を信頼することは分けます。 ## 認証結果は何へ署名するか 認証では、RPが新しいチャレンジを渡し、`navigator.credentials.get()`が登録済み認証情報へ認証結果を依頼します。主な返り値は次の通りです。 | 項目 | 内容 | 主な検査 | | --- | --- | --- | | `rawId` / 認証情報ID | どの公開鍵候補を使うか | 登録済み・有効な認証情報か | | `clientDataJSON` | 型、チャレンジ、オリジン、オリジン横断情報 | 要求とブラウザーの文脈へ一致するか | | `authenticatorData` | RP IDハッシュ、フラグ、`signCount`、拡張機能データ | RP・利用者確認・バックアップ状態・カウンター方針 | | `signature` | ES256ならDER形式のP-256署名 | 保存済み公開鍵で検証できるか | | `userHandle` | 検出可能な認証情報の利用者対応 | 期待するアカウントへ対応するか | 署名対象は、単なるチャレンジでもトランザクションハッシュでもありません。 ```text clientDataHash = SHA-256(clientDataJSON) signedBytes = authenticatorData || clientDataHash messageHash = SHA-256(signedBytes) signature = P-256-sign(messageHash) ``` 次の図では、端末内の利用者確認と、外へ渡る認証結果を分けています。
ブラウザー、認証器、認証結果、P-256検証処理、スマートアカウントを結ぶ検証経路
生体認証情報ではなく、公開鍵で検証できる認証結果がアプリケーション側へ戻ります。そのため、P-256署名だけを確認しても不十分で、どのチャレンジ・オリジン・RP IDに対する認証結果かを同じ入力として検査します。 ## チャレンジ・オリジン・RP ID・フラグ・カウンターを読む ### チャレンジは一回の認可対象へ結び付ける チャレンジはサーバーまたはアカウントアプリケーションが作る予測困難な値です。ログインならセッション、スマートアカウントなら`userOpHash`や操作ダイジェストなど、今回許可する対象へ対応させます。 古いチャレンジを再利用したり、署名後に操作を差し替えたりできないよう、期限、ノンス、チェーン、アカウント、呼び出しをどのダイジェストへ含めたかも固定します。WebAuthnが再利用方針を自動で設計してくれるわけではありません。 ### オリジンとRP IDハッシュは別項目 `clientDataJSON.origin`はブラウザーが見たオリジンです。一方、`authenticatorData`の先頭32バイトは`SHA-256(RP ID)`です。 今回の公開検証入力例は次を別々に固定します。 ```text origin = https://wallet.3mikan.test RP ID = wallet.3mikan.test RP ID hash = SHA-256("wallet.3mikan.test") ``` オリジンの文字列だけ、またはRP IDハッシュだけを確認するのではなく、登録時方針と要求文脈へ両方を対応させます。`crossOrigin`や関連オリジンを許可する場合も、暗黙に全オリジンを通さず方針を明示します。 ### フラグは一つの「生体認証済み」真偽値ではない 37バイト以上ある通常の`authenticatorData`では、32バイトのRP IDハッシュの次がフラグ、続く4バイトがビッグエンディアンの`signCount`です。 | ビット | 名称 | 確認する意味 | | ---: | --- | --- | | `0x01` | UP | 利用者が認証操作を行ったことを確認した | | `0x04` | UV | PINや生体認証等による利用者確認が行われた | | `0x08` | BE | 認証情報がバックアップ対象になり得る | | `0x10` | BS | 認証情報が現在バックアップされている | | `0x40` | AT | 証明付き認証情報データを含む | | `0x80` | ED | 拡張機能データを含む | 資産操作でUVを要求するかはアカウント方針です。`BS=1`なら`BE=1`である関係も確認します。ただし、BE / BSは「このプロバイダーなら安全」「別端末から必ず復旧できる」という保証ではありません。 ### カウンターが増えないという理由だけで厳格に拒否しない RPは保存済みカウンターと新しい`signCount`を比べ、認証情報が複製された兆候を検出できます。ただし、カウンターが常に意味のある増分を返すとは限りません。0を返す認証器や、複数端末で使う認証情報の挙動を想定し、リスク信号、追加認証、認証情報の失効などをアプリケーション方針として決めます。 ERC-1271の`isValidSignature`は読み取り専用判定なので、カウンター状態の更新には向きません。カウンターをチェーン上で消費するなら、アカウント実行検証と状態更新を同じトランザクション境界で設計し、第三者が先にカウンターだけ消費するDoSも避けます。
チャレンジ、オリジン、RP IDハッシュ、フラグ、カウンター、P-256署名の検査担当を分けた図
## OpenZeppelin WebAuthnで省略される検査を補う OpenZeppelin Contracts `5.6.1`の`WebAuthn.verify`は、次を検査します。 - 型が`webauthn.get` - チャレンジが期待値と一致 - UP、必要ならUV - BE / BSの組み合わせ - P-256署名とlow-s方針 一方、同バージョンの文書とソースは、オリジン、RP IDハッシュ、カウンター、拡張機能出力、証明を意図的に省略すると明記しています。これはWebAuthn RP全体で不要という意味ではありません。 公開例のERC-1271ラッパーは、保存済みRP IDハッシュを`authenticatorData`と比較し、固定したオリジンを含む`clientDataJSON`へ一致させてから`WebAuthn.verify`を呼びます。 ```solidity if (!_matchesRpId(auth.authenticatorData)) return 0xffffffff; if ( keccak256(bytes(auth.clientDataJSON)) != keccak256(bytes(expectedClientDataJSON(digest))) ) return 0xffffffff; return WebAuthn.verify( abi.encodePacked(digest), auth, credential.qx, credential.qy ) ? IERC1271.isValidSignature.selector : bytes4(0xffffffff); ``` 完全なJSON文字列比較は、項目順や追加項目を許さない教育用例の単純化です。本番環境ではW3C仕様の意味に沿って検証し、クライアントとコントラクトのどちらが何を検査したかを監査できる形にします。 ## DER署名を32バイトの`r,s`へ変換する WebAuthnのES256署名は通常、ASN.1 DERの`SEQUENCE(INTEGER r, INTEGER s)`です。EIP-7951のプリコンパイルはDERを受け取らず、`r`と`s`を各32バイトのビッグエンディアン値として受け取ります。 変換では次を確認します。 1. 外側タグが`0x30`で、長さが入力全体と一致する 2. `r`と`s`が`0x02`のINTEGERである 3. 負数ではなく、不要な先頭0や末尾データがない 4. 符号ビットを避けるための先頭`0x00`だけを外す 5. 左を0で埋め、各32バイトへする 6. アプリケーションがlow-sを要求するなら`N/2`以下へ正規化する 公開検証入力例のDERは70バイトです。 ```text DER = 3044 0220 <32-byte r> 0220 <32-byte s> r = 19c7406a...cff50248 s = 73f92dbe...2efe4e7d ``` EIP-7951は`0 < r,s < N`を要求しますが、low-sを必須にしません。OpenZeppelinの`P256`は署名の展性対策として`0 < s <= N/2`を要求します。sが大きい同値署名が来た場合は、採用するライブラリーの方針に合わせてブラウザー / サーバー側で`N - s`へ正規化するか、明示的に拒否します。 ## RIP-7212・EIP-7951・Solidityフォールバックの違い RIP-7212とEIP-7951は、どちらも`0x0000000000000000000000000000000000000100`へ次の160バイトを渡します。 ```text 32 bytes message hash 32 bytes r 32 bytes s 32 bytes public key qx 32 bytes public key qy ``` 成功時は32バイトの`1`、失敗時は空バイトです。EIP-7951はRIP-7212とのインターフェース互換を維持しつつ、無限大点と`r`比較の境界を修正し、ガスを6,900としています。 ### 2026年8月30日時点の確認対応表 | 対象 | 有効仕様 | アドレス | 有効化 / ガス | 確認範囲 | | --- | --- | --- | --- | --- | | Ethereumメインネット | EIP-7951 | `0x100` | Fusaka 2025-12-03 / 6,900 | EIP-7607とEthereum Foundation発表 | | Baseメインネット | RIP-7212 → EIP-7951相当 | `0x100` | Fjord 2024-07-10で3,450、Azul 2026-05-21から6,900 | Base公式更新文書 | | OP Stack一般 | Fjord仕様にRIP-7212 | `0x100` | チェーンごとの有効化が必要 | OP Stack採用だけで各チェーン有効化を断定しない | | ローカルFoundry | Osaka / EIP-7951 | `0x100` | プリコンパイル実行履歴6,900 | Foundry 1.8.0決定的テスト | チェーン名の一覧を複製して判定せず、対象チェーンのフォーク設定、公式更新記録、既知の有効な入力例への戻り値データを確認します。空の戻り値だけでは「プリコンパイルがない」のか「署名が無効」なのかを区別できません。 ### 同じ入力例で測ったガス Foundry `1.8.0`、Solidity `0.8.36`、オプティマイザーの`runs: 200`、Osaka EVMで、同じ有効入力例をウォームアップ後に測りました。 | パス | ローカルガス | 読み方 | | --- | ---: | --- | | EIP-7951プリコンパイル本体 | 6,900 | プロトコル仕様と実行履歴が一致 | | `P256.verifyNative`の外部ラッパー | 13,424 | 公開鍵 / low-sの確認と外部呼び出しを含むローカルラッパー | | `P256.verify`の自動外部ラッパー | 13,391 | ネイティブがあるためプリコンパイルを選択 | | `P256.verifySolidity`の外部ラッパー | 259,167 | SolidityフォールバックとModExp呼び出しを含む | 33ガスの自動 / ネイティブ差に意味を持たせず、桁の違いを見ます。これはアカウント全体、呼び出しデータ、ERC-4337検証、トランザクション固有ガスを含む総ガスではありません。コンパイラー、ライブラリー、ウォーム / コールド状態、フォークが変われば再計測します。 ネイティブ実装だけを使えばバイトコードとガスを抑えられますが、未対応チェーンでは使えません。OpenZeppelinの`P256.verify`はネイティブ実装を既知の有効な入力例で検出し、未対応ならSolidity実装へフォールバックします。対象チェーンを限定できないアカウントでは、フォールバックを含むデプロイサイズと検証ガス上限も見積もります。 ## ERC-1271アカウントで認証結果を検証する [ERC-1271](https://eips.ethereum.org/EIPS/eip-1271)では、コントラクトアカウントが現在の状態を読んで、有効なら`0x1626ba7e`を返します。公開例は署名へ認証情報IDとWebAuthn認証結果をABIエンコードし、登録済み公開鍵を選びます。 | 例 | 変更したもの | 期待結果 | ローカル結果 | | --- | --- | --- | --- | | 通常 | 変更なし | ERC-1271マジック値 | 合格 | | オリジン不一致 | `clientDataJSON.origin` | 無効 | 合格 | | チャレンジ不一致 | 期待するダイジェスト | 無効 | 合格 | | RP ID不一致 | 期待するRP IDハッシュ | 無効 | 合格 | | 署名改変 | `r`の1ビット | 無効 | 合格 | | sが大きい署名 | `s = N - s` | OpenZeppelin方針で無効 | 合格 | | 不正形式符号化 | 4バイトだけ | `revert`せず無効 | 合格 | | 削除済み認証情報 | 復旧後に旧認証情報を削除 | 無効 | 合格 | Foundryは11/11、ブラウザーのWebCrypto検証は5例を通しました。端末認証情報を使わずに項目と曲線の境界を確認できる[ローカル認証結果実演](/demos/passkey-smart-account)も用意しています。 ERC-1271は署名形式を標準化しないため、呼び出し元とアカウントが同じABIを使う必要があります。コントラクト署名者全般のマジック値、`revert`、状態依存は[ERC-1271でコントラクトアカウント署名を検証する方法](/archives/6011)へつなげられます。 アカウントがまだデプロイされていない段階で同じERC-1271署名を検証する場合は、[ERC-6492のラッパー・巻き戻し・ファクトリー方針の検証](/archives/6018)を使います。ERC-6492は外側のアカウント準備を担当し、WebAuthnチャレンジ、オリジン、RP ID、フラグ、認証情報状態の確認は内側のアカウント実装に残ります。 ERC-4337アカウントへ組み込む場合も、`UserOperation.signature`の中身はアカウント実装が決めます。チャレンジへ`userOpHash`を結び付け、署名不一致をバンドラー受付、アカウント検証、オンチェーン取り込み後の実行と分ける手順は[ERC-4337 UserOperationの失敗解析](/archives/6013)を参照してください。 EIP-7702でコードを委任したEOAアドレスが同じ署名検証処理を提供する構成もあります。EOAのアドレスと委任コードの責務は[EIP-7702委任の確認方法](/archives/6006)で分けています。 ## 複数認証情報と端末紛失を先に設計する パスキーを追加しただけでは、アカウント復旧は完成しません。登録時点で少なくとも次を決めます。 - 同じアカウントへ複数認証情報を登録できるか - 追加・削除を誰が、何署名で、どの遅延後に実行できるか - 最後の認証情報を削除できるか - 同期可能な認証情報と端末に紐付く認証情報を区別するか - 保護者、別端末、ハードウェアキー、ソーシャルリカバリーをどう組み合わせるか - 盗難時に認証情報を失効し、古い認証結果を再利用できないか - 復旧主体がアカウントを奪える中央集権化をどう制限するか 公開例は二つ目の認証情報を追加し、旧認証情報を削除した後に同じ認証結果が無効になること、最後の一つは削除できないこと、管理者以外は追加できないことをテストします。 ただし、この管理者は注意点を見せる教育用です。本番環境で単一のサーバーを復旧管理者にすると、そのサーバーがアカウントを乗っ取れる権限を持ちます。自己呼び出し、保護者の必要署名数、タイムロック、利用者への通知、取り消し可能期間など、脅威モデルに合う経路へ置き換えます。 端末を失った後に初めて二つ目の認証情報を追加する設計では、追加を承認する鍵が残っていない可能性があります。**利用可能な認証情報と独立した復旧経路を、資産を置く前に試す**ことが必要です。 物理セキュリティキーへ端末に紐付くパスキーを置く場合も、認証情報は予備キーへ自動でコピーされません。[Yubico・Titan・Token2・FEITIANの公式仕様比較](/archives/6069)で、容量、PIN / UV、USB-C / NFC、初期化、普段使うキー・予備キー・サービス復旧の境界を確認できます。 ## ブラウザーのバージョンとパスキー機能を分けて確認する MDNのブラウザー互換性データを2026年8月30日に確認したところ、基本的な`PublicKeyCredential`インターフェースは次のバージョンから記録されています。 | ブラウザー | 基本は`PublicKeyCredential` | 注意 | | --- | ---: | --- | | Chrome | 67 | 条件付きUIや各拡張機能のバージョンではない | | Edge | 18 | 現行Chromium版のすべてのパスキー挙動を表す表ではない | | Firefox | 60 | データには初期のUSB U2F制約注記がある | | Safari | 13 | 端末側認証情報、同期、拡張機能は別に確認 | この表は「そのバージョンなら同じパスキーの操作体験、同期、生体認証、復旧が使える」という互換表ではありません。実装時は必要なメソッド、拡張機能、条件付きメディエーション、OS / 認証器の条件を、機能検出と実機テストで確認します。 この記事のブラウザーデモも`navigator.credentials.create()` / `get()`を呼ばず、公開入力例を`crypto.subtle.verify()`で検算するだけです。実在するブラウザーのパスキー画面や操作感は、この検算とは分けて実機で確認する必要があります。 ## 実装前のチェックリスト - [ ] 登録と認証を別手順として設計した - [ ] 認証情報ID、P-256公開鍵、RP ID、オリジン、復旧方針を対応させた - [ ] チャレンジを操作、ノンス、期限、チェーン、アカウントへ結び付けた - [ ] `clientDataJSON`の型、チャレンジ、オリジン、オリジン横断方針を検査した - [ ] `authenticatorData`のRP IDハッシュ、UP、UV、BE / BS、カウンター方針を検査した - [ ] DERを厳密に解析し、採用ライブラリーのlow-s方針へ合わせた - [ ] 対象チェーンでの`0x100`有効化とガスを、公式情報と既知の有効な入力例で確認した - [ ] ネイティブ実装のみの場合とフォールバックを含む場合のデプロイサイズ・検証ガスを計測した - [ ] ERC-1271マジック値またはERC-4337アカウント検証までテストした - [ ] 複数認証情報、最後の認証情報、失効、端末紛失、復旧権限をテストした - [ ] 生体認証データやパスキー同期をチェーン側の保証として説明していない パスキーで守る対象はP-256署名だけではありません。**チャレンジ、オリジン、RP ID、フラグ、認証情報状態、復旧方針を同じアカウント認可へ対応させること**が実装の中心です。 なお、パスキーSDK、スマートアカウント基盤、認証サービス、セキュリティ監査のスポンサーを将来掲載する場合も、広告であることを明示し、仕様状態、チェーン対応、失敗テスト、復旧のセキュリティ評価から分離します。採用サービスを安全証明として扱いません。 ## 確認した一次情報 - [W3C Web Authentication Level 3 Recommendation](): 確認日 2026-08-30 - [EIP-7951 secp256r1 precompile](): 確認日 2026-08-30 - [RIP-7212 secp256r1 precompile](): 確認日 2026-08-30 - [EIP-7607 Fusaka hardfork meta](): 確認日 2026-08-30 - [Base Fjord upgrade](): 確認日 2026-08-30 - [Base Azul P-256 gas update](): 確認日 2026-08-30 - [OpenZeppelin Contracts 5.x WebAuthn](): 確認日 2026-08-30 - [OpenZeppelin Contracts 5.x P256](): 確認日 2026-08-30 - [OpenZeppelin Contracts v5.6.1](): 確認日 2026-08-30 - [ERC-1271 contract signature validation](): 確認日 2026-08-30 - [MDN PublicKeyCredential browser compatibility data](): 確認日 2026-08-30 - [Foundry v1.8.0](): 確認日 2026-08-30 --- # EIP-7702委任のライフサイクル｜設定・変更・解除・保存領域 EIP-7702の委任を同じEOAに設定し、AからBへ変更して解除するまでを、コード、保存領域、ノンス、残高、利用許可額、失敗例に分けて検証します。 正規URL: https://3mikan.com/archives/6017 著者: みかん 公開: 2026-08-30T11:25:00.000Z 更新: 2026-09-02T05:35:00.000Z EIP-7702の委任を解除すると、EOAへ置かれた23バイトの案内は消えます。しかし、EOAのストレージ、ETH残高、トークンコントラクトが持つ利用許可額、委任先独自のセッションやモジュールまで一括で消えるわけではありません。 先に結論を固定すると、**委任を解除しても、ストレージ、利用許可額、セッション状態は同時には消えません**。緊急時に「コードが`0x`へ戻ったから全権限を回収できた」と判断しないことが大切です。 この記事は、[EIP-7702でEOAの実行文脈を確認する基礎記事](/archives/6006)の続編です。同じローカルEOAへ委任先Aを設定し、互換なBへ変更し、ゼロアドレスで解除するまでを、FoundryとAnvil Pragueで追います。 実在ウォレット、公開RPC、メインネットアカウント、実トークンは使いません。掲載アドレスと秘密鍵はすべてAnvil既定のローカル検証値、またはテスト専用値です。 ## まず、解除で変わるものと残るものを分ける | 状態 | 委任を解除した直後 | 保存している場所 | | --- | --- | --- | | 委任指標 | `0xef0100 || delegate`から空コードへ戻る | 認可したEOAのコード | | EOAアドレス | 同じ | Ethereumアカウント状態 | | EOAノンス | 解除認可が有効なら増える | 認可したEOA | | ETH残高 | 解除だけでは移動しない。ガス支払いは別 | 認可したEOA | | 委任先が使ったストレージ | 自動では消えない | 認可したEOAのストレージ | | ERC-20利用許可額 | 自動では消えない | トークンコントラクトの`owner → spender`状態 | | セッション鍵 / モジュール | 保存先と無効化規則による | EOAストレージまたは外部コントラクト | | 委任先実装コード | 解除の対象ではない | 委任先アドレス側 | 「委任を解除する」と「トークンの利用許可を取り消す」は別操作です。利用許可額の所有者、トークン、利用先を確認する手順は、[Spending上限・`approve`・取り消しの確認方法](/archives/6007)で分けています。
同じEOAで委任をAへ設定し、Bへ変更し、解除する4段階
## 認可タプルはチェーンID・委任先・ノンスへ署名する EIP-7702のtype 0x04トランザクションは、次の認可タプルを持ちます。 ```text [chain_id, address, nonce, y_parity, r, s] ``` 署名対象のハッシュは次の形です。 ```text keccak256(0x05 || rlp([chain_id, address, nonce])) ``` - `chain_id`: 認可を有効にするチェーン。`0`ならチェーン間扱い - `address`: EOAが処理を委任するコードアドレス。ゼロアドレスなら解除 - `nonce`: 認可したEOAの現在のノンスと一致させる再利用防止値 - `y_parity / r / s`: 認可者を復元するsecp256k1署名 これは外側のtype 0x04トランザクション署名とは別です。トランザクションを送るアカウントと、認可へ署名する認可者は異なっていても構いません。 クライアントは認可一覧をトランザクション実行より先に、ただしトランザクション送信者のノンスを増やした後に処理します。認可タプルが誤ったチェーンを指定しているか、ノンスが一致しない場合は、そのタプルを省略して次へ進みます。複数の有効なタプルが同じ認可者を対象にする場合は、最後の有効なタプルが最終コードを決めます。 ### 認可者自身が送信する場合はノンスが2回増える 今回のライフサイクルでは、認可者自身がtype 0x04トランザクションを送っています。そのため1回の段階で、次の2回が起きます。 1. トランザクション送信者として認可者EOAのノンスが1増える 2. 有効な認可の処理で認可者EOAのノンスがもう1増える viem 2.56.0では`executor: 'self'`を指定すると、この順序を見越して認可ノンスをトランザクションノンスより1大きく準備します。 ```js const authorization = await authorityClient.signAuthorization({ contractAddress: delegateA, executor: 'self', }) await authorityClient.sendTransaction({ to: authority.address, authorizationList: [authorization], data: configureAndApproveData, }) ``` リレイヤーがトランザクションを送る場合、認可者はトランザクション送信者ではないため、有効な認可による増加は通常1回です。**EIP-7702なら常にノンスが2増える**わけではありません。 ## 同じEOAを変更前 → A → B → 解除で読む 実行環境を固定しました。 | 項目 | 固定値 | | --- | --- | | EIP-7702 | Final、ソースコミット`bbc3f95844c37612a2f1b9e7477990bb717ecfa0` | | 実行仕様 | Prague、コミット`c4deda5b3cfc5c1c8429dcd9159a6fb5636d8486` | | Foundry / Anvil | 1.8.0、コミット`61ae26af36320d4fa1020f7db53785885e29eeb5` | | Solidity | 0.8.36、EVM `prague` | | viem | 2.56.0、タグコミット`063faa52a247233c32445c5eda735ade21ca5801` | | チェーンID | `31337`（ローカル） | | 基準手数料 / ガス価格 | `0`。残高境界だけを分離する再現設定 | | 外部RPC / 実資産 | なし | 段階ごとに、`eth_getCode`相当、EOAノンス、残高、スロット0、スロット1、模擬ERC-20利用許可額を同じ列で読みました。 | 段階 | コード / 対象 | ノンス | 残高 | スロット0 | セッションスロット1 | 利用許可額 | | --- | --- | ---: | ---: | ---: | --- | ---: | | 変更前 | `0x` / なし | 0 | 10,000 ETH | 0 | ゼロアドレス | 0 | | 委任先A | 23バイト / A | 2 | 10,000 ETH | 41 | `0x…bEEF` | 250 | | 委任先B | 23バイト / B | 4 | 10,000 ETH | 42 | `0x…bEEF` | 250 | | 解除 | `0x` / なし | 6 | 10,000 ETH | 42 | `0x…bEEF` | 250 | 10,000 ETHという値はAnvilの初期残高です。基準手数料とガス価格を0へ固定したため変わりません。実ネットワークではトランザクション送信者がガスを支払えば残高は減ります。 [公開した再現データ](/fixtures/eip-7702-lifecycle-6017.json)には、コードの対象とテスト専用アドレスを収録しています。メインネットへのデプロイや利用を推奨するアドレスではありません。 ## 委任先Aを設定してストレージと利用許可額を作る 委任先Aはスロット0へ`number`、スロット1へ`sessionKey`を置きます。同じ自身トランザクション内で模擬トークンへ`approve`も呼びました。 ```solidity contract LifecycleDelegateA { uint256 public number; address public sessionKey; modifier onlySelf() { require(msg.sender == address(this), "only self"); _; } function configureAndApprove( uint256 newNumber, address newSessionKey, address token, address spender, uint256 amount ) external onlySelf { number = newNumber; sessionKey = newSessionKey; require(IApprovalToken(token).approve(spender, amount)); } } ``` 委任済みコードは認可したEOAの文脈で動きます。したがって`number`と`sessionKey`は実装A自身ではなく認可したEOAのストレージへ入り、トークンコントラクトが見る`msg.sender`もそのEOAになります。 利用許可額はEOAのスロットへ保存されません。模擬トークンコントラクト側の対応表へ、次の組み合わせで保存されます。 ```text token.allowance(authority, spender) = 250 ``` この保存先の違いが、解除後にも利用許可額が残る理由です。 ## 互換な委任先Bは同じストレージを引き継ぐ 委任先BはAと同じ順序・同じ型で状態変数を宣言しています。 ```solidity contract LifecycleDelegateB { uint256 public number; address public sessionKey; function incrementNumber() external onlySelf { number += 1; } } ``` AからBへ指定を変えた直後、Bはスロット0の`41`とスロット1のセッション鍵を読みました。`incrementNumber()`後はスロット0が`42`になり、利用許可額は250のままです。 これは、**この小さなA/Bが偶然ではなく意図して同じ配置を共有した**結果です。任意の2実装を差し替えて安全という意味ではありません。 ## 非互換な配置は残存値を別の意味で読む 失敗再現では、同じスロットを別の型と意味へ割り当てました。 ```solidity contract IncompatibleLifecycleDelegate { address public admin; // slot 0: Aではnumber uint256 public dailyLimit; // slot 1: AではsessionKey } ``` Aがスロット0へ保存した`41`は、非互換委任先から`address(0x29)`に見えます。スロット1の`0x…bEEF`は、`dailyLimit = 48879`として読めます。EVMは「名前が違うから危険」と自動判定せず、同じ256ビットスロットをそのまま解釈します。 ローカル再現では期待した管理者と一致しないため`storage collision`で`revert`しました。しかし、実装が明示的に検査しなければ、誤った値のまま処理を続ける可能性があります。 [ERC-7201](https://eips.ethereum.org/EIPS/eip-7201)は、名前空間IDからストレージルートを導く規約を定義しています。EIP-7702自身も委任先変更時の衝突対策として名前空間付きストレージに触れています。ただし、注釈を書くだけでコンパイラーが移行安全性を保証するわけではありません。 変更前には少なくとも次を固定します。 - 古い / 新規実装のストレージ配置と名前空間ID - 追加・削除・型変更した項目 - 対応表、配列、詰め込み済み項目のルートと意味 - 初期化関数 / 移行を誰がいつ実行するか - 古いセッション、モジュール、ノンス、権限を新実装がどう読むか - 巻き戻したときに新しい状態を古いコードがどう読むか ## ゼロアドレスで解除してもストレージは消えない 解除認可では、委任先アドレスへゼロアドレスを指定します。有効ならクライアントは認可者EOAのコードを空に戻し、ノンスを増やします。 ```js const clearAuthorization = await authorityClient.signAuthorization({ contractAddress: zeroAddress, executor: 'self', }) ``` Anvilで解除後に確認した結果は次の通りです。 ```text code.length = 0 nonce = 6 storage slot 0 = 42 storage slot 1 = 0x...bEEF ETH balance = 10000 ETH // zero-fee local run token allowance = 250 ``` EIP-7702には、解除と同時に全ストレージキーを消すプロトコル処理はありません。仕様は、必要ならストレージを消すための専用委任先を設計できると説明しています。 ただし、「専用委任先を一度呼べば、任意のアカウントストレージを完全に消せる」と一般化もできません。対応表や動的配列のすべてのキーを列挙できるか、誰が解除関数を呼べるか、途中`revert`やガス上限をどう扱うかを実装ごとに検証します。
委任解除後もEOAストレージと外部トークン利用許可額が別状態として残る境界
## 利用許可額・セッション鍵・モジュールは保存先ごとに止める 委任の解除は、権限回収の一項目です。少なくとも次を別々に確認します。 ### ERC-20利用許可額 利用許可額はトークンコントラクトが`owner`と`spender`の組み合わせで返します。解除後も`allowance(authority, spender)`を読み、必要なら同じトークン・利用先の取り消しを別トランザクションとして検討します。 ### EOAストレージ内のセッション鍵 コードが空の間は、そのセッション鍵を読む委任先関数もありません。しかし値はスロットに残るため、同じ配置の委任先を再設定すると再び有効と解釈される可能性があります。 セッション鍵を無効化したというためには、キーの記録、権限範囲、有効期限、委任先独自ノンスを、実装が定義する方法で更新した証拠が必要です。 ### 外部登録簿やモジュール モジュール、保護者、権限登録簿が別コントラクトにある場合、EOAのコード変更ではそのコントラクト状態は変わりません。外部コントラクト側の無効化 / 削除結果を読み直します。 ### アプリケーションノンス EIP-7702認可ノンスはアカウントノンスです。委任先が署名付き操作へ使うアプリケーションノンス、セッションノンス、ERC-4337ノンスキーとは別です。[UserOperation失敗を検証・ペイマスター・実行に分ける方法](/archives/6013)でも、EntryPointとアカウント内部の状態を分けて確認しています。 ## 失敗4ケースは実行結果だけで判定しない | 例 | ローカル結果 | 読み方 | | --- | --- | --- | | 誤ったチェーン | 外側の実行結果は成功、認可者コードは0バイト、ノンスは0 | 無効な認可タプルが省略された。実行結果の成功は委任設定の成功を意味しない | | 古いノンス再利用 | 1回目・再利用とも外側の実行結果は成功、ノンスは1のまま | 2回目の認可タプルが省略され、Aへの委任は変わらない | | 非互換ストレージ | 意味検査が`storage collision`で`revert` | コード変更自体と配置安全性は別 | | 委任先呼び出しの`revert` | 実行結果は`reverted`、失敗する委任先への指定とノンス1は残る | 有効な認可は実行時の`revert`で巻き戻されない | ### 誤ったチェーン チェーンID`31338`を指定して署名した認可タプルを、チェーンID`31337`のタイプ0x04トランザクションへ入れました。トランザクション自体はブロックへ入りましたが、認可者EOAのコードとノンスは変わりませんでした。 ### ノンス再利用 ノンス0の認可をリレイヤーが一度使うと、認可者EOAのノンスは1になりました。同じ署名済み認可タプルをもう一度含めた外側トランザクションも成功でしたが、そのタプルはノンス不一致で省略され、ノンスと委任先は変わりませんでした。 「再利用トランザクションが`revert`するはず」と決め打ちせず、認可者コード、委任先、ノンスを最終状態で確認します。 ### 委任先呼び出しの`revert` 失敗する委任先への有効な認可と`fail()`呼び出しを同じtype 0x04トランザクションへ入れると、実行結果は`reverted`になりました。それでも認可者コードは失敗する委任先を指し、ノンスは1です。 後続呼び出しが失敗したから委任も設定されなかった、とは判断できません。トランザクション調査では[実行結果・`revert`・ログ・最終状態の確認順](/archives/6001)と合わせ、認可者コードを独立して読みます。 ## Forge補助関数とAnvilトランザクションの役割を分ける Foundry 1.8.0の`signDelegation`、`attachDelegation`、`signAndAttachDelegation`は、Prague以降のテストで委任済みコードを扱えます。今回のForgeテストでは、次の挙動を個別に確認しました。 - EOAストレージへ書き、実装ストレージは変わらない - A → B → 解除で未加工ストレージと利用許可額が残る - 古いノンスの取り付けを拒否する - 誤ったチェーンの署名が認可者の委任を変えない - 非互換配置が別の意味でスロットを読む - 委任先呼び出しが`revert`しても設定済みの委任が残る ただし`attachDelegation`はテストVMへコードを直接反映する便宜補助関数で、単独では実際のtype 0x04トランザクションにおける認可ノンスの状態遷移を再現しません。そこでAnvil 1.8.0へviemで未加工トランザクションを送り、RPCから`0 → 2 → 4 → 6`を別に確認しました。 このローカル検証では、委任の設定、実行、委任先の変更、解除までを同じEOAで追跡しました。各段階でアカウントコード、ノンス、ストレージを読み直し、メインネットやテストネットには接続していません。 ## 委任先アドレスが同じでもコードの意味は固定とは限らない 委任指標が保持するのは委任先アドレスで、実行時コードハッシュではありません。対象がプロキシなら、EOA側の23バイトが同じまま実装や挙動が変わる場合があります。 委任先がプロキシの場合に実行先と権限を追うときは、[ERC-1967の実装・管理者・ビーコンスロット、更新イベント、ストレージ配置を読む方法](/archives/6020)で、委任先アドレスの先をさらに分解できます。 委任先が更新可能で複数モジュールの状態を持つ場合は、[ERC-7201 Namespaced Storageのルート・項目互換性を検証する手順](/archives/6046)で、コードを切り替えても残るストレージを名前空間ID、ルート、未加工スロットへ分解できます。 確認時は次を分けます。 1. 認可者EOAの23バイトコードと委任先 2. 対象アドレスの現在実行時コード / コードハッシュ 3. プロキシなら実装、管理者、更新イベント 4. ストレージ配置と移行バージョン 5. 確認日時、チェーン、クライアント [EIP-6780](https://eips.ethereum.org/EIPS/eip-6780)以後、既存コントラクトの`SELFDESTRUCT`は、同じトランザクションで作成された例外を除きコードやストレージを削除しません。`SELFDESTRUCT`を一般的な委任先コード消去・差し替え手段として扱わず、認可者側の委任解除と委任先側のコードライフサイクルを別々に読みます。 一括呼び出しを委任先へ持たせる場合も、ウォレット要求とアカウント実行は同じ層ではありません。[`wallet_sendCalls`とERC-7821の実装・検証](/archives/6014)で、EIP-7702の自己呼び出し、アトミックな巻き戻し、ウォレット状態を分けています。 ## 緊急時に確認する順番 実在アカウントで不審な委任が疑われる場合、この記事の検証用秘密鍵やアドレスを使わず、利用ウォレットとチェーンの公式手順を確認してください。少なくとも次を一つずつ記録します。 1. 新しい署名・トランザクション・DApp接続を止める 2. チェーンIDと対象アカウントを固定する 3. アカウントコードが空か23バイトか、委任先はどこか読む 4. アカウントノンス、保留中 / 置換済みトランザクションを確認する 5. 対象コード、プロキシ実装、更新権限、検証を確認する 6. ストレージ名前空間、セッション鍵、モジュール、保護者、アプリケーションノンスを確認する 7. トークンごとの所有者・利用先・利用許可額を確認する 8. ウォレットが対応する解除手順の呼び出し内容と手数料を確認する 9. 実行結果後にコード、ノンス、利用許可額、セッション / モジュール状態を再度読む 実在ウォレットの委任表示や解除UIは、生成画像から判断できません。実機で確認する場合は、ウォレットのバージョン、チェーン、確認日を記録し、アカウントや残高などの個人情報を除いて比較してください。 委任認可へ署名する前に、`eth_sign`、型付きデータ、Permit、SIWEとの違いから確認する場合は、[ウォレット署名要求の見分け方と停止フロー](/archives/6025)で方法、オリジン、チェーン、委任先、ノンスを同じ要求へ対応させてください。 設定後の不審操作履歴で、委任だけでなくシード / 秘密鍵、利用許可、Permit、セッション、スマートアカウントモジュール、端末を同時に疑う場合は、状態変更前に[ウォレット侵害時の証拠保存と7層初動ガイド](/archives/6026)へ進んでください。 ウォレットのサイト権限を外した後に、利用許可額、サーバー側セッション、セッション鍵、モジュール、委任のどれが残るかを横断確認する場合は、[DApp切断と権限解除の違い](/archives/6031)で保存場所、読み取り方法、トランザクション要否を一件ずつ対応させてください。 ## まとめ - ゼロアドレス認可はEOAの委任指標を空コードへ戻す - 解除でもEOAストレージ、残高、トークン利用許可額は自動で消えない - 互換なA / Bは状態を引き継げるが、非互換配置は同じスロットを別の意味で読む - 認可者自身が送信する場合は外側のトランザクションと認可でノンスが2回増える。リレイヤー経路と同一視しない - 誤ったチェーンや古い認可タプルは省略されるため、外側の実行結果が成功しただけで設定成功を断定しない - 委任先呼び出しが`revert`しても、先に処理された有効指定は残る - 対象アドレス、実行時コード、プロキシ更新、ストレージ配置、外部権限を別々に確認する 委任の解除は重要ですが、権限回収の完了条件そのものではありません。**コード、ストレージ、ノンス、残高、利用許可額、セッション / モジュールを、それぞれの保存先で読み直すこと**が最後の確認です。 この記事とローカル検証は特定ウォレット、委任先、取り消し手順、安全性を推奨・保証するものではありません。将来ウォレットセキュリティ、スマートアカウントSDK、監視、監査サービスのスポンサーを掲載する場合も、広告と仕様・検証結果・緊急時確認項目を分離します。 ## 確認した一次情報 - [EIP-7702 Set Code for EOAs](): 確認日 2026-08-30 - [Ethereum execution-specs Prague EOA delegation](): 確認日 2026-08-30 - [Foundry signDelegation](): 確認日 2026-08-30 - [Foundry v1.8.0](): 確認日 2026-08-30 - [viem signAuthorization](): 確認日 2026-08-30 - [viem Sending Transactions with EIP-7702](): 確認日 2026-08-30 - [ERC-7201 Namespaced Storage Layout](): 確認日 2026-08-30 - [ERC-20 Token Standard](): 確認日 2026-08-30 - [EIP-6780 SELFDESTRUCT only in same transaction](): 確認日 2026-08-30 - [Solidity 0.8.36](): 確認日 2026-08-30 --- # ERC-6492とは？未デプロイのスマートアカウント署名を検証 ERC-6492のラッパー、CREATE2で予定するアドレス、状態を戻す検証、信頼するファクトリーの方針、デプロイ後のERC-1271までをローカル環境で確認します。 正規URL: https://3mikan.com/archives/6018 著者: みかん 公開: 2026-08-30T12:26:00.000Z 更新: 2026-09-02T05:35:00.000Z ERC-6492は、**まだコードがない予定アドレスの署名を、ファクトリーによる準備とERC-1271検証へつなぐラッパー規則**です。結論から言えば、`signer.code.length == 0`だけでEOAと決めず、ERC-6492の32バイト末尾を先に検出します。 ただし、ERC-6492がファクトリー、呼び出しデータ、ダイジェストの意味を安全にしてくれるわけではありません。汎用検証役の処理と、アプリケーションが許可するファクトリー・予定署名者・ダイジェスト・期限・ノンスの方針を分けてレビューします。 ## コードがないアドレスはEOAとは限らない 同じ`code.length == 0`でも、意味は一つではありません。 | 署名者の状態 | 通常の検証 | 見落としやすい点 | | --- | --- | --- | | EOA | ECDSA復旧 | ダイジェストの用途、チェーン、ノンス、有効期限は別に必要 | | デプロイ済みコントラクトアカウント | ERC-1271 `isValidSignature` | 現在の所有者や必要署名数などの状態に依存する | | 未デプロイのコントラクトアカウント | ファクトリーで準備してERC-1271 | 検証時点では予定アドレスにコードがない | [ERC-1271の署名検証](/archives/6011)だけでは、呼び出し先にコードがない段階を直接扱えません。そこでERC-6492は、デプロイまたはアカウント準備に必要な呼び出しと、本来のERC-1271署名を一つに包みます。 ## ERC-6492ラッパーの中身 [ERC-6492](https://eips.ethereum.org/EIPS/eip-6492)のラッパーは次の形です。 ```text abi.encode(factory, factoryCalldata, originalERC1271Signature) || 0x6492649264926492649264926492649264926492649264926492649264926492 ``` 末尾は正確に32バイトです。検証役は通常のERC-1271やECDSAより先にこの末尾を調べます。 | 項目 | 役割 | ERC-6492が保証しないもの | | --- | --- | --- | | `factory` | 準備呼び出しの宛先 | 信頼済みファクトリーであること | | `factoryCalldata` | アカウントを使える状態にする任意呼び出しデータ | 識別子、所有者、ソルト、初期化コードの意味 | | `originalERC1271Signature` | アカウントへ渡す内側署名 | ダイジェストの用途、ノンス、有効期限 | | 検出末尾 | ラッパーだと識別する目印 | ラッパー全体の正当性 | ERC-6492は、`factoryCalldata`をCREATE2の`owner, salt`形式へ標準化していません。ファクトリーのインターフェースに依存しないため、プロキシ準備や既存アカウントの追加設定も表現できる一方、アプリケーション側の許可一覧と呼び出しデータ解析は別方針です。 ## CREATE2予定アドレスと期待署名者を対応させる 今回の再現例では、説明を固定するためCREATE2ファクトリーを使います。[EIP-1014](https://eips.ethereum.org/EIPS/eip-1014)の予定アドレスは、デプロイ者、ソルト、初期化コードハッシュから決まります。コンストラクター、ライブラリー、メタデータ、プロキシ初期化関数まで含めた計算境界は、[CREATE2アドレスをファクトリー・ソルト・初期化コードから予測する手順](/archives/6044)で独立検証しています。 ```text predicted = last20( keccak256(0xff || factory || salt || keccak256(accountInitCode)) ) ``` 検証者は「ラッパーに書かれたファクトリーが何か」だけでなく、呼び出しデータの`owner`と`salt`から得た予定アドレスが、外から受け取った期待署名者と一致するかを確認します。署名から勝手に署名者を採用すると、別アカウントの有効な署名を目的のアカウントへ取り違える余地が残ります。 ERC-6492末尾を先に検出し、信頼するファクトリーの方針と準備呼び出しを経てERC-1271へ進む検証順 ## 検証順は末尾、準備、ERC-1271、EOA 実装では次の順序を崩しません。 1. 署名末尾のERC-6492末尾を先に検出する 2. ラッパーなら`factory, factoryCalldata, innerSignature`をデコードする 3. アプリケーション方針でファクトリー、呼び出しデータ、期待署名者を照合する 4. 署名者が未デプロイならファクトリー呼び出しを実行可能な文脈で試す 5. 署名者へ内部署名を渡し、ERC-1271マジック値`0x1626ba7e`を確認する 6. ラッパーでなく、署名者にコードがあれば通常のERC-1271へ進む 7. ラッパーでなく、コードもなければ最後にEOAのECDSAを試す `code.length`を最初の分類にすると、未デプロイのコントラクトアカウントをEOA経路へ落としてしまいます。反対に、末尾があるだけで有効にもできません。デコード失敗、ファクトリーの`revert`、誤ったマジック値、短い戻り値、内側署名不一致はいずれも失敗です。 ## ローカル環境で5段階を確認した [固定した再現結果](/fixtures/erc-6492-6018.json)を公開しています。Foundry / Anvil 1.8.0、Solidity 0.8.36、OpenZeppelin Contracts 5.6.1、viem 2.56.0、ローカルチェーンID 31337だけを使い、公開RPCや実在ウォレットには接続していません。 予定アカウントは`0xc7401d0A1FCf6838deE56c8414f0CD8a70Ca833e`です。これはテスト専用キーとローカルデプロイから得た検証用アドレスで、利用推奨アドレスではありません。 | 段階 | コードバイト | 結果 | 永続化 | | --- | ---: | --- | --- | | 予測した | 0 | 未検証 | なし | | 巻き戻しを伴う検証 | 0 | `true` | アカウントコードは残らない | | 明示的デプロイ | 821 | `true` | 実行結果成功、コードが残る | | デプロイ後のERC-1271 | 821 | `true` | 通常署名で検証 | | デプロイ後のラッパー | 821 | `true` | ラッパーも引き続き検証可能 | Foundryでは、ラッパーのデコード、単純なコード長判定、巻き戻し、明示デプロイ、デプロイ後のERC-1271、デプロイ後のラッパー、EOAへのフォールバック、誤ったファクトリー、誤ったソルト、不正な内部署名、不正形式のラッパー、ファクトリーの`revert`を分けて確認しています。 ## 巻き戻しを伴う検証と明示デプロイを分ける 未デプロイアカウントを検証するには、EVMの中でファクトリー呼び出しとERC-1271呼び出しを実行する必要があります。しかし、読み取り目的の検証がアカウントを永続デプロイすると、検証だけの呼び出しに予想外の副作用が混ざります。 再現例の状態を変更しない経路は、内側呼び出しで一時的にデプロイしてERC-1271結果を1バイトの`revert`データへ載せ、外側でその値だけを読むERC-6492参照手法です。結果が`true`でも、終了後の予定アドレスはコード0バイトのままです。 `eth_call`も状態遷移をシミュレートできますが、RPC呼び出し終了後に状態を永続化しません。ローカルのviem実行では巻き戻しを伴う検証後のコードが0バイト、明示的に状態を変更するトランザクション後は821バイトになりました。 未デプロイ予定アドレスを巻き戻しを伴って検証し、明示デプロイ後は通常のERC-1271とERC-6492ラッパーの両方を検証する段階 状態を残す経路をチェーン上で提供する場合は、任意のファクトリー呼び出し、再入、ガス、検証前の実行、重複デプロイ、ファクトリー更新を含む別の脅威モデルが必要です。読み取り専用APIとデプロイAPIを同じ接続先へ曖昧に混ぜません。 ## 信頼するファクトリーの方針はERC-6492の外側に置く 公開例の`UniversalSigValidator`は標準の検証順を再現します。別コントラクトの`TrustedFactory6492Verifier`は、この例固有の制限として次を確認します。 - ラッパーのファクトリーが固定許可一覧と一致する - 呼び出しデータ識別子が`createAccount(address,bytes32)`である - 呼び出しデータから読む所有者とソルトで予測したアドレスが期待署名者と一致する - 不正形式呼び出しデータを実行前に拒否する この制限を「ERC-6492標準の必須形式」と説明してはいけません。本番環境のファクトリーのインターフェースが違えば解析方法も違います。プロキシ、モジュール設定、アカウント移行などを許すなら、許可する識別子、実装バージョン、コードハッシュ、更新主体、再実行時の挙動をそのファクトリーの仕様に合わせて固定します。 ## 失敗ケースはコードと結果を両方読む | 例 | 検証 | 予定署名者へコードが残るか | | --- | --- | --- | | 誤ったファクトリー | `false` | いいえ | | 誤ったソルト / 別予定アドレス | `false` | いいえ | | 不正内部署名 | `false` | いいえ | | 不正形式ラッパー | `false` | いいえ | | ファクトリーの`revert` | エラー | いいえ | `factory.call`が成功したことと署名が有効であることは別です。ファクトリーが何もデプロイせず成功を返す場合も、予定署名者のERC-1271マジック値を得られなければ成功にしません。`revert`を`false`へ変換するかエラーとして返すかはAPI契約ですが、`true`へ変えてはいけません。 ## デプロイ後もラッパーを先に検出する ERC-6492ラッパーは、アカウントがデプロイされた後も有効な形式です。検証役が「コードがあるから通常ERC-1271」と先に分岐してラッパー全体をアカウントへ渡すと、内側署名としてデコードされず失敗します。 そのため末尾検出を常に先に行い、デプロイ済みなら通常はファクトリー呼び出しを省略して内部署名をERC-1271へ渡します。アカウントが追加準備を必要とする場合は、ERC-1271が失敗した後にラッパーの準備呼び出しを試す経路も仕様にあります。 ただし、過去に有効だった署名が永久に有効という意味ではありません。[ERC-1271は現在の状態を読む](/archives/6011)ため、所有者、必要署名数、認証情報、許可ハッシュなどが変われば結果も変わります。 ## ダイジェスト、再利用、有効期限は別レイヤー ERC-6492は、渡された`bytes32 digest`の意味を定義しません。少なくとも次をアプリケーションの署名対象と状態へ結びつけます。 - 操作と引数 - チェーンIDと検証コントラクト - 期待するスマートアカウントアドレス - アプリケーションノンス - 有効期限 - セッションや権限範囲 [EIP-712のドメイン区切りと再利用対策](/archives/6010)はダイジェストの作り方を担当し、ERC-6492は未デプロイ署名者へ検証を届けます。ラッパーにファクトリー情報が入っていても、ダイジェストへ用途や期限が入る保証はありません。 ログイン用途では、[SIWEをノンス・ドメイン・URI・チェーンIDからセッションまで実装する方法](/archives/6019)がERC-4361メッセージと一度だけ使えるチャレンジを担当します。未デプロイ署名者対応を足す場合も、SIWE項目方針とERC-6492ファクトリーの方針を同じ`true`へ省略しません。 ## ERC-4337とPasskeyへつなぐ境界 [ERC-4337 UserOperation](/archives/6013)では、未デプロイアカウントの`factory`と`factoryData`をEntryPoint経路で扱います。一方、ERC-6492はチェーン外メッセージや別コントラクトが未デプロイアカウント署名を検証する形式です。両方が同じファクトリーを使えても、UserOperation検証成功と任意メッセージの有効性は同じ証拠ではありません。 [Passkeyスマートアカウントの検証](/archives/6016)を内側署名に使う場合は、ERC-6492の外側をデコードした後、アカウント側でWebAuthnチャレンジ、オリジン、RP ID、フラグ、認証情報状態、P-256署名を確認します。ERC-6492末尾がこれらを代行することはありません。 ## 実装前のチェックリスト - [ ] ERC-6492末尾をERC-1271 / ECDSAより先に検出した - [ ] ラッパーを厳密にデコードし、不正形式入力を拒否した - [ ] 外から受け取った期待署名者を基準に検証した - [ ] 許可するファクトリー、識別子、呼び出しデータ、予定アドレスの方針を明示した - [ ] 状態を戻す検証と永続デプロイAPIを分離した - [ ] ERC-1271呼び出し成功だけでなく`0x1626ba7e`を厳密に確認した - [ ] デプロイ後のラップ済み署名もテストした - [ ] 誤ったファクトリー、誤ったソルト、不正内部署名、ファクトリーの`revert`をテストした - [ ] ファクトリー呼び出しの再入、ガス、更新、再実行をレビューした - [ ] ダイジェストへ操作、チェーン、アカウント、ノンス、有効期限を結びつけた - [ ] ローカル検証結果を実在ウォレットやチェーン対応の証拠にしていない ERC-6492対応の中心は「デプロイしてから確認する」ことではありません。**ラッパーを先に識別し、期待署名者と許可した準備呼び出しを対応させ、副作用を制御してからERC-1271の現在結果を読むこと**です。 この記事にスポンサー、アフィリエイト、ウォレット作成、署名要求、デプロイ、資産移動の販売誘導はありません。将来、スマートアカウントSDK、ファクトリーサービス、署名検証サービス、監査の広告を置く場合も広告であることを明示し、仕様、検証結果、失敗対応表、セキュリティレビューから独立させます。 ## 確認した一次情報 - [ERC-6492 Signature Validation for Predeploy Contracts](): 確認日 2026-08-30 - [ERC-1271 Standard Signature Validation Method for Contracts](): 確認日 2026-08-30 - [ERC-4337 Account Abstraction Using Alt Mempool](): 確認日 2026-08-30 - [EIP-1014 CREATE2](): 確認日 2026-08-30 - [OpenZeppelin Contracts 5.x Create2](): 確認日 2026-08-30 - [OpenZeppelin Contracts 5.x SignatureChecker](): 確認日 2026-08-30 - [OpenZeppelin Contracts v5.6.1](): 確認日 2026-08-30 - [Foundry v1.8.0](): 確認日 2026-08-30 - [Solidity 0.8.36](): 確認日 2026-08-30 - [viem simulateContract](): 確認日 2026-08-30 --- # SIWEを安全に実装する｜ノンス・ドメイン・URI・チェーンID・セッション Sign-In with Ethereumを署名確認だけで終わらせず、ERC-4361の各項目、一度だけ使えるノンス、EOA・ERC-1271、Cookie、CSRF、ログアウトまでローカル環境で検証します。 正規URL: https://3mikan.com/archives/6019 著者: みかん 公開: 2026-08-30T13:30:00.000Z 更新: 2026-09-02T05:35:00.000Z SIWE（Sign-In with Ethereum）を安全に実装する中心は、**署名の真偽だけでなく「このサイトが、今、1回だけ発行したログインチャレンジか」を検証すること**です。ERC-4361メッセージを厳密に解析し、サーバーが固定した`scheme`、`domain`、`URI`、`chain ID`、時刻と照合し、ノンスを1回だけ消費してからEOAまたはERC-1271署名を確認します。 成功後も終わりではありません。セッションをアドレスへ結び付け、Cookie、CSRF、ログアウト、ウォレットのアドレス / チェーン変更、コントラクトアカウントの状態変更まで設計して、ようやくウェブ認証の一連の流れになります。 ## SIWEはメッセージ署名からウェブセッションを作る規則 [ERC-4361](https://eips.ethereum.org/EIPS/eip-4361)は、Ethereumアカウントでチェーン外サービスへ認証し、セッションを確立するための標準です。EOAでは人が読めるメッセージを[ERC-191](https://eips.ethereum.org/EIPS/eip-191)形式で署名し、サーバーはメッセージと署名の両方を受け取ります。 ここで確認する対象は2層あります。 | 層 | 確認するもの | 確認しないまま成功にすると起きること | | --- | --- | --- | | チャレンジ方針 | 誰が、何のURIで、どのチェーンへ、いつ、どのノンスを発行したか | 別サイト・別要求・過去署名の使い回し | | 署名者証明 | メッセージに書かれたアドレスが本当に署名したか | 別キー・別コントラクト状態の署名を受理 | 署名が有効でも、チャレンジ方針が違えばログインは失敗です。反対に、項目が正しくても署名が違えばセッションを発行しません。 ## ERC-4361項目を役割ごとに読む ERC-4361のABNFは、項目の名前だけでなく改行、順序、文字種を定義します。独自の`split("\n")`で部分的に読むのではなく、準拠解析器で全体を解析してからアプリケーションの期待値を比較します。 | 項目 | 必須 | 意味 | サーバーでの扱い | | --- | --- | --- | --- | | `scheme` | 任意 | 要求オリジンの方式 | 未指定時の既定はHTTPS。公開環境では期待方式を固定する | | `domain` | 必須 | 署名を要求するホスト名と任意のポート | 設定済みドメインと完全一致させる | | `address` | 必須 | 認証するEthereumアドレス | 署名の期待署名者、セッションの結び付け先にする | | `statement` | 任意 | 人が読む署名目的 | 改行を入れず、認証以上の同意を曖昧に混ぜない | | `URI` | 必須 | 署名の対象となるリソース | ログイン接続先など、サーバーで許可したURIと一致させる | | `version` | 必須 | ERC-4361バージョン | 現行は正確に`1` | | `chain ID` | 必須 | セッションを結ぶチェーン。コントラクトアカウントを解決するチェーン | 許可した値と、そのチェーン専用クライアントへ対応させる | | `nonce` | 必須 | 再利用を防ぐチャレンジ | 8文字以上の英数字。高エントロピー、短期限、1回限りにする | | `issued-at` | 必須 | メッセージ発行時刻 | サーバー時刻と許容ずれを決める | | `expiration-time` | 任意 | メッセージ失効時刻 | この実装では必須方針にして5分後へ固定する | | `not-before` | 任意 | 使用開始時刻 | 未来なら開始前として拒否する | | `request-id` | 任意 | アプリケーション固有要求ID | ログや追跡用途を決め、認可情報だと決めつけない | | `resources` | 任意 | 関連URI一覧 | 解釈はERC-4361の範囲外。列挙だけで認可しない | `domain`と`URI`は同じ文字列を重複して置く項目ではありません。前者は署名要求元のホスト名とポート、後者は署名対象のリソースです。`chain ID`も「現在ウォレットで選ばれているチェーンを何となく記録する値」ではなく、特にERC-1271コントラクトをどのチェーンで解決するかを決めます。 ## 想定オリジンをHostヘッダーから作らない 想定した値は、受信要求から自由に組み立てずサーバー設定へ置きます。たとえば公開URLが`https://login.example`なら、`scheme=https`、`domain=login.example`、`URI=https://login.example/auth/siwe`をデプロイ設定へ固定します。 リバースプロキシの背後でも、`Host`や`X-Forwarded-Host`を無条件に信用しません。公開例の`resolveRequestOrigin()`は次の順で扱います。 1. 通常は正規オリジンを使う 2. 転送済みヘッダーがあれば、接続元が信頼済みプロキシの許可一覧内か確認する 3. `proto`と`host`は単一値だけを受け取る 4. 復元したオリジンが最終許可一覧内かもう一度確認する これにより、攻撃者が`Host: evil.example`を送り、その値をSIWEメッセージへ反映させる経路を閉じます。ウォレット側のオリジン表示・検証と、サーバー側の想定値検証は両方必要です。 ## ノンスは生成・期限・消費を一つの状態として扱う ERC-4361はノンスを8文字以上の英数字と定義しますが、具体的な生成・保存方法までは決めません。公開例ではNode.js `crypto.randomBytes(16)`の128ビット値を16進数へ変換し、保存時はSHA-256ハッシュをキーにして5分のTTLを持たせます。 重要なのは「照合してから後で削除」ではなく、**未使用から使用済みへの変更を1回のアトミックな操作にすること**です。 ```js take(nonce, now) { const key = sha256(nonce); const record = records.get(key); if (!record) throw new AuthError('unknown-or-used-nonce'); records.delete(key); // async signature verificationより前に消費 if (now > record.expiresAt) throw new AuthError('expired-nonce'); return record; } ``` これは1つのNode.jsプロセス内を説明する例です。複数インスタンスで動かす場合は、共有データベースで条件付き`DELETE`や比較・設定を1トランザクションとして実行します。先に`SELECT`して、署名検証後に別要求で`DELETE`すると、同時に届いた2件が両方成功する時間差が残ります。 署名が無効だった場合もノンスは復活させません。攻撃者が失敗を繰り返せるチャレンジを残すより、クライアントへ新しいチャレンジの取得を求める方が状態は単純です。 SIWEメッセージを解析し、期待項目と一度だけ使えるノンスを確認してからEOAまたはERC-1271署名検証とセッション発行へ進む順序 ## 検証順は解析、項目、ノンス、署名、セッション バックエンドは次の順序を固定します。 1. メッセージサイズを制限し、ERC-4361 ABNFとして全体を解析する 2. `scheme`、`domain`、`URI`、`version`、`chain ID`をサーバー側の方針と比較する 3. `issued-at`の時刻ずれ、`expiration-time`、`not-before`をサーバー時刻で確認する 4. ノンスを期限内・未使用から使用済みへアトミックに移す 5. 解析済みアドレスを期待署名者としてEOAまたはERC-1271署名を検証する 6. 新しいセッションIDを作り、アドレス、チェーンID、署名者型へ結び付ける 項目と時刻は署名検証より安いので先に落とせます。ただしノンス消費は非同期のRPC / 署名処理より前です。同じノンスの並行要求が来ても、2件目は`unknown-or-used-nonce`になり、セッションを2つ作れません。 ## EOAとERC-1271を同じ入口で検証する EOAはERC-191メッセージハッシュから署名者を復元します。デプロイ済みのコントラクトアカウントは、メッセージの`chain ID`に対応するクライアントでコードを読み、[ERC-1271](https://eips.ethereum.org/EIPS/eip-1271)の`isValidSignature`結果を確認します。 公開例はviem `2.56.0`の`publicClient.verifyMessage`を使います。 ```js const code = (await publicClient.getCode({ address })) ?? '0x'; const signerType = code === '0x' ? 'eoa' : 'erc1271'; const valid = await publicClient.verifyMessage({ address, message: originalSiweMessage, signature, }); ``` `verifyMessage`へ到達する前に、アプリケーションがチェーンクライアントと想定した項目を決めていることが前提です。「ライブラリーが`true`を返したから、どのドメイン・URI・ノンスでもよい」にはなりません。 [ERC-1271の署名検証](/archives/6011)で説明した通り、コントラクト署名は現在の状態に依存します。所有者、必要署名数、モジュール、停止状態が変われば、同じメッセージと署名でも結果が変わり得ます。 SIWEは[EIP-712のドメイン区切り](/archives/6010)へ置き換える形式ではなく、現行ERC-4361はERC-191の人が読めるメッセージを使います。また、この記事のローカル再現はデプロイ済みERC-1271アカウントまでです。未デプロイのスマートアカウントを扱う場合は、[ERC-6492ラッパーと信頼するファクトリーの方針](/archives/6018)を別途レビューします。 ## ローカル再現で成功系と20の拒否理由を固定した [公開再現データ](/fixtures/siwe-6019.json)は、Node.js 24.x、npm 11.9.0、`siwe` 3.0.0、ethers 6.17.0、viem 2.56.0、Foundry / Anvil 1.8.0、Solidity 0.8.36、OpenZeppelin Contracts 5.6.1、ローカルチェーンID 31337へ固定しています。公開RPC、実在ウォレット、個人の秘密鍵、署名確認画面、実資産は使っていません。 | 成功例 | 結果 | 確認した状態 | | --- | --- | --- | | EOA ERC-191 | `true` | 解析済みアドレスとセッションアドレスが一致 | | デプロイ済みERC-1271 | `true` | ローカルチェーン上のコントラクトアカウントで検証 | | 同一ノンスの並行2要求 | 成功1、拒否1 | アトミックな消費処理でセッション成功を1件に限定 | | 信頼済みプロキシ経由 | `true` | 接続元と最終オリジンの両方が許可一覧を通過 | | Origin + CSRF | `true` | アドレスに紐づくセッションで状態変更を許可 | | ログアウト | 取り消し済み | サーバー側セッションを削除 | | アドレス / チェーン変更 | 取り消し済み | ウォレット文脈とセッション結び付けの不一致 | | ERC-1271所有者削除後 | 署名検証は`false` | 該当するコントラクトセッションを1件失効 | ERC-1271コントラクト自体のFoundry 14テストも通し、EOA、1-of-1、2-of-3、必要署名数の不足、誤った所有者、誤ったダイジェスト、誤ったマジック値、`revert`、期限、所有者 / 停止状態変更を分けています。 失敗は「何となくログイン失敗」ではなく、次の理由へ分類しました。 | 区分 | ローカル再現で拒否した例 | セッション | | --- | --- | --- | | 形式 / オリジン項目 | 不正形式ABNF、誤ったバージョン、方式、ドメイン、URI | 発行しない | | チェーン | 誤ったチェーンID、方針とクライアントのチェーン不一致 | 発行しない | | ノンス | 不明、期限切れ、再利用、不正署名後の再利用 | 発行しない | | 時刻 | 期限切れメッセージ、将来発行時刻、有効開始時刻前 | 発行しない | | 署名者 | 誤ったEOA署名者、誤ったERC-1271所有者 | 発行しない | | プロキシ | 信頼できない転送済みホスト、信頼済みプロキシからの許可されないオリジン | 発行しない | | セッション操作 | 誤ったOrigin、誤ったCSRFトークン | 状態変更を実行しない | `wrong version`は現行ABNF自体に合わないため、解析器段階の`malformed-message`として落ちます。署名を確かめる前に拒否して構いません。 ## セッションCookieにはアドレスや署名を入れない 署名やアドレスをそのまま保有者Cookieにせず、認証成功ごとに256ビットの不透明セッションIDを新しく作ります。サーバー側はIDのハッシュをキーに、少なくとも次を保存します。 - チェックサム済みアドレス - チェーンID - 署名者型（EOA / ERC-1271） - 作成済み / 期限切れになるタイムスタンプ - セッションに紐付くCSRFトークンのハッシュ 公開例のCookieは次の形です。 ```http Set-Cookie: __Host-siwe=; Path=/; Max-Age=28800; Secure; HttpOnly; SameSite=Lax ``` `__Host-`接頭辞を使うため、`Secure`と`Path=/`を付け、`Domain`属性は付けません。`HttpOnly`はJavaScriptからセッションIDを読めなくし、`SameSite=Lax`はサイト横断送信を減らします。ただし、SameSiteだけをCSRF対策の全部にはしません。 ## 状態を変更する要求はOriginとCSRFトークンを確認する Cookieはブラウザーが自動送信します。そのため、プロフィール変更やログアウトなど状態を変更する接続先では、セッションが有効なだけでなく次も確認します。 1. HTTP方法を`POST`などの変更系へ限定する 2. `Origin`が正規オリジンと一致する 3. 要求本文または独自ヘッダーのCSRFトークンが、セッションに結び付くハッシュと一致する 4. サーバー側の認可をリソースごとに実行する CSRFトークン自体をセッションCookieと同じHttpOnly Cookieだけに置くと、要求側から別値として提示できません。ログイン応答から安全にクライアント状態へ渡す、専用接続先で取得するなど、開発基盤の推奨方式に合わせます。トークンをURLへ置くとリファラーやログへ残り得るため避けます。 XSSがあると同一オリジンからCSRFトークンを使われる可能性があります。出力エスケープ、Content Security Policy、依存関係管理などのXSS対策は別の必須層です。 ## ログアウトとアカウント変更でサーバー側セッションを失効する ログアウトはウォレット接続を切るだけではありません。`POST /logout`でOriginとCSRFを確認し、サーバー側のセッション記録を削除してCookieを期限切れにします。 フロントエンドがウォレットの`accountsChanged`または`chainChanged`を受け取った場合も、画面表示だけを変えず、現在セッションを失効させて再認証します。サーバー側セッションがアドレスAへ結び付けされているのに、ウォレット表示だけアドレスBへ変わる状態を残しません。 SIWEチャレンジからアドレスに紐づくセッションを発行し、OriginとCSRFを検証してログアウト、アドレス・チェーン・ERC-1271の状態変更で失効する流れ ERC-1271ではさらに、所有者、必要署名数、モジュールなど署名有効性へ影響する状態変更を検知したとき、該当するセッションを失効する方針が必要です。ウェブフック、イベント監視、重要操作前の再検証、短いセッションTTLを組み合わせます。ローカル再現では所有者を削除し、同じ署名が`true → false`になったことを確認してコントラクトアカウントのセッションを削除しました。 ## SIWE認証と認可を分離する ERC-4361の範囲は認証です。SIWE成功から分かるのは、期待したチャレンジに対してアドレスの署名者証明が通り、ウェブセッションを作れることです。 次の判断は別です。 - 管理画面を使える役割か - 非公開文書を読める所属か - トークンやNFTを現在保有しているか - トランザクションを送ってよいか - 利用許可額、資産移動、メッセージ公開へ同意したか これらを`resources`や`statement`に書いただけでサーバー側の認可へ変換しません。役割データベース、リソース所有権、方針エンジン、追加認証などをリソースごとに判定します。特にSIWEログイン署名を、トークンの利用許可や資産移動への包括同意として再利用してはいけません。 利用者がウォレット確認画面上でSIWEをPermit、一般EIP-712、EIP-7702委任と分け、ドメイン・URI・チェーンID・ノンスを確認する入口は、[ウォレット署名要求の見分け方と9項目チェックリスト](/archives/6025)にまとめています。 ウォレットの切断とサーバー側のログアウトを同じ操作だと考えず、トークン利用許可額、Permit2、スマートアカウントモジュール、EIP-7702委任まで残存権限を確認する場合は、[DApp切断後の六つの権限層](/archives/6031)を参照してください。 ## 実装前のチェックリスト - [ ] ERC-4361 ABNF全体を準拠解析器で読み、項目サイズも制限した - [ ] 方式、ドメイン、URI、バージョン、チェーンIDをサーバー側の固定方針と比較した - [ ] 要求Hostや転送済みヘッダーを想定した値へ無条件に採用していない - [ ] 信頼済みプロキシの接続元と最終許可済みオリジンを両方確認した - [ ] ノンスは暗号学的無作為、短いTTL、ハッシュ保存、1回限りにした - [ ] 同時要求でもノンスの成功を1件にするトランザクション処理を実装した - [ ] 発行時刻のずれ、有効期限、有効開始時刻をサーバー時刻で確認した - [ ] EOA ERC-191と、指定チェーン上のデプロイ済みERC-1271を検証した - [ ] 署名失敗後に同じノンスを復活させていない - [ ] セッションIDを新しい乱数値にし、アドレス / チェーン / 署名者型へ結び付けた - [ ] `__Host-`、Secure、HttpOnly、Path、SameSite、TTLをレビューした - [ ] 状態を変更する要求でOriginとセッションに紐付くCSRFトークンを確認した - [ ] ログアウト、セッション有効期限、アドレス / チェーン変更でサーバー側セッションを失効した - [ ] ERC-1271状態変更時の再検証・失効方法を決めた - [ ] 認証とリソース認可、トランザクション / 資産同意を分離した - [ ] 利用制限、TLS、ログの秘密情報除外、XSS対策、共有ストアの障害挙動をレビューした - [ ] ローカル再現結果を全ウォレット・プロバイダー・チェーン対応やセキュリティ監査の証拠にしていない SIWE実装の完了条件は「署名ライブラリーが`true`を返した」ではありません。**想定するオリジンと要求を固定し、一度だけ使えるチャレンジを先に消費し、署名者の現在の状態を確認して、失効できるアドレス紐づけのセッションへ移すこと**です。 この記事にスポンサー、アフィリエイト、ウォレット接続、署名要求、トランザクション、資産移動の販売誘導はありません。将来、ウォレット、認証プロバイダー、RPC、セッションサービス、監査サービスの広告を置く場合も広告であることを明示し、項目方針、ノンス状態、署名検証、セッション / CSRF、失敗対応表、セキュリティレビューから独立させます。 ## 確認した一次情報 - [ERC-4361 Sign-In with Ethereum](): 確認日 2026-08-30 - [ERC-191 Signed Data Standard](): 確認日 2026-08-30 - [ERC-1271 Standard Signature Validation Method for Contracts](): 確認日 2026-08-30 - [Sign-In with Ethereum TypeScript library](): 確認日 2026-08-30 - [SIWE backend quickstart](): 確認日 2026-08-30 - [SIWE security considerations](): 確認日 2026-08-30 - [viem publicClient.verifyMessage](): 確認日 2026-08-30 - [OWASP Session Management Cheat Sheet](): 確認日 2026-08-30 - [OWASP CSRF Prevention Cheat Sheet](): 確認日 2026-08-30 - [MDN Using HTTP cookies](): 確認日 2026-08-30 - [Node.js crypto.randomBytes](): 確認日 2026-08-30 --- # プロキシコントラクトの読み方｜ERC-1967のスロット・実装・管理者・更新 ERC-1967の実装・管理者・ビーコン用スロットをRPCで直接読み、Transparent・UUPS・Beacon、初期化、保存領域の衝突、更新履歴までローカル環境で検証します。 正規URL: https://3mikan.com/archives/6020 著者: みかん 公開: 2026-08-30T14:25:00.000Z 更新: 2026-09-02T05:35:00.000Z プロキシコントラクトを読む出発点は、**プロキシアドレスが状態と外部呼び出しの入口、実装アドレスが実行コードの置き場**だと分けることです。ブロックエクスプローラーに検証済みソースや「プロキシ」と表示されても、現在の実行先、更新権限、過去の変更、ストレージ配置まで同時に安全だとは分かりません。 この記事では、ERC-1967の実装、管理者、ビーコンという3つのストレージスロットを同じブロックで読みます。その後にバイトコード、ソース、ABI、呼び出し挙動、権限、イベント、ストレージ配置を対応させます。調査は読み取り専用とローカル再現だけで、公開RPC、実在ウォレット、署名、更新トランザクション、資産は使いません。 ## プロキシアドレスと実装アドレスは役割が違う 通常の`delegatecall`型プロキシでは、利用者はプロキシアドレスを呼びます。プロキシは実装のコードを実行しますが、`address(this)`、残高、ストレージはプロキシ側です。 | アドレス | 主な役割 | 単独では分からないこと | | --- | --- | --- | | プロキシ | 利用者向けアドレス、状態、残高、イベント発行元、`delegatecall`入口 | 現在・過去の実行コード、更新権限の全体 | | 実装 | 関数コード、ABI候補、ストレージ配置の宣言 | プロキシに保存された値、現在そのプロキシが本当に参照するか | | 管理者 / 所有者 | 更新を開始できる権限候補 | マルチシグ、タイムロック、ガバナンス、所有者履歴の健全性 | | ビーコン | 複数プロキシが共有する実装参照先 | ビーコン所有者と、各プロキシに残る個別状態 | 実装を直接読み取る（Read）と、その実装自身のストレージを読みます。プロキシ経由の結果とは別です。書き込み（Write）を送る前の基本確認は[直コンで検証済みコントラクト・ABI・シミュレーションを確認する順番](/archives/1005)、呼び出しデータとログの読み方は[ABI・関数識別子・イベントログの手検算](/archives/6005)で確認できます。 ## ERC-1967の3スロットを未加工RPCで読む [ERC-1967](https://eips.ethereum.org/EIPS/eip-1967)は、実装、ビーコン、管理者を実装側の通常ストレージと衝突しにくい固定位置へ置きます。各値は識別文字列のKeccak-256から1を引いた値です。 | スロット | 正確な位置 | 32バイト語の読み方 | | --- | --- | --- | | 実装 | `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` | 下位20バイトが実装候補 | | 管理者 | `0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103` | 下位20バイトが管理者候補 | | ビーコン | `0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50` | 下位20バイトがビーコン候補 | 未加工JSON-RPCでは、アドレス、スロット、ブロックタグを`eth_getStorageAt`へ渡します。`latest`のまま証拠へ残すのではなく、先にブロック番号を固定します。 ```json { "jsonrpc": "2.0", "id": 1, "method": "eth_getStorageAt", "params": [ "0xProxyAddress", "0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc", "0xFixedBlockNumber" ] } ``` viem `2.56.0`では同じRPCを次のように3回読み、32バイト語の下位20バイトをチェックサムアドレスへ変換できます。 ```ts import { getAddress, toHex } from 'viem' const slots = { implementation: '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc', admin: '0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103', beacon: '0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50', } as const const blockNumber = await publicClient.getBlockNumber() const entries = await Promise.all(Object.entries(slots).map(async ([name, slot]) => { const word = await publicClient.getStorageAt({ address: proxy, slot, blockNumber }) const normalized = word ?? toHex(0, { size: 32 }) return [name, { slot, word: normalized, address: getAddress(`0x${normalized.slice(-40)}`) }] })) console.log({ blockNumber, slots: Object.fromEntries(entries) }) ``` ゼロ語は「その方式ではない」手掛かりですが、直ちに更新不能という意味にはなりません。独自プロキシは別スロットを使えます。ゼロでないアドレスも、`getCode`、実行時バイトコード、ソース、ABI、呼び出し挙動まで確かめて初めて役割の候補になります。 ERC-1967未加工スロットからアドレス、バイトコードとソース、更新権限とイベント履歴、ストレージ配置へ進む読み取り専用調査順 ## Transparent・UUPS・Beaconは呼び出しパスと権限が違う 3方式とも`delegatecall`を使えますが、「実装をどこから得るか」と「更新関数を誰が呼ぶか」が違います。 Transparent、UUPS、Beacon Proxyの呼び出し元から実装までの呼び出しパスと更新権限の違い | 方式 | プロキシで主に見えるスロット | 通常呼び出し | 更新入口 / 権限 | | --- | --- | --- | --- | | Transparent | 実装 + 管理者 | 管理者以外を実装へ`delegatecall` | ProxyAdminがプロキシの専用振り分けを呼ぶ | | UUPS | 実装。管理者は通常ゼロ | 実装へ`delegatecall` | 実装内の`upgradeToAndCall`と`_authorizeUpgrade` | | Beacon | ビーコン。実装は通常ゼロ | ビーコンの`implementation()`を読み`delegatecall` | ビーコン所有者がビーコンを更新し、接続プロキシ全体へ反映 | ### Transparent Proxyは管理者の呼び出しだけ分岐する OpenZeppelin Contracts `5.6.1`の`TransparentUpgradeableProxy`は、構築時に専用`ProxyAdmin`を作ります。通常の呼び出しは実装へ進みます。一方、実際の管理者であるProxyAdminからの呼び出しは更新用の振り分けだけを受け付け、実装の通常関数へフォールバックしません。 ローカル再現では実装スロットがV1、管理者スロットがコードを持つProxyAdmin、ビーコンスロットがゼロになりました。ProxyAdmin呼び出し元の`value()`は`ProxyDeniedAdminAccess`で失敗し、別呼び出し元の`value()`は`41`を返しました。 OpenZeppelin 5.xでは実際の管理者アドレスをプロキシの`immutable`変数にも保持します。信頼できない実装がERC-1967管理者スロットを書き換えると、未加工スロットと実際の管理者が一致しない場合があります。したがって管理者スロットは重要な手掛かりですが、実装を信用できない状況で唯一の権限証拠にはしません。 ### UUPSは実装側に更新コードがある UUPSではプロキシは基本的な`ERC1967Proxy`で、更新関数は実装にあります。プロキシ経由で`upgradeToAndCall`を呼ぶと`delegatecall`され、実装側の`onlyProxy`による実行文脈の確認と、アプリケーション固有の`_authorizeUpgrade`を通って実装スロットを書き換えます。 管理者スロットがゼロでも更新不能とは限りません。所有者、役割、マルチシグ、タイムロックなど、`_authorizeUpgrade`が読む状態と変更履歴を実装ソースから追います。新実装の`proxiableUUID()`がERC-1967実装スロットを返す互換性確認も必要です。 ローカル再現では所有者呼び出しだけがV1からV2へ進み、外部者は拒否されました。実装アドレスへ直接送った更新呼び出しも、プロキシ文脈ではないため`UUPSUnauthorizedCallContext`で拒否されました。 ### Beacon Proxyはビーコンを経由して二段階で解決する Beacon Proxyは実装スロットではなくビーコンスロットを読み、そのビーコンコントラクトの`implementation()`を呼び出して実行先を得ます。1つの`UpgradeableBeacon`を2つのプロキシが共有すれば、ビーコンの1回の更新で両方の実行コードが変わります。ただし値や所有者などの状態は各プロキシに別々に残ります。 OpenZeppelin 5.xの`BeaconProxy`は効率のためビーコンを`immutable`変数にも保持し、実際の呼び出しパスはその値を使います。実装処理がビーコンスロットを書き換えても実行先は変わらず、未加工スロットとの不一致を作ります。ビーコンスロット、プロキシバイトコード / ソース、ビーコンの`implementation()`を三点照合します。 ## 3方式を同じローカルチェーンへ固定して再現した [公開再現データ](/fixtures/erc-1967-6020.json)は、Foundry / Anvil `1.8.0`、Solidity `0.8.36`、OpenZeppelin Contracts `5.6.1`、viem `2.56.0`、Prague EVM、ローカルチェーンID `31337`へ固定しています。プロキシ種別ごとの読み取り、更新、衝突時の境界を個別に確認しています。 | パス | 未加工スロット / 挙動 | ローカル結果 | | --- | --- | --- | | Transparent初期 | 実装=V1、管理者=ProxyAdmin、ビーコン=ゼロ | 所有者=デプロイ者、値=`41` | | Transparent互換V2 | 実装だけV2へ変更 | 所有者 / 値を維持、バージョン=`2` | | Transparent衝突V2 | 同じ未加工スロットを逆の型で読む | 所有者=`0x…0029`、値が旧所有者の整数表現 | | UUPS | 実装=V1→V2、管理者 / ビーコン=ゼロ | 所有者更新成功、外部者と直接実装は拒否 | | 危険初期化関数 | 明示的に空データを許可したプロキシ | 外部者がプロキシ所有者を取得。危険実装自身も直接初期化可能 | | Beacon A / B | 実装 / 管理者=ゼロ、ビーコン=共通アドレス | 1回のビーコン更新で両方バージョン2、値`7` / `9`を維持 | このアドレスと秘密鍵はAnvilが作る使い捨て検証環境専用です。メインネットアドレス、個人の秘密鍵、実在アカウント、ウォレット確認画面、外部RPC、資産の証拠ではありません。 ## 初期化関数はプロキシ構築データで同時に実行する 実装のコンストラクターは実装自身のストレージにしか作用しません。プロキシ側の所有者や初期値は、初期化関数を`delegatecall`してプロキシストレージへ書きます。 安全側の再現コードは次の2点を組み合わせます。 1. プロキシ構築時の`data`へ`initialize(owner, value)`を入れ、配置と初期化を同じトランザクションにする 2. 実装コンストラクターで`_disableInitializers()`を呼び、実装自身を直接初期化できないようにする OpenZeppelinの`ERC1967Proxy` 5.6は空の`data`を既定で`ERC1967ProxyUninitialized`として拒否します。事故を再現するため、検証用コードだけが次の危険上書きを明示しています。 ```solidity contract UnsafeUninitializedProxy is ERC1967Proxy { constructor(address implementation) ERC1967Proxy(implementation, "") {} function _unsafeAllowUninitialized() internal pure override returns (bool) { return true; } } ``` このプロキシへ外部者が先に`initialize`すると所有者を取れました。コンストラクターのデータを空にすることや、上書きを本番環境の方式として勧める例ではありません。また実装を直接呼び出して所有者になれても、それだけでプロキシ所有者になったとは限りません。 2つのストレージ文脈を分けます。 ## ストレージ配置はソース差分ではなくスロットの意味を比べる `delegatecall`では新実装も既存プロキシストレージを読みます。変数名が同じでも、宣言順序、継承、詰め込み、型が変われば同じ語の意味が変わります。 ローカル再現のV1と互換V2は末尾へ`revision`を追加しました。衝突V2は最初の2宣言を逆にしています。 | 未加工位置 | V1 / 互換V2 | 衝突V2 | 同じ語の結果 | | --- | --- | --- | --- | | スロット0 | `uint256 value = 41` | `address owner` | `0x0000…0029`として読む | | スロット1 | `address owner = 0xf39F…2266` | `uint256 value` | `1390849295786071768276380950238675083608645509734`として読む | | スロット2 | 互換V2の`uint256 revision = 2` | 宣言なし | 衝突側からは使わない | 更新トランザクション自体は成功しても、意味は壊れています。コンパイラーのストレージ配置出力、前バージョン、次バージョン、継承順、名前空間付きストレージ、移行初期化関数を比較し、ローカルフォークまたは決定的なローカル再現で値を読むまでを更新レビューに含めます。 [EIP-7702ライフサイクルの記事](/archives/6017)でも、コードの参照先を変えてもストレージや外部権限は自動で消えないことを確認しました。仕組みは別ですが、「コードの変更」と「アドレスに残る状態」を分ける観点はプロキシ更新でも同じです。 同じ`delegatecall`でもトランザクション中だけ存在する状態は別領域です。[EIP-1153一時ストレージの記事](/archives/6021)で、CALLは呼び出し先、DELEGATECALLはプロキシ / ホスト側の一時ストアを所有することと、通常戻り値後の後片付けを再現しています。 更新前後の権限や会計を単発例だけでなく操作列として検査する場合は、[Foundry不変条件テストの記事](/archives/6022)でハンドラー、実行主体、補助変数、縮約した反例の作り方を確認できます。 ## イベントと各ブロックのスロットから実装履歴を作る ERC-1967はスロット変更時の`Upgraded`、`AdminChanged`、`BeaconUpgraded`イベントを定義します。現在スロットだけでなく、デプロイブロックからイベントをアドレス別・ログ索引順に集め、そのブロックのスロットを読み直します。 ```ts import { parseAbiItem } from 'viem' const upgraded = await publicClient.getLogs({ address: proxy, event: parseAbiItem('event Upgraded(address indexed implementation)'), fromBlock: deploymentBlock, toBlock: fixedHead, }) for (const log of upgraded) { const word = await publicClient.getStorageAt({ address: proxy, slot: slots.implementation, blockNumber: log.blockNumber, }) console.log({ blockNumber: log.blockNumber, logIndex: log.logIndex, event: log.args, word }) } ``` ローカル再現では次の履歴になりました。 | 発行元 | イベント | ブロック / 件数 | 読み方 | | --- | --- | --- | --- | | Transparentプロキシ | `Upgraded` | 7、8、9 / 3 | 初期V1 → 互換V2 → 衝突V2 | | Transparentプロキシ | `AdminChanged` | 7 / 1 | ゼロ → 生成済みProxyAdmin | | UUPSプロキシ | `Upgraded` | 10、11 / 2 | コンストラクター V1 → 所有者が認可したV2 | | ビーコン | `Upgraded` | 15、18 / 2 | ビーコン自体の実装履歴 | | Beacon Proxy A / B | `BeaconUpgraded` | 16、17 / 各1 | 各プロキシが参照するビーコンの発見イベント | 同じ`Upgraded(address)`署名でも、プロキシが発行する実装変更とビーコンコントラクトが発行する変更があります。必ず発行元アドレスを記録します。権限調査ではProxyAdmin / ビーコンの所有権移転、AccessControl、タイムロック、ガバナンスイベントも別に追います。 チェーン再編、RPCの履歴保持範囲、デプロイブロックの取り違え、独自イベントの欠落は残る境界です。重要な調査では複数の履歴対応ソースとブロックハッシュを照合します。 Blobトランザクションでは実行RPCのバージョン付きハッシュが残っていても、Beaconサイドカーは別の保存期間境界を持ちます。[Fusaka・PeerDASの記事](/archives/6023)では、固定ブロックの実行証拠と保存期間に制限があるBlobデータを分けて再現しています。 ## 検証済みソースは調査の入口であって安全証明ではない ソース検証が示すのは、対象バイトコードとソース / コンパイラー設定の対応です。次は別々に確認します。 - プロキシアドレスの実行時バイトコードとプロキシソース - 現在の実装アドレスの実行時バイトコード、ソース、ABI - ProxyAdmin、UUPS権限、ビーコンとその所有者のソース・現在の状態 - コンパイラーのストレージ配置と更新前後の互換性 - デプロイ / 更新 / 権限変更のイベント履歴 - 停止、役割、オラクル、外部呼び出し、事業処理などアプリケーション固有リスク Etherscanのプロキシ検証APIはプロキシと想定した実装の関連付けを検証する接続先です。Sourcifyもソースメタデータ照合の別経路になります。どちらも更新権限の妥当性、ストレージ互換性、監査完了、悪意ある処理がないことを保証しません。 ソース照合そのものを追試する場合は、[検証済みソースを作成時/実行時・コンパイラー・コンストラクター・メタデータから再ビルドする手順](/archives/6033)で、プロキシと実装を別対象にした未加工バイトコード比較を確認できます。 プロキシをCREATE2で決定的にデプロイする場合は、実装とコンストラクターから渡された初期化データが初期化コードへ入るかを追加で確認します。[CREATE2のソルト・初期化コード・プロキシ / クローンアドレスを検証する手順](/archives/6044)では、ERC1967Proxyと最小クローンで初期化関数の境界を分けています。 45バイト実行時へ実装を直接埋め込むEIP-1167は、ERC-1967スロットを読むプロキシとは調査方法が異なります。[Minimal Proxyのバイトコード・初期化関数・ファクトリーを検証する手順](/archives/6045)では、実行時から実装を抽出し、クローンストレージと未初期化状態を確認します。 実装更新前後のストレージ互換性をモジュール単位で追う場合は、[ERC-7201 Namespaced Storageの名前空間ID・ルート・項目配置を検証する手順](/archives/6046)で、通常配置、`__gap`、名前空間内の末尾追加・並べ替え・型変更を比較できます。 実装スロットを1つ持たず識別子ごとに実装先が変わる構成は、[EIP-2535 Diamondのファセット振り分け・参照機能・DiamondCutを検証する手順](/archives/6047)で、現在振り分け、変更履歴、初期化関数、ストレージルート、権限を分離しています。 ブロックエクスプローラーが「Read as Proxy」で結合ABIを表示しても、確認対象のブロック、実装ソース、プロキシ状態、管理者 / ビーコン権限を自分の調査メモへ分けます。未検証ならABIを推測して書き込み（Write）を実行しません。検証済みでもシミュレーションや権限確認を省略しません。 Safeプロキシを調べている場合は、ERC-1967スロットがある前提にせず、対象Safeバージョンの公式プロキシソースへ戻ります。[Safeトランザクションの署名・ノンス・実行失敗を分ける手順](/archives/6030)では、実装と`VERSION()`を固定してから所有者、必要署名数、モジュール、保護機構、Safeノンスを読み取り専用で追います。 古い変形可能コントラクトや実装の`SELFDESTRUCT`が関係する場合は、プロキシ更新と同じ「コード変更」にまとめません。[EIP-6780後のコード・ストレージ・残高・CREATE2再デプロイ検証](/archives/6043)で、既存コントラクトと同一トランザクション内作成の境界を確認できます。 ## 読み取り専用調査チェックリスト - [ ] チェーン、プロキシアドレス、固定ブロック番号 / ハッシュを記録した - [ ] 実装、管理者、ビーコンの正確なスロットを同じブロックで読んだ - [ ] 32バイト語、下位20バイトアドレス、ゼロ、コード有無を保存した - [ ] プロキシ実行時バイトコード / ソースと呼び出し挙動を照合した - [ ] Transparent、UUPS、Beacon、独自プロキシをスロット一つだけで断定していない - [ ] ビーコンなら`beacon.implementation()`を同じブロックで読んだ - [ ] UUPSなら`proxiableUUID`、プロキシ文脈、`_authorizeUpgrade`を確認した - [ ] 管理者 / 所有者 / 役割 / マルチシグ / タイムロック / ガバナンスを権限チェーンとして追った - [ ] `Upgraded`、`AdminChanged`、`BeaconUpgraded`を発行元とログ索引付きで集めた - [ ] イベントブロックのスロットを再読し、現在値だけから過去を推測していない - [ ] 実装直接呼び出しとプロキシの`delegatecall`のストレージ文脈を分けた - [ ] プロキシのコンストラクターデータ、初期化関数バージョン、実装ロックを確認した - [ ] コンパイラーが出力したストレージ配置を更新前後で比較し、ローカル状態を再現した - [ ] 検証済みソースを公式性、監査、安全、変更不能と同一視していない - [ ] 調査の読み取り専用操作とウォレット接続、署名、更新、資産操作を分離した プロキシ調査の完了条件は、ブロックエクスプローラーが実装名を表示したことではありません。**プロキシアドレスの未加工スロットを起点に、実装コード、更新権限、イベント履歴、ストレージ配置を同じブロックへ対応させること**です。 この記事にスポンサー、アフィリエイト、ウォレット接続、署名要求、更新トランザクション、資産操作の販売誘導はありません。将来ブロックエクスプローラー、RPC、監視、検証、監査、開発者ツール対応の広告を置く場合も広告であることを明示し、未加工スロット、ソース、権限、イベント、配置の調査結果や安全評価から分離します。 ## 確認した一次情報 - [ERC-1967 Proxy Storage Slots](): 確認日 2026-08-30 - [OpenZeppelin Contracts 5.x Proxy API](): 確認日 2026-08-30 - [OpenZeppelin Upgrades Plugins](): 確認日 2026-08-30 - [Solidity Layout of State Variables in Storage](): 確認日 2026-08-30 - [Ethereum JSON-RPC eth\_getStorageAt](): 確認日 2026-08-30 - [viem getStorageAt](): 確認日 2026-08-30 - [Etherscan Verify Proxy Contract API](): 確認日 2026-08-30 - [Sourcify API](): 確認日 2026-08-30 - [Foundry v1.8.0](): 確認日 2026-08-30 --- # 一時ストレージ入門｜EIP-1153のTSTORE・TLOADと再入防止 EIP-1153の一時ストレージについて、トランザクション内の寿命、CALL・DELEGATECALLの所有関係、revertと残ったロック、通常のストレージを使う防止策とのガス差をFoundryで検証します。 正規URL: https://3mikan.com/archives/6021 著者: みかん 公開: 2026-08-30T16:00:00.000Z 更新: 2026-09-02T05:35:00.000Z 一時ストレージは、**同じトランザクションの複数呼び出しから共有でき、トランザクションが終わると消えるコントラクト所有状態**です。メモリーのように呼び出しごとに作り直されるわけでも、通常ストレージのように次のトランザクションへ残るわけでもありません。 この寿命は再入防止や一時的なコールバックフラグに向きます。ただし通常ストレージから全面的に置き換えたり、関数が正常終了すれば自動で後片付けされると思ったりすると、同じトランザクション内の後続呼び出しを残留ロックが止めます。この記事ではEIP-1153の`TSTORE` / `TLOAD`を、CALL、DELEGATECALL、`revert`、STATICCALL、再入防止のガスまでローカルで再現します。 ## メモリー・一時・ストレージの違いは寿命と所有者で決まる 最初に3つを「どこに属し、いつまで残るか」で分けます。 | 状態 | 所有単位 | 同じトランザクションの別呼び出し | 次のトランザクション | 主な用途 | | --- | --- | --- | --- | --- | | メモリー | 呼び出しフレーム | 原則共有しない | 残らない | 1回の関数実行中の計算 | | 一時ストレージ | コントラクトアドレスのトランザクション内だけのストア | 同じ所有文脈なら共有 | すべて0へ戻る | ロック、コールバックフラグ、一時承認 | | ストレージ | コントラクトアドレスの永続ストア | 共有 | 残る | 残高、所有者、設定、会計状態 | 「一時的だからメモリー」は、入れ子呼び出しやコールバックから同じ値を読む必要があると成立しません。「複数呼び出しから読むからストレージ」は、トランザクション後に不要な値の書込み・後片付けを永続状態へ持ち込みます。その中間が一時ストレージです。 メモリー、一時ストレージ、ストレージの所有単位と呼び出し・トランザクションを越える寿命の比較 通常ストレージのスロット配置と一時ストレージのスロット配置は別です。同じスロット番号でも同じ領域ではありません。[ERC-1967プロキシのスロットと`delegatecall`の実行文脈](/archives/6020)を調べるときも、永続ストレージと一時ストアを混ぜずに追います。 ## TSTOREとTLOADの基本 EIP-1153は`TLOAD`（命令コード`0x5c`）と`TSTORE`（`0x5d`）を定義します。どちらもワード単位でアドレスを指定し、EIPの現在の規定では各100ガスです。ただしコントラクト全体のガス差は、周辺のSLOAD / SSTORE、呼び出しデータ、分岐、返金、ウォーム / コールドアクセスを含むため、命令コードの単価だけから決めません。 Solidity `0.8.36`では値型の状態変数へ`transient`を指定できます。今回の最小例は次の形です。 ```solidity contract LifetimeStore { uint256 private transient _temporary; uint256 private _persistent; function setTransient(uint256 value) external { _temporary = value; } function transientValue() external view returns (uint256) { return _temporary; } } ``` 宣言時の初期化は使わず、必要な入口で値を書きます。配列、対応表、構造体など参照型の一時状態変数は、この確認環境のSolidityでは対象にしません。任意のスロットを明示したい場合はOpenZeppelin `TransientSlot`、または監査可能な定数スロットとインラインアセンブリを使います。 ## CALLは呼び出し先、DELEGATECALLは呼び出し元の文脈を使う 一時ストアは「トランザクション全体で1個」ではありません。通常の`CALL` / `STATICCALL`では呼び出し先コントラクトが所有者です。同じコントラクトを別フレームから呼べば共有しますが、別コントラクトの同じスロットへは漏れません。 `DELEGATECALL` / `CALLCODE`では、永続ストレージと同様に呼び出し元の所有文脈を使います。実装コードが`TSTORE`しても、値が入るのは実装自身ではなくホスト / プロキシ側です。 CALLで呼び出し先ごとに分かれ、DELEGATECALLでホスト側へ保存され、トランザクション終了時に全一時値が消える流れ ローカル再現では`keccak256("3mikan.eip1153.delegate.value")`を共通スロットにしました。ホストが処理を`delegatecall`して`29`を書くと、同じ呼び出し中のホスト読み取りは`29`、処理アドレスへ通常CALLした読み取りは`0`でした。スロット定数が同じでも所有コントラクトが違うためです。 | 操作 | 書込み先 | 同じトランザクション内の観測 | | --- | --- | --- | | A → ストアAをCALL | ストアAの一時ストア | ストアAの別フレームから読める | | A → ストアBをCALL | ストアBの一時ストア | ストアAの同じスロットとは別 | | ホスト → 処理をDELEGATECALL | ホストの一時ストア | ホストで読める。処理自身では0 | | トランザクション終了 | 全コントラクトの一時ストア | 次のトランザクションは0から開始 | プロキシで使う場合は実装ごとではなくプロキシ文脈のスロット衝突をレビューします。更新前後の処理が同じ一時スロットを別の意味に使えば、同一トランザクション内で干渉できます。 ## `revert`はその呼び出しフレーム以降の一時書き込みも戻す 内部呼び出しが`revert`すると、そのフレームと内側で行った一時書き込みは永続ストレージと同じように状態が戻されます。外側で先に書いた値までトランザクション全体から消えるわけではありません。 ローカル再現では外側が`7`を書き、内部呼び出しが`99`を書いて`revert`しました。低水準呼び出しで`revert`を捕捉した後に読むと`7`です。 ```solidity store.setTransient(7); (bool success,) = address(store).call( abi.encodeCall(LifetimeStore.writeTransientThenRevert, (99)) ); require(!success); require(store.transientValue() == 7); ``` 一方、内部呼び出しが正常終了するまでに書いた値は、トランザクション終了まで残ります。「関数を抜けたから0」は誤りです。後片付けする設計なら成功する経路で明示的に0へ戻します。 `STATICCALL`中の`TLOAD`は許可されますが、`TSTORE`は例外になります。ローカル再現は静的読み取りが`5`を返し、静的書き込みが失敗し、元の`5`が変わらないことを確認しました。`view`関数から読むことと、静的文脈でロックを立てることは別です。 ## 通常ストレージ版と一時ストレージ版の再入防止を同条件で比較する OpenZeppelin Contracts `5.6.1`には永続ストレージ版の`ReentrancyGuard`と、EIP-1153対応チェーン専用の`ReentrancyGuardTransient`があります。今回の2コントラクトは再入防止の方式以外を同じにしました。 ```solidity contract TransientGuardCounter is ReentrancyGuardTransient { uint256 public count; function increment(address callback) external nonReentrant { count += 1; if (callback != address(0)) { IGuardCallback(callback).onGuardEntered(address(this)); } } } ``` コールバックから同じ`increment`へ再入すると、ストレージ版と一時版の両方が入れ子呼び出しを拒否し、外側の呼び出しだけが1回完了しました。ロックの保存方式が違っても、保護済みの外部入口を内部実装から分ける、確認・状態更新・外部呼び出しの順序を守る、コールバックが発生する箇所を把握するといった確認は必要です。 Anvilで`increment(address(0))`をそれぞれ新しい最上位トランザクションから1回だけ呼びました。 | 固定条件 | 通常ストレージ版 | 一時ストレージ版 | 観測差 | | --- | ---: | ---: | ---: | | 使用ガス | 46,090 | 44,185 | 一時ストレージ版が1,905少ない | 環境はFoundry / Anvil `1.8.0`、Solidity `0.8.36`、OpenZeppelin `5.6.1`、viem `2.56.0`、Prague EVM、オプティマイザー有効、`runs: 200`、チェーンID`31337`です。[公開再現データ](/fixtures/eip-1153-6021.json)には、正確なバージョン、コミット、コントラクトアドレス、ガス計測結果を収録しています。 この1,905ガスは、このバイトコードと環境での観測値です。すべてのコントラクト、チェーン、コンパイラー設定で同じだけ削減できる保証ではありません。導入候補では、実際の入口、オプティマイザー、呼び出し列、チェーンのハードフォークを固定して再計測します。 ## 残留一時ロックは同じトランザクションの後続呼び出しを壊す 最も危険な誤解は「正常終了すれば一時状態も消える」です。次の危険な関数は正常終了してもロックを残します。 ```solidity function enterWithoutCleanup() external { if (_locked) revert Locked(); _locked = true; } ``` バッチ実行コントラクトがこれを呼んだ後、同じトランザクションで通常の保護済み関数を呼ぶと`Locked`で失敗しました。最初の呼び出しが`revert`していないため、書き込みは巻き戻されません。ルーター、Multicall、アカウント抽象化、フック、コールバックなど、1トランザクションに複数の外部呼び出しが入る環境では、ほかの処理と組み合わせたときに失敗します。 正常な再入防止処理は、成功する経路で後片付けします。 ```solidity modifier cleanGuard() { if (_locked) revert Locked(); _locked = true; _; _locked = false; } ``` このローカル再現では、後片付けを行う関数を同じトランザクションで2回呼び、どちらも成功しました。後片付けを省いて正常終了した後は2回目が失敗しますが、残留書き込みを行った内部呼び出しが`revert`した場合は状態が巻き戻されます。その`revert`を捕捉した後は、後片付けを行う関数を呼び出せました。さらに残留ロックだけを書いて最上位トランザクションを終えると、次のトランザクションでは`false`へ戻りました。 | パス | トランザクション内のロック | 後続呼び出し | | --- | --- | --- | | 設定 → 本文 → 解除 → 正常終了 | `false` | 成功できる | | 設定 → 解除なしで正常終了 | `true` | 同じトランザクションでは失敗 | | 内部設定 → `revert`を捕捉 | 内部の書き込みを巻き戻す | 外側の以前の値から継続 | | 残留のままトランザクション終了 | 次トランザクションで0 / `false` | 新しいトランザクションは開始できる | 後片付けを「ガスを節約するため不要」と省かないでください。EIP-1153も、ほかの処理との組み合わせを壊さないため、利用者が一時スロットを明示的に解除する設計を推奨しています。 ## 一時的利用許可と一時状態の使いどころ トランザクション中だけ必要なトークン権限は一時ストレージの代表例です。[ERC-7674一時的利用許可を含む権限比較](/archives/6012)では、付与と引き出しが同じトランザクションなら使え、トランザクション境界後は未使用数量も0になることを別のローカル再現で確認しました。 ほかに、次のような値が候補になります。 - 再入ロックやコールバック中フラグ - 一連の入れ子呼び出しで共有する一時的な計算結果 - トランザクション内の台帳 / 残高と差分の整合 - ルーターやフックの一時文脈 - 同一トランザクションだけ有効な認可 ただし1関数内だけで完結する値はメモリーの方が単純です。次のトランザクションで読む必要があるノンス、残高、所有者、設定はストレージへ置きます。「削除し忘れてもトランザクションで消える」ことを主目的にせず、所有文脈と複数呼び出しでの共有が本当に要件かを先に決めます。 ## 採用前のレビュー時の確認項目 - [ ] デプロイチェーンがEIP-1153を有効化したハードフォーク以降か確認した - [ ] コンパイラー、EVMバージョン、ライブラリー、オプティマイザー設定を固定した - [ ] 値が呼び出しフレーム、トランザクション、複数トランザクションのどこまで必要か決めた - [ ] CALLなら呼び出し先、DELEGATECALLなら呼び出し元 / プロキシが所有者になると確認した - [ ] プロキシと実装の一時スロット衝突をレビューした - [ ] 成功、`revert`、捕捉、入れ子コールバック、STATICCALLをテストした - [ ] 正常終了時に0へ戻す後片付けの経路がある - [ ] 後片付け前に外部呼び出しを行い、再入される経路をテストした - [ ] Multicall / ルーター / フックで同じトランザクションの2回目が成功する - [ ] 残留状態を意図的に残す失敗テストがある - [ ] 次トランザクションで0へ戻ることをAnvil等の実トランザクション境界で確認した - [ ] 通常ストレージ版とのガス比較を同じ関数、呼び出しデータ、コンパイラー条件で行った - [ ] 性能比較値を普遍的な削減率や安全保証として広告していない - [ ] 一時ストレージ非対応チェーンへ同じバイトコードを配置しない 次の検証段階では、ユニットテストの例を増やすだけでなく、任意の操作列でも「正常終了後のロックは`false`」「`revert`後に以前の値へ戻る」といった性質を守るかを、状態を引き継ぐファズテストで調べます。[Foundry不変条件テストの後続記事](/archives/6022)で、この検証例から機械的な不変条件へつなげます。 再入防止を実際の呼び出しグラフへ適用するときは、[基本型・関数横断・読み取り専用・コールバック・`delegatecall`を並べたReentrancyの検証](/archives/6048)で、通常ストレージ版と一時ストレージ版が同じ共有不変条件をどこまで覆うかを比較できます。 一時ストレージの採用判断で重要なのは、命令コードが安いという一点ではありません。**値の所有文脈、同じトランザクションで共有する呼び出し、正常終了時の後片付け、`revert`時の巻き戻し、次のトランザクションで0になることを一つの操作列で確認すること**です。 この記事にスポンサー、アフィリエイト、ウォレット接続、署名要求、トランザクション送信、資産操作の販売誘導はありません。将来コンパイラー、テスト、監査、RPC、開発者ツール対応の広告を置く場合も広告であることを明示し、再現データ、ガス報告書、失敗テスト、採用判断から分離します。 ## 確認した一次情報 - [EIP-1153 Transient Storage Opcodes](): 確認日 2026-08-31 - [Solidity Transient Storage](): 確認日 2026-08-31 - [Solidity Inline Assembly](): 確認日 2026-08-31 - [OpenZeppelin ReentrancyGuardTransient](): 確認日 2026-08-31 - [OpenZeppelin TransientSlot](): 確認日 2026-08-31 - [Foundry v1.8.0](): 確認日 2026-08-31 --- # Foundryの不変条件テスト入門｜ハンドラー・ゴースト変数・反例 Foundryの状態を引き継ぐ不変条件テストを単体テスト・ファジングと比較し、ハンドラー、実行主体、対象関数、ゴースト変数、ERC-20・AMM・Vault・権限の性質、縮約した反例を再現します。 正規URL: https://3mikan.com/archives/6022 著者: みかん 公開: 2026-08-30T16:36:00.000Z 更新: 2026-09-02T05:35:00.000Z Foundryの不変条件テストは、**多数の入力を試すだけでなく、複数の操作を順番に実行しても守られる性質を探すテスト**です。1回の入金が成功するかではなく、入金、`donate`、`redeem`の順序や実行主体が変わっても会計が合うかを確認します。 この記事では、単体テスト、状態を持たないファジング、状態を引き継ぐ不変条件テストを同じ検証環境で比較します。ハンドラー、実行主体、`targetSelector`、ゴースト変数を組み、ERC-20、AMM、保管庫、アクセス制御の性質を4,096回の呼び出しで検査します。最後に意図的な取り消し処理の不具合を発生させ、Foundryが30回の呼び出しを3回へ縮めた反例を回帰テストへ戻します。 単体テスト、状態を持たないファジングテスト、状態を引き継ぐ不変条件テストが探索する入力と操作列の違い ## 単体・ファジング・不変条件は状態の扱いが違う まずは三つを実行単位で分けます。 | テスト | 変えるもの | 状態の扱い | 見つけやすい失敗 | | --- | --- | --- | --- | | 単体テスト | 既知の入力と手順 | 一つの例を固定 | 明確な正常系・異常系・回帰 | | 状態を持たないファジング | 1関数の入力 | 各ファジング例で初期状態へ戻す | 境界値、オーバーフロー、入力依存の失敗 | | 状態を引き継ぐ不変条件テスト | 関数、入力、実行主体、順序 | 一つの試行内で状態を引き継ぐ | 操作順、複数の実行主体、会計・権限のずれ | 今回の状態を持たないファジングは、同じ初期準備高に対して1回だけ交換し、256通りの入力で積が減らないことを確認します。不変条件キャンペーンは、11種類のハンドラー操作から64回の呼び出しを並べる試行を64回実行するため、上限は合計4,096回です。 回数が多いだけでは同じテストになりません。ファジングテストを1万回実行しても、各例で状態を戻すなら「権限を付与した後に取り消し、その後で以前の実行主体が操作する」という順序は作りません。 ## 良い不変条件は自然言語の安全性主張から作る 不変条件は「`revert`しない」「残高が正しい」のような広すぎる言葉から始めず、比較する左右を決めます。 | 種類 | 今回の性質 | 左辺と右辺 | | --- | --- | --- | | 保存則 | ERC-20供給量が既知の実行主体の残高合計と一致 | `totalSupply == sum(balanceOf(actor))` | | 独立台帳 | 発行合計から焼却合計を引くと供給量になる | `totalSupply == ghostMinted - ghostBurned` | | 単調性 | 手数料付きAMMの準備高の積が初期値を下回らない | `reserveX * reserveY >= initialProduct` | | 状態整合 | 保管庫の資産と持分が操作履歴へ一致 | 実際の状態とゴースト台帳 | | 権限 | ゴースト変数上で未承認の実行主体は特権操作に成功しない | `unauthorizedSuccesses == 0` | 「コントラクトが安全」は一つの機械検証可能な性質ではありません。会計、権限、丸め、進行可能性、価格、外部呼び出しを分け、今回のモデルが観測できる値へ落とします。 ## ハンドラーはプロトコルへ入る操作窓口 ハンドラーは、ファザーが作る未加工入力を現実的な操作へ直すラッパーです。今回の`ProtocolHandler`は4人の固定した実行主体を持ち、発行、送金、焼却、交換、入金、`donate`、`redeem`、役割操作をプロトコルへ渡します。 たとえば発行は次の順に処理します。 ```solidity function tokenMint(uint256 actorSeed, uint256 rawAmount) external { address receiver = _actor(actorSeed); uint256 amount = bound(rawAmount, 1, 1e18); vm.prank(admin); token.mint(receiver, amount); ghostMinted += amount; } ``` `actorSeed`をそのままアドレスとして使わず、固定した実行主体の一覧に対する索引へ変換します。発行が成功した後だけゴースト変数を増やすため、期待状態と実際の状態を別の経路で更新できます。 実行主体の操作をハンドラーが整形し、プロトコル実行後に実際の状態とゴースト台帳を比較して次の操作へ進む循環 ### 実行主体を1人だけに固定しない トークン送金、保管庫の持分、役割はアカウントごとに状態が違います。テストコントラクトだけを`msg.sender`にすると、別の実行主体への送金や、付与した役割を別の実行主体が使う経路を探索できません。 一方、無制限にアドレスを生成すると、残高の合計対象や権限対象を追えなくなります。今回はハンドラーが4アドレスだけを使い、トークンを一覧外へ送らないことで「既知の実行主体が持つ残高の合計」を成立させました。この前提が変わるなら、プール、保管庫、手数料の受取先、焼却アドレスも合計へ追加します。 ## 関数セレクターで操作範囲を明示する Foundryは`targetContract`でハンドラーを対象にできます。さらに`targetSelector`を使うと、キャンペーンが呼ぶ関数を許可一覧にできます。 ```solidity bytes4[] memory selectors = new bytes4[](11); selectors[0] = ProtocolHandler.tokenMint.selector; selectors[1] = ProtocolHandler.tokenTransfer.selector; // swap、vault、role操作を続ける selectors[10] = ProtocolHandler.attemptPrivilege.selector; targetContract(address(handler)); targetSelector(FuzzSelector({ addr: address(handler), selectors: selectors })); ``` `excludeSelector`は、コントラクトを広く対象にしつつデバッグ用関数などを除く拒否リストです。今回のように安全性へ関わる操作範囲が明確なら、許可一覧で「呼ぶもの」をレビューしやすくします。 対象を絞るほど必ず良いわけではありません。本番環境の入口を関数セレクターの一覧から落とせば、その経路は試行回数を増やしても探索されません。今回の結果ではセレクター数と各呼び出し件数を照合し、11操作すべてが337〜397回呼ばれたことを確認しました。 ## `bound`・`assume`・`fail_on_revert`を使い分ける ハンドラーへ入る`uint256`は、そのままでは残高や準備高より大きい値が大半です。今回の数量は`bound`で有効範囲へ写します。 ```solidity uint256 amount = bound(rawAmount, 1, balance); ``` `vm.assume(condition)`は条件を満たさない例全体を捨てます。複数の厳しい`assume`を重ねると拒否上限へ達したり、重要な境界値をほとんど実行できなかったりします。 使い分けの目安は次の通りです。 - 数量を有効範囲へ入れる: `bound` - アドレス同士が異なるなど、生成し直すべき全体前提条件: `assume` - 現在の残高が0など、操作列の途中で自然に起きる状態: ハンドラーから早期に戻り、呼び出し件数には残す - 権限不足など想定した失敗: 低水準呼び出しで結果を観測し、成功・失敗をゴースト変数へ記録する 今回の`fail_on_revert`は`false`です。これは「すべての`revert`を無視してよい」という意味ではありません。ハンドラーが想定内の`revert`を意味のあるカウンターへ変換し、今回の通過キャンペーンでは4,096回の呼び出し中に想定外の`revert`が0件だったことまで確認します。 想定外の`revert`も性質に含めたいプロトコルでは、`fail_on_revert=true`にするか、ハンドラーの失敗件数を0とする不変条件を追加します。設定だけでなく、`revert`が仕様上の拒否なのか不具合なのかを先に分けてください。 ## ゴースト変数は期待状態の別帳簿 ゴースト変数は、プロトコルに保存されていない期待値をテスト側で持つ補助変数です。トークンの例では、成功した発行と焼却だけを集計します。 ```text expected supply = ghostMinted - ghostBurned observed supply = token.totalSupply() ``` ここで`ghostMinted = token.totalSupply()`と毎回コピーすると、同じ値を左右で比較するだけです。入力、成功結果、以前のゴースト変数から期待値を更新し、プロトコルの読み取り関数とは独立させます。 今回の検証コードでは次を別管理しました。 - トークン: 発行合計、焼却合計 - 保管庫: 入金、寄付、出金の資産合計 - アクセス制御: 実行主体ごとの期待役割、承認済みの成功、未承認の成功、承認済みの失敗 - 網羅率: 識別子ごとの呼び出し件数 ## ERC-20は供給量を2方向から照合する [ERC-20](https://eips.ethereum.org/EIPS/eip-20)は`totalSupply`と`balanceOf`を定義します。OpenZeppelin Contracts 5.6.1のERC20を使った例では、次の2性質を同時に確認しました。 ```text totalSupply == actor A〜D の balanceOf 合計 totalSupply == ghostMinted - ghostBurned ``` 一つ目は残高配分、二つ目は発行・焼却履歴です。送金時に供給量まで変える不具合なら両方がずれます。発行時に間違った実行主体へ配る不具合は、残高合計だけでは見逃しても、実行主体別のゴースト変数を追加すれば追跡できます。 この例の合計は、ハンドラーがトークンを4人の実行主体以外へ送らない条件でのみ完全です。任意のアドレスへ送金できる本番用トークンへ、同じループをそのままコピーしないでください。 ## AMMは準備高の積の単調性を小さく検査する 定積型AMMでは`x*y=k`を基準にします。今回の小さなプールは入力から0.3%を差し引く式を使い、交換後に次を確認します。 ```text reserveX * reserveY >= initialProduct ``` 64×64キャンペーンではX→YとY→Xの順序が混ざります。1方向を1回だけ試す状態を持たないファジングより、丸めが積み重なった状態を検査できます。 ただしこれは、簡略化した準備高の会計だけを対象にした性質です。実際のAMMでは、トークン残高と記録済み準備高、流動性の発行 / 焼却、送金時手数料型トークン、コールバック、オラクル、プロトコル手数料も別に検査します。定積式と数値例は[インパーマネントロスとAMM式の解説](/archives/580)、プロキシを含む実行文脈は[ERC-1967のスロット・権限・配置確認](/archives/6020)へ分けています。 ## 保管庫は資産と持分を別々に追う 保管庫では資産と持分を同じ数量だと決めつけません。今回の再現コードは入金、寄付、`redeem`を持ち、次を確認します。 ```text totalAssets == ghostDeposited + ghostDonated - ghostWithdrawn totalShares == sum(sharesOf(known actors)) ``` 100資産を入金して100持分を発行した後、25資産を`donate`すると`totalAssets=125`、`totalShares=100`です。寄付で持分まで増える実装なら、2つ目の性質が壊れます。 [ERC-4626](https://eips.ethereum.org/EIPS/eip-4626)では資産とERC-20持分を分け、入金や`redeem`の方向ごとに丸め要件があります。今回の`ShareVault`はその関係を学ぶ最小実装であり、ERC-4626の全インターフェース、手数料、許容価格差、インフレーション攻撃対策を実装した本番環境保管庫ではありません。 ## アクセス制御は期待役割と実際の成功を比べる 役割操作用のハンドラーは、管理者として役割を付与 / 取り消しし、実行主体として特権関数を呼びます。ゴースト変数上で未承認なら、成功数は常に0でなければなりません。 ```text ghostUnauthorizedSuccesses == 0 gate.privilegedCount == ghostAuthorizedSuccesses ghostAuthorizedFailures == 0 ``` 権限は関数単体より、付与、取消、再付与、実行の順序で壊れやすい領域です。[OpenZeppelin AccessControl](https://docs.openzeppelin.com/contracts/5.x/access-control)でも役割と役割管理者を分けています。プロキシ更新でコードと権限が変わる場合は[ERC-1967の記事](/archives/6020)、同じトランザクション内の一時ロックを操作列で検査する入口は[一時ストレージの記事](/archives/6021)も参照してください。 ## 意図的な取り消し不具合を3呼び出しへ縮める 反例用の`BuggyRoleGate`は、付与時に役割を`true`にしますが、取り消し時に実際のマッピングを`false`へ戻しません。実行主体を追うゴースト変数は`false`になるため、期待状態と実際の状態が分かれます。 固定シードのキャンペーンでは、Foundryが30呼び出し目で失敗を見つけ、縮約処理が次の3呼び出しへ縮めました。 ```text grantActor() revokeActor() actAsActor() ``` | 手順 | `ghostAuthorized` | コントラクト認可済み | 特権呼び出し | | --- | --- | --- | --- | | 付与 | `true` | `true` | 未実行 | | 取り消し | `false` | `true`（不具合） | 未実行 | | `act` | `false` | `true` | 成功して不変条件失敗 | Forgeの未加工出力には、ファザーがハンドラーを呼ぶ送信者と、ハンドラー内部の`vm.prank`も出ます。最小再現へ落とすときは、送信者表示をそのまま写すのではなく、管理者による付与、管理者による取り消し、実行主体による操作という意味を読みます。 意図的な失敗例は通常の通過キャンペーンと分離します。失敗用の設定では「この不変条件は失敗する」「理由が一致する」「3回の呼び出しがこの順で出る」ことを期待値として検査します。[公開した再現データ](/fixtures/foundry-invariant-6022.json)には、環境、設定、通過した性質、失敗した呼び出し列、検証の限界を収録しています。 ## 修正後は最小の呼び出し列を単体テストへ戻す 縮約済みの呼び出し列は、そのまま高速な回帰テストへ変えます。修正版の`RoleGate.revoke`がマッピングを`false`へ戻した後、以前の実行主体による特権呼び出しが失敗し、カウンターが0のままか確認しました。 ```solidity gate.grant(actor); gate.revoke(actor); vm.prank(actor); (bool success,) = address(gate).call( abi.encodeCall(RoleGate.privilegedIncrement, ()) ); require(!success); require(gate.privilegedCount() == 0); ``` 単体回帰テストだけへ置き換えず、修正後のコントラクトに対する不変条件キャンペーンも残します。単体テストは既知の再発をすぐ止め、不変条件テストは別の操作列で同じ性質が壊れないか探す役割です。 ## 今回の実行結果 環境はFoundry / Forge `1.8.0`、Solidity `0.8.36`、OpenZeppelin Contracts `5.6.1`、Prague EVM、オプティマイザー有効、`runs: 200`です。2026年8月31日時点のFoundry安定版には`1.8.1`がありますが、この記事では公開した検証環境と同じ`1.8.0`を使い、ツールチェーンの更新を混ぜていません。 | キャンペーン | 結果 | | --- | --- | | 単体テスト | ERC-20、保管庫、取り消しの回帰を個別に確認 | | 状態を持たないファジング | AMMで256回の試行に合格 | | 修正後の状態を引き継ぐ不変条件テスト | 7性質、64回の試行、4,096回の呼び出し、想定外の`revert`が0件で合格 | | セレクター網羅率 | 11 / 11操作を実行、各337〜397呼び出し | | 意図的不具合 | 30呼び出しで検出し、3呼び出しへ縮約 | | 想定した失敗の検証 | 失敗理由と呼び出し列を公開JSONへ照合して合格 | これらは同じシードと環境での観測結果です。実行時間や呼び出し件数の偏りは、ハードウェア、Foundryのバージョン、入力の辞書、ワーカー設定、コード変更によって変わり得ます。 ## シード・試行回数・深さ・ワーカー数を固定する 再現用`foundry.toml`の主要値は次の通りです。 ```toml [fuzz] runs = 256 seed = "0x6022602260226022602260226022602260226022602260226022602260226022" [invariant] runs = 64 depth = 64 workers = 1 fail_on_revert = false check_interval = 1 shrink_run_limit = 5000 show_metrics = true show_solidity = true ``` `runs`は操作列を作る回数、`depth`は1実行の呼び出し数です。単純には探索呼び出し数が`runs × depth`になりますが、`revert`、破棄、早期失敗、`check_interval`で実際の評価回数は変わります。 固定シードは失敗の再現に役立ちますが、同じパスだけを永久に試す理由にはしません。固定キャンペーンを回帰基準にし、深い夜間実行キャンペーンや複数シードを追加する場合は別プロフィールへ分けます。 ## 反例を読む順番 失敗ログが長い場合は、次の順に切り分けます。 1. 失敗した不変条件名と比較式を確認する 2. 元と縮約済みの呼び出し数を見る 3. ハンドラー関数、実行主体、`bound`適用後の入力を順に並べる 4. 各呼び出し後の実際の状態とゴースト変数が最初にずれた箇所を探す 5. 想定した`revert`を想定外の成功として数えたのか確認する 6. 最小の呼び出し列を単体テストで再現する 7. 修正後に単体テストと状態を引き継ぐキャンペーンを両方実行する 同じ性質を別のエンジンでも探索したい場合は、[Foundry・Echidna・Medusaを同じ検証例で比較した結果](/archives/6053)で、シード、呼び出し列の上限、縮約、入力コーパス、網羅率、無効な実行の判定境界を確認できます。 最後の呼び出しだけを修正すると、差が生まれた以前の呼び出しを見落とします。今回も失敗したのは`actAsActor`ですが、原因は一つ前の`revokeActor`でした。 ## 不変条件テスト導入チェックリスト - [ ] 自然言語の主張を左右の値がある性質へ変換した - [ ] 単体テスト、状態を持たないファジング、状態を引き継ぐ不変条件テストの役割を分けた - [ ] 本番環境の入口に対応するハンドラー操作を列挙した - [ ] 実行主体の一覧と一覧外アドレスの扱いを決めた - [ ] `targetSelector`または`excludeSelector`の理由をレビューした - [ ] 数量は`bound`し、過剰な`assume`で例を捨てていない - [ ] 想定内の`revert`と想定外の`revert`を分けた - [ ] ゴースト変数はプロトコルの読み取り関数からコピーせず独立して更新した - [ ] 寄付、丸め、手数料、役割取り消しなど順序依存パスを入れた - [ ] 各関数セレクターの呼び出し件数と`revert` / 破棄を確認した - [ ] シード、試行回数、深さ、ワーカー数、コンパイラー、オプティマイザーを固定した - [ ] 反例を縮約し、最小の単体回帰テストへ戻した - [ ] 合格を全状態の証明や監査完了として扱っていない 今回の再現環境は、外部RPC、メインネットフォーク、ウォレット、個人の秘密鍵、署名、トランザクション送信、資産を使いません。トークン、AMM、保管庫、役割条件も学習用の小さな会計モデルです。 [再入の分類と防御範囲](/archives/6048)では、このハンドラー / 縮約手順を脆弱な保管庫へ適用し、1回の呼び出しによる反例と2,048回の呼び出しに合格した不変条件テストを、同じ支払能力の性質で比較しています。 [Solidityのオプティマイザー・via-IR・EVMバージョンを比較する手順](/archives/6050)では、コンパイラー更新前後の同じ正常系・失敗系を固定し、バイトコードハッシュの差と意味上の回帰を分けています。 既存チェーンのコード・ストレージを開始点に連携処理を検査するときは、[Foundryフォークテストのブロック固定と状態の出所](/archives/6051)で、単体テスト / 不変条件テストから分離したRPC、ブロックハッシュ、ローカルで加えた変更の記録方法を確認できます。 性質を実行する前のソースレビューには、[Slither・Aderyn・Mythrilの同一プロジェクト比較](/archives/6052)を使い、静的解析結果のTP、FP、FN、重複を正解例へ対応させます。 不変条件テストで重要なのは、実行数を大きく見せることではありません。**守りたい性質、到達できる操作、実行主体、入力、ゴースト変数、`revert`の意味を明示し、見つかった最小の呼び出し列を回帰テストへ戻すこと**です。 この記事にスポンサー、アフィリエイト、ウォレット接続、署名要求、トランザクション送信、資産操作の販売誘導はありません。将来、テスト基盤、監査、開発者教育の広告を置く場合も広告であることを明示し、再現コード、反例、テスト結果、セキュリティレビューから分離します。 ## 確認した一次情報 - [Foundry Invariant Testing](): 確認日 2026-08-31 - [Foundry Testing Configuration](): 確認日 2026-08-31 - [Foundry v1.8.0](): 確認日 2026-08-31 - [Foundry v1.8.1](): 確認日 2026-08-31 - [Solidity Documentation](): 確認日 2026-08-31 - [ERC-20 Token Standard](): 確認日 2026-08-31 - [ERC-4626 Tokenized Vaults](): 確認日 2026-08-31 - [Uniswap v2 Core Pair](): 確認日 2026-08-31 - [OpenZeppelin Access Control](): 確認日 2026-08-31 --- # FusakaとPeerDASとは？実測ブロックからBlob手数料・L2手数料を読む EthereumのFusakaとPeerDASを、Blobトランザクション、データ列、Blobガス、OP Mainnetの一括投稿における実測値から解説し、プロトコル容量とL2利用者手数料を分けます。 正規URL: https://3mikan.com/archives/6023 著者: みかん 公開: 2026-08-30T17:45:00.000Z 更新: 2026-09-02T05:35:00.000Z Fusakaは、Ethereumが**Blobデータをより多く受け入れながら、各ノードのデータ負担を分担する**ための更新です。中心となるPeerDASはBlobをデータ列へ分け、ノードが一部を保管・サンプリングしてデータ可用性を確かめます。 ただし、容量が増えること、L2バッチャーがEthereumへ払うBlob手数料が変わること、利用者がL2画面で払う合計手数料は別の段階です。**PeerDASが動いたからL2手数料が必ず下がる、とは言えません。** この記事では、Fusakaの有効化を確定情報から整理した後、Ethereumメインネットのブロック`25,869,397`を固定します。このブロックは21 Blobを含み、そのうち5 Blobを投稿したOP Mainnetのバッチ送信トランザクションについて、実行ガスとBlobガスを別々に再計算します。 ## Fusakaは2025年12月3日にメインネットへ入った [Ethereum Foundationのメインネット発表](https://blog.ethereum.org/2025/11/06/fusaka-mainnet-announcement)によると、Fusakaの有効化は次の値です。 | 項目 | メインネット値 | | --- | --- | | 日付 / 時刻 | 2025-12-03 21:49:11 UTC | | スロット | 13,164,544 | | エポック | 411,392 | | 状態 | 有効化済み | Fusakaの有効化時点では、1ブロック当たりの目標 / 最大Blob数は6 / 9のままでした。後続のBlob Parameter OnlyフォークであるBPO1とBPO2が、容量を段階的に引き上げています。 | 段階 | 有効化 | 目標Blob数 / ブロック | 最大Blob数 / ブロック | | --- | --- | ---: | ---: | | Fusaka | 2025-12-03 | 6 | 9 | | BPO1 | 2025-12-09 | 10 | 15 | | BPO2 | 2026-01-07 | 14 | 21 | 2026-08-31に公開RPCの`eth_config`で確認した現在のBlobスケジュールも、目標14、最大21、基準手数料の更新比率11,684,671でした。これは執筆時点のスナップショットです。後のBPOやネットワーク更新で変わり得るため、「Fusakaの永久固定値」ではありません。 ## BlobはEVMの通常データストレージではない [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844)でBlobを運ぶトランザクションはタイプ`0x03`です。1 Blobは4,096個のフィールド要素、131,072バイトで、Blobガスも1 Blob当たり131,072です。 ここで実行側と合意側を分けます。 - 実行ブロックとトランザクション: KZGコミットメントから作った`blobVersionedHashes`を持つ - 合意データ: Blobバイトをサイドカーとして運び、Fusaka以後はデータ列へ分割して共有する - EVM: バージョン付きハッシュは扱えるが、Blobバイトの中身を直接読むことはできない つまりBlobは、コントラクトが後から任意に読める永続ストレージではありません。L2はバッチデータを安価なデータ可用性領域へ置き、導出ノードが一定期間内に取得してL2チェーンを再構成します。 L2のバッチデータがtype 3 Blobトランザクションのバージョン付きハッシュと合意層のデータ列へ分かれ、PeerDASの保管・サンプリングを経てL2導出へ戻る経路 ### バージョン付きハッシュとBlobバイトを同じ場所だと思わない バージョン付きハッシュは32バイトの参照値です。先頭1バイトでバージョンを示し、現在のKZGコミットメントでは残りをコミットメントのSHA-256から作ります。 ```text versioned hash = 0x01 || sha256(kzg_commitment)[1:] ``` 実行RPCでtype 3トランザクションを取得すると、このハッシュ一覧は後からも確認できます。一方、未加工Blobバイトを返すBeacon APIには保存期間の境界があります。ハッシュが残っていても、任意の公開プロバイダーが過去Blobを永久に返すわけではありません。 ## PeerDASはBlobを128データ列へ分ける [EIP-7594](https://eips.ethereum.org/EIPS/eip-7594)とFulu合意仕様では、Blobデータを消去符号化し、128のデータ列として扱います。ノードは保管グループ（custody group）に応じた列を保持し、サンプリングによって他の列がネットワーク上で利用可能かを確認します。 重要なのは「すべての通常ノードが、すべてのBlobバイトを必ず受信・保存する」という前提を外した点です。全データを各ノードへ複製する場合より、1ノードあたりの帯域とストレージ負担を抑えながらネットワーク全体のBlob容量を広げられます。 ただし、「各ノードは必ずちょうど8分の1だけ持つ」と一つの割合へ固定する説明も不正確です。保管要件、ノードの役割、サンプリング、再構築の経路を分ける必要があります。Blob全体を返した公開Beacon APIが、すべてのPeerDASノードでBlob全体を保存している証拠にもなりません。 プロバイダーがスーパーノードとして動くか、列から再構成して返せるためです。 ## 21 Blobを含むメインネットブロックを固定する 実測例は、2026-08-30 16:51:11 UTCのEthereumメインネットブロックです。公開実行RPCを2系統、Beacon APIを2系統で照合しました。 | 項目 | 固定済み証拠 | | --- | --- | | 実行ブロック | `25,869,397` / `0x18abc55` | | ブロックハッシュ | `0x3f3d6d7a5aa24c81e066e2ff674e5df1b21ec18888fb66f61786e0dbb69c22ba` | | ビーコンスロット / ルート | `15,107,054` / `0x1adb135d…36ee4e` | | 確定済み / オプティミスティック | `true` / `false` | | `blobGasUsed` | `2,752,512 = 21 × 131,072` | | Blobトランザクション | 7トランザクション、Blob数は`1 + 5 + 3 + 3 + 3 + 3 + 3` | | 確認時点の最大 | 21 Blob / ブロック | このブロックを選んだ理由は、観測時点の上限と同じ21 Blobを含み、Blob件数を整数で検算しやすいからです。満杯ブロックを一つ示しただけで、平均利用率、混雑度、手数料の傾向、PeerDASの性能を証明するものではありません。 ### 5 BlobのOP Mainnetバッチ送信トランザクション 7件のBlobトランザクションから、トランザクション索引46を選びました。 | 項目 | 値 | | --- | --- | | トランザクションハッシュ | `0x94dff4d56139f0286804297841f8bdc09154a1834464baeff5480b163b29c1a3` | | 型 | `0x3` | | 送信元 | `0x6887246668a3b87f54deb3b94ba47a6f63f32985` | | 送信先 | `0xff00000000000000000000000000000000000010` | | Blob件数 | 5 | | `maxFeePerBlobGas` | 1,000,000,000 wei / Blobガス | | 実行結果の状態 | 1 | [Superchain Registryの固定コミット](https://github.com/ethereum-optimism/superchain-registry/blob/52037bfea66a6b923b0d52994a3d5294634db6e5/superchain/configs/mainnet/op.toml)では、同じ`from`がOP Mainnetのバッチャー、同じ`to`がバッチ受信先です。アドレスだけを見て推測せず、チェーンID 10、`eth-da`設定と一緒に照合しています。 トランザクションにある5個のバージョン付きハッシュは、Beaconサイドカーの索引1〜5にあるKZGコミットメントから再計算した値とすべて一致しました。各Blobを復号した長さも131,072バイトです。未加工のBlobデータは容量が大きく、取得できる期間にも制限があるため公開データには含めず、コミットメント、ハッシュ、長さだけを[確認用JSON](/fixtures/fusaka-peer-das-6023.json)へ収録しました。 ## 実行ガスとBlobガスは別の手数料市場 同じtype 3トランザクションでも、実行結果には通常の実行ガスとBlobガスが別々にあります。 | 構成要素 | 数量 | 価格 | 手数料 | | --- | ---: | ---: | ---: | | 実行 | 21,000ガス | 1,114,005,115 wei / ガス | 23,394,107,415,000 wei | | Blob | 655,360 Blobガス | 6,996,870 wei / Blobガス | 4,585,468,723,200 wei | | 合計 | — | — | 27,979,576,138,200 wei | 計算は次の2本です。 ```text execution fee = 21,000 × 1,114,005,115 = 23,394,107,415,000 wei blob fee = 655,360 × 6,996,870 = 4,585,468,723,200 wei ``` 合計は`0.0000279795761382 ETH`です。これは5 Blobを含む**一つのL1バッチ送信トランザクション**の実行 + Blob手数料で、L2利用者一人の手数料ではありません。 `maxFeePerBlobGas`の1,000,000,000 weiは上限、実行結果の`blobGasPrice` 6,996,870 weiは実際に掛けた価格です。上限をそのまま支払額として計算しないでください。ブロックの`baseFeePerGas` 114,005,115 weiと実行結果の`effectiveGasPrice` 1,114,005,115 weiも役割が違います。 OPのバッチ送信トランザクションの実行手数料とBlob手数料を別計算し、圧縮データ・スカラーによる配賦、L2実行手数料、運用者手数料を経て利用者合計手数料になる3段階 ### EIP-7918は単純な固定切り捨てではない Fusakaには、Blob基準手数料が極端に低いときの挙動を調整する[EIP-7918](https://eips.ethereum.org/EIPS/eip-7918)も含まれます。`BLOB_BASE_COST`と実行基準手数料の積を、1 Blob分のガスとBlob基準手数料の積と比較し、条件を満たすと`excess_blob_gas`の更新へ予備価格を反映します。 「Blob手数料を常に固定下限へ切り上げる」だけの仕組みではありません。実行側の費用と比べながら次のブロックのBlob手数料状態を更新するため、トランザクションの実行結果にある実際の`blobGasPrice`を確認します。 ## L2利用者手数料が必ず下がるわけではない OP Stackの公式手数料資料では、Isthmus以後の利用者合計手数料を、概ね次の構成要素へ分けています。 ```text L2 user total = L2 execution fee + L1 data fee + operator fee ``` L1データ手数料は、利用者トランザクションの圧縮後サイズ、L1基準手数料またはBlob基準手数料、ロールアップが設定するスカラーなどから計算されます。バッチャーがまとめたL1トランザクションの実行結果を、利用者一人へそのまま転記するわけではありません。 PeerDASが直接変えるのは、Ethereumネットワークが受け入れられるBlobデータ容量と、ノード間でデータ可用性を確かめる方法です。そこから利用者手数料へ届くまでには、少なくとも次の条件があります。 - L2が増えた容量を実際に利用するか - バッチ圧縮後に一人あたり何バイトになるか - Blob需要とBlob基準手数料がどう動くか - L2実行ガスがどれくらい必要か - スカラー、追加負荷、運用者手数料をロールアップがどう設定するか - 容量増加分を需要増加がどれだけ使うか そのため、Blob投稿費用が下がっても運用者手数料が上がれば合計は下がらないことがあります。逆にBlob手数料が一時的に上がっても、圧縮改善やスカラー変更で利用者手数料が抑えられる場合があります。プロトコル容量、バッチャーの費用、利用者手数料を別々に観測してください。 BaseとArbitrum Oneの公開実行結果から実行とデータ構成要素を再計算する例は、[L2手数料を実行・L1データ・運用者へ分ける手順](/archives/6054)で確認できます。 ## 公開RPCで同じブロックを再確認する [確認用JSON](/fixtures/fusaka-peer-das-6023.json)には、ブロックの21 Blob、選択したトランザクションの5 Blob、実行手数料、Blob手数料、合計手数料、検証した5コミットメントを収録しています。保存値を使えば、16進数と10進数の変換、Blob件数、手数料、コミットメントハッシュをオフラインで再計算できます。 現在の公開接続先と比較するときは、次を読み取り専用で照合します。ウォレット、ブラウザー拡張機能、APIキー、署名、トランザクション送信は不要です。 1. 2つの実行RPCでブロックハッシュ、`blobGasUsed`、実行結果を比較する 2. type 3トランザクションの送信者、バッチ受信先、5個のバージョン付きハッシュを確認する 3. 2つのBeacon APIでスロットと正規ルートを比較する 4. サイドカーがまだ取得できる間は、索引1〜5のコミットメント、バージョン付きハッシュ、Blob長さを確認する 5. 現在の`eth_config`を記事作成時のスナップショットと分けて表示する 公開RPCを使った調査で値が動くときは、`latest`を何度も読む前に[未加工RPCをブロックへ固定する手順](/archives/6024)を参照してください。トランザクションの`pending`、`included`、`confirmed`を区別する基礎は[トランザクションの状態の確認順](/archives/6004)、L2入金が見えない場合の送信元トランザクション、メッセージ、送信先の切り分けは[ブリッジ未着金の確認手順](/archives/6027)で扱っています。正規L2→L1の証明・チャレンジ・L1実行を追う場合は[L2出金の段階確認手順](/archives/6028)へ進みます。 ブリッジの送信先実行後に取引所残高へ反映されない場合は、さらに[チェーン状態と取引所内状態を分ける手順](/archives/6008)へ進みます。 ### サイドカーは後から取得できなくなる Fulu P2P仕様では、サイドカー要求へ応答する最低期間が4,096エポックです。1エポックを約6.4分として換算すると約18.2日ですが、これは履歴提供を永久に義務付ける期間ではありません。 後日サイドカーを再取得したときに接続先が404 / 410を返した場合は、保存期間の制限によって確認できない状態として扱います。実行ブロックのバージョン付きハッシュと実行結果は照合できるため、「サイドカーを取得できない＝元のトランザクションにBlobがなかった」とは判断しません。長期保存が必要なら、執筆時のコミットメントか、信頼条件を明示した履歴データの取得元を別に残します。 ## メインネット・現在スナップショット・将来を分ける 仕様変更の記事では、提案名より状態と有効化条件が重要です。 | クラス | この記事で確定扱いするもの | 読み方 | | --- | --- | --- | | メインネット有効化済み | Fusaka、PeerDAS、EIP-7918、BPO1、BPO2 | 有効化日付 / スロット / エポックを一次情報へ結ぶ | | 記事作成時点 | `eth_config`の目標14 / 最大21、`next: null` | 2026-08-31時点のプロバイダー観測として扱う | | 将来 / 未安定 | 後続フォークの仕様上の記載、下書きEIP、未有効化の引数 | メインネットの挙動へ混ぜず、再確認日を付ける | `eth_config.next === null`は、そのRPCが現在「次の設定を返していない」という意味です。Ethereumに次の更新が存在しない、今後引数が変わらない、という保証ではありません。 またEIPページの状態がFinalでも、どのネットワークでいつ有効化したかは別の確認です。EIP本文、フォーク仕様、メインネット発表、現在のRPC観測の順に対応させると、下書きと稼働中仕様を混ぜにくくなります。 ## Fusaka・Blob・L2手数料確認チェックリスト - [ ] メインネット有効化日付、スロット、エポックを一次情報で固定した - [ ] Fusaka有効化と後続BPOの引数変更を分けた - [ ] type 3トランザクションのバージョン付きハッシュとBlobバイトの保存場所を分けた - [ ] 1 Blobを131,072バイト / Blobガスとして整数検算した - [ ] PeerDASの保管、サンプリング、再構築を全ノードによる全体複製と混同していない - [ ] 実行ガスとBlobガスを実行結果から別計算した - [ ] `maxFeePerBlobGas`と実際の`blobGasPrice`を分けた - [ ] バッチャーの送信者とバッチ受信先を対象L2の公式登録簿で照合した - [ ] バッチ送信費用を利用者一人の手数料として転記していない - [ ] 圧縮、L2実行、スカラー、運用者方針、需要を条件へ残した - [ ] サイドカーの保存期間後に何が再現できないか明示した - [ ] 現在の設定、将来の提案、メインネットで有効化済みの仕様を別の欄へ置いた 結論は、**Fusaka / PeerDASはBlobデータ容量とノードによるデータ可用性の検査を変えたが、L2利用者手数料は別の構成要素を含む**ということです。ブロック、トランザクション、実行結果、Beaconデータ、L2手数料計算式を順番に固定すれば、「Blobが増えた」「バッチャーの費用が変わった」「利用者手数料が下がった」を別々に検証できます。 この記事にスポンサー、アフィリエイト、ウォレット接続、ブリッジ、署名要求、トランザクション送信、資産操作の販売誘導はありません。将来L2、RPC、ノード基盤、データ可用性、開発者向けホスティングの広告を置く場合も広告であることを明示し、公式仕様、メインネットの証拠、手数料計算、プロトコル評価から分離します。 ## 確認した一次情報 - [ethereum.org Fusaka roadmap](): 確認日 2026-08-31 - [Ethereum Foundation Fusaka mainnet announcement](): 確認日 2026-08-31 - [EIP-7594 PeerDAS](): 確認日 2026-08-31 - [EIP-4844 Shard Blob Transactions](): 確認日 2026-08-31 - [EIP-7918 Blob base fee bounded by execution cost](): 確認日 2026-08-31 - [EIP-7892 Blob Parameter Only hardforks](): 確認日 2026-08-31 - [EIP-7910 eth\_config JSON-RPC method](): 確認日 2026-08-31 - [Ethereum consensus specs Fulu DAS core](): 確認日 2026-08-31 - [Ethereum consensus specs Fulu P2P interface](): 確認日 2026-08-31 - [OP Stack transaction fees](): 確認日 2026-08-31 - [OP Stack derivation specification](): 確認日 2026-08-31 - [Superchain Registry OP Mainnet configuration](): 確認日 2026-08-31 --- # Ethereum RPCのlatestがずれる理由｜固定ブロック・履歴状態・Multicall Ethereum RPCのpending・latest・safe・finalized、ブロック番号とハッシュ、履歴状態、JSON-RPCの一括要求、Multicallを比較し、同じブロックで価格・残高・スロット・ログを再現します。 正規URL: https://3mikan.com/archives/6024 著者: みかん 公開: 2026-08-30T18:45:00.000Z 更新: 2026-09-02T05:35:00.000Z Ethereum RPCで同じアドレスを読んだはずなのに、価格、残高、利用許可額、プロキシスロット、イベントが噛み合わない。最初に確認するのはプロバイダー名ではなく、**すべての読み取りが同じブロックを参照したか**です。 `latest`は固定スナップショットではありません。1回目の`eth_call`と2回目の`eth_getLogs`の間にチェーンの先端が進めば、どちらも正しい応答でも、組み合わせた結果はチェーン上の一つの時点に存在しません。 対策は、目的に合う`safe`または`finalized`を一度取得し、そのブロック番号とハッシュを保存してから全方法へ渡すことです。JSON-RPC一括処理やMulticallは要求をまとめますが、ブロック指定の代わりにはなりません。 この記事ではローカルAnvilで変化する`latest`の失敗を再現し、Ethereumメインネットブロック`25,869,830`へ価格・残高・利用許可額・未加工ストレージ・ログを固定します。公開RPCの観測は2026-08-31、日本リージョン、認証不要の公開プランです。ウォレット、APIキー、署名、トランザクション送信、資産操作は使いません。 ## 保留中・`latest`・安全・確定済みは位置が違う [Ethereum JSON-RPCのブロック引数](https://ethereum.org/developers/apis/json-rpc/)は、数量で指定するブロック番号のほか、`pending`、`latest`、`safe`、`finalized`などのタグを受け取ります。 | 識別子 | 何を選ぶか | 主な用途 | 注意点 | | --- | --- | --- | --- | | `pending` | 次のブロック候補に対応する保留中状態 | メモリープール反映後のシミュレーション | 内容が変わる。ハッシュが`null`の実装もある | | `latest` | ノードが現在の正規チェーンの先端とみなすブロック | 最新表示、低遅延監視 | 呼び出しごとに進み、近いチェーン再編の影響を受ける | | `safe` | 合意層が安全とするチェーンの先端 | `latest`より強い基準の表示 | 方法・プロバイダーの対応差を確認する | | `finalized` | 確定済みチェックポイントに対応するチェーンの先端 | 再現用ブロックの選択、会計・記事データ | `latest`より古い。極端な合意失敗までの絶対保証ではない | | ブロック番号 | その高さのブロック | 複数方法を同じ高さへ揃える | 未確定ではチェーン再編後に別ハッシュへ対応し得る | | ブロックハッシュ | そのブロック識別情報 | 厳密な再現、正規性確認 | 方法がEIP-1898へ対応するか確認する | 2026-08-31 03:46 JST前後に3つの公開接続先を確認したスナップショットでは、`pending` 25,869,973、`latest` 25,869,972、`safe` 25,869,926、`finalized` 25,869,894でした。2接続先は保留中ブロックのハッシュを`null`、1接続先は暫定ハッシュを返しています。 これはプロバイダーの優劣を示す表ではありません。同じ時刻帯でもタグが指す位置と返却項目が異なり得るため、取得日時、接続先、契約プラン、地域、番号、ハッシュを一緒に保存する例です。 Ethereum RPCの保留中、latest、安全、確定済みと固定ブロックの位置関係。変化するチェーンの先端から一つのブロック番号とハッシュを固定する ### 確定済みは強いが「何があっても不可逆」ではない Ethereumのプルーフ・オブ・ステークでは、バリデーターの3分の2を超える投票によりチェックポイントが確定されます。通常の短いチェーン再編と比べて、確定済みブロックを覆すには大規模な合意失敗やスラッシング対象となる振る舞いが必要です。 したがって再現用スナップショットには`finalized`が扱いやすい一方、「数学的に絶対不可逆」「プロバイダーが確定済みと返せば必ず正しい」とは書けません。別接続先で番号とハッシュを照合し、観測条件を残します。 ## ブロックを一度解決して全読み取りへ渡す viemでは、最初に`finalized`ブロックを一度だけ取得します。その後は`blockTag`を繰り返し使わず、解決済みの`block.number`を全読み取りへ渡します。 ```ts const block = await client.getBlock({ blockTag: 'finalized' }) if (block.number === null || block.hash === null) { throw new Error('finalized block identity is unavailable') } const at = block.number const price = await client.readContract({ address: feed, abi: feedAbi, functionName: 'latestRoundData', blockNumber: at, }) const balance = await client.readContract({ address: token, abi: erc20Abi, functionName: 'balanceOf', args: [holder], blockNumber: at, }) const implementation = await client.getStorageAt({ address: proxy, slot: implementationSlot, blockNumber: at, }) const logs = await client.getLogs({ address: token, fromBlock: at, toBlock: at, }) ``` ブロック番号を使う利点は、viemの各操作へ同じ形で渡しやすいことです。同時にハッシュも保存し、別プロバイダーから取得したブロックヘッダーが同じハッシュか照合します。 プロキシの未加工スロットを読む手順は[ERC-1967プロキシをブロックへ固定して調べる記事](/archives/6020)、トランザクション・実行結果・イベントのエラー層を先に分ける場合は[トランザクション失敗を切り分ける順番](/archives/6001)も参照してください。 ## EIP-1898でブロックハッシュと正規性を指定する [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898)は、ブロック番号の代わりに`blockHash`を含むオブジェクトを渡せる形を定義しています。`requireCanonical: true`を付けると、そのハッシュが正規チェーン上にない場合をエラーとして扱えます。 ```ts const raw = await client.request({ method: 'eth_call', params: [ { to: feed, data: latestRoundDataCalldata }, { blockHash: block.hash, requireCanonical: true }, ], }) ``` EIP-1898の対象には`eth_getBalance`、`eth_getStorageAt`、`eth_getTransactionCount`、`eth_getCode`、`eth_call`、`eth_getProof`があります。`blockNumber`と`blockHash`を同じオブジェクトへ同時に入れず、`requireCanonical`はハッシュと一緒に使います。 今回の固定ブロックハッシュは`0x53d1375a96ad48b9a0f3e30152c0f01dc142fca8dce2f22ee95270a27b365294`です。公開接続先とAnvilの両方で、`blockHash` + `requireCanonical: true`の`eth_call`が番号固定と同じ値を返しました。 ただし、ゲートウェイがEIP-1898を実装していない場合があります。その場合は番号と取得済みヘッダーハッシュを別々に照合し、未対応エラーも隠さず記録します。ハッシュ指定は履歴状態を生成しないため、古い状態が削除済みならやはり失敗します。 ## 過去の`eth_call`には状態履歴が必要 古いブロックヘッダーやトランザクションを取得できることと、その時点のコントラクト状態で`eth_call`できることは別です。過去呼び出しには、対象ブロックの状態を再構成できる実行クライアントまたは履歴サービスが必要です。 Gethの状態履歴に関する現在の文書では、パス方式の状態履歴を`--history.state`で設定します。現在のコマンドラインリファレンスは既定を90,000ブロックとし、`0`は全履歴を要求する値です。設定、同期方式、クライアントバージョン、プロバイダーのプランによって利用可能な深さは変わります。 ### 同じ接続先で現在は成功、古いブロックは失敗した Chainlink ETH/USDフィードの`latestRoundData()`を、`latest`とブロック16,000,000で同じ公開接続先へ送りました。 | 要求 | 2026-08-31の観測結果 | | --- | --- | | `eth_call(..., "latest")` | HTTP 200、復号済み結果を取得 | | `eth_call(..., "0xf42400")` | HTTP 403 / RPCコード`-32602` | | エラー | `Archive requests require a personal token` | 同じ過去呼び出しは、記事作成時点の別の認証不要の公開接続先で成功し、ETH/USDの回答`120872000000`、小数桁8、`updatedAt`は`2022-11-18T21:55:35Z`を返しました。 ここから言えるのは、**ブロック16,000,000の状態自体は取得可能だが、最初の認証不要の公開プランでは履歴要求として拒否された**ことです。失敗した接続先が履歴非対応のノードである、別の接続先が永久に全履歴を保証する、とまでは断定できません。プランの条件、保存期間、振り分け、利用制限は後から変わり得ます。 ## 連番・JSON-RPC一括処理・Multicallの違い 3方式は「何をまとめるか」が違います。 | 方法 | HTTP / RPC形状 | 同一ブロックになる条件 | 応答 / 失敗 | 対象外 | | --- | --- | --- | --- | --- | | 連番 | 呼び出しごとに1要求 | 全呼び出しへ同じ番号/ハッシュを渡す | 呼び出し単位で順番に処理 | 要求途中で`latest`が動く | | JSON-RPC一括処理 | 複数RPC項目を1 HTTP本文へ入れる | 各項目へ同じ番号 / ハッシュを渡す | 順序は保証されずIDで照合 | 同一時点での実行保証 | | Multicall3 | 1回の`eth_call`内で複数コントラクト呼び出し | 外側の`eth_call`へブロックを指定 | 呼び出しごとの`allowFailure`を設計 | ログ、未加工ストレージ、履歴状態の提供 | [JSON-RPC 2.0仕様](https://www.jsonrpc.org/specification)では、一括処理内の要求をサーバーが並列または任意順で処理でき、応答順序も要求順序と一致する必要はありません。配列位置ではなく`id`で結合します。 viemの`multicall`操作はMulticall3へ複数のコントラクト読み取りを渡し、1回のRPC呼び出しへまとめます。同じ外側の`eth_call`なので、コントラクト側の読み取りは一つのEVMブロック文脈を共有します。`blockNumber`を省略すれば、その1回が実行された時点の`latest`です。 後日同じ値を再現したいなら明示的ブロックを残します。 連番RPC、JSON-RPC一括処理、Multicall3の要求数とスナップショット境界。共通の明示的な固定ブロックと、別RPCになる未加工ストレージ・ログを示す ### 一括処理だけでは同一時点のスナップショットにならない 次の一括処理は1 HTTP要求ですが、各項目が`latest`を指定しています。サーバーは独立して処理できるため、チェーンの先端が切り替わる境界をまたぐ可能性を仕様上排除できません。 ```json [ {"jsonrpc":"2.0","id":4105,"method":"eth_call","params":[{"to":"0x…","data":"0x…"},"latest"]}, {"jsonrpc":"2.0","id":4101,"method":"eth_call","params":[{"to":"0x…","data":"0x…"},"latest"]} ] ``` `latest`を両方とも`0x18abe06`へ変えれば、処理順や応答順にかかわらず同じブロック状態を要求できます。一括処理がスナップショットを作るのではなく、各項目のブロック指定がスナップショットを作ります。 ### Multicallに入らない状態もある Multicall3はEVMコントラクト呼び出しをまとめます。`balanceOf`、`allowance`、オラクル読み取り関数、複数コントラクトの`view`関数には向きます。 一方、`eth_getStorageAt`はノードのRPC方法、`eth_getLogs`は実行結果ログ索引からの検索です。Multicallコントラクトから同じ形で取得できません。これらは別要求のまま同じブロック番号またはハッシュへ固定し、結果を後から結合します。 また、Multicallを古いブロックへ指定しても、プロバイダーがその過去状態を持たなければ外側の`eth_call`が失敗します。Multicallは履歴ノードの代替ではありません。 ## Anvilで変化する最新状態のずれを再現する ローカル再現環境はFoundry / Anvil `1.8.0`、Solidity `0.8.36`、viem `2.56.0`、Prague EVM、チェーンID `31337`へ固定しました。固定ブロックの読み取りと、変動する`latest`を混ぜた場合の失敗を分けて確認しています。 最初にブロック3で4種類の状態を更新し、`price()`を`latest`で読みます。その後、別トランザクションでブロック4へ進めてから`balanceOf()`を`latest`で読みました。 | 読み取り | ブロック | 値 | | --- | ---: | ---: | | 最初の`price()`を`latest`で取得 | 3 | 250,000,000,000 | | 状態更新トランザクション | 4 | 価格 / 残高 / 利用許可額 / 未加工スロットを更新 | | 2回目の`balanceOf()`を`latest`で取得 | 4 | 1,400,000 | 2つの応答は個別には正しいですが、ブロック3の`price`とブロック4の`balance`を組み合わせても、一つのスナップショットにはなりません。 次に全呼び出しをブロック3へ固定しました。 | 状態 | 想定値 | 逐次呼び出し | JSON-RPC一括処理 | Multicall | | --- | ---: | ---: | ---: | ---: | | 価格 | 250,000,000,000 | 250,000,000,000 | 250,000,000,000 | 250,000,000,000 | | 残高 | 1,250,000 | 1,250,000 | 1,250,000 | 1,250,000 | | 利用許可額 | 7 | 7 | 7 | 7 | | 未加工値 | 41 | 41 | 41 | 41 | 一括処理の要求ID順序は`3003, 3001, 3004, 3002`です。応答配列を意図的に逆順へ並べる検証でも、IDで結合して同じ4値になることを確認しました。 同じブロック3のスロット0は`0x…0029`、復号済み値は41です。`SnapshotUpdated`イベントのブロックハッシュもブロック3と一致し、EIP-1898ハッシュを固定した呼び出しも41を返しました。[ローカル再現JSON](/fixtures/ethereum-rpc-local-6024.json)にブロック、未加工スロット、イベント、要求順序を保存しています。 ## メインネットで5種類の状態を同じブロックへ固定した 公開計測はEthereumメインネットブロック`25,869,830`、16進数`0x18abe06`、タイムスタンプ`2026-08-30T18:17:59Z`を使いました。執筆時点の確定済みブロックより64ブロック古く、状態取得に対応する2つの公開接続先でブロックハッシュと全コントラクト読み取りを照合しています。 | 状態の種類 | 対象 / メソッド | 固定ブロックの結果 | | --- | --- | --- | | オラクル価格 | Chainlink ETH/USD `latestRoundData()` | `250019228748` / 小数桁8 = 2,500.19228748 USD | | トークン残高 | USDC `balanceOf(OP L1StandardBridge)` | `25313978911659` / 小数桁6 = 25,313,978.911659 USDC | | トークン利用許可額 | USDC `allowance(bridge, portal)` | 0 | | 未加工プロキシストレージ | ブリッジEIP-1967実装スロット | `0xB37a11AadF167B2F0b8dD85372De4bC66CD4A891` | | イベントログ | 固定ブロック内のUSDC `Transfer` | 14件 | Chainlinkラウンドの`updatedAt`は`2026-08-30T17:26:11Z`です。ブロックタイムスタンプより前なのは正常です。オラクルが各ブロックで必ず更新されるのではなく、そのブロック時点でコントラクトが保持していた最新ラウンドを読んでいるためです。 この固定ブロックの値一式を利用側で「利用可能」「古い」「異常」へ分ける手順は、[DeFiオラクルの小数桁・鮮度切れ・TWAP検証](/archives/6042)で、L2シーケンサーと代替価格を含めて確認しています。 コントラクト読み取り関数6件は、連番6 HTTP要求、JSON-RPC一括処理1 HTTP要求、Multicall3 1 `eth_call`の3方式ですべて一致しました。別接続先でも同じ6値です。 未加工実装スロットと14件のログは別RPCですが、同じブロック番号を使用しています。14件のログを正規化したJSONのSHA-256は`b2aa6df269ad18cc0d587f2ac82c1758bada2beaeb550a9a82557c8ec77e839a`です。[公開計測JSON](/fixtures/ethereum-rpc-snapshot-6024.json)には全未加工ログ、未加工の`eth_call`、一括処理ID順序、EIP-1898の結果、履歴取得の成功 / 失敗を残しました。 USDCアドレスはCircle公式、Chainlinkフィードは公式クイックスタート、OP Mainnetブリッジ / PortalはSuperchain Registryの固定コミットから確認しています。アドレスとABIを推測してプロバイダー比較へ混ぜないためです。 ## 後日同じ条件で再確認する 再確認では、先に[公開計測JSON](/fixtures/ethereum-rpc-snapshot-6024.json)のブロック番号・ハッシュ・未加工値を読み、保存済みの観測と現在の観測を分けます。固定ブロックを読み取り専用で取得し直した結果は保存済み証拠と比較し、`latest`など動くタグや履歴取得の可否は再確認時点の結果として別に記録します。 接続先はHTTPS、認証情報なし、問い合わせ文字列なしの公開RPCに限定します。別の接続先を使う場合も認証ヘッダー、ウォレット、秘密鍵、署名、トランザクション送信は扱いません。 | 項目 | 確定済み計測 | | --- | --- | | `checkedAt` | 2026-08-30T18:46:35.912Z | | ネットワーク / チェーンID | Ethereumメインネット / 1 | | 地域 | JP | | 契約プラン | 公開・未認証。アカウントやAPIキーは不使用 | | Node / viem | Node 24 / viem 2.56.0 | | 遅延の順位付け | 実施していない | | 固定ブロック | 25,869,830 / `0x53d1…5294` | | 過去試験呼び出し | ブロック16,000,000 | タグ対応、履歴深さ、利用制限、キャッシュ、振り分け、契約プランは変わります。後日の再取得では履歴エラーが消える、別エラーになる、接続先自体が終了する可能性があります。掲載済みJSONは執筆時の未加工観測、再取得した値は現在の確認結果として分けてください。 ## プロバイダー差を調べる順番 値が違うときは、次の順に狭めます。 1. チェーンID、コントラクトアドレス、ABI、関数識別子、引数を固定する 2. 各応答のブロック番号とハッシュを記録する 3. `latest`を一度`safe`または`finalized`へ解決し、明示的ブロックで再実行する 4. 番号取得後に別接続先で同じハッシュか確認する 5. 一括処理応答を配列位置ではなくIDで結合する 6. Multicallの外側ブロック、コントラクトごとの成功、`allowFailure`を記録する 7. 過去の失敗についてHTTPステータス、RPCコード、メッセージ、契約プラン、地域、タイムスタンプを残す 8. RPCノード、索引サービス、キャッシュ、ブロックエクスプローラー APIのどの層を読んだか分ける `latest`でだけ違い、固定ブロックで一致するなら変化するチェーンの先端または近いチェーン再編が第一候補です。固定ブロックでも一方だけ古い呼び出しに失敗するなら状態履歴または契約プランの境界を調べます。同じブロックハッシュで未加工RPCは一致するのにブロックエクスプローラー集計だけ遅れるなら、索引サービス遅延やキャッシュを別層として確認します。 Blobデータのように実行状態とは別の保存期間境界を持つ証拠は、[Fusaka・PeerDASとBlob手数料の固定ブロック検証](/archives/6023)で扱っています。実行RPCがトランザクションハッシュを返しても、別APIの過去データが永久に残るとは限りません。 同じブロック番号 / ハッシュへ手数料履歴、実行結果、手数料オラクルの読み取りを対応させる実例は、[Base・Arbitrum OneのL2手数料分解](/archives/6054)で扱っています。 同じ考え方でOP StackのPortal状態やArbitrumのOutbox状態を確認する場合は、[L2出金を証明・チャレンジ・確定・受取へ分ける手順](/archives/6028)を参照してください。ERC-20の未加工`balanceOf`を小数桁とウォレット表示へ対応させる場合は、[トークンが表示されない時の確認順](/archives/6029)へ進みます。`latest`のコントラクト値と過去実行結果タイムスタンプを、同じ時点の保証として混ぜないことが重要です。 ## Ethereum RPCスナップショット確認チェックリスト - [ ] チェーンID、アドレス、ABI、引数を固定した - [ ] 保留中 / `latest` / 安全 / 確定済みのどれを選んだか記録した - [ ] タグを一度番号とハッシュへ解決した - [ ] コントラクト読み取り、未加工ストレージ、ログへ同じブロックを渡した - [ ] 番号固定とハッシュ / 正規性確認を分けた - [ ] EIP-1898未対応エラーも保存した - [ ] 逐次呼び出し / 一括処理 / Multicallを同じブロック条件で比較した - [ ] 一括処理応答をIDで対応させた - [ ] Multicallへ入らないログと未加工ストレージを別RPCで固定した - [ ] 過去状態に必要な保存期間 / 履歴 / 契約プランを確認した - [ ] 接続先、地域、契約プラン、タイムスタンプ、HTTPステータス、RPCエラーを残した - [ ] 公開接続先の一回の観測を永久仕様や性能順位にしていない 結論は、**RPCスナップショットは先にブロック番号とハッシュを一度解決し、価格、残高、利用許可額、未加工ストレージ、ログの全読み取りを同じブロックへ対応させること**です。逐次呼び出し、一括処理、Multicallは要求のまとめ方を選ぶ手段で、スナップショットの識別情報や履歴の利用可否は別に設計します。 このスナップショットをFoundryへ渡し、`prank`、`deal`、`store`、`etch`などのローカル変更とプロバイダー由来状態を分ける方法は、[Foundryフォークテストの再現記録](/archives/6051)で扱っています。 この記事にスポンサー、アフィリエイト、ウォレット接続、署名要求、トランザクション送信、資産操作の販売誘導はありません。将来RPC、ノードホスティング、監視、データ基盤の広告を置く場合も広告であることを明示し、測定方法、未加工結果、プロバイダーの観測、技術的な結論から分離します。 接続先差の原因が429、タイムアウト、JSON-RPCコード、ノード方針、トランザクション検証、EVMのどこにあるかを先に分ける場合は、[Ethereum RPCエラーの層別診断](/archives/6032)で未加工の応答とviemの原因チェーンを照合してください。 ## 確認した一次情報 - [Ethereum JSON-RPC API](): 確認日 2026-08-31 - [Ethereum proof-of-stake finality](): 確認日 2026-08-31 - [EIP-1898 blockHash in JSON-RPC](): 確認日 2026-08-31 - [JSON-RPC 2.0 Specification](): 確認日 2026-08-31 - [Geth archive mode](): 確認日 2026-08-31 - [Geth command-line options](): 確認日 2026-08-31 - [viem getBlock](): 確認日 2026-08-31 - [viem multicall](): 確認日 2026-08-31 - [Multicall3 source](): 確認日 2026-08-31 - [Circle USDC contract addresses](): 確認日 2026-08-31 - [Chainlink historical prices quickstart](): 確認日 2026-08-31 - [Superchain Registry OP Mainnet configuration](): 確認日 2026-08-31 - [Foundry v1.8.0](): 確認日 2026-08-31 --- # ウォレットの署名要求は安全？eth\_sign・EIP-712・SIWE・委任の見分け方 ウォレットの署名・トランザクション・利用許可を分け、eth_sign、personal_sign、EIP-712、SIWE、Permit・Permit2、EIP-7702を比較します。ドメイン、チェーン、コントラクト、利用先、数量、ノンス、有効期限を署名前に確認します。 正規URL: https://3mikan.com/archives/6025 著者: みかん 公開: 2026-08-30T20:05:00.000Z 更新: 2026-09-02T05:35:00.000Z ウォレットに「署名」と表示されても、すぐに資産が動くトランザクションとは限りません。反対に、ガスが表示されないから安全とも限りません。チェーン外で作った署名が、後からトークン権限、注文、ログインセッション、アカウント委任へ使われる場合があるためです。 最初に、**署名・トランザクション・利用許可を別のものとして確認**します。その後で方法、オリジン、アカウント、チェーン、コントラクト、権限、ノンス、期限を一つの要求へ対応させます。一つでも説明できなければ署名せず、画面を閉じて自分で開いた公式サイトへ戻ってください。 この記事で掲載するウォレット画面はMetaMask公式文書のサンプルです。個人アカウント、3MIKANのウォレット、実資産は使わず、ウォレット接続、署名、トランザクション送信も行っていません。 ## 署名・トランザクション・利用許可は別の軸 | 用語 | その場で作るもの | ガス / ネットワークへの送信 | 後から残り得るもの | 例 | | --- | --- | --- | --- | --- | | 署名 | メッセージや構造化データに対する署名者の証明 | 作成時は通常ガスなし、チェーンへ送信しない | アプリケーションが署名を提出・検証した後のセッション、注文、利用許可額など | `personal_sign`、EIP-712、SIWE、Permit | | トランザクション | チェーンへ送る実行要求への署名 | ネットワークへの送信後、実行条件を満たせばガスと実行結果が発生 | 送金、コントラクト状態、イベント、委任など | 送金、交換、`approve`、EIP-7702のtype 0x04トランザクション | | 利用許可 | 利用先へトークン使用権限を与えるという**結果** | `approve`トランザクションでもPermit署名でも作れる | トークンコントラクトやPermit2に保存された利用許可額 | ERC-20の`approve`、ERC-2612 Permit、Permit2 AllowanceTransfer | 「署名かトランザクションか」は要求の形、「利用許可か」は権限の状態更新です。したがって「署名だから利用許可ではない」「ガスが0だから資産へ影響しない」という判断はできません。 ## 突然開いたら、まず止まる条件 次のどれかに当てはまる場合は、「Confirm」や「Sign」を押しません。 - 自分が始めていない操作で、要求元のブラウザーオリジンを説明できない - メソッドが不明、未加工のハッシュやバイナリーデータだけで内容を読めない - 選択中アカウントまたはチェーンが期待と違う - コントラクト、トークン、利用先、委任先のアドレスを公式情報と照合できない - 数量が空、不自然に大きい、無制限、または単位を確認できない - ノンス、有効期限、権限失効時刻がなく、再利用範囲を説明できない - 「取消」「本人確認」「復旧」のためにシードフレーズや秘密鍵の入力を求められる シードフレーズと秘密鍵は、署名を取り消すためにもサポートへ本人確認するためにも入力しません。検索広告やDMのリンクを使わず、自分でブックマークまたは公式ドメインからサポートへ戻ります。 ## 署名前に書き出す9項目 要求元と署名アカウントを含む、次の9項目を確認します。 | 項目 | 画面・要求で確認する値 | 不明なら何をするか | | --- | --- | --- | | 方法 / 目的 | `personal_sign`、`eth_signTypedData_v4`、SIWE、Permit、EIP-7702など。ログインか権限付与か | DAppの説明ではなく要求JSONやウォレット表示を確認。未加工 / 不明なら拒否 | | オリジン / ドメイン | ブラウザーオリジン、`Request from`、署名済みドメイン、URI | 文字列の一部一致で済ませず、スキーム・ホスト・ポートを照合 | | アカウント | 署名するアドレス、所有者、権限 | 複数アカウントを切り替えた直後は特に確認 | | チェーン | チェーンID、ネットワーク | 名前だけでなくチェーンIDを見る。`0`など広い適用範囲も確認 | | コントラクト | `verifyingContract`、トークン、Permit2、委任先アドレス | 公式文書・ブロックエクスプローラーの検証済みソース・デプロイ情報へ戻る | | 利用先 / 委任先 | 資産を使うアドレス、コードを委任するアドレス | フロントエンド名ではなくアドレスとコードの役割を確認 | | 数量 | トークン、小数桁、数量、上限、受取先 / 証明データ | 無制限や単位不明なら署名しない | | ノンス | メッセージ、トークン、Permit2、権限のノンス | どこで消費され、再利用を何が止めるか確認 | | 有効期限 | 署名提出期限、権限期限、セッション期限 | `deadline`と`expiration`を同じものとして扱わない | ウォレット署名要求を方法、オリジン、アカウント、チェーン、コントラクト、権限、数量、ノンス、有効期限、後続状態更新の順で確認し、不明なら署名せず停止する判断フロー ## 7形式を同じ表で分ける | 形式 | 署名時のチェーン上状態 / ガス | 主な用途と後続状態更新 | 再利用・期限の境界 | 最低限見る項目 | | --- | --- | --- | --- | --- | | `eth_sign` | 通常は署名だけ。ウォレット・クライアント実装差が大きい | 不透明なデータやハッシュへの署名として扱われ得る | 要求自体に共通のノンス / 有効期限規則はない | 方法、ペイロードの意味、オリジン、アカウント、ウォレット実装 | | `personal_sign` / ERC-191 | 署名だけ | 人が読むメッセージ、ログインチャレンジ、アプリケーション独自認可 | メッセージへノンス・期限・ドメインを入れない限り共通規則はない | オリジン、アカウント、メッセージ全文、ドメイン、ノンス、期限 | | EIP-712 | 型付きデータへの署名だけ | 注文、許可、プロトコル操作などを構造化 | EIP-712自体は再利用対策を提供しない | ドメイン、`chainId`、`verifyingContract`、`primaryType`、メッセージ全文 | | SIWE / ERC-4361 | ERC-191メッセージへの署名だけ | サーバー検証後にウェブセッションを作る | ドメイン、URI、チェーンID、一度だけ使えるノンス、発行時刻 / 失効時刻 | 要求元（Request from）、ドメイン、URI、アカウント、チェーンID、ノンス、時刻 | | ERC-2612 Permit | 署名者はガスなし。第三者が提出可能 | トークンコントラクトの利用許可額を設定 | トークンノンスと`deadline` | トークン / `verifyingContract`、所有者、利用先、値、ノンス、有効期限 | | Permit2 | 署名者はガスなし。提出後に権限または送金 | AllowanceTransferまたはSignatureTransfer。トークン→Permit2利用許可は別層 | 順序付き / 順不同ノンス、`sigDeadline`、利用許可額の`expiration`など方式別 | Permit2、トークン、利用先、数量、ノンス、各期限、受取先 / 証明データ | | EIP-7702認可 | 認可単体ではなくtype 0x04トランザクションの処理で反映 | 認可したEOAへ委任先コードの実行入口を設定 | 認可ノンス、チェーンID、外側トランザクション。ストレージ等は別に残る | 認可したEOA、チェーンID、委任先、ノンス、外側トランザクションと呼び出し元制約 | [公開検証データ](/fixtures/wallet-signature-6025.json)には、この7形式の検証用項目と未署名ダイジェストを保存しています。viem `2.56.0`でローカル計算し、ウォレット、秘密鍵、署名、外部RPC、コントラクト呼び出し、トランザクションは使っていません。ダイジェスト一致は符号化の再現にすぎず、オリジン、UI表示、コントラクトの安全性、再利用防止、同意を証明しません。 ## `eth_sign`は方法名だけで意味を決めない MetaMaskのMIP-3は、同ウォレットの従来の`eth_sign`を任意ハッシュの盲目的署名につながる方法として廃止対象にし、現在の公式署名データ手引きも非推奨としています。一方、Ethereum.orgのノードJSON-RPC説明は同名方法にEthereum Signed Message接頭辞を記載しています。 この差があるため、`eth_sign`をウォレット横断で一つのダイジェスト式や一つの表示へ一般化しません。要求元、クライアント、バージョン、ペイロード解釈を独立して確認できず、未加工ハッシュしか見えないなら拒否するのが安全側です。「ログインのため」「ガスはかからない」というDApp側の説明だけで押さないでください。 ## `personal_sign`は読めるメッセージでも作用を確認する ERC-191は署名済みデータの先頭を`0x19`で区別し、バージョン`0x45`をEthereum Signed Message形式へ割り当てます。MetaMaskの公式手引きは`personal_sign`を人が読めるメッセージに使い、不透明なバイナリーデータを表示させないよう案内しています。 ただし、読める文章なら無害という意味ではありません。次のような文面は、署名後にアプリケーションが認可として解釈できます。 - ログインチャレンジとしてサーバー側セッションを発行する - 規約・注文・受け取りへ同意した証明として保存する - ドメインやノンスのない文章を別サイト・別時点で再利用する メッセージ全文、要求オリジン、署名アカウントを読み、ドメイン、目的、ノンス、発行時刻、失効時刻が必要な用途なら本文へ入っているか確認します。見慣れた挨拶文でも、末尾や折りたたみ範囲を省略しません。 ## EIP-712は構造化するが安全を保証しない EIP-712は`domain`、`types`、`primaryType`、`message`を分け、ウォレットが項目を構造化表示できるようにします。ドメイン区切りには通常、名前、バージョン、チェーンID、検証コントラクトが入ります。 ここで確認するのは見た目ではなく値です。 1. ブラウザーの要求オリジンと、ウォレットの`Request from` 2. 選択中ネットワークとドメインの`chainId` 3. `verifyingContract`と公式デプロイアドレス 4. `primaryType`が示す操作 5. 利用先、委任先、受取先、トークン、数量を含むメッセージ全文 6. ノンス、有効期限、アプリケーション側の使用済み状態 EIP-712仕様は、同形式自体が再利用対策を含まないと明記しています。ドメイン分離が正しくても、アプリケーションがノンスや使用済み状態を検証しなければ再利用を止められません。詳しいダイジェスト構造は[EIP-712のドメイン・ノンス・有効期限を照合する記事](/archives/6010)で確認できます。
MetaMask公式サンプルの型付きデータ署名画面。ネットワーク、要求元、操作先、主要な型、メッセージの位置を示す
MetaMask公式の署名データ文書にあるサンプルUI。ネットワーク（Network）、要求元（Request from）、操作先（Interacting with）、主要な型（Primary type）、メッセージ（Message）を分けて表示しています。文書は2026-08-04更新、画面は2026-08-31に確認し、拡張機能v13.46.0のサンプル実装とも照合しました。`Account 1`は公式サンプルで、3MIKANのアカウントではなく、この記事で署名していません。
ウォレットが表示したコントラクト名やサイト名だけでなく、アドレスを最後まで照合します。セキュリティ警告が出ないこと、要求が型付きデータであること、主要型が見慣れていることは安全の保証になりません。 ## SIWEはログイン用でもドメイン・ノンスを確認する SIWE（Sign-In with Ethereum）はERC-4361のメッセージをERC-191形式で署名し、サーバーが検証してウェブ認証へ使う規則です。トークンの利用許可そのものではありませんが、成功後に作られるセッションが何を操作できるかはアプリケーションの認可設計に依存します。 最低限、次を同じログイン要求へ対応させます。 - ブラウザーオリジン、メッセージ先頭のドメイン、`URI` - アカウント、チェーンID - サーバーが今回だけ発行したノンス - `Issued At`、`Expiration Time`、必要なら`Not Before` - `statement`とリソースがログイン以外の同意を混ぜていないか MetaMask公式文書はSIWEを専用UIへ解析し、要求中サイトとメッセージドメインが違う場合に警告する例を掲載しています。ただし利用者が明示的に上書きできるため、警告機能だけに任せず、自分でドメインとURLを照合します。サーバー側のノンス消費、セッション、CSRF対策は[SIWEをノンスからセッションまで安全に実装する記事](/archives/6019)で分けています。
MetaMask公式サンプルのSIWE署名画面。要求元、アカウント、URL、ネットワーク、バージョン、チェーンID、ノンス、発行時刻の位置を示す
MetaMask公式SIWE文書のサンプルUI。要求元（Request from）、アカウント（Account）、URL、ネットワーク（Network）、バージョン（Version）、チェーンID（Chain ID）、ノンス（Nonce）、発行時刻（Issued）を表示しています。2026-08-31確認、文書は2026-08-04更新。個人アカウントや実在セッションではなく、この記事でウォレット接続・署名・ログインは行っていません。
## PermitとPermit2はガスなしでトークン権限になり得る ERC-2612 PermitはEIP-712を使い、`owner`、`spender`、`value`、`nonce`、`deadline`へ署名します。署名者がトランザクションガスを払わなくても、仕様上は任意の呼び出し元が有効な署名をトークンコントラクトへ提出でき、利用許可額とノンスが更新されます。 署名前にトークンコントラクト、チェーンID、所有者、利用先、値、ノンス、有効期限を読みます。トークン名やシンボルは重複できるため、`verifyingContract`のアドレスを公式デプロイと照合してください。 Permit2ではさらに層を分けます。 1. トークンコントラクトからPermit2コントラクトへのERC-20利用許可 2. Permit2内で特定利用先へ与える後段権限、または1回のSignatureTransfer AllowanceTransferでは数量、失効時刻、順序付きノンス、利用先、`sigDeadline`を分けます。SignatureTransferは永続な後段利用許可額を残さない方式ですが、受取先、要求済み数量、順不同ノンス、有効期限、証明データなどのメッセージ内容を確認する必要があります。「Permit2だから一度だけの利用」「署名1回だから無制限ではない」と決めつけません。 通常のERC-20利用許可を確認する入口は[トークンの利用許可を安全に確認する記事](/archives/6007)、Permit / Permit2の状態保存先と期限は[4方式のトークン権限を比較する記事](/archives/6012)に分けています。 ## EIP-7702委任は型付きデータとは別に読む EIP-7702の認可タプルは、`chain_id`、委任先の`address`、認可者EOAの`nonce`と署名を含みます。署名対象ハッシュは`0x05 || rlp([chain_id, address, nonce])`から作られ、EIP-712型付きデータではありません。有効な認可がtype 0x04トランザクションで処理されると、認可者EOAのコードへ委任指標が設定されます。 確認項目は次のとおりです。 - 認可者が意図したEOAか - `chain_id`が対象チェーンか。`0`なら複数チェーンへ適用できる範囲を理解したか - 委任先アドレスの現在コード、検証済みソース、プロキシ / 更新権限 - 認可者EOAのノンスと、外側トランザクションの送信者・呼び出し内容 - 委任先が実行できる呼び出し、セッション鍵、モジュール、利用許可額の範囲 委任を後から解除しても、EOAストレージ、ERC-20利用許可額、外部登録簿、セッション状態まで同時に消えるわけではありません。設定・差し替え・解除後の残存状態は[EIP-7702委任ライフサイクルの記事](/archives/6017)で確認してください。 ## ウォレット画面に見えても、見えなくても確認する 2026-08-31にMetaMask公式文書のサンプルを確認した範囲では、型付きデータ画面にネットワーク（Network）、要求元（Request from）、操作先（Interacting with）、主要な型（Primary type）、メッセージ（Message）、SIWE画面にURL、チェーンID（Chain ID）、ノンス（Nonce）、発行時刻（Issued）などが表示されます。本文では、この公式画面と現行文書の表示だけを確認根拠にしています。 これはMetaMaskの公式サンプル表示を確認した証拠であり、すべてのウォレット、バージョン、ロケール、アカウント型、Snap、セキュリティ設定で同じ表示になる証拠ではありません。また、画面だけでは次を証明できません。 - ブラウザー拡張機能自体や要求元サイトが改ざんされていないこと - 検証コントラクトや委任先コードが安全で、将来更新されないこと - ノンスが未使用で、アプリケーションが正しく消費すること - 利用先が署名後にどのトランザクションを提出するか - SIWEサーバーが適切なセッションと認可を発行すること ウォレットの表示を第一の停止点にしつつ、コントラクトアドレス、公式デプロイ、コード、アプリケーションの効果まで別に確認します。 署名鍵を電話・PCから分離する場合も、ハードウェアウォレットという分類だけで安全と決めません。[EVM向けハードウェアウォレット5機種の選び方](/archives/6034)で、端末上の表示項目、USB・Bluetooth・QR、バックアップ、ファームウェア、ソース公開範囲を先に比較し、購入後は受取・送金・`approve`・EIP-712の共通検証手順で確認してください。 ## 署名後に不安になったときの順番 ### 1. 署名を公開せず、要求情報を保存する オリジン、時刻、ウォレット / バージョン、方法、アカウント、チェーンID、メッセージまたは型付きデータJSON、コントラクト、利用先 / 委任先、数量、ノンス、有効期限、画面記録を保存します。未加工署名そのものは、第三者が提出できる可能性があるためSNSや公開の問い合わせ欄へ貼りません。 ### 2. 方法ごとに残る状態を確認する | 署名 | 確認先 | 停止・失効の考え方 | | --- | --- | --- | | SIWE / ログイン | アプリケーションの有効セッション、ログイン履歴 | 公式サイトからログアウト・全セッション失効。元署名を一般に「取り消し」できるとは限らない | | 注文 / 型付き操作 | アプリケーションと検証コントラクトのノンス・取り消し機能 | プロトコル固有の取り消しまたはノンス無効化を一次情報で確認 | | ERC-2612 Permit | トークン利用許可額、ノンス、有効期限 | 提出済みなら利用許可額を取り消し / 置換。未提出署名の失効方法はトークン実装ごとに確認 | | Permit2 | トークン→Permit2利用許可額とPermit2後段状態 | 2層を別々に確認し、公式手順で取り消し / ノンス無効化を行う | | EIP-7702 | アカウントコード、委任先、ストレージ、利用許可額、セッション / モジュール | 委任の置換 / 解除だけで終わらせず、残存状態を保存先ごとに停止 | 切断はウェブサイトからアカウント接続を外す操作で、チェーン上利用許可額、提出可能なPermit、委任、サーバー側セッションを一括削除しません。 接続権限、SIWEセッション、ERC-20 / Permit2、セッション鍵 / モジュール、EIP-7702委任を保存場所・確認方法・失効トランザクションへ分ける手順は、[DAppを切断しても残る権限の確認ガイド](/archives/6031)にまとめています。 Safeの提案へ署名した場合は、ウォレット確認画面の確認に加えて、その署名がどのSafeトランザクションハッシュとSafeノンスへ対応するかを保存します。[Safeの取引が進まない時の確認手順](/archives/6030)で、チェーン外の承認数、2-of-3の必要署名数、同一ノンスの競合、別のEthereum実行トランザクションを分けて確認できます。 ### 3. チェーン上の状態更新と公式のインシデント情報を確認する 自分で開いたブロックエクスプローラーでアドレス、トークン利用許可額、トランザクション、イベントを確認します。ウォレットやプロトコルの公式セキュリティ窓口にインシデント情報があるかを、ブックマークまたは公式サイトからたどります。検索結果の電話番号、DMを送ってくるサポート、遠隔操作アプリ、シードフレーズの入力案内は使いません。 ### 4. 秘密情報を渡さない 署名の取消、ウォレット同期、資産保護、本人確認を理由にしても、シードフレーズ、秘密鍵、キーストアパスワードを入力・送信しません。すでに入力した場合は、単なる署名問題ではなくウォレット侵害として、信頼できる別端末・別ウォレットを含む緊急対応へ切り替えます。 不審なトランザクションが既にある、秘密情報入力や端末侵害も疑われる、利用許可・セッション・委任のどれを先に確認すべきか分からない場合は、追加操作の前に[ウォレット侵害時の証拠保存と7層初動ガイド](/archives/6026)へ進んでください。 ## 最終チェックリスト - [ ] 署名、トランザクション、利用許可のどれを見ているか分けた - [ ] 方法と目的を要求側で確認した - [ ] ブラウザーオリジン、ウォレットの`Request from`、署名済みドメイン / URIを照合した - [ ] アカウントとチェーンIDが意図どおりだった - [ ] 検証コントラクト、トークン、Permit2、利用先、委任先をアドレスで照合した - [ ] 数量、トークン小数桁、上限、受取先 / 証明データを確認した - [ ] ノンス、有効期限、権限失効時刻、使用済み状態の役割を分けた - [ ] 署名後のセッション、利用許可額、注文、委任という状態更新を説明できた - [ ] 一つでも不明なら署名せず、自分で開いた公式サイトへ戻った - [ ] シードフレーズ・秘密鍵・未加工署名をサポートや公開投稿へ渡していない ウォレット署名の安全確認は、**方法、オリジン / ドメイン、アカウント、チェーン、コントラクト、利用先 / 委任先、数量、ノンス、有効期限、後続状態更新を同じ要求へ対応させ、一つでも説明できなければ署名しないこと**です。 この記事にはウォレットインストール、交換、取引所、署名、利用許可を促すアフィリエイト販売誘導を置いていません。形式や製品の推奨ではなく、署名を止めて確認する順序を提供しています。 ## 確認した一次情報 - [ERC-191 Signed Data Standard](): 確認日 2026-08-31 - [EIP-712 Typed structured data hashing and signing](): 確認日 2026-08-31 - [ERC-4361 Sign-In with Ethereum](): 確認日 2026-08-31 - [ERC-2612 Permit](): 確認日 2026-08-31 - [EIP-7702 Set EOA account code](): 確認日 2026-08-31 - [MetaMask Sign data guide](): 確認日 2026-08-31 - [MetaMask Sign in with Ethereum guide](): 確認日 2026-08-31 - [MetaMask MIP-3 eth\_sign deprecation](): 確認日 2026-08-31 - [MetaMask signature phishing guidance](): 確認日 2026-08-31 - [Ethereum JSON-RPC eth\_sign documentation](): 確認日 2026-08-31 - [Uniswap Permit2 source](): 確認日 2026-08-31 - [MetaMask extension v13.46.0](): 確認日 2026-08-31 --- # ウォレットが侵害されたかも？シード・権限・セッション・委任を切り分ける初動 不審なウォレット操作を見つけた直後に追加操作を止め、証拠を保存し、シード・秘密鍵、利用許可、Permit、セッション、EIP-7702委任、端末侵害を切り分ける初動ガイドです。 正規URL: https://3mikan.com/archives/6026 著者: みかん 公開: 2026-08-31T03:30:00.000Z 更新: 2026-09-02T05:35:00.000Z 「ウォレットが侵害された」と感じても、最初に原因を一つへ決めないでください。**追加の署名・送金・接続を止め、秘密を含まない証拠を保存し、シード / 秘密鍵、トークン権限、署名、セッション、委任、端末のどこが疑われるかを分ける**のが初動です。 接続を切るだけでは、チェーン上の利用許可は消えません。利用許可を取り消しても、漏れたシードフレーズや秘密鍵は安全な状態に戻りません。この記事は回収手順ではなく、追加被害と二次詐欺を避けながら、公式サポートやセキュリティ担当者へ渡せる情報を整理するための読み取り専用ガイドです。 実被害ウォレット、個人アカウント、実資産、シードフレーズ、秘密鍵、未加工署名は検証に使っていません。ウォレット接続、署名、トランザクション、取り消し、資産移動も行っていません。 ## 最初に止める7つの行動 原因が分からない間は、次の操作を止めます。 1. 突然開いた署名、トランザクション、利用許可を確定しない 2. DM、検索広告、返信欄から届いたリンクを開かない 3. 「確認」「同期」「取り消し」「復旧」のためにシードフレーズや秘密鍵を入力しない 4. 未加工の署名、パスワード、2FAバックアップコード、本人確認書類を公開掲示板やSNSへ貼らない 5. 見知らぬ相手へ画面共有や遠隔操作ツールの導入を許可しない 6. 「回収用ガス」「解除料」「保証金」という先払いをしない 7. 資金を自動で抜くスイーパーの疑いがあるアカウントへ、自己判断で追加ガスを送らない MetaMaskの公式サポートは未依頼のDMをせず、電話サポートを提供せず、Secret Recovery Phraseを要求しないと案内しています。連絡先はDMのプロフィールや検索結果ではなく、自分で開いたウォレット・サービスの公式サイトから確認してください。 ## 秘密を含めず、事実を固定する ブラウザーやウォレットの表示を操作する前に、次を保存します。URLは履歴から文字列を控え、不審サイトを確認のために開き直しません。 | 保存する項目 | 例 | 公開共有の境界 | | --- | --- | --- | | 公開アドレス | `0x…`、スマートアカウントのアドレス | 公開チェーン上の値。ただし本人との関係は必要な相手にだけ共有 | | チェーン | チェーン名とチェーンID | 名前だけでなくチェーンIDを保存 | | トランザクション | トランザクションハッシュ、状態、ブロック、日時とタイムゾーン | ブロックエクスプローラーのURLよりハッシュを優先。未確定・失敗・成功を分ける | | 関係アドレス | `from`、`to`、受取先、利用先、委任先、トークンコントラクト | 役割を決めつけず、アドレスと見えた項目を保存 | | 呼び出し / イベント | 関数セレクター、`transfer` / `transferFrom`、`Approval`イベント、入力データ | 解析結果と未加工入力を分ける。未加工の**署名**は保存先を限定し公開しない | | 権限状態 | 利用許可額、アカウントコード、所有者 / 必要署名数、モジュール、セッション有効期限 | チェーン、ブロック、確認時刻を一緒に残す | | ローカル環境 | ウォレット / 拡張機能、ブラウザー、OS、アプリのバージョン | 拡張機能の入手元、更新日時、見覚えのない変更も記録 | | 接触履歴 | URL、DM送信者、公式サポートの問い合わせ番号、先払い要求 | 画面記録ではシード、キー、パスワード、個人情報を隠す | シードフレーズと秘密鍵は「証拠」としてサポートへ送らないでください。画面共有で見せる、写真を添付する、クラウドメモへ置くことも避けます。ethereum.orgは、復旧フレーズからウォレット内のアカウントへアクセスでき、秘密鍵で対応アカウントを操作できると説明しています。正規のサポートが要求する情報ではありません。 見覚えのないトランザクションではなく、自分の送信先やネットワーク選択を誤った可能性がある場合は、侵害と決めつけません。[誤ネットワーク・誤アドレスをトランザクション状態から確認するガイド](/archives/6009)で、ネットワークへの送信前、保留中、確定済みの失敗、確定済みの成功を先に分けます。
追加操作を止め、証拠を保存してから7つの権限・端末層へ分ける初動確認を、3MIKANのキャラクターと7区画の保管棚で示した図
## 7つの候補層を同じ表で分ける 一つのインシデントに複数の層が同時に関係する場合があります。この表は診断ではなく、追加の確認先を決めるための入口です。 | 候補層 | 保存する信号 | 最初の境界 | その信号だけでは分からないこと | | --- | --- | --- | --- | | シード / 秘密鍵 | 自分が作っていない直接トランザクション、複数アカウント / チェーンの動き、秘密情報入力・ファイル保存・遠隔操作の履歴 | 署名権限そのものを疑い、疑わしい端末で新しい秘密を作らない | 未認可トランザクション一件だけでは漏えい経路を確定できない | | ERC-20利用許可 | `transferFrom`、所有者、利用先、トークン、利用許可額、Approvalイベント | DApp接続とチェーン上利用許可額を別に見る | 切断（Disconnect）しても利用許可額が消えた証拠にはならない | | Permit / Permit2 | 型付きデータの要求、所有者、利用先、値、ノンス、有効期限、Permit2コントラクト | 未提出の署名はチェーンに見えない場合がある。未加工の署名を公開しない | 全トークンに共通する取り消し方法はなく、トークン / プロトコルのノンス実装を確認する必要がある | | DApp / WalletConnectセッション | オリジン、アカウント、チェーン、方法、セッショントピック、有効期限 | セッション終了とチェーン上権限を分ける | 切断（Disconnect）は利用許可、Permit、委任の解消を証明しない | | EIP-7702委任 | アカウントコード、委任先、認可トランザクション、チェーンID、ノンス | 委任先コードと利用許可額 / ストレージ / セッションを別に見る | コード解除だけで他状態が消えたとは言えない | | スマートアカウント権限 | 所有者、必要署名数、モジュール、ガード、フォールバックハンドラー、セッション鍵 | ウォレット固有の権限構成として確認 | トークンの利用許可一覧だけではモジュール権限を確認できない | | 端末 / ブラウザー | 拡張機能の入手元・バージョン、OS / ブラウザー更新、遠隔操作、クリップボード異常、メール / SIM警告 | チェーン外の認証・端末インシデントとして分ける | ブラウザー変更だけでは既存権限の封じ込めを証明できない | ## シードフレーズ・秘密鍵侵害の候補 自分が作っていないネイティブ資産の送金やコントラクト呼び出しが、アカウント自身を`from`として成立している場合は、シード / 秘密鍵、悪意のある署名、端末上のウォレット操作、自動処理などを候補にします。複数アカウントや複数チェーンで近い時刻に動きがあっても、それだけで漏えい経路までは確定できません。 秘密情報を偽サイトへ入力した、写真・クラウド同期・平文ファイルへ保存した、偽拡張機能を導入した、第三者へ遠隔操作を許可した、という事実があれば、その時刻と端末を公式サポートやセキュリティ担当者へ伝えます。秘密そのものは渡しません。 MetaMaskの侵害時ガイドは、別のブラウザー / プロフィール / 端末で新しいウォレットを用意し、残る資産を移して被害を限定する方法を案内しています。一方で、スイーパーが疑われるアカウントへガスを追加しないよう注意しています。これは時間、端末、資産、アカウント設計で結果が変わる、MetaMask固有の案内です。**本記事だけを根拠に一律の移動手順を実行せず、公式サポートまたは信頼できるセキュリティ担当者へ緊急性を伝えて個別に判断してください。** 既に確定済みになったチェーントランザクションをウォレットプロバイダーが取り消したり、失われた資産を必ず復元したりすることはできません。新しいウォレットを作ることも、古い権限、トークンの利用許可、委任、DAppセッションが自動で消えた証拠にはなりません。 ## ERC-20利用許可とPermitを分ける ERC-20の`allowance(owner, spender)`は、所有者に代わって利用先が使える残量です。`transferFrom`が見える場合は、トークンコントラクト、所有者、利用先、数量、直前のApprovalイベントと利用許可額を同じチェーン・ブロックへ対応させます。 サイトから切断（Disconnect）する操作は、通常はアドレス共有やDApp接続の境界です。チェーン上利用許可額を変更する取り消しとは別です。さらに取り消しはトランザクションであり、特定利用先の利用許可額を変えるだけなので、漏れたシードフレーズや秘密鍵を安全なものへ戻しません。 利用許可の確認項目は[MetaMaskのトークンの利用許可を安全に確認するガイド](/archives/6007)へ分けています。 ERC-2612 Permitは`owner`、`spender`、`value`、`nonce`、`deadline`へ署名し、仕様上は第三者が提出できます。署名がまだ提出されていなければ、チェーン上のトランザクションや利用許可額だけでは見つからない場合があります。ERC-2612は全トークン共通の「未提出署名を取り消す」操作を定義していないため、トークンコントラクト、ノンス、有効期限、使用済み状態を個別に確認します。 Permit2では、トークンコントラクトからPermit2への利用許可と、Permit2内のAllowanceTransferまたはSignatureTransferを別の層として保存します。「一回の署名」「ガスなし」という表示だけで権限が小さいとは判断しません。署名要求の項目と、未加工署名を公開しない理由は[ウォレット署名要求の見分け方](/archives/6025)で確認できます。 ## DAppセッションはチェーン上権限ではない WalletConnectのセッションは、トピックに対応するチェーン、方法、イベント、アカウントを含み、切断または有効期限までDAppとウォレットの通信を結びます。セッションを終了すればその接続経路は止められますが、トークン利用許可額、提出済みPermit、EIP-7702委任、アプリケーション側ログインセッションまで消えた証拠にはなりません。 保存するのは、DAppオリジン、セッショントピック、アカウント、チェーン、許可方法、作成・更新・有効期限時刻です。セッション制御を操作する場合も、検索結果やDMのツールではなく、使用しているウォレットまたはDAppの公式画面・文書へ自分で戻ります。 ## EIP-7702委任とスマートアカウント権限 EIP-7702ではEOAコードが`0xef0100 || address`という委任指標を持ち、委任先コードを実行入口にできます。不審な操作履歴では、対象アカウントのコード、委任先アドレス、認可を含むトランザクション、チェーンID、認可者EOAのノンスを保存します。 委任を解除したように見えても、コントラクトストレージ、ERC-20利用許可額、Permit2権限、DAppセッションが消えたとは限りません。委任先がプロキシなら、コードの役割が将来変わる可能性もあります。読み取り専用で確認する状態と残存境界は[EIP-7702委任ライフサイクルガイド](/archives/6017)へ分けています。 Safeのようなスマートアカウントでは、所有者と必要署名数、モジュール、ガード、フォールバックハンドラー、セッション鍵が別の権限層になり得ます。Safe公式文書は、モジュールが通常の所有者確認とは別の実行経路を提供し、悪意のあるモジュールがSafeを乗っ取り得ると注意しています。トークンの利用許可だけを見て「権限は全部正常」と判断せず、ウォレット固有の公式文書とセキュリティ担当者へ構成のスナップショットを渡してください。 ## 端末・ブラウザー・メール・SIMをチェーン外の層として扱う 見覚えのない拡張機能、非公式ストアからのインストール、クリップボードのアドレス差し替え、遠隔操作ツール、OS / ブラウザーの不自然な変更、メールやSIMのセキュリティ警告は、チェーン外の原因候補です。端末の電源断や初期化を一律に勧めると証拠を失う場合があるため、時刻、バージョン、入手元、警告、接触履歴を先に記録します。 不審なトランザクションはなく、送金履歴の似たアドレス、ゼロ値送金、同じシンボルのトークン行、コピー元と貼り付け後の不一致を見つけた段階なら、[アドレスポイズニングの送金前確認手順](/archives/6056)で履歴、コントラクト、イベント、端末の境界を先に分けます。 疑わしい端末で新しいシードフレーズ、パスワード、2FAバックアップコードを作成・表示しません。別環境を使う必要がある場合も、「別だから安全」と自己判定せず、ウォレットプロバイダー、端末 / OS提供元、組織のセキュリティ担当者など、対象に合う公式窓口の案内に従います。 インシデント対応が終わった後に平時のアカウントログインを見直す場合は、[物理セキュリティキーのFIDO2・NFC・復旧設計](/archives/6069)で、普段使うキーと予備キーの別登録、復旧コード、失ったキーの削除を確認してください。購入や登録を緊急対応の途中へ混ぜず、既存セッションや権限の確認とは別工程にします。 ## 公式窓口へ渡す証拠パッケージ 問い合わせは、目的ごとに分けます。 | 窓口 | 渡す情報 | 期待してはいけないこと | | --- | --- | --- | | ウォレット / DApp公式サポート | 公開アドレス、チェーン、トランザクションハッシュ、時刻、オリジン、ウォレット / アプリのバージョン、表示された要求 | チェーントランザクションの取り消し、確実な回収、シード / キーの受領 | | カストディ型取引所 / サービス | 入金 / 出金ID、チェーン、トランザクションハッシュ、送信先、アカウント内の時刻、公式の問い合わせ番号 | 即時凍結、返金、相手情報の開示を保証しない | | セキュリティ担当者 | インシデントの時系列、権限のスナップショット、端末 / 拡張機能の情報、公開チェーンの証拠 | 証拠のない断定、救済を保証する勧誘、秘密情報の提出 | | 警察相談 | 被害・接触の時系列、トランザクション / 支払い証拠、DM / URL、相手の要求、添付可能な資料 | 凍結、追跡、逮捕、返金、解決時期を保証しない | 日本では警察庁のサイバー事案相談窓口から、都道府県警察を選び、相談・通報・情報提供とファイル添付へ進めます。これは相談経路の案内であり、資産の凍結、返金、回収、捜査結果を約束するものではありません。緊急性や身の安全に関わる場合は、該当する公的緊急窓口を使ってください。 > **二次詐欺の危険信号** > > 依頼していないDM、シード / 秘密鍵の要求、遠隔操作ツール、画面共有、先払い、成功報酬を装う追加ガス、「必ず回収できる」という断定、公式に似せたドメインは、対応を止める条件です。相手が「急がないと消える」と言っても、秘密や資産を渡さず、公式サイトから別経路で確認します。 ## 最終確認項目 - 追加署名、未知サイト、DM、遠隔操作、先払いを止めた - 公開アドレス、チェーンID、トランザクションハッシュ、時刻とタイムゾーン、関係アドレスを保存した - シードフレーズ、秘密鍵、未加工署名、パスワード、2FAコードを公開・送信していない - 直接トランザクションと`transferFrom`、利用許可とPermit、セッションとチェーン上権限を分けた - アカウントコード、委任先、スマートアカウントの所有者 / モジュールを利用許可一覧と分けた - 端末 / ブラウザー / メール / SIMの信号をチェーン上の証拠と分けた - 公式サイトから目的に合うサポートへ入り、問い合わせ番号を保存した - 回収、凍結、返金、追跡、解決時期を保証する相手を信用していない この確認項目を終えても「安全になった」とは断定できません。どの権限層が疑われ、何が未確認かを明示して、セキュリティレビュー担当者へ引き継ぐところまでが初動です。 ## 確認した一次情報 - [MetaMask: compromised wallet and unauthorized transactions](): 確認日 2026-08-31 - [MetaMask official support channels](): 確認日 2026-08-31 - [MetaMask revoke token allowances guidance](): 確認日 2026-08-31 - [Ethereum security and scam prevention](): 確認日 2026-08-31 - [ERC-20 Token Standard](): 確認日 2026-08-31 - [ERC-2612 Permit](): 確認日 2026-08-31 - [Uniswap Permit2 source](): 確認日 2026-08-31 - [WalletConnect Wallet SDK session usage](): 確認日 2026-08-31 - [EIP-7702 Set EOA account code](): 確認日 2026-08-31 - [Safe smart account overview](): 確認日 2026-08-31 - [Safe smart account modules](): 確認日 2026-08-31 - [警察庁 サイバー事案に関する相談窓口](): 確認日 2026-08-31 --- # ブリッジ送金が保留・失敗・未着金のときの確認順｜送信元・メッセージ・送信先 ブリッジ送金が保留、失敗、未着金のとき、送信元トランザクション、チェーン間メッセージ、プロトコルの段階、送信先トランザクション、トークンの対応関係を分けて確認します。 正規URL: https://3mikan.com/archives/6027 著者: みかん 公開: 2026-08-30T21:45:00.000Z 更新: 2026-09-02T05:35:00.000Z ブリッジ画面が`pending`のまま、ソースチェーンのトランザクションは`success`なのに送信先へ反映されない。このとき、**同じ送金を繰り返したり、検索広告やDMのサポートを開いたりする前に、送信元トランザクション、チェーン間メッセージ、プロトコル段階、送信先トランザクションまたは受取、トークン対応表を分けて確認します**。 ソース側の`success`は、そのチェーン上の呼び出しが成功した証拠です。送信先側で同じメッセージが実行され、意図したトークンコントラクトへ到達した証拠ではありません。 この記事は公開テストネットの実行結果とログを読み取り専用で照合します。ウォレット接続、署名、受取、再試行、`approve`、ブリッジ送信、メインネット資産操作は行いません。 ## 先に止めること、保存すること 原因が分かるまでは、次の操作を止めます。 - 同じ経路・数量の再送 - `pending`を消すためだけの優先処理、取り消し、受取、`redeem` - 検索広告、SNS返信、DMから開く「復旧」「ブリッジサポート」 - シードフレーズ、秘密鍵、キーストアの共有や遠隔操作アプリの導入 - 送信先に見えないトークンを別ブリッジへ送り直す操作 代わりに、次の項目を一つの調査メモへ保存してください。 | 層 | 保存する値 | 理由 | | --- | --- | --- | | 経路 | 利用した公式URL、ブリッジ名、正規 / 第三者 | 同じ名前でも状態モデルが違うため | | 方向 | ソースチェーン → 送信先チェーン、入金 / 出金 | 往路と復路で段階が違うため | | 資産 | シンボル、数量、ソーストークンコントラクト、想定送信先トークンコントラクト | シンボルだけでは表現を区別できないため | | ソース | トランザクションハッシュ、ブロック、実行結果の状態、ブリッジコントラクト、イベント | ソース呼び出しとメッセージ作成を分けるため | | メッセージ | `sourceHash`、出金ハッシュ、再試行可能チケットID、位置、プロバイダーの注文IDなど | チェーン間の同じ1件を結ぶため | | プロトコル | リレー、証明、チャレンジ、確認、実行可能などの公式状態 | 時間だけで停止箇所を決めないため | | 送信先 | トランザクションハッシュ、実行結果の状態、イベント、受取 / 実行状態 | 到着処理が実行されたか確認するため | | 表示 | ウォレット / ブリッジUIの表示、確認時刻、ブラウザー・アプリバージョン | チェーン状態との表示遅延を分けるため | トランザクションハッシュやアドレスは省略せずコピーし、チェーンIDと確認時刻も添えます。公開のサポート窓口へ出す場合は、個人情報、残高全体、メール、IPアドレス、非公開の注文情報を必要な範囲まで隠します。シードフレーズと秘密鍵は、サポートの本人確認にも使いません。 ブリッジ送金を送信元トランザクション、メッセージ識別子、プロトコル段階、送信先トランザクションまたは受取、トークン対応表へ分ける流れ ## 送信元トランザクションの成功は最初の確認地点 EVMの`eth_getTransactionReceipt`は、実行結果がまだなければ`null`、取り込まれた後は`status`とログを返します。まずソースチェーンの正しいRPCまたはブロックエクスプローラーでトランザクションハッシュを確認します。 | ソースの証拠 | 読めること | まだ読めないこと | | --- | --- | --- | | 実行結果が`null` | 未採用、破棄 / 置換済み、またはRPC遅延の候補 | チェーン間メッセージが確定したとは言えない | | `status = 0` | ソース呼び出しが`revert`した | 正常なソースイベントや送信先実行が成立したとは言えない | | `status = 1`、対象イベントなし | 呼び出しは成功したが、想定したブリッジ経路か再確認が必要 | メッセージIDと送信先実行 | | `status = 1`、対象イベントあり | ソース呼び出しとメッセージ作成の証拠を取得できる | リレー、証明、送信先実行結果、トークン表示 | 実行結果がないときのノンス、置換、破棄トランザクションの切り分けは[トランザクションが保留中のときの確認順](/archives/6004)で先に確認できます。送信元側を飛ばしてブリッジの待ち時間だけを調べると、そもそも別チェーン、別ハッシュ、`reverted`の呼び出しを待ち続けることがあります。 ## メッセージ識別子で同じ送金をチェーン間につなぐ チェーン間メッセージは、送信元トランザクションから送信先実行へ渡す指示です。ただし、すべてのブリッジが`message hash`という同じ名前・計算式を使うわけではありません。 - OP Stack入金: L1ブロックハッシュと`TransactionDeposited`のログ索引から作る`sourceHash` - OP Stack出金: 出金トランザクション / メッセージを識別するハッシュと証明対象 - Arbitrum親チェーンから子チェーン: 再試行可能チケットを追跡する識別子 - Arbitrum子チェーンから親チェーン: `L2ToL1Tx`の`position`とOutbox実行 - 第三者流動性ブリッジ: プロバイダーの注文ID、入金イベント、リレイヤー / 流動性精算の組み合わせ ブリッジUIに短いIDしか出ない場合でも、ソースイベント、公式ブロックエクスプローラー、公式SDK・状態APIがどの値を対応させるかを一次情報で確認します。別のブリッジ向けのハッシュ計算機へトランザクションハッシュを貼っても、同じメッセージを追跡できるとは限りません。 ## 正規ブリッジと第三者ブリッジを分ける 正規ロールアップブリッジは、ロールアッププロトコルの入金 / 出金メッセージを通して資産表現を発行・焼却・ロック・解放します。一方、第三者流動性ブリッジは送信先側のプールから先に支払い、後でリレイヤーや別経路がリバランスする方式があります。 | 比較 | 正規ブリッジ | 第三者流動性ブリッジ | | --- | --- | --- | | 主な識別子 | プロトコルメッセージ、出金、再試行可能チケット、位置 | 注文ID、入金イベント、プロバイダーのメッセージ | | 送信先処理 | ロールアップメッセンジャー / ゲートウェイ / Outbox | リレイヤー、流動性プール、プロバイダーのコントラクト | | 待ち状態 | プロトコルの証明・承認数・実行 | リレイヤー、流動性、見積もり有効期限、プロバイダーの精算もあり得る | | 問い合わせ先 | ロールアップ / ブリッジの公式状態とサポート | 利用したプロバイダーの公式な注文状態とサポート | 第三者ブリッジのソーストランザクションを、正規ブリッジの公式UIへ入れても追跡できない場合があります。逆に、プロバイダー画面の`completed`だけで正規送信先実行結果やトークンコントラクトを確認したことにもなりません。利用したURLとソースコントラクトを最初に固定してください。 ## OP Stackは入金と出金で段階が違う OP Stack Standard Bridgeでは、両チェーンのトークン表現を`localToken`と`remoteToken`の組として扱います。送信元トランザクションの成功、ドメイン横断メッセージ、送信先側の確定、トークン対応表を分けて読みます。 ### EthereumからOP Stackへの入金 典型的なL1 → L2入金では、L1のOptimismPortalが`TransactionDeposited`イベントを出し、そのL1ブロックハッシュとログ索引から`user-deposit`ドメインの`sourceHash`を作ります。L2側ではtype 0x7eの入金トランザクションに同じ`sourceHash`が入ります。 ```text depositId = keccak256(l1BlockHash || bytes32(l1LogIndex)) sourceHash = keccak256(bytes32(uint256(0)) || depositId) ``` この対応が見つかって初めて、ソースイベントとL2トランザクションを同じ入金として結べます。L1実行結果の`status = 1`だけでは、L2実行結果の`status`を確認したことになりません。 ### OP StackからEthereumへの出金 L2 → L1出金は入金の逆再生ではありません。出金をL2で開始し、L1側で出力・証明条件を満たし、チャレンジ期間など経路の条件を経て確定します。`initiated`、`ready to prove`、`proven`、`ready to finalize`、`finalized`は同じ状態ではありません。 所要時間を「必ず7日」のような一つの数字へ固定しないでください。ネットワーク、障害証明構成、対象出力、証明 / 確定の実行状況で変わります。選んだチェーンと経路の公式状態を、同じ出金識別子で確認します。 OP StackとArbitrumの正規L2→L1を、実際の出金ハッシュ、異議申立てゲーム、アサーション、Outbox実行結果まで追う手順は[L2出金の証明・確定・受取確認手順](/archives/6028)で分けて解説しています。 ## Arbitrumは再試行可能とOutbox出金を分ける Arbitrumの親チェーンから子チェーンメッセージは再試行可能チケットとして追跡します。ソースL1トランザクション、チケット作成、自動受取または再試行可能な状態、L2実行結果を分けます。ソースL1実行結果の成功だけで、チケットがL2で`redeem`済みとは言えません。 子チェーンから親チェーン出金では、ArbSysの`L2ToL1Tx`イベントに固有の`position`が記録されます。その後、バッチ / アサーションと承認数を経て受取可能になり、Outboxで実行されると`OutBoxTransactionExecuted`のトランザクション索引へ同じ位置が現れます。 公式監視資料の状態は、概ね次の境界を持ちます。 | 状態 | 意味 | 読者が確認する証拠 | | --- | --- | --- | | `UNCONFIRMED` | アサーションの承認数条件を満たしていない | L2イベント、位置、対象アサーション | | `CONFIRMED` | プロトコル上は実行可能 | 公式経路、Outbox、未実行であること | | `EXECUTED` | Outboxトランザクションが実行済み | L1実行結果と`OutBoxTransactionExecuted` | `CONFIRMED`は`EXECUTED`と同じではありません。手動受取が必要か、自動実行されるかは利用した経路に依存します。この記事は受取操作を実行せず、公式状態が実行可能と示す地点までを読み取り専用で確認します。 ### OP StackとArbitrumの語を置き換えない | 方向 | OP Stackで見る主な段階 | Arbitrumで見る主な段階 | | --- | --- | --- | | 親 → 子 | `TransactionDeposited` → `sourceHash` → L2入金済みトランザクション | L1メッセージ → 再試行可能チケット → L2 `redeem` / 実行 | | 子 → 親 | 開始 → 証明 → チャレンジ条件 → 確定 | `L2ToL1Tx.position` → アサーション確認 → Outbox実行 | どちらにも`pending`や`claim`という画面上の表記はありますが、内部の証拠は同一ではありません。ほかのL1 / L2、サイドチェーン、ライトクライアントブリッジ、MPCブリッジでは、さらに別の状態遷移を使います。 ## 公開テストネットでソース・メッセージ・送信先を照合する 2026-08-31に、実資産や個人ウォレットを使わず、公開RPCから2つの完了済みテストネット例を固定しました。[検証用JSON](/fixtures/bridge-lifecycle-6027.json)にはチェーンID、トランザクションハッシュ、ブロックハッシュ、イベント識別子、タイムスタンプを収録しています。 ### OP Sepolia入金は`sourceHash`で一致する | 層 | 固定した証拠 | | --- | --- | | ソース | Ethereum Sepoliaブロック`11,600,446`、[トランザクション`0x5e1d…5f1b`](https://sepolia.etherscan.io/tx/0x5e1db4c8b84b8a201565f51d92edf24c5b5cd7e0aa4387c2cdeefbb245495f1b)、実行結果成功 | | ソースイベント | OP Sepolia Portalの`0x16fc…8bc`の`TransactionDeposited`、ログ索引`122` | | メッセージ | `sourceHash = 0x9b028f28…932f4f6b` | | 送信先 | OP Sepoliaブロック`48,155,271`、[タイプ0x7eのトランザクション`0x2700…454`](https://testnet-explorer.optimism.io/tx/0x270083ada19948a8fe0c54d607ac5ad83b2887f245a738a02fd78ba0ebe14454)、同じ`sourceHash`、実行結果成功 | | 観測時刻 | `2026-08-30 18:03:24 UTC` → `18:04:42 UTC`、78秒 | 78秒はこのテストネットトランザクション組の観測差であり、平均、SLA、次回の所要時間、メインネットの着金保証ではありません。重要なのは時間ではなく、L1イベントから再計算した`sourceHash`とL2トランザクションの`sourceHash`が一致したことです。 ### Arbitrum Sepolia出金は位置で一致する | 層 | 固定した証拠 | | --- | --- | | ソース | Arbitrum Sepoliaブロック`303,468,608`、[トランザクション`0x559f…ab13`](https://sepolia.arbiscan.io/tx/0x559f5a93a53f8e850c920f0653fcfe3ece22fef112bb69ef0056523d81a7ab13)、実行結果成功 | | メッセージ | `L2ToL1Tx.position = 117,694`、イベントハッシュ`0xcdd0…0f8b` | | 送信先 | Ethereum Sepoliaブロック`11,598,850`、[Outboxトランザクション`0x54cc…71e8`](https://sepolia.etherscan.io/tx/0x54cce03b6d3a4fd723f19ce7d70c802741aca1c6a9a6101b37da059ab71571e8)、実行結果成功 | | 実行イベント | `OutBoxTransactionExecuted.transactionIndex = 117,694` | | 観測時刻 | `2026-08-30 03:44:12 UTC` → `12:34:48 UTC`、8時間50分36秒 | この時間もArbitrumメインネットのチャレンジ期間や将来のテストネット実行頻度を示しません。OPの例は親チェーンから子チェーン入金、Arbitrumの例は子チェーンから親チェーン出金であり、速度比較にも使えません。2例は「ソーストランザクションと送信先トランザクションをプロトコル固有の識別子で結ぶ」方法だけを示します。 保存済み値と計算は、[検証用JSON](/fixtures/bridge-lifecycle-6027.json)を使ってオフラインで照合できます。現在の公開RPCと比較する場合は、`eth_chainId`、`eth_getTransactionReceipt`、`eth_getTransactionByHash`だけを読み取り専用で使います。トランザクション送信、ウォレット、APIキー、秘密情報は不要です。 ## 保留中・失敗・UI遅延・手動受取を分ける ソース実行結果、メッセージID、公式プロトコル状態、送信先実行結果から待機中、失敗、UI遅延、手動受取候補を切り分ける判断図 | 観測 | 分類 | 次に確認する読み取り専用証拠 | | --- | --- | --- | | ソース実行結果なし | ソース保留中 / 破棄 / 置換済み / RPC遅延 | ソースチェーン、ノンス、置換後のハッシュ、複数RPC | | ソースの`status = 0` | ソース失敗 | `revert`、入力、ガス、正しいブリッジコントラクト。正常なメッセージIDを待たない | | ソース成功、対象イベントなし | 経路 / 呼び出し不一致 | 呼び出されたコントラクト、イベントトピック、入金 / 出金方向 | | メッセージIDあり、送信先トランザクションなし | プロトコル待機中 / リレイヤー待機中 | 公式状態、証明 / アサーション / 再試行可能チケット / リレイヤーの状態 | | 公式状態が実行可能 | 手動実行候補 | 利用経路が受取必須か、公式URL・チェーン・ID・未実行状態 | | 送信先実行結果の`status = 0` | 送信先失敗 | 送信先の`revert`、メッセージ再実行規則、公式サポート | | 送信先実行結果の`status = 1`、UIは保留中 | UI / 索引サービス遅延 | ブロックエクスプローラー、確定性、ブリッジ索引サービス確認時刻 | | 送信先成功、ウォレットにトークンなし | トークン対応表 / 表示 | 送信先チェーン、受取先、トークンコントラクト、残高、ウォレット追加設定 | ### 待機中は「あと何分」だけで判定しない 待ち時間はネットワーク確定性、バッチ / アサーション、チャレンジ、リレイヤー、送信先混雑、索引サービスで変わります。公式状態が同じメッセージを追跡できているか、どの段階名で止まっているか、最終更新ブロックはどこかを保存します。 ブリッジUIとチェーン状態が違う場合は、確認時刻とUIバージョンを添えてください。取引所の入金表示も別システムなので、チェーン実行結果とサービス内状態を分ける考え方は[暗号資産の入金が反映されないときの確認順](/archives/6008)が使えます。 ### 失敗はソースと送信先を混ぜない ソース失敗なら、正常なメッセージイベントはそのトランザクションから成立していません。送信先失敗なら、メッセージは到達したが送信先呼び出しが`revert`した可能性があります。どちらも「もう一度同額を送る」でまとめず、失敗したチェーン、トランザクション、`revert`、再実行規則を分けます。 イベントデータの読み方が必要なら[ABI・呼び出しデータ・ログの基礎](/archives/6005)を参照してください。検証済みコントラクトという表示だけでブリッジ、ゲートウェイ、プロキシの安全性を保証しない点にも注意します。 ### 手動受取は公式状態が示したときだけ候補にする 受取 / 確定 / `redeem`ボタンが見えることと、対象メッセージが実行可能で未実行であることは別です。操作前に少なくとも次を同じ経路へ対応させます。 - 自分でブックマークまたは公式プロジェクトページから開いたURL - ソース / 送信先チェーンIDと方向 - トランザクションハッシュとプロトコル固有メッセージID - 公式状態が実行可能 / 確定済み / 利用可能であること - 送信先実行がまだ存在しないこと - コントラクトアドレス、受取先、トークン、表示される呼び出し内容 この記事の範囲はここまでです。受取を実行する場合は、利用したブリッジの最新公式手順とリスク注意を別途確認します。DMのサポートが送るURL、シードフレーズの入力、遠隔操作、追加送金を「解除手数料」とする案内は使いません。 ## ネイティブトークンとブリッジトークンをコントラクトで分ける 送信先トランザクションが成功しても、ウォレットに想定シンボルが出ないことがあります。まず「ネイティブトークン」と「ブリッジ表現」を分けます。 - ネイティブトークン: そのチェーン側で基準となる資産 / コントラクト - ブリッジトークン: ブリッジが対応する遠隔資産を表すトークンコントラクト - ラップ済みネイティブトークン: ネイティブ資産をERC-20として扱う別コントラクト - 第三者表現: 正規ブリッジとは別の発行者 / 経路が作るトークン OP Standard Bridgeの資料が示すように、同じネイティブトークンに複数の独立したブリッジ表現が対応し得ます。シンボル、名前、アイコンは識別子ではありません。ソースチェーンID、ソーストークンコントラクト、ブリッジ経路、送信先チェーンID、送信先トークンコントラクトの組で確認します。 送信先の実行結果が成功した後は、受取先アドレスのトークン残高、送金 / 発行イベント、送信元と送信先のトークン対応を確認します。ウォレットへ独自トークンを追加する前にも、公式の一覧やブリッジコントラクトが示す送信先アドレスと一致するか確認してください。送信先上の`balanceOf`には残高があるのにウォレットへ出ない場合は、[チェーン・コントラクト・小数桁・索引サービスを分ける確認手順](/archives/6029)へ進みます。 誤ったネットワーク、同じアドレス形式、管理主体の違いは[別ネットワークへ送ったときの確認順](/archives/6009)で切り分けられます。回収や返金が可能だと先に断定せず、誰が送信先キーやコントラクトを管理するかを固定します。 ## L2のデータ可用性や確定性と利用者表示を混ぜない ロールアップのバッチデータがL1へ投稿されたこと、プロトコルがメッセージを認識したこと、出金が証明 / 確認されたこと、送信先トランザクションが実行されたこと、ウォレットやブリッジ索引サービスが表示を更新したことは別のイベントです。 BlobやL2バッチ投稿の仕組みは[Fusaka・PeerDASとL2手数料の記事](/archives/6023)で扱っています。データ可用性の改善やL1バッチ送信の実行結果を、個別のブリッジメッセージが送信先で実行された証拠へ置き換えないでください。 ブリッジ全体の表示額と一つのL2実行結果の手数料を分けるには、[L2手数料を実行・データ可用性・運用者へ分解する手順](/archives/6054)も参照してください。 ## 公式サポートへ渡す証拠パッケージ 自力で段階を特定できない場合は、自分で開いた公式サイトのサポート入口から、次をまとめて渡します。 ```text 確認日時: ブリッジのURL / 提供元: 正規ブリッジ / 第三者ブリッジ: 送信元チェーンID -> 送信先チェーンID: 入金 / 出金: 送信元トランザクションのハッシュ / 実行結果 / イベント: メッセージ識別子と取得元: 公式プロトコル上の状態 / 最終更新ブロック: 送信先トランザクションのハッシュ / 実行結果（あれば）: 送信元トークンコントラクト -> 想定する送信先トークンコントラクト: 受取先アドレス: 画面上の状態とスクリーンショットの時刻: ``` トランザクションハッシュと公開アドレスはチェーン上で公開されていますが、サポート問い合わせ番号自体の公開範囲は別です。メール、電話番号、残高全体、本人確認書類、APIキー、セッションCookie、未加工ウォレットバックアップは必要性と送信先を確認します。シードフレーズ、秘密鍵、キーストアパスワードは渡しません。 ## 最終チェックリスト - [ ] 利用したURLとブリッジコントラクトから正規 / 第三者を分けた - [ ] ソース → 送信先と入金 / 出金を固定した - [ ] ソーストランザクションハッシュ、実行結果の状態、ブリッジイベントを同じチェーンで確認した - [ ] 経路固有の`sourceHash`、出金ハッシュ、再試行可能チケットID、位置、注文IDを保存した - [ ] リレー / 証明 / チャレンジ / 確認 / 実行可能のどの段階か公式情報で確認した - [ ] 送信先トランザクションまたは未実行受取状態を同じメッセージIDへ対応させた - [ ] ネイティブ / ブリッジ / ラップ済みトークンとローカル / 遠隔コントラクトを分けた - [ ] 観測時間を到着予想や保証として扱っていない - [ ] 再送、非公式サポート、秘密情報共有を止めた - [ ] 公式サポートへ渡す証拠パッケージから秘密情報と不要な個人情報を除いた ブリッジ未着金の切り分けは、**送信元トランザクション、メッセージ識別子、プロトコル段階、送信先トランザクションまたは受取、トークン対応表を同じ経路へ対応させ、最初に証拠が途切れた地点を特定すること**です。 この記事にはブリッジ、交換、ウォレット、復旧サービスのアフィリエイト販売誘導を置いていません。特定サービスへの送金を促すのではなく、追加操作の前に読み取り専用証拠を揃える順序を示しています。 ## 確認した一次情報 - [Ethereum Execution APIs eth\_getTransactionReceipt](): 確認日 2026-08-31 - [OP Stack bridging basics](): 確認日 2026-08-31 - [OP Stack Standard Bridge](): 確認日 2026-08-31 - [OP Stack tracing deposits and withdrawals](): 確認日 2026-08-31 - [OP Stack withdrawal specification at pinned commit](): 確認日 2026-08-31 - [OP Sepolia Superchain Registry configuration at pinned commit](): 確認日 2026-08-31 - [Arbitrum bridge transaction traceability at pinned commit](): 確認日 2026-08-31 - [Arbitrum withdrawal monitoring at pinned commit](): 確認日 2026-08-31 - [Arbitrum SDK network configuration at pinned commit](): 確認日 2026-08-31 --- # L2出金はどこで止まった？OP Stack・Arbitrumの証明・確定・受取手順 OP StackとArbitrumのL2からL1への出金を、開始、出金ハッシュまたは位置、証明・アサーション、異議申立期間・確定性、確定・実行、L1の実行結果に分けて確認します。 正規URL: https://3mikan.com/archives/6028 著者: みかん 公開: 2026-08-30T23:20:00.000Z 更新: 2026-09-02T05:35:00.000Z L2の出金トランザクションが`success`なのに、L1へまだ反映されない。このとき、**L2実行結果は出金の開始を示すだけで、証明、チャレンジまたは確定性、L1での確定 / 実行まで完了した証拠ではありません**。 OP StackとArbitrumでは、同じ`pending`や`claim`という表示でも内部の状態遷移が異なります。まず利用した正規経路を確認し、経路、出金識別子、証明またはアサーション、チャレンジ / 確定性、L1実行結果を同じ一件へ対応させることが重要です。 この記事では公開テストネットの完了済みトランザクションを読み取り専用で照合します。ウォレット接続、署名、証明、確定、実行、受取、トランザクション送信、実資産移動、個人残高の取得は行いません。 ## 先に止める操作と保存する値 状態が分かるまでは、同じ出金の再送、別ブリッジへの移し替え、検索広告やDMから開く`claim`、手当たり次第の証明 / 確定を止めます。シードフレーズや秘密鍵をサポートへ渡す必要もありません。 最初に次の値を一つの調査メモへ保存します。 | 項目 | 保存する値 | なぜ必要か | | --- | --- | --- | | 経路 | 公式URL、正規 / 第三者、ソースL2、送信先L1、チェーンID | 別経路の状態を見ないため | | 資産 | ネイティブ / ERC-20、数量、L2トークン、想定L1トークン | シンボルだけで別表現を混同しないため | | 受取先 | L1受取先アドレス | 自分のウォレット表示ではなく実行先を固定するため | | 開始 | L2トランザクションハッシュ、ブロック、実行結果の状態、呼び出されたコントラクト、イベント | 出金開始が成立したか確認するため | | 識別子 | OP出金ハッシュ、Arbitrum `position`など | 同じ一件をL2とL1で結ぶため | | 証明 / アサーション | 証明トランザクション、出力 / 異議申立てゲーム、アサーションの状態 | 待機前の条件を分けるため | | チャレンジ / 確定性 | 公式状態、コントラクト値、確認ブロック・時刻 | 固定日数の転載で判断しないため | | L1実行 | 確定 / 実行トランザクション、実行結果、イベント、未実行状態 | `claimable`と`executed`を分けるため | | バージョン | Portal、Bridge、Outboxなどのアドレス・実装・バージョン | 更新前後の手順を混ぜないため | 一般的なブリッジ未着金のソース・メッセージ・送信先の確認順は[ブリッジ送金が保留中・失敗・未着金のときの確認順](/archives/6027)で先に整理できます。ここでは正規オプティミスティックロールアップのL2→L1だけを深掘りします。 ## L2→L1出金は一つのトランザクションではない L1→L2入金とL2→L1出金は逆再生ではありません。オプティミスティックロールアップの出金では、L2上の開始、L1で参照できる出力やアサーション、異議申立て・確定性条件、L1実行が別の境界になります。 | 境界 | OP Stack | Arbitrum | 完了を示す主な証拠 | | --- | --- | --- | --- | | 開始 | L2出金と`MessagePassed` | ArbSysの`L2ToL1Tx` | L2実行結果、対象イベント | | 識別子 | 出金ハッシュ | `position` / 子チェーンから親チェーンメッセージ | イベントから得たプロトコル固有値 | | 証明 / アサーション | 出力を参照してPortalへ証明 | バッチに含まれ、アサーションへ取り込まれる | 証明イベント、公式メッセージ状態 | | チャレンジ / 確定性 | 障害証明ゲームとPortal条件 | アサーションの承認数条件 | ゲーム / アサーションの現在の状態 | | 実行可能 | 確定条件を満たす | `CONFIRMED` | 公式状態と未実行状態 | | L1実行 | `finalizeWithdrawalTransaction` | Outbox `executeTransaction` | L1実行結果、実行イベント、使用済み状態 | `initiated`、`proven`、`confirmed`、`claimable`、`finalized`、`executed`は同じ意味ではありません。UIのボタン名ではなく、対象経路のコントラクトとイベントを照合します。 ## OP Stackは開始・証明・待機・確定を分ける OP StackのL2出金を開始、出金ハッシュ、証明、障害証明待機、確定、L1実行結果へ分ける図 ### 1. L2で開始実行結果と出金ハッシュを得る OP Stackの出金は、L2側のブリッジやメッセンジャーを通り、`L2ToL1MessagePasser`の`MessagePassed`を発生させます。まずL2実行結果の`status = 1`、呼び出されたコントラクト、イベントコントラクト、送信者、対象、値、ガス上限、データを確認します。 出金ハッシュは、対象メッセージの各項目をABIエンコードして計算する識別子です。 ```text withdrawalHash = keccak256( abi.encode(nonce, sender, target, value, gasLimit, data) ) ``` L2トランザクションハッシュと出金ハッシュは別物です。証明と確定のL1イベントへ同じ出金ハッシュが現れるかを確認します。 ### 2. 出力と証明トランザクションを確認する 開始直後に、どの出力でも証明できるわけではありません。対象L2ブロックを含む出力と、経路が採用する証明システムの条件が必要です。 障害証明構成のPortalでは、証明時に参照した異議申立てゲーム、証明の提出者、証明タイムスタンプが出金へ対応します。`WithdrawalProven`があるだけでL1実行済みとは言えません。対象ゲームの種類、状態、L2ブロック、作成時 / 解決時のタイムスタンプも保存します。 ### 3. チャレンジ・確定待ち期間・確定性を現在のコントラクトで確認する 「OP出金は必ず7日」のような固定値だけで次の操作を決めないでください。ネットワーク、Portalのバージョン、採用されているゲーム型、証明の確定待ち期間、ゲーム確定性の構成は変わり得ます。 確認時点の公式登録簿とPortalで、少なくとも次を対応させます。 - L1チェーンIDとPortalアドレス - Portalプロキシのバージョンと実装 - `proofMaturityDelaySeconds` - `disputeGameFinalityDelaySeconds` - `respectedGameType` - 証明時に使ったゲームの状態と解決結果 - 出金がすでに確定済みか 過去の所要時間は、その一件の観測値です。現在の別出金に残り時間を保証する値ではありません。 ### 4. 確定とL1実行結果を確認する 確定可能な条件と、誰かが確定トランザクションを送ったことは別です。L1実行結果でPortalの`WithdrawalFinalized`を探し、同じ出金ハッシュと`success`を確認します。さらにPortalの`finalizedWithdrawals(withdrawalHash)`が`true`かを読み取り専用で照合できます。 `WithdrawalFinalized`が成功しても、ERC-20ならL1トークン、受取先、ブリッジイベントを追加で確認します。この記事の公開例はネイティブテストネットETHであり、個人残高を取得せず、コントラクト実行までを証拠境界にします。 ## OP Sepoliaの完了例を一件追跡する 2026-08-31に、公開テストネットの完了済み出金を固定しました。以下は速度の見積もりではなく、各段階を同じ出金ハッシュで結ぶ例です。 | 段階 | 固定した公開証拠 | | --- | --- | | 経路 | OP Sepolia `11155420` → Ethereum Sepolia `11155111`、正規Standard Bridge | | 資産 / 受取先 | ネイティブテストネットETH 1 ETH、受取先`0x6e94…bce2` | | 開始 | [L2トランザクション`0x52a8…5854`](https://testnet-explorer.optimism.io/tx/0x52a807d5bf5d216627e73e77abf0fb5c9cced1cea535a347b76f11bb6a505854)、ブロック`47,798,324`、実行結果成功 | | 識別子 | `withdrawalHash = 0x02e37383…e2a995`、`MessagePassed`のログ索引`5` | | 証明 | [L1トランザクション`0xeec0…c93c`](https://sepolia.etherscan.io/tx/0xeec016ee03119db5c20968c19af3ec1bf3cd3559f8271eea8beb1f21a047c93c)、`WithdrawalProven`のログ索引`52` | | ゲーム | 索引`84,080`、プロキシ`0x44d8…ed6f`、ゲームタイプ`8`、状態`DEFENDER_WINS` | | 確定 | [L1トランザクション`0x87f4…c00a`](https://sepolia.etherscan.io/tx/0x87f46225c4e1f39d44bea381c7dbd6f172adcdf1e6be0afac2e8528fceb2c00a)、`WithdrawalFinalized`成功 | | 経路バージョン | L2 Standard Bridgeは`1.13.2`、Portalは`5.6.1`、Portal実装は`0xe89f…d3c2`（2026-08-31確認） | イベントの452バイトのデータから再計算した出金ハッシュは、証明と確定のイベントトピックにある`0x02e37383…e2a995`と一致しました。Portalの`finalizedWithdrawals`も`true`でした。 観測時刻は開始が`2026-08-22 11:46:28 UTC`、証明が`2026-08-23 09:05:00 UTC`、確定が`2026-08-30 10:06:12 UTC`です。21時間18分32秒、7日1時間1分12秒、合計7日22時間19分44秒という差は、このテストネット例の履歴にすぎず、メインネット、別バージョン、次の出金の待ち時間ではありません。 ## Arbitrumは開始・アサーション・確認・実行を分ける ArbitrumのL2出金をL2ToL1Tx、位置、アサーションとチャレンジ、確定済み、Outbox実行、L1実行結果へ分ける図 ### 1. `L2ToL1Tx`の位置を保存する Arbitrumの子チェーンから親チェーン出金では、ArbSysの`L2ToL1Tx`イベントを探します。呼び出し元、送信先、値に加え、固有の`position`を保存します。この位置がL1 Outbox実行と同じ一件を結びます。 OPの出金ハッシュ計算をArbitrumへ流用したり、Arbitrumの位置をOP Portalへ照会したりはできません。 ### 2. アサーションとチャレンジの状態を確認する 公式監視資料では、開始後のメッセージはバッチへの取り込みとアサーションを経て、概ね`UNCONFIRMED`、`CONFIRMED`、`EXECUTED`として区別されます。 | 状態 | 読めること | まだ完了していないこと | | --- | --- | --- | | `UNCONFIRMED` | 開始を追跡できるが、アサーションの承認数条件を満たしていない | L1での実行 | | `CONFIRMED` | プロトコル上、Outbox実行の候補になった | 実行トランザクションとL1実行結果 | | `EXECUTED` | Outbox実行が記録された | UIやウォレット表示は別途確認が必要な場合がある | `confirmPeriodBlocks`は親チェーンのブロック数であり、固定した日数の保証ではありません。対象ネットワークのRollupコントラクト、現在値、メッセージ状態を確認します。 ### 3. Outboxの実行と使用済み状態を確認する `CONFIRMED`と表示されても自動で実行済みとは限りません。L1のOutboxトランザクションの実行結果で`OutBoxTransactionExecuted`を探し、イベントのトランザクション索引がL2の位置と一致するかを確認します。 Outboxの`isSpent(position)`が`true`なら、その位置は実行済みです。未実行なのに受取ボタンが見える場合も、公式経路、チェーン、送信先、呼び出し内容を確認するまでは署名しません。 ## Arbitrum Sepoliaの完了例を一件追跡する | 段階 | 固定した公開証拠 | | --- | --- | | 経路 | Arbitrum Sepolia `421614` → Ethereum Sepolia `11155111`、正規Outbox経路 | | 資産 / 受取先 | ネイティブテストネットETH 0.5 ETH、送信先`0xce23…3276` | | 開始 | [L2トランザクション`0x559f…ab13`](https://sepolia.arbiscan.io/tx/0x559f5a93a53f8e850c920f0653fcfe3ece22fef112bb69ef0056523d81a7ab13)、ブロック`303,468,608`、実行結果成功 | | 識別子 | `L2ToL1Tx.position = 117,694`、イベントハッシュ`0xcdd0…0f8b` | | ネットワーク状態 | Rollup `0xd808…81c8`、確認時の`confirmPeriodBlocks = 20` | | 実行 | [L1トランザクション`0x54cc…71e8`](https://sepolia.etherscan.io/tx/0x54cce03b6d3a4fd723f19ce7d70c802741aca1c6a9a6101b37da059ab71571e8)、`OutBoxTransactionExecuted`のログ索引`23` | | 使用済み / バージョン | `isSpent(117694) = true`、Outboxは`0x65f0…b78f`、実装は`0xfed2…224f`（2026-08-31確認） | L2イベントとL1イベントの位置はどちらも`117,694`で一致しました。開始は`2026-08-30 03:44:12 UTC`、実行は`12:34:48 UTC`で、観測差は8時間50分36秒です。この値はArbitrumメインネットのチャレンジ期間や将来のテストネット実行頻度を示しません。 ## 公開検証データを保存値・公開RPCで再確認する [検証用JSON](/fixtures/l2-withdrawal-6028.json)には、2例のチェーンID、トランザクション / ブロックハッシュ、識別子、コントラクト、バージョン、タイムスタンプ、観測差を収録しています。公開アドレスはイベントを結ぶためだけに記録し、人物特定、残高、ウォレット状態には使いません。保存済みデータ同士の整合は、ネットワークへ接続せず確認できます。 現在の公開RPCと比較する場合に使うのは、`eth_chainId`、`eth_getTransactionReceipt`、`eth_getBlockByHash`、`eth_call`、`eth_getStorageAt`という読み取り専用の方法だけです。ウォレット、署名者、APIの秘密情報、トランザクション送信は使いません。公開RPCが過去データを返さない場合は、保存データの不一致と決めつけず、同じチェーンの履歴対応RPCや公式ブロックエクスプローラーでブロックハッシュを再確認します。 ## 「何日」ではなく現在の段階を確認する L2実行結果、識別子、証明またはアサーション、チャレンジまたは確定性、L1実行結果から出金の停止段階を判断する図 | 観測 | 現在の分類 | 次の読み取り専用確認 | | --- | --- | --- | | L2実行結果なし | 開始未確定 / 破棄 / RPC遅延 | L2チェーン、ノンス、置換、別RPC | | L2実行結果の`status = 0` | 開始失敗 | `revert`、呼び出されたコントラクト。正常な証明を待たない | | 実行結果成功、対象イベントなし | 経路 / 呼び出し不一致 | ブリッジコントラクト、方向、イベントトピック | | 識別子あり、証明 / アサーション未成立 | プロトコル待機中 | 対象出力 / アサーション、最終更新ブロック | | OP証明済み、Portal条件未成立 | チャレンジ / 確定性待機中 | ゲーム状態、確定待ち期間、確定性、Portalバージョン | | Arbitrum `UNCONFIRMED` | アサーションの承認数待ち | 位置、アサーション、Rollupコントラクト | | 実行可能 / `CONFIRMED`、L1実行結果なし | 手動実行候補 | 公式経路、未実行状態、受取先、呼び出し内容 | | L1実行結果の`status = 0` | L1実行失敗 | `revert`、再実行規則、公式サポート | | L1イベントと識別子一致 | プロトコル実行済み | トークン / 受取先 / UI反映を分けて確認 | | チェーン上は実行済み、UIは保留中 | 索引サービス / UI遅延候補 | ブロックエクスプローラー、確認時刻、状態ページ | RPCの値を同じブロックへ固定して比較したい場合は[Ethereum RPCスナップショットを同じブロックへ固定する方法](/archives/6024)が使えます。ロールアップのデータ可用性やL1手数料を「出金の実行済み」と混ぜないためには[Fusaka・PeerDAS後のL2データとBlob手数料の確認方法](/archives/6023)も参照してください。 開始、証明、確定それぞれのトランザクション手数料を一つの出金手数料へ混ぜないためには、[L2実行結果の実行・L1データ・運用者分解](/archives/6054)を各段階へ個別に適用します。 ## 経路・トークン・受取先・コントラクトバージョンを最後に照合する L1実行まで見つかっても、ウォレットに期待したシンボルが出ないことがあります。そのときは、次を同じ実行結果へ対応させます。 1. ソースL2と送信先L1のチェーンID 2. 正規ブリッジ / Portal / Outboxのアドレス 3. プロキシ実装とバージョンの確認時点 4. ネイティブ資産かERC-20か 5. L2トークンとL1トークンのコントラクト組 6. 数量と受取先 7. L1実行イベントと実行結果の状態 8. ウォレットが表示しているチェーン・トークンコントラクト・索引サービス時刻 コントラクト更新があると、古いブログやスクリーンショットのボタン名、待機値、関数が現在の経路と一致しない場合があります。公式登録簿と検証済みソースを確認し、確認日とブロックをメモします。検証済み表示だけを安全保証にせず、公式登録簿のアドレスと一致するかを先に見ます。 第三者の高速ブリッジを使った場合は、この正規ライフサイクルをそのまま当てはめません。流動性提供者、リレイヤー、注文ID、精算経路という別の状態があり得ます。トラブル対応中に「待たずに移せる」という広告から追加送金しないでください。 ## サポートへ渡す証拠パッケージ 公式サポートへ問い合わせる場合は、秘密情報ではなく次の公開証拠を渡します。 - 利用した公式経路URL、ソース / 送信先チェーンID、確認時刻 - L2開始トランザクションハッシュ、ブロックハッシュ、実行結果の状態、イベントログ索引 - OP出金ハッシュまたはArbitrum位置 - 証明トランザクション / 異議申立てゲーム、またはアサーション / メッセージ状態 - L1確定 / 実行トランザクションがある場合はハッシュ、実行結果、イベント - トークンコントラクト、数量、受取先。公開投稿では必要に応じて一部マスク - Portal / Bridge / Rollup / Outboxアドレス、バージョン / 実装 - UI表示とチェーン状態が違う場合は、個人情報を除いた画面とブラウザーのバージョン シードフレーズ、秘密鍵、キーストアを渡さず、遠隔操作アプリを導入せず、追加の「解除手数料」も払いません。サポートが操作を求める場合も、URL、チェーン、コントラクト、復号した呼び出し、資産の状態変更を確認し、分からなければ署名前で止めます。 ## まとめ L2出金のL2実行結果は、L1での受取処理の実行結果ではありません。OP Stackでは開始 → 出金ハッシュ → 証明 → 障害証明 / 確定性 → 確定、Arbitrumでは`L2ToL1Tx.position` → アサーション / チャレンジ → `CONFIRMED` → Outbox実行を別々に確認します。 経過日数だけを答えにせず、経路、トークン、受取先、コントラクトバージョン、プロトコル固有識別子、現在の公式状態、L1実行結果を一つの証拠パッケージへまとめてください。状態が分からない間は、再送、非公式受取、追加ブリッジ、秘密情報の共有を止めるのが安全です。 ## 確認した一次情報 - [OP Stack withdrawal flow](): 確認日 2026-08-31 - [OP Stack withdrawal specification at pinned commit](): 確認日 2026-08-31 - [OP Stack OptimismPortal specification at pinned commit](): 確認日 2026-08-31 - [OP Sepolia Superchain Registry configuration at pinned commit](): 確認日 2026-08-31 - [Arbitrum bridge transaction traceability at pinned commit](): 確認日 2026-08-31 - [Arbitrum withdrawal monitoring at pinned commit](): 確認日 2026-08-31 - [Arbitrum Sepolia network configuration at pinned commit](): 確認日 2026-08-31 --- # トークンがウォレットに表示されないときの確認手順｜チェーン・コントラクト・小数桁 送金・交換・ブリッジ後にERC-20が見えないとき、チェーン、アカウント、Transferログ、トークンコントラクト、balanceOf、小数桁、自動検出、索引処理を順に確認します。 正規URL: https://3mikan.com/archives/6029 著者: みかん 公開: 2026-08-30T23:40:00.000Z 更新: 2026-09-02T05:35:00.000Z 送金、交換、ブリッジのトランザクションが成功したのに、ウォレットの資産一覧へトークンが出てこない。ここで最初に分けるべきなのは、**ウォレット表示に行がないこと**と、**正しいチェーン・アカウント・トークンコントラクトの`balanceOf`が0であること**です。前者だけでは資産消失を証明しません。 反対に、トークンが一覧へ表示されたことも、公式、換金可能、安全、正しいブリッジ表現である証拠にはなりません。この記事では、チェーン、アカウント、Transferログ、コントラクト、`balanceOf`、小数桁を先に固定し、その後でトークン検出、トークン一覧、RPC、索引サービス、キャッシュ、非表示設定を調べます。 ウォレット接続、署名、独自トークン追加、`approve`、交換、焼却、受取、トランザクション送信、実資産移動は行いません。掲載する検証例は架空アドレスだけを使う読み取り専用データです。 ## 先に止める操作と保存する値 原因が分かるまでは、同じトークンの再送、検索結果から開く「表示解除」や「現金化」、未知トークンの交換・焼却・`approve`、DMサポートへの接続を止めます。表示の問題を直すためにシードフレーズ、秘密鍵、キーストア、遠隔操作アプリが必要になることはありません。 最初に次を一つの調査メモへ保存します。 | 項目 | 保存する値 | なぜ必要か | | --- | --- | --- | | チェーン | ネットワーク名ではなくチェーンID、利用RPC、確認ブロック | 同名ネットワークや別チェーンを混ぜないため | | アカウント | 受取予定アドレス、ウォレットで選択中のアカウント | 別アカウントの一覧を見ないため | | トランザクション | トランザクションハッシュ、`receipt.status`、ブロック、`to`、ログ | ネットワークへの送信・成功・トークン移動を分けるため | | トークン | Transferログの`address`、公式ソースが示すコントラクト | シンボルやアイコンを資産IDにしないため | | 受取先 | Transferログの`to` | ウォレット所有アドレスと一致するか確認するため | | 残高 | `balanceOf(account)`の未加工の`uint256`とブロック | UIではなくコントラクト状態を確認するため | | メタデータ | 同じコントラクトの小数桁、シンボル、名前 | 未加工整数の表示方法を確認するため | | 表示 | ウォレット/バージョン、トークン検出、非表示、RPC、確認時刻 | 索引サービス・キャッシュ・設定の観測を再現するため | ブリッジの送信先トランザクション自体がまだない場合は、先に[ブリッジ未着金をソース・メッセージ・送信先へ分ける手順](/archives/6027)へ戻ります。取引所内残高へ反映されない場合は[チェーン上の状態と取引所状態を分ける手順](/archives/6008)、別ネットワークへ送った可能性がある場合は[送信チェーンと管理主体の確認順](/archives/6009)を使ってください。 ## 表示ではなく証拠を上から順に確認する チェーンID、アカウント、Transferログ、トークンコントラクト、`balanceOf`、小数桁、ウォレット表示の順にトークン未表示を切り分ける図 順番は次のとおりです。 1. 実行結果を開いたブロックエクスプローラーとRPCのチェーンIDを固定する 2. ウォレットで選んだアカウントとTransferログの受取先を照合する 3. Transferログを発生させたコントラクトアドレスをトークン候補にする 4. 同じチェーン・コントラクトへ`balanceOf(account)`を読み取り専用で呼ぶ 5. 未加工整数を同じコントラクトの小数桁で整形する 6. チェーン上残高がある場合だけウォレットの表示層を調べる 最初の不一致が原因候補です。後ろの表示設定から先に触ると、別コントラクトを追加して「直ったように見える」状態を作りやすくなります。 ## 1. チェーンIDとアカウントを固定する トークンは「どのチェーンの、どのコントラクトが、どのアカウントについて返す残高か」で読みます。ウォレットに表示されたネットワーク名や同じ`0x`形式だけでは足りません。 確認する値は次の4つです。 - トランザクションの実行結果を取得したチェーンID - ウォレットが現在読んでいるチェーンID - Transferログの受取先アドレス - ウォレットで選択中のアカウントアドレス 例えばEthereum Mainnetのコントラクトアドレスと、Base上で同じ文字列になるコントラクトアドレスは、同じ資産IDではありません。アカウントアドレスの文字列が複数EVMチェーンで同じでも、残高状態はチェーンごとに別です。 RPCを使う場合は`eth_chainId`を先に記録し、後続読み取りを同じ接続先へ対応させます。過去トランザクションと現在残高を再現したい場合は、`latest`ではなく確認対象ブロックを保存してください。複数読み取りを同じブロックへ固定する方法は[RPCスナップショットの作り方](/archives/6024)で詳しく説明しています。 ## 2. Transferログからトークンコントラクトと受取先を得る ERC-20の`Transfer`イベントは次の形です。 ```text Transfer(address indexed from, address indexed to, uint256 value) ``` 実行結果では、イベントを発生させた`log.address`がトークンコントラクト候補です。トランザクション本体の`to`はルーター、ブリッジ、保管庫、マルチシグなど別コントラクトの場合があります。 | 実行結果の場所 | 読む値 | 間違えやすい点 | | --- | --- | --- | | `receipt.status` | トランザクション全体の成功・失敗 | 成功だけで受取残高を断定する | | `transaction.to` | 最初に呼ばれたアドレス | トークンコントラクトとは限らない | | `log.address` | イベントを発行したコントラクト | 公式トークンかは別途照合が必要 | | `topics[1]` | 索引付きの`from` | 32バイト語の末尾20バイトがアドレス | | `topics[2]` | 索引付きの`to` | 受取予定アカウントと一致するか確認 | | `data` | 未加工の`uint256 value` | 小数桁適用前の整数 | [公開検証JSON](/fixtures/token-display-6029.json)では、トランザクションの`to`を架空のルーター`0x3333…3333`、Transferログのコントラクトを`0x0000…1006`に分けています。受取先は`0x1111…1111`、未加工値は`123456789`です。 Transferログが受取先へ向いていても、そのトークンが公式、安全、売買可能という証拠ではありません。スパムトークンもTransferイベントを作れます。まず「どのコントラクトの値が動いたか」を特定する証拠として使います。 ## 3. `balanceOf`でチェーン上残高を読む [ERC-20](https://eips.ethereum.org/EIPS/eip-20)の`balanceOf(address)`は、指定アカウントの残高を未加工整数で返します。`eth_call`はトランザクションを作らず、チェーン状態を読み取り専用で確認するJSON-RPCメソッドです。 架空アカウント`0x1111…1111`の呼び出しデータは次の形になります。 ```text 0x70a08231 0000000000000000000000001111111111111111111111111111111111111111 ``` `0x70a08231`は`balanceOf(address)`の4バイト識別子で、その後ろにアドレスを32バイトへ左パディングします。RPC要求では`to`へTransferログで得たトークンコントラクト、`data`へこの呼び出しデータ、ブロック引数へ記録したブロックを指定します。 ```json { "jsonrpc": "2.0", "id": 1, "method": "eth_call", "params": [ { "to": "0x0000000000000000000000000000000000001006", "data": "0x70a082310000000000000000000000001111111111111111111111111111111111111111" }, "0xFIXED_BLOCK" ] } ``` `0xFIXED_BLOCK`は説明用の仮値です。そのまま送信せず、調査対象チェーンの実在ブロック番号へ置き換えます。この記事の検証ではRPCへ接続せず、ウォレット、秘密情報、署名者、書き込み操作も使いません。 結果が0の場合でも、すぐ「消失」と結論づけません。次を再確認します。 - チェーンIDとブロックが正しいか - アカウントが受取先と一致するか - コントラクトがTransferログと公式ソースの両方に一致するか - 送金後のブロックを読んでいるか - ブリッジや保管庫が別表現・受取可能残高を使っていないか - 呼び出しが`revert`、空応答、RPCエラーになっていないか 結果が0より大きく、ウォレット表示だけがないなら、チェーン上残高と表示層を切り分けられます。 ## 4. 未加工整数を小数桁で表示額へ変換する ERC-20の残高は小数ではなく整数です。`decimals`が`d`なら、人が読む表示は概念上`raw / 10^d`です。JavaScriptの`Number`へ大きな値を入れると丸める可能性があるため、未加工は文字列または`BigInt`のまま扱います。 架空の検証データは同じように見えるシンボル`BOX`で、0・6・8・18小数桁を分けています。 | 小数桁 | 未加工整数 | 正しい表示 | | ---: | ---: | ---: | | 0 | `42` | `42` | | 6 | `123456789` | `123.456789` | | 8 | `123456789` | `1.23456789` | | 18 | `1234567890123456789` | `1.234567890123456789` | 小数点を文字列で置く最小例です。 ```js function formatUnits(rawValue, decimals) { const digits = BigInt(rawValue).toString() if (decimals === 0) return digits const padded = digits.padStart(decimals + 1, '0') const whole = padded.slice(0, -decimals) const fraction = padded.slice(-decimals).replace(/0+$/, '') return fraction ? `${whole}.${fraction}` : whole } ``` 未加工値`123456789`のコントラクト小数桁が6なら`123.456789`です。ウォレットへ18と誤登録すると`0.000000000123456789`に見えますが、チェーン上未加工残高は変わりません。独自トークンを再追加しても資産を移動・回収したことにはなりません。 EIP-20では`name`、`symbol`、`decimals`は任意メタデータです。読み取り関数がない、標準的なABI符号化を返さない、プロキシや古い実装に癖があるトークンもあるため、メタデータ取得失敗と残高0を同じ意味にしないでください。 ## 5. シンボルではなくチェーンIDとコントラクトで資産を分ける 名前、シンボル、アイコン、小数桁は表示メタデータです。同じ文字が見えても資産識別情報は一致しません。 | 見た目 | 実際に比較する値 | 判断 | | --- | --- | --- | | 同じシンボル・同じ小数桁 | チェーンID、コントラクトアドレス | コントラクトが違えば別トークン | | 同じコントラクト文字列 | チェーンID | チェーンが違えば別状態 | | ネイティブとラップ済み | ERC-20コントラクトの有無 | ラップ前後は別表現 | | 正規ブリッジと第三者ブリッジ | ソーストークン、経路、送信先コントラクト | 発行者・裏付け・`redeem`経路が異なり得る | | 同じロゴ・名前 | 公式登録簿とコントラクト | 資産識別情報の証拠にならない | Uniswap Token Listsのスキーマもトークンメタデータとして`chainId`と`address`を別々に持ちます。ただし、スキーマへ適合する一覧を誰でも作れるため、一覧掲載だけで公式性や安全性を保証しません。一覧の配布元、バージョン、確認日、発行者やブリッジの公式コントラクトソースを別に照合します。 ブロックエクスプローラーの検証済み表示もトークンの公式性や安全性を保証しません。[コンパイラー・コンストラクター・プロキシ・メタデータから検証済みソースを再ビルドする手順](/archives/6033)で、ソースと実行時バイトコードの対応、プロキシ先、所有者や管理者の別評価まで確認できます。 ブリッジ後に送信先実行結果が成功している場合は、ソーストークンと送信先トークンの対応表を利用経路の公式情報で確認します。ネイティブ、ラップ済み、ブリッジ、第三者表現の違いは[ブリッジのトークン対応表確認](/archives/6027)も参照してください。 ## 6. チェーン上残高がある場合だけウォレット表示層を調べる ここまでで正しいチェーン・アカウント・コントラクトの`balanceOf`が0より大きければ、次にウォレット側の表示経路を確認します。 | 表示層 | 確認すること | 境界 | | --- | --- | --- | | 選択済みネットワーク | ウォレットが正しいチェーンを表示しているか | ネットワーク切替は資産移動ではない | | 選択済みアカウント | 受取先と同じアカウントか | アカウント追加は残高複製ではない | | 自動検出 | 対象チェーンとトークンが現在の検出対象か | 未検出は残高0を意味しない | | トークン一覧 / メタデータAPI | チェーンID、コントラクト、小数桁、更新時刻 | 一覧掲載は公式・安全保証ではない | | 非表示 / スパム絞り込み | 手動非表示・自動絞り込み対象か | 非表示は焼却や削除ではない | | RPC | チェーンID、先頭、エラー、別接続先との差 | RPC追加は資産回収ではない | | 索引サービス / キャッシュ | ブロックエクスプローラー・ウォレット・ポートフォリオの更新ブロックと時刻 | 遅延はチェーン状態と別 | 2026-08-31確認時点の[MetaMask公式案内](https://support.metamask.io/manage-crypto/tokens/how-to-display-tokens-in-metamask/)は、自動トークン検出と、検索またはコントラクトアドレスによる手動追加を分けています。また、MetaMask自身が「有効なトークンを確定する公式一覧」を維持しているわけではないと説明しています。対応ネットワークや画面位置は変わり得るため、ウォレットバージョンと公式の現行手順を確認してください。 別RPCへ切り替える場合も、公式ネットワーク情報から選び、チェーンIDが一致することを先に確認します。未知サイトが指定するRPCやネットワーク追加を、残高表示のためにそのまま承認しないでください。 ## 7. 独自トークン追加で変わるもの・変わらないもの 独自トークン追加は、ウォレットへ「このチェーンのこのコントラクトを一覧で追跡する」と教える表示操作です。 変わり得るものは次です。 - 資産行が一覧へ追加される - シンボル、小数桁、アイコンなどの表示が補われる - ウォレットが対象コントラクトの残高を定期取得する 変わらないものは次です。 - コントラクトストレージの`balanceOf` - トークンの所有者、発行者、裏付け、送金制限 - ブリッジ前後の表現 - 交換可能性、価格、流動性、安全性 - 資産の公式性 [EIP-747](https://eips.ethereum.org/EIPS/eip-747)の`wallet_watchAsset`も、ウォレットが資産追加要求を認識したことと、実際に表示・承認されたことを分けています。DAppからトークン追加確認画面が出ても、チェーンIDとコントラクトを独立して確認し、未知サイトの要求を表示修正として承認しないでください。 ## 8. スパム・エアドロップトークンは「表示するために触る」を止める 身に覚えのないトークンがブロックエクスプローラーやポートフォリオに見える場合、表示されたこと自体は被害ではありません。危険は、トークン名、シンボル、エラーメッセージ、メタデータに誘導され、外部サイトを開いて署名・`approve`・交換・焼却・受取することです。 [MetaMaskの失敗トランザクション詐欺案内](https://support.metamask.io/stay-safe/protect-yourself/tokens-and-transactions/failed-transaction-scams)は、動かせないエアドロップトークンを配布し、失敗メッセージからフィッシングサイトへ誘導する手口を説明しています。 未知トークンでは次を行いません。 - エラーメッセージやトークン名に書かれたURLを開く - 「換金確認」のために`approve`、交換、焼却を試す - ガスや解除料を追加送金する - シードフレーズや秘密鍵を入力する - トークン一覧掲載やウォレット表示を安全評価に使う ウォレットに非表示機能があるなら、操作せず表示だけ隠す選択肢があります。非表示にしてもチェーン上トークンは焼却されません。 ## 状態別の次の確認先 | 観測 | 分類 | 次に確認する読み取り専用証拠 | | --- | --- | --- | | 実行結果なし | 保留中 / 破棄 / 誤ったチェーン / RPC遅延 | トランザクションハッシュ、送信元・ノンス、チェーンID、別ブロックエクスプローラー | | 実行結果失敗 | トランザクション失敗 | `revert`、呼び出されたコントラクト、手数料。正常なTransferを想定しない | | 実行結果成功、対象Transferなし | 経路 / イベント不一致 | ログ全体、ブリッジ / ルーターのイベント、受取先 | | Transferあり、受取先不一致 | 異なるアカウント / 送信先 | トピック、受取アドレス、カストディ型サービス / コントラクトの管理主体 | | Transferあり、`balanceOf = 0` | 後続の送金 / 誤ったブロック / 誤った識別情報 | 送金後のブロック、チェーン、アカウント、コントラクト、後続ログ | | `balanceOf > 0`、表示なし | ウォレット表示 / 検出 / 索引サービス | 小数桁、非表示状態、RPC、ウォレットバージョン、更新時刻 | | 未加工は一致、表示額が違う | 小数桁 / 整形処理 | 同じコントラクトの小数桁、BigInt整形、手動メタデータ | | シンボルだけ一致 | 識別情報不明 | チェーンID、コントラクト、発行者 / ブリッジ公式ソース | | 未知トークンが表示された | スパム候補 | 操作せず、公式ソース不在なら非表示のまま停止 | ## 公式サポートへ渡す証拠パッケージ ウォレットまたはサービスの公式サポートへ問い合わせる場合は、次をまとめます。 ```text 確認日時: ウォレット / アプリのバージョン: チェーン名とチェーンID: 認証情報を除いたRPCホスト名: アカウント / 受取先: トランザクションハッシュとブロック: 実行結果の状態: Transferログのコントラクト / from / to / 未加工値: balanceOfのブロック / calldata / 未加工結果: name / symbol / decimalsの取得結果: 正しく整形した値: ウォレットの表示・非表示状態 / 最終更新時刻: コントラクト照合に使ったトークンまたはブリッジの公式情報: ``` 公開チェーンデータをサポートへ渡す場合も、公開の問い合わせ欄に書ける情報とは限りません。メール、電話番号、他資産の残高、本人確認書類、APIキー、セッションCookie、ウォレットのバックアップは必要性を確認して最小限にします。シードフレーズ、秘密鍵、パスワード、2段階認証コード、遠隔操作アプリは渡しません。 ## よくある質問 ### 独自トークンを追加すれば資産を回収できますか？ できません。追加はウォレット表示を追加する操作です。正しいチェーン・コントラクトに残高があれば見える可能性がありますが、別チェーンの資産を移動したり、誤送金を返還したりしません。 ### シンボルと小数桁が同じなら同じトークンですか？ 同じとは限りません。同じチェーンでもコントラクトが違えば別トークンです。同じコントラクト文字列でもチェーンIDが違えば別状態です。 シンボル、名前、アイコンは資産識別情報の根拠にしません。 ### ブロックエクスプローラーではトークンがあるのにウォレットだけ0です ブロックエクスプローラーが見ているチェーン、アカウント、コントラクト、ブロックを先に固定し、同じ条件で`balanceOf`を読みます。一致するならウォレットの選択済みネットワーク / アカウント、小数桁、トークン検出、非表示状態、RPC、索引サービス時刻を確認します。 ### トークンが表示されたので交換して安全か確かめてもよいですか？ 未知トークンでは行いません。表示や`balanceOf > 0`は、安全性、送金可能性、価格、流動性を証明しません。送金・売却失敗を調べる場合は[送金手数料・残高変動・拒否リスト・流動性を分ける手順](/archives/6061)へ進みます。 失敗トランザクションや外部URLを使う詐欺があるため、独立した公式ソースがないトークンは操作せず停止します。 ## 最終チェックリスト - [ ] トランザクションとウォレットのチェーンIDを記録した - [ ] Transferログの受取先と選択中アカウントを照合した - [ ] トランザクションの`to`ではなくTransferログの`log.address`からコントラクト候補を得た - [ ] コントラクトを発行者・ブリッジの公式ソースと照合した - [ ] `balanceOf(account)`の未加工結果とブロックを保存した - [ ] 同じコントラクトの小数桁でBigIntのまま表示額を計算した - [ ] シンボル、名前、アイコンを資産識別情報にしていない - [ ] ネイティブ、ラップ済み、ブリッジ、第三者表現を分けた - [ ] チェーン上残高確認後にトークン検出、一覧、RPC、索引サービス、キャッシュ、非表示状態を調べた - [ ] 独自トークン追加を回収・移動・安全保証として扱っていない - [ ] 未知トークンで`approve`、交換、焼却、受取、外部URLを試していない - [ ] サポートへ秘密情報や不要な個人情報を渡していない トークン未表示の切り分けは、**チェーンID、アカウント、Transferログのコントラクト、固定ブロックの`balanceOf`、同じコントラクトの小数桁を一つの証拠列へ対応させ、ウォレットのトークン検出・一覧・索引サービスは最後に確認すること**です。 この記事にはウォレット、交換、ブリッジ、トークン追加ツール、取引所、復旧サービスのアフィリエイト販売誘導を置いていません。表示の不安から追加トランザクションへ誘導せず、読み取り専用証拠を先に揃える順序を示しています。 ## 確認した一次情報 - [ERC-20 Token Standard](): 確認日 2026-08-31 - [wallet\_watchAsset RPC Method](): 確認日 2026-08-31 - [Ethereum JSON-RPC API](): 確認日 2026-08-31 - [MetaMask token display and import guidance](): 確認日 2026-08-31 - [MetaMask missing or incorrect token balance guidance](): 確認日 2026-08-31 - [MetaMask failed transaction scam guidance](): 確認日 2026-08-31 - [Uniswap Token Lists types at pinned commit](): 確認日 2026-08-31 --- # Safeの取引が進まないときの確認手順｜署名・必要署名数・ノンス・実行失敗 Safeのマルチシグが署名待ち、ノンス競合、実行失敗になるとき、提案、所有者の承認数、Safeのノンス、保護機構、呼び出し先のrevertを証拠ごとに確認します。 正規URL: https://3mikan.com/archives/6030 著者: みかん 公開: 2026-08-31T00:45:00.000Z 更新: 2026-09-02T05:35:00.000Z Safeの画面に署名待ち（Awaiting confirmations）、待機中（Queued）、実行失敗（Execution failed）などと出ても、同じ原因とは限りません。最初に分けるのは、**提案が作られたこと**、**所有者署名が集まったこと**、**別のEthereumトランザクションでチェーン上実行が試されたこと**の3段階です。 2-of-3で署名が2件見えても、現在の所有者・必要署名数、署名対象のSafeトランザクションハッシュ、Safeノンス、保護機構、対象呼び出しが一致しなければ実行成功は確定しません。反対に、Transaction Serviceの表示が遅れていても、チェーン上ではすでにSafeノンスが進んでいる場合があります。 この記事は、Safeアドレスやチェーンを確認せずに再署名・再実行する手順ではありません。公開データは読み取り専用で扱い、掲載する再現結果はローカルチェーンだけで動かしています。実在Safeへの接続、署名要求、モジュール・保護機構変更、トランザクション送信、資産移動は行いません。 ## 先に止める操作と保存する値 原因が分かるまでは、同じ内容への再署名、ノンスだけを変えた再提案、未知の実行者やリレイヤーへの送信、保護機構・モジュール・必要署名数の変更、検索結果やDMから開く「復旧」接続を止めます。所有者であっても、内容を確認していないハッシュへ署名しません。 一件の調査メモへ次を保存します。 | 項目 | 保存する値 | 分けたいもの | | --- | --- | --- | | Safe識別情報 | チェーンID、Safeアドレス、実装、`VERSION()`、確認ブロック | 別チェーン・別プロキシ・別バージョン | | 認可 | 所有者、必要署名数、現在のSafeノンス | 現在の署名条件 | | 提案 | `to`、値、データ、操作、ガス関連項目、ノンス、`safeTxHash` | 署名対象の内容 | | 承認数 | 署名者アドレス、署名型、確認時刻、対応`safeTxHash` | 件数表示と有効署名 | | 実行 | Ethereumトランザクションハッシュ、送信者、EOAノンス、実行結果、ログ、実行履歴 | 提案とチェーン上試行 | | 拡張機能 | モジュール、トランザクション保護機構、モジュール保護機構、フォールバックハンドラー | 所有者経路以外の実行・拒否 | | サービス | Transaction Service URL、応答、索引処理状態、確認時刻 | チェーン外記録とチェーン状態 | SafeアドレスとチェーンIDを固定できない場合はそこで停止します。アドレスの文字列が同じでもチェーンが違えば別のコントラクト状態です。プロキシ実装の読み方は[ERC-1967プロキシの確認手順](/archives/6020)も参照してください。 SafeプロキシはERC-1967スロットを使うとは限らないため、一般的なプロキシ判定をそのまま当てはめず、対象バージョンの公式ソースと照合します。 ## 提案・承認数・実行の3段階 チェーン外の提案、所有者の承認数、必要署名数と、別のチェーン上のexecTransaction呼び出し、実行結果、Safeイベント、実行履歴を分ける図 ### 1. 提案 提案は、Safeトランザクションの項目とSafeノンスをまとめ、EIP-712の`safeTxHash`を作った段階です。Safe Transaction Serviceへ登録された提案や、別の調整役が保持する提案はチェーン外記録です。提案が一覧にあるだけでは、Safeコントラクトの状態は変わりません。 ### 2. 承認数 所有者は、表示ラベルではなく同じ`safeTxHash`へ署名します。Safe v1.5.0の通常のEOA署名は、署名から復元した所有者アドレスの昇順に連結して検証されます。2-of-3なら現在の所有者3名のうち2名が必要ですが、削除済み所有者、別ハッシュ、重複所有者、順序不正、必要署名数未満は有効な2件になりません。 所有者がコントラクトアカウントならERC-1271など別の署名検証が関係します。EOA署名とコントラクト署名の違いは[ERC-1271の検証手順](/archives/6011)、ウォレット確認画面で型付きデータのドメイン・チェーン・コントラクト・ノンスを読む方法は[署名要求の安全確認](/archives/6025)へ分けてください。 ### 3. チェーン上実行 必要署名数へ到達しても自動実行とは限りません。実行者が別のEthereumトランザクションでSafeの`execTransaction`を呼びます。この外側トランザクションにはEthereumトランザクションハッシュと実行者EOAノンスがあり、Safeトランザクションには`safeTxHash`とSafeノンスがあります。 実行結果の`status: 1`は外側呼び出しが`revert`せず終わったことを示します。しかしSafeが対象失敗を捕捉して`ExecutionFailure`を発行し、`execTransaction`が`false`を返す構成では、外側実行結果が成功でもSafe内部呼び出しは失敗し得ます。実行結果、`ExecutionSuccess` / `ExecutionFailure`イベント、戻り値、実行履歴を同じEthereumトランザクションハッシュへ対応させます。 ## `safeTxHash`とEthereumトランザクションハッシュは別物 | 識別子 | いつ作られるか | 主な入力 | 何を証明しないか | | --- | --- | --- | --- | | Safeトランザクションハッシュ | 提案作成時 | チェーンID、Safeアドレス、`to`、値、データ、操作、ガス / 返金項目、Safeノンス | ネットワークへの送信、ブロック採用、対象成功 | | Ethereumトランザクションハッシュ | 実行者がネットワークへ送る時 | 外側トランザクション、実行者、EOAノンス、ガス、チェーン | Safe内部呼び出しの成功、署名内容の妥当性 | Safe v1.5.0の`getTransactionHash`へ渡す項目は次の10個です。 ```text to, value, data, operation, safeTxGas, baseGas, gasPrice, gasToken, refundReceiver, nonce ``` どれか1つが変われば別のSafeトランザクションです。SafeアドレスとチェーンIDもEIP-712ドメインへ入るため、別Safe・別チェーンのハッシュへ署名を流用できません。[公開検証JSON](/fixtures/safe-transaction-6030.json)は、架空Safe `0x0000…5000`、チェーンID 31337、Safeノンス7を固定し、値41と42の提案が異なる`safeTxHash`になることをオフライン計算しています。 生成器は秘密鍵、ウォレット、RPC、署名、トランザクションを使いません。 Transaction Serviceの`safeTxHash`がある場合も、取得したトランザクション項目と対象Safeの`getTransactionHash`から再計算して一致を確認します。見た目が同じ送金先や数量でも、データ、操作、`refundReceiver`、ノンスが違えば同じハッシュではありません。 ## Safeノンスと実行者のEOAノンスを分ける Safeノンスは、Safeが所有者の承認を受けたトランザクションを順序付けし、再利用を防ぐ値です。実行者EOAノンスは、外側トランザクションを送るアカウント自身のネットワークノンスです。同じ`7`と表示されても、所属するアカウントと役割が違います。 同じSafeノンスNを使う提案AとBが別ハッシュになり、Aの実行後はN+1となってBの元署名が無効になる図 同じSafeノンス`N`で提案AとBが作られることはあります。AとBはデータが異なるので`safeTxHash`も別です。Aが先に成功するか、Safeが失敗を捕捉してノンスを消費すると、現在のSafeノンスは`N + 1`になります。 Bへ集めた署名はノンス`N`のハッシュへ固定されているため、そのまま`N + 1`へ付け替えられません。 UIの「拒否」「置換」は、元提案を消去する魔法ではありません。どのSafeトランザクションがどのノンスを使い、どのハッシュがチェーン上で実行され、現在ノンスがいくつになったかを確認します。新しいノンスへ内容を移すなら新しい`safeTxHash`となるため、所有者は新しい全項目を再確認します。 実行者側で`nonce too low`が出た場合は、Safeノンスではなく実行者EOAの保留中トランザクション競合かもしれません。外側送信者、EOAノンス、置換手数料、Ethereumトランザクションハッシュを別列で調べます。 ## 所有者・必要署名数・モジュール・保護機構・バージョンを読み取り専用で確認する UIやTransaction Serviceのキャッシュより先に、対象ブロックのSafeコントラクトを読み取り専用で確認します。RPC、ブロックエクスプローラーの検証済みコントラクト読み取り、または監査済みスクリプトを使い、ウォレット接続や書き込み方法は不要です。 | 対象 | Safe v1.5.0で読む入口 | 注意点 | | --- | --- | --- | | バージョン | プロキシ経由の`VERSION()` | 実装が違えば挙動を一般化しない | | 所有者 | `getOwners()` | 表示名ではなくアドレスを保存 | | 必要署名数 | `getThreshold()` | 承認数と同じ時点で読む | | Safeノンス | `nonce()` | 提案のノンスと現在値を分ける | | モジュール | `getModulesPaginated(0x…01, pageSize)` | センチネルからページ分割し、全ページを確認 | | トランザクション保護機構 | `getStorageAt(GUARD_STORAGE_SLOT, 1)` | v1.5.0は公開読み取り関数を持たない | | モジュール保護機構 | `getStorageAt(MODULE_GUARD_STORAGE_SLOT, 1)` | 所有者トランザクション保護機構とは別 | | 実装 | Safeプロキシの`masterCopy()`またはストレージスロット0 | 対象プロキシ型を公式ソースで固定 | Safe v1.5.0のトランザクション保護機構スロットは次です。 ```text 0x4a204f620c8c5ccdca3fd54d003badd85ba500436a431f0cbda4f558c93c34c8 ``` モジュール保護機構スロットは次です。 ```text 0xb104e0b93118902c651344349b610029d694cfdec91c589c91ebafbcd0289947 ``` `getStorageAt(uint256(slot), 1)`が返す32バイトの末尾20バイトをアドレスとして読みます。これらは特定のコミットへ固定したSafe v1.5.0の公式ソースで確認した値です。別バージョンへ無条件に流用しません。 保護機構やモジュールを「確認のため」に無効化・交換しないでください。設定変更自体が所有者の承認を必要とする書き込みであり、資産制御の境界を変えます。 モジュールは、通常の所有者承認とは別の`execTransactionFromModule`経路を使えます。有効なモジュールが実行したトランザクションでは、通常提案の承認数を原因にしません。呼び出し元モジュール、モジュール保護機構、モジュールイベント、実行履歴を確認します。 悪意あるモジュールは任意実行につながり得るため、名称やUIアイコンではなくアドレス、コード、設定トランザクションを記録します。 ## 失敗を止まった場所で分類する 必要署名数の不足、ノンス競合、保護機構拒否、対象のrevert、Transaction Service遅延を、止まる場所、Safeノンス、次に読む証拠で分ける表 ### 必要署名数の不足・無効な所有者・署名順序 Safeはノンスを後置インクリメントしてから署名検証へ進みますが、署名検証が`revert`すれば外側呼び出し全体が巻き戻るため、Safeノンスは消費されません。次を同じブロックと`safeTxHash`で確認します。 - 現在の所有者と必要署名数 - 各署名から復旧した所有者、またはコントラクト署名所有者 - 署名が同じ`safeTxHash`へ対応するか - EOA署名が所有者アドレス昇順か - 事前検証済み署名やERC-1271など署名型の解釈 件数だけ合わせるために追加署名を依頼せず、まず既存署名がどのハッシュへ対応するかを固定します。 ### トランザクション保護機構拒否 トランザクション保護機構は`execTransaction`の対象呼び出し前後で検査を実行できます。事前検査が`revert`すると対象は呼ばれず、外側の呼び出しも`revert`するためノンスの増分も巻き戻ります。保護機構の`revert`データ、アドレス、コードバージョン、遮断条件を保存します。 保護機構を外せば通るという案内はしません。Safe公式も、壊れた保護機構や悪意ある保護機構がトランザクションをブロックできると注意しています。保護機構変更はSafe自身からの認可済み呼び出しが必要で、別の運用・セキュリティレビューです。 ### 対象の`revert`と`ExecutionFailure` 署名と保護機構を通過しても、対象コントラクトが`revert`する場合があります。Safe v1.5.0では署名済みガス項目により外側結果が変わります。 - `safeTxGas > 0`または`gasPrice > 0`で対象失敗をSafeが捕捉した場合、`execTransaction`は`false`を返して`ExecutionFailure`を発行し、Safeノンスは消費されます - `safeTxGas == 0`かつ`gasPrice == 0`では対象の失敗をそのまま返すため、外側のトランザクションが`revert`し、Safeノンスの増分も巻き戻る したがって「対象の`revert`ならノンス未消費」「実行結果成功ならSafe成功」のどちらも一般化できません。署名済み項目、Safeイベント、実行履歴、現在ノンスを一緒に読みます。 対象の`revert`はSafeではなく、対象側の利用許可額、役割、有効期限、許容価格差、停止状態、呼び出しデータ、値、`DELEGATECALL`の文脈などが原因の場合があります。`revert`データと実行履歴を保存し、同じ呼び出しを実資産環境で闇雲に再実行しません。 ### 実行ガス・返金・リレイヤー `safeTxGas`、`baseGas`、`gasPrice`、`gasToken`、`refundReceiver`は`safeTxHash`に含まれます。画面でガス見積もりだけを更新したつもりでも、署名済みSafeトランザクションが変わる場合があります。 `gasPrice > 0`ならSafeは実装の計算に基づき返金を試みます。ネイティブ通貨やトークンによる返金が失敗すると、外側の実行も`revert`し得ます。実行者が払うネットワーク手数料、Safeが設定に基づき返す金額、リレイヤーサービスの料金は別項目です。 `refundReceiver`や`gasToken`を推測で変えず、署名対象項目、Safe残高、トークンの挙動、外側の実行結果を確認します。 ## Transaction Service表示とチェーン上状態がずれる場合 Safe Transaction Serviceはチェーン外提案と承認数を提供し、チェーンの実行履歴やイベントを索引します。便利な調整層ですが、Safeコントラクトそのものではありません。索引サービス遅延、未対応チェーン、実行履歴取得失敗、チェーン再編、サービス接続先の違いにより、一時的に表示とチェーン状態がずれる可能性があります。 次の順で照合します。 1. RPCでチェーンID、Safeコード、実装、バージョンを固定する 2. 所有者、必要署名数、現在のSafeノンス、モジュール、保護機構を同じブロックで読む 3. サービス応答のトランザクション項目から`safeTxHash`を再計算する 4. 実行トランザクションハッシュがあればRPCでトランザクションと実行結果を取得する 5. Safeイベントと実行履歴を読み、対象呼び出しの成功 / `revert`を確認する 6. 最後にTransaction Serviceの索引処理状態、応答時刻、再取得結果を比較する サービスに提案がないことは、チェーン上実行がなかった証拠ではありません。反対に、サービスに承認数が揃っていることも、実行済みの証拠ではありません。**チェーン上状態を先に固定し、Transaction Serviceの状態は最後に照合すること**が切り分けの基準です。 ## ローカル2-of-3で再現した結果 公式`@safe-global/safe-smart-account@1.5.0`をローカルFoundryチェーンへデプロイし、公開された検証専用キーだけを使って次の条件を再現しました。外部RPCやウォレットへは接続していません。 | 条件 | ローカル実行の結果 | | --- | --- | | 2-of-3 | 所有者2名の並べ替え済みECDSA署名で対象状態を更新し、Safeノンスが1進む | | 必要署名数の不足 | 1署名で`revert`し、対象状態とSafeノンスは変わらない | | 無効所有者 | 所有者 + 外部者で`revert`し、Safeノンスは巻き戻る | | ノンス競合 | 同じノンスのAを実行後、Bの元署名は現在ノンスと合わず実行できない | | 対象の`revert` | ゼロでない`safeTxGas`で`false`を返し、対象状態は変わらずSafeノンスは進む | | 保護機構拒否 | Safe自己呼び出しで設定した保護機構が対象前に`revert`し、Safeノンスは巻き戻る | 同じローカル実行でトランザクション保護機構を公式ストレージスロットから読み取り専用確認し、モジュール一覧が空であること、`VERSION()`が`1.5.0`であることも確かめました。この結果はSafe v1.5.0の限定条件を再現したもので、任意のSafe、モジュール、保護機構、対象、リレイヤーで同じ結果を保証しません。 ## サポート・運用担当へ渡すパッケージ 問い合わせには、画面記録だけでなく次の機械可読な値を渡します。シードフレーズ、秘密鍵、署名データ全体を公開の問い合わせ欄へ貼りません。 - チェーンID、Safeアドレス、実装アドレス、Safeバージョン、確認ブロック - 所有者、必要署名数、現在のSafeノンス - 提案の全トランザクション項目と`safeTxHash` - 署名者アドレスと各承認の確認時刻。署名本体は必要性と安全な共有先を確認する - 実行時のEthereumトランザクションハッシュ、外側送信者、EOAノンス、実行結果、Safeイベント、実行履歴、`revert`データ - モジュール、トランザクション保護機構、モジュール保護機構、フォールバックハンドラー - Transaction Service接続先、応答、索引処理状態、取得時刻 - 期待した結果と実際の結果、最初に不一致になった段階 この順に揃えると、「署名が足りない」「同じノンスの別提案が先に進んだ」「保護機構が拒否した」「対象が`revert`した」「サービス表示だけ遅れている」を混ぜずに相談できます。`safeTxHash`とEthereumトランザクションハッシュ、Safeノンスと実行者EOAノンスを別欄にすることが、再署名や再実行を判断する前提です。 ## 最終チェック 1. チェーンID、Safeアドレス、実装、`VERSION()`を固定した 2. 所有者、必要署名数、Safeノンス、モジュール、トランザクション保護機構、モジュール保護機構を同じブロックで読んだ 3. 提案の全項目から`safeTxHash`を再計算した 4. 承認数が同じハッシュと現在の所有者へ対応することを確認した 5. 競合提案ごとにノンスと`safeTxHash`を分けた 6. 実行トランザクションハッシュ、実行者EOAノンス、実行結果、Safeイベント、実行履歴を保存した 7. 対象の`revert`、保護機構拒否、返金失敗、サービス遅延のどこで止まったかを分類した 8. 原因確定前の再署名、再提案、モジュール・保護機構変更、資産操作を止めた この8項目が揃うまで、UIの状態だけを根拠に「署名を追加すれば進む」「拒否すれば置換できる」「もう一度実行すれば直る」と判断しません。 ## 確認した一次情報 - [Safe Transaction Service API overview](): 確認日 2026-08-31 - [Safe off-chain transaction guide](): 確認日 2026-08-31 - [Safe Protocol Kit transaction signatures](): 確認日 2026-08-31 - [Safe Protocol Kit transaction execution](): 確認日 2026-08-31 - [Safe Smart Account guard tutorial](): 確認日 2026-08-31 - [Safe Smart Account v1.5.0 release](): 確認日 2026-08-31 - [Safe.sol at pinned v1.5.0 commit](): 確認日 2026-08-31 - [GuardManager.sol at pinned v1.5.0 commit](): 確認日 2026-08-31 - [ERC-1271 contract signature validation](): 確認日 2026-08-31 --- # DAppを切断しても権限は消えない？利用許可・セッション鍵・委任解除を比較 DAppの切断、SIWEのログアウト、ERC-20・Permit2の利用許可取り消し、スマートアカウントのモジュール、EIP-7702委任解除を、保存場所と確認方法から分けます。 正規URL: https://3mikan.com/archives/6031 著者: みかん 公開: 2026-08-31T01:50:00.000Z 更新: 2026-09-02T05:35:00.000Z DAppの画面で「切断（Disconnect）」を押しても、トークンの`allowance`、サーバーのログインセッション、スマートアカウントのモジュール、EIP-7702委任まで一括で消えるとは限りません。これらは保存場所も、読む方法も、失効に必要な操作も別だからです。 最初に確認するのは、ボタンの表示ではなく、**どのチェーン・アカウント・オリジン・コントラクトに、どの権限層が残っているか**です。緊急時に未知の取り消しサイトへ接続したり、検索結果やDMから追加署名を求められたりしても応じません。この記事の確認途中には広告やアフィリエイト販売誘導を置いていません。 ## 先に固定する値 操作を増やす前に、調査メモへ次を保存します。 - ウォレット名とバージョン、ブラウザープロフィール、サイトオリジン - アカウントアドレス、チェーンID、確認ブロック、RPCまたはブロックエクスプローラー - トークン、Permit2、スマートアカウント、モジュール、委任先実装のアドレス - 元の利用許可・モジュール追加・委任設定トランザクションが分かる場合はトランザクションハッシュ - 切断、ログアウト、取り消し、モジュール削除、委任変更を行った時刻 同じアドレス文字列でもチェーンが違えば別状態です。ウォレットのアカウント権限はオリジン単位、ウェブセッションはドメイン・Cookie・サーバー単位、利用許可額はトークンコントラクトと`owner / spender`単位で確認します。アドレスやチェーンが固定できない状態で書き込み操作へ進みません。 ## 「接続」は六つの層に分ける ブラウザーのサイト権限、サーバー側セッション、トークン利用許可額、Permit2、スマートアカウントモジュール、EIP-7702委任が別の保存先にあり、それぞれ個別に確認・失効する図 以下は「切断」という一語を、保存場所・読み取り専用確認・失効方法・トランザクション要否へ分解した比較です。ウォレットやアカウント実装によって方法名は変わるため、対象バージョンの公式手順を優先します。

サイト / アカウント権限

保存
ウォレット・ブラウザーのオリジン別権限
確認
ウォレットの接続済みサイト、対応ウォレットではwallet_getPermissions
失効
公式UIで切断 / 権限を削除
トランザクション
通常不要
切断
この層が対象

SIWE / ウェブセッション

保存
サーバー側セッション、Cookie、トークンなど
確認
サイトのアカウント / セッション画面と認証済み接続先
失効
ログアウト、サーバー側無効化、有効期限
トランザクション
不要
切断
サイト実装次第で残る

ERC-20利用許可額

保存
トークンコントラクトの所有者 / 利用先状態
確認
allowance(owner, spender)
失効
対象トークンで利用先の利用許可額を0へ更新
トランザクション
チェーン上トランザクションが必要
切断
消えない

permit / Permit2

保存
署名はチェーン外、使用後の利用許可額・ノンス等はコントラクト
確認
ノンス、有効期限、数量、利用先、トークン→Permit2利用許可額
失効
方式固有の取り消し、ノンス無効化、有効期限
トランザクション
方式と状態による
切断
消えない

セッション鍵 / モジュール

保存
スマートアカウント、モジュール、バリデーター、ポリシーコントラクト
確認
対象実装の読み取り関数、モジュール一覧、設定イベント
失効
アカウントから無効化・削除・交代を実行
トランザクション
通常チェーン上トランザクション
切断
消えない

EIP-7702委任

保存
EOAのコードとして委任指標、関連状態はEOAストレージ等
確認
eth_getCodeと委任先アドレス、ストレージ・ノンス
失効
ゼロアドレスへ解除、または別実装へ変更する認可
トランザクション
type 0x04トランザクションが必要
切断
消えない
## ウォレットのサイト権限はアカウント公開範囲の管理 EIP-2255は、オリジンからウォレット権限を要求・取得するインターフェースを定義します。MetaMaskでは`wallet_getPermissions`で現在オリジンへ許可された権限を取得でき、ブラウザー拡張機能では`wallet_revokePermissions`で現在オリジンの権限を一件ずつ取り消せます。これはウォレット固有の対応状況を確認して使う仕組みで、全ウォレットに同じAPIがあるとは限りません。 接続済みサイトを外すと、そのサイトからアカウントへアクセスする権限は止められます。しかし、過去に送信済みのトランザクションを巻き戻したり、トークンコントラクトの利用許可額を更新したりはしません。[トークンの利用許可を確認・解除する基礎手順](/archives/6007)でも、接続とチェーン上利用許可を別に扱っています。 確認後は、ウォレットの接続済みサイト一覧を再読み込みし、対象オリジンとアカウントが消えたことを確認します。ブラウザープロフィールやウォレットが複数ある場合は、操作したものを記録します。 ## SIWEの署名とログインセッションは別 ERC-4361のSign-In with Ethereumは、アドレスでチェーン外認証を行うメッセージ形式です。署名検証後にCookieやサーバー側セッションをどう作り、いつ無効にするかはサービス側の実装です。ウォレットを切断しても、すでに作成されたサーバー側セッションが自動ログアウトされる保証はありません。 サイトの公式ログアウトを行い、認証済み接続先が未認証へ変わったこと、セッション一覧がある場合は対象端末が消えたこと、Cookieやトークンの有効期限が想定どおりであることを確認します。署名メッセージのドメイン、URI、チェーンID、ノンス、発行時刻、有効期限を読む方法は[SIWEのドメイン・ノンス・セッションを確認する手順](/archives/6019)を参照してください。 ログアウト後もサーバー側セッションが有効なら、ウォレット権限ではなくサービスのセッション無効化問題としてサポートへ渡します。シードフレーズや秘密鍵をサポートへ送る必要はありません。 ## ERC-20利用許可はトークンコントラクトの状態 ERC-20の`approve(spender, value)`は、トークンコントラクトに所有者と利用先の利用許可額を保存します。`allowance(owner, spender)`で現在値を読み取り専用確認でき、利用先は範囲内で`transferFrom`を呼べます。サイトの接続を外してもこの対応表は変わりません。 解除する場合はチェーン、トークンコントラクト、所有者、利用先を再確認し、対象トークンコントラクトで利用許可額を0へ更新します。ウォレットやブロックエクスプローラーの「Revoke」ラベルではなく、送信先が正しいトークンコントラクトで、呼び出しデータの利用先と値が意図どおりか確認します。トークン実装やUIによって操作手順が異なるため、公式ウォレットまたはプロトコルの案内へ戻ります。 ブロック採用後は次を一件の証拠として保存します。 1. トランザクションハッシュ、チェーンID、ブロック番号 2. 実行結果の状態と実際の`to` 3. `Approval`ログの所有者、利用先、値 4. 確定後の`allowance(owner, spender)` 実行結果が成功でも、別トークン・別利用先を更新していれば目的の権限は残ります。最後の読み取りが0になったかを確認します。 ## `permit`とPermit2は署名・ノンス・利用許可額を分ける ERC-2612の`permit`署名は、作成しただけではチェーン状態を変えません。第三者が期限内に正しいノンスでトランザクションへ載せ、`permit`が成功すると利用許可額が更新され、所有者のノンスが1進みます。未使用署名をウォレット切断だけで無効化する標準方法はありません。 期限、現在ノンス、利用先、値、対象トークンを確認し、そのトークン実装の公式手順に従います。 Permit2は二つの経路を持ちます。 - AllowanceTransfer: トークンからPermit2コントラクトへの利用許可と、Permit2内のトークン・利用先別利用許可額、数量、失効時刻、ノンスを分ける - SignatureTransfer: 署名ノンスを使う一回限りの送金権限。未使用ノンスの無効化方法は公式実装で確認する Permit2内の利用先利用許可額だけを0にしても、トークン→Permit2コントラクトのERC-20利用許可額が別に残る場合があります。反対に、トークン→Permit2利用許可を変えても、保存済みPermit2記録の意味を調べずに「すべて失効」と断定しません。[ERC-20・許可・Permit2の権限境界](/archives/6012)で、署名時点とチェーン上反映時点をさらに分けています。 ## スマートアカウントのセッション鍵・モジュールは実装固有 セッション鍵は一つの共通規格名ではありません。鍵のアドレス、有効期間、対象、関数識別子、利用上限などがスマートアカウント本体、バリデーター、モジュール、ポリシーコントラクトのいずれかへ保存されます。まずアカウント実装とバージョンを固定し、公式ソースや文書から正しい読み取り関数と無効化経路を特定します。 Safeのモジュールはアカウント内の登録簿で有効化され、モジュール経路からトランザクションを実行できます。通常の所有者トランザクションとは別の認可経路になり得るため、ウォレットサイトを切断しただけでは無効になりません。モジュールアドレス、コード、有効状態、保護機構やポリシー、追加トランザクションを確認し、削除は所有者の承認を必要とするトランザクションとして扱います。 解除後は、無効化 / 削除トランザクションの実行結果とイベントだけでなく、同じブロック以後の読み取り関数やページ分割されたモジュール一覧で、対象アドレスが無効になったことを確認します。セッション鍵ならキーの有効フラグ、有効期限、権限記録を再読します。UIから行が消えただけではチェーン状態の証拠にしません。 ## EIP-7702委任はEOAのコード状態 EIP-7702では、認可者EOAのコードが`0xef0100 || address`という23バイト委任指標になり、呼び出し時に指定実装のコードがEOA文脈で実行されます。有効な認可が処理されると委任はトランザクション実行結果とは独立して永続です。サイトを切断しても`eth_getCode`は変わりません。 解除は、認可者EOAがゼロアドレスを対象にした認可をtype 0x04トランザクションへ含め、委任指標を解除する手順です。別実装への変更は解除ではありません。チェーンID、認可者EOAとそのノンス、委任先アドレス、認可を載せるトランザクションを確認し、対象ウォレットが公式に対応する方法だけを使います。 解除後は十分に確定したブロックで`eth_getCode(authority)`を再取得します。ただし、委任を解除してもEOAストレージ、トークン利用許可額、セッション鍵記録、サーバー側セッションは同時には消えません。[EIP-7702の設定・変更・解除とストレージライフサイクル](/archives/6017)で、委任コードとEOA側状態が独立して残るローカル再現を確認できます。 ## ローカル環境で切断後の残存を再現 Foundryのローカルチェーンを使い、外部RPC・ウォレット・実資産へ触れずに、チェーンID 31337で次を再現しました。 | ローカル段階 | サイト接続 | トークン利用許可額 | セッション鍵 / モジュール | EIP-7702コード | | --- | --- | ---: | --- | --- | | 設定完了 | 接続済み | 250 | 有効 | 委任先A | | 切断直後 | 切断済み | 250 | 有効 | 委任先A | | 利用許可額取り消し後 | 切断済み | 0 | 有効 | 委任先A | | セッション/モジュール無効化後 | 切断済み | 0 | 無効化 | 委任先A | | 委任解除後 | 切断済み | 0 | 無効化 | 空 | このローカル再現では、切断はチェーン外の接続状態だけを`false`へ変えます。その直後もトークンコントラクトの`allowance`、認可者EOAのストレージにあるセッション鍵・モジュールフラグ、EOAコードの委任指標が残りました。その後、各層の明示的な状態変更だけが対応する状態を変え、他層を自動変更しないことも確認しました。 [公開検証JSON](/fixtures/dapp-permission-boundaries-6031.json)には、使用した架空アドレス、各段階の期待状態、読み取り方法、失効後の確認項目を掲載しています。公開された検証専用キーだけを使い、実在ウォレット、外部RPC、署名確認画面、資産移動は使っていません。 ## 解除後は実行結果と状態を組にする 対象権限の保存先を読み、公式の失効操作を一つだけ行い、実行結果またはログアウト結果と同じ保存先の状態を再確認する手順 権限ごとに次の順を繰り返します。 1. チェーン、アカウント、オリジン、コントラクト、利用先または委任先を固定する 2. 書き込み前の状態を読み取り専用で保存する 3. 対象実装の公式手順で一つの層だけ失効する 4. トランザクションならハッシュ、実行結果、イベント、確定ブロックを保存する。ログアウトなら応答とセッション再確認を保存する 5. 同じ保存先をもう一度読み、期待する値へ変わったことを確認する 6. 他層も再読し、残存権限を次の調査対象へ回す 判断基準は、**切断の完了表示ではなく、各権限層の保存先を読み取り専用で再確認すること**です。複数の取り消しをまとめて送る前に、どの操作がどの状態を変えるかを一行ずつ対応させます。 ## 署名要求が出たときの停止条件 取り消し、無効化、解除という名称でもトランザクションや型付きデータ署名を要求する場合があります。次に該当すれば署名せず停止します。 - チェーン、検証コントラクト、トークン、利用先、委任先、モジュールが記録した値と違う - 無制限の数量、未知の一括呼び出し、`delegatecall`、モジュール追加など解除と逆方向の権限が含まれる - 公式ドメインやウォレット内導線ではなく、検索広告、DM、遠隔サポートから開いた - シードフレーズ、秘密鍵、画面共有、遠隔操作、先払いを要求される - トランザクションのシミュレーションと呼び出しデータの意味を説明できない 型付きデータのドメイン、チェーンID、コントラクト、ノンス、有効期限、利用先を読む手順は[危険な署名要求を見分ける確認項目](/archives/6025)を参照してください。実際の不正送金やシード侵害が疑われる場合は、取り消しだけで解決すると判断せず、追加署名を止めて証拠を保存し、ウォレット・プロトコル・取引所の公式窓口へ相談します。 署名鍵をハードウェアウォレットへ移しても、すでに残る利用許可額、Permit2、セッション鍵、モジュール、委任、サーバー側セッションは自動では消えません。新しい端末を選ぶ段階では[EVM向けハードウェアウォレット5機種の比較](/archives/6034)を使い、`approve`とEIP-712で利用先、数量、チェーンID、検証コントラクトを端末上で確認できる運用を条件にしてください。 ## 確認項目 - [ ] ウォレットのオリジン別サイト権限を確認した - [ ] サイトのログアウト後にサーバー側セッションを再確認した - [ ] トークンコントラクトごとに所有者・利用先・利用許可額を読んだ - [ ] Permit / Permit2のノンス、失効時刻、数量、二段階の利用許可額を分けた - [ ] スマートアカウント実装、モジュール、セッション鍵、方針を特定した - [ ] EIP-7702認可者EOAのコード、委任先、ノンス、ストレージを確認した - [ ] 状態を変更する操作の前後でチェーン・アドレス・ブロックを保存した - [ ] 実行結果・イベントだけでなく対象状態を再読した - [ ] シードフレーズや秘密鍵を入力・共有していない - [ ] 残る別層を「切断済み」という表示だけで安全と判断していない 切断、ログアウト、利用許可額の取り消し、Permitの無効化、モジュールの無効化、委任解除は、それぞれ別の操作です。一つのボタンへ期待を集めず、保存場所ごとに「読む→一つだけ失効→同じ場所を再読する」を繰り返してください。 ## 確認した一次情報 - [ERC-20 Token Standard](): 確認日 2026-08-31 - [ERC-2612 permit extension](): 確認日 2026-08-31 - [ERC-4361 Sign-In with Ethereum](): 確認日 2026-08-31 - [EIP-2255 wallet permissions](): 確認日 2026-08-31 - [EIP-7702 account code delegation](): 確認日 2026-08-31 - [MetaMask wallet\_getPermissions reference](): 確認日 2026-08-31 - [MetaMask wallet\_revokePermissions reference](): 確認日 2026-08-31 - [MetaMask token approval revocation guidance](): 確認日 2026-08-31 - [Uniswap Permit2 official repository](): 確認日 2026-08-31 - [Safe Smart Account modules](): 確認日 2026-08-31 --- # Ethereum RPCエラーを層別に直す｜4001・429・-32602・ノンス・revert Ethereum RPCエラーを、ウォレットプロバイダー、HTTP、JSON-RPC、ノード、トランザクション、EVMに分類します。viemの原因の連鎖と元の応答を対応させ、安全な再試行と修正手順を解説します。 正規URL: https://3mikan.com/archives/6032 著者: みかん 公開: 2026-08-31T03:00:00.000Z 更新: 2026-09-02T05:35:00.000Z `4001`、`429`、`-32602`、`nonce too low`、`execution reverted`を、すべて「RPCエラー」として同じ再試行へ流してはいけません。発生した場所が違えば、直す対象も違います。 最初に保存するのは、RPCメソッド、引数の形、チェーンID、ブロック、HTTPステータス、JSON-RPCのコード・メッセージ・データ、viemのエラー名と原因、トランザクションハッシュです。APIキー、Cookie、署名済みトランザクションの生データ、個人情報は保存しません。 この記事では、ウォレットプロバイダー、HTTP通信、JSON-RPCプロトコル、ノードまたはゲートウェイの制約、トランザクション検証、EVM実行へ分けます。2026-08-31時点のviem 2.56.0、Foundry 1.8.0、Anvil 1.8.0を使い、外部ウォレットや公開RPCを使わないローカル環境で12種類の応答と独自エラーを確認しました。 ## エラーを7層へ置く 画面へ最後に表示されたメッセージは、もっと内側のエラーを包んでいることがあります。次の順で、最初に失敗した境界を探します。 アプリとviem、ウォレットプロバイダー、HTTP通信、JSON-RPC、ノード方針、トランザクション検証、EVM実行の7層。各層で保存する証拠と次の確認先を示す | 層 | 代表的な症状 | 最初に保存する証拠 | 主な次の行動 | | --- | --- | --- | --- | | アプリ / ライブラリー | `ChainMismatchError`、ABIや型の不一致 | 操作名、ライブラリーバージョン、入力の形 | チェーン、ABI、引数を直す | | ウォレットプロバイダー | `4001`、`4100`、`4200`、`4900`、`4901` | オリジン、メソッド、プロバイダーコード、選択チェーン | 利用者操作、許可、対応メソッドを確認 | | HTTP通信 | DNS、TLS、タイムアウト、`429`、`5xx` | URLのホスト、状態、`Retry-After`、経過時間 | 待機、範囲縮小、限定的な代替接続先 | | JSON-RPC | `-32601`、`-32602`、`-32603` | 要求ID、メソッド、引数、エラーオブジェクト | メソッド・引数修正、内側のエラー確認 | | ノード / ゲートウェイ | `-32005`、履歴不足、ペイロード制限 | クライアント、契約プラン、ブロック範囲、メッセージ、データ | 範囲縮小、必要なノード機能を選ぶ | | トランザクション検証 | 資金、手数料、ノンス、置換 | 送信者、ノンス、残高、手数料、既存ハッシュ | 同じ入力の連打を止めて状態を直す | | EVM実行 | `revert`、ガス不足、独自エラー | 呼び出しデータ、`revert`データ、シミュレーション時のブロック、トランザクションレシート | 識別子と引数を復号し、コントラクト条件を直す | コードだけで層を断定できない場合もあります。たとえば`-32000`はEIP-1474で無効入力ですが、ノード実装はメッセージへ`insufficient funds`などを入れることがあります。コード、メッセージ、データ、呼び出した操作を組にしてください。 ## 最初の30秒で要求を識別できる情報を固定する 再現前に、次を一件の記録へまとめます。 1. 操作名と実行時刻 2. RPCメソッドと、秘密値を除いた引数の形 3. チェーンID、ブロック番号またはタグ、対象アドレス 4. HTTP状態、`Retry-After`、経過時間 5. JSON-RPCコード、メッセージ、データの型 6. viemの最上位エラー名、`shortMessage`、`details`、原因名 7. トランザクションを送った可能性がある場合はハッシュ、送信者、ノンス メソッドと引数を保存せずメッセージだけを見ると、同じ`InvalidParamsRpcError`でも「アドレスの形式」「ブロック数量の形式」「引数の個数」を区別できません。反対にHTTPヘッダーの生データを丸ごと保存すると、APIキーやCookieを漏らす危険があります。必要な項目を先に決め、値ではなく形式だけ残す項目を分けます。 ## ウォレットプロバイダーの4001・4100・4200・4900・4901 [EIP-1193](https://eips.ethereum.org/EIPS/eip-1193)は、プロバイダーが返す代表的なコードを定義しています。 | コード | 意味 | 自動再試行 | 読者へ伝える内容 | | ---: | --- | --- | --- | | `4001` | 利用者が要求を拒否 | しない | キャンセル済み。必要なら本人がもう一度開始する | | `4100` | メソッドまたはアカウントが未承認 | しない | オリジンとアカウントの許可を確認する | | `4200` | プロバイダーがメソッド非対応 | しない | 対応確認または別の実装経路が必要 | | `4900` | すべてのチェーンから切断 | 接続回復後だけ | プロバイダーの接続状態を確認する | | `4901` | 指定チェーンだけ未接続 | しない | 意図したチェーンを確認し、明示的に選択する | `4001`を「RPCが不安定」と扱って自動でウォレットポップアップを再表示すると、利用者の拒否を無視します。`4200`も時間経過ではメソッド対応になりません。`4901`では、アプリが別チェーンへ勝手に目的を変えず、要求したチェーンと現在チェーンを表示します。 チェーンの値がアプリ設定とウォレットクライアントで違う`ChainMismatchError`は、プロバイダーへ要求が届く前にライブラリーが止める場合があります。このときはHTTP状態を探すのではなく、設定したチェーン、ウォレットが選んだチェーン、署名対象チェーンを比較します。 ## HTTP 429・タイムアウト・5xxは送信結果を先に分ける HTTP `429 Too Many Requests`は、一定時間の要求数が多すぎることを示します。[RFC 6585](https://www.rfc-editor.org/rfc/rfc6585.html#section-4)では、サーバーは待機時間を`Retry-After`で示せます。 読み取りメソッドなら、`Retry-After`を優先し、上限付きの指数バックオフとジッターを使えます。たとえば待機を1秒、2秒、4秒へ増やし、最大回数と全体タイムアウトを決めます。全クライアントが同時に再試行するのを避けるため、待機時間へ小さな乱数を加えます。 しかし`eth_sendRawTransaction`のタイムアウトは別です。応答を受け取れなくても、ノードがトランザクションを受理した可能性があります。同じ署名済みトランザクションならハッシュを手元で導出し、まず`eth_getTransactionByHash`と送信者の保留中ノンスを確認します。 別ノンスや別署名を作って即送信すると、重複意図や置換競合を増やします。 | 状況 | 同じ要求の再試行 | 先に行う確認 | | --- | --- | --- | | `eth_blockNumber`がタイムアウト | 上限付きで可 | 接続先、経過時間、チェーンID | | `eth_getLogs`が429 | 範囲縮小後に可 | `Retry-After`、開始 / 終了ブロック、件数制限 | | `eth_call`が503 | ブロック固定後に可 | チェーン、ブロック、呼び出しデータ、代替接続先との差 | | `eth_sendRawTransaction`がタイムアウト | 即時は不可 | 導出ハッシュ、保留中ノンス、既存トランザクション | | ウォレット署名要求がタイムアウト | 自動表示しない | ウォレット側の未完了要求と利用者操作 | 代替接続先を使う場合も、チェーン、ブロック、メソッド、引数を変えません。別接続先で値が違うときのブロック固定方法は[Ethereum RPCの`latest`・履歴・Multicallを比較する記事](/archives/6024)で確認できます。 ## JSON-RPCのエラーコード -32601・-32602・-32603 [EIP-1474](https://eips.ethereum.org/EIPS/eip-1474)はEthereum RPCのエラーオブジェクトにコードとメッセージを含めるよう求め、JSON-RPCの標準コードを採用しています。 - `-32601 Method not found`: メソッド名が存在しない、または接続先が公開していない - `-32602 Invalid params`: 引数の個数、順序、型、16進数符号化などが不正 - `-32603 Internal error`: JSON-RPC処理内の内部エラー `-32601`と`-32602`は、同じ内容を待って再送しても通常は直りません。メソッド名の綴り、クライアントの対応、アドレス、数量とデータの16進数規則、ブロック識別子、引数の順序を直します。 `-32603`は一時的な場合がありますが、先に未加工エラーの`data`と内側のメッセージを保存します。コントラクトの`revert`をゲートウェイが内部エラーへ包む実装もあるため、「ノード障害」と断定して再試行する前に`revert`データがないか確認します。 ```json { "jsonrpc": "2.0", "id": 17, "error": { "code": -32602, "message": "Invalid params", "data": { "field": "params[0]" } } } ``` 要求IDは応答との対応に使います。一括処理応答は送信順と同じとは限らないため、配列位置ではなくIDで結合します。 ## ノード側の制約はゲートウェイと実行クライアントを分ける `-32005 Limit exceeded`、広すぎる`eth_getLogs`、古い状態への履歴制限、ペイロードサイズ制限は、同じノード故障ではありません。プロバイダーのプラン、ゲートウェイ、負荷分散装置、実行クライアントのどこが返したかを記録します。 範囲制限ならブロック範囲を分割し、重複ブロックをIDやログ識別情報で排除します。履歴不足なら、現在の状態を読む同じ要求が成功しても、過去の状態を読める証拠にはなりません。必要な履歴深さを明示し、対応するノードまたは契約プランを選びます。 プロバイダーを切り替えるだけで万能に直るとは限りません。無効引数やコントラクトの`revert`を別プロバイダーへ繰り返せば、同じ入力を増幅するだけです。 ## 不足資金・ノンス・置換は状態を直す トランザクション検証は、EVMバイトコードを実行する前に止まる層です。go-ethereum 1.17.5のソースでも、ノンス、資金、ガス、手数料上限、トランザクションプールの置換方針は別エラーとして定義されています。 ### 不足資金 送信者残高が`value + gas limit × fee`を賄えるか確認します。トークン残高ではなく、ガスを支払うネイティブ資産の残高です。同じトランザクションを待って再送しても残高は増えません。 残高を読むブロック、値、ガス、最大手数料を揃えて再計算します。 ### `nonce too low` 指定ノンスがすでに使われた、同じトランザクションが取り込まれた、または別接続先が返す`pending`の値が遅れている可能性があります。`latest`と`pending`のトランザクション件数、既知ハッシュ、トランザクションレシートを確認します。ノンスを機械的に1増やす前に、同じ意図がすでに送られていないか調べます。 ### 置換手数料不足 同じ送信者・ノンスの保留中トランザクションを置き換えるには、ノードの置換方針を満たす手数料上昇が必要です。値はクライアントやプール方針で変わり得るため、固定率を万能値として書きません。元トランザクション、置換、同じノンス、手数料項目、ノードメッセージを対応させます。 トランザクションの入力・トランザクションレシート・イベントを調べる全体手順は[viemで失敗トランザクションを調べる記事](/archives/6001)、ガス見積もりの境界は[`estimateGas`が失敗する理由](/archives/6003)、保留中・破棄・置換済みは[トランザクション状態を判定する記事](/archives/6004)へ進んでください。 ## `execution reverted`ではEVMの戻りデータを読む `execution reverted`は、EVM実行へ到達して処理が巻き戻された状態です。HTTP 200のJSON-RPCエラーになることも、`-32603`や`-32000`へ包まれることもあります。メッセージだけでなく、`revert`データを保存します。 独自エラーなら先頭4バイトの識別子とABIからエラー名と引数を復号できます。ローカルAnvilでは`execute(3)`に対して`BelowMinimum(caller, 3, 7)`を返し、viemでは最上位の`ContractFunctionExecutionError`から原因をたどって`ContractFunctionRevertedError`と引数を取得しました。`revert`後にコントラクト状態が変わっていないことも確認しています。 `revert`データの復号手順は[`execution reverted`と独自エラーの記事](/archives/6002)を参照してください。シミュレーションが成功しても、送信時のブロック、状態、送信者、値、ガスが変われば同じ結果とは限りません。反対にシミュレーションで`revert`してもトランザクションレシートは生成されず、トランザクションがネットワークへ送信された証拠にもなりません。 ## viemでは`shortMessage`・詳細・原因を分ける viem 2.56.0ではエラーが`BaseError`を継承し、読みやすい`shortMessage`、内側の`details`、元エラーの`cause`を持ちます。最上位メッセージを正規表現だけで分類せず、クラスと原因チェーンを使います。 ```ts import { BaseError, HttpRequestError, InvalidParamsRpcError, RpcRequestError, } from 'viem' try { await client.getBalance({ address, blockNumber }) } catch (error) { if (!(error instanceof BaseError)) throw error const httpError = error.walk( (candidate) => candidate instanceof HttpRequestError, ) const rpcError = error.walk( (candidate) => candidate instanceof RpcRequestError, ) const invalidParams = error.walk( (candidate) => candidate instanceof InvalidParamsRpcError, ) audit.write({ name: error.name, shortMessage: error.shortMessage, details: error.details, httpStatus: httpError?.status, rpcCode: rpcError?.code, rpcDataShape: shapeOnly(rpcError?.data), decision: invalidParams ? 'fix-input' : 'review-layer', }) } ``` `details`にはノードメッセージが入ることがありますが、秘密値を含まない保証はありません。公開ログへ出す前に秘密情報を取り除きます。`Authorization`、Cookie、APIキー付きURL、署名済みトランザクションの生データ、秘密鍵、シードフレーズは記録しません。 ## ローカル再現で12種類の対応表を固定した Node 24.14.0とviem 2.56.0で、127.0.0.1の一時HTTPサーバーだけを使い、次を確認しました。 - プロバイダー: `4001`、`4100`、`4200`、`4900`、`4901` - HTTP通信: `429` + `Retry-After: 2`、40msタイムアウト - JSON-RPC: `-32601`、`-32602`、`-32603` - ノード方針: `-32005` - トランザクション検証メッセージ: `-32000` + `insufficient funds` たとえば`-32602`は`InvalidParamsRpcError → RpcRequestError → 元のエラーオブジェクト`、HTTP 429は`HttpRequestError`、4001は`UserRejectedRequestError → RpcRequestError → 元のエラーオブジェクト`になりました。[公開再現JSON](/fixtures/rpc-error-layers-6032.json)で、秘密情報を除いた要求、元の応答、viemエラーの連鎖、再試行分類を確認できます。 Foundry 1.8.0、Anvil 1.8.0、Solidity 0.8.36、Prague EVMでは独自エラーと巻き戻しを3例確認しました。外部ウォレット、公開RPC、実在アカウント、外部署名、実資産は使っていません。 ## 再試行・バックオフ・代替接続先の判断 要求識別情報を保存し、送信済みの可能性を判定し、エラー層を特定してから入力修正・利用者操作・限定再試行・代替接続先へ分岐する手順 1. メソッド、引数形式、チェーン、ブロック、要求IDを固定する 2. トランザクション送信済みの可能性があるか分ける 3. HTTPステータスとJSON-RPCエラーオブジェクトを別項目へ保存する 4. viemの最上位クラスと原因チェーンから失敗層を特定する 5. 利用者拒否、未対応、無効引数、資金、ノンス、`revert`は原因を直す 6. 429、タイムアウト、5xx、内部エラーは、読み取りだけ上限付きで再試行する 7. 書き込みの結果が不明ならハッシュとノンスを調べ、重複送信を防ぐ 8. 代替接続先でもチェーン、ブロック、メソッド、引数を保ち、応答差を記録する 自動再試行の対象をコード一覧だけで決めず、メソッドの副作用と「サーバーが受理した可能性」を判定してください。`eth_call`と`eth_sendRawTransaction`は、同じタイムアウトでも扱いが違います。 ## サポートログの最小項目 | 項目 | 保存例 | 秘密値への対応 | | --- | --- | --- | | `operation` | `load-position` | 内部画面名を一般化 | | `method` | `eth_call` | 保存可 | | `sanitizedParamsShape` | `{to,dataBytes,blockTag}` | 呼び出しデータ全文は必要時だけ限定保管 | | `chainId` / `block` | `1` / `finalized` | 保存可 | | `httpStatus` / `retryAfter` | `429` / `2` | 保存可 | | `rpcCode` / `rpcMessage` | `-32602` / `Invalid params` | データに個人情報がないか確認 | | `viemErrorName` | `InvalidParamsRpcError` | バージョンと組にする | | `causeNames` | クラス名の配列 | メッセージ全文より先に保存 | | `transactionHash` | 既知の場合のみ | 未加工署名済みトランザクションは保存しない | | `attempt` / `elapsedMs` | `2` / `2140` | 再試行の集中を発見する | | `decision` | `fix-input` | 実行した分岐を残す | RPCや監視サービスを比較する場合も、この分類と計測条件を広告・スポンサー表記から分離します。特定プロバイダーへの切り替えを、無効入力、ノンス競合、コントラクトの`revert`に対する万能な解決策として扱いません。 ## 確認チェックリスト - [ ] メソッドと引数形式を保存した - [ ] チェーンID、ブロック、アドレスを固定した - [ ] HTTPステータスとJSON-RPCコードを別項目で読んだ - [ ] viemの`shortMessage`、`details`、原因クラスを確認した - [ ] 4001を自動で再表示していない - [ ] 429では`Retry-After`と範囲制限を確認した - [ ] 無効引数を待機だけで再送していない - [ ] トランザクション送信結果が不明ならハッシュとノンスを先に調べた - [ ] 不足資金、ノンス、置換、`revert`を別層へ分けた - [ ] 代替接続先でもチェーン、ブロック、メソッド、引数を変えていない - [ ] APIキー、Cookie、署名済みトランザクションの生データ、秘密鍵をログへ残していない 結論は、**エラーメッセージをそのまま再試行条件にせず、元の応答とviemの原因の連鎖を対応させ、失敗した層とメソッドの副作用を見極めてから次の行動を選ぶこと**です。入力を直すエラー、利用者操作を待つエラー、限定的に再試行できるエラーを分ければ、無駄な要求と重複トランザクションを減らせます。 ## 確認した一次情報 - [EIP-1193 Ethereum Provider JavaScript API](): 確認日 2026-08-31 - [EIP-1474 Ethereum Remote Procedure Call Specification](): 確認日 2026-08-31 - [Ethereum JSON-RPC API](): 確認日 2026-08-31 - [JSON-RPC 2.0 Specification](): 確認日 2026-08-31 - [RFC 6585 429 Too Many Requests](): 確認日 2026-08-31 - [RFC 9110 idempotent methods](): 確認日 2026-08-31 - [viem errors glossary](): 確認日 2026-08-31 - [viem 2.56.0](): 確認日 2026-08-31 - [viem BaseError source at 2.56.0](): 確認日 2026-08-31 - [viem request error mapping and retry source at 2.56.0](): 確認日 2026-08-31 - [go-ethereum 1.17.5](): 確認日 2026-08-31 - [go-ethereum transaction validation errors at 1.17.5](): 確認日 2026-08-31 - [go-ethereum transaction pool errors at 1.17.5](): 確認日 2026-08-31 - [Foundry 1.8.0](): 確認日 2026-08-31 --- # 検証済みコントラクトは安全？コンパイラー・コンストラクター・プロキシまで確認 ブロックエクスプローラーの検証済みソースを安全保証と誤解せず、作成時・実行時のバイトコード、コンパイラー設定、コンストラクター、ライブラリー、メタデータ、プロキシの参照先から再検証します。 正規URL: https://3mikan.com/archives/6033 著者: みかん 公開: 2026-08-31T04:10:00.000Z 更新: 2026-09-02T05:35:00.000Z ブロックエクスプローラーに「Contract Source Code Verified」と表示されても、そのコントラクトが安全、監査済み、アップグレード不能、公式トークンという意味にはなりません。まず証明されるのは、特定のソースとビルド条件から、チェーン上のバイトコードに対応するコンパイル結果を再現できることです。 調査では、チェーン、アドレス、ブロック、実行時バイトコードを固定し、作成時バイトコード、コンパイラー、最適化設定、EVMバージョン、via-IR、ライブラリーアドレス、コンストラクター引数、メタデータを照合します。プロキシなら、プロキシ本体と現在の実装を別のコントラクトとして確認します。 この記事では2026-08-31時点の公式仕様を参照し、Foundry 1.8.0とSolidity 0.8.36で4種類の照合結果をローカル再ビルドしました。公開RPC、ウォレット、実資産、外部トランザクションは使っていません。 ## 検証済みソースが証明すること／しないこと ソースコード検証は、次の問いへ答えるための仕組みです。 > このチェーンのこのアドレスにあるバイトコードを、提示されたソースコードとコンパイル条件から説明できるか。 反対に、次は別の調査です。 - 所有者、管理者、役割、マルチシグ、タイムロックが妥当か - 誰がプロキシをアップグレードできるか - オラクル、ブリッジ、外部呼び出し、トークン会計に欠陥がないか - ソースコードが監査範囲と同じコミットか - 監査後に実装や設定が変わっていないか - 同名・同シンボルのコントラクトが公式のものか - スポンサー、広告、ブロックエクスプローラー上のバッジが信頼根拠になるか 検証済みソースは「読めるコードとデプロイ済みバイトコードの対応」を確かにしますが、ビジネスロジックの安全性を自動評価しません。トークンはシンボルではなくチェーンとコントラクトアドレスから識別するため、[トークンが表示されないときの確認手順](/archives/6029)も合わせてください。 ## 最初にチェーン・アドレス・ブロック・実行時情報を固定する 比較前に調査対象を一行へ固定します。 ```text chainId / address / blockNumber / blockHash / runtimeCodeHash ``` 同じアドレスでもチェーンが違えば別コントラクトです。プロキシはブロックによって実装が変わり得ます。`latest`のまま別の日に読み直すと、ソースではなく調査時点が変わった可能性を排除できません。 実行時バイトコードは`eth_getCode(address, block)`で取得できます。コードが空なら、チェーン・ブロック・アドレス、`selfdestruct`や作成前ブロック、EOAとの取り違えを先に確認します。ブロックエクスプローラーの表示だけを保存せず、取得した16進数とハッシュを残します。 ## 作成時バイトコードと実行時バイトコードを分ける デプロイトランザクションの入力は、通常「作成時バイトコード + ABI符号化したコンストラクター引数」です。EVMが作成時コードを実行し、返したバイトがアドレスへ保存される実行時バイトコードです。 ソースとコンパイラー設定、ライブラリーをコンパイルして作成時バイトコードを作り、コンストラクター引数を加えたデプロイ入力から実行時バイトコードを得てチェーン上コードと比較する流れ この2つを同じものとして比較すると、正しいソースでも不一致になります。 | 比較対象 | 主な内容 | 変わり得るもの | | --- | --- | --- | | 作成時バイトコード | コンストラクターを含むデプロイ用コード | コンパイラー設定、ライブラリーリンク、メタデータ | | トランザクション入力 | 作成時バイトコードの後ろにコンストラクター引数 | 所有者、初期値、ソルト以外の引数 | | 実行時バイトコード | アドレスに保存される実行コード | イミュータブル変数（`immutable`）、リンク済みライブラリー、メタデータ | | ストレージ | 実行時とは別にアドレスへ残る状態 | コンストラクター / 初期化関数、通常トランザクション | コンストラクター引数はソース本文に含まれません。Etherscanの公式エラー手引きも、コンストラクターを使う場合はデプロイ時の引数を16進数で提示する必要があると説明しています。入力末尾を推測だけで切らず、ABI型でエンコードし直して作成時バイトコードへ連結します。 ## コンパイラー条件はバージョン名だけでは足りない 再ビルドには、ソース一式とStandard JSON相当の入力を保存します。最低限、次を固定します。 1. コンパイラーの完全なバージョンとコミット 2. 最適化の有無、`runs`値、詳細設定 3. EVMバージョン 4. `viaIR`の有無 5. ソース単位名、パス、リマッピング、インポート内容 6. ライブラリーの完全修飾名とアドレス 7. メタデータの`bytecodeHash`、CBOR追加設定 8. コンストラクター引数 ```json { "language": "Solidity", "sources": { "src/VerificationFixture.sol": { "content": "…" } }, "settings": { "optimizer": { "enabled": true, "runs": 200 }, "viaIR": false, "evmVersion": "prague", "metadata": { "bytecodeHash": "ipfs" }, "libraries": { "src/VerificationFixture.sol": { "BuildLibrary": "0x0000000000000000000000000000000000001001" } }, "outputSelection": { "*": { "*": ["metadata", "evm.bytecode", "evm.deployedBytecode"] } } } } ``` [Solidityのコンパイラー文書](https://docs.soliditylang.org/en/latest/using-the-compiler.html)は、複雑な自動処理ではStandard JSONインターフェースを推奨しています。ソースを平坦化するとパスやメタデータが変わり、元のビルドの指紋を失うことがあります。元の`build-info`またはStandard JSON入力を優先します。 ## ライブラリーはコンパイル時にリンクする 外部ライブラリー呼び出しを含む未リンクバイトコードには、完全修飾ライブラリー名から作るプレースホルダーと`linkReferences`があります。アドレスを間違えれば実行コードが変わります。 Solidity公式は、生成後のバイトコードへ手作業でアドレスを差す方法を推奨していません。メタデータにはコンパイル時のライブラリー情報が入り、後からリンクしてもメタデータは更新されないためです。再現ビルドではStandard JSONの`libraries`へソース単位、ライブラリー名、アドレスを入れます。 ローカル再現データでは、未リンクの実行時バイトコードでオフセット`324`からの20バイトがライブラリー参照でした。同じアドレスを手動で差すとメタデータを除いた実行部分は一致しましたが、加工前の実行時バイトコード全体は一致しませんでした。コンパイル時にリンクすれば、設定とメタデータも対応します。 ## `immutable`とコンストラクター差は既知の変換として扱う `immutable`変数はコンストラクターで値が決まり、作成時コードが実行時コードの指定位置へ値を書き込みます。[Solidityの説明](https://docs.soliditylang.org/en/latest/contracts.html#constant-and-immutable-state-variables)どおり、コンパイラー出力の`immutableReferences`に位置が出ます。 再現データでは`owner`と`minimum`に合計4つの32バイト参照があり、`minimum`を`7`から`9`へ変えると加工前の実行時ハッシュが変わりました。一方、コンパイラーが示した`immutable`参照範囲だけを正規化すると、残りの実行時コードは一致しました。 「取得した16進数が違うから別ソース」と即断せず、次の順で扱います。 1. コンパイラー出力の`linkReferences`と`immutableReferences`を取得する 2. チェーン上コードの該当範囲を記録する 3. 既知変換だけを正規化する 4. それ以外のバイトを比較する 5. メタデータ指紋を別に比較する 位置を自作の正規表現や「末尾だけ」と決めつけないでください。コンパイラーバージョンやコード構造でオフセットは変わります。 ## メタデータハッシュはビルド全体の指紋になる Solidityは通常、正規メタデータファイルのIPFSハッシュとコンパイラー情報をCBORでバイトコード末尾へ付けます。末尾2バイトはCBOR部分の長さです。メタデータにはソースハッシュ、コンパイラー、設定、ABI、NatSpecなどが含まれます。 そのため、実行時の動作を変えないコメント、ソースパス、ライセンス、変数名の変更でもメタデータハッシュは変わり得ます。`bytecodeHash: "none"`はメタデータハッシュを付けない設定ですが、CBOR追加自体を止める`appendCBOR: false`とは別です。 ローカル再現データの通常ビルドは実行時522バイトで、そのうち末尾53バイトがCBOR末尾データでした。同じソース・最適化設定で`bytecodeHash`だけを`none`へ変えると、メタデータを除いた469バイトは一致し、加工前のバイトコードは不一致になりました。 ## Exact Match・Match・不一致・類似を分ける Sourcifyの現行文書は、以前の完全一致を`Exact Match`、以前の部分的一致を`Match`と呼びます。名称はブロックエクスプローラーごとに同じとは限りません。参照した公式ページは末尾の出典一覧に記録しています。 | 状態 | 実行部分 | メタデータ指紋 | 読み方 | | --- | --- | --- | --- | | Exact Match | 既知変換を除いて一致 | 一致 | ソース内容とメタデータまで対応 | | Match（旧部分的） | 一致 | 不一致 | 動作部分は対応するがパス・コメント等の差が残り得る | | 不一致 | 不一致 | 多くは不一致 | コンパイラー条件、ソース、ライブラリー、対象を見直す | | 類似候補 | まだ結論ではない | 未確定 | 既存候補を使って再コンパイルし、通常の一致判定を完了する | Etherscanの`Exact Match`・`Similar Match`表示とSourcifyの一致名を混ぜず、利用したサービス、ラベル、確認日、作成時と実行時のどちらが照合されたかを記録します。別チェーンや別ブロックエクスプローラーへ検証が自動で伝わるとも限りません。 Sourcifyの類似度検証も、似たバイトコードから候補のコンパイル入力を見つけ、その候補を通常の検証手順へ通します。「似ている」と表示された時点でソース一致を確定する仕組みではありません。 ## ローカル再ビルドで4状態を固定した Foundry 1.8.0、Solidity `0.8.36+commit.8a079791`、Prague EVMを使い、同じソースを4通りの設定でビルドしました。 | 例 | 変更 | 実行部分 | メタデータ | 結果 | | --- | --- | --- | --- | --- | | Exact Match | 最適化あり / `runs: 200` / IPFS | 一致 | 一致 | `exact_match` | | メタデータのみ変更 | `bytecodeHash: none` | 一致 | 不一致 | `match` | | 最適化設定の不一致 | 最適化なし | 不一致 | 不一致 | `mismatch` | | 類似候補 | `immutable`変数`minimum`を7 → 9 | 既知範囲正規化後に一致 | 一致 | 全体検証が必要 | 作成時バイトコードは693バイト、コンストラクター引数は64バイト、デプロイ入力は757バイトでした。実行時は522バイト、メタデータを除く実行部分は469バイトです。[公開再現JSON](/fixtures/verified-source-rebuild-6033.json)にはビルド条件一覧、ソースと設定のハッシュ、コンストラクターの符号化、ライブラリーと`immutable`の参照、加工前データのSHA-256、4種類の判定を保存しています。 Foundryのローカル検証は3件すべて成功し、コンストラクター値による実行時ハッシュ差、固定ライブラリーアドレスでの外部呼び出し、プロキシと実装の異なるコードハッシュを確認しました。再現処理はローカルコンパイラーとFoundryの検証用VMだけで完結します。 ## プロキシと実装は別々に検証する プロキシアドレスの実行時ソースが検証済みでも、利用者の呼び出しを処理する現在の実装のソースまで検証済みとは限りません。実装が検証済みでも、プロキシの管理者、ビーコン、更新権限、ストレージ配置が安全とは限りません。 プロキシアドレスの実行時ソース、ERC-1967実装・ビーコン・管理者、現在の実装の実行時ソースとストレージ配置を別々に検証する構造 ERC-1967なら、固定ブロックで実装、ビーコン、管理者スロットを読みます。ビーコンを使う場合はビーコンコントラクトの`implementation()`も同じブロックで確認します。 詳しいスロット値、Transparent・UUPS・Beaconの呼び出しパス、初期化関数、更新イベント、保存領域の衝突は[ERC-1967 Proxyの読み方](/archives/6020)でローカル再現データ付きで確認できます。 最低でも次を個別に記録します。 - プロキシアドレスの実行時バイトコード、ソース、コンパイラー条件 - 現在の実装アドレスの実行時バイトコード、ソース、コンパイラー条件 - ビーコン、管理者、ProxyAdmin、所有者、役割、タイムロック - 実装変更イベントとブロック固有のスロット - ストレージ配置と初期化関数状態 ブロックエクスプローラーがプロキシABIを結合表示しても、検証対象まで一つになったわけではありません。 EIP-1167最小クローンは、正確な45バイトの実行時コードから実装アドレスを抽出できます。[Minimal Proxyの実行時・初期化関数・ファクトリーを検証する手順](/archives/6045)では、標準クローンとイミュータブル引数拡張をコード長から分け、クローンと実装を別々に照合します。 コンパイラーのAST注釈とストレージ配置を更新前後で比較する場合は、[ERC-7201 Namespaced Storageのルート計算と検証境界](/archives/6046)で、名前空間ID、アセンブリースロット、安全な末尾追加、型変更をチェーン上の状態データへ対応させています。 最適化の`runs`値、従来のコード生成方式とvia-IR、対象EVM、メタデータ、solc更新を同一ソースで比較する場合は、[Solidityビルド設定の7条件対応表](/archives/6050)で実行部分のバイトコード、デプロイ時と実行時のガス、PUSH0互換性、挙動テストを分けています。 検証済みの実行時コードを既存の状態へ重ねる統合テストでは、[Foundryフォークテストのブロック・プロバイダー・変更操作境界](/archives/6051)を使い、取得したチェーン上の状態と`store`や`etch`で作った状態を別の出所として残します。 Diamondアドレスとファセット群を別々の検証対象として追う場合は、[EIP-2535 Diamondの識別子・ファセット・参照機能・DiamondCutを読む手順](/archives/6047)で、識別子ごとの実行時コードハッシュと共有ストレージを現在の関数振り分けへ対応させています。 実行時コードが過去ブロックと現在ブロックで違うときは、更新イベントだけでなく旧来のメタモーフィックパターンも候補になります。[EIP-6780後のSELFDESTRUCTとCREATE2再デプロイ](/archives/6043)では、ShanghaiとCancunでコード、ストレージ、残高、ノンスがどう分かれるかをトランザクション確定後に比較しています。 決定的デプロイでは、再構築した作成時バイトコードへコンストラクターデータを連結し、リンク済みライブラリーとメタデータ設定を含む初期化コードハッシュを一致させます。[CREATE2アドレスをSolidityとviemで独立計算する手順](/archives/6044)では、同じ実行時コードでもコンストラクター差でアドレスが変わる例を確認できます。 ## ブロックエクスプローラーへ提出する前の再現手順 1. チェーン、アドレス、固定ブロック、実行時コードハッシュを保存する 2. コントラクト作成トランザクションと入力を取得する 3. すべてのソースファイル、ソース単位名、リマッピングを揃える 4. コンパイラー完全バージョン、最適化の有無、`runs`値、EVM、via-IRを固定する 5. ライブラリーをコンパイル時にリンクする 6. コンストラクター引数をABIエンコードして作成時バイトコードへ連結する 7. 実行時のライブラリーリンクと`immutable`変数の変換をコンパイラー出力から適用する 8. 機能部分のバイトコードとメタデータ指紋を別々に比較する 9. プロキシなら実装 / ビーコン / 管理者を分離する 10. ブロックエクスプローラーのサービス名、一致ラベル、確認日を記録する ABI、呼び出しデータ、イベントログをソースと照合する前提は[ABI・呼び出しデータ・ログを読む記事](/archives/6005)、ブロックエクスプローラーで直接読み書きする前のアドレス・関数・シミュレーション確認は[Etherscanからコントラクトを操作する記事](/archives/1005)へ進んでください。 ## ソース検証後に見る安全性確認項目 トークンのソースを再現できても、送金手数料、停止、拒否リスト、`maxTx`、プール宛制限、流動性までは保証されません。[トークンを送れない・売れないときの確認順](/archives/6061)では、検証済みソースを起点に現在の実装、役割、送金時の会計、市場、シミュレーションを分けます。 - [ ] ソース検証の対象チェーン・アドレス・ブロックを固定した - [ ] プロキシと実装を別々に確認した - [ ] 所有者、管理者、役割、停止、更新権限を読んだ - [ ] デプロイ・更新・所有権イベントを追った - [ ] ストレージ配置と初期化関数を確認した - [ ] 監査報告書の範囲、コミット、日付、除外項目を照合した - [ ] オラクル、ブリッジ、外部呼び出し、トークン会計を調べた - [ ] 同名トークンや類似コントラクトを公式性の根拠にしていない - [ ] スポンサー・広告表示を検証結果から分離した 検証ツール、ブロックエクスプローラー、監査、監視サービスがスポンサーの場合でも、広告表示は独立して明示します。スポンサー契約、バッジ、掲載順位はバイトコード一致や安全判定を変えません。この記事にもアフィリエイトリンクはありません。 ## まとめ 検証済みソースは、調査を始められる重要な証拠です。ただし結論はバッジではなく、チェーン・アドレス・ブロック、作成時と実行時、コンパイラー設定、コンストラクター、ライブラリー、`immutable`変数、メタデータ、プロキシ先を照合して判断します。 検証済み表示を結論にせず、チェーン・アドレス・実行時バイトコード・ビルド条件・プロキシ先を同じ記録へ固定することが、再現可能なコントラクト調査の最短経路です。 ## 確認した一次情報 - [Solidity Contract Metadata](): 確認日 2026-08-31 - [Solidity Using the Compiler and Standard JSON](): 確認日 2026-08-31 - [Solidity immutable variables](): 確認日 2026-08-31 - [Sourcify Exact Match vs Match](): 確認日 2026-08-31 - [Sourcify similarity verification](): 確認日 2026-08-31 - [Sourcify Solidity metadata](): 確認日 2026-08-31 - [Etherscan common verification errors](): 確認日 2026-08-31 - [Etherscan verification with Foundry](): 確認日 2026-08-31 - [Blockscout contract verification UI](): 確認日 2026-08-31 - [ERC-1967 Proxy Storage Slots](): 確認日 2026-08-31 - [Foundry 1.8.0](): 確認日 2026-08-31 --- # EVM向けハードウェアウォレット5機種比較｜署名表示・接続・復旧で選ぶ Ledger Flex、Trezor Safe 5、Keystone 3 Pro、OneKey Pro、CoolWallet Proを、EVM署名で確認したい項目、接続方式、バックアップ、公開ソースの範囲から比較します。 正規URL: https://3mikan.com/archives/6034 著者: みかん 公開: 2026-08-31T05:00:00.000Z 更新: 2026-09-02T05:35:00.000Z ハードウェアウォレットを選ぶときは、「鍵が端末内にある」だけでなく、**署名前に端末自身の画面で何を確認できるか**、普段のスマートフォンやPCへどう接続するか、紛失時にどう復旧するかを先に決めます。高価な機種が全員にとって最適とは限りません。 この記事は、2026-08-31に公式販売を確認できたLedger Flex、Trezor Safe 5、Keystone 3 Pro、OneKey Pro、CoolWallet Proを、EVM利用者向けに比較します。対象は、ソフトウェアウォレットから署名鍵を分離したい人、モバイル中心の人、QRによるオフライン隔離運用をしたい人、EIP-712や`approve`の確認範囲を重視する開発者です。 重要な制限があります。3MIKANは今回、5機種の実機を購入・貸与されていません。端末画面や接続時間を確認したレビューではなく、公式製品情報、公式サポート、公開ソース・変更履歴で購入候補を絞るための記事です。 確認できなかった項目は「未確認」とし、実機結果や総合順位を作りません。 ## 先に結論：機種名より4つの条件を決める 候補を一つに絞る前に、次の4問へ答えてください。 1. `approve`やEIP-712で、利用先、数量、チェーンID、検証コントラクト、有効期限まで端末上で確認したいか 2. 接続はUSB-C、Bluetooth、QRのどれを許容するか 3. 復旧は1つのBIP39バックアップ、SLIP39の複数の分割片、専用バックアップカードのどれを運用できるか 4. ファームウェアの公開範囲、再現可能なビルド、Secure Elementの設計について、どの信頼境界を受け入れるか 「Bluetoothがある／ない」だけでは安全性は決まりません。通信経路が増えても、署名内容を独立した端末画面で検証できる設計なら、ホスト側の表示をそのまま信じずに済みます。反対にオフライン隔離でも、QRから読み込んだ内容を端末が十分に解析できなければ盲目的署名は残ります。 ## ハードウェアウォレットが守るもの／守らないもの ハードウェアウォレットの中心的な役割は、秘密鍵を通常の電話・PCから分離し、署名の最終確認を専用端末へ移すことです。ソフトウェアウォレットやDAppが作った要求は、接続経路を通って端末へ届きます。そこで受取先、数量、コントラクト、メソッド、型付きデータを読み、意図と一致したときだけ物理操作で承認します。 取引所、メール、パスワード管理サービス、Gitホスティング、クラウドなどのアカウントへのログインに使うFIDO2認証器は、別の製品区分です。[セキュリティキー4製品の公式仕様比較](/archives/6069)では、WebAuthn、パスキー容量、PINと利用者確認（UV）、NFC、予備キー、アカウント復旧を扱っています。セキュリティキーをシードのバックアップやチェーン上の署名者として代用しません。 受取先確認では、端末画面も正しいアドレスの入手元にはなりません。[アドレスポイズニングとクリップボード差し替えの確認手順](/archives/6056)のように、信頼できる別経路から完全なアドレスとチェーンを入手し、PCやスマートフォンへ貼り付けた値と端末表示の両方を照合します。 一方、次は自動では守られません。 - 復旧フレーズやパスフレーズを偽サイトへ入力した - 正しい端末画面を読まずに`approve`した - ブラインド署名の警告を無視した - 攻撃者のアドレスを自分の受取先と思い込んだ - すでに漏れたシードを新しい端末へ追加した - 悪意あるコントラクトの動作を、メソッド名だけで安全と判断した 署名要求のメソッド、オリジン / ドメイン、アカウント、チェーン、コントラクト、利用先、数量、ノンス、有効期限を読む順序は[危険な署名要求を見分ける確認項目](/archives/6025)で整理しています。ハードウェアウォレットはこの確認を強くできますが、確認そのものを代行する装置ではありません。 ## 比較方法と商業関係 比較対象は、各ブランドの公式ストアで販売中と確認でき、EthereumまたはEVM利用を公式に案内している1機種です。価格、在庫、配送地域は変わるため本文へ固定しません。購入直前に公式ストアと正規販売店の方針を再確認してください。 証拠は次の3段階に分けました。 - **公式説明**：製品ページ、サポート、変更履歴で提供元が説明している - **公開ソース**：関連ファームウェアやアプリのソース、公開版の履歴を公開情報から読める - **実機未確認**：3MIKANの物理端末で同一要求を表示していない 5機種とも購入品・貸与品・スポンサー提供品ではありません。この記事にアフィリエイトリンクはなく、掲載順、選択条件、将来の評価点に販売手数料を含めません。 ## 5機種の公式仕様比較 表は2026-08-31に公式情報で確認した範囲です。「EIP-712あり」は、すべてのDApp・ウォレット・メッセージが全項目表示される意味ではありません。ホストウォレット、ファームウェア、端末アプリ、メッセージ構造、記述子対応で表示は変わります。 | モデル | 信頼済み表示の公式説明 | 主な接続 | バックアップ / 復旧 | ソース公開範囲 | EVM署名の証拠状態 | | --- | --- | --- | --- | --- | --- | | Ledger Flex | 2.84インチE Inkタッチ画面、Secure Elementから制御 | USB-C / Bluetooth / 一部NFC | 24語のフレーズ、Recovery Key、任意の別サービス | アプリ・SDK・一部OSは公開、SE低水準は非公開 | EIP-712とクリア署名 / ブラインド署名の公式資料あり、実機未確認 | | Trezor Safe 5 | 1.54インチのカラータッチ画面、触覚、端末上での入力 | USB-C | SLIP39の単一 / 複数シェア、BIP39の12 / 24語、パスフレーズ | ファームウェア・設計を広く公開 | EIP-712・`approve`表示の変更履歴あり、実機未確認 | | Keystone 3 Pro | 4インチのカラータッチ画面、全体表示の公式説明 | QRオフライン隔離 / USB-C / microSD更新 | BIP39、SLIP39、パスフレーズ、複数シード | Keystone 3ファームウェア公開 | EIP-712解析の変更履歴あり、実機未確認 | | OneKey Pro | 3.5インチのカラータッチ画面、クリア署名の公式説明 | USB-C / Bluetooth / QR / NFC | BIP39、SLIP39、パスフレーズ、OneKey Lite | アプリ・ファームウェア公開、再現可能なビルドの公式説明 | 型付きデータ・`approve`改善の変更履歴あり、実機未確認 | | CoolWallet Pro | カード型表示と物理ボタンの公式説明 | 暗号化済みBluetooth / 補助アプリ / WalletConnect | BIP39互換12/18/24語 | SEファームウェア公開の公式説明 | Ethereum対応は確認、EIP-712・`approve`の端末項目は未確認 | 画面の大きさは、長いアドレスや型付きデータを読みやすくする一要素です。ただし大画面でも、端末アプリが項目を解析せずハッシュだけを出す要求は十分に読めません。小型画面でもページ送りですべての重要項目へ到達できる場合があります。 寸法だけで署名時の安全性を採点しないでください。 ## Ledger Flex：電話とデスクトップを跨ぐ候補 [Ledger Flex公式ページ](https://shop.ledger.com/pages/ledger-flex)は、2.84インチ、480×600、16階調E Inkタッチ画面、USB-C、Bluetooth、NFC、Secure Elementを案内しています。公式設計指針では、解析済みのトランザクションとブラインド署名を分け、解析できない要求では警告と明示的な設定を要求しています。 LedgerはEIP-712のネイティブサポートを説明しています。ただしクリア署名の可否は、Ledger側端末アプリだけでなく、接続するウォレットやDApp、対象プロトコルの記述子にも依存します。「Ledgerだから常にすべて読める」とは判断できません。 ソースコードの公開範囲は一律ではありません。Ledger Wallet、SDK、組み込みアプリ、一部OSは確認できますが、Secure Elementとやり取りする低水準コードには非公開部分があります。この境界を許容し、モバイルとデスクトップを同じ端末で使いたい人の候補です。 完全公開を必須条件にする人、Bluetoothを運用から除外したい人は別候補と比較します。 ## Trezor Safe 5：USB-Cと標準バックアップを重視する候補 [Trezor Safe 5公式ページ](https://trezor.io/trezor-safe-5)は、1.54インチのカラータッチ画面、触覚フィードバック、USB-C、EAL6+ Secure Element、公開ソースのセキュリティ設計を案内しています。初期状態ではファームウェアを入れずに出荷し、Trezor Suiteで公式ファームウェアと端末の正規性を確認する手順です。 バックアップはSLIP39の20語による単一シェアを標準にし、複数シェアへ移行できます。BIP39の12 / 24語とパスフレーズにも対応します。シェアを複数拠点へ分ける運用を実際に維持できる人には選択肢が広い一方、シェア総数・復旧に必要なシェア数・パスフレーズを複雑にしすぎると自分が復旧できないリスクも増えます。 公開ファームウェア変更履歴にはEIP-712署名やETH `approve`表示の改善が記録されています。これは対応の証拠ですが、今回の共通検証項目で全項目を実機確認した結果ではありません。接続をUSB-Cに限定したいデスクトップ中心・Android併用の候補です。 iOSだけで設定・送信・端末管理まで完結したい場合は、公式のiOS制限を先に確認してください。 ## Keystone 3 Pro：QRオフライン隔離を運用できる人の候補 [Keystone 3 Pro公式ページ](https://keyst.one/shop/products/keystone-3-pro)は、4インチのタッチ画面、QRオフライン隔離、3つのSecure Element、オープンソースのファームウェア、Shamirバックアップ、パスフレーズを案内しています。MetaMaskやOKX等とのEVM連携も公式に説明されています。 QR方式では、オンラインウォレットが未署名要求を表示し、Keystoneがカメラで読み取って端末内で確認・署名し、署名済みペイロードをQRで戻します。BluetoothやUSBデータ接続を運用から外せますが、カメラで読んだ要求の項目を端末側で解析できることが前提です。 ファームウェア変更履歴にはEIP-712解析、EVMトランザクション解析、ERC-20表示の改善が記録されています。最新ファームウェアページでは2026-08-12付のMulti-Coin Firmware 3.0.4が掲載されていました。QRの往復、ファームウェアのチェックサム、microSD、電池、バックアップのシェアを管理できる人向けです。 小さく持ち歩きたい人や、QRスキャンを毎回行いたくない人には手順が重くなります。 ## OneKey Pro：接続方式を切り替えたい人の候補 [OneKey Pro公式ページ](https://onekey.so/products/onekey-pro/)は、3.5インチのタッチ画面、USB-C、Bluetooth、QR、NFC、4つのEAL6+ Secure Element、オープンソースのファームウェアを案内しています。AirGap Modeを有効にするとUSB・Bluetooth・NFCのデータ通信を止め、QRだけを使う公式手順があります。 ファームウェア更新ログでは、4.15.0でApproveなどのトランザクション解析、4.20.0で`EIP712-Domain`がない型付きデータ表示の修正が記録されています。2026-08-31の確認時点で、掲載されていた最新のシステムファームウェアは4.21.0でした。更新履歴が具体的であることと、すべての要求が意図どおり表示されることは別なので、購入後に共通検証手順を実行します。 モバイル・デスクトップ・QRを一台で切り替えたい人の候補です。反対に、接続方式を一つに固定して攻撃表面と操作手順を最小化したい人は、不要なインターフェースを無効にできるか、設定が更新後も維持されるかを実機で確認します。 ## CoolWallet Pro：カード型とモバイル運用を優先する候補 [CoolWallet Pro公式ページ](https://www.coolwallet.io/products/coolwallet-pro/)は、クレジットカードサイズ、CC EAL6+ Secure Element、暗号化済みBluetooth、表示部、物理ボタン、Android / iOS補助アプリを案内しています。12 / 18 / 24語のBIP39互換バックアップを作成でき、カード上の数字をBIP39の単語へ対応させる方式も公式サポートにあります。 WalletConnectとMetaMask連携は公式手順がありますが、CoolWallet Pro本体でEIP-712のドメイン、検証コントラクト、利用先、数量、ノンス、有効期限がどこまで表示されるかを示す十分に具体的な一次情報は、今回の調査では確認できませんでした。この欄は「非対応」ではなく「未確認」です。 薄いカード型でモバイル中心に使いたい人の候補です。型付きデータや複雑なコントラクト呼び出しを頻繁に扱う開発者は、購入前に公式サポートへ対象要求の表示範囲を確認し、購入後は少額で、ローカル環境かテストネットの共通検証手順を試してから運用します。 ## 同じ手順で確認する5つの要求 製品説明を並べるだけでは、実際の署名表示差は分かりません。そこで、物理端末を確保したときに全機種へ同じ要求を渡す[公開比較データ](/fixtures/hardware-wallet-comparison-6034.json)を用意しました。 この比較データはチェーンID `31337`のローカル要求データだけを持ち、既存ウォレット、実資産、メインネット送信、秘密情報、シード、秘密鍵を含みません。今は全5機種が`not_run_no_device`です。 | 例 | 端末で確認したい項目 | 見えない場合の判断 | | --- | --- | --- | | 受取アドレス | アドレス全体 | ホスト画面だけを信じず中止 | | ネイティブ資産の送金 | 受取先、数量、チェーン、手数料 | 別チェーン・別受取先を除外できなければ中止 | | ERC-20送金 | トークンコントラクトまたは独立確認済み識別情報、受取先、数量 | シンボルだけならコントラクトと小数桁を別確認 | | ERC-20 `approve` | トークン、利用先、利用許可額、無制限警告 | 利用先または数量が見えなければ中止 | | EIP-712 Permit | 主要型、ドメイン、チェーンID、検証コントラクト、所有者、利用先、値、ノンス、有効期限 | 非表示項目があればブラインド署名として中止 | EIP-712は型付き構造化データをハッシュ・署名する規格です。規格にはドメインの`name`、`version`、`chainId`、`verifyingContract`等がありますが、ウォレットがすべてを読みやすく表示することまで自動保証しません。ファームウェア、端末アプリ、ホストウォレットを一組として確認します。 ## 評価点は実機結果が揃うまで付けない 比較評価点の式は先に固定し、販売手数料を0にしました。 ```text 総合点 = Σ（各軸0〜5点 ÷ 5 × 重み） 信頼できる表示・署名項目 30 バックアップ / 復旧 20 接続方法との適合 20 ソース公開 / 検証範囲 15 ウォレット / EVM連携 10 ファームウェア更新の証拠 5 販売手数料 0 ``` ただし、5つすべての共通検証項目を物理端末で実行し、秘密情報を取り除いた記録を確認するまでは採点しません。現時点では全機種`N/A`です。数値を埋めるために、提供元の説明を実機評価とみなすことはしません。 シードやパスフレーズを接続済みホストへ露出する、独立した端末上確認がない、必要チェーン・ウォレットが非対応、公式サポートが終了、重要な要求がブラインド署名から抜けられない場合は評価点計算前に除外します。 ## 用途別の候補の絞り方 ### モバイルとデスクトップを頻繁に切り替える Ledger FlexとOneKey Proは、公式仕様上USB-Cと無線接続を持ちます。CoolWallet Proはモバイル補助アプリ中心です。無線の有無より、ペアリング、ファームウェア更新、接続解除、端末画面の項目を自分が毎回確認できるかで選びます。 ### USB-Cだけで運用したい Trezor Safe 5は接続要件が明確です。Ledger FlexやOneKey Proでも不要インターフェースを使わない運用は考えられますが、設定で無効化できる範囲と更新後の状態を実機確認します。 ### QRオフライン隔離を優先する Keystone 3 ProとOneKey Proが公式にQRを使った手順を案内しています。オフライン隔離は「安全」というバッジではなく、未署名要求 → 端末での復号 → 物理確認 → 署名済みデータという手順です。QRの枚数、大きなデータ、カメラ、電池、補助ウォレットとの互換性も日常運用の一部です。 ### EIP-712・`approve`を頻繁に扱う 公式変更履歴で型付きデータと`approve`の表示改善を追えるLedger、Trezor、Keystone、OneKeyを候補にし、実機の共通検証手順で項目を確認します。CoolWallet Proは具体的表示範囲を確認できるまで保留です。どの機種でもブラインド署名の警告が出た要求は、別機種なら安全だと推測せず、要求自体を止めます。 ### バックアップを複数拠点へ分ける SLIP39複数の分割片を標準的に扱いたい場合はTrezor Safe 5、Keystone 3 Pro、OneKey Proの公式手順を比較します。BIP39を複数断片へ自己流で切り分ける方法は使いません。相続、災害、紛失、パスフレーズ忘れを含め、自分以外でも復旧手順を誤解しない設計にします。 ## 購入後の初日に行うこと モデルを選んだ後は、[ハードウェアウォレット初日の安全設定手順](/archives/6035)で、公式アプリ、正規品確認、ファームウェア、端末で生成したバックアップ、復旧確認、受取アドレス照合を順番に進めてください。実機未確認の項目を提供元の説明だけで補完せず、シード、PIN、パスフレーズ、QRを接続済みホストや記録へ残さない手順です。 1. 公式ストアまたは認可済み再販業者を使い、モデル、配送地域、返品・保証を再確認する 2. パッケージ、開封検知シール、同梱物を公式手順と照合する 3. 復旧カードに事前印刷済み語があれば使用を止める 4. 公式アプリ・ファームウェアの配布元、署名、チェックサムを確かめ、端末の正規品確認を行う 5. 新しいバックアップは端末自身で生成し、カメラ、クラウド、クリップボード、パスワード管理サービスへ保存しない 6. バックアップ確認または予行復旧を行い、パスフレーズウォレットならアドレスも記録する 7. 受取アドレスを端末画面と照合し、ローカル/テストネットまたは損失許容範囲の少額から始める 8. 送金、`approve`、EIP-712の共通検証手順を実行し、見えない項目がある要求は運用対象から外す ソフトウェアウォレットで接続解除しても、過去のトークン利用許可額、Permit2記録、サーバー側セッション、セッション鍵、EIP-7702委任は同時に消えません。[DApp権限を層ごとに解除する手順](/archives/6031)で、ウォレット接続とチェーン上状態を分けて確認できます。 既存シードの漏えいが疑われる場合、新しいハードウェアウォレットへ同じシードを追加しても漏えいは消えません。追加署名を止め、証拠を保存し、ウォレット・プロトコル・取引所の公式窓口へ相談してください。 ## 更新期限と未確認事項 製品比較対象、ファームウェア、ウォレット組み込み、配送地域、保証、アフィリエイトプログラムは変わります。この記事は2026-11-30までに再確認し、公式ストアの販売状態、最新ファームウェア、EIP-712・`approve`表示、サポート終了、リンク切れを見直します。 実機を確保した場合は、モデルごとに購入・貸与・レビュー用提供品の関係、ファームウェア、補助アプリ、OS、ブラウザー、ウォレット拡張機能、確認日を固定します。工場出荷状態へ初期化した検証専用アカウントだけを使い、製造番号、QR、復旧情報を撮影しません。提供元の説明、公開ソース、実機記録を同じ証拠として混ぜません。 ## まとめ ハードウェアウォレットの比較は、単一の「一番安全」では終わりません。端末画面で読む項目、接続、バックアップ、ファームウェア、ソース公開範囲、利用ウォレットを、自分の運用へ合わせて選びます。 現段階の5機種は公式仕様から候補を絞るための比較であり、実機順位ではありません。購入後は同じ検証手順を使い、受取先、数量、コントラクト、利用先、EIP-712ドメインを端末上で確認できることを確かめてから、本番資産の運用へ進んでください。 ## 確認した一次情報 - [Ledger Flex official product page](): 確認日 2026-08-31 - [Ledger signing design guidelines](): 確認日 2026-08-31 - [Ledger open-source scope](): 確認日 2026-08-31 - [Trezor Safe 5 official product page](): 確認日 2026-08-31 - [Trezor wallet backup formats](): 確認日 2026-08-31 - [Trezor firmware changelog](): 確認日 2026-08-31 - [Keystone 3 Pro official product page](): 確認日 2026-08-31 - [Keystone 3 Pro firmware page](): 確認日 2026-08-31 - [Keystone 3 firmware changelog](): 確認日 2026-08-31 - [OneKey Pro official product page](): 確認日 2026-08-31 - [OneKey Pro firmware update log](): 確認日 2026-08-31 - [OneKey Pro AirGap guide](): 確認日 2026-08-31 - [CoolWallet Pro official product page](): 確認日 2026-08-31 - [CoolWallet WalletConnect guide](): 確認日 2026-08-31 - [CoolWallet Secure Element firmware source announcement](): 確認日 2026-08-31 - [EIP-712 typed structured data](): 確認日 2026-08-31 --- # ハードウェアウォレット初日の安全設定｜公式アプリ・バックアップ・復旧確認 Ledger Flex、Trezor Safe 5、Keystone 3 Pro、OneKey Pro、CoolWallet Proの初日設定を、公式配布元、正規品確認、ファームウェア、端末内でのシード生成、バックアップ、復旧、受取アドレス照合の順に整理します。 正規URL: https://3mikan.com/archives/6035 著者: みかん 公開: 2026-08-31T06:00:00.000Z 更新: 2026-09-02T05:35:00.000Z 新品のハードウェアウォレットを開封した直後は、早く資産を移すより、**正しい配布元・端末自身の表示・復旧できるバックアップ**を一つずつ確認する方が先です。検索広告、DMのサポート担当、動画概要欄、同梱QRを起点にアプリを入れないでください。 この記事は2026-09-01時点の公式手順を、Ledger Flex、Trezor Safe 5、Keystone 3 Pro、OneKey Pro、CoolWallet Proについて整理したものです。購入候補をまだ決めていない場合は、先に[EVM向けハードウェアウォレット5機種の公式仕様比較](/archives/6034)で、接続方式、署名表示、バックアップ形式を絞ってください。 アカウントへのログイン用のFIDO2キーを探している場合は対象が異なります。[セキュリティキー4製品のFIDO2・NFC・復旧比較](/archives/6069)へ進み、ハードウェアウォレットの復旧フレーズとセキュリティキーの予備キー登録を混同しないでください。 重要な制限があります。3MIKANは今回も5機種の実機を所有していません。開封、初期化、ファームウェア更新、バックアップ確認、消去、復元、アドレス照合を実行した記事ではありません。 製品固有の結果はすべて`not_run_no_device`で、画面名や順序は更新で変わり得ます。手元の端末画面と各社の最新公式手引きが一致しなければ、その場で止めてください。 ## まず止める5つの信号 次のどれかがあれば、PINや復旧フレーズを入力せず設定を止めます。 1. 復旧カードに語や数字が印刷・記入済み 2. 端末にPINがすでに設定されている、または「同梱PINを使う」と案内される 3. PC、電話、ブラウザー、チャット、入力フォームへ復旧フレーズを入力するよう求められる 4. 遠隔サポート、画面共有、カメラ、クリップボード、クラウド写真を要求される 5. 公式ドメインへ自分で移動せず、検索広告、DM、短縮URL、同梱QRだけからアプリ・ファームウェアを取得するよう求められる 箱や封印がきれいでも完全な安全保証にはなりません。反対に箱の小さな傷だけで改ざんとも断定できません。購入経路、同梱物、空白のバックアップカード、公式アプリ、暗号学的な正規品確認、ファームウェア署名を別々の証拠として扱います。 ## 初日の共通手順 ### 1. 秘密を記録する機器を作業場所から外す カメラ、スマートスピーカー、画面記録、遠隔デスクトップ、クリップボード同期を止め、人が通らない机を使います。復旧フレーズ、PIN、パスフレーズ、Shamirシェアはメモ、写真、ログ、パスワード管理サービス、印刷機、クラウド、チャットへ残しません。USBケーブル、充電器、白紙、油性ペンだけを用意します。 実機確認を行う場合も、最初は資産ゼロの**端末で生成したテストウォレット**だけを使います。既存ウォレット、メインネット資産、ソフトウェアウォレットで作ったシードを追加しません。 ### 2. 公式ドメインを手入力またはブックマークから開く アプリ名の検索ではなく、提供元の公式ドメインからダウンロードページへ入ります。デスクトップパッケージ、App Store、Google Playへ遷移した後も発行者名を確認します。OSの署名警告や発行者不一致を「初回だから」と無視しません。 | ブランド | 公式の入口 | 初日に使うアプリ / サイト | | --- | --- | --- | | Ledger | `ledger.com/start/device-setup` | Ledger Walletのデスクトップ / モバイル公式配布 | | Trezor | `trezor.io/start` | Trezor Suiteデスクトップ、対応Androidでは公式モバイルアプリ | | Keystone | `guide.keyst.one`と`keyst.one/firmware` | 端末検証 / ファームウェアページ。資産管理は対応第三者ウォレットを別途公式配布元から取得 | | OneKey | `onekey.so/download` | OneKey Appデスクトップ / 拡張機能 / モバイルの公式配布 | | CoolWallet | `coolwallet.io`のHelp Center | App Store / Google PlayのCoolWallet App。ストア発行者と公式リンクを照合 | 検索結果の上位表示は公式性の証明ではありません。一度正しい入口を確認したらブックマークし、ファームウェア更新時も同じ入口から辿ります。 ### 3. パッケージ確認と正規品確認を分ける 封印、外装、同梱物、空白の復旧シートを公式手引きと照合します。その後、提供元が用意した端末の正規品確認や`Genuine Check`を、公式アプリまたは公式サイトで実行します。 正規品確認が成功しても、物流中のあらゆる物理改変を否定できるとは限りません。Ledger自身も`Genuine Check`は物理的なサプライチェーン履歴の完全確認ではないと説明しています。Keystoneの公式手引きは強い安全表現を使いますが、この記事では提供元による確認の成功を「完全に安全」と読み替えません。 ### 4. ファームウェアはバージョン・配布元・結果を秘密なしで記録する 更新前に端末名、現在のバージョン、提供バージョン、公式リリースノートのURL、確認日だけを作業表へ記録します。シリアル番号、端末ID、ペアリングコード、QR、アカウント、アドレスは残しません。 ファームウェアファイルをダウンロードする機種では公式署名と、提供される場合はチェックサムを確認します。Keystoneの端末上チェックサム比較はmicroSD更新かつファームウェア1.2.4以降という条件があります。Trezor Safe 5はファームウェアなしで出荷され、Trezor Suiteが署名済みファームウェアの導入とSecure Elementの正規品確認を案内します。 画面が公式手引きと違う、署名警告が出る、チェックサムが違う場合は続けません。 ### 5. 新しいシードは端末自身で生成する `Create new wallet`を選び、復旧フレーズはハードウェア端末の信頼できる表示だけで読みます。PCや電話に同じ語を表示・入力する流れへ進みません。白紙へ順番どおり手書きし、端末上の確認問題を完了します。 「既存のソフトウェアウォレットをそのままコールドウォレットにする」ために、MetaMask等で作ったシードを追加しても、そのシードが過去にオンライン環境へ露出した事実は消えません。新しいハードウェアウォレットへ移行する場合は、新規シードを端末で作り、アドレスを端末画面で確認してから、既存ウォレットから通常のチェーン上送金で移します。 ### 6. PIN、パスフレーズ、Shamirは役割を分ける - **PIN**は紛失・盗難時の端末操作を防ぐ。復旧フレーズの代わりではない - **パスフレーズ**は同じ復旧フレーズから別ウォレットを導出する。1文字違えば別ウォレットになり、忘れると復旧フレーズだけでは戻れない - **Shamir / SLIP39**は複数のシェアを作り、定めた数をそろえて復旧する。BIP39フレーズを自己流で分割する方法ではない 初回から複雑さを増やさず、自分が災害、相続、端末故障時にも再現できる方式だけを選びます。パスフレーズや複数のシェアを使うなら、通常利用するウォレットの復旧確認を終えた後、別の検証用ウォレットで手順と保管場所を確かめます。 ### 7. バックアップ確認と消去して復元する確認を同じ操作にしない 提供元が端末内の**非破壊バックアップ確認**を提供する場合は、それを先に使います。Trezor Safe 5の`Check backup`は端末内で入力したバックアップと保存中のウォレットを比較します。Keystone 3 Proの`Seed Phrase Check`も標準シードとShamirに対応しますが、パスフレーズ確認には対応しないと公式手引きにあります。 消去して復元する確認は、端末の状態を消す破壊的な操作です。次の条件をすべて満たす場合だけ行います。 1. 端末自身が生成した、資産ゼロの一時的な検証用シードである 2. バックアップの全語・順序を端末上の確認で再確認した 3. 復旧入力先がハードウェア端末自身であり、PC / 電話 / ブラウザーではない 4. 消去後に比較する検証用の受取アドレスを別の紙へ記録し、写真や公開場所へ残さない 5. 失敗しても失う資産・アカウント・履歴がない 復元後は同じネットワーク・導出の最初の受取アドレスを端末画面と公式アプリで全文照合します。一致を確認したら検証用ウォレットを再び消去し、検証用バックアップシートを運用用バックアップと混ざらない方法で廃棄してから、運用用ウォレットを新規生成します。 実資産のあるウォレットを、この記事だけを根拠に消去しないでください。CoolWalletの公式復旧確認は初期化・復元・アドレス比較を案内し、ウォレット一覧の画面記録にも触れますが、3MIKANの検証では個人用アドレスや資産一覧を記録へ残しません。また、CoolWallet Proで復旧フレーズが常に端末だけへ入力されることを今回の実機で確認できていないため、その破壊的手順は`pending_device_verification`です。 ### 8. 受取アドレスはホストと端末で全文を照合する アプリのアドレスだけをコピーして送金しません。対象ネットワークとアカウントを選び、端末に表示させ、先頭・末尾だけでなく全文を照合します。EVM互換チェーンで同じ16進数アドレスが使われても、送金ネットワークやトークンコントラクトは別に確認します。 一致後も、最初は失ってよい少額に限定します。受取確認後に返送テストを行う場合は、[危険なウォレット署名要求の確認項目](/archives/6025)で受取先、数量、チェーン、コントラクト、権限を端末画面へ対応させてください。 ## ブランド別に異なる部分 ### Ledger Flex [公式ダウンロードページ](https://www.ledger.com/start/device-setup)からLedger Walletを取得します。Ledgerは公式ウェブサイトまたは公式モバイルアプリストア以外のリンク、第三者ストア、TestFlight版を使わないよう案内しています。 Ledger Flexの公式初期設定は、空白のRecovery Sheets、端末上での24語生成・確認、Ledger Walletによる`Genuine Check`、必要なファームウェア更新という順です。`Genuine Check`が失敗したら使用を止めます。復旧フレーズをPC、電話、アプリ、ウェブサイトへ入力しません。 受取時はLedger Walletに表示されたアドレスとLedger Flexの安全な画面を照合します。今回は`Recovery Check`に相当する現行のFlex手順と消去後の復旧を実機確認していないため、それらを「検証済み」とはしません。 ### Trezor Safe 5 `trezor.io/start`からTrezor Suiteを取得します。Safe 5はファームウェアなしで出荷され、Suiteが最新の署名済みファームウェアのインストールとSecure Elementの正規品確認を案内します。バックアップカードが記入済みなら使用しません。 新規ウォレットでは端末に表示されるバックアップを手書きし、PINを端末タッチ画面で設定します。通常のバックアップ形式とSLIP39の複数シェアを混同しないでください。 初期設定後はTrezor Suiteの`Check backup`を使い、語をSafe 5自身へ入力します。これは端末にバックアップを保存し直さず、保存済みウォレットとの一致を確認する機能です。公式手引きは消去前とファームウェア更新前の確認を推奨しています。 受取アドレスもSuiteだけでなく端末で確認します。 ### Keystone 3 Pro `guide.keyst.one`から設定手引きを開き、端末検証は`keyst.one`の公式検証ページでQRチャレンジと端末側コードを照合します。この確認もサプライチェーン全体の完全保証とは扱いません。 ファームウェアは公式ファームウェアページから取得し、microSDまたはUSBを使う公式手順に従います。microSD方式では端末が計算したチェックサムと公式サイトの値を比較できます。更新ファイル名やバージョン条件は現行手引きをそのまま確認します。 シードは端末がオフラインで生成した24語を使います。`Device Settings → Wallet Settings → Seed Phrase Check`では標準シードまたはShamirを端末内で確認できますが、パスフレーズは対象外です。受取アドレスはKeystone本体で表示し、接続したソフトウェアウォレット側とネットワークを含めて照合します。 ### OneKey Pro `onekey.so/download`からOneKey Appを取得します。公式手引きではデスクトップ / 拡張機能はUSB、モバイルはBluetoothという接続境界が案内されています。発行者が異なる拡張機能やストア掲載を使いません。 端末で新規ウォレットの作成、PINの設定、復旧フレーズの表示と単語確認を完了した後、OneKey Appへ接続して端末が正規品か確認します。パッケージの復旧シートは空白である必要があります。ファームウェアバージョンは公式更新ログと照合します。 OneKey Appの`Receive → Verify on device`でアプリとOneKey Proのアドレス全文を比較します。SLIP39はOneKey Proファームウェア4.15.0以降の公式手順があるため、バージョン、シェア総数、復旧に必要なシェア数を固定して別の検証用ウォレットで確認します。今回確認した公式情報では、初期設定時の単語検証とは別の非破壊バックアップ確認機能を確認できていません。 パスフレーズは失うと復旧できない別ウォレットを作るため、通常バックアップを確認する前に有効化しません。 ### CoolWallet Pro CoolWallet公式サイトのHelp CenterからApp StoreまたはGoogle Playへ移動し、ストアの発行者を照合します。カードのペアリング、ファームウェア、復旧手順はアプリ更新で変わるため、公式Help CenterのPro欄を当日確認します。 公式製品ページはカード上の表示とボタン、暗号化済みBluetooth、12・18・24語のバックアップを案内しています。一方、今回確認できた復旧検証手引きは初期化、復元、アドレス比較を必要とし、ウォレット一覧やアドレスの画面記録にも言及します。個人情報を記録へ残さない3MIKANの手順とは、そのまま両立しません。 したがって、CoolWallet Proでは新規の検証用シード、カード上での生成、ファームウェア、フレーズ入力画面、初期化、復元、同一アドレスのカード表示まで実機で確認する前に破壊的な操作へ進みません。ソフトウェアウォレットやCoolWallet Goへ同じシードを追加して試す方法も使いません。 ## 5機種の確認状態 | モデル | 公式アプリ / サイト | 正規品確認 | 端末内バックアップ確認 | 消去 / 復元 | 受取アドレス照合 | | --- | --- | --- | --- | --- | --- | | Ledger Flex | 公式情報を確認 | 公式`Genuine Check`手順あり | 初期設定時の単語確認のみ | 実機未確認 | 公式手順あり、実機未確認 | | Trezor Safe 5 | 公式情報を確認 | ファームウェア / Secure Element確認手順あり | `Check backup`手順あり | 実機未確認 | 公式手順あり、実機未確認 | | Keystone 3 Pro | 公式情報を確認 | QR検証手順あり | `Seed Phrase Check`手順あり | 実機未確認 | 公式手順あり、実機未確認 | | OneKey Pro | 公式情報を確認 | アプリ / 端末検証手順あり | 初期検証のみ。独立した非破壊確認機能は今回確認した公式情報で未確認 | 実機未確認 | 公式手順あり、実機未確認 | | CoolWallet Pro | 公式情報を確認 | 現行Pro固有の十分な証拠を未確認 | 初期化 / 復元方式のみ確認 | 実機未確認 | 実機未確認 | ## 初日を完了と判断する確認項目 - 公式ドメインからアプリ / サイトへ入った - パッケージと空白バックアップカードを確認した - 提供元の正規品確認を実行し、成功を完全保証とは扱っていない - ファームウェアバージョン、リリースノート、配布元、結果だけを記録した - 新しい復旧フレーズを端末自身で生成し、紙だけへ保存した - PIN / パスフレーズ / Shamirの役割を分けた - 提供される非破壊バックアップ確認を端末上で完了した - 破壊的復旧は資産ゼロのテストウォレット以外で行っていない - 受取アドレスをアプリと端末の全文で照合した - 秘密、QR、シリアル番号、個人用アドレス、資産一覧を写真・ログ・公開場所へ残していない 一つでも未確認なら、その機種の初日設定は未完了です。未完了のまま大きな資産を移さず、公式サポートへ相談するときも復旧フレーズ、PIN、パスフレーズを渡したり、画面を共有したりしません。 ## 設定後もハードウェアウォレットだけに任せない ハードウェアウォレットへ移しても、ソフトウェアウォレット側に残るサイト接続、サーバー側セッション、トークン利用許可額、Permit2、セッション鍵、スマートアカウントモジュール、EIP-7702委任は消えません。[DAppを切断しても残る権限を層ごとに確認する手順](/archives/6031)で別に棚卸しします。 すでに不審なトランザクションや残高減少がある場合は、新しい端末の設定を続ける前に[ウォレット侵害の初動切り分けガイド](/archives/6026)で追加操作を止め、秘密を含まない証拠を保存してください。 この記事にはアフィリエイトリンクや購入を促す広告はなく、遠隔設定や復旧代行も行いません。ウォレット接続や署名、シードの入力も求めません。公式製品名は手順を識別するためだけに使い、実機未確認の情報を安全評価へ置き換えていません。 ファームウェア、アプリ、初期設定UI、バックアップ形式は変わります。購入や復旧を始める前に、対象モデルの公式情報を再確認してください。実機を比較する場合も、モデル、ファームウェア、アプリ、OS、確認日を揃え、秘密情報を取り除いた記録だけを使います。 ## 確認した一次情報 - [Ledger Wallet official download](): 確認日 2026-09-01 - [Ledger purchase and Genuine Check practices](): 確認日 2026-09-01 - [Ledger Flex official onboarding](): 確認日 2026-09-01 - [Ledger on-device receive-address verification](): 確認日 2026-09-01 - [Trezor Safe 5 official setup](): 確認日 2026-09-01 - [Trezor Safe 5 authentication](): 確認日 2026-09-01 - [Trezor Safe 5 Check backup](): 確認日 2026-09-01 - [Trezor firmware hash check](): 確認日 2026-09-01 - [Trezor on-device receive-address verification](): 確認日 2026-09-01 - [Keystone 3 Pro official setup](): 確認日 2026-09-01 - [Keystone device verification](): 確認日 2026-09-01 - [Keystone firmware checksum verification](): 確認日 2026-09-01 - [Keystone Seed Phrase Check](): 確認日 2026-09-01 - [Keystone receiving-address guide](): 確認日 2026-09-01 - [OneKey Pro official setup](): 確認日 2026-09-01 - [OneKey Pro authentication](): 確認日 2026-09-01 - [OneKey App official install guide](): 確認日 2026-09-01 - [OneKey Pro firmware update log](): 確認日 2026-09-01 - [OneKey Pro SLIP39 guide](): 確認日 2026-09-01 - [CoolWallet Pro official product page](): 確認日 2026-09-01 - [CoolWallet official Help Center](): 確認日 2026-09-01 - [CoolWallet recovery verification guide](): 確認日 2026-09-01 - [CoolWallet cold-seed reuse warning](): 確認日 2026-09-01 --- # ERC-4626保管庫の仕組み｜持分計算・丸め・インフレーション攻撃 ERC-4626の資産・持分換算、4操作の丸め、事前計算と上限、初回預け入れへのインフレーション攻撃、仮想値、手数料、損失をFoundryで検証します。 正規URL: https://3mikan.com/archives/6040 著者: みかん 公開: 2026-08-31T05:00:00.000Z 更新: 2026-09-02T05:35:00.000Z ERC-4626保管庫へ資産を預けたのに、想定より持分が少ない。`previewDeposit`は十分に見えたのに、実行時の最小受取量を守れない。初回入金の直前に寄付が入り、丸めで0持分になった。 このような問題を調べる人向けに、換算式、4操作、丸め、手数料、損失を一つのローカル検証用実装で確認します。 結論は、**資産と持分を別の単位として扱い、操作直前の`totalAssets`、`totalSupply`、小数桁、該当する`preview*`、`max*`、手数料、最小受取量を同じブロックで確認すること**です。ERC-4626準拠、事前計算、仮想資産・仮想持分、小数桁オフセット、テスト通過のどれか一つだけでは、資産保全や収益を保証しません。 この記事の検証はOpenZeppelin Contracts `5.6.1`、Solidity `0.8.36`、Foundry `1.8.0`を固定したローカルコントラクトだけで行います。外部RPC、メインネットフォーク、実在ウォレット、実資産、利回り戦略は使いません。 ## 資産と持分は別の単位 [ERC-4626](https://eips.ethereum.org/EIPS/eip-4626)は、一種類のERC-20資産を受け取り、その保管庫への持分をERC-20持分として表すインターフェースです。 ```text 資産: 保管庫が保有・運用する基礎トークン 持分: 保管庫全体に対する持分を表すERC-20 ``` `totalAssets=100`、`totalSupply=100`なら、単純化した平均では1持分が1資産相当です。寄付や運用益で`totalAssets=150`になり、持分が100のままなら、1持分は約1.5資産相当になります。損失で資産が60へ減れば、持分を100持っていても100資産は引き出せません。 したがって、「1持分 = 1資産」は初期状態の一例にすぎません。ウォレットの持分残高だけでなく、同じ保管庫の`totalAssets`と`totalSupply`に対応づけて確認します。 ## 入金・発行・引き出し・`redeem`の違い 4操作は、呼び出し側が固定する単位と、保管庫が計算する単位が違います。 | 操作 | 呼び出し側が固定 | 保管庫が返す・消費 | 対応する事前計算 | 利用者側に有利にならない丸め | | --- | --- | --- | --- | --- | | `deposit(assets, receiver)` | 入れる資産 | 受け取る持分 | `previewDeposit(assets)` | 持分を切り上げず、下へ丸める | | `mint(shares, receiver)` | 欲しい持分 | 支払う資産 | `previewMint(shares)` | 必要資産を下げず、上へ丸める | | `withdraw(assets, receiver, owner)` | 受け取る資産 | 焼却する持分 | `previewWithdraw(assets)` | 必要持分を下げず、上へ丸める | | `redeem(shares, receiver, owner)` | 返す持分 | 受け取る資産 | `previewRedeem(shares)` | 資産を切り上げず、下へ丸める | 「資産量を決めて入る」のが入金、「持分量を決めて入る」のが発行です。退出側も、「資産量を決める」引き出しと「持分量を決める」`redeem`に分かれます。
3MIKANのキャラクターが上下二つの保管庫機械で資産から持分、持分から資産への換算と切り下げ・切り上げの違いを示す補助図
図は単位と方向の補助表現です。正確な入力、出力、丸めは上の比較表と再現結果を基準にしてください。
### 3資産・2持分で丸めを確認する 意図的に仮想単位を外した検証用実装を`totalAssets=3`、`totalSupply=2`へ置き、1単位を入力すると次の結果になります。 | 関数 | 丸め前 | 再現結果 | 理由 | | --- | ---: | ---: | --- | | `previewDeposit(1)` | `1 × 2 ÷ 3 = 0.66… share` | `0 share` | 発行持分は切り捨て | | `previewMint(1)` | `1 × 3 ÷ 2 = 1.5 asset` | `2 asset` | 必要資産は切り上げ | | `previewWithdraw(1)` | `1 × 2 ÷ 3 = 0.66… share` | `1 share` | 必要持分は切り上げ | | `previewRedeem(1)` | `1 × 3 ÷ 2 = 1.5 asset` | `1 asset` | 受取資産は切り捨て | 1基準単位未満はトークン上で表せません。入金で0持分になるほど小さい入力は、資産だけ保管庫へ入り、既存持分保有者へ価値を移す寄付になり得ます。フロントエンドとルーターは見積もり表示だけでなく、`minShares`や`maxAssets`などの許容価格差条件を実行呼び出しへ結びつける必要があります。 ## 換算・事前計算・上限を取り違えない ERC-4626には似た`view`関数がありますが、用途は別です。 | 関数群 | 答える質問 | 含めるもの | 含めないもの | | --- | --- | --- | --- | | `convertToShares` / `convertToAssets` | 平均的な換算量はどれくらいか | 実装が定める換算率 | 操作固有手数料や個別上限を前提にしない | | `previewDeposit` / `previewMint` / `previewWithdraw` / `previewRedeem` | 現在の条件で該当操作を行うと何単位か | 操作固有の手数料を含む実行結果に近い見積もり | `max*`が表す利用者・全体上限 | | `maxDeposit` / `maxMint` / `maxWithdraw` / `maxRedeem` | 現在その受取側・所有者へどこまで許されるか | 全体・利用者別上限 | 入出力の反対側にあたる数量の見積もり | OpenZeppelin `5.6.1`の既定実装では、`maxDeposit`と`maxMint`は制限なしを`uint256`最大値で表し、`maxRedeem(owner)`は所有者の持分残高、`maxWithdraw(owner)`はその持分の`previewRedeem`です。停止、上限、待ち行列などを持つ保管庫は上書きできます。 事前計算は、同じトランザクション内で直後に操作した場合の結果へ近づける関数ですが、価格オラクルではありません。別トランザクションになる間に寄付、手数料、損失、上限、戦略評価が変われば、先に見た値と実行値はずれ得ます。 外部価格で`totalAssets`や上限を評価する保管庫では、[DeFi Oracleの小数桁・鮮度切れ・TWAP検証](/archives/6042)の順序でフィード識別情報、更新時刻、L2稼働状態、代替手段も別に確認します。 ## 資産小数桁と持分小数桁を表示値で混ぜない 今回の資産は6小数桁です。 | 保管庫 | 資産小数桁 | 持分小数桁 | 空保管庫へ1.000000資産を入金 | | --- | ---: | ---: | ---: | | OpenZeppelin既定の小数桁オフセット0 | 6 | 6 | 1,000,000持分基準単位 | | OpenZeppelinの小数桁オフセット3 | 6 | 9 | 1,000,000,000持分基準単位 | どちらも表示上は初期率を理解できますが、基準単位の桁数は違います。`10 ** assetDecimals`を持分へそのまま使わず、資産と保管庫の`decimals()`を別々に読みます。 精度を上げると小さな入金が多くの持分基準単位へ分かれ、丸め損失を小さくできます。ただし小数桁差だけを見ても防御全体は分かりません。換算式に入る仮想資産と仮想持分も確認します。 ## 寄付型インフレーション攻撃を同じ100単位で比較する 空の保管庫に対して、次の順番をローカルテストで再現しました。 1. 攻撃者が1資産を入金する 2. 攻撃者が保管庫へ100資産を直接送金し、持分を受け取らない 3. 被害者が100資産を入金する 4. 攻撃者が最初の持分を`redeem`する | 実装 | 攻撃者初回持分 | 被害者の持分 | 攻撃者回収資産 | 攻撃者支出101に対する結果 | | --- | ---: | ---: | ---: | --- | | 仮想単位なしの意図的な脆弱実装 | 1 | 0 | 201 | 被害者の100を取り込む | | OpenZeppelin `5.6.1`既定の小数桁オフセット0 | 1 | 1 | 67 | 34の損失 | | OpenZeppelin `5.6.1`の小数桁オフセット3 | 1,000 | 1,960 | 51 | 50の損失 | 脆弱実装では、被害者の換算が`floor(100 × 1 ÷ 101)=0`です。被害者の資産は保管庫へ入りますが持分は増えず、唯一の持分を持つ攻撃者が201資産を`redeem`できます。
3MIKANのキャラクターが寄付で持分出力が細る無防備保管庫と、仮想単位と高精度持分を持つ保管庫を見比べる補助図
左は無防備な換算、右は仮想単位と細かな持分単位の概念図です。攻撃値と回収額は上の実行表を参照してください。
## 仮想資産・仮想持分・小数桁オフセットの役割 OpenZeppelin `5.6.1`の既定換算は、概念上次の値を使います。 ```text shares = assets × (totalSupply + 10^offset) ÷ (totalAssets + 1) assets = shares × (totalAssets + 1) ÷ (totalSupply + 10^offset) ``` `+1`の仮想資産と`+10^offset`の仮想持分が、空の保管庫にも初期換算率を作ります。攻撃者が寄付しても、攻撃者は実際の持分だけを持ち、仮想持分の取り分まで回収できません。小数桁オフセットを増やすと持分精度が上がり、同じ入金が0持分へ丸められるために必要な寄付も大きくなります。 ただし、これは万能な防御ではありません。 - 許容価格差条件なしで別トランザクションの事前計算を信頼する問題は残る - 実装が換算や`totalAssets`を上書きすれば前提が変わる - 仮想持分にも収益のごく一部が割り当てられ、損失時の退出順にも影響し得る - 上限、停止、待ち行列、戦略流動性、オラクル、非同期出金は別の確認対象 既定の小数桁オフセット0でも今回の攻撃は赤字になりましたが、「どの入金も損失ゼロ」「どの実装も攻撃不能」という意味ではありません。 ## 手数料は対応する事前計算へ入れる 1%の入金時・出金時手数料を資産で取る検証用実装では、次の見積もりと実行結果を確認しました。 | 操作 | 利用者が指定 | 事前計算・実行結果 | 手数料 | | --- | ---: | ---: | ---: | | 入金 | 101資産を支払う | 100持分を受け取る | 1資産 | | 発行 | 100持分を受け取る | 101資産を支払う | 1資産 | | 引き出し | 99資産を受け取る | 100持分を焼却 | 1資産 | | `redeem` | 100持分を焼却 | 99資産を受け取る | 1資産 | 入金の`assets`は手数料込み、引き出しの`assets`は受取側が実際に受け取る量として扱っています。したがって入金時手数料は`previewDeposit`の持分を減らし、`previewMint`の必要資産を増やします。出金時手数料は`previewWithdraw`の必要持分を増やし、`previewRedeem`の受取資産を減らします。 OpenZeppelin手引きの手数料拡張例そのものが、本番利用可能または監査済みであるとは保証されていません。手数料を資産で取るか持分で取るか、受取先、端数、イベント、最大値との整合まで実装ごとに確認します。 ## 損失は持分を自動で減らさず、1持分当たり資産を下げる 100資産を入金して100持分がある保管庫から、40資産の損失を直接反映すると次の状態になりました。 ```text totalAssets: 100 → 60 totalSupply: 100 → 100 previewRedeem(100): 60 assets ``` 持分残高を自動で40%焼却するのではなく、同じ持分が請求できる資産量が下がります。`totalAssets`が戦略の時価、未回収債権、手数料、ロックされた流動性をどう数えるかはERC-4626インターフェースだけでは決まりません。 利用者側は、`totalAssets`の実装、更新頻度、損失認識、引き出し可能な流動性、`maxWithdraw`を分けて見ます。持分価格表示だけで即時引き出し可能額を断定しません。 ## 送金時手数料型・残高変動資産は残高差分まで見る OpenZeppelin `5.6.1`の既定`totalAssets()`は、資産の`balanceOf(vault)`を返します。直接残高が25増える再現ケースでは、`totalAssets`も100から125へ増え、100持分の`previewRedeem`は仮想単位を含め124になりました。残高を戻すと見積もりも戻ります。 一方、1%の送金時手数料型資産を既定保管庫へ100送金した例では、保管庫が受け取ったのは99でも、事前見積もりに基づく100持分が発行されました。 ```text `deposit`の引数: 100 保管庫の受取量: 99 発行持分: 100 ``` これは「すべての送金時手数料型トークンが同じ」という主張ではなく、**要求数量と受取数量が異なる資産を既定の送金経路へ入れると会計前提が崩れる**境界例です。残高変動、コールバック付き、拒否リスト付き、戻り値が標準外の資産も、名称で一括判断せず、実際の残高差、`revert`、持分発行順を統合テストで確認します。 ## Foundry不変条件で守る4つの性質 小数桁オフセット3の保管庫に対し、4人のアクターが入金、寄付、`redeem`、損失をランダムな順序で行う検証を作りました。64回の試行 × 64回の呼び出し、合計4,096回で次を確認しています。 ```text totalAssets == asset.balanceOf(vault) totalSupply == 既知のアクターが持つ持分残高の合計 previewRedeem(totalSupply) <= totalAssets previewRedeem(previewDeposit(x)) <= x ``` 実行結果は次の通りです。 ```text unit tests: 10 passed, 0 failed invariants: 4 passed runs: 64, calls: 4096, reverts: 0 ``` 固定シード、操作別呼び出し件数、数値結果は[公開検証JSON](/fixtures/erc4626-vault-6040.json)へ保存しました。アクター、補助変数、補助台帳、対象識別子の作り方は[Foundry不変条件テスト入門](/archives/6022)で先に確認できます。 この検証は、指定した4操作、4人のアクター、入力範囲、試行回数、深さの中で反例を探します。合格は網羅的証明でも監査完了でもありません。 ## 実装・組み込みの確認順 実装または接続前は、次を同じ保管庫アドレスとブロックへ対応させます。 1. `asset()`、資産小数桁、保管庫持分小数桁を読む 2. `totalAssets`の実装と、`totalSupply`、換算率を確認する 3. 利用する操作に対応する`preview*`を選ぶ 4. 受取側 / 所有者に対応する`max*`を読む 5. 入金時・出金時手数料、上限、停止、待ち行列、戦略の流動性を確認する 6. 見積もりを`minShares`、`maxAssets`、`maxShares`、`minAssets`へ結びつける 7. 初回入金、小入金、直接寄付、損失、手数料をテストする 8. 送金時手数料型、残高変動、コールバックなど対象資産固有の残高差をテストする 9. 単体テスト、ファジング、不変条件テストを通し、見つけた最小反例を回帰テストへ戻す 保管庫が資産を移動できる利用許可額の保存先と失効は[`approve`・Permit・Permit2・ERC-7674の比較](/archives/6012)、AMMの換算率と損益を別モデルで追う場合は[インパーマネントロスとAMM式](/archives/580)を参照してください。 資産送金や引き出しが受取側コールバックを起こす場合は、[Reentrancyの関数横断・読み取り専用・トークンコールバック再現](/archives/6048)で、債務を外部呼び出し前に確定する範囲と別利用側が読む途中率を確認できます。 ## 検証コードを再実行する 検証コードを取得したディレクトリで、次のコマンドを実行します。 ```bash forge fmt --check forge test -vv node verify-results.mjs ``` | ツール | 固定バージョン | | --- | --- | | Foundry / Forge | `1.8.0` / コミット`61ae26af36320d4fa1020f7db53785885e29eeb5` | | Solidity | `0.8.36` | | OpenZeppelin Contracts | `5.6.1` / コミット`5fd1781b1454fd1ef8e722282f86f9293cacf256` | | EVM | Prague | | 最適化 | 有効 / 実行回数200 | 検証コードの`VulnerableVault`は攻撃を再現するため、意図的に仮想単位を外しています。デプロイしてはいけません。この記事には、特定保管庫への入金、利回り商品、トークン購入を促すアフィリエイトリンクはありません。スポンサーの有無と技術評価も分離します。 ## 確認した一次情報 - [ERC-4626 Tokenized Vaults](): 確認日 2026-08-31 - [OpenZeppelin ERC-4626 guide](): 確認日 2026-08-31 - [OpenZeppelin Contracts v5.6.1](): 確認日 2026-08-31 - [OpenZeppelin ERC4626 v5.6.1 source](): 確認日 2026-08-31 - [OpenZeppelin IERC4626 v5.6.1 source](): 確認日 2026-08-31 - [OpenZeppelin Math v5.6.1 source](): 確認日 2026-08-31 - [Solidity 0.8.36 documentation](): 確認日 2026-08-31 - [Foundry v1.8.0](): 確認日 2026-08-31 --- # Uniswap v4入門｜PoolManager・フック・フラッシュ会計を実装で検証 Uniswap v4の単一構成のPoolManager、PoolKey、フックの権限、unlockコールバック、差分精算、ネイティブETH、動的手数料をFoundryで検証します。 正規URL: https://3mikan.com/archives/6041 著者: みかん 公開: 2026-08-31T07:00:00.000Z 更新: 2026-09-02T05:35:00.000Z Uniswap v4のフックを実装したいが、v3までのルーターとプールを前提にすると、どこでトークンを支払い、いつ残高が確定するのか分からない。フックアドレスの末尾ビットは合っているのに交換が`revert`する。コールバック途中の差分を最終残高と読み違える。 このような開発者・組み込み担当・レビュー担当者向けに、`PoolManager`、`PoolKey`、フック権限、フラッシュ会計を一つのローカル検証で確認します。 結論は、**PoolKeyを毎回同じ5項目で特定し、`unlock` → コールバック → プール操作 → 差分確認 → `sync`・`settle`・`take` → 差分ゼロ、という流れを一つのトランザクションとして追うこと**です。フックアドレスの権限ビットは呼ばれる関数を示すだけで、そのコードが安全、正確、または有利であることを保証しません。 この記事はnpm公開版の`@uniswap/v4-core 1.0.2`と`@uniswap/v4-periphery 1.0.3`、Solidity `0.8.26`、Cancun EVM、Foundry `1.8.0`を固定したローカルコントラクトだけで検証します。外部RPC、メインネットフォーク、ウォレット接続、署名、公開トランザクション、実資産の交換やLP入金は行いません。 ## v2・v3のプール別コントラクトから単一構成へ Uniswap v2ではペアごと、v3ではプールごとにコントラクトがあり、ルーターなどの周辺機能がそれらを呼びます。v4では、複数プールの状態とトークン残高を一つの`PoolManager`が管理します。 | 世代 | プール状態の主な置き場所 | 複数経路の中間送金 | 拡張点 | | --- | --- | --- | --- | | v2 | ペアごとのコントラクト | ペア間でトークンを移す | ペア / ルーターの固定ロジック | | v3 | プールごとのコントラクト | プール間でトークンを移す | 集中型流動性、周辺機能 | | v4 | 単一の`PoolManager` | 中間は差分へ集約し、最後に精算できる | プールごとのフック | 単一コントラクト構成は「プールが一つになった」という意味ではありません。一つのコントラクト内に、異なる`PoolId`を持つ多数のプール状態があります。組み込み担当は`PoolManager`へ曖昧な通貨の組を渡すのではなく、完全な`PoolKey`を渡します。
3MIKANのキャラクターが一つのPoolManagerに接続された複数プールと、各プール固有の交換可能なフック条件を確認する補助図
一つのPoolManagerが複数プールを持ち、プールごとに0または1つのフックを指定する概念図です。正確な識別項目と権限は本文の表を基準にしてください。
## PoolKeyの5項目がプールを特定する 固定した中核ソースの`PoolKey`は次の5項目です。 ```solidity struct PoolKey { Currency currency0; Currency currency1; uint24 fee; int24 tickSpacing; IHooks hooks; } ``` | 項目 | 確認すること | 間違えた場合 | | --- | --- | --- | | `currency0` | アドレスの数値順で小さい通貨 | 順序が逆なら初期化が`revert` | | `currency1` | アドレスの数値順で大きい通貨 | 別トークンなら別プール | | `fee` | 静的手数料または動的手数料フラグ | 値が違えば別プール | | `tickSpacing` | ティックの許容間隔 | 値が違えば別プール | | `hooks` | 0アドレスまたはプール固有フック | アドレスが違えば別プール | `PoolId`は、この構造体をエンコードしたハッシュです。PoolManagerはPoolKey自体をストレージへ保存しないため、呼び出し側が毎回正しいキーを組み立てます。今回の検証ではティック間隔だけを変えたキーで交換し、初期化済みプールとは別IDになるため`PoolNotInitialized`で`revert`することを確認します。 ネイティブETHは`address(0)`の`Currency`です。アドレス順では必ず先頭になるため、ETH/トークン組ではETHが`currency0`になります。 ## フックはプールライフサイクルへ差し込む外部コントラクト 各プールは、初期化時に0または1つのフックアドレスを固定します。一つのフックコントラクトを複数プールが共有することはできます。 PoolManagerはフックアドレスの下位14ビットを見て、どのコールバックを呼ぶか判断します。 | ビット | 16進数 | コールバックまたは能力 | | ---: | ---: | --- | | 13 | `0x2000` | `beforeInitialize` | | 12 | `0x1000` | `afterInitialize` | | 11 | `0x0800` | `beforeAddLiquidity` | | 10 | `0x0400` | `afterAddLiquidity` | | 9 | `0x0200` | `beforeRemoveLiquidity` | | 8 | `0x0100` | `afterRemoveLiquidity` | | 7 | `0x0080` | `beforeSwap` | | 6 | `0x0040` | `afterSwap` | | 5 | `0x0020` | `beforeDonate` | | 4 | `0x0010` | `afterDonate` | | 3 | `0x0008` | `beforeSwap`が差分を返す | | 2 | `0x0004` | `afterSwap`が差分を返す | | 1 | `0x0002` | `afterAddLiquidity`が差分を返す | | 0 | `0x0001` | `afterRemoveLiquidity`が差分を返す | 戻り値差分のビットは、対応するコールバックのビットと組み合わせる必要があります。たとえば`beforeSwap`と`afterSwap`を使う単純なカウンターフックなら、下位マスクは`0x00c0`です。 ### 権限ビットは安全性の証明ではない 権限ビットが合っていることから分かるのは、PoolManagerがそのコールバックを呼ぶという一点です。 - コールバック内のアクセス制御が正しいか - 外部呼び出しやオラクル読み取りが操作されないか - 戻り値差分と手数料が意図どおりか - コールバックが正しい識別子と長さを返すか - 状態変更が別プールや別利用者へ影響しないか - 更新、管理者、停止、引き出し権限があるか これらはコード、コンストラクター、ストレージ、権限、動作検証、監査を別々に確認します。意図的に`revert`するフックは正しい`beforeSwap`ビットを持つためプールを初期化できますが、コールバックが`revert`するため交換全体は失敗します。ビットが正しいことと、動作が安全であることは別です。 フック内で外部価格を読む場合は、戻り値だけでなくフィード識別情報、`updatedAt`、L2シーケンサー、TWAP観測期間を分けます。[DeFiオラクルの小数桁・鮮度切れ・TWAP検証](/archives/6042)に利用側の停止条件をまとめています。 ## `unlock`コールバックとフラッシュ会計 `swap`、`modifyLiquidity`、`donate`などの残高を変える操作は、原則としてPoolManagerを`unlock`した範囲で行います。プールの初期化は残高を変えないため、`unlock`外で実行できます。 ```text 接続処理またはルーター → PoolManager.unlock(data) → PoolManagerが呼び出し元のunlockCallback(data)を呼ぶ → swap / modifyLiquidityなどを実行する → 呼び出し元・通貨ごとの残高差分を累積する → 負の差分を支払い、正の差分を受け取る → 全差分が0ならロック状態へ戻って処理を終える ``` コールバックは外部公開関数です。次の検査がなければ、第三者が任意データで直接呼び出せます。 ```solidity if (msg.sender != address(poolManager)) revert UnauthorizedCallback(); ``` ローカル検証ではコールバックを直接呼び、PoolManager以外なら`revert`することを確認します。また、`unlock`中に再度`unlock`すると`AlreadyUnlocked`です。コールバック入口の認証と、フック自身の`onlyPoolManager`は別の境界として確認します。
3MIKANのキャラクターがアンロック中に増減する二つの差分皿を同期、精算、取得でゼロへ戻し、最後に門を閉じる流れを確認する補助図
途中の差分は債権・債務の記録であり、最終ウォレット残高ではありません。正確な符号と精算操作は次の表を基準にしてください。
## BalanceDeltaの符号を呼び出し元視点で読む PoolManagerは`unlock`中、`(caller, currency)`ごとに差分を累積します。 | 差分 | 呼び出し元視点 | 終了までに行うこと | | ---: | --- | --- | | 負 | PoolManagerへ支払う債務 | `sync`、トークン支払い、`settle` | | 正 | PoolManagerから受け取る債権 | `take`、ERC-6909化、または限定的な`clear` | | 0 | 精算済み | 追加操作なし | 交換を2回行えば、1回目の出力を2回目の入力へ差分上で相殺できます。途中のトークンをプール間で転送せず、最後の正味残高だけを実際に動かすのがフラッシュ会計です。 コールバックから戻った時点でゼロでない差分が一つでも残れば、`PoolManager`は`CurrencyNotSettled`でトランザクション全体を`revert`します。トークンを一時的に`take`することはできますが、`unlock`終了までに反対側の操作や支払いで相殺しなければなりません。 ## ERC-20とネイティブETHの精算 固定した周辺機能の`DeltaResolver`に合わせ、今回のルーターは通貨ごとに次の順序で支払います。 | 通貨 | 負差分の精算 | 正差分の受取 | | --- | --- | --- | | ERC-20 | `sync(currency)` → `transferFrom(payer, PoolManager, amount)` → `settle()` | `take(currency, recipient, amount)` | | ネイティブETH | 周辺機能バージョン`1.0.3`では`sync(address(0))` → `settle{value: amount}()` | `take(address(0), recipient, amount)` | ERC-20の`sync`は、送金前の`PoolManager`残高を一時ストレージへ基準値として保存します。`settle()`は、その後に実際に増えた残高を差分へ反映します。送金してから同期すると増加前の値を失うため、順番を入れ替えません。 ネイティブETHは`msg.value`から支払額を決めます。中核の`IPoolManager`ではERC-20残高の基準点が不要なので`sync`を省略できますが、固定した周辺機能バージョン`1.0.3`の`DeltaResolver`はネイティブでも先に`sync`します。今回の検証実装は周辺機能に準拠する経路と、中核インターフェースが許す省略経路を別関数で再現し、どちらも値付き`settle`と`take`の後に差分が0になることを確認します。 余った`msg.value`はコールバック終了後に支払者へ返します。 ### `clear`は受取ではなく放棄 `clear(currency, amount)`は、トークンを送金せずに正の差分を0にします。数量は現在の正の差分と完全一致しなければ`revert`します。 `clear`した分は利用者へ届かず、`PoolManager`内から回収できなくなります。今回の検証では正の差分`9,969`を正確な数量で消去し、受取先残高が増えないことを確認します。これは危険境界を示す専用の確認であり、通常の経路では正の差分を`take`します。 通常の受取を`clear`へ置き換えず、放棄してよいごく少額と完全一致する数量に限定します。 ## 静的手数料・動的手数料・フック独自収支を分ける v4では「手数料」という語が複数の層に現れます。 | 種類 | どこで決まるか | 変更の境界 | | --- | --- | --- | | 静的LP手数料 | `PoolKey.fee` | 手数料を変えると別PoolKey・別プール | | 動的LP手数料 | `PoolKey.fee = 0x800000` | フックだけが保存済み手数料を更新できる | | 交換ごとの上書き | 動的プールの`beforeSwap`戻り値 | `0x400000 | fee`で当該交換だけ上書き | | プロトコル手数料 | PoolManagerのプロトコル設定 | フック手数料やLP手数料とは別 | | フック独自収支 | フックの戻り値差分や独自会計 | フックコードと権限を個別レビュー | LP手数料の単位は1基準点の100分の1です。`3000`は`0.30%`、`500`は`0.05%`です。最大は`1_000_000`、つまり100%です。 ローカル検証の動的手数料フックは、保存済み手数料の初期値が`0`のプールを、次の交換の`beforeSwap`で`4,000`（0.40%）へ更新します。これは保存済み手数料更新の検証であり、`0x400000 | fee`を返す交換ごとの上書きの検証ではありません。 動的であること自体は手数料の妥当性を保証しません。手数料入力のソース、更新者、更新頻度、操作可能性、上限、失敗時の挙動を確認します。 ## ローカル環境で再現する正常系と失敗系 同一の`PoolManager`へERC-20/ERC-20プールとネイティブETH/ERC-20プールを初期化し、三つのフックを分けて確認します。 | 例 | 確認する証拠 | 期待結果 | | --- | --- | --- | | 単純なフック | 権限マスク、変更前・変更後の件数、交換差分 | 変更前と変更後が各1回、最終差分0 | | 動的手数料フック | 動的フラグ、`beforeSwap`、保存済み手数料 | 0から0.40%へ更新、最終差分0 | | `revert`フック | 正しい`beforeSwap`ビット、`revert`識別子 | プール初期化は成功、交換全体は`revert` | | ERC-20精算 | コールバック中の負差分、同期、送金、`settle` | PoolManager残高が増え、差分0 | | ネイティブ精算 | 周辺機能同期あり / 中核同期省略、値付き`settle` | 両パスでETHとトークンを精算し、差分0 | | `clear` | 交換出力の正差分、受取先残高 | 正確な差分だけ0、受取先は受け取らない | | 未清算 | コールバックから戻る直前のゼロでない差分 | `CurrencyNotSettled`で全体`revert` | | 不正コールバック | コールバックの直接呼出元 | `UnauthorizedCallback`で`revert` | | 誤ったPoolKey | ティック間隔だけを変更 | `PoolNotInitialized`で`revert` | 実行履歴は次の順序を確認します。 ```text PoolManager.unlock → SettlementRouter.unlockCallback → PoolManager.swap → ERC-20ならPoolManager.sync → token transferFrom → ERC-20はsettle、ネイティブETHは周辺機能の経路でsync → value付きsettle → 正の差分をPoolManager.take → ゼロでない差分の件数 = 0 ``` 固定したローカル検証のERC-20正確入力では、交換直後の差分が`(-10,000, +9,969)`、精算後が`(0, 0)`でした。ネイティブETHでは入力上限`0.01 ETH`に対し`6,035,841,794,200,769 wei`を`settle`し、トークン側の正の差分`5,981,737,760,509,662`を取得して、未使用値を返しました。精算を省いた例はコールバック終了直前に`(-10,000, +9,969)`が残り、`CurrencyNotSettled`で全体が`revert`します。 数値、検証項目、固定したソース情報、制約は[公開検証JSON](/fixtures/uniswap-v4-6041.json)へ記録しています。 `revert`したトランザクションのイベントと状態変更は残りません。失敗例は、残ったイベントを証拠にせず、期待したエラー識別子と`revert`後も残高・カウンターが不変であることを証拠にします。 ## 固定した検証環境 再現に使ったバージョンと12の検証項目に加え、ERC-20、ネイティブETHの2経路、`clear`、未清算差分の詳しい実行履歴を[公開検証JSON](/fixtures/uniswap-v4-6041.json)へ記録しています。 | 構成要素 | 固定値 | | --- | --- | | `@uniswap/v4-core` | npm `1.0.2` / `gitHead` `59d3ecf53afa9264a16bba0e38f4c5d2231f80bc` | | `@uniswap/v4-periphery` | npm `1.0.3` / `gitHead` `60cd93803ac2b7fa65fd6cd351fd5fd4cc8c9db5` | | Foundry / Forge | `1.8.0` / コミット`61ae26af36320d4fa1020f7db53785885e29eeb5` | | Solidity / EVM | `0.8.26` / Cancun | | 最適化 | via IR、実行回数`200` | v4-coreの公式リリースは確認時点で`v4.0.0`、タグのコミットは`e50237c43811bd9b526eff40f26772152a42daba`です。検証ではリリースタグを曖昧に追従せず、npmパッケージのバージョン・完全性・`gitHead`を固定します。v4-peripheryは確認時点でGitHubリリースがないため、同様にnpmパッケージと`gitHead`を基準にします。 ## 一時ストレージはトランザクションが終わるまで共有される v4中核は`unlock`状態、通貨差分、ゼロでない差分の件数、同期した準備金などにEIP-1153の`TSTORE`と`TLOAD`を使います。 一時ストレージはトランザクション終了時に破棄され、`revert`にも追従します。しかし「コールバックから戻った瞬間に自動で消えるストレージ」ではありません。同じトランザクション内の入れ子呼び出しや再入からも、そのトランザクションに属する状態が見えます。 したがって、フラッシュ会計で最終差分が0になることだけではフックの安全性を証明できません。外部呼び出しの前後、コールバック送信者、プールキー、フック状態、戻り値差分、再入保護機構、資産の流れを合わせて確認します。一時ストレージ単体の挙動は[TSTORE・TLOADのローカル検証](/archives/6021)で確認できます。 [Reentrancyの分類とFoundry再現](/archives/6048)では、フックを含むコールバック、途中の読み取り、関数横断、`delegatecall`モジュールを、同じ不変条件と保護範囲の観点で横断します。 PoolManager内部債権のERC-6909化を、ウォレット向けマルチトークンの標準選定と同一視はできません。[ERC-6909とERC-1155の実装比較](/archives/6049)で、ID別利用許可額、標準一括処理、受取側コールバック、イベント再構築、製品対応の確認範囲を分けています。 ## 実装・レビュー時の確認項目 ### Poolとフック - `currency0 < currency1`か - 手数料、ティック間隔、フックを含む完全な`PoolKey`を固定したか - フックアドレスの下位14ビットと実装コールバックが一致するか - 権限ビットを安全性評価へ流用していないか - フックがPoolManager以外からのコールバックを拒否するか - 動的手数料のソース、上限、更新条件を確認したか ### コールバックと精算 - `unlockCallback`がPoolManagerだけを許可するか - 操作直後に通貨別差分を記録したか - ERC-20は同期より後に送金しているか - 負差分は`settle`し、正差分は`take`しているか - `clear`する数量と放棄理由を明示したか - コールバック終了前に全通貨差分が0か ### 利用者向け表示 - 見積もり時のPoolKey、手数料、フック、ブロックを表示または記録できるか - コールバック途中の差分をウォレット最終残高として見せていないか - 最低出力、有効期限、経路、価格影響を実行条件へ結びつけたか - トランザクションレシートと最終トークン残高をトランザクション後に読み直すか LPの価格変動と集中流動性の前提は[インパーマネントロスの計算](/archives/580)、見積もりと実行差は[価格影響・許容価格差・MEVの違い](/archives/741)で確認できます。保管庫の資産・持分会計とプールの通貨差分は別モデルなので、[ERC-4626の持分計算](/archives/6040)と混同しないでください。 ## まとめ Uniswap v4は、フックを追加できるだけのv3ではありません。複数プールを持つ単一構成のPoolManager、5項目のPoolKey、トランザクション中の差分、`unlock`コールバック、最後の精算が一つの設計です。 調査時は、**PoolKey → フック権限とコード → コールバック送信者 → 操作差分 → `sync`・`settle`・`take` → 差分ゼロ → トランザクションレシートと最終残高**の順に対応させます。権限ビット、動的手数料、動作検証の通過のどれか一つを、フックやプール全体の安全性評価へ置き換えないことが重要です。 この記事には特定プールへの交換、LP入金、トークン購入を促す導線はありません。将来開発者ツールや監査サービスを紹介する場合も、広告表記とローカル検証結果を分離します。 ## 確認した一次情報 - [Uniswap v4 protocol overview](): 確認日 2026-08-31 - [Uniswap v4 architecture](): 確認日 2026-08-31 - [Uniswap v4 PoolManager](): 確認日 2026-08-31 - [Uniswap v4 hooks](): 確認日 2026-08-31 - [Uniswap v4 flash accounting](): 確認日 2026-08-31 - [Uniswap v4 dynamic fees](): 確認日 2026-08-31 - [Uniswap v4-core PoolManager pinned source](): 確認日 2026-08-31 - [Uniswap v4-core Hooks pinned source](): 確認日 2026-08-31 - [Uniswap v4-core PoolKey pinned source](): 確認日 2026-08-31 - [Uniswap v4-periphery BaseHook 1.0.3 pinned source](): 確認日 2026-08-31 - [Uniswap v4-periphery DeltaResolver 1.0.3 pinned source](): 確認日 2026-08-31 - [EIP-1153 transient storage](): 確認日 2026-08-31 - [Foundry v1.8.0](): 確認日 2026-08-31 --- # DeFiオラクルの読み方｜小数桁・鮮度・TWAP・L2停止を検証 DeFiの価格を、フィードのアドレス、小数桁、ラウンド、更新時刻、L2シーケンサー、TWAP、代替フィードに分け、利用可否と停止条件をFoundryで検証します。 正規URL: https://3mikan.com/archives/6042 著者: みかん 公開: 2026-08-31T07:30:00.000Z 更新: 2026-09-02T05:35:00.000Z DeFiの画面に「1 ETH = 2,500 USD」と出ていても、コントラクトが同じ価格を安全に使えるとは限りません。価格フィードのアドレスや通貨ペアを取り違えた、8桁の値を18桁として扱った、古いラウンドを最新とみなした、L2シーケンサー復旧直後に清算へ使った、といった別々の失敗が同じ「価格がおかしい」に見えます。 この記事は、貸付、保管庫、デリバティブ、ステーブルコインへ価格を組み込む開発者と、価格に関するインシデントを調べる人向けです。**チェーン → フィード識別情報 → ラウンド → 時刻 → L2稼働 → 単位変換 → 範囲 → 代替情報源**の順に確認し、価格を「利用可能」「古い」「異常」「未確定」へ分けられる状態を目指します。 結論は、`latestRoundData()`が返っただけでは不足です。アプリケーション側がフィード識別情報、`decimals`、`updatedAt`、L2猶予期間、許容範囲、代替フィードの方針を明示し、DEX価格なら現在値と観測期間を分けて判断します。 検証にはSolidity `0.8.36`、Cancun EVM、Foundry `1.8.0`のローカルコントラクトを使いました。公開データはEthereumメインネットの過去ブロックへ読み取り専用で固定した値だけを再利用し、ウォレット、秘密鍵、署名、公開トランザクション、清算、実資産操作は行いません。 ## 最初に価格ではなく読み取り条件を固定する 調査を始めるときは、USD表示をメモする前に次の項目を一組で残します。 | 項目 | 確認する内容 | 省くと起きる混同 | | --- | --- | --- | | チェーン | チェーンID、ネットワーク、L1・L2 | 別チェーンの同じアドレスを読む | | フィード識別情報 | プロキシアドレス、説明、基準通貨・見積通貨 | ETH/USDとBTC/USD、USD建てとETH建てを混ぜる | | 精度 | `decimals()` | `250019228748`を2,500.19228748以外に変換する | | ラウンド | `roundId`、`answer`、`startedAt`、`updatedAt` | 値だけを最新とみなす | | ブロック | 番号、ハッシュ、タイムスタンプ | 複数読み取りが別時点になる | | 方針 | 最大経過時間、範囲、L2猶予、代替フィード | 失敗時に止めるか代替値を使うか決まらない | [Chainlink Data Feeds API Reference](https://docs.chain.link/data-feeds/api-reference)は、利用側がプロキシアドレスを`AggregatorV3Interface`として読む形を示しています。`decimals()`は回答の精度、`description()`はフィードの説明、`latestRoundData()`はラウンドと時刻を返します。 アドレスをUIや記憶から転記せず、対象チェーンの公式フィード一覧とデプロイ済みバイトコードを照合します。`description()`は有用な確認項目ですが、文字列だけで正しいプロキシを発見する仕組みではありません。**公式アドレスを先に固定し、説明を二重確認に使う**順序です。
価格ソースからフィード識別情報、ラウンド時刻、L2稼働、単位変換、範囲判定、利用側操作までを別々の検査台として並べた概念図
価格値へ到達する前に、ソース、識別情報、時刻、チェーン固有条件を順番に通します。
## 小数桁と通貨ペアを確認してから正規化する EthereumメインネットETH/USDフィードの固定観測では、元の回答値が`250019228748`、`decimals()`が`8`でした。 ```text 250019228748 / 10^8 = 2500.19228748 USD per ETH ``` ここで`1e18`形式へ揃えるなら、8桁から18桁へ`10^(18 - 8)`を掛けます。ただし、フィードごとに8桁だと決め打ちしてはいけません。まず実際の`decimals()`がアプリケーション設定と一致することを確認し、指数と回答の範囲からオーバーフローしないことを検査します。 ```solidity uint8 actualDecimals = feed.decimals(); if (actualDecimals != expectedDecimals) revert WrongDecimals(); (uint80 roundId, int256 answer,, uint256 updatedAt, uint80 answeredInRound) = feed.latestRoundData(); if (answer <= 0) revert NonPositiveAnswer(); if (updatedAt == 0 || updatedAt > block.timestamp) revert InvalidTimestamp(); if (block.timestamp - updatedAt > maxStaleness) revert StalePrice(); uint256 priceE18 = uint256(answer) * 10 ** (18 - actualDecimals); ``` 基準通貨と見積通貨の向きも別に確認します。ETH/USDの回答は1 ETHあたりのUSDです。USD/ETHとして使うなら逆数計算が必要で、2つのフィードから合成ペアを作る場合は両方の小数桁、鮮度、符号、丸めを独立して確認します。 ## ラウンドが返っても`updatedAt`が古ければ止める `latestRoundData()`は次の5項目を返します。 | 項目 | 読み方 | 判定上の注意 | | --- | --- | --- | | `roundId` | プロキシが返すラウンドID | 価格の大小や新しさをIDだけで決めない | | `answer` | フィード固有精度の値 | ゼロ、負値、範囲外をアプリケーション側で拒否する | | `startedAt` | ラウンド開始時刻 | 価格鮮度には通常`updatedAt`を使う | | `updatedAt` | ラウンドの回答更新時刻 | `0`、未来、最大経過時間超過を拒否する | | `answeredInRound` | 回答が確定したラウンドを表す旧来の項目 | 現行API資料では非推奨。単独の鮮度証拠にしない | 現在のAPI資料は`answeredInRound`を非推奨としています。本記事のローカル検証では、従来形式のラウンド情報の不整合を見落とさないため`answeredInRound < roundId`も拒否しますが、**主要な鮮度判定は`updatedAt`とアプリケーションの最大経過時間**です。 ### ハートビートと偏差しきい値は鮮度切れ上限そのものではない 価格フィードは、価格変化が偏差しきい値を超えた場合やハートビート時間が経過した場合など、フィード固有の条件で更新されます。値は資産、ネットワーク、フィード型、時点で異なります。 利用側の`maxStaleness`は、アプリケーションがそのフィードを何秒まで利用できると判断するかという別の方針です。公式フィードページに掲載された現在の更新条件、市場の特性、プロトコルの清算や停止設計を確認し、「ハートビートが1時間だから常に3,600秒までは安全」のように同一視しません。 ローカル検証では最大経過時間を`3,600秒`に固定し、ちょうど境界までは受理、`3,601秒`前の`updatedAt`は`StalePrice`で停止させました。この数値は検証条件であり、すべてのフィードへの推奨値ではありません。 ## ゼロ・負値・外れ値を別の失敗として扱う 回答の異常は一つにまとめず、原因と方針を分けます。 | 観測済み状態 | ローカル結果 | 判断 | | --- | --- | --- | | `answer == 0` | `NonPositiveAnswer` | 0を無料・無価値と解釈せず停止 | | `answer < 0` | `NonPositiveAnswer` | 価格用途では拒否。フィード型を再確認 | | `decimals != 8` | `WrongDecimals` | 古い換算式を続行しない | | `updatedAt == 0` | `MissingTimestamp` | 未初期化・不完全なデータとして停止 | | `updatedAt > now` | `FutureTimestamp` | 時刻とチェーンの条件を確認 | | 正規化済み価格が設定範囲外 | `OutOfRange` | フィードが返した事実と採用可否を分離 | 検証用の利用側はETH/USDの許容範囲を`1,000〜5,000 USD`へ固定し、`6,000 USD`を外れ値として拒否します。これも記事執筆時の相場予測ではなく、サーキットブレーカーが動くことを再現する値です。実装では上限・下限の根拠、更新権限、停止後の動作をプロトコルごとに決めます。 ChainlinkのAPI資料も、多くのフィードで集約者の`minAnswer`と`maxAnswer`がサーキットブレーカーとして使われていないため、必要ならアプリケーション側で設計するよう案内しています。 ## L2ではシーケンサーの状態を価格より先に読む L2上でシーケンサーが停止すると、L2上の価格フィードが値を返していても、利用者が通常どおりトランザクションを投入できるとは限りません。清算側だけが復旧直後に動ける状態を避けるため、価格フィードより先にSequencer Uptime Feedを確認します。 [Chainlink L2 Sequencer Uptime Feeds](https://docs.chain.link/data-feeds/l2-sequencer-feeds)の例では、`answer == 0`が稼働、`answer == 1`が停止です。稼働へ戻った後も`block.timestamp - startedAt`が猶予期間を超えるまで価格を使いません。 ```solidity (, int256 status, uint256 startedAt,,) = sequencerFeed.latestRoundData(); if (status != 0) revert SequencerDown(); if (startedAt == 0 || startedAt > block.timestamp) revert InvalidSequencerRound(); if (block.timestamp - startedAt <= gracePeriod) revert GracePeriodNotOver(); ``` 公式資料の例は猶予期間を`3,600秒`としています。ローカル検証も同じ値を使い、停止中、復旧から3,600秒ちょうど、3,600秒超過を別テストにしました。実際のプロトコルでは対象L2の稼働状況フィードアドレス、障害時の扱い、出金経路、利用者保護を確認します。 Arbitrumではフィード未初期化時に`startedAt == 0`となる場合があることも公式資料に明記されています。0を「十分昔から稼働している」と計算せず、未確定として停止します。
L2シーケンサーの停止・復旧猶予と、短時間に動く現在価格を長い観測期間で平均するTWAPを二つの時間軸で比較した概念図
L2の利用可否と価格の観測期間は、どちらも時間を使いますが別の判定です。
## 現在値とTWAPは同じプールでも見ている時間が違う DEXの現在価格は、現在の準備金または現在のティックから得る瞬間値です。TWAPは過去の観測期間における累積値の差から平均を求めます。TWAPにしただけで価格操作を防げるわけではありませんが、短時間だけ価格を動かす操作の影響を観測期間全体へ薄められます。 ローカルAMM観測では、最初の900秒を`2,000`、その後60秒を`4,000`としました。 ```text (2,000 × 900秒 + 4,000 × 60秒) / 960秒 = 2,125 ``` | 読み取り | 結果 | 意味 | | --- | ---: | --- | | 操作後の現在値 | 4,000 | 現在の準備金をすぐ反映 | | 60秒TWAP | 4,000 | 観測期間全体が変更後なので現在値と同じ | | 960秒TWAP | 2,125 | 900秒分の以前の価格を含む | | 961秒TWAP | `revert` | そこまで古い観測がない | Uniswap v3の`OracleLibrary.consult`は`secondsAgo`と0の2点を`observe`へ渡し、`tickCumulative`の差を観測期間で割って算術平均ティックを得ます。ティックから得る価格は幾何平均に対応し、単純なUSD価格の算術平均とは同じではありません。 さらに、プールの観測枠数、最古の観測、観測期間、範囲内流動性、基準通貨と見積通貨の小数桁を確認します。Uniswap v3中核は最初のオラクル配列長が1で、追加スロットは誰かがストレージ費用を払って増やす設計です。要求観測期間より古い観測がなければ`OLD`相当で`revert`し得ます。 価格変化、許容価格差、MEVは[価格影響と最低出力を分ける記事](/archives/741)、トークンコントラクト自身の手数料・残高変動・停止・売却制限は[トークンを送れない・売れないときの確認順](/archives/6061)で分けます。Uniswap v4のPoolManagerとフック内部でオラクルを読む境界は[PoolManager・フック・フラッシュ会計の検証](/archives/6041)で確認できます。 ## 代替フィードは「何でも返す予備」ではない 主フィードが古いときに代替フィードへ切り替える場合も、代替フィードの識別情報、精度、鮮度、範囲を同じように検証します。主フィードと代替フィードが同時に有効なのに大きく離れているなら、都合のよい方を選ばずサーキットブレーカーで停止します。 | 主フィード | 代替フィード | ローカル方針 | | --- | --- | --- | | 有効 | 有効・差5%以内 | 主フィードを採用し、差を監視 | | 古い | 有効 | 代替フィードを採用し、その事実を返す | | 有効 | 有効・差5%超 | `SourcesDiverge`で停止 | | 無効 | 無効 | `BothFeedsInvalid`で停止 | | シーケンサー停止 | どの状態でも | 代替フィードへ進まず停止 | 同じL2上の代替フィードは、シーケンサー停止を解決しません。L1の情報源、DEX TWAP、管理者が手動設定する値、最後に正常だった価格などを組み合わせる場合は、更新時点、チェーン間遅延、価格操作への耐性、権限、停止中の操作を個別に設計します。 保管庫の資産・持分計算とオラクル評価を分けるには[ERC-4626の丸め・インフレーション攻撃検証](/archives/6040)、複数RPC読み取りを同じ時点へ固定する方法は[Ethereum RPCの固定ブロック検証](/archives/6024)を参照してください。 シーケンサーの利用可否とトランザクション手数料は別の観測です。Base・Arbitrum Oneのトランザクションレシートと手数料見積もりを分ける手順は、[L2手数料の構成要素別再計算](/archives/6054)で確認できます。 固定ブロックをFoundryへ読み込み、`warp`後の鮮度切れやプロバイダー差を検査するときは、[Foundryフォークテストの状態出所とシミュレーション境界](/archives/6051)で、チェーン由来ラウンドとローカル時刻変更を分けて記録します。 ## 公開フィードをブロック番号とハッシュへ固定して読み戻す 公開観測はEthereumメインネットブロック`25,869,830`へ固定しています。 | 項目 | 固定結果 | | --- | --- | | フィード | `0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419` | | ペア / 小数桁 | `ETH / USD` / 8 | | ブロックハッシュ | `0x53d1375a96ad48b9a0f3e30152c0f01dc142fca8dce2f22ee95270a27b365294` | | ブロックタイムスタンプ | `2026-08-30T18:17:59Z` | | ラウンドID | `129127208515966894439` | | 元の回答値 | `250019228748` | | startedAt | `2026-08-30T17:24:51Z` | | `updatedAt` | `2026-08-30T17:26:11Z` | | 正規化済み | `2,500.19228748 USD per ETH` | 二つの公開接続先でブロックハッシュとラウンド情報を照合しました。`updatedAt`がブロックタイムスタンプより約52分前でも、それだけで異常とは限りません。フィードが各ブロックで更新されるわけではないため、対象フィードの更新条件とアプリケーションの最大経過時間を合わせて判断します。 この値は2026-08-30の過去スナップショットであり、現在価格や投資判断には使えません。固定したブロック、元のラウンド値一式、ローカルでの失敗結果は[公開検証JSON](/fixtures/oracle-validation-6042.json)にまとめています。 ## 組み込みとインシデント調査のチェックリスト - [ ] チェーンIDとフィードプロキシアドレスを公式一覧で固定した - [ ] `description()`で基準通貨と見積通貨を二重確認した - [ ] `decimals()`を読み、変換前後の単位を書いた - [ ] `roundId`、`answer`、`startedAt`、`updatedAt`を同じブロックで保存した - [ ] ゼロ、負値、未来時刻、古い、オーバーフロー、範囲外を止めた - [ ] ハートビート・偏差しきい値とアプリケーション最大経過時間を分けた - [ ] L2ではシーケンサーの回答、`startedAt`、猶予期間を先に確認した - [ ] DEXでは現在値、観測期間、最古の観測、流動性、トークン小数桁を確認した - [ ] 代替フィードも同じ基準で検証し、ソース乖離時の停止条件を決めた - [ ] トランザクションレシート、イベント、価格読み取り、最終状態を同じブロック識別情報へ結び付けた オラクルのブランド、正常な戻り値、TWAPという名前だけでは、安全性も清算結果も保証できません。どのソースを、どの時点と単位で、どの停止条件の下で使ったかを残すと、値の異常と利用側方針の異常を分けて調査できます。 この記事には特定資産、貸付市場、利回り商品への入金や取引を促す導線はありません。将来オラクル、RPC、監視、監査サービスを紹介する場合も、広告表記と技術検証を分離します。 ## 確認した一次情報 - [Chainlink Using Data Feeds on EVM Chains](): 確認日 2026-08-31 - [Chainlink Data Feeds API Reference](): 確認日 2026-08-31 - [Chainlink Selecting Quality Data Feeds](): 確認日 2026-08-31 - [Chainlink L2 Sequencer Uptime Feeds](): 確認日 2026-08-31 - [Chainlink ETH/USD Ethereum Mainnet feed page](): 確認日 2026-08-31 - [Uniswap v3 OracleLibrary pinned source](): 確認日 2026-08-31 - [Uniswap v3 Oracle v1.0.1 source](): 確認日 2026-08-31 - [Ethereum JSON-RPC API](): 確認日 2026-08-31 - [EIP-1898 blockHash in JSON-RPC](): 確認日 2026-08-31 - [Foundry v1.8.0](): 確認日 2026-08-31 --- # SELFDESTRUCTはコントラクトを消す？EIP-6780後のコード・保存領域・再デプロイ EIP-6780後のSELFDESTRUCTを、コード、保存領域、残高、ノンス、同一トランザクションの例外、CREATE2での再デプロイに分け、ShanghaiとCancunで検証します。 正規URL: https://3mikan.com/archives/6043 著者: みかん 公開: 2026-08-31T08:10:00.000Z 更新: 2026-09-02T05:35:00.000Z `SELFDESTRUCT`を「コントラクトを完全に削除する命令」と覚えているなら、その説明には実行チェーンのフォークとトランザクション境界が足りません。EthereumメインネットでDencunが有効になった後、以前から存在するコントラクトがこの命令を実行しても、原則として**全残高を受取人へ送り、現在の呼び出しフレームを終了するだけ**です。コード、ストレージ、アカウント自体は削除されません。 例外は、コントラクトを作成したのと同じトランザクション内で`SELFDESTRUCT`を実行した場合です。このときは旧挙動が保たれ、トランザクションの終わりにコードやストレージを含むアカウントが削除されます。 この記事は、デプロイファクトリーや更新機構を実装する開発者、古い攻撃手法やメタモーフィック（変形可能）コントラクトを調べる人、EVMバージョン差を確認する人向けです。**チェーンとフォーク → 作成時トランザクション → `SELFDESTRUCT`を実行したトランザクション → コード・ストレージ・残高・ノンス → CREATE2アドレス計算の入力 → 次のトランザクション**の順に確認し、「消えた」「残った」「再デプロイできる」を分けます。 検証にはSolidity `0.8.36`、Foundry `1.8.0`、Anvil `1.8.0`、viem `2.56.0`を使いました。同じShanghai互換バイトコードを、ShanghaiとCancunに固定した2つのローカルチェーンで実行しています。公開RPC、メインネットフォーク、ウォレット、実資産、公開トランザクションは使っていません。 ## 最初にチェーン、フォーク、トランザクションを固定する EIP-6780はハードフォークによる合意規則の変更です。EthereumメインネットではDencunの一部として、タイムスタンプ`1710338135`、2024年3月13日13:55 UTCに有効になりました。 この日時を、すべてのEVMチェーンへそのまま当てはめてはいけません。L2、サイドチェーン、非公開チェーン、ローカルノードでは、同じ命令コードでもフォークの有効化時期や設定が異なります。 | 最初に残す項目 | 何を確認するか | 省くと起きる混同 | | -------------- | ----------------------------------- | ----------------------------------------- | | チェーン | チェーンID、ネットワーク、クライアント | Ethereumメインネットのフォーク時刻を別チェーンへ使う | | ブロック | 番号、ハッシュ、タイムスタンプ | Cancun前後を混ぜる | | 実行時フォーク | Shanghai / Cancun以降 | コンパイラー設定だけで実行挙動を決める | | 作成トランザクション | コントラクトを作ったトランザクション | 同一トランザクション例外を判定できない | | 破棄トランザクション | `SELFDESTRUCT`を実行したトランザクション | 同じブロックを同じトランザクションと誤認する | | 変更後の状態 | 次ブロックのコード、スロット、残高、ノンス | 実行履歴に命令コードがあるだけで削除と断定する | Solidityの資料は、Cancun以降の挙動がネットワーク全体の変更であり、コンパイル時の`--evm-version`は稼働中チェーン上の`SELFDESTRUCT`の意味を決めないと明記しています。コンパイラーの対象は生成バイトコードの互換性に関係しますが、既にデプロイ済みのコントラクトへどのフォーク規則を適用するかは実行側のEVMが決めます。
同じコントラクトのコード、ストレージ、残高、ノンスを、旧ルールとEIP-6780後のルールで別々のレーンに分けて比較する概念図
残高の移動とアカウント削除は別の状態変化です。4項目を分けて読みます。
## コード・ストレージ・残高・ノンスは別々に読む ローカル検証では、CREATE2で作ったコントラクトを次の初期状態へ固定しました。 | 項目 | `selfdestruct`前 | | -------------- | -------------: | | 実行時コード | 195バイト | | ストレージスロット0 | `77` | | 残高 | `1 ETH` | | ノンス | `1` | 別トランザクションで同じ`destroy(beneficiary)`を実行し、トランザクション確定後に`eth_getCode`、`eth_getStorageAt`、`eth_getBalance`、`eth_getTransactionCount`を読み直した結果です。 | 実行規則 | コード | スロット0 | 残高 | ノンス | 受取人 | | -------- | --------: | -----: | ------: | ----: | ----------: | | Shanghai | 0バイト | `0` | `0 ETH` | `0` | `+1 ETH` | | Cancun | 195バイト | `77` | `0 ETH` | `1` | `+1 ETH` | 両方で`SELFDESTRUCT`命令は1回実行され、受取人へ1 ETHが移りました。しかし、Cancunではコードハッシュ、ストレージ、ノンスが実行前と同じです。**残高が0になったことは、コントラクトが消えた証拠ではありません。** 逆にShanghaiのローカル規則では、トランザクション終端後にコード、スロット、アカウントノンスが空になりました。それでも過去ブロック、トランザクション、実行履歴まで消えるわけではありません。状態からアカウントが削除されることと、ブロックチェーン履歴から情報が消去されることも分けます。 呼び出しの途中で`address.code.length`を読んだ値だけにも注意が必要です。旧規則でも削除はトランザクション終端で確定するため、同じトランザクション内の観測を変更後の状態の代わりにできません。トランザクションレシートが確定するのを待ち、確定ブロックを指定して4項目を読み直します。 ## 同一トランザクションで作成して破棄した場合だけ例外になる EIP-6780は、コントラクトが作られたのと同じトランザクションで`SELFDESTRUCT`した場合に旧挙動を残します。外部アカウントから直接作るコントラクト作成トランザクションだけでなく、`CREATE`や`CREATE2`によって作られた場合も、その処理が始まった時点が作成時です。 検証では、コンストラクターの中で`SELFDESTRUCT`する小さなコントラクトをCREATE2で作りました。ShanghaiとCancunのどちらでも、トランザクション確定後は次の状態です。 | 項目 | 確定後 | | -------------- | ------: | | 実行時コード | 0バイト | | ストレージスロット0 | `0` | | 残高 | `0 ETH` | | ノンス | `0` | ただし、同じトランザクション内で同じファクトリー、ソルト、初期化コードを使って2回目のCREATE2を実行すると、返り値はゼロアドレスでした。EIP-1014が説明するように、`SELFDESTRUCT`は同じトランザクションの途中でコードやノンスを即時消去しないため、作成時衝突を避けられません。 次のトランザクションではアカウントが空になっているため、1回目のCREATE2は同じ予定アドレスで再び成功しました。整理すると、**同じトランザクションの2回目は失敗し、次トランザクションの1回目は成功する**という境界です。 「同じブロックで別トランザクション」と「一つのトランザクション内の別呼び出し」も同じではありません。調査記録にはブロック番号だけでなくトランザクションハッシュと呼び出し実行履歴を残します。 ## CREATE2はソルトだけで同じアドレスを作るわけではない CREATE2の予定アドレスは、次の原像から計算されます。 ```text address = keccak256( 0xff ++ factory_address ++ salt ++ keccak256(init_code) )[12:] ``` 固定するのは、次の3項目です。 1. CREATE2を実行するファクトリーアドレス 2. 32バイトソルト 3. コンストラクター引数を含む初期化コードのハッシュ ローカル検証の永続対象では、ファクトリーが`0x5FbD…0aa3`、ソルトが`0xa4a8…3336`、初期化コードハッシュが`0x4374…433d`で、予定アドレスは`0x9e48…9ab4`でした。コンストラクター引数を`77`から`78`へ変えると初期化コードハッシュが変わるため、同じソルトでも別アドレスになります。 ファクトリー、ソルト、コンストラクター、リンク済みライブラリー、メタデータ、プロキシ初期化関数まで含む一般的な予測手順は、[CREATE2アドレスをSolidityとviemで独立計算する記事](/archives/6044)で扱っています。 Shanghai規則では、既存対象を別トランザクションで`selfdestruct`した後、同じ3項目を使う次トランザクションのCREATE2が成功し、`0x9e48…9ab4`へコードとスロット`77`が戻りました。Cancun規則ではコードとノンスが残るためCREATE2が衝突し、ゼロアドレスを返しました。
ファクトリー、ソルト、初期化コードから同じ予定アドレスへ進み、既存コントラクトは衝突し、作成直後に消える例だけが次トランザクションで再利用される流れを示す概念図
予定アドレスの計算、現在のアカウント状態、トランザクション境界の3つが揃って初めて再デプロイ可否を判断できます。
CREATE2のアドレス計算そのものはEIP-6780で変わっていません。未デプロイアドレスを先に計算して、後で一度だけデプロイする未デプロイ用途も、`SELFDESTRUCT`による再デプロイとは別です。[ERC-6492の未デプロイアカウント検証](/archives/6018)では、ファクトリー、ソルト、初期化コードから予定署名者を結び付ける例を確認できます。 ## メタモーフィックコントラクトとプロキシ更新を混同しない 古典的なメタモーフィックコントラクトは、一定の初期化コードから外部状態に応じた実行時コードを返し、既存コントラクトを`SELFDESTRUCT`してから同じCREATE2アドレスへ別コードを置く設計です。Cancun以降、以前のトランザクションから存在するコントラクトは削除されないため、この再デプロイの繰り返しは成立しません。 すべてのCREATE2ファクトリーや更新が壊れた、という意味ではありません。 | 方式 | 同じアドレスを保つ方法 | コード / ストレージの所在 | EIP-6780との関係 | | ------------------------ | ----------------------------------- | -------------------------------------- | ------------------------------------------------- | | 通常のCREATE2デプロイ | 同じファクトリー・ソルト・初期化コード | デプロイ先コントラクト | 空アドレスへ一度デプロイする用途は継続 | | 古典的なメタモーフィック方式 | 削除後に同じアドレスへ再デプロイ | 同じアドレスの実行時コードを入れ替える | 既存コントラクトの削除が止まり、繰り返しが成立しない | | コンストラクター内の`SELFDESTRUCT` | 作成トランザクション内で削除 | 確定後は空 | 次のトランザクションで再利用できるが、稼働中コントラクトの更新ではない | | ERC-1967プロキシ | プロキシが実装アドレスを読む | 状態はプロキシ、実行コードは実装 | `selfdestruct`再デプロイではなくスロット更新で切り替える | プロキシを調べるときは、[ERC-1967の実装・管理者・ビーコンスロットを読む方法](/archives/6020)のように、プロキシアドレスの状態と実装アドレスの実行時コードを分けます。検証済みソースを含む再構築は[バイトコード・コンパイラー設定・プロキシ先を同じブロックで照合する方法](/archives/6033)へ進めます。 もう一つの注意は`delegatecall`です。Solidityの資料は、対象コントラクト自身のソースに`SELFDESTRUCT`がなくても、`delegatecall`先のコードから命令コードを実行できると警告しています。`delegatecall`では呼び出し元側のストレージ、残高、アドレス文脈で実行されるため、実装だけを検索して「プロキシには命令コードがない」と終えません。 Cancun規則なら既存プロキシのコードとストレージを削除しませんが、残高移転と呼び出しフレーム終了は起きます。非推奨警告が出ること、コードが残ること、影響がないことは同義ではありません。 ## 過去挙動はローカルハードフォークと実ブロックを分けて再現する 今回のShanghai結果は、旧意味を比較する決定的ローカルテストです。Ethereumメインネットの過去トランザクションを再利用した結果ではありません。 実際のインシデントを過去ブロックで確認するなら、少なくとも次を一組で保存します。 - チェーンID、ブロック番号、ブロックハッシュ、タイムスタンプ - 作成時トランザクションと`SELFDESTRUCT`を実行したトランザクション - クライアントと適用ハードフォーク - 実行履歴内の`CREATE`・`CREATE2`・`SELFDESTRUCT`と呼び出し深さ - `SELFDESTRUCT`前後のブロックにおけるコード、関連するストレージスロット、残高、ノンス - 受取人と残高差分 - CREATE2ならファクトリー、ソルト、完全な初期化コードハッシュ 実行履歴に`SELFDESTRUCT`が1回あるだけでは、変更後にどの状態になったか分かりません。今回もShanghaiとCancunの実行履歴はどちらも命令を1回含み、差が現れたのはトランザクション確定後の状態でした。 公開した[Shanghai / Cancun比較JSON](/fixtures/selfdestruct-eip6780-6043.json)には、同じアドレスの変更前 / 変更後、CREATE2結果、命令コード件数、固定バージョンを分けてあります。値はローカルチェーンの再現結果であり、特定メインネットコントラクトの安全性を示すものではありません。 コンパイル対象自体の差を調べる場合は、[Solidityビルド設定のParis / Prague比較](/archives/6050)で、同じソースのPUSH0件数、バイトコードサイズ、古いEVMでのデプロイ結果を分けています。 ## インシデント調査とコードレビューのチェックリスト - [ ] チェーンID、ブロック番号 / ハッシュ、実行時ハードフォークを固定した - [ ] 作成時トランザクションと`SELFDESTRUCT`を実行したトランザクションが同じか確認した - [ ] トランザクションレシートが確定した後の`eth_getCode`を確定ブロックで読んだ - [ ] 関連するストレージスロットを`selfdestruct`前後で比較した - [ ] コントラクト残高と受取人の増分を別々に確認した - [ ] アカウントノンスを読み、CREATE2衝突条件を確認した - [ ] ファクトリーアドレス、ソルト、コンストラクター引数込みの初期化コードハッシュを保存した - [ ] 実行履歴でCREATE2の返り値とSELFDESTRUCTの呼び出し文脈を確認した - [ ] `delegatecall`経路を含め、実際に命令コードへ到達できる権限を確認した - [ ] 変形可能方式、プロキシ、未デプロイアドレスへのデプロイを別方式として扱った - [ ] コンパイラー警告、コンパイル対象、実行時フォークを同じバージョン情報へまとめていない 現行規則での結論は「`SELFDESTRUCT`が何もしない」ではありません。既存コントラクトではコードとストレージを残しながら、残高を送り、実行を終了します。何が残ったかを項目ごとに読み、トランザクションとフォークを固定して初めて、安全な停止設計やインシデントの説明につながります。 この記事には特定コントラクト、トークン、更新サービスの利用や投資を促す導線はありません。将来監査、検証、デプロイツール対応を紹介する場合も、広告表記と技術検証を分離します。 ## 確認した一次情報 - [EIP-6780 SELFDESTRUCT only in same transaction](): 確認日 2026-08-31 - [EIP-6049 Deprecate SELFDESTRUCT](): 確認日 2026-08-31 - [EIP-1014 Skinny CREATE2](): 確認日 2026-08-31 - [EIP-7569 Dencun hardfork meta](): 確認日 2026-08-31 - [Ethereum Foundation Dencun mainnet announcement](): 確認日 2026-08-31 - [Solidity selfdestruct documentation](): 確認日 2026-08-31 - [Solidity contract deactivation and delegatecall warning](): 確認日 2026-08-31 - [Ethereum JSON-RPC API](): 確認日 2026-08-31 - [Foundry EVM version configuration](): 確認日 2026-08-31 - [Foundry v1.8.0](): 確認日 2026-08-31 --- # CREATE2入門｜ソルトと初期化コードからコントラクトのアドレスを予測 CREATE2のアドレスをファクトリー、ソルト、初期化コードから計算し、コンストラクター、ライブラリー、メタデータ、プロキシ、クローン、衝突、未デプロイ時の利用境界を検証します。 正規URL: https://3mikan.com/archives/6044 著者: みかん 公開: 2026-08-31T08:50:00.000Z 更新: 2026-09-02T05:35:00.000Z CREATE2を使うと、コントラクトをデプロイする前にアドレスを計算できます。ただし、「ソルトが同じなら同じアドレス」「実行時バイトコードだけあれば計算できる」「コードがないアドレスは予約済み」という理解は正しくありません。 アドレスを決めるのは、**CREATE2を実行するファクトリーアドレス、32バイトのソルト、初期化コードのハッシュ**です。初期化コードには作成時バイトコードだけでなくコンストラクター引数も入り、リンク済みライブラリー、コンパイラーメタデータ、プロキシ初期化関数の設計によっても変わります。 この記事は決定論的デプロイのファクトリー、スマートアカウント、プロキシやクローンのファクトリーを実装する開発者向けです。**チェーン → ファクトリー → 実効ソルト → 作成時バイトコード → コンストラクターまたは初期化関数 → 初期化コードハッシュ → 予測したアドレス → コード・ノンス・残高 → デプロイのトランザクションレシート**の順に固定し、予測と安全性を分けます。 検証にはSolidity `0.8.36`、Foundry `1.8.0`、Anvil `1.8.0`、OpenZeppelin Contracts `5.6.1`、viem `2.56.0`を使いました。チェーンID`31345`の隔離したローカルチェーンだけで実行し、公開RPC、メインネットフォーク、ブラウザーウォレット、実資産は使っていません。 ## CREATEとCREATE2はアドレスの入力が違う 通常の`CREATE`は、作成者アドレスとノンスから次のアドレスを導きます。ファクトリーが先に別コントラクトを作るとノンスが進むため、予定アドレスも変わります。 ```text CREATE = keccak256(rlp([creator, nonce]))[12:] ``` CREATE2はノンスの代わりに、次の固定長の入力（原像）を使います。 ```text CREATE2 = keccak256( 0xff ++ factory ++ salt ++ keccak256(init_code) )[12:] ``` EIP-1014では、`0xff`が1バイト、ファクトリーアドレスが20バイト、ソルトが32バイト、初期化コードハッシュが32バイトです。最終ハッシュへ渡す入力は合計85バイトになります。 ここでいうファクトリーは、EOAのトランザクション送信者ではありません。**CREATE2命令を実行するコントラクトのアドレス**です。同じEOA、ソルト、初期化コードでも、別ファクトリーからデプロイすれば別アドレスになります。
ファクトリー、ソルト、初期化コードの3つの部品を照合し、建設前のコントラクト区画へ結び付ける概念図
予定アドレスへ入る3要素を別々に固定します。正確な式とハッシュは本文を基準にしてください。
## 初期化コードは実行時バイトコードではない EIP-1014の`init_code`は、実行されて実行時バイトコードを返す一時的なコードです。Solidityでコンストラクター付きコントラクトを作る場合は、概念上次の組み合わせになります。 ```solidity bytes memory initCode = abi.encodePacked( type(Target).creationCode, abi.encode(initialValue, recipient) ); bytes32 initCodeHash = keccak256(initCode); ``` `type(Target).runtimeCode`や、デプロイ後に`eth_getCode`で読んだコードを代入してはいけません。コンストラクターはストレージを初期化し、最後に別の実行時コードを返します。 ローカル検証では、同じファクトリーとソルトでコンストラクターの`initialValue`だけを`77`から`78`へ変えました。 | コンストラクター値 | 初期化コードハッシュ | 予測したアドレス | 実行時コードハッシュ | | ----------------: | -------------- | ----------------- | ----------------- | | `77` | `0x1f91…0d68` | `0x282A…7648` | `0xaa3d…fddf` | | `78` | `0xb8b5…caa7` | `0xe1F0…3402` | `0xaa3d…fddf` | 二つの実行時コードハッシュは同じですが、コンストラクターデータを含む初期化コードハッシュは異なり、アドレスも異なりました。**同じ実行時コードになることは、同じCREATE2アドレスになる条件ではありません。** ## Solidity手計算とviemを独立して一致させる ファクトリー側の計算は、次のように式をそのまま実装できます。 ```solidity function computeAddress(bytes32 salt, bytes32 initCodeHash) public view returns (address) { return address(uint160(uint256(keccak256(abi.encodePacked( bytes1(0xff), address(this), salt, initCodeHash ))))); } ``` TypeScript側では、作成時バイトコードとABI符号化済みコンストラクター引数を連結してからviemへ渡します。 ```ts const initCode = concatHex([ creationBytecode, encodeAbiParameters( parseAbiParameters('uint256, address'), [77n, recipient], ), ]) const predicted = getContractAddress({ from: factory, opcode: 'CREATE2', salt, bytecode: initCode, }) ``` 固定したローカル検証では、Solidityファクトリーの`view`関数、85バイトの入力を組み立てるTypeScriptの手計算、viemの`getContractAddress`という3経路が、すべて`0x282AE3Ef80fB8F5F68D934dA24201EeD1bf67648`で一致しました。 1つの補助関数だけを予測と検証の両方に使うと、同じ符号化不具合を共有して一致してしまいます。可能ならSolidityとチェーン外のコードを独立して実装し、初期化コードそのものとハッシュも比較します。 ## ライブラリーとコンパイラーメタデータもデプロイ入力に含める Solidityの外部ライブラリー呼び出しを含むバイトコードには、リンク用のプレースホルダーがあり、コンパイル時に実際のライブラリーアドレスが埋め込まれます。したがって、ライブラリーアドレスが違えば作成時バイトコード、初期化コードハッシュ、CREATE2アドレスも変わります。 同じソースを二つのライブラリーアドレスでリンクした固定結果です。 | リンクしたライブラリー | バイトコード | 初期化コードハッシュ | 予測したアドレス | | -------------- | -------: | -------------- | ----------------- | | `0x11…11` | 301バイト | `0xf670…34d1` | `0xE655…fca4` | | `0x22…22` | 301バイト | `0x924a…c941` | `0x9c5F…2418` | Solidityメタデータも見落としやすい入力です。メタデータにはコンパイラーバージョン、設定、ソースハッシュ、ライブラリー情報などが入り、変更によってバイトコードが変わり得ます。同じソースとSolidity `0.8.36`で、メタデータ設定だけを変えた結果です。 | メタデータ設定 | 作成時バイトコード | 初期化コードハッシュ | 予測したアドレス | | ---------------- | ----------------: | -------------- | ----------------- | | CBORなし | 259バイト | `0xb601…d38b` | `0x1116…6ac8` | | IPFSメタデータ | 313バイト | `0xe731…0b18` | `0x8754…21aF` | ソースが同じという説明だけでは、再現可能なビルドになりません。solcバージョン、最適化の有無と実行回数、`viaIR`、EVMバージョン、メタデータ、リマッピング、ライブラリーアドレスを記録へ残します。バイトコード再構築の詳しい手順は、[実行時バイトコードを同じコンパイラー条件で再構築する記事](/archives/6033)で確認できます。 ## ソルトは値ではなく、導出規則まで固定する `bytes32 salt`に何を入れるかはファクトリーの設計です。許可不要ファクトリーが利用者入力をそのまま使い、初期化コードが全呼び出し元で同じなら、別呼び出し元が先に同じアドレスへデプロイできます。 ローカル例では、所有者をコンストラクターへ結び付けず、デプロイ後の`initialize`で決めるコントラクトを使いました。最初の呼び出し元が利用者入力のソルトをそのまま使ってデプロイと初期化を行うと、次の呼び出し元は同じアドレスとの衝突でデプロイできません。 | 順番 | 呼び出し元 | 結果 | | ---- | ------ | ------ | | 1 | `0x7099…79C8` | `0x9384…83A4`へデプロイし所有者になる | | 2 | `0xf39F…2266` | 同じアドレスとの衝突でゼロアドレス | ただし、これをすべて「ソルトの先回りで所有権が盗まれる」と一般化してはいけません。所有者や設定値がコンストラクター引数へ入っていれば、攻撃者が別所有者でデプロイした初期化コードはハッシュが違うため別アドレスになります。攻撃者が被害者と同じ初期化コードを先に使える場合も、コンストラクターが被害者を所有者として固定していれば、主な結果は占有によるDoSです。 対策の1つは、利用者ソルトを呼び出し元名前空間へ入れる方法です。 ```solidity bytes32 effectiveSalt = keccak256(abi.encode(msg.sender, userSalt)); ``` 固定例では、同じ利用者ソルトでも2つの呼び出し元の予測アドレスは`0xcb5f…7501`と`0x3437…78b8`へ分かれました。ただし、名前空間化だけでファクトリーが安全になるわけではありません。誰がデプロイできるか、初期化コードを誰が選べるか、所有者がどこで結び付くか、初期化が同じトランザクションで完了するかも確認します。 ## CREATEとCREATE2の違いを調査の順番へ落とす
作成順のノンスで区画が進むCREATEと、ファクトリー、ソルト、設計図の組み合わせで予定区画を選ぶCREATE2を並べた概念図
CREATEは作成順、CREATE2は固定した入力を追います。どちらもデプロイ成功やコードの安全性までは保証しません。
予測が合わないときは、表示されたアドレスを何度も見比べるより、入力を左から固定します。 | 確認順 | 残す値 | 典型的なずれ | | ------ | ------ | ------------ | | 1 | チェーンID、ブロック、RPC | 別ネットワークを見ている | | 2 | ファクトリーアドレス、コードハッシュ、所有者と権限 | 別ファクトリー、プロキシ先、権限変更 | | 3 | 利用者が入力したソルト、実効ソルト、導出式 | パディング、呼び出し元名前空間、文字列ハッシュ | | 4 | 作成時バイトコード | 実行時バイトコードを使用、別成果物 | | 5 | コンストラクターのABIデータ | 型、順序、アドレス、バイト符号化 | | 6 | solc、最適化、EVM、メタデータ | ビルド環境の差 | | 7 | ライブラリーアドレス、実装 | リンク先やプロキシ先の差 | | 8 | 初期化コードハッシュ、想定したアドレス | チェーン外とチェーン上の計算の不一致 | チェーンID自体はEIP-1014の式へ直接入りません。それでもチェーンを最初に残すのは、ファクトリーがそのチェーンに同じアドレス・同じコード・同じ権限で存在するとは限らないためです。 ## 衝突、`revert`、誤ったファクトリーを別の失敗として扱う 予測したアドレスが正しくても、デプロイは失敗します。ローカル検証では次を別々に再現しました。 | 失敗 | トランザクション後の観測 | 原因 | | ------- | ------------------- | ---- | | 既存コード衝突 | CREATE2戻り値はゼロアドレス | 同一ファクトリー・ソルト・初期化コードが既にデプロイ済み | | コンストラクターの`revert` | 戻り値はゼロ、コード0バイト、ノンス0 | 初期化コード実行中に`revert` | | 誤ったファクトリー | 予測`0x282A…7648`、実際のファクトリー側`0x838E…972b` | 命令コード実行アドレスが異なる | | 誤ったコンストラクター引数 | 別の初期化コードハッシュ、別アドレス | ABIデータが異なる | | 誤ったライブラリーまたはメタデータ | 別の作成時バイトコード、別アドレス | コンパイラー入力が異なる | EIP-1014は、送信先のノンスがゼロでないまたはコードが空でない場合に作成時が失敗する衝突規則を説明しています。同じソルトでも初期化コードが違えば通常は別アドレスです。「ソルトを一度使ったらファクトリー全体で永久に使用禁止」という規則ではありません。 コンストラクターの`revert`も衝突と同じゼロアドレスに見える低水準ファクトリーがあります。ファクトリーはゼロアドレスを必ず拒否し、可能なら`revert`の理由、トランザクションレシートの状態、実行履歴、変更後の状態を残します。 SELFDESTRUCT後の再デプロイでは、フォークとトランザクション境界も確認する必要があります。[EIP-6780後のコード残存とCREATE2再デプロイ](/archives/6043)では、ShanghaiとCancunを別のローカル規則として比較しています。 ## プロキシ初期化関数はどこで実行するかでアドレスへの影響が変わる ERC1967Proxyは、コンストラクターへ実装アドレスと初期化関数データを渡し、そのデータを実装へ`delegatecall`できます。この形では初期化関数データがプロキシのコンストラクター引数に含まれるため、初期化コードの一部です。 固定例では、同じ実装、ファクトリー、ソルトでも、初期化関数の値を`77`から`78`へ変えると予測アドレスが`0x42A5…772c`から`0x6cDC…8C61`へ変わりました。 一方、空の初期化データでプロキシをデプロイし、後のトランザクションで初期化する設計なら、後から渡す所有者や値はCREATE2の入力へ入りません。しかし未初期化の時間を作ると、第三者に初期化される危険があります。初期化データをアドレス計算へ含めるかどうかだけでなく、**デプロイと初期化を同じトランザクションで完了するか**を確認します。 プロキシの実装、管理者 / 更新権限、ストレージスロットの読み分けは、[ERC-1967プロキシの確認手順](/archives/6020)も参照してください。 ## 最小クローンは実装が初期化コードへ入り、初期化関数は後段になる OpenZeppelin `Clones.cloneDeterministic`は、ERC-1167最小プロキシの初期化コードへ実装アドレスを埋め込み、ファクトリーとソルトからアドレスを予測します。[Minimal Proxyの45バイト実行時・初期化関数・ファクトリーを検証する手順](/archives/6045)では、埋め込みアドレスの抽出とクローンストレージを詳しく分けています。固定例では次を一致させました。 | 項目 | 固定値 | | ----- | ----------- | | 実装 | `0x9fE4…a6e0` | | 実効ソルト | `0xae1a…8d01` | | クローン初期化コードハッシュ | `0x4798…e0ba` | | 予測値とデプロイ先 | `0xd563…33Db` | | 同一トランザクションで初期化した所有者と値 | `0xf39F…2266`、`99` | 通常の最小クローンでは初期化関数呼び出しデータはクローン初期化コードの外にあります。つまり初期化関数値を変えてもクローンアドレス計算へ直接入らない設計があります。そのためファクトリーがクローンを作った直後、同じトランザクションで初期化することが重要です。 OpenZeppelinは、実装にコードがないクローンでは初期化呼び出しが成功したように見えても効果がなく、未初期化のまま残り得ると警告しています。予測前とデプロイ前に実装コードハッシュを確認します。 ## 未デプロイアドレスは「存在前に使える」が「予約済み」ではない EIP-1014の目的には、まだチェーン上に存在しないアドレスを前提としたやり取りがあります。スマートアカウントではファクトリー、所有者、ソルトから予定アドレスを計算し、署名やUserOperationを先に組み立てることがあります。 ローカルチェーンで予定アカウントを3段階に分けました。 | 段階 | コード | ノンス | 残高 | | ----- | ---: | ----: | ------: | | 予測直後 | 0バイト | 0 | 0 | | ローカルテストETHを事前送金 | 0バイト | 0 | 0.25 ETH | | CREATE2デプロイ後 | 108バイト | 1 | 0.25 ETH | コードもノンスも0のアドレスへネイティブ残高を置けること、後で同じアドレスへデプロイすると残高が残ることを確認しました。しかし、これは実資産の事前送金を勧める結果ではありません。 予測一致だけでは、ファクトリーが将来もデプロイ可能か、所有者が正しいか、初期化コードが監査済みか、コンストラクターが`revert`しないか、資産を取り出せるコードになるかは分かりません。未デプロイ署名のファクトリー呼び出しデータと`revert`検証は、[ERC-6492の未デプロイアカウント署名検証](/archives/6018)で扱っています。 ## デプロイ記録に固定する項目 アドレスだけを共有するのではなく、再計算できる入力とトランザクションレシートを1件にまとめます。 | グループ | 項目 | | ----- | ------ | | ネットワーク | チェーンID、初期状態またはフォーク、RPCの用途、ブロック | | ファクトリー識別情報 | アドレス、実行時コードハッシュ、実装、所有者とデプロイ権限 | | ソルト | 元の値、型、符号化、名前空間、実効`bytes32` | | コンパイラー | solcバージョン、最適化の有無と実行回数、`viaIR`、EVMバージョン、メタデータ設定 | | リンク | 完全修飾ライブラリー名、ライブラリーアドレス、リマッピング | | 初期化コード | 作成時バイトコードハッシュ、コンストラクターの型と値、初期化関数データハッシュ | | 予測 | 想定したアドレス、Solidity結果、チェーン外結果 | | 実行前の状態 | `eth_getCode`、ノンス、残高 | | デプロイ | トランザクションハッシュ、トランザクションレシートの状態、作成済みアドレス、イベント | | 変更後の状態 | コードハッシュ、ノンス、残高、所有者と初期化済み状態 | 記録に秘密情報を入れてはいけません。秘密鍵、シード、API秘密情報、個人情報は対象外です。予測アドレスへ権限や資産を結び付ける前に、別担当者が同じ記録から再計算できる状態にします。 ## レビュー時の確認項目 1. CREATE2を実行するファクトリーアドレスと実行時コードハッシュを確認したか。 2. 利用者ソルトと実効ソルトを分け、符号化と呼び出し元名前空間を固定したか。 3. 実行時バイトコードではなく、コンストラクターデータ付き作成時バイトコードをハッシュしたか。 4. コンパイラー、最適化、EVM、メタデータ、ライブラリーアドレスを固定したか。 5. プロキシ初期化関数がコンストラクター内かデプロイ後かを確認したか。 6. クローン / アカウントの初期化を同じトランザクションで完了するか。 7. 予測したアドレスのコード、ノンス、残高をデプロイ直前に読み直したか。 8. 衝突、コンストラクターの`revert`、誤ったファクトリーを別エラーとして扱うか。 9. ファクトリーのデプロイ権限、更新権限、停止条件を確認したか。 10. アドレス予測をコントラクト安全性、デプロイ成功、資産回収の保証として表示していないか。 ## まとめ CREATE2アドレスは、ソルトだけでは決まりません。**ファクトリーアドレス、実効ソルト、コンストラクターや初期化関数を含む初期化コード、そのコンパイラーとライブラリーの条件**を固定して初めて再計算できます。 予測が一致したら、次はコード・ノンス・残高、ファクトリー権限、衝突、コンストラクターの結果、初期化の一体性を確認します。決定的なのはアドレス導出であり、デプロイの成功やコントラクトの安全性ではありません。 ## 確認した一次情報 - [EIP-1014 Skinny CREATE2](): 確認日 2026-08-31 - [Solidity salted contract creation](): 確認日 2026-08-31 - [Solidity contract metadata](): 確認日 2026-08-31 - [Solidity library linking](): 確認日 2026-08-31 - [OpenZeppelin Create2 utility](): 確認日 2026-08-31 - [OpenZeppelin deterministic clones](): 確認日 2026-08-31 - [OpenZeppelin ERC1967Proxy constructor initializer](): 確認日 2026-08-31 - [viem getContractAddress](): 確認日 2026-08-31 --- # 最小プロキシとは？EIP-1167クローンのバイトコード・初期化・ファクトリー EIP-1167最小プロキシの45バイトの実行時コード、埋め込む実装、delegatecall、初期化関数、CREATE2ファクトリー、イミュータブル引数、調査手順をローカル環境で検証します。 正規URL: https://3mikan.com/archives/6045 著者: みかん 公開: 2026-08-31T09:45:00.000Z 更新: 2026-09-02T05:35:00.000Z 最小プロキシは、同じ機能のコントラクトについて実装全体を何度もデプロイせず、短いプロキシを複数作って一つの実装コードを共有する方法です。ERC-1167（EIP-1167）は、実装アドレスを埋め込んだ標準実行時バイトコードを定めています。 短いコードだから自動的に安全になるわけではありません。クローンのストレージは空から始まり、実装のコンストラクターはクローン側で動きません。`initialize`を別トランザクションへ残すと、第三者が先に所有者を設定できる設計があります。 この記事はアカウント、保管庫、プールなどをクローンファクトリーで量産する開発者と、ブロックエクスプローラーやRPCからクローンを調べる人向けです。**チェーン → クローンの実行時コード → 実装アドレスとコードハッシュ → `delegatecall`の文脈 → ストレージ配置 → 初期化状態 → ファクトリーとソルト → 拡張機能 → 権限**の順に確認できる状態を目指します。 検証にはSolidity `0.8.36`、Foundry `1.8.0`、Anvil `1.8.0`、OpenZeppelin Contracts `5.6.1`、viem `2.56.0`を使いました。EVMバージョンはCancun、チェーンIDは`31346`です。隔離したローカルチェーンだけで実行し、公開RPC、メインネットフォーク、ブラウザーウォレット、実資産は使っていません。 ## 完全なデプロイと最小クローンの違い 実装全体のデプロイは、各個体へ機能を含む実行時コードを置き、コンストラクターでその個体のストレージを初期化します。最小クローンは45バイトの小さな実行時だけを置き、呼び出しを固定実装へ`DELEGATECALL`します。 固定したローカル結果では、比較用コントラクト全体の実行時コードは366バイト、クローンの実行時コードは45バイト、共有実装は1,079バイトでした。コードサイズは小さくなりますが、クローンごとのストレージ、初期化トランザクション、実装の検証は別に必要です。 | 項目 | 完全なデプロイ | 標準最小クローン | | ---- | --------------- | ---------------- | | 個体の実行時 | 機能を含むコード | 45バイト転送コード | | 実行するコード | 個体自身 | 固定実装 | | 状態の保存先 | 個体 | クローン | | コンストラクター | 個体作成時に実行 | 実装コンストラクターはクローンで再実行されない | | 初期値 | コンストラクターで設定できる | 初期化関数等を別途設計する | | 更新 | コントラクト設計次第 | 標準実行時自体に管理者機能や更新機能はない | デプロイガスの差だけで選ぶと、初期化関数、実装の依存関係、運用上の調査コストを見落とします。最初に「コードを共有すること」と「状態を共有すること」を分けてください。クローン同士が共有するのは実装コードで、通常のストレージはクローンごとに別です。 ## EIP-1167実行時は45バイト EIP-1167が示す標準実行時は次の45バイトです。``には20バイトアドレスが入ります。 ```text 363d3d373d3d3d363d73 <20-byte implementation> 5af43d82803e903d91602b57fd5bf3 ``` 0始まりのバイト索引では、実装アドレスは`10`から`29`までです。命令列では、オフセット`9`の`PUSH20`が続く20バイトをスタックへ積み、オフセット`31`の`DELEGATECALL`がその宛先を使います。`revert`時は戻り値データをクローンの呼び出し元へ戻し、成功時も同様にデータを返します。 ローカルでデプロイしたクローンの実行時は次の値でした。 ```text 0x363d3d373d3d3d363d73 e7f1725e7734ce288f8367e1bb143e90bb3f0512 5af43d82803e903d91602b57fd5bf3 ``` 抽出した`0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512`は、実際にデプロイした実装アドレスと一致しました。 TypeScriptでは、長さ、接頭辞、末尾を確認してからアドレス部分を切り出せます。 ```ts const prefix = '363d3d373d3d3d363d73' const suffix = '5af43d82803e903d91602b57fd5bf3' function extractImplementation(runtime: `0x${string}`) { if ((runtime.length - 2) / 2 !== 45) throw new Error('not 45-byte runtime') if (!runtime.slice(2).startsWith(prefix)) throw new Error('prefix mismatch') if (!runtime.slice(2).endsWith(suffix)) throw new Error('suffix mismatch') return `0x${runtime.slice(2 + 10 * 2, 2 + 30 * 2)}` } ```
短い最小プロキシ実行時の中に実装アドレス領域が埋め込まれ、共有実装へ結び付く関係を示す概念図
図は埋め込み領域の関係だけを示します。正確な45バイト、索引10–29、命令列は本文と実バイトコードを基準にしてください。
## `delegatecall`は実装コードをクローンの文脈で動かす Solidityの説明どおり、`delegatecall`では対象のコードを呼び出し元コントラクトの文脈で実行します。ここで呼び出し元コントラクトはクローンです。 | 実行要素 | `delegatecall`時に使われるもの | | -------- | ---------------------------- | | コード | 実装アドレスのコード | | ストレージ | クローンのストレージ | | `address(this)` | クローンアドレス | | 残高 | クローン残高 | | `msg.sender` | クローンを呼んだ元の送信者のまま | | `msg.value` | クローンへ渡した値のまま | ローカル例では、所有者がクローンの`execute(5)`へ`123 wei`を付けて呼びました。クローンの`value`は`77`から`82`へ変わり、`address(this)`はクローンアドレス、`lastCaller`は所有者、クローン残高は`123 wei`になりました。一方、実装側の`value`と残高は`0`のままです。
呼び出し元がクローンへ渡した処理が共有実装のコードを借り、結果をクローン固有のストレージへ保存する流れの概念図
コードは実装から借りますが、状態、アドレス、残高、送信者、値はクローンの実行文脈です。
この性質により、実装とクローンのストレージ配置が一致しないと、別のスロットを所有者や値として読み書きします。変数名が同じかではなく、スロット番号、型、詰め込み、継承順を照合します。 ## 実装のコンストラクターはクローンストレージを初期化しない コンストラクターは、そのコントラクトを作る作成時コードの実行中に1回だけ動きます。実装をデプロイしたときのコンストラクターは実装ストレージを変更しますが、後から作るクローンストレージにはコピーされません。 ローカル例では、実装のコンストラクターが記録したデプロイ者アドレスを確認できました。同じ読み取り関数を未初期化クローンで読むとゼロアドレスで、所有者もバージョンもゼロでした。 ```solidity contract CloneLogic { address public owner; uint256 public value; uint64 public initializedVersion; address public constructorSender; constructor() { constructorSender = msg.sender; // 実装側だけ } function initialize(address initialOwner, uint256 initialValue) external { require(initializedVersion == 0, "already initialized"); require(initialOwner != address(0), "zero owner"); initializedVersion = 1; owner = initialOwner; // delegatecallならクローンのストレージへ書く value = initialValue; } } ``` Solidityの`immutable`も注意が必要です。不変値は実行時コードへ埋め込まれるため、クローンごとにストレージへ置かれる値ではありません。実装コンストラクターで決まった不変は、その実装を使うクローンから共通に見えます。 ## 初期化関数はデプロイと同じトランザクションで完了させる 安全側のファクトリーは、クローン作成と初期化を同じトランザクションで実行し、どちらかが失敗すれば全体を`revert`します。 ```solidity function deployCloneAndInitialize( address implementation, address owner, uint256 value ) external returns (address instance) { require(implementation.code.length > 0, "implementation has no code"); instance = Clones.clone(implementation); CloneLogic(instance).initialize(owner, value); } ``` `clone()`だけを先に実行し、後のトランザクションで`initialize()`する形には未初期化の時間があります。許可不要な初期化関数なら、メモリープールで見た第三者や、単に先に呼んだ第三者が所有者になれます。 固定例では、未初期化クローンへ攻撃者が`initialize(attacker, 1)`を先に実行し、所有者になりました。その後の予定所有者による`initialize(owner, 77)`は`already initialized`で`revert`しました。 | 状態または失敗 | 観測 | 対応 | | --------------- | ---- | ---- | | 同一トランザクションで初期化 | デプロイと設定が同じトランザクションで完了 | ファクトリーで一括実行し、失敗時は全体`revert` | | 未初期化 | 所有者とバージョンがゼロ | 利用開始・送金・権限付与を止める | | 先着の呼び出し元が取得 | 想定外アドレスが所有者 | インシデントとしてファクトリートランザクションと呼び出し元を追う | | 初期化関数再利用 | 2回目も通る | バージョンによる保護を実装する | | 無許可の再初期化 | 所有者以外がバージョンを進められる | 権限とバージョンを両方検証する | | 実装にコードなし | 初期化が成功したように見えるが状態が変わらない | クローン作成前後にコード長 / ハッシュを固定する | `initialize`だけでなく、`reinitializeV2`のような移行関数も対象です。ローカル例ではバージョン`1 → 2`への移行を所有者だけに許可し、所有者以外、同バージョンの再実行、初期化の再実行をそれぞれ`revert`させました。 ## コードのない実装では成功に見える場合がある OpenZeppelin Contracts 5.6.1の`Clones`は、`clone`と`cloneDeterministic`が実装にコードがあるか確認しないと警告しています。コードのないアドレスへの`DELEGATECALL`は、呼び出し自体が成功になっても実行するコードがなく、状態を変更しません。 ローカル例では、コード長さが`0`の`0x…bEEF`を実装として45バイトクローンを作りました。初期化関数の低水準呼び出しは`success = true`、戻り値データは`0x`でしたが、所有者スロットはゼロのままでした。`owner()`を読む低水準呼び出しも成功で空データを返し、ABIで復号できる32バイト値は得られません。 ファクトリーでは少なくとも次を別々に確認します。 1. デプロイ前の実装で`code.length > 0`となること 2. 想定した実装実行時コードハッシュとの一致 3. クローン実行時から抽出した実装アドレスとの一致 4. 初期化関数呼び出しの成功だけでなく、所有者、バージョン、ドメインなどの変更後の状態 5. イベントだけでなくトランザクションレシートと変更後の状態 「トランザクションが成功」「ファクトリーイベントが出た」「初期化関数呼び出しが`revert`しなかった」のどれも、初期化完了を単独では証明しません。 ## 決定論的クローンは実装・ソルト・ファクトリーを固定する `cloneDeterministic`はCREATE2でクローンを作ります。標準クローンの初期化コードには実装アドレスが入り、CREATE2アドレスはファクトリー、ソルト、初期化コードハッシュから決まります。 ```text clone address = keccak256( 0xff ++ factory ++ salt ++ keccak256(clone_init_code) )[12:] ``` ローカル例では、ファクトリー`0x5FbD…aa3`、実装`0xe7f1…0512`、固定ソルトから予測した`0x5f19…0e40`とデプロイ後アドレスが一致しました。同じ組み合わせをもう一度デプロイすると衝突で`revert`しました。 この一致はライブラリーの予測関数だけで確認していません。45バイトの実行時コードへ10バイトの作成時接頭辞を付けたクローン初期化コードは55バイト、初期化コードハッシュは`0xcb1c…e7c8`でした。前掲のEIP-1014式へファクトリー、32バイトのソルト、このハッシュを入れた手計算結果も`0x5f19…0e40`です。 標準クローンでは通常、初期化関数呼び出しデータはクローン初期化コードに含まれません。そのため、同じ実装、ファクトリー、ソルトなら初期化関数の所有者や値を変えても予定アドレスは変わらない設計があります。だからこそ、デプロイ直後に同じトランザクションで初期化する必要があります。 ソルト、初期化コード、ファクトリーを含むCREATE2の計算と衝突は、[CREATE2アドレスを予測する手順](/archives/6044)で詳しく分けています。 ## イミュータブル引数付きクローンは標準45バイト実行時と分ける OpenZeppelin Contracts 5.6.1には、`cloneWithImmutableArgs`と`cloneDeterministicWithImmutableArgs`があります。引数はクローンコードの末尾へ付加され、`fetchCloneArgs`で取得できます。 ローカル例では、標準クローンは45バイト、64バイトのABI符号化済み引数を付けたクローンは109バイトでした。後者の先頭には標準転送部分がありますが、**コントラクトコード全体はEIP-1167が示す正確な45バイト実行時ではありません**。 | 判定 | 標準クローン | 不変引数拡張 | | ---- | ---------- | ------------------ | | コード長さ | 45バイト | 45バイト + 引数長さ | | 引数保存 | なし | コード末尾 | | 取得方法 | 該当なし | ライブラリー固有の取得処理 | | ブロックエクスプローラー判定 | バイトコードの完全一致 | 拡張機能として別判定 | | CREATE2入力 | 標準クローン初期化コード | 実装・引数を含む拡張初期化コード | 独自最小プロキシは接頭辞、末尾、`revert`処理、呼び出しデータ加工、不変引数の読み方が異なる場合があります。45バイトでないコードを、アドレスらしい20バイトが見つかったという理由だけで標準クローンと断定しません。 ## 標準クローン自体は更新可能ではない EIP-1167の標準実行時は、20バイト実装アドレスを固定で埋め込みます。管理者スロット、更新関数、実装を書き換えるストレージスロットはありません。そのクローン単体については、通常のERC-1967プロキシのように実装を変更できません。 ローカルクローンでERC-1967実装スロットと管理者スロットをストレージの生データから読むと、どちらもゼロでした。調査時は次の違いを先に固定します。 | 方式 | 実装の場所 | 更新経路 | 主な権限確認 | | ------- | ---------------------- | ----------- | ----------------- | | EIP-1167標準クローン | 実行時バイト索引10–29 | 標準クローンにはなし | ファクトリー、初期化関数、埋め込み実装 | | UUPSプロキシ | ERC-1967実装スロット | 実装側の更新関数 | 更新を認可する役割または所有者 | | Transparentプロキシ | ERC-1967実装スロットと管理者スロット | 管理者またはProxyAdmin経由 | 管理者、ProxyAdmin所有者、管理者へのフォールバック制限 | UUPSとTransparentをコード長さだけで区別せず、ERC-1967スロット、検証済み実装、更新関数、管理者 / 権限を合わせて確認します。 ただし、次の依存は残ります。 - 埋め込まれた実装コードが正しいか - クローンと実装のストレージ配置が一致するか - 実装コードが外部コントラクト、オラクル、登録簿へ依存するか - クローンストレージに別プロキシ用スロットを持ち、実装側のコードがそれを読む設計か - チェーンやフォークによってコードのライフサイクルに関する前提が違わないか SELFDESTRUCTについて「実装がいつでも消えてクローンが壊れる」と現在のEthereumへ一律に書くのは不正確です。Cancun以降、既存コントラクトの`SELFDESTRUCT`は通常コードを削除せず、作成と同じトランザクションで実行した場合だけ従来の削除動作を保ちます。フォーク境界は[SELFDESTRUCTとEIP-6780の検証](/archives/6043)で分けています。 一方、別チェーン、古いフォーク、作成トランザクション内の特殊なライフサイクル、最初からコードのないアドレスは別です。調査時はチェーンとブロックを固定し、その時点の`eth_getCode`とコードハッシュを記録します。 ## ブロックエクスプローラーとRPCでクローンを調べる順番 ブロックエクスプローラーの「Proxy」表示だけを結論にせず、取得したコードとトランザクションを順に確認します。 | 順番 | 確認するもの | 判断できること | | ---- | ------------ | -------------- | | 1 | チェーンID、ブロック、クローンアドレス | 別ネットワークと別時点の混同を防ぐ | | 2 | クローンの`eth_getCode`、長さ、コードハッシュ | 正確な45バイトか、拡張機能または独自実装か | | 3 | 接頭辞、バイト10–29、末尾 | 標準実行時と埋め込み実装 | | 4 | 実装コードとコードハッシュ | コードの有無と想定成果物との一致 | | 5 | クローン作成時のトランザクション、ファクトリー | デプロイ者、CREATEまたはCREATE2、同一トランザクション内の呼び出し | | 6 | 初期化関数呼び出しデータ、トランザクションレシート、実行履歴 | 誰が何を設定したか | | 7 | 所有者、バージョン、ドメイン、重要スロット | 変更後の状態が完了したか | | 8 | ストレージ配置と検証済みソース | `delegatecall`先とクローンスロットの整合 | | 9 | ソルト導出、予測 | 決定的アドレスの再計算 | | 10 | 権限と外部依存関係 | 後から挙動へ影響できる主体 | 検証済みソースがある場合も、表示ソースとチェーン上実行時の一致条件を確認します。コンパイラー、最適化、メタデータ、リンクしたライブラリーを固定してバイトコードを再構築する方法は、[検証済みソースと実行時バイトコードを照合する記事](/archives/6033)を参照してください。 ERC-1967、Transparent、UUPS、Beaconと最小クローンを同じ「プロキシ」という言葉だけでまとめると調査を誤ります。実装スロット、管理者、更新権限の読み分けは、[ERC-1967プロキシの調査手順](/archives/6020)で整理しています。 クローンやプロキシが読むストレージをモジュールごとに分ける設計では、名前空間を採用しただけで項目互換性が保証されるわけではありません。[ERC-7201 Namespaced Storageのルート・並べ替え・型変更を検証する手順](/archives/6046)で、通常配置と名前空間配置の衝突境界を比較できます。 ## ファクトリーレビューで残すチェックリスト デプロイ前、トランザクション内、デプロイ後を分けます。 ### デプロイ前 - チェーンID、ファクトリーアドレス、ファクトリーコードハッシュを固定したか - 実装アドレス、コード長さ、実行時コードハッシュを固定したか - クローンと実装のストレージ配置が一致するか - 初期化関数にバージョン保護機構と権限の検査があるか - ソルトの導出規則と呼び出し元名前空間を説明できるか - 標準、不変引数、独自プロキシのどれか明示したか ### 同じトランザクション内 - クローンのデプロイと初期化を同じトランザクションで行ったか - 初期化関数失敗で全体が`revert`するか - 初期所有者、役割、ドメイン、資産が呼び出し元任せになっていないか - 初期化関数の戻り値だけでなく、期待状態を検査できるか - CREATE2衝突時の失敗を処理しているか ### デプロイ後 - クローンコードが期待する長さ、接頭辞、実装、末尾か - 実装コードハッシュがデプロイ前と一致するか - 所有者、初期化関数バージョン、役割、重要引数が期待値か - イベント、トランザクションレシート、実行履歴、変更後の状態が同じ個体を指すか - ファクトリーと実装へ影響できる権限を記録したか ## まとめ 最小プロキシの確認順は、**チェーン → クローンの実行時コード → 実装アドレスとコードハッシュ → `delegatecall`の文脈 → ストレージ配置 → 初期化状態 → ファクトリーとソルト → 拡張機能 → 権限**です。 標準EIP-1167実行時は45バイトで、実装アドレスはバイト索引10–29へ埋め込まれます。実行コードは実装から借りますが、ストレージ、`address(this)`、残高、`msg.sender`、`msg.value`はクローン側です。 コンストラクターはクローンストレージを初期化しません。ファクトリーは実装コードを検査し、クローン作成と初期化を同じトランザクションで完了させ、所有者やバージョンの変更後の状態まで確認します。45バイトより長いイミュータブル引数付きクローンや独自拡張は、標準実行時と分けて判定してください。 ## 確認した一次情報 - [ERC-1167 Minimal Proxy Contract](): 確認日 2026-08-31 - [OpenZeppelin Contracts Clones API](): 確認日 2026-08-31 - [OpenZeppelin Contracts 5.6.1 Clones.sol](): 確認日 2026-08-31 - [Solidity delegatecall and libraries](): 確認日 2026-08-31 - [EIP-1014 Skinny CREATE2](): 確認日 2026-08-31 - [EIP-6780 SELFDESTRUCT only in same transaction](): 確認日 2026-08-31 --- # ERC-7201名前空間付きストレージ入門｜更新時の配置衝突を検証 ERC-7201の名前空間IDとルート計算、保存場所の注釈、安全な末尾追加、危険な並べ替え・型変更・IDの誤記、更新検証の境界をローカル環境で確認します。 正規URL: https://3mikan.com/archives/6046 著者: みかん 公開: 2026-08-31T11:20:00.000Z 更新: 2026-09-02T05:35:00.000Z 更新可能コントラクトでは、プロキシのアドレスとストレージを残したまま、実行する実装コードを差し替えます。新しい実装が同じスロットを別の意味で読むと、所有者、残高、上限などが壊れます。これがストレージ衝突です。 ERC-7201の名前空間付きストレージは、モジュールごとの状態を固有の名前空間へ分ける規約です。継承したコントラクトの変数を一つの連続した配置へ積み重ねる代わりに、`account`、`rewards`、`governance`のようなストレージ構造体を、それぞれ離れたルートから始められます。 ただし、名前空間を導入しただけで更新が安全になるわけではありません。同じ名前空間内の項目順・型・詰め込みは引き継ぐ必要があり、名前空間IDの誤記は別の空領域を読む原因になります。注釈とアセンブリのスロットが一致しているか、検証ツールが何を見ているかも分けて確認します。 この記事は更新可能コントラクトを実装・レビューする開発者と、プロキシのストレージ配置を調べる人向けです。確認順を **チェーン → プロキシ → 古い実装 → 新しい実装 → コンパイラー設定 → 名前空間ID → ルート → 項目配置 → ストレージの生データ → 移行 → 権限** に固定します。 検証にはSolidity `0.8.36`、Foundry `1.8.0`、Anvil `1.8.0`、OpenZeppelin Upgrades Core `1.46.0`、viem `2.56.0`を使いました。EVMバージョンはCancun、最適化の実行回数は200、ローカルチェーンIDは`31347`です。公開RPC、メインネットフォーク、ブラウザーウォレット、実資産は使っていません。 ## まず3種類の配置を分ける Solidityの通常ストレージ、`__gap`、ERC-7201名前空間は、目的と壊れ方が異なります。 | 方法 | 状態の置き方 | 得意なこと | 残る注意点 | | ---- | ------------ | ---------- | ------------ | | 通常ストレージ | 継承順を含む連続配置 | 単純なコントラクト、末尾追加 | 基底コントラクトへの途中追加、並べ替え、型変更で後続スロットが動く | | `__gap` | 将来用の連続スロットを予約 | 基底コントラクトへ変数を追加する余地を残す | 追加分だけ予約領域を正しく縮める必要があり、モジュール同士は分離されない | | ERC-7201 | 名前空間ごとに別ルートを持つ構造体 | モジュール・継承木間の衝突を分離 | 同じ名前空間内の互換性、IDとルートの一致、検証ツールの解析範囲は別確認 |
通常ストレージの連続棚、将来用の予約領域を含む棚、名前空間ごとに独立した保管室を並べて比較する概念図
図は3方式の空間関係を示す概念図です。正確なスロット、バイトオフセット、型はコンパイラー出力と本文の表を基準にしてください。
Solidityの通常配置では、値型は可能なら同じ32バイトスロットへ詰め込まれます。継承がある場合も、C3線形化の順序に従って基底側から配置され、異なるコントラクトで宣言した項目が同じスロットを共有する場合があります。 固定したV1では、`address owner`と`uint96 limit`がスロット`0`へ収まり、`uint256 points`がスロット`1`へ置かれました。 | 項目 | スロット | バイトオフセット | 型 | | ----- | ---- | ----------- | ---- | | `owner` | 0 | 0 | `address` | | `limit` | 0 | 20 | `uint96` | | `points` | 1 | 0 | `uint256` | V2で`nonce`を末尾へ追加すると既存3項目は動かず、`nonce`はスロット`2`です。一方、`limit`と`owner`を並べ替えると同じスロット`0`でもバイトオフセットが変わります。`owner`を`bytes32`へ変えると、後続項目はスロット`1`、`2`へ押し出されます。 変数名が残っていても、ストレージから取得した32バイトの意味は同じではありません。 ## `__gap`は予約を使った分だけ縮める OpenZeppelinの従来型更新可能コントラクトでは、基底コントラクトに固定長配列の`__gap`を置き、将来の変数追加に使う方法があります。 ```solidity contract GapV1 { uint256 public value; uint256[49] private __gap; } contract GapV2Safe { uint256 public value; uint256 public added; uint256[48] private __gap; } ``` ここではV1の`__gap`がスロット`1`から`49`を予約します。V2はスロット`1`へ`added`を入れ、予約領域を48スロットへ縮めるため、継承先の開始位置を維持できます。変数を追加したのに`__gap`を49スロットのまま残すと、後続状態を1スロットずらします。 `__gap`は便利ですが、予約量を人が管理し、継承木全体の連続配置を追う必要があります。独立モジュールごとのストレージを明示したい場合にERC-7201が選択肢になります。 ## ERC-7201のルートを式から計算する ERC-7201の`erc7201`計算式は、名前空間IDの`id`からルートを次の式で求めます。 ```text keccak256( abi.encode(uint256(keccak256(bytes(id))) - 1) ) & ~bytes32(uint256(0xff)) ``` 今回の名前空間IDは`mikan.storage.Main`です。計算結果は次のルートになりました。 ```text 0x351e99d536f6929a0d7758896402b97bf95ac2715119a5c4fc2bfc39425ad500 ``` 最初のハッシュから1を引いて再度ハッシュすることで、Solidityの通常ストレージ木と単純に重なる形を避けます。最後に下位8ビットをゼロへマスクするため、ルートは256スロットの境界に揃います。固定結果も末尾が`00`で、`uint256(root) % 256 == 0`でした。
名前空間を材料に二段階の変換と整列を経て独立したストレージ領域の開始地点を得る概念図
図はIDから独立ルートへ進む関係だけを示します。式、ID、ルート値は本文とストレージから取得した値で確認してください。
名前空間IDは表示名ではなく、ストレージ上の位置を決める入力です。大文字・小文字、ドット、綴りを1文字変えるだけで別ルートになります。組織、パッケージ、モジュール名などを含む衝突しにくいIDを決め、定数・注釈・設計記録で同じ値を使います。 ## 注釈・構造体・アセンブリのスロットを一致させる 基本形は、ストレージ構造体へ`@custom:storage-location erc7201:`を付け、計算済みルートをアセンブリーで構造体参照位置へ割り当てます。 ```solidity /// @custom:storage-location erc7201:mikan.storage.Main struct MainStorage { address owner; uint96 limit; uint256 points; uint256 nonce; } bytes32 private constant MAIN_STORAGE_LOCATION = 0x351e99d536f6929a0d7758896402b97bf95ac2715119a5c4fc2bfc39425ad500; function _getMainStorage() private pure returns (MainStorage storage $) { assembly ("memory-safe") { $.slot := MAIN_STORAGE_LOCATION } } ``` Solidity `0.8.20`以降はNatSpec注釈をASTへ含めるため、対応ツールが名前空間配置を解析できます。しかしSolidityコンパイラー自身は、注釈のIDからルートを再計算してアセンブリ定数との一致を強制しません。コンパイル成功は次を保証しません。 - 名前空間IDが更新前後で同じ - 同じIDが別構造体で重複していない - 構造体項目が互換な順序・型を保つ - アセンブリが注釈に対応するルートを指す - ライブラリーや独自アセンブリを検証ツールが完全に追跡する 定数は手入力だけにせず、計算式から生成・検証し、更新前後のビルド情報をレビュー担当者へ渡します。 ## 安全な末尾追加では既存項目を動かさない V1の名前空間内配置は次の3項目です。相対スロットは名前空間ルートを`0`とした相対位置です。 | バージョン | 項目 | 相対スロット | バイトオフセット | 型 | | ------- | ----- | ------------- | ----------- | ---- | | V1 | `owner` | 0 | 0 | `address` | | V1 | `limit` | 0 | 20 | `uint96` | | V1 | `points` | 1 | 0 | `uint256` | | V2安全 | `nonce` | 2 | 0 | `uint256` | V2安全は既存3項目を同じ順序・型で残し、末尾へ`nonce`を追加します。ローカルプロキシをV1からV2安全へ切り替えると、`owner`、`limit = 12345`、`points = 987654321`は保持され、ルートから2スロット後へ`nonce = 77`を書けました。 通常配置の末尾追加、正しく縮めた`__gap`、名前空間内の末尾追加は、いずれもUpgrades Core検証を通過しました。ただし検証ツールの合格は、初期化関数、移行、アクセス制御、業務処理まで安全という意味ではありません。 ## 同じ名前空間内の並べ替えと型変更は危険 名前空間は別モジュールとの衝突を分離しますが、その部屋の中の収納順までは自動で守りません。 ```solidity // V1 address owner; // 相対スロット0、オフセット0 uint96 limit; // 相対スロット0、オフセット20 // 安全でないV2 uint96 limit; // 相対スロット0、オフセット0 address owner; // 相対スロット0、オフセット12 ``` この並べ替えでは、V1が保存した同じ32バイト語をV2が異なる境界で切り出します。型変更も詰め込みと後続スロットを変えます。名前空間を変えずに項目名だけを変える場合も、対応ツールが削除と追加として扱う可能性があるため、注釈や名前変更用の選択肢を含むツール固有の手順を確認します。 固定検証では次の結果になりました。 | 変更 | 参照 | 結果 | 主な検出内容 | | ------ | --------- | ------ | ------------ | | 通常配置の末尾追加 | `TraditionalV1` | 合格 | 既存項目を保持 | | `__gap`を一つ消費 | `GapV1` | 合格 | 追加分だけ予約領域を縮小 | | 名前空間内の末尾追加 | `NamespacedV1` | 合格 | 同じIDで既存項目を保持 | | 通常配置の並べ替え | `TraditionalV1` | 失敗 | `owner`の削除として検出 | | 通常配置の型変更 | `TraditionalV1` | 失敗 | `address → bytes32`を検出 | | 名前空間内の並べ替え | `NamespacedV1` | 失敗 | 名前空間内の`owner`削除を検出 | | 名前空間内の型変更 | `NamespacedV1` | 失敗 | 名前空間内の`address → bytes32`を検出 | | 名前空間IDの誤記 | `NamespacedV1` | 失敗 | 旧名前空間の削除を検出 | | 同一コントラクト木のID重複 | 単体検証 | 失敗 | 重複名前空間を検出 | | コントラクト外のライブラリー構造体 | 単体検証 | 警告付きで合格 | 名前空間構造体がコントラクト外で解析対象外 | この表はOpenZeppelin Upgrades Core `1.46.0`へSolidityビルド情報と参照コントラクトを渡した固定結果です。バージョン、コンパイラー出力、注釈の置き場所、CLIの選択肢が違えば、同じ検出範囲だと仮定しません。 ## 名前空間IDの誤記は「初期化されたように見えない」状態を作る `mikan.storage.Main`を`mikan.storage.Mian`と綴ると、ルートは次へ変わりました。 ```text 0x2a2faa7b8b284411dad3c4b390dfa4621dc55ce9306dc4c5c01e9cdd87c40900 ``` 旧ルートには所有者・上限・ポイントが残っていますが、誤記ルートの対応スロットはゼロでした。V2の読み取り関数は旧状態を失ったのではなく、別の空ストレージ木を読んでいます。この状態で初期化関数の保護機構が`owner == address(0)`だけなら、再初期化できる設計になる可能性があります。 ID変更が意図的な移行なら、新旧ルート、複製対象項目、順番、実行権限、再実行防止、完了目印、巻き戻しの可否を設計します。単に定数を差し替えて「更新完了」としません。 ## 重複IDとライブラリー境界を別に確認する 同じ継承木で二つの構造体が同じ名前空間IDを使うと、両者は同じルートを指します。名前の異なるモジュールでも同じストレージスロットを共有し、片方の書き込みがもう片方の状態を変えます。固定したコントラクト内の重複は検証ツールが拒否しました。 一方、コントラクト外のライブラリーに置いた名前空間構造体と手動ルートの衝突は、今回の検証では警告を出して合格しました。これは衝突が安全という意味ではなく、その定義が解析対象外であるというツール境界です。 独自アセンブリ、`delegatecall`先、Diamondストレージライブラリー、生成コードを含む設計では、検証ツールだけに依存せず次を追加します。 1. 全名前空間IDと計算ルートの一覧を作る 2. 重複IDだけでなく重複ルートを検査する 3. 注釈IDとアセンブリ定数の一致を自動照合する 4. プロキシを更新して旧値をストレージの生データと読み取り関数の両方で確認する 5. 検証対象外警告を失敗扱いにするか方針を決める [公開した固定検証JSON](/fixtures/erc7201-storage-6046.json)には、コンパイラーが出力した配置、名前空間ルート、10種類の検証結果、ローカルプロキシの更新前後のスロットを保存しています。生成画像は概念説明であり、トランザクション、監査、更新安全性の証拠には使っていません。 ## プロキシ・UUPS・Beacon・Diamondとの関係 ERC-7201が定めるのはストレージ配置の名前空間です。実装アドレスの保存場所、更新関数、更新権限、呼び出し振り分け、初期化関数や移行は定めません。 | 方式 | ERC-7201が助ける部分 | 別に確認する部分 | | ------- | -------------------- | ---------------- | | UUPS | 実装側状態のモジュール分離 | ERC-1967スロット、`upgradeToAndCall`、`_authorizeUpgrade`、実装ロック | | Transparent | 実装側状態のモジュール分離 | 管理者、`ProxyAdmin`、管理者のフォールバック制限、更新イベント | | Beacon | 各プロキシが読む実装側配置 | ビーコンアドレス、ビーコン実装、ビーコン所有者、全個体への影響 | | Diamond | ファセット間ストレージの名前空間設計 | 識別子振り分け、`diamondCut`権限、ファセットのライフサイクル、ライブラリーのルート衝突 | | EIP-7702対象 | 委任済みコードが読むアカウントストレージの整理 | 認可リスト、対象コード、EOAに残る状態、権限回収 | ERC-1967の実装・管理者・ビーコンスロット、呼び出し文脈、更新イベントは[ERC-1967プロキシをストレージの生データから調べる手順](/archives/6020)で確認できます。ソースと実行時をコンパイラー設定から再構築する場合は[検証済みソースの再現手順](/archives/6033)へ進んでください。 コンパイラー設定の変更そのものは、[Solidityオプティマイザー・via-IR・EVMバージョンの比較](/archives/6050)で作成時、実行時、メタデータ、ガス、正常系・失敗系を同じ対応表へ固定しています。 EIP-1167最小クローンは通常実装を固定し、クローンごとにストレージを持ちます。[Minimal Proxyのバイトコード・初期化関数・ファクトリーを検証する記事](/archives/6045)では、45バイト実行時とクローンストレージを分けています。 ファセットごとにDiamond Storage、AppStorage、ERC-7201式のルートが混在し得る構成は、[EIP-2535 Diamondの関数セレクター振り分け・Loupe・DiamondCutを読む手順](/archives/6047)で、ファセットのライフサイクル、初期化関数、ストレージの生データ、変更権限までつなげています。 EIP-7702ではEOAアドレスに委任後の状態が残り得ます。[EIP-7702の委任先切替・解除後に残る状態](/archives/6017)と合わせると、「実行コードを変えること」と「既存ストレージを移行・消去すること」が別だと確認できます。 ## 更新前後に残すチェックリスト ### ビルドと配置 - [ ] 古い実装と新しい実装のソースコミットと成果物ハッシュを固定した - [ ] Solidityの完全なバージョン、最適化の有無と実行回数、EVM、`viaIR`、リマッピングを揃えた - [ ] コンパイラーの`storageLayout`とASTをビルド情報へ含めた - [ ] 参照コントラクトを指定して更新検証した - [ ] 警告、除外名前空間、独自アセンブリを記録した ### 名前空間 - [ ] 名前空間IDを文字列の完全一致で比較した - [ ] 計算式からルートを再計算した - [ ] ルートの下位8ビットがゼロか確認した - [ ] 注釈、定数、アセンブリの参照位置が同じIDとルートを指す - [ ] コントラクト、基底コントラクト、ライブラリー、ファセットを横断してIDとルートの重複を検査した - [ ] 同じ名前空間内の項目順、スロット、バイトオフセット、型、詰め込みを比較した - [ ] 追加項目は互換な末尾追加か、明示移行かを決めた ### チェーン上の状態 - [ ] チェーンID、プロキシアドレス、固定ブロック番号とハッシュを記録した - [ ] 古い実装と新しい実装のアドレス、実行時コードハッシュを読んだ - [ ] 更新前の重要な読み取り関数とストレージの生データを保存した - [ ] シミュレーションまたはローカルフォーク相当の隔離環境で更新後状態を読んだ - [ ] 移行呼び出しデータ、初期化関数バージョン、再実行防止を確認した - [ ] 更新トランザクションのレシート、イベント、変更後の状態を同じプロキシへ対応させた - [ ] 管理者、所有者、役割、マルチシグ、タイムロックまで権限チェーンを追った 本番更新では「自動検査に合格した」だけで承認せず、プロキシアドレス、古い実装と新しい実装、ブロック、変更前の状態データ、移行、権限を同じ記録へ揃えます。逆に自動検査が失敗した場合、本番環境データを見て問題ないと推測して無視せず、配置変更か明示的な移行設計を見直します。 ## まとめ ERC-7201は、モジュールごとの状態を固有の名前空間ルートへ分離し、継承順や別モジュールによるストレージ衝突を減らす規約です。ルートは名前空間IDから二段階のハッシュと256スロット境界への整列で計算し、ストレージ構造体の注釈、定数、アセンブリの参照位置を一致させます。 安全な更新では、同じ名前空間内の既存項目を同じ順序・バイトオフセット・型で残し、新しい項目を互換な末尾へ追加します。並べ替え、型変更、ID誤記、重複ID、解析対象外のライブラリーは、名前空間を採用しても別の失敗になります。 最終確認は **チェーン → プロキシ → 古い実装 → 新しい実装 → コンパイラー設定 → 名前空間ID → ルート → 項目配置 → ストレージの生データ → 移行 → 権限** です。名前空間、検証ツール、チェーンから取得した状態データの三つを対応させてから更新判断へ進んでください。 ## 確認した一次情報 - [ERC-7201 Namespaced Storage Layout](): 確認日 2026-08-31 - [Solidity Layout of State Variables in Storage](): 確認日 2026-08-31 - [OpenZeppelin Writing Upgradeable Contracts](): 確認日 2026-08-31 - [OpenZeppelin Upgrades Core API](): 確認日 2026-08-31 - [OpenZeppelin Contracts Upgradeable](): 確認日 2026-08-31 - [ERC-1967 Proxy Storage Slots](): 確認日 2026-08-31 --- # Diamondプロキシの読み方｜EIP-2535のファセット・関数セレクター・ストレージ・更新 EIP-2535 Diamondの関数振り分け、ファセット、Loupe、DiamondCut、初期化関数、ストレージ方式、更新権限をローカル環境で検証します。 正規URL: https://3mikan.com/archives/6047 著者: みかん 公開: 2026-08-31T12:20:00.000Z 更新: 2026-09-02T05:35:00.000Z EIP-2535 Diamondは、一つのコントラクトアドレスへ複数の実装コントラクトを組み合わせる仕組みです。機能ごとの実装をファセットと呼び、Diamondの`fallback`が呼び出しデータ先頭4バイトの関数セレクターを見て、対応するファセットへ`delegatecall`します。 これは「実装スロットを一つ読む」プロキシとは構造が違います。[ERC-1967プロキシをストレージの生データから読む方法](/archives/6020)では実装、ビーコン、管理者を分けますが、Diamondは関数セレクターごとに実行先を分けます。同じDiamondアドレスでも、`transfer`はファセットA、`mint`はファセットB、LoupeはファセットCというように実行コードが分かれます。 状態はファセット側ではなくDiamond側に残るため、振り分け、ファセットコード、ストレージ配置、更新権限を一緒に読まなければ現在の動作を説明できません。 この記事はDiamondを実装・レビューする開発者と、既存Diamondを読み取り専用で調べる人向けです。確認順を **チェーン → Diamond → 関数セレクター → ファセット → ソースコードと実行時コード → Loupe → DiamondCutログ → 初期化関数 → ストレージルート → 権限** に固定します。 検証にはSolidity `0.8.36`、Foundry `1.8.0`、Anvil `1.8.0`、viem `2.56.0`を使いました。EVMバージョンはCancun、最適化の実行回数は200、ローカルチェーンIDは`31348`です。公開RPC、メインネットフォーク、ブラウザーウォレット、利用者の鍵、公開トランザクション、実資産は使っていません。 ## Diamondは関数セレクターごとにファセットを選ぶ 通常の単一実装プロキシは、`fallback`から一つの実装へほぼすべての呼び出しを転送します。Diamondでは、Diamondが`bytes4 selector => address facet`に相当する振り分け表を持ちます。 ```text 呼び出しデータ └─ 先頭4バイト = 関数セレクター └─ Diamondの振り分け表 └─ 選択されたファセットのコード └─ Diamondのアドレスとストレージでdelegatecall ``` `delegatecall`ではファセットのコードを使いますが、`address(this)`、ストレージ、残高はDiamondの文脈です。`msg.sender`と`msg.value`も元の呼び出しから引き継がれます。ファセットコントラクト自身のストレージへ書く通常呼び出しとは分けて考えます。
複数の4分割された印が中央入口で振り分けられ、異なる三つの機能室と共通の保管基盤へつながる関数セレクター振り分けの概念図
図は関数セレクターの振り分けと共有ストレージの関係を示す概念図です。正確な関数セレクター、ファセットアドレス、実行時コードハッシュ、ストレージルートは本文と固定検証JSONを基準にしてください。
今回のローカル再現では、V1ファセットの`setValue(17)`をDiamondアドレスへ送ると、Diamondのスロット`0`が`17`、スロット`1`がバージョン`1`になりました。呼び出し元もDiamondのスロット`3`へ残り、V1ファセットコントラクト自身のスロット`0`はゼロのままです。コードの場所と状態の所有者が違うことを、ストレージの生データで確認できます。 ## 関数セレクターを署名から再計算する 関数セレクターは、正規化した関数署名をKeccak-256へ通した先頭4バイトです。戻り値の型は署名へ含めません。 ```text bytes4(keccak256("setValue(uint256)")) = 0x55241077 ``` 配列、タプル、`uint`と`uint256`の正規表記を誤ると別の値になります。呼び出しデータの手読みと正規型の基本は[ABI・関数セレクター・呼び出しデータ・イベントログを読む方法](/archives/6005)で確認できます。 4バイトは約43億通りなので、異なる署名が同じ関数セレクターになる衝突は起こり得ます。関数セレクターだけを検索して関数名を確定せず、対象ファセットのABI、検証済みソース、実行時バイトコード、コンパイラー条件まで照合します。 ローカル再現の最終振り分けから一部を抜き出すと次の通りです。 | 署名 | 関数セレクター | 最終ファセット | | --------- | -------- | ----------- | | `diamondCut((address,uint8,bytes4[])[],address,bytes)` | `0x1f931c1c` | DiamondCutファセット | | `facets()` | `0x7a0ed627` | Loupeファセット | | `facetAddress(bytes4)` | `0xcdffacc6` | Loupeファセット | | `setValue(uint256)` | `0x55241077` | Counter V2ファセット | | `value()` | `0x3fa4f245` | Counter V1ファセット | | `owner()` | `0x8da5cb5b` | Ownershipファセット | | `note()` | `0x26d111f5` | ゼロアドレス（削除後） | `setValue`だけをV2へ置換したため、同じCounter機能でも`value()`など7個の関数セレクターはV1に残ります。「ファセット単位で更新されたはず」と推測せず、関数セレクターごとの実際の行き先を一覧にします。 ## Loupeの4関数で現在の振り分けを読む EIP-2535のLoupeは、現在のファセットと関数セレクターを調べる読み取り専用インターフェースです。 | 関数 | 返すもの | 主な用途 | | -------- | -------- | -------- | | `facets()` | ファセットアドレスと関数セレクターの全グループ | 現在の一覧を一括取得 | | `facetFunctionSelectors(address)` | 指定ファセットの関数セレクター | 1ファセットの担当範囲 | | `facetAddresses()` | 現在のファセットアドレス一覧 | コード確認対象の列挙 | | `facetAddress(bytes4)` | 関数セレクターの現在のファセット | 既知の関数セレクターを直接確認 | `IDiamondLoupe`のインターフェースIDは、4個の関数セレクターをXORした`0x48e2b093`です。ローカル再現ではERC-165の`supportsInterface`がIERC165 `0x01ffc9a7`、IDiamondCut `0x1f931c1c`、IDiamondLoupe `0x48e2b093`へ`true`、`0xffffffff`へ`false`を返しました。 ただしLoupeは「今」を返します。過去のファセット、変更順、初期化関数、変更権限はLoupeだけでは復元できません。また、大きなDiamondですべての要素を配列で返す関数は、ガスやRPC応答の上限へ達する可能性があります。 既知の関数セレクターなら`facetAddress(bytes4)`を優先し、一括取得には分割可能な独自インデックスや複数のRPCも検討します。 ## ファセットアドレスのコードとソースを個別に照合する Loupeからアドレスを得たら、各アドレスの実行時コードの有無とハッシュを同じブロックで読みます。Diamondアドレスのソースだけを検証しても、`delegatecall`先のファセットソースまでは証明しません。 固定したローカル再現のコードハッシュは次のように分かれました。 | ファセット | 実行時バイト | 実行時コードハッシュ | | ----- | ------------- | ----------------- | | DiamondCut | 3249 | `0x9ae07cb18db7121d650f59f685c3c4f4a50d00b577ab5f24acc6ae6e9f4a1fbf` | | Loupe | 2065 | `0x288e55868ce4c3d982a9152e8307e597298fa20b17406a7dbce50ff9b91830f4` | | Counter V1 | 590 | `0x3f59288ec1ad70dbbfec5a6ec3d3b917fabf97ceedb97fff7d203df941f0a689` | | Counter V2 | 234 | `0x7b273f7f5323d07ab71d4c54be522b611520f1a7fb9240d3f6aded0d2365a00a` | | Ownership | 389 | `0xa234efe7ddad9e7b48e486e35bd785622305a8c43bebf0f3bd6e944e30b550fb` | 本番調査ではチェーン、Diamond、固定ブロック番号とハッシュを先に固定し、Diamondの`fallback`、Loupe、現在の全ファセット、変更用ファセット、権限管理用ファセット、初期化対象を別々に再構築します。[検証済みソースをコンパイラー・コンストラクター・プロキシまで確認する手順](/archives/6033)と同じく、検証済みバッジを監査や安全保証に置き換えません。 ## `diamondCut`の追加・置換・削除をイベントと変更後の状態で結ぶ `diamondCut`は複数の`FacetCut`と任意の初期化関数呼び出しを1トランザクションで適用します。操作の値は次の通りです。 | 操作 | 列挙型値 | ファセットアドレス | 関数セレクターの条件と結果 | | ------ | ---------- | ------------- | -------------------- | | `Add` | 0 | コードがあるファセット | 未登録の関数セレクターを振り分けへ追加 | | `Replace` | 1 | コードがある別ファセット | 登録済みの関数セレクターの振り分けを変更 | | `Remove` | 2 | ゼロアドレス | 登録済みの関数セレクターの振り分けを削除 | ローカル再現では`note()`をExtraファセットへ追加し、`setValue(uint256)`だけをCounter V2へ置換し、最後に`note()`を削除しました。それぞれDiamondアドレスから`DiamondCut`イベントが発行され、操作は`0 → 1 → 2`でした。置換後に`setValue(21)`を呼ぶとV2の処理で値は`42`、バージョンは`2`になり、V1から引き継いだDiamondストレージを読めました。
中央施設へ部屋が追加され、別仕様の部屋へ置き換わり、最後に部屋が取り除かれる3場面でDiamondCutを示す概念図
図は追加・置換・削除の違いだけを示します。列挙型値、関数セレクターの配列、ファセットアドレス、イベント、変更後の状態は本文と固定検証JSONで確認してください。
重複する関数セレクターの`Add`、存在しない関数セレクターの`Replace`と`Remove`、コードがないファセット、同じファセットへの`Replace`は拒否されるべき条件です。ローカル再現では重複`Add`とコードなしファセットを拒否し、`Remove`後の`note()`は振り分けなしとして`revert`しました。 `DiamondCut`イベントを見つけただけで変更完了を断定しません。トランザクションの実行結果、発行元、ログの順序、変更内容、同じブロックでLoupeから得た値、各ファセットのコードハッシュを対応させます。過去履歴ではデプロイトランザクションから固定した対象ブロックまでイベントを集め、初期の関数セレクターもコンストラクターデータとデプロイログから確認します。 ## 初期化関数は変更と同じトランザクションの任意`delegatecall` `diamondCut`は`_init`アドレスと`_calldata`を受け取り、関数セレクター変更後の初期化や移行を同じトランザクションで実行できます。初期化関数もDiamond文脈の`delegatecall`なので、Diamondストレージを書き換えられます。 ローカル再現の初期変更では値`41`、バージョン`1`を設定しました。別の変更で値`77`、バージョン`3`へ更新し、関数セレクターの追加と状態変更が同時に反映されることも確認しました。 重要なのは、初期化関数が単なる補助関数ではなく任意コード実行点だということです。次を固定します。 - `_init`アドレスの実行時コードハッシュとソース - `_calldata`の関数セレクター、引数、復号結果 - 書き換えるストレージルートと項目 - 初期化関数の再実行防止とバージョン - `msg.sender`を使う場合の意味 - 外部呼び出し、トークンの利用許可、資産移動の有無 - `revert`した場合に変更全体が巻き戻ること `revert`する初期化関数と`note()`のAddを組み合わせたローカル再現では、シミュレーションが拒否され、変更後の状態の`facetAddress(0x26d111f5)`はゼロのままでした。原子性は確認できても、成功する初期化関数の内容が安全だとは証明しません。 ## Diamond Storage・AppStorage・ERC-7201を混同しない EIP-2535はファセット間で状態を共有する必要性を説明しますが、アプリケーション状態を1種類の配置へ固定しません。代表的な設計を分けます。 | 方式 | ルートの考え方 | 利点 | 注意点 | | ------- | ------------ | ---- | ------ | | Diamond Storage | モジュール固有文字列などのハッシュスロット | ファセットやモジュールごとに離れた構造体を置ける | 定数衝突、ID誤記、構造体内互換性 | | AppStorage | スロット`0`などに1つの大きな構造体 | アプリケーション状態をまとめて型付きで参照 | 全ファセットが項目順・型を厳密に共有する必要 | | ERC-7201計算式 | 名前空間IDから256スロット境界に揃えたルートを計算 | 名前空間の宣言とツール対応を標準化しやすい | EIP-2535とは別規格で、自動採用されない | ローカル再現ではAppStorageルートがゼロ、振り分け用Diamond Storageルートが`0xc8fcad8db84d3cc18b4c41d551ea0ee66dd599cde068d998e57d5e09332c131c`、ERC-7201式の例が`0x3286117daff9f85013498e4492687a45855d62df0707c718045a4347f7b1d900`で、互いに異なりました。 AppStorageの項目順を`value, version`から`version, value`へ取り違えたファセットは、同じストレージのスロット`0 = 41`をバージョン、スロット`1 = 1`を値として読みました。ファセットを差し替えてもストレージの内容は自動移行されません。 名前空間ルートの式、注釈、同じ名前空間内の末尾追加・並べ替え・型変更は[ERC-7201名前空間付きストレージの検証手順](/archives/6046)で詳しく比較しています。Diamondでは全ファセットとライブラリーを横断してルート、構造体、スロット、バイトオフセット、型を一覧化します。 ## 更新権限はEIP-2535だけでは決まらない EIP-2535は`diamondCut`の仕組みを定めますが、誰が実行できるかを一つの方式へ固定しません。所有者、AccessControl、マルチシグ、タイムロック、ガバナンス、不変化など、実装ごとに異なります。 ローカル再現は所有者だけを許可し、無関係なローカルアカウントの変更を拒否しました。本番では`owner()`が読めるだけで終えず、次の権限チェーンを追います。 1. `diamondCut`の関数セレクターを処理する現在のファセットをLoupeで得る 2. 変更ファセットの実行時ソースとアクセス制御を読む 3. 所有者、役割、管理者の現在値を固定ブロックで読む 4. アドレスがマルチシグやタイムロックなら、その必要署名数、構成員、遅延、提案者、実行者を追う 5. 所有権、役割、ガバナンス引数の変更イベントを履歴化する 6. 更新関数を削除・置換できる別経路がないか、すべての関数セレクターとソースを検索する EIP-2535では更新可能性自体は任意です。標準の変更入口がない、または削除されたDiamondもあり得ますが、「更新不能」は関数名が見えないことだけでは証明できません。`fallback`への直接実装、別の関数セレクター、外部ストレージコントラクト、`delegatecall`先の管理機能を含めて調べます。 ## 固定検証で確認した境界 [公開した固定検証JSON](/fixtures/diamond-routing-6047.json)には、17個の関数署名とセレクターの対応表、初期状態と最終状態のLoupe取得値、4件のDiamondCutイベント、7コントラクトの実行時コードハッシュ、ストレージの生データ、3種類のストレージルート、権限のない変更が拒否された結果を保存しています。 Foundryの12テストと、viemとAnvilによるライフサイクル検証では、次を確認しました。 - 関数セレクターからファセットへの`fallback`振り分け - Diamondストレージとファセット自身のストレージの分離 - ERC-165と三つのインターフェースID - Loupe 4関数から取得した現在の一覧 - `Add`、`Replace`、`Remove`とイベント - 重複する関数セレクター、コードなしファセット、権限のない変更の拒否 - 置換後も残るDiamond所有の状態 - 削除後の`fallback`による`revert` - 初期化関数成功時の状態変更と失敗時の全体的な巻き戻し - AppStorage、Diamond Storage、ERC-7201例のルート分離 - 誤ったAppStorage項目順によるストレージの生データの再解釈 これはローカル環境の再現結果です。本番環境Diamond、ファセット、初期化関数、ストレージ配置、ガバナンス、監査、安全性には一般化しません。生成画像も概念説明であり、トランザクション、イベント、コード、ストレージ、権限の証拠には使っていません。 ## Diamond調査チェックリスト ### 対象の識別と振り分け - [ ] チェーンID、Diamondアドレス、固定ブロック番号とハッシュを固定した - [ ] Diamond実行時コードハッシュと`fallback`のソースを確認した - [ ] 呼び出しデータの関数セレクターを正規化した関数署名から再計算した - [ ] `facetAddress(selector)`とLoupeから得た全一覧を保存した - [ ] 関数セレクターの衝突や同名関数をABIだけで断定していない - [ ] 現在の各ファセットについて、コードの有無、実行時ハッシュ、検証済みソース、コンパイラー条件を照合した ### 変更と履歴 - [ ] デプロイから固定した対象ブロックまで`DiamondCut`ログを発行元とログインデックスの順に集めた - [ ] `Add`の`0`、`Replace`の`1`、`Remove`の`2`とファセットアドレスの条件を検査した - [ ] イベント直後と現在のブロックでLoupeから得た状態を比較した - [ ] 初期化関数アドレス、呼び出しデータ、ソース、ストレージ書き込み、外部呼び出しを復号した - [ ] 初期化関数の`revert`時に変更全体が巻き戻る実装か確認した - [ ] 標準外の振り分け変更操作や更新入口をソースとすべての関数セレクターから探した ### ストレージと権限 - [ ] 全ファセットとライブラリーのストレージルート、構造体、スロット、バイトオフセット、型を一覧化した - [ ] AppStorageの項目順と型をファセット間で比較した - [ ] Diamond StorageとERC-7201のID、ルート、重複、誤記を検査した - [ ] 更新前後の重要な読み取り関数とストレージの生データを保存した - [ ] 変更の所有者、役割、マルチシグ、タイムロック、ガバナンスを末端まで追った - [ ] ソース検証、監査、Loupe対応を安全保証と同一視していない ## まとめ Diamondを読む起点はDiamondアドレスだけではなく、呼び出しデータ先頭4バイトの関数セレクターです。Loupeで現在のファセットを取得し、ファセットごとの実行時ソースとコードハッシュ、DiamondCut履歴、初期化関数、共有ストレージ配置、更新権限へつなげます。 最終確認は **チェーン → Diamond → 関数セレクター → ファセット → ソースコードと実行時コード → Loupe → DiamondCutログ → 初期化関数 → ストレージルート → 権限** です。振り分けの現在値、変更履歴、状態の意味、変更できる主体を同じ固定ブロックの記録へ揃えてから、動作とリスクを判断してください。 ## 確認した一次情報 - [EIP-2535 Diamonds, Multi-Facet Proxy](): 確認日 2026-08-31 - [Solidity Contract ABI Specification](): 確認日 2026-08-31 - [Solidity Introduction to Smart Contracts](): 確認日 2026-08-31 - [Solidity Layout of State Variables in Storage](): 確認日 2026-08-31 - [ERC-165 Standard Interface Detection](): 確認日 2026-08-31 - [Nick Mudge diamond-3 reference implementation](): 確認日 2026-08-31 --- # 再入の種類と防ぎ方｜関数横断・読み取り専用・コールバックをFoundryで再現 Solidityの再入を、基本型、関数横断、コントラクト横断、読み取り専用、トークンのコールバック、delegatecallに分け、CEIと再入ガードが守る範囲をFoundryで検証します。 正規URL: https://3mikan.com/archives/6048 著者: みかん 公開: 2026-08-31T15:45:00.000Z 更新: 2026-09-02T05:35:00.000Z 再入は「同じ`withdraw`がもう一度呼ばれること」だけではありません。外部呼び出し中に制御を渡し、**同じ不変条件に関係する状態が確定する前に、到達可能な別の入口や別コントラクトがその中間状態を使うこと**が本質です。 そのため、`withdraw`へChecks-Effects-Interactions（CEI）や`nonReentrant`を付けただけでは調査は終わりません。別関数、`view`、トークン受取側、フラッシュ貸付コールバック、フック、`fallback`、プロキシモジュールを含む呼び出しグラフと、共有すべきロックの範囲を確認します。 この記事ではSolidity `0.8.36`、Cancun EVM、Foundry `1.8.0`に固定したローカル検証用実装で、基本型、関数横断、コントラクト横断、読み取り専用、ERC-777形式のコールバック、`delegatecall`モジュールを再現します。外部RPC、メインネットフォーク、ウォレット、個人の鍵、公開トランザクション、実資産は使いません。 ## 再入は呼び出しスタックと不変条件から定義する 最初に「どの関数へ戻ったか」ではなく、守る式を置きます。今回のETH保管庫なら、最低限の支払能力は次です。 ```text address(vault).balance >= 正常な利用者が請求できる額 ``` 通常の実装では、`sum(credits) == totalCredits`、`totalCredits <= 利用可能資産`、持分と資産の換算、価格スナップショットなど複数の性質があります。外部呼び出しの前後でどの式が一時的に崩れ、コールバックからどこへ到達できるかを追います。 ```text 外側の入口 → 状態Aを読む → 状態Bだけ更新する → 外部呼び出しを行う → callback / fallback / hook → 同じ関数、別関数、別コントラクト、viewへ到達 → 残りの状態を更新 ``` 外部呼び出しはETH送金だけではありません。任意コントラクトへの呼び出し、受取側フック、フラッシュ貸付コールバック、AMMフック、安全なNFT発行、プロキシやモジュールの`delegatecall`も、呼び出し先へ制御を渡します。Solidity公式も、Ether送金に限らず外部コントラクトへの任意の呼び出しで再入が起こり得ると説明しています。
3MIKANのキャラクターが未確定の中央状態と、外部呼び出しから別の入口へ戻る経路を確認する再入シーケンス図
図は制御が外へ出て別入口から戻る関係の補助表現です。正確な呼び出し順と状態差は下の実行履歴と公開JSONを基準にしてください。
## 六つの境界へ分類する 同じ攻撃コントラクトでも、再入先と観測対象で防御の射程が変わります。 | 分類 | コールバックから到達する先 | 中間状態で起きること | 主な確認点 | | --- | --- | --- | --- | | 基本型・単一関数 | 同じ状態変更関数 | 同じ残高を複数回読む | 状態更新を外部呼び出し前へ移せるか | | 関数横断 | 同じコントラクトの別の外部関数 | 共通台帳を別経路で変更 | 再入ガードが関連する外部関数をすべて覆うか | | コントラクト横断 | 別コントラクトを経由して元状態を利用 | 利用側が途中の値を確定値として保存 | 信頼境界とスナップショット | | 読み取り専用 | `view`読み取り関数 | 一時的に不整合な価格や比率を返す | 読み取りも共有不変条件へ含めるか | | 受取側・フックコールバック | トークン、NFT、貸付、AMMのコールバック | 送金や会計の途中で任意呼び出し | コールバック送信者、更新順、再到達先 | | `delegatecall`・モジュール | 同じホスト状態上の別モジュール | モジュール固有ロックを迂回 | ホストで共有するロックスロット |
3MIKANのキャラクターを中心に同じ関数、関数横断、読み取り専用観測、受取側コールバック、共有状態を使うモジュールの五領域を比べる分類図
分類名、標準、再入ガードの範囲は画像ではなくこの比較表を基準にしてください。複数分類が同じ呼び出しチェーンに重なることもあります。
## 基本型：外部呼び出し後に残高を消すと同じ額を再利用できる 脆弱版は残高を読み、ETHを送った後で残高と`totalCredits`を減らします。 ```solidity uint256 amount = credit[msg.sender]; (bool success,) = msg.sender.call{value: amount}(""); require(success); credit[msg.sender] = 0; totalCredits -= amount; ``` 正常利用者が4 ETH、攻撃コントラクトが1 ETHを入金し、受取側が最大3回戻る再現実行履歴は次です。 ```text ClassicReenter.attack(3) → deposit(1 ETH) → withdraw: credit = 1 ETH → 攻撃側を呼び出す: 1 ETH → withdraw: creditはまだ1 ETH → 攻撃側を呼び出す: 1 ETH → withdraw → 攻撃側を呼び出す: 1 ETH → withdraw → 攻撃側を呼び出す: 1 ETH → 四つの呼び出しフレームから戻り、それぞれcreditを0にしてtotalCreditsから1 ETHを引く ``` | 状態 | 外部呼び出し前 | 脆弱版の完了後 | CEI修正版の完了後 | | --- | ---: | ---: | ---: | | 攻撃者入金 | 1 ETH | 1 ETH | 1 ETH | | 攻撃者受取合計 | 0 | 4 ETH | 1 ETH | | 保管庫ETH残高 | 5 ETH | 1 ETH | 4 ETH | | 正常残高 | 4 ETH | 4 ETH | 4 ETH | | totalCredits | 5 ETH | 1 ETH | 4 ETH | | 入れ子呼び出し | 未実行 | 3回成功 | 1回目を拒否 | 修正版は`credit=0`と`totalCredits-=amount`を送金前へ移します。入れ子の`withdraw`は`NO_CREDIT`となり、攻撃コントラクト側で1回の拒否を観測しました。支払い処理から送金を分離するPull Paymentも、誰がいつコールバックを受けるかを限定する方法です。 ## 関数横断：引き出しだけの再入ガードでは共通台帳を守れない 次は`withdraw`にストレージロックがあっても、`moveCredit`に同じロックがない例です。送金コールバック中、攻撃コントラクトは同じ`withdraw`ではなく`moveCredit(receiver, 1 ether)`へ入ります。 ```text withdrawが攻撃側のcredit = 1 ETHを読む → 外部呼び出しで1 ETHを送る → moveCredit(receiver, 1 ETH) attacker credit: 1 → 0 receiver credit: 0 → 1 → withdrawを再開 attacker credit: 0 totalCredits: 5 → 4 ``` 完了時の保管庫残高は4 ETHです。しかし請求可能額は正常利用者の4 ETHと受取側の1 ETHを合わせた5 ETHで、`claims > balance`になります。`withdraw`の再実行を防いでも、同じ残高台帳を変更する別関数は開いていました。 `moveCredit`にも**同じロック**を付けた修正版ではコールバック中の移動が拒否され、受取側残高は0、正常残高と保管庫残高はともに4 ETHでした。ここで必要なのは関数名単位の排他制御ではなく、「どの外部関数が同じ不変条件を共有するか」という範囲です。 この経路は、外部の攻撃コントラクトを経て元の保管庫の別関数へ戻るため、コントラクト横断でもあります。より長い経路では、プロトコルAのコールバック中にオラクルや利用側BがAの`view`を読み、B側の請求記録や見積もりへ保存することがあります。コントラクト境界を越えても、同じ途中状態へ依存するなら一つの脅威モデルです。 ## 読み取り専用：`view`は書かなくても途中の価格を公開する 読み取り専用再入では、再入した`view`が直接状態を書かないことがあります。問題は、その戻り値を別コントラクトが信頼して書き込むことです。 今回のプールは`spotPrice = accountedAssets / totalShares`です。正常入金後は100 / 100 = 1.0。攻撃コントラクトが10を追加して終了するとき、脆弱版は先に持分だけ減らし、ETH送金後に資産会計を減らします。 ```text exit(10) totalShares: 110 → 100 accountedAssets: 110のまま → callback spotPrice = 110 / 100 = 1.1 PriceConsumer.claimDuringMutation()が請求記録を1件保存 accountedAssets: 110 → 100 post-state spotPrice = 1.0 ``` トランザクション後にプールだけを見ると価格は1.0へ戻っていますが、利用側の請求記録は残ります。修正版は持分と資産の両方を外部呼び出し前に確定し、コールバック中も1.0を返すため請求を拒否しました。 CEIは有効ですが、一つの関数内の順序だけを機械的に見ても不十分です。価格、持分率、仮想残高、報酬指数など、**外部コントラクトが読む`view`まで含めて一貫した状態を作る**必要があります。OpenZeppelin 5.xの`nonReentrantView`も、保護中に不整合な読み取りを拒否したい境界向けです。 利用バージョンのAPIと、すべての利用側がその読み取り関数を通るかを確認します。 ## ERC-777・ERC-721・ERC-1155は受取側呼び出しを前提にする トークン転送は常に単純な残高移動とは限りません。 - ERC-777の`tokensReceived`は受取側コントラクトへ制御を渡す - ERC-721の安全な転送や発行は`onERC721Received`を呼ぶ - ERC-1155の安全な転送は残高とイベントを更新した後で受取側フックを呼び、仕様も再入を明示する - ERC-3156フラッシュ貸付は`onFlashLoan`、AMMや保管庫のフック設計もコールバックを持つ - ETHを直接送る`call`は`receive`または`fallback`へ入る ローカル検証用実装ではERC-777形式の`tokensReceived`を最小再現しました。保管庫は100トークンを預かり、`token.send`で受取側フックを呼んだ後に持分を0にします。コールバックから3回戻ると、預入後500あった保管庫トークンのうち400が攻撃コントラクトへ移り、保管庫は100だけになりました。 | トークンコールバック例 | 攻撃者トークン | 保管庫トークン | 拒否した再入 | | --- | ---: | ---: | ---: | | 脆弱版の完了後 | 400 | 100 | 0 | | 持分を先に0にする修正版 | 100 | 400 | 1 | これはERC-777全体の実装ではなく、受取側コールバック境界だけを扱う教育用の最小再現です。実装レビューでは、コールバック送信者が想定したトークンや管理コントラクトか、残高更新とプロトコル会計の順序、バッチ転送、発行と焼却、運用者、フック内の別の外部関数まで確認します。 ERC-1155の受取側フックを、必須コールバックを持たないERC-6909中核と同じ操作順で比べる場合は、[ERC-6909とERC-1155の一括処理・コールバック・イベント比較](/archives/6049)で、受取拒否、入れ子転送、ID別利用許可額、誤転送の境界を確認できます。 ## `delegatecall`：モジュール固有ロックはホスト全体のロックではない `delegatecall`ではモジュールコードがウォレットやプロキシのストレージ文脈で動きます。それでもモジュールAとBが別々のロックスロットを使えば、Aのコールバック中にBへ入れます。 ```text wallet.run(module, enterLocalA) → delegatecall: ローカルAのロックを設定、カウンター 0 → 1 → コールバック wallet.run(module, enterLocalB) → ローカルBのロックは0なので成功、カウンター 1 → 2 ``` 検証用モジュールの固有ロックでは入れ子呼び出しが成功し、ホストカウンターは2でした。AとBが同じストレージロックスロットを使う修正版では入れ子呼び出しが失敗し、カウンターは1になりました。同じ一時ストレージのロックスロットを使った場合も入れ子呼び出しは失敗しましたが、最上位の呼び出しを終えた後の次のトランザクションではロックが消え、通常のB呼び出しによってカウンターが2になりました。 EIP-1153の一時ストレージも`delegatecall`では呼び出し元ホストの所有権文脈を使います。この性質はモジュール間でロックを共有する用途に合いますが、スロット名の衝突、成功経路での明示的な後片付け、同じトランザクション内の後続呼び出しまでレビューします。[一時ストレージのCALL・DELEGATECALL・後片付け境界](/archives/6021)で寿命と所有者を詳しく検証しています。 ## CEI・再入ガード・引き出し・スナップショットは役割が違う | 防御 | 強い範囲 | 単独では残る境界 | | --- | --- | --- | | CEI | 1操作の関連状態更新を外部呼び出し前に確定 | 別関数で漏れた状態更新、外部利用側、意図したコールバック中状態 | | 共有`nonReentrant` | 同じ再入ガードを使う入口間 | 保護されていない関数、別コントラクト、無防備な`view`、別モジュールのスロット | | 引き出し式の支払い | 支払い側から呼ぶコールバックの時点と責務を分離 | 引き出し側のコールバック、トークンフック、他の外部呼び出し | | 会計スナップショット | コールバック中の比率や価格を安定化 | スナップショット自体のデータ元、別台帳の未更新 | | ストレージ型ガード | 幅広いEVMで同一コントラクトの排他制御 | 永続ストレージへの書き込みと解除の費用、範囲設計 | | 一時ストレージ型ガード | トランザクション内だけの排他制御、次トランザクションで自動消去 | 対応EVM、同一トランザクションの残留ロック、スロット所有権 | OpenZeppelinの`ReentrancyGuard`は一つの再入ガードを共有するため、`nonReentrant`関数同士を直接呼べません。共通処理を`private`に置き、外部の入口を保護する構成が必要です。同時に「全部へ付ける」ことを目的にせず、コールバック中に許可したい構成と禁止する共有不変条件を分けます。 ストレージ版と一時版の最小実装は、どちらも入れ子の入口を拒否し、通常の処理から戻った後の次の呼び出しを成功させました。同じコンパイラーとCancun環境で比較すると、一時版の実行ガスはストレージ版より小さくなりましたが、これは普遍的な削減率ではありません。実際の入口、コンパイラー、最適化、チェーンのハードフォークで再計測します。 ## 不変条件テストは最小の攻撃シーケンスを回帰確認へ戻す 13件の回帰ケースで各分類の既知の挙動を確認しました。件数自体を品質指標にはせず、それぞれが異なる再入経路や防御境界を検証するように分けています。さらにハンドラーへ`attack(rawDepth)`だけを公開し、次の性質を状態保持型の不変条件にしました。 ```text 修正版の保管庫残高 >= 正常な利用者の請求可能額 ``` 修正版は固定シードで64回の試行を行い、各試行で32回、合計2,048回呼び出しても不変条件を保ち、予期しない`revert`もありませんでした。意図的な脆弱版は同じ性質に失敗し、縮約前後とも1回の呼び出しという最小手順になりました。 ```text vm.prank(0x000000000000000000000000000000000000bEEF) ClassicAttackHandler.attack(bound(rawDepth, 1, 3)) → invariant_VaultAlwaysBacksHonestCredit が失敗 → 理由: 正常な利用者への債務を十分に裏付けられない ``` ファザーが生成した攻撃深さの元の値より、入力を境界内へ丸めた後に1回の攻撃だけで正常な債務を裏付けられなくなることが重要です。固定環境、13件の回帰ケース、2,048回の呼び出しで不変条件を保った試行、1回の呼び出しによる反例、各状態差分は[公開検証JSON](/fixtures/reentrancy-taxonomy-6048.json)へ保存しました。[ハンドラー・補助変数・反例の設計](/archives/6022)も合わせて確認できます。 合格は全経路の証明や監査完了ではありません。ハンドラーに含めなかった外部関数、未知のトークン挙動、更新後のモジュール、本番環境固有のオラクルやフックは探索範囲外です。 ## 保管庫・フックへ適用するレビュー時の確認項目 - [ ] `balance >= liabilities`など守る不変条件を式で書いた - [ ] `public`と`external`の入口、`fallback`、`receive`を列挙した - [ ] ETH、トークン、NFT、貸付、フック、ルーター、オラクルへの外部呼び出しを列挙した - [ ] 各外部呼び出しから同じ関数、別関数、別コントラクト、`view`へ戻る経路を追った - [ ] コールバック前の途中状態を読み取り関数ごとに記録した - [ ] CEIが一つの台帳だけでなく関連状態をすべて確定するか確認した - [ ] 再入ガードを同じ不変条件に関わる外部関数と`view`で共有した - [ ] プロキシと`delegatecall`モジュールが同じホストのロックスロットを使うか確認した - [ ] 受取側フックの送信者、運用者、一括処理、発行、焼却をテストした - [ ] ストレージ型と一時ストレージ型のガードについて、成功、`revert`、捕捉、次の呼び出しをテストした - [ ] 固定した単体回帰テストと状態保持型の不変条件テストを両方残した - [ ] 実行履歴の最初の状態差とトランザクション後の状態を分けて読んだ - [ ] 公開RPC、実在対象、実資産を使わずに最小実装で再現した [ERC-4626の資産と持分の会計](/archives/6040)では債務と丸めを、[Uniswap v4のフックとフラッシュ会計](/archives/6041)ではコールバック送信者とトランザクション中の差分を別のモデルで検証しています。どちらも「最後に残高が合う」だけでコールバック途中の読み取りや別の外部関数まで安全になるわけではありません。 [Slither・Aderyn・Mythrilの比較](/archives/6052)では、この記事の基本型と関数横断の再入を同じ正解データへ置き、一般的な外部呼び出しの注意と原因を特定した検出結果を分けています。[Foundry・Echidna・Medusaの状態保持型ファジング比較](/archives/6053)では、コールバック前後の残高差を共通の性質にし、縮約した反例と安全な対照実装まで比較しています。 再入を調べる順番は、**不変条件 → 入口 → 外部呼び出し → コールバック → 途中状態 → 共有する再入ガードの範囲 → 実行履歴 → 状態差分 → 不変条件の回帰テスト**です。`nonReentrant`の有無を最初の結論にせず、何を、どの入口から、どのコントラクトまで一緒に守るロックなのかを説明できる状態を完成とします。 この記事にトークン購入、特定プロトコルの利用、ウォレット接続、署名、トランザクション送信、実資産操作を促す導線はありません。将来監査、形式的検証、テストツール、セキュリティ研修の広告を掲載する場合も、広告表記とローカル再現結果、セキュリティ判断を分離します。 ## 確認した一次情報 - [Solidity Security Considerations: Reentrancy](): 確認日 2026-09-01 - [OpenZeppelin Contracts 5.x ReentrancyGuard](): 確認日 2026-09-01 - [EIP-1153 Transient Storage Opcodes](): 確認日 2026-09-01 - [ERC-777 Token Standard](): 確認日 2026-09-01 - [ERC-721 Non-Fungible Token Standard](): 確認日 2026-09-01 - [ERC-1155 Multi Token Standard](): 確認日 2026-09-01 - [ERC-3156 Flash Loans](): 確認日 2026-09-01 - [Foundry v1.8.0](): 確認日 2026-09-01 --- # ERC-6909とERC-1155の違い｜ID別権限・一括処理・コールバックを比較 ERC-6909とERC-1155を同じトークンID・残高・転送順で実装し、運用者、ID別利用許可額、バッチ転送、受取コールバック、イベント、メタデータ、ガス量を比較します。 正規URL: https://3mikan.com/archives/6049 著者: みかん 公開: 2026-09-01T08:00:00.000Z 更新: 2026-09-02T05:35:00.000Z ERC-6909とERC-1155は、どちらも一つのコントラクトで複数のトークンIDを管理できます。ただし、ERC-6909をERC-1155の上位互換として置き換えることはできません。 選定時は、次の順で要件を固定します。 1. 複数IDを一つの標準関数でまとめて移す必要があるか 2. 転送先コントラクトが受取を明示的に承認する必要があるか 3. 全IDを動かせる運用者だけでなく、IDと数量を限定した利用許可額が必要か 4. ウォレット、ブロックエクスプローラー、索引サービス、市場が、その標準とメタデータを実際に解釈できるか 以降は、残高、権限、複数ID移動、受取確認、イベント、表示情報、ガス、製品対応の順で仕様と実測を対応させます。 ERC-1155の中核インターフェースはバッチ転送と受取側コールバックを含み、権限は全IDを対象にする運用者です。ERC-6909の中核インターフェースはバッチ転送と必須コールバックを外し、全IDの運用者とID別利用許可額を併設します。機能数の大小ではなく、**標準が要求する外部呼び出し・権限・ログの境界**が違います。 この記事はOpenZeppelin Contracts `5.6.1`、Solidity `0.8.36`、Cancun EVM、Foundry `1.8.0`、Anvil `1.8.0`、viem `2.56.0`を固定したローカル検証環境で比較します。外部RPC、メインネットフォーク、ブラウザーウォレット、公開トランザクション、実資産のトークン発行や販売は行いません。 ## まず必要条件を同じ表へ置く | 比較軸 | ERC-1155中核 | ERC-6909中核 | 選定時の確認 | | --- | --- | --- | --- | | 残高 | `balanceOf(owner, id)` | `balanceOf(owner, id)` | 所有者とIDを同時に固定する | | 自分から送る | `safeTransferFrom` | `transfer` | コントラクト宛ての扱いが異なる | | 第三者が送る | 全ID運用者 | 運用者またはID別利用許可額 | 権限の広さと失効方法を分ける | | 複数IDの移動 | `safeBatchTransferFrom`を標準化 | 中核にはない | 独自一括処理のABIを標準扱いしない | | コントラクト受取 | コールバックとマジック値を要求 | 必須コールバックなし | 拒否できるか、誤転送を検出できるか | | 転送イベント | `TransferSingle`と`TransferBatch` | `Transfer` | 索引付き項目と配列の復号を分ける | | メタデータ | `uri(id)`拡張機能 | 名前、シンボル、小数桁、内容URIの拡張機能 | 中核と拡張機能を区別する | | 中核インターフェースID | `0xd9b67a26` | `0x0f632fb3` | ERC-165で実装を照合する | 2026-09-01時点で、ERC-1155とERC-6909のEIP本文はいずれも`Final`です。一方、OpenZeppelinのERC-6909手引きには下書きとする古い説明が残っています。標準の状態はEIP本文を基準とし、ライブラリーが実装を提供する事実とは別に記録します。
同じ複数トークン棚を中心に、ERC-1155の全ID運用者条件と、ERC-6909の全ID運用者およびID別数量札を比較する補助図
権限の正確な関数名と範囲は画像ではなく、次の表と再現結果を基準にしてください。
## 同じ残高・ID・数量で移動する ローカル検証では両コントラクトへ同じ初期残高を発行します。 ```text 所有者 ID 1: 100 ID 2: 50 1. 所有者がID 1を10移動 2. 運用者がID 2を7移動 3. ID 1とID 2を4・5ずつ別アカウントへ移動 ``` 直接転送と運用者による転送後の残高は、両標準で一致します。違いが出るのは、誰にどこまで移動権限を渡すか、複数IDを何回の標準呼び出しで動かすか、転送先コントラクトを呼ぶかです。 ## 運用者は両方とも全IDへ届く ERC-1155の`setApprovalForAll(operator, true)`は、その所有者が持つすべてのIDを運用者が移動できるようにします。中核インターフェースにIDと数量を限定する利用許可額はありません。 ERC-6909にも`setOperator(spender, true)`があり、同じく全IDへ無制限に届きます。ID別利用許可額が追加されたからといって、運用者の広い権限が消えるわけではありません。 | 状態 | ERC-1155 | ERC-6909 | | --- | --- | --- | | 運用者無効 | 所有者本人だけ | 所有者本人、またはID利用許可額を持つ利用先 | | 運用者有効 | 全IDを移動可能 | 全IDを移動可能 | | ID 1だけ8許可 | 中核では表現できない | `approve(spender, 1, 8)` | | ID 2への影響 | 運用者なら届く | ID 1利用許可額だけなら届かない | ローカルテストではERC-6909でID 1を`8`許可し、利用先が`6`移動した後の利用許可額が`2`になることを確認しました。同じ利用先がID 2を移動すると`revert`します。 また、同じアカウントに運用者とID利用許可額の両方がある場合、固定したOpenZeppelin `5.6.1`実装は運用者を先に確認し、ID利用許可額を消費しません。これは今回のライブラリー実装で観測した順序です。独自実装をレビューするときは、運用者パスで利用許可額を誤って減算しないかもテストします。 [ERC-20の`approve`・Permit・Permit2・一時的利用許可比較](/archives/6012)では、利用先、保存先、期限、失効を同じ順で確認しています。ERC-6909でも「署名があるか」ではなく、所有者・利用先・ID・数量・運用者の5項目を分けます。 ## 一括処理は一つのトランザクションと同じ意味ではない ERC-1155は`safeBatchTransferFrom`を中核インターフェースに含めます。ID配列と数量配列の長さ・順序を合わせ、複数残高の更新と`TransferBatch`を一つの標準呼び出しで表現します。転送先がコントラクトならバッチ受取用のコールバックも必要です。 ERC-6909の中核には、一括処理用の関数はありません。実装が独自の一括処理を追加することはできますが、呼び出しデータの配置、イベント、コールバック、失敗時の一体性は実装固有の仕様です。組み込み担当者は「ERC-6909対応」という情報だけから独自一括処理の存在を推測できません。 同じ条件のローカル検証では、次の2方式で結果を作りました。 - ERC-1155: ID 1を4、ID 2を5、一つの一括呼び出しで移動 - ERC-6909: ID 1とID 2を二つの`transfer`トランザクションで移動 後者は一つ目だけ成功し二つ目が失敗する状態を取り得ます。両方を一つのトランザクションへまとめたい場合は、呼び出し側の一括処理コントラクトまたは実装固有拡張機能が必要です。 ## 受取側コールバックは受取確認と外部呼び出しを同時に作る ERC-1155では、転送先がコントラクトなら残高とイベントを更新した後に受取側フックを呼びます。フックが正しいマジック値を返さない、または`revert`すれば転送全体も`revert`します。 ローカル実行の受理例では、`3`を受け取るコールバック内から受取側自身の残高`3`を読めました。拒否例ではトランザクションが`revert`し、所有者残高も元に戻りました。
ERC-1155の複数トークントレイが受取側条件で受理または`revert`される経路と、ERC-6909が必須条件を通らず個別に届く経路を比較する補助図
コールバックがない経路は外部呼び出しを一つ減らしますが、転送先コントラクトがトークンを扱える証明にはなりません。
### コールバック中に別の転送へ入れる 再現用受取側はコールバック中、受け取ったID 1の`1`を別アカウントへ`safeTransferFrom`しました。外側と内側で合計2件の転送イベントが発生し、受取側の最終残高は0、転送先は1です。 これはERC-1155の欠陥を意味しません。仕様どおり、コールバック前に残高が更新されているため、受取側がその残高を使う別呼び出しを開始できるという制御フローの境界です。トークンを受け取った後に独自会計を更新するコントラクトは、コールバックで到達可能な別の入口と不変条件を確認します。 [再入の分類と再入ガードの範囲](/archives/6048)で、受取側コールバック、別関数、別コントラクトを同じ呼び出しグラフへ置く方法を扱っています。 ### コールバックがなければ常に安全、ではない ERC-6909で同じ受取側コントラクトへ送ると転送は成功し、ERC-1155コールバックの呼出回数は0でした。必須外部呼び出しがないことは、標準転送の制御フローを小さくします。 ただし、受取側は受取を拒否できません。トークンを戻す関数を持たないコントラクトへ送れば、残高がそのコントラクトに残ることがあります。また、独自拡張機能、フック、手数料処理、更新モジュールが外部呼び出しを追加する可能性は別です。 「ERC-6909だから再入がない」ではなく、実際の実装の呼び出しグラフを確認します。 ## イベントから残高を再構築する 索引サービスは、関数名ではなくイベントの索引付き項目とデータを標準ごとに復号します。 ```solidity // ERC-1155 event TransferSingle( address indexed operator, address indexed from, address indexed to, uint256 id, uint256 value ); event TransferBatch( address indexed operator, address indexed from, address indexed to, uint256[] ids, uint256[] values ); ``` ```solidity // ERC-6909 event Transfer( address caller, address indexed sender, address indexed receiver, uint256 indexed id, uint256 amount ); ``` ERC-1155は運用者、送信元、送信先を索引付きにし、IDと数量をデータへ置きます。ERC-6909は送信者、受取側、`id`を索引付きにし、呼び出し元と数量をデータへ置きます。同じ四つのトピックでも意味は同じではありません。 ローカル観測コードは新しいAnvil環境から発行、単一転送、バッチ転送、入れ子転送、焼却のログを取得し、`decodeEventLog`で0から残高を再構築します。 | 標準 | 復号した転送ログ | バッチイベント | 照合したアドレス・ID組 | チェーン残高との一致 | | --- | ---: | ---: | ---: | --- | | ERC-1155 | 単一8件、一括処理1件 | 1 | 9 | 一致 | | ERC-6909 | 10件 | 中核になし | 8 | 一致 | 発行は送信元または送信者をゼロアドレス、焼却は送信先または受取側をゼロアドレスとして差分へ反映します。`ApprovalForAll`、`OperatorSet`、`Approval`は権限履歴であり、トークン残高へ加算しません。 ## メタデータは中核と拡張機能を分ける ERC-1155のメタデータURI拡張機能は`uri(id)`を定義し、`{id}`をクライアント側で置き換える形式を取れます。基底コントラクトが返す文字列にIDが展開済みとは限りません。 ERC-6909は任意拡張機能として、IDごとの`name`、`symbol`、`decimals`、コントラクトとトークンの内容URI、合計供給量を分けています。OpenZeppelinの基底`ERC6909`だけではメタデータや供給量を持たず、必要な拡張機能を継承します。 比較環境では、ERC-1155に`{id}` URI、ERC-6909にID 1の名前、シンボル、18小数桁、個別トークンURIを設定しました。実運用では、表示クライアントがどのインターフェースを問い合わせるかまで確認します。 ## ガスは固定した操作条件だけで読む 次はローカルAnvil実行結果の`gasUsed`です。OpenZeppelin `5.6.1`、Solidity `0.8.36`、最適化の実行回数200、Cancun EVM、初回受取残高0という今回の条件だけに適用します。 | 操作 | ERC-1155 | ERC-6909 | 比較単位 | | --- | ---: | ---: | --- | | コントラクトデプロイ | 1,180,046 | 1,063,391 | 比較用コントラクト一つ | | ID 1・2を別々に発行 | 95,904 | 94,334 | 2トランザクション合計 | | 所有者からID 1を10移動 | 56,920 | 52,396 | 1トランザクション | | 運用者がID 2を7移動 | 59,198 | 55,276 | 1トランザクション | | ID利用許可額で6移動 | 中核になし | 43,747 | 利用許可額作成ガスを含めない転送本体 | | ID 1・2を4・5移動 | バッチ転送88,798 | 2転送合計104,792 | 最終残高が同じ操作 | | 受取側へ3移動 | コールバック込み106,415 | 必須コールバックなし52,612 | コントラクト受取先 | この表から「ERC-6909は常に安い」とは結論しません。独自一括処理、メタデータ、供給量、アクセス制御、フックを加えればバイトコードと実行ガスは変わります。ERC-1155一括処理とERC-6909の二つのトランザクションでは一体性も異なります。 [Uniswap v4のPoolManagerとフラッシュ会計](/archives/6041)でERC-6909化という選択肢が現れるのは、プロトコル内部の債権をIDで管理する文脈です。ウォレットで収集品を受け取り市場へ出す要件と、同じ組み込み前提にはしません。 ## ツール対応は三段階で記録する | 対象 | 状態 | 今回確認したこと | | --- | --- | --- | | EIP状態・必須インターフェース | 公式 | EIP-1155とEIP-6909の本文、インターフェースID、メソッド、イベント、コールバック規則 | | OpenZeppelin・Foundry・viem | 実測 | 5.6.1をコンパイルし、権限・転送・コールバックを再現、Anvilログを復号して残高と照合 | | ウォレット・ブロックエクスプローラー・索引サービス・市場表示 | 未確認 | 認証済みの実際のUIを記録していないため、対応済みと書かない | ABIを復号できることと、製品UIが残高、画像、承認、転送を正しく表示することは別です。製品対応を要件にする場合は、対象バージョン、ネットワーク、コントラクト、ID、転送・受取・失効の画面を実測します。 ## 用途から選ぶ判断表 | 必要条件 | 第一候補 | 理由 | 残る確認 | | --- | --- | --- | --- | | 多数のIDを標準一括処理でまとめて移す | ERC-1155 | 中核に一括処理がある | 受取側の一括処理コールバック、配列上限 | | コントラクトが受取拒否できることを必須にする | ERC-1155 | マジック値で受理を確認 | コールバック再入、ガス、互換性 | | IDと数量を限定した利用先を標準で持つ | ERC-6909 | ID別利用許可額が中核にある | 運用者の全ID権限、利用許可額失効 | | プロトコル内部の軽量な複数債権 | ERC-6909を検討 | 一括処理とコールバックを中核から外す | 独自組み込み、回収経路、ツール対応 | | ウォレットやNFT市場との互換性が最優先 | 実測して決める | 標準仕様だけでは製品対応を証明できない | 対象製品・バージョン・ネットワーク | | 独自一括処理やフックが必須 | 実装仕様を比較 | 中核標準外の差が支配的 | ABI、イベント、一体性、外部呼び出し | ## 実装・レビュー時の確認項目 - [ ] 所有者、運用者、利用先、ID、数量を別々に列挙したか - [ ] 運用者が全IDへ届くことをUIと失効手順で示したか - [ ] ERC-6909利用許可額が別IDへ漏れず、有限値と無限値を正しく扱うか - [ ] 一括処理の失敗が全件`revert`か、部分成功し得るかをテストしたか - [ ] コントラクト受取先の受理、拒否、誤転送、回収経路を確認したか - [ ] コールバックから到達できる別の外部関数と共有不変条件を確認したか - [ ] イベントの索引付き項目、一括処理配列、発行と焼却のゼロアドレスを復号したか - [ ] 中核インターフェースとメタデータ、供給量、独自拡張機能を分けたか - [ ] ガスにコンパイラー、最適化、EVM、ライブラリー、操作条件を添えたか - [ ] ウォレット、ブロックエクスプローラー、索引サービス、市場対応を推測で埋めていないか [公開した固定検証JSON](/fixtures/multi-token-standards-6049.json)に実測値、イベント再構築結果、Foundryとviemの再現条件を保存しています。生成画像は概念説明であり、製品対応、ガス、イベント、コントラクト安全性の証拠には使いません。 ## 確認した一次情報 - [ERC-6909 Minimal Multi-Token Interface](): 確認日 2026-09-01 - [ERC-1155 Multi Token Standard](): 確認日 2026-09-01 - [OpenZeppelin ERC-6909 guide](): 確認日 2026-09-01 - [OpenZeppelin ERC-1155 guide](): 確認日 2026-09-01 - [OpenZeppelin Contracts 5.6.1](): 確認日 2026-09-01 - [OpenZeppelin ERC6909 5.6.1 source](): 確認日 2026-09-01 - [OpenZeppelin ERC1155 5.6.1 source](): 確認日 2026-09-01 - [viem decodeEventLog](): 確認日 2026-09-01 - [Foundry v1.8.0](): 確認日 2026-09-01 --- # Solidityのビルド設定入門｜最適化・viaIR・EVMバージョン・バイトコード 同じSolidityソースを、最適化の想定実行回数、viaIR、対象EVM、メタデータ、solcのバージョンが異なる7条件でビルドし、バイトコード、サイズ、デプロイ時のガス、実行時のガス、挙動を分けて検証します。 正規URL: https://3mikan.com/archives/6050 著者: みかん 公開: 2026-08-31T18:30:00.000Z 更新: 2026-09-02T05:35:00.000Z 同じSolidityソースでも、コンパイラーバージョンとビルド設定が違えば、作成時バイトコード、実行時バイトコード、メタデータ、コントラクトサイズ、ガスは変わります。ソースだけが同じでも、ブロックエクスプローラーの検証済みバイトコードや再現ビルドが一致するとは限りません。 この記事では2026-09-01時点のSolidity最新安定版`0.8.36`と比較用`0.8.35`、Foundry `1.8.0`を固定し、一つのコントラクトを7条件でビルドしました。すべてローカルAnvil上の計測で、外部RPC、ウォレット、個人の鍵、公開トランザクション、実資産は使いません。 結論を先に置くと、`optimizer_runs`は最適化処理を何回繰り返すかではありません。想定する実行回数に応じて、デプロイ時のコードサイズと利用中の実行費用のどちらを重く見るかを伝える値です。`via_ir`、`evmVersion`、メタデータ、solc更新も別の軸なので、設定名だけで優劣を決めず、同じ入力とテストで差分を測ります。 ## ビルド結果を決めるもの 再現に必要なのは`.sol`だけではありません。最低限、次の7項目を一つの記録にします。 1. ソース内容とハッシュ 2. 完全なsolcバージョン 3. Standard JSONの最適化設定、`viaIR`、`evmVersion`、メタデータ設定 4. 追加リマッピングと依存パッケージのバージョン 5. ライブラリーアドレスとリンク時点 6. コンストラクター引数、`immutable`変数、対象チェーン 7. 期待する作成時と実行時のバイトコードハッシュ、挙動テスト コンパイラーのStandard JSONインターフェースは自動ビルドの基準です。CLIやFoundryの設定も、最終的には同じ境界をコンパイラー入力へ渡します。 ```json { "optimizer": { "enabled": true, "runs": 200 }, "viaIR": false, "evmVersion": "prague", "metadata": { "bytecodeHash": "ipfs", "appendCBOR": true } } ``` 今回の検証用コントラクトは、`pure`な反復計算、結果をストレージへ書く正常系、独自エラーで`revert`する失敗系を持ちます。同じ入力`execute(17, 32, 1)`を各ビルドへ送り、出力、成功状態、独自エラーのセレクターが変わらないことも確認しました。
3MIKANのキャラクターが一つの設計図から設定の異なる3台のビルド機構へ入力し、長さと構成が異なるバイトコードタイル列を比較する図
図は同一ソースから異なる出力が生まれる関係の補助表現です。正確な設定、バイト数、ハッシュ、ガスは下の表と公開JSONを基準にしてください。
## 7条件のバイトコード・サイズ・ガスを比較する ガスは二つに分けました。デプロイガスは新しいコントラクトを作ったトランザクションレシートの`gasUsed`、実行時ガスは初回の`execute(17,32,1)`でストレージを0から更新したレシートの`gasUsed`です。基準手数料とガス価格は0に固定し、通貨換算はしません。 | ビルド条件 | 作成時バイト | 実行時バイト | メタデータバイト | デプロイガス | 実行時ガス | | --- | ---: | ---: | ---: | ---: | ---: | | 従来方式、想定実行回数1、Prague | 624 | 596 | 53 | 182,147 | 47,261 | | 従来方式、想定実行回数200、Prague | 624 | 596 | 53 | 182,147 | 47,261 | | 従来方式、想定実行回数10,000、Prague | 724 | 696 | 53 | 202,439 | 47,261 | | viaIR、想定実行回数200、Prague | 443 | 417 | 53 | 143,417 | 47,008 | | 従来方式、想定実行回数200、Paris | 648 | 617 | 53 | 186,453 | 47,268 | | 従来方式、想定実行回数200、メタデータハッシュなし | 583 | 555 | 12 | 173,283 | 47,261 | | solc 0.8.35、従来方式、想定実行回数200 | 624 | 596 | 53 | 182,147 | 47,261 | この小さなコントラクトでは、想定実行回数1と200でメタデータを除いた実行時部分は同じでした。想定実行回数を含むメタデータハッシュが変わるため、実行時バイトコード全体のハッシュは異なります。想定実行回数10,000ではメタデータを除いた実行時部分が543バイトから643バイトへ増えましたが、今回選んだ実行時操作のガスは47,261のままです。 つまり「想定実行回数を上げれば常に実行時ガスが下がる」とは言えません。最適化処理は振り分け、定数、インライン化などの候補を、想定利用回数とのトレードオフで選びます。実際の効果はコントラクトと入口ごとに測ります。 viaIRビルドは今回、実行時417バイト、デプロイ143,417ガス、実行時47,008ガスでした。従来方式より小さい結果ですが、この一例をすべてのコントラクトへ一般化はできません。IR経由の処理はSolidityをYul IRへ変換してから最適化するため、出力経路そのものが異なります。 ## 最適化の想定実行回数は処理の反復回数ではない Solidity公式は最適化を、コード生成、Yul IR、命令コードの三層に分けています。`runs`は各命令コードがコントラクトの生涯で何回ほど実行されるかという期待値で、最適化処理の反復回数ではありません。 低い値は一般に短いコードと安いデプロイを重く見ます。高い値は繰り返し利用時の実行費用を重く見て、インライン化や定数の表現が長くなる場合があります。ただし「想定実行回数1なら必ず最小」「10,000ならすべての関数が安い」という保証ではありません。 比較するときは、少なくとも次を分離します。 | 観測対象 | 何を測るか | 混ぜないもの | | --- | --- | --- | | 作成時バイトコード | コンストラクターを実行して実行時を返すコード | ABI符号化済みのコンストラクター引数 | | 実行時バイトコード | デプロイ後にアドレスへ保存されたコード | 作成時コード、トランザクション入力 | | メタデータを除いた実行時部分 | CBORメタデータ末尾データを除いた部分 | メタデータハッシュだけの差 | | デプロイガス | 作成時トランザクション全体 | 実行時呼び出しガス、手数料換算 | | 実行時ガス | 固定した外部関数・状態・入力 | 別関数、ウォームとコールドの条件差 | コントラクトサイズが小さくても、よく使う経路が安いとは限りません。逆にデプロイガスが増えても、長期に高頻度で使うコントラクトでは総費用が下がる可能性があります。想定トランザクション数を置いて損益分岐を計算し、更新後も同じ性能比較を回します。 ## viaIRはバイトコードだけの切り替えではない 従来方式とIR経由の処理には小さな意味の差があるため、Solidity公式は移行時の注意点を別ページにまとめています。今回の正常系と独自エラー失敗系は、両方で同じ結果とエラーセレクターになりました。それでも「同じ挙動は自動的に保証された」とは扱いません。 一方、17個の引数を一つの式へ束ねたスタック負荷用コントラクトは、従来方式で`Stack too deep`になり、viaIRでは作成時275バイト、実行時250バイトとしてビルドできました。viaIRがコンパイル失敗を解消する場合があることと、既存コントラクトの挙動を回帰確認しなくてよいことは別です。 移行時は次の順で確認します。 1. 従来方式とviaIRを同じsolc、対象EVM、最適化の想定実行回数でビルドする 2. 正常系の戻り値、イベント、ストレージ差を比較する 3. `revert`の型、独自エラー識別子、巻き戻し後の状態を比較する 4. バイトコードサイズ、デプロイガス、頻出する外部関数のガスを別々に測る 5. 継承初期化、インラインアセンブリ、`memory-safe`指定、ライブラリー境界をレビューする 6. コンパイラーの既知不具合を対象バージョンと設定で照合する `Stack too deep`が消えたことだけで採用を決めず、差分テストとレビューの開始点にします。 ## 対象EVMが違うと命令コードと実行可否が変わる `evmVersion`は「どのチェーン名へデプロイするか」ではなく、コンパイラーが利用してよい命令コードとガスモデルを決める対象です。Solidity公式も、実行環境と一致しない対象は失敗や予期しない挙動につながると警告しています。 今回、Paris対象の作成時バイトコードと実行時バイトコードには`PUSH0`が含まれませんでした。Prague対象の従来方式ビルドには作成時32個、実行時28個の`PUSH0`が含まれます。`PUSH0`はShanghaiで導入されたため、Prague対象で生成された作成時バイトコードをParis Anvilへ送るとデプロイで`revert`しました。 Paris対象ビルドは同じParis Anvilでデプロイと実行時呼び出しに成功しています。
3MIKANのキャラクターが旧対象と新対象の2台の実行条件を点検し、新しい小型タイルを含むバイトコード列が旧条件へ入らない境界を確認する図
画像は互換性の概念図です。ParisとPrague、PUSH0の数、デプロイ結果は本文と公開JSONを基準にしてください。
非公開チェーン、L2、フォーク前ブロック、古いローカルノードでは、ネットワーク名だけを見ず実際のハードフォークサポートを確認します。[EVM・ハードフォーク差分の追跡方法](/archives/6043)では命令コード、プリコンパイル、ガス、システムコントラクトを層に分けています。 ## メタデータを除けば同じでも、バイトコード全体は違う場合がある Solidityは通常、実行時末尾へCBORメタデータを付けます。今回の`bytecodeHash: "ipfs"`では53バイト、`bytecodeHash: "none"`でも`appendCBOR: true`のため12バイトの末尾データが残りました。後者のメタデータを除いた実行時部分は前者と完全一致していますが、実行時バイトコード全体のハッシュと総バイト数は異なります。 検証済みソースを再現するときは、次の三つを同じ意味にしません。 - バイトコード全体が完全一致する - メタデータを分けた機能部分のバイトコードが一致する - ソースコードが見た目として同じである ライブラリーのリンク、`immutable`変数、コンストラクター引数も比較位置が違います。ライブラリーアドレスはコンパイラー入力へ入れてリンクするのが原則で、後からバイトコードを書き換えるとメタデータは更新されません。[検証済みソースとバイトコード再現](/archives/6033)で作成時、実行時、メタデータ、ライブラリー、`immutable`変数を分解しています。 ## コンパイラー更新はハッシュ差と挙動差を別に見る 同じ設定でsolc `0.8.35`から`0.8.36`へ上げると、今回の実行時バイトコード全体のハッシュは変わりました。一方、メタデータを除いた実行時部分のハッシュ、サイズ、デプロイガス、実行時ガス、正常系の出力は同じでした。 これは「更新しても常に機能的コードが同じ」という意味ではありません。今回の差はバージョンを含むメタデータへ閉じましたが、コンパイラーのリリースには最適化、コード生成、不具合修正が含まれます。更新レビューでは次を固定します。 | 差分 | 判定方法 | | --- | --- | | コンパイラー識別情報 | 完全なバージョンと配布パッケージを固定する | | 入力 | ソースハッシュとStandard JSONを保存する | | 出力 | 作成時、実行時、メタデータを除いた実行時部分、メタデータのハッシュを分ける | | 挙動 | 正常、`revert`、イベント、ストレージ、戻り値データを比較する | | ガス | 同じハードフォーク、初期状態、送信者、入力で実行結果を比較する | | 既知不具合 | 古いバージョンと新しいバージョンの条件へ該当するか確認する | プロキシ更新ではコンパイラー差に加えてストレージ配置と権限が関わります。[ERC-7201名前空間付きストレージの更新差分](/archives/6046)を使い、ストレージの生データと配置も同じレビューへ入れます。 ## 再現ビルド記録を作る 今回の[公開検証JSON](/fixtures/solidity-build-settings-6050.json)には、ソースSHA-256、二つのコンパイラーの完全なバージョン、7条件のStandard JSON設定、作成時、実行時、メタデータを除いた実行時部分、メタデータの各ハッシュ、バイト数、PUSH0の数、デプロイガス、実行時ガス、正常系出力、独自エラーセレクターを保存しました。 各条件は同じプロセスで2回ビルドし、作成時と実行時のハッシュが一致することを確認しています。再現確認は「手元でビルドできた」で終えず、期待ハッシュと比較して初めて合格にします。 ```text 1. ソースハッシュを照合する 2. 正確なコンパイラーパッケージを選ぶ 3. 保存したStandard JSON設定でビルドする 4. 作成時、実行時、メタデータを除いた実行時部分、メタデータのハッシュを計算する 5. 期待するハッシュと比較する 6. 固定入力の正常系・失敗系テストを実行する 7. 対象ハードフォーク上でガスと命令コードの互換性を測る ``` Foundryではプロフィールごとに`solc_version`、`optimizer`、`optimizer_runs`、`via_ir`、`evm_version`、`bytecode_hash`を明記できます。環境変数や自動コンパイラー検出に任せた値も、公開版成果物へ残す記録では明示値へ展開します。 ## ビルド設定変更のレビュー時の確認項目 - [ ] ソースコミットとソースハッシュを固定した - [ ] solcの完全なバージョンと取得元を固定した - [ ] Standard JSON入力または等価な全設定を保存した - [ ] 最適化の有効・無効と想定実行回数を別項目で記録した - [ ] 従来方式とviaIRの正常系と失敗系を比較した - [ ] 対象EVMとデプロイ先ハードフォークを照合した - [ ] 作成時、実行時、機能的、メタデータを分けてハッシュ化した - [ ] ライブラリーアドレス、リマッピング、依存関係、コンストラクター引数を固定した - [ ] デプロイガスと主要な外部関数の実行時ガスを分けた - [ ] 同じ状態、送信者、入力、ハードフォークでガスを比較した - [ ] コンパイラー更新前後で戻り値、`revert`、イベント、ストレージを比較した - [ ] 対象バージョンと設定を既知不具合へ照合した - [ ] 期待バイトコードハッシュを使う再ビルド検証を自動化した - [ ] 公開RPC、ウォレット、実資産を使わない最小再現を先に作った [Foundry不変条件テストの設計](/archives/6022)を使えば、単体テストにない状態シーケンスもコンパイラー変更前後で比較できます。ただしファジングや不変条件の合格も、入力空間全体の証明や監査完了ではありません。 [Slither・Aderyn・Mythrilの同一プロジェクト比較](/archives/6052)では、このビルド条件を固定したまま、脆弱な例と安全な対照例から成る正解データを走査し、ソース検出器が見ない対象EVM互換性を別工程へ残しています。 再現ビルドは、ソースハッシュ、solcバージョン、Standard JSON設定、ライブラリーアドレス、対象EVM、期待バイトコードハッシュ、挙動テストを一つの記録に固定します。設定変更のレビューでは「ガスが下がった」「`Stack too deep`が消えた」だけで終えず、何が変わり、何が同じだったかを作成時、実行時、メタデータ、挙動の各層で説明できる状態を完成とします。 この記事にトークン購入、特定プロトコルの利用、ウォレット接続、署名、トランザクション送信、実資産操作を促す導線はありません。将来コンパイラーツール、検証、監査、テストツール、開発者教育の広告を掲載する場合も、広告表記と再現結果、セキュリティ判断を分離します。 ## 確認した一次情報 - [Solidity 0.8.36 release](): 確認日 2026-09-01 - [Solidity Using the Compiler](): 確認日 2026-09-01 - [Solidity Optimizer internals](): 確認日 2026-09-01 - [Solidity IR-based Codegen Changes](): 確認日 2026-09-01 - [Solidity Contract Metadata](): 確認日 2026-09-01 - [Solidity List of Known Bugs](): 確認日 2026-09-01 - [EIP-3855 PUSH0 instruction](): 確認日 2026-09-01 - [Foundry Solidity compiler configuration](): 確認日 2026-09-01 - [Foundry v1.8.0](): 確認日 2026-09-01 --- # Foundryのフォークテスト入門｜ブロック固定・状態変更・シミュレーション Foundryのフォークテストについて、ブロック番号・ハッシュ、RPC、履歴ノード、フォークID、prank・deal・store・etch・warp・rollによる変更まで固定し、eth_callや実トランザクションとの境界を検証します。 正規URL: https://3mikan.com/archives/6051 著者: みかん 公開: 2026-08-31T19:30:00.000Z 更新: 2026-09-02T05:35:00.000Z Foundryのフォークテストは、既存チェーンの状態を参照しながらローカルでコントラクトを動かすための仕組みです。プロトコル連携、インシデント再現、更新前後の比較には便利ですが、「メインネットを完全に複製した環境」でも「本番トランザクションが成功する証明」でもありません。 再現性を決めるのはRPC URLだけではありません。チェーンID、接続先の識別情報、ブロック番号、ブロックハッシュ、履歴状態、フォークID、ローカルで変更したアカウント・スロット・コード・タイムスタンプを一緒に残します。`latest`で作ったフォークへ`prank`や`deal`を重ね、成功結果だけを共有すると、読み手はチェーン由来の事実とテスト用の仮定を分けられません。 この記事ではFoundry `1.8.0`、Solidity `0.8.36`、二つのローカルAnvilプロバイダーを使い、同じチェーンID・同じコントラクトアドレス・同じブロック番号でも、ブロックハッシュと状態が異なる境界を再現しました。さらに履歴不足のRPC、複数フォーク、`prank`、`deal`、`store`、`etch`、`warp`、`roll`、`eth_call`、ローカルトランザクションを分けて検証しています。公開RPC、APIキー、ウォレット、署名済みトランザクション、公開ネットワーク、実資産は使っていません。 結論を先に置くと、フォークの再現単位は、チェーンIDではなく、RPC識別情報、ブロック番号、ブロックハッシュ、フォークID、ローカル変更操作を一つの記録へ固定した組み合わせです。 ## ローカルコントラクトだけのテストとフォークテストを使い分ける 外部プロトコルの状態を必要としないビジネスルールは、ローカルにデプロイした小さなコントラクトで先に検証します。速く、RPC停止やプロバイダー差の影響を受けず、失敗条件を小さくできます。 フォークテストが必要になるのは、次のような境界です。 - 特定ブロック時点の既存コントラクトコード・ストレージ・残高へ依存する - プロキシ実装、プール予備、オラクル観測など複数コントラクトの組み合わせを再現する - 実際のアドレス・ABI・ストレージ配置に対する組み込みを確認する - 過去のトランザクション直前または直後の状態を比較する - 更新候補を既存状態へ重ねたときの挙動を見る 一方、アクセス制御、計算式、`revert`条件、状態遷移、不変条件はローカルテストでも確認できます。最初から大きなフォークへ寄せると、RPC失敗とコントラクト不具合が同じ失敗に見えます。単体テスト・ファジング・不変条件テストの分担は[Foundry不変条件テストの記事](/archives/6022)で詳しく整理しています。
青灰色のチェーン状態をブロックスナップショットとして固定し、オレンジ色で呼び出し元・残高・ストレージ・コードをローカル変更してから検証結果へ進む出所図
青灰色はプロバイダー由来、オレンジ色はローカル変更を表す概念図です。正確なブロック識別情報、値、チートコード、判定は下の表と公開JSONを基準にしてください。
## `createFork`と`createSelectFork`でブロックを固定する `vm.createFork(urlOrAlias, blockNumber)`はフォークを作るだけで、有効フォークは切り替えません。`vm.createSelectFork(urlOrAlias, blockNumber)`は作成と選択を一度に行い、どちらもフォークIDを返します。`vm.selectFork(forkId)`で切り替え、`vm.activeFork()`で現在のIDを確認できます。 ```solidity uint256 primary = vm.createFork(vm.envString("PRIMARY_RPC"), 2); uint256 secondary = vm.createFork(vm.envString("SECONDARY_RPC"), 2); vm.selectFork(primary); assertEq(vm.activeFork(), primary); vm.selectFork(secondary); assertEq(vm.activeFork(), secondary); ``` ブロックを省略するとフォーク作成時の`latest`が選ばれます。今回の主系プロバイダーでは、固定ブロック`2`の値が`41`、作成時の`latest`ブロック`3`の値が`42`でした。1ブロック進んだだけで状態が変わるため、`latest`フォークは同じコードを後日実行しても同じ開始点になりません。 | フォーク条件 | ブロック番号 | ブロックハッシュ | 読み取った値 | | --- | ---: | --- | ---: | | 主系・固定 | 2 | `0x627ada…05ba` | 41 | | 主系・`latest` | 3 | `0xdff0cf…6513` | 42 | | 副系・固定 | 2 | `0x6f95ad…122` | 91 | | 副系・`latest` | 3 | `0x329732…0cf` | 92 | Foundryのブロック番号指定だけでは、同じ高さが同じブロックだったことまでは表せません。フォーク作成前に`eth_getBlockByNumber`でハッシュを取得し、番号とハッシュを一組で保存します。[Ethereum RPCスナップショットの記事](/archives/6024)と同様に、再実行時はハッシュも照合します。 今回の二つのプロバイダーはチェーンID `31337`、コントラクトアドレス、固定ブロック番号が同じですが、固定ブロックハッシュとストレージ値が異なりました。これはプロバイダー優劣ではなく、別のローカル履歴でチェーン再編相当の不一致を作ったものです。チェーンIDと高さだけで同一状態と判断できないことを示します。 ## フォーク記録でチェーン由来とローカル変更を分ける 実行前に記録を作り、実行後に変更履歴と期待結果を追記します。接続先は秘密情報を含まない別名または識別名を保存し、認証情報を含むURLやAPIキーは残しません。 ```json { "chainId": 31337, "endpoint": "local-anvil-primary", "blockNumber": "2", "blockHash": "0x627ada8d...05ba", "forkId": "実行時の値。別の実行とは比較しない", "archiveRequired": true, "target": "0x5FbDB2...80aa3", "mutations": [ { "kind": "prank", "caller": "0x...bEEF", "signature": false }, { "kind": "store", "slot": "0x0", "before": "41", "after": "777" } ], "expected": { "valueBefore": "41", "valueAfter": "777" } } ``` フォークIDはFoundryプロセス内の識別子で、チェーンIDやネットワークIDではありません。別の実行で同じ数字になる保証を期待せず、その実行内で`activeFork()`と対応させるために使います。 | 項目 | チェーン由来 | ローカル変更 | 証拠として言える範囲 | | --- | --- | --- | --- | | コード・ストレージ・残高 | 固定ブロックをRPCから取得 | `etch`・`store`・`deal`後は変更済み | 変更操作前だけが取得時点のプロバイダー状態 | | 呼び出し元 | トランザクションや呼び出しの文脈 | `prank`で上書き | 署名や秘密鍵の所持は示さない | | ブロックタイムスタンプ | ブロックヘッダー | `warp`で上書き | 実チェーンでその時刻へ進むことは示さない | | ブロック番号 | フォーク開始ブロック | `roll`または`rollFork` | ヘッダー・状態・`blockhash`の連続性を別確認する | | 想定した結果 | 仕様・観測から定義 | 検証結果で照合 | 本番実行の成功やガス価格は保証しない | 変更前と変更後を同じ記録へ入れると、`777`を「ブロック2に実在したストレージ」と誤読する余地が減ります。公開した[再現結果JSON](/fixtures/foundry-fork-testing-6051.json)には、二つのプロバイダー、フォークの識別・状態照合結果、六つの変更操作、履歴取得の失敗、`eth_call`とローカルトランザクションの差をまとめています。 ## RPC・履歴・キャッシュ・チェーン再編相当の失敗を分ける フォークは必要な状態をRPCから取得します。過去ブロックのヘッダーが読めても、その時点のアカウント状態やストレージをノードが保持しているとは限りません。過去状態を必要とする場合は、対象ブロックを提供できる履歴対応接続先が必要です。 今回の履歴制限プロキシは`latest`への読み取りを通す一方、ブロック`2`の`eth_getStorageAt`をJSON-RPCコード`-32000`、`historical state unavailable: archive data required`で拒否しました。その結果、固定ブロックフォークの作成は失敗し、`latest`状態の読み取りは成功しています。 この失敗はSolidityの`revert`ではありません。次の順に層を分けます。 1. 接続先へ接続できるか 2. チェーンIDと想定ネットワークが一致するか 3. ブロック番号とハッシュを取得できるか 4. 対象ブロックのコード・残高・ストレージが読めるか 5. フォーク作成後、対象アドレスのコードハッシュと主要スロットが期待どおりか 6. 検証処理が対象状態の照合まで進んだか プロバイダーを切り替えたときは、同じチェーンIDや同じブロック番号だけでキャッシュを信用しません。ブロックハッシュ、対象コードハッシュ、主要スロットを再照合します。検証済みソースからバイトコードと設定を照合する手順は[検証済みコントラクトの再構築記事](/archives/6033)も参照してください。
プロバイダーのハッシュ差、履歴不足、変化する最新状態、時刻とオラクルのローカル仮定という四つのFoundryフォークテスト失敗境界を3MIKANのキャラクターが照合する図
同じ高さに見えるブロックでも識別情報は別になり得ます。図は境界の補助表現で、実際のハッシュ、RPCエラー、タイムスタンプ、状態は本文と公開JSONで確認します。
## `prank`とネットワークへの送信は目的が違う `vm.prank(address)`は次の呼び出しで`msg.sender`を指定アドレスへ変えます。秘密鍵を読み込まず、署名を作らず、そのアドレスの権限を現実に取得するものでもありません。 今回の検証では`0x…bEEF`を呼び出し元にして、対象が観測した`msg.sender`だけを確認しました。結果に残すのは「呼び出し元上書き」かつ「署名なし」です。「大口保有者として署名した」「管理者アカウントを操作できた」とは書きません。 `broadcast`はスクリプトでトランザクションを組み立て、指定送信者の送信処理へつなぐための別機能です。フォーク上で`prank`が通ったことから、実際ネットワークで必要になる署名、ノンス、手数料、残高、メモリープール、ブロック組み込み、直前状態を省略できるわけではありません。 アクセス制御のテストでは、少なくとも次を対にします。 - 許可呼び出し元で成功する - 許可されていない呼び出し元では想定したエラーで失敗する - `prank`の適用範囲が一呼び出しか複数呼び出しかを明示する - `tx.origin`まで変える必要が本当にあるか確認する - 署名検証が要件なら、`prank`ではなく署名そのものをテストする ## `deal`・`store`・`etch`はチェーン状態を作り替える チートコードは準備を短くしますが、変更後の状態はプロバイダーから取得した事実ではありません。 ### `deal`は送金ではない `vm.deal(account, amount)`はネイティブ残高を直接設定します。今回の`0x…bEEF`は0 weiから5 ETH相当へ変わりましたが、送金トランザクション、送信者、トランザクションレシートは存在しません。 ERC-20向けのForge Std `deal(token, account, amount)`は別の補助関数で、ストレージスロットを操作します。非標準配置、残高変動、残高フックを持つトークンでは、実際の発行・送金と同じ副作用にならない場合があります。トークンの会計を確認するなら、`deal`後の残高だけでなく合計供給量、フック、イベント、後段会計も分けます。 ### ストアはストレージ配置が前提 `vm.store(account, slot, value)`は指定スロットへ値を直接書きます。今回のスロット`0x0`は`41`から`777`へ変わりました。対応表、動的配列、詰め込み済み項目、プロキシストレージ、名前空間付きストレージはスロット計算が異なるため、ソースとコンパイラー設定を確認せず推測で書きません。 `vm.load`で変更前と変更後を読み、スロットの意味、値の符号化、変更理由を記録へ残します。更新検証では、別項目まで壊していないか複数スロットを比較します。 ### `etch`は実行時コードだけを置く `vm.etch(target, code)`はアドレスの実行時バイトコードを直接設定します。今回の`0x…cAFE`はコードなしから、目印の値`909`を返す実行時コードへ変わりました。デプロイトランザクションはなく、コンストラクターも実行されません。 したがってコンストラクターで設定する所有者、不変値、ストレージ、イベント、ファクトリーの記録は自動では再現されません。初期化関数または明示的なスロット設定が必要なら、その変更も別々に記録します。独自プリコンパイルの模擬にも使えますが、チェーン固有プリコンパイルのガス・状態遷移・システムコントラクトの挙動を完全に再現する保証はありません。 ## `warp`・`roll`・`rollFork`で「進んだ」の意味を混ぜない `vm.warp(timestamp)`はテスト環境の`block.timestamp`を、`vm.roll(blockNumber)`は`block.number`を設定します。今回の固定フォークではタイムスタンプを`1788200002`から`1788203602`へ、ブロック番号を`2`から`14`へ変えました。 この操作でプロバイダー側に12ブロックが生成されたわけではありません。各ブロックのハッシュ、トランザクション、基準手数料、乱数性、L1/L2データ、オラクル観測が自動的に埋まるわけでもありません。 `vm.rollFork`は有効フォークまたは指定フォークを別ブロックへ進める機能で、ブロック番号を受け取る形とトランザクションハッシュまで進めて手前のトランザクションを再利用する形があります。単に環境変数を変える`roll`とは分けて使います。 時刻依存テストでは、次を個別に扱います。 - 有効期限・権利確定・待機時間はタイムスタンプ境界の直前、同値、直後をテストする - TWAPは時間だけでなく観測更新と流動性条件を確認する - オラクルはラウンドタイムスタンプ、鮮度、回答範囲、小数桁を確認する - L2はシーケンサーの稼働状況、L1データ、システムコントラクト、プリコンパイルを確認する - `blockhash`依存は取得可能範囲と実際のヘッダー連続性を確認する オラクルの安全境界は[価格フィードの検証記事](/archives/6042)にまとめています。`warp`して価格が変わらない環境を、本番の将来価格として扱ってはいけません。 ## 複数フォークは独立状態として扱う Foundryは複数フォークを作り、フォークIDで切り替えられます。今回、主系の固定フォークでスロットを`777`へ変えた後に副系の固定フォークへ切り替えると値は`91`で、主系へ戻すと`777`が残りました。変更はそのフォークにだけ保存されています。 公式参照では、フォークごとにストレージは独立し、フォーク切替時に置き換わります。初期状態ではテストコントラクトと呼び出し元がフォーク間で永続です。ほかのアカウントを`vm.makePersistent`で共有すると、別チェーン由来の状態へローカルコントラクト状態が持ち越されます。 チェーン間テストで永続オブジェクトが便利な場合もありますが、次を記録へ書きます。 - 各フォークIDに対応するチェーン・接続先・ブロック番号・ハッシュ - フォークごとに変更したアカウント・スロット・コード - 永続にしたアドレスと理由 - 切り替え前後の期待状態 - ブリッジメッセージや証明を模擬したか、実際のソースデータを使ったか 「メインネットフォークからL2フォークへ切り替わった」だけでは、ブリッジの確定性やメッセージリレーまで再現したことにはなりません。 ## フォークテスト・`eth_call`・シミュレーション・トランザクションの境界 同じ呼び出しデータでも、実行方法で残るものが違います。 | 実行方法 | 状態を変更するか | トランザクションレシート | 署名・送信 | 主に確認できること | | --- | --- | --- | --- | --- | | `eth_call` | プロバイダー状態へ保存しない | なし | なし | 指定ブロックと呼び出し文脈での戻り値または`revert` | | クライアント固有シミュレーション | 通常は保存しない | 実装依存 | 通常は送信なし | 実行履歴、複数呼び出し、状態上書きを含む仮想実行 | | フォーク上のローカルトランザクション | 有効フォーク内へ保存 | ローカルレシート | ローカルの鍵または呼び出し文脈 | 複数呼び出し後の状態、イベント、ガスの比較 | | 公開トランザクション | 正規チェーンへ採用されれば保存 | 組み込み後に取得 | 有効署名と送信が必要 | 実ネットワークで採用された結果 | 今回、値を`99`へ書く呼び出しデータを`eth_call`で実行すると戻り値は得られましたが、状態は`42`のままで、トランザクションレシートもありませんでした。同じ呼び出しをローカルAnvilトランザクションとして実行すると、ブロック`4`で成功レシートが作られ、状態は`99`へ変わりました。 それでもローカルレシートは公開トランザクションの証拠ではありません。実際のネットワークではノンス、手数料、残高、署名、メモリープール方針、アクセスリスト、基準手数料、直前の競合トランザクション、ブロック生成者の順序が加わります。フォークテストの成功は「固定した開始状態とローカル仮定の下で期待どおり動いた」という範囲に限定します。 状態上書きを受け付けるシミュレーションAPIも便利ですが、方法、項目、複数ブロックの扱いはクライアントやプロバイダーにより異なります。要求ペイロード、接続先識別情報、ブロック識別情報、上書き内容、応答を保存し、通常のEthereum JSON-RPCと同じ仕様だと決めつけません。 ## 秘密情報を残さない実行確認項目 フォークテストに書き込み権限のあるRPCキーやウォレット秘密情報は不要です。読み取り専用接続先を使い、失敗ログや画面記録へ認証情報を残さない設計にします。 - RPC URLは環境変数または秘密情報ストアから読み、記録には別名だけを保存する - コマンド行へトークン付きURLを直接書かない - エラーオブジェクト、要求ヘッダー、プロセス環境を丸ごと出力しない - ブラウザーウォレット、シードフレーズ、秘密鍵、署名済みトランザクションの生データを使わない - 公開トランザクション送信方法をテストプロセスから分離する - 接続先の利用制限、履歴範囲、地域、取得日時を記録する - ブロック番号とハッシュ、対象コードハッシュ、主要スロットを実行前に照合する - 変更操作ごとに変更前、変更後、出所、戻し方を記録する - 正確なFoundryバージョンとコミット、solcバージョン、EVM対象を固定する - 成功だけでなく履歴不足、プロバイダーのハッシュ差、許可されていない呼び出し元、古いオラクルもテストする ## 最小のレビュー手順 1. ローカルコントラクトだけで確認できる処理を先に分離する 2. 読み取り専用接続先と対象ブロックを選び、番号とハッシュを保存する 3. コードハッシュ・主要スロット・残高を取得し、開始状態が想定どおりか確認する 4. `createFork`または`createSelectFork`の返すフォークIDを記録する 5. `prank`、`deal`、`store`、`etch`、`warp`、`roll`を一つずつ適用し、変更前と変更後を残す 6. 複数フォークなら切り替えごとの有効フォークと状態を確認する 7. `eth_call`、ローカルトランザクション、公開トランザクションで残る証拠を分ける 8. プロバイダー差、履歴不足、`latest`のずれ、オラクル、時刻、L2の境界を失敗例に入れる 9. 秘密情報、署名済みペイロード、個人データが出力へ出ていないことを確認する フォークテストの価値は、メインネットらしく見える大きな環境を作ることではありません。どの状態をどこから読み、どこをローカルで変え、何を確認し、何をまだ証明していないかを説明できることです。その境界が記録に残っていれば、成功結果だけでなく、プロバイダー変更や将来の再実行で起きた差も調べられます。 フォークへ接続する前のソースレビューは、[Slither・Aderyn・Mythrilの同一プロジェクト比較](/archives/6052)で正解データと検出結果を対応させます。静的合格とフォーク組み込みは別の未検出境界を持つため、一方の成功をもう一方の代用にしません。 本記事は開発・検証方法の解説であり、特定プロトコル、資産、RPCプロバイダーの安全性、トランザクション成功、監査完了を保証するものではありません。 ## 確認した一次情報 - [Foundry Fork Testing guide](): 確認日 2026-09-01 - [Foundry createSelectFork reference](): 確認日 2026-09-01 - [Foundry selectFork reference](): 確認日 2026-09-01 - [Foundry makePersistent reference](): 確認日 2026-09-01 - [Foundry prank reference](): 確認日 2026-09-01 - [Foundry deal reference](): 確認日 2026-09-01 - [Foundry store reference](): 確認日 2026-09-01 - [Foundry etch reference](): 確認日 2026-09-01 - [Foundry rollFork reference](): 確認日 2026-09-01 - [Ethereum JSON-RPC API](): 確認日 2026-09-01 - [Geth archive mode](): 確認日 2026-09-01 - [Foundry v1.8.0](): 確認日 2026-09-01 --- # Solidity静的解析ツール比較｜Slither・Aderyn・Mythrilを同じ脆弱コントラクトで検証 Slither 0.11.6、Aderyn 0.6.8、Mythril 0.24.8を同じSolidity 0.8.36プロジェクトで実行し、13例の検出、誤警告、未検出、重複、速度、SARIF、抑制方法を比較します。 正規URL: https://3mikan.com/archives/6052 著者: みかん 公開: 2026-08-31T20:30:00.000Z 更新: 2026-09-02T05:35:00.000Z Solidityの静的解析ツールは、同じソースを渡しても同じ検出結果を返しません。構造とデータの流れを広く調べるツール、AST規則を高速に適用するツール、バイトコードの実行経路を記号実行で探索するツールでは、見える範囲と費用が違うからです。 この記事ではSlither `0.11.6`、Aderyn `0.6.8`、Mythril `0.24.8`を、Solidity `0.8.36`、最適化の想定実行回数200、Prague対象へ固定した同じ小規模プロジェクトで比較しました。13件の正解例と安全な対照例1件を先に定義し、ツール名や深刻度表示を見てから正解を変えない方法を採っています。 結論を先に置くと、今回の例単位検出はSlitherが9/13、Aderynが10/13、Mythrilが4/13でした。しかし、この数字だけでツールを順位付けできません。Mythrilは15コントラクトを個別に記号実行し、トランザクション数2、各20秒の上限を設けています。 SlitherとAderynはプロジェクト全体を一度に走査しました。解析方式、タイムアウト、規則設定が違うため、網羅率と実行時を必ず設定と一緒に読みます。 ## 比較の正解を先に固定する 検証用プロジェクトには次の13ケースを入れました。検出件数を増やすために同じ不具合を細かく分割せず、レビューで一つの原因として扱う単位を一つの例にしています。 1. 基本型再入 2. 関数横断再入 3. 所有者を書き換えられる欠落アクセス制御 4. `tx.origin`による認可 5. 検査されていない低水準呼び出し 6. 利用者が制御できる`delegatecall` 7. 未保護初期化関数 8. プロキシと実装の保存領域の衝突 9. タイムスタンプと`prevrandao`を使う弱い乱数性 10. コントラクト残高の厳密な等価比較 11. 組み込み名とローカル変数のシャドーイング、未使用状態、到達不能な非公開コード 12. ライブラリー内に隠れた未検査の呼び出し 13. `PUSH0`を含み得る対象EVM互換性 安全な対照例には、状態を先に減らしてから外部呼び出しを行うChecks-Effects-Interactions（CEI）と、戻り値を検査する低水準呼び出しを置きました。ツールが単に「外部呼び出しがある」と棚卸ししただけなら、すぐ誤警告とはしません。一方、安全な対照例を脆弱性として高・中・低深刻度で報告した場合は誤検出に分類します。 TPはソース範囲と検出器の種類が正解例の原因に一致した例です。一般的な外部呼び出しの注意だけで関数横断再入を検出したことにはしません。FNは該当例にTPが一つもない状態、重複は同じ例を複数の検出結果として数えた状態です。 深刻度はツール表示と編集側仮説を別々に保存しました。
3MIKANのキャラクターがスマートコントラクトソースを構造解析、記号実行パス、検出結果分類、人手トリアージ、自動検証の順に案内し、確定した検出結果、重複、誤検出を分ける概念図
画像は解析からトリアージまでの補助表現です。正確な例、検出器、分類、実行時間、ハッシュは本文と公開JSONを基準にしてください。
## 13ケースの検出結果 | 正解例 | Slither | Aderyn | Mythril | | --- | --- | --- | --- | | 基本型再入 | 検出 | 検出 | 検出 | | 関数横断再入 | 検出 | 検出 | 未検出 | | 欠落アクセス制御 | 未検出 | 未検出 | 未検出 | | `tx.origin`認可 | 検出 | 検出 | 検出 | | 検査されていない低水準呼び出し | 検出 | 検出 | 検出 | | 利用者が制御できる`delegatecall` | 検出 | 検出 | 検出 | | 未保護初期化関数 | 未検出 | 検出 | 未検出 | | プロキシ保存領域の衝突 | 未検出 | 未検出 | 未検出 | | 弱いチェーン上乱数性 | 検出 | 検出 | 未検出 | | コントラクト残高の一致 | 検出 | 検出 | 未検出 | | シャドーイング・未使用・到達不能コード | 検出 | 検出 | 未検出 | | ライブラリー内の未検査呼び出し | 検出 | 検出 | 未検出 | | `PUSH0`互換性 | 未検出 | 未検出 | 未検出 | 全ツールが見逃したのは、誰でも所有者を書き換えられる処理、プロキシと実装のスロット0衝突、対象EVM互換性です。所有者更新は「状態変更がある」「ゼロアドレス検査がない」という周辺検出結果が出ても、認可不在を指摘していないためTPにはしませんでした。 ストレージ衝突ではMythrilがプロキシのアセンブリ内にある`delegatecall`を、利用者指定の呼び出し先と報告しました。しかし、今回の原因は呼び出し元が対象を直接選べることではなく、実装のスロット0への書き込みがプロキシの実装スロットを上書きする配置不一致です。原因が一致しないため、検出ではなく誤分類の検出結果として残しています。 `PUSH0`は対応済みEVMでは正常な命令コードです。古い対象へデプロイするときだけ互換性リスクになります。この例を全ツールが報告しなかった結果は、コンパイラー・対象EVMの照合を別工程に残す必要性を示します。 [最適化・viaIR・EVMバージョンの比較](/archives/6050)と同じく、ソース解析器へビルド設定の全責任を移せません。 ## TP・FP・FN・重複を分けた集計 | ツール | TP例 | FN例 | FP検出結果 | 重複した検出結果 | 例の網羅率 | | --- | ---: | ---: | ---: | ---: | ---: | | Slither 0.11.6 | 9 | 4 | 0 | 4 | 69.2% | | Aderyn 0.6.8 | 10 | 3 | 2 | 4 | 76.9% | | Mythril 0.24.8 | 4 | 9 | 1 | 1 | 30.8% | Aderynの誤検出2件は、安全な対照例のCEIと戻り値検査済み呼び出しを`ETH transferred without address checks`として高深刻度で報告したものです。Mythrilの1件は、安全な対照用保管庫の外部呼び出しを低深刻度の再入として報告しました。Slitherも安全な対照例の低水準呼び出しを参考情報に棚卸ししましたが、脆弱性主張ではないためFPへ数えていません。 ツールが出した全検出結果はSlither 30件、Aderyn 37件、Mythril 10件でした。これを原因ごとのTP例へまとめると9件、10件、4件になります。「検出結果が多いツールほど多くの不具合を見つけた」とは言えません。 一般的な低水準呼び出し、イベント不足、ゼロアドレス検査、最適化注意はレビューには役立ちますが、今回の13原因とは別に扱いました。
3台の解析器が12個のコントラクト標本へ異なる範囲の光を当て、重複検出、未検出、安全な標本への誤警告を3MIKANのキャラクターが正解例と照合する概念図
解析器の重なりは網羅率の違いを表す概念図です。画像内の個数は実測値ではなく、実測の13ケースは表と公開JSONに固定しています。
## Slitherはプロジェクト全体の構造とデータの流れを広く拾った Slitherは今回、二つの再入、弱い乱数性、利用者が制御できる`delegatecall`、未検査の呼び出し、厳密な等価比較、シャドーイング、到達不能コード、ライブラリー内呼び出しを検出しました。プロジェクト全体のコントラクトと関係を短時間で見渡す、最初のレビュー待ち行列として使いやすい結果です。 一方、未保護初期化関数、ストレージ衝突、欠落アクセス制御、対象EVM互換性はTPになりませんでした。検出器を増やすだけでなく、プロキシ配置の検査、コンパイラー記録、権限テストを別に組み合わせます。 抑制には検出器単位のインライン指定、パスや深刻度による絞り込み、トリアージ用のデータベースがあります。今回の比較設定は検出結果があっても終了コードを0とし、別の基準設定では低深刻度と参考情報を除外して、高深刻度だけを失敗条件にできます。抑制行には「なぜ安全か」と期限を残し、ソース変更後に無期限で隠れないようレビューします。 ## Aderynは高速な規則走査で初期化関数まで届いた Aderynは三つのツールのうち唯一、未保護の初期化関数を正解例と一致させました。13件中10件を検出し、2回目の実行は約0.21秒でした。Foundryプロジェクトを認識し、JSON、SARIF、Markdownを直接出せるため、開発者へのフィードバックと自動集約を同じ設定へ寄せやすい構成です。 ただし、安全な対照例二つへの高深刻度警告がありました。外部呼び出しの宛先だけを調べ、状態を先に更新していることや戻り値の検査を十分に反映しない規則には、人によるトリアージが必要です。検出器の有効・無効指定やソースパスの絞り込みは使えますが、誤検出を生む規則を一括で除外すると、別の正しい検出結果も消える可能性があります。 ## Mythrilは記号実行パスを深掘りする代わりに境界を強く受けた Mythrilは基本型の再入、`tx.origin`、検査されていない低水準呼び出しの戻り値、利用者が制御できる`delegatecall`の4件を検出しました。基本型の再入では、外部呼び出し後に状態を書き換える具体的なトランザクション列を返します。ソースコード上の規則とは異なる証拠を付けられる点が特徴です。 今回の関数横断例では「利用者指定のアドレスへの呼び出し」という補助的な指摘は出ました。しかし、外部呼び出し後の状態更新や別の入口からの再入経路を示さなかったため、未検出（FN）に分類しました。弱い乱数性も、値を返すだけで処理の流れを変えない設計では、指定した解析モジュールの検出対象になりませんでした。 記号実行はパス、トランザクション件数、ソルバー、タイムアウトの影響を強く受けます。今回は15入口コントラクトを個別に、トランザクション数2、各20秒上限で実行しました。別の深さやモジュールなら結果は変わり得ます。 4/13はMythril全体の能力値ではなく、この固定条件の観測です。 ## 実行時は同じ仕事量として読まない Apple M4 Max、16論理CPU、128 GiB RAM、Docker 28.5.1の同じ実行環境で経過時間を計測しました。コンテナー内の最大RSSを同じ条件で取得できなかったため、メモリー使用量の順位付けは行っていません。 | ツール | 初回 | 2回目 | 実行単位 | | --- | ---: | ---: | --- | | Slither | 2.277秒 | 2.295秒 | プロジェクト全体1回 | | Aderyn | 0.501秒 | 0.209秒 | プロジェクト全体1回 | | Mythril | 165.492秒 | 165.380秒 | 15入口コントラクトの合計 | Slitherのウォームがコールドより約18ms長い差は測定誤差範囲で、優劣には使いません。Aderynは最初のコンパイラー準備後に短縮しました。Mythrilは各コントラクトのソルバー探索が支配的で、キャッシュだけでは大きく短縮しませんでした。 プロジェクト全体を一回走査するツールと、入口コントラクトごとに範囲を限定して記号実行するツールの秒数は、単純には比較できません。自動検証では短時間の静的解析を常時実行し、重い記号実行は変更範囲、夜間実行、公開前などに分ける設計が現実的です。 ## JSON・SARIF・テキストと終了コードを選ぶ | ツール | JSON | SARIF | 人が読める形式 | 今回、検出結果がある場合の終了コード | | --- | --- | --- | --- | ---: | | Slither | 対応 | 対応 | テキスト、Markdown | 0（方針で変更可能） | | Aderyn | 対応 | 対応 | Markdown | 0 | | Mythril | JSON、JSONv2 | 非対応 | テキスト、Markdown | 1 | SARIFは複数ツールの指摘位置と規則を共通の閲覧ツールへ集約する形式ですが、深刻度名、指紋、抑制の意味まで統一するものではありません。アップロード前にツール、バージョン、設定ハッシュを結果へ添え、同じ指摘の再出現と新しい指摘を区別します。 Aderynは検出結果があっても終了0だったため、報告書件数を読むラッパーが必要です。Mythrilは検出結果のあるコントラクトで1、ないコントラクトで0でした。Slitherは設定した`fail_on`で変わります。 終了コードの違いを無視して三つへ一律の判定を当てると、問題を見つけたのに成功扱いになる、正常終了したのに失敗扱いになる、といった逆転が起きます。 ## 抑制とベースラインを安全に運用する 抑制は「ツールが間違っているから消す」操作ではなく、正解データとレビュー責任を記録する操作です。最低限、次を一組にします。 - ツールバージョンと検出器ID - ソース範囲または安定した指紋 - TP、FP、重複、受容したリスク、対象外の分類 - 判断理由とレビュー担当者 - 追加テストまたは別ツールで補う境界 - ソース・コンパイラー・ツール更新後の再確認日 ベースラインは既存の指摘を記録し、新しい差分だけを失敗条件にできます。ただし、ソース移動で指紋が変わる、検出器の改良でIDや位置が変わる、コンパイラー更新でASTが変わる場合があります。件数だけを比較せず、消えた指摘と新しい指摘を正解例へ対応させ直します。 [Foundry不変条件テストの設計](/archives/6022)は連続した操作でしか破れない性質を補い、[再入6分類の実行履歴比較](/archives/6048)は外部呼び出しへの注意から実際の状態差へ進む方法を示します。[Foundry・Echidna・Medusaの状態保持型ファジング比較](/archives/6053)では、同じ性質、安全な対照例、2〜5回の呼び出しで表面化する意図的な不具合を三ツールへ接続しています。 ## 導入時の選択確認項目 - [ ] ソースだけでなくコンパイラー、対象EVM、開発基盤設定を固定した - [ ] ツールバージョン、実行ファイルまたは画像ダイジェスト、設定ハッシュを保存した - [ ] プロジェクト固有の正解データと安全対照を先に作った - [ ] ツールが出した全検出結果数とTP例数を分けた - [ ] FP、FN、重複、補助的な指摘、対象外を区別した - [ ] ツール深刻度と製品側リスク評価を別項目にした - [ ] JSON、SARIF、テキストの位置と指紋を確認した - [ ] 検出結果がある場合とない場合の終了コードを実測した - [ ] 抑制へ理由、所有者、再確認日を付けた - [ ] ベースライン更新で新しい検出結果をまとめて隠していない - [ ] 短時間の静的解析と、範囲を限定した記号実行の頻度を分けた - [ ] アクセス制御、プロキシ配置、コンパイラー互換性を別テストで補った - [ ] 解析器合格を監査完了や安全保証として表示していない 今回の[公開検証JSON](/fixtures/solidity-static-analysis-6052.json)には、13件の検証例、ツール別のTP、FP、FN、重複、全指摘の分類、初回と2回目の実行時間、終了コード、実行条件、ソースハッシュ、各ツールが出したレポートのハッシュ、抑制方針を保存しました。各ツールは無料のオープンソース版だけを使い、有料プラン、スポンサー提供、アフィリエイト、クラウド解析はありません。 静的解析ツールは、レビュー待ちの指摘を素早く整理し、見落としやすいパターンを継続的に示すための道具です。完成条件は「三つとも成功」ではありません。どの正解例をどのツールが検出し、どこを別のテストと人によるレビューが引き受けるか説明できる状態です。 ## 確認した一次情報 - [Slither package metadata](): 確認日 2026-09-01 - [Slither Action and triage documentation](): 確認日 2026-09-01 - [Aderyn 0.6.8 release](): 確認日 2026-09-01 - [Aderyn official repository](): 確認日 2026-09-01 - [Mythril 0.24.8 release](): 確認日 2026-09-01 - [Mythril official repository](): 確認日 2026-09-01 - [Solidity 0.8.36 release](): 確認日 2026-09-01 - [GitHub SARIF upload documentation](): 確認日 2026-09-01 - [Foundry v1.8.0](): 確認日 2026-09-01 --- # Solidityの状態保持型ファジング比較｜Foundry・Echidna・Medusaを同じ性質で検証 Foundry 1.8.0、Echidna 2.3.3、Medusa 1.5.1に同じ7種類の意図的な不具合と安全な対照例を渡し、再現率、反例、乱数の種、入力集、網羅率、自動検証の設計を比較します。 正規URL: https://3mikan.com/archives/6053 著者: みかん 公開: 2026-09-01T15:30:00.000Z 更新: 2026-09-02T05:35:00.000Z 状態保持型ファジングは、入力値だけでなく**操作の順序と途中状態**を探索します。1回の入金では保たれる会計が、寄付後の少額入金で崩れる。権限付与と実行は正常でも、次の操作まで権限のキャッシュが残る。 こうした不具合は、単一呼び出しのユニットテストや状態を持たないファジングだけでは届きにくい領域です。 この記事ではFoundry `1.8.0`、Echidna `2.3.3`、Medusa `1.5.1`へ、同じ8個のコントラクト、同じ`property_`関数、同じ操作範囲を渡しました。7種類の意図的な不具合と安全な対照例1件を先に定義し、各例を3回ずつ、合計72回のキャンペーンを実行しています。 結果は三つのツールとも7種類の不具合を3回中3回再現し、安全な対照例は3回とも合格しました。ツールエラーとタイムアウトもありませんでした。しかし、これは「三つのツールが同点で、安全性も同じ」という意味ではありません。 今回の不具合は、最短2〜5回の呼び出しで到達できる小規模な検証例です。検出件数では差がつかなかったため、性質の書き方、探索設定、シード、反例の縮約、入力集、網羅率、出力検証の違いを比較します。 **テストの価値は本数ではなく、どの失敗を検出でき、無効な実行を失敗として止め、再現に必要な証拠を残せるかで判断します。** ## 同じ性質へ三種類の探索方法を接続する 各対象コントラクトは、壊れたときだけ`false`になる`property_`関数を持ちます。EchidnaとMedusaはその関数を性質モードで直接探索します。Foundryでは同じ関数を不変条件テストコントラクトから呼び、`false`ならテストを失敗させます。 | ツール | 性質の入口 | 今回の対象指定 | 失敗時の主な証拠 | | --- | --- | --- | --- | | Foundry 1.8.0 | `invariant_`テストから共通の`property_`を確認 | 不変条件テストコントラクトごとに対象を分離 | 呼び出し列、実行履歴、試行・呼び出し・`revert`の回数、ファジングシード | | Echidna 2.3.3 | `property_`を性質モードで実行 | 例ごとのコントラクトと設定 | 縮約した呼び出し列、網羅率を広げた入力集、固有命令数、指定シード | | Medusa 1.5.1 | `property_`を性質テストで実行 | 例ごとの対象とJSON設定 | 縮約した呼び出し列、呼び出し順の入力集、分岐網羅率、実行履歴 | [Foundry不変条件テストのハンドラー・実行主体・補助変数設計](/archives/6022)を先に読むと、性質の観測値と探索操作を分ける理由が分かります。本比較ではツールごとの記法を無理に統一せず、**同じ原因と同じ性質を見ていること**を揃えました。 ## 7不具合と安全対照を実行前に固定する 検出結果を見てから正解を作ると、ツールが出した呼び出し列へ都合よく正解例を寄せられます。そこで、原因、期待する失敗、意味のある最短の呼び出し列を先に固定しました。 | 検証例 | 分類 | 正解例の最短手順 | 原因 | | --- | --- | --- | --- | | 待ち行列取り消し | 会計 | `queue → cancel` | 取り消し時に待ち行列に登録済み債務だけ減らない | | エポック二重受取 | 状態遷移 | `advance → claim → claim` | 奇数エポックで受取確認地点を更新しない | | 認可再利用 | アクセス制御 | `stage → authorize → execute → stage → execute` | 実行後も認可が残る | | 保管庫ゼロ持分 | 丸め | `donate → deposit` | 持分価格上昇後の小額入金を0持分で受理する | | 取り消し済み役割キャッシュ | アクセス制御 | `grant → revoke → privilegedAction` | 取り消し時に認可キャッシュを消さない | | コールバック再入 | 再入 | `armCallback → withdraw` | 外部コールバックより後に残高を消費する | | 遅延型二重実行 | 時刻依存の状態 | `schedule → tick → tick → execute → execute` | 実行後も予定登録を解除しない | | 安全な待ち行列制御 | 対照例 | 失敗なし | 取り消し時に残高、待ち行列への登録量、債務を同期する | 安全な対照例は「何も見つけなかった」だけではありません。三つのツールが性質を正しく合格させ、終了状態も成功し、コンパイラーエラーや未知の出力になっていないことまで確認します。対照例がコンパイルされずに終了しても、不具合の未検出と数えてはいけません。 コールバック例の意味は[再入を6分類して状態差を追う記事](/archives/6048)で詳しく整理しています。ここでは外部呼び出しの有無ではなく、コールバック中に同じ残高を再利用でき、最終出金が残高を超えることを性質にしました。 ## 上限を対応づけても仕事量は完全には同じにならない 共通条件はSolidity `0.8.36`、対象EVMがPrague、オプティマイザーの`runs`が200、呼び出し列の上限が32、ワーカーが1、キャンペーンごとのタイムアウトが45秒、縮約上限が5,000回です。EchidnaとMedusaのコンパイル前解析にはSlither `0.11.6`を有効にしました。 | 設定 | Foundry | Echidna | Medusa | | --- | --- | --- | --- | | 探索上限 | `runs: 625` × `depth: 32` | `testLimit: 20000` | `testLimit: 20000` | | 呼び出し列の上限 | `depth: 32` | `seqLen: 32` | `callSequenceLength: 32` | | 並列数 | 1スレッド | 1ワーカー | 1ワーカー | | `revert`の方針 | `fail_on_revert: false` | 性質モードの通常探索 | 性質テストの通常探索 | | 縮約上限 | 5,000 | 5,000 | 5,000 | | ソース解析 | Forgeでコンパイル | Slither 0.11.6 | Slither 0.11.6 | | キャンペーン間のキャッシュ | 毎回削除 | 毎回削除 | 毎回削除 | Foundryの625 × 32は20,000回の呼び出しの**上限**です。EchidnaとMedusaの`testLimit`と、内部の入力生成や網羅率処理を同じ仕事量に変換する式ではありません。設定名が似ていても、性質が失敗するまでの呼び出し、初期化、コンパイル、網羅率からのフィードバックはツールごとに異なります。 キャンペーンごとにコンパイルキャッシュ、生成設定、網羅率出力を消し、前のツールが作ったSolidityの再現用入力や入力集を次のツールへ読ませないよう分離しました。経過時間にはコンパイルとSlither解析も含めます。キャッシュが温まった最速値だけを選んではいません。 ## シードは三つのツールで完全には一致していない 実行ラベルは`19501`、`19502`、`19503`の三つです。Foundryでは`FOUNDRY_FUZZ_SEED`、Echidnaでは設定項目の`seed`へ指定しました。 Medusa `1.5.1`について今回確認した公開設定とCLIヘルプでは、外部から乱数シードを固定する項目を確認できませんでした。そのため、Medusaの3回は独立したキャンペーンであり、この番号は記録上の実行ラベルにすぎません。「同じシードを三つのツールへ渡した」とは扱いません。 シードを固定しても、失敗を完全に再現できるとは限りません。ツールバージョン、コンパイラー、対象、初期状態、操作の集合、ワーカー数、呼び出し列の長さ、入力集を一緒に保存します。最終的な回帰テストには、シードではなく縮約後の具体的な呼び出し列を戻します。 ## 三つのツールとも7種類の不具合を再現した 次の表は「3回中の再現回数 / 3回で得た反例の最短呼び出し数」です。最短値は、すべての実行が同じ長さまで縮約されたことを意味しません。 | 検証例 | Foundry | Echidna | Medusa | | --- | ---: | ---: | ---: | | 待ち行列取り消し | 3/3・2呼び出し | 3/3・2呼び出し | 3/3・2呼び出し | | エポック二重受取 | 3/3・3呼び出し | 3/3・3呼び出し | 3/3・3呼び出し | | 認可再利用 | 3/3・5呼び出し | 3/3・5呼び出し | 3/3・5呼び出し | | 保管庫ゼロ持分 | 3/3・2呼び出し | 3/3・2呼び出し | 3/3・2呼び出し | | 取り消し済み役割キャッシュ | 3/3・3呼び出し | 3/3・3呼び出し | 3/3・3呼び出し | | コールバック再入 | 3/3・2呼び出し | 3/3・2呼び出し | 3/3・2呼び出し | | 遅延型二重実行 | 3/3・5呼び出し | 3/3・5呼び出し | 3/3・5呼び出し | | 安全待ち行列制御 | 3/3合格 | 3/3合格 | 3/3合格 | 72回すべてのキャンペーンについて、ツール固有の正確な失敗・合格の目印と、終了状態の組み合わせを確認しました。コンパイラーエラー、生成エラー、タイムアウト、認識できない出力は検出にも合格にもせず、`tool_error`として比較全体を止めます。すべて有効な実行で、ツールエラー、タイムアウト、安全な対照例での誤検出はいずれもありませんでした。 この検証例では結果が揃いました。差が出なかったことも重要です。2〜5回の呼び出しで到達でき、性質が直接原因を表す小さな例には、三つのツールとも十分に到達できました。 一方、実行主体の制約、低確率の入力、長い前提手順、`revert`の多いハンドラー、複数コントラクトにまたがる複雑なコールバックを加えれば、結果は変わり得ます。7/7という結果を製品全体の検出率へ外挿しません。 ## 実行時は順位ではなく実行設計に使う Ubuntu 24系、AMD EPYC 9V74、2論理CPU、約8.3 GB RAMの同じ環境で、各キャンペーンのコンパイルとソース解析を含む経過時間を測りました。 | ツール | 有効なキャンペーン | 全24回の中央値 | 安全な対照例3回の中央値 | | --- | ---: | ---: | ---: | | Foundry | 24/24 | 0.454秒 | 0.736秒 | | Echidna | 24/24 | 1.573秒 | 2.072秒 | | Medusa | 24/24 | 1.129秒 | 3.433秒 | 不具合のある例は失敗を見つけると早く止まり、安全な対照例は上限まで探索します。そのため全24回の中央値は、不具合の見つけやすさと例の構成に依存します。Foundryの0.454秒を、任意のプロジェクトでEchidnaより3倍速いという能力値にはしません。 今回の時間から判断できるのは、この検証例をこの設定で自動実行できたことまでです。大規模なプロジェクトでは、コンパイル対象の依存関係、Slither解析、ワーカー数、入力集の再利用、タイムアウト、実行環境のCPUが所要時間を左右します。変更ごと、夜間、公開前のどこで実行するかは、自分のプロジェクトで安全な対照例と既知の不具合を含む時間分布を測って決めます。 ## 網羅率の単位を共通割合へ変換しない 三つのツールは同じ単位の網羅率を出しません。 - Foundryのレポートでは試行、呼び出し、`revert`の回数を確認した - Echidnaでは入力集と固有命令数を保存した - Medusaでは呼び出し順の入力集と分岐網羅率を保存した 呼び出し回数、固有命令数、分岐数は相互に変換できません。分母、計測方法、初期化、`revert`の扱いが違うからです。網羅率は、同じツール、バージョン、検証例の中で「新しい状態へ進めているか」「ハンドラー変更後に急落していないか」を見る指標にします。 入力集の役割にも違いがあります。Echidnaは網羅率を広げた呼び出し列と再現用入力を残し、Medusaは呼び出し列、テスト結果、網羅率を残しました。今回のFoundry設定では、探索用入力集の永続化を比較対象にしていません。 三つを同じ「入力集の件数」へ丸めず、回帰テストへ戻す最小の呼び出し列と、再探索に使うツール固有の入力集を分けます。 ## 反例は原因の説明まで縮める 縮約後の呼び出し数が少ないだけでは、良い反例とは限りません。確認するのは次の四点です。 1. 正解例の原因を実際に踏んでいる 2. 不要な呼び出しと実行主体が除かれている 3. 初期状態、引数、送信者、時間進行を再現できる 4. 修正後の決定的回帰テストへ移せる たとえば認可再利用の5回の呼び出しは、最初の`execute`後に認可が残り、次の`stage`を再認証なしで実行できる因果を保ちます。最後に性質が失敗したという事実だけを保存すると、「なぜ二度目だけ成功したか」が分からなくなります。 再入も`withdraw`一行だけでは不十分です。コールバックを実行可能な状態へ移し、外部へ制御を渡している間も残高が未消費であることを実行履歴へ残します。[三つの静的解析ツールの比較](/archives/6052)で外部呼び出しへの注意と正解例を分けたのと同じく、ファザーでも「失敗した」と「原因を説明できる」を分けます。 ## Foundry・Echidna・Medusaの選び方 ### Foundryは既存Forgeテストと回帰へ接続しやすい [Foundry不変条件テスト](https://getfoundry.sh/forge/invariant-testing)は、Solidityテスト、チートコード、ハンドラー、対象を絞るセレクター、実行履歴を同じForgeプロジェクトへ置けます。既存の単体テストと共有し、縮約した呼び出し列をSolidityの回帰テストへ戻しやすい構成です。 一方、対象を絞らないとテストコントラクトや補助関数まで探索され、`revert`の多いハンドラーは有効な状態へ進みません。試行回数を増やす前に、実行主体、対象関数、入力範囲、補助状態、`revert`の方針を確認します。 ### Echidnaは性質・入力集・網羅率を一組で残しやすい [Echidnaの設定](https://secure-contracts.com/program-analysis/echidna/configuration.html)は`testLimit`、`seqLen`、シード、ワーカー、縮約、入力集を明示できます。[網羅率を広げた入力集](https://secure-contracts.com/program-analysis/echidna/advanced/collecting-a-corpus.html)を調べ、届いていない関数や`revert`へ偏った呼び出し列を見直せます。 今回のような`property_`コントラクトは簡潔ですが、本番用コントラクトへテスト専用の性質を混ぜるか、検証専用のコントラクトを別に置くかを決める必要があります。Slitherによるコントラクト解析も含むため、コンパイラーとインポートの解決方法を固定します。 ### Medusaは並列ファジングと呼び出し順の証拠を設計できる [Medusaのテスト設定](https://secure-contracts.com/program-analysis/medusa/docs/src/project_configuration/testing_config.html)は性質テスト、呼び出し列、ワーカー、テスト上限、縮約をJSONで管理します。今回も[推奨されているSlither解析](https://secure-contracts.com/program-analysis/medusa/docs/src/project_configuration/slither_config.html)を有効にしました。 Medusaはワーカーを増やせますが、条件をそろえた1ワーカーの比較では並列実行を無効にしています。また、`1.5.1`では外部シードを固定できないため、厳密な再現が要件なら、保存した縮約済みの呼び出し列とツールバージョンを中心に使います。 ## 自動検証では終了コードだけで判定しない 性質の失敗はテストとしては非ゼロ終了でも、性能比較では「意図した不具合を検出した正常な観測」です。反対に、コンパイラーエラーによる非ゼロ終了は検出ではありません。安全な対照例の終了コードが0でも、性質が合格したことを示す目印がなければ成功扱いにしません。 自動判定は次の順にします。 1. ツール、バージョン、対象の性質、検証例IDを固定する 2. タイムアウト、生成失敗、コンパイラーエラーを先に除外する 3. ツール固有の正確な合格・失敗の目印を読む 4. 目印と終了状態が一致することを確認する 5. 意図的不具合は期待する失敗、安全対照は合格を要求する 6. ツールが出した元の結果、縮約した呼び出し列、入力集、設定、ハッシュを保存する 最初の試行では、あるツールが生成したSolidityの再現用入力を後続ツールのソースとして拾い、コンパイルエラーになったキャンペーンがありました。以前の判定は「残りの二つのツールが不具合を見つけた」ことで全体を通していました。キャンペーンごとにディレクトリーを分け、厳密な出力条件を設けて、**一つのツールでも無効な実行があれば比較全体を失敗**させてから再測定しています。 これはテスト数を増やす問題ではありません。必要だったのは、無効な結果を成功へ混ぜない、再利用可能な判定境界です。特定の検出件数や出力全文を固定するのではなく、コンパイラーエラーを検出へ分類しないこと、安全な対照例を必ず実行すること、未知のツール出力を見つけたら止めることを、小さな合成入力で検証します。 ## 導入確認項目 - [ ] 実行前に不具合の原因、性質、安全な対照例、最短の呼び出し列を定義した - [ ] 本番用コントラクトと検証用コントラクトの責任を分けた - [ ] 対象コントラクト、関数、実行主体、入力範囲を絞った - [ ] `revert`を失敗、破棄、許容のどれとして扱うか決めた - [ ] 試行回数、深さ、呼び出し列の長さ、ワーカー数、タイムアウトを保存した - [ ] コンパイラー、対象EVM、オプティマイザー、ツール、ソース解析のバージョンを固定した - [ ] シードを設定できるツールとできないツールを区別した - [ ] キャンペーンごとのキャッシュと入力集の境界を決めた - [ ] 正確な目印と終了状態の両方を検証した - [ ] コンパイラーエラー、タイムアウト、未知の出力を未検出へ混ぜていない - [ ] 安全対照が全実行で合格した - [ ] 反例を、原因が分かる決定的な回帰テストへ戻した - [ ] ツール固有の網羅率を共通の点数へ変換していない - [ ] キャンペーン数や実行速度を安全性の順位付けに使っていない - [ ] 未検出を不具合不在や監査完了として表示していない ## まとめ 今回の検証例では、Foundry、Echidna、Medusaの三つのツールすべてが7種類の不具合を各3回再現し、最短2〜5回の呼び出しで反例へ到達しました。安全な対照例もすべての実行で合格しました。この結果だけでは、検出件数によるツール選択はできません。 差が出るのは運用です。Forgeテストへ統合しやすいFoundry、シードや網羅率を広げる入力集を設定しやすいEchidna、JSON設定と呼び出し順の入力集を持つMedusaでは、性質の置き場所、再現方法、網羅率の読み方が違います。 一つを「最強」と決める前に、プロジェクト固有の正解例と安全な対照例を同じ性質へ通します。そして、有効な実行だけを比較し、縮約した呼び出し列を回帰テストへ戻します。多く回したことではなく、**何を探索し、何を見逃し、失敗をどう再現できるか説明できること**が状態保持型ファジングの完成条件です。 この記事にスポンサー、アフィリエイト、有料ツールの提供はありません。FoundryはMITまたはApache-2.0のデュアルライセンス、Echidna、Medusa、今回併用したSlitherはAGPL-3.0です。導入時は、利用するバージョンのライセンスと配布形態を自分のプロジェクトで確認してください。 ## 確認した一次情報 - [Foundry invariant testing documentation](): 確認日 2026-09-02 - [Foundry v1.8.0 release](): 確認日 2026-09-02 - [Foundry official repository and license](): 確認日 2026-09-02 - [Echidna configuration reference](): 確認日 2026-09-02 - [Echidna corpus and coverage documentation](): 確認日 2026-09-02 - [Echidna v2.3.3 release](): 確認日 2026-09-02 - [Echidna official repository and license](): 確認日 2026-09-02 - [Medusa testing configuration](): 確認日 2026-09-02 - [Medusa Slither configuration](): 確認日 2026-09-02 - [Medusa v1.5.1 release](): 確認日 2026-09-02 - [Medusa official repository and license](): 確認日 2026-09-02 - [Slither 0.11.6 release](): 確認日 2026-09-02 - [Solidity 0.8.36 release](): 確認日 2026-09-02 --- # L2のガス代はどう決まる？実行・L1データ・Blob・運用者手数料に分解 BaseとArbitrum Oneの公開トランザクションのレシートを使い、L2手数料を実行、L1データ・Blob投稿、運用者手数料に分けて再計算します。 正規URL: https://3mikan.com/archives/6054 著者: みかん 公開: 2026-08-31T23:30:00.000Z 更新: 2026-09-02T05:35:00.000Z L2のウォレットに表示される「ガス代」は一つの数字でも、内部では複数の費目が動いています。EVMを実行する費用、トランザクションデータをL1へ届ける費用、チェーン固有の運用者手数料は、同じ混雑指標でも同じ比率では増減しません。 そのため、`gasUsed × effectiveGasPrice`だけで全L2の総額を説明することはできません。Baseでは、この積へトランザクションレシートの`l1Fee`と運用者手数料を加えます。Arbitrum Oneでは、L1への投稿費用がL2ガスへ換算され、レシートの`gasUsed`に含まれます。 **L2手数料は、チェーンとバージョンを固定し、実行・データ可用性・運用者の費用を別々に再計算してから合計します。** この記事では2026年9月1日にBase MainnetとArbitrum Oneの公開RPCを読み取り専用で確認しました。同じ数分内の4件の完了済みトランザクションと、チェーンごとに固定した1,024ブロックを使います。ウォレット接続、署名、トランザクション送信、個人残高、APIキー、実資産操作は使っていません。 これは最安チェーンのランキングではなく、明細を追う方法の比較です。 ## 一つのL2手数料を三つの層へ分ける
L2トランザクションが実行、圧縮、呼び出しデータまたはBlobによるデータ可用性、運用者の境界を通り、一つの総額へ合流する概念図
呼び出しデータとBlobは、データ可用性を確保する方法の選択肢です。両方が常に利用者へ二重請求されるという意味ではありません。
| 費目 | 何に対する支払いか | 値を確認する場所 | | --- | --- | --- | | 実行 | EVM命令コード、メモリー、ストレージ、呼び出しなどL2上の実行 | レシートの`gasUsed`、`effectiveGasPrice`、チェーン固有の分解項目 | | L1データ・投稿 | トランザクションを圧縮し、一括処理として親チェーンへ投稿する費用の回収 | Baseの`l1Fee`、Arbitrumの`gasUsedForL1`、各チェーンのオラクルやプリコンパイル | | 運用者 | チェーン運用者が設定する追加費用 | OP Stackの`operatorFeeScalar`、`operatorFeeConstant`など | | 優先度・順序 | 組み込み順序に関係する優先度手数料やチェーン固有の仕組み | トランザクション、レシート、現在のシーケンサー仕様 | 実行とデータ可用性は独立した変数です。L2が空いていてもEthereum側のデータ価格が高い場合があり、逆にL2の実行価格が上がってもBlob側の価格が下がる場合があります。運用者手数料もチェーンごとの設定で決まり、OP Stackだから必ず同じ値になるわけではありません。 ## Baseは実行費用・`l1Fee`・運用者手数料を足す OP Stackの基本形は次のとおりです。`effectiveGasPrice`にはブロックの基準手数料と、実際に支払った優先度手数料が反映されます。 ```text executionFee = gasUsed × effectiveGasPrice totalFee = executionFee + l1Fee + operatorFee ``` Jovian導入後の運用者手数料は、対象チェーンの設定値を使って次のように計算します。 ```text operatorFee = gasUsed × operatorFeeScalar × 100 + operatorFeeConstant ``` 今回のBaseブロック`50,713,856`では、スカラーと定数がどちらも0だったため、2件とも運用者手数料は0です。「OP Stackに運用者手数料の仕組みがある」ことと、「このBaseトランザクションで追加額が発生した」ことは別の主張です。 ### 同じブロックの2件をレシートから再計算する | Base Mainnet | 呼び出しデータ | 使用ガス | 実行 | L1データ | 運用者 | 合計 | | --- | ---: | ---: | ---: | ---: | ---: | ---: | | [ネイティブ送金`0xbdc0…de61`](https://basescan.org/tx/0xbdc017ca8e5bd53df7d9541b182ca9853e82ed6dcdd8c5bab2bfd07a700ade61) | 0バイト | 21,000 | 126,000,000,000 wei | 487,492,768 wei | 0 wei | 126,487,492,768 wei | | [コントラクト呼び出し`0x2460…bf05`](https://basescan.org/tx/0x24609ff47cfd9c5ee325a86a172298a9cdba658dcd74c6415be89848a08fbf05) | 1,348バイト | 755,382 | 4,683,368,400,000 wei | 1,280,823,388 wei | 0 wei | 4,684,649,223,388 wei | 1件目は`21,000 × 6,000,000 + 487,492,768`、2件目は`755,382 × 6,200,000 + 1,280,823,388`でレシートの総額を再構成できます。結果はそれぞれ`0.000000126487492768 ETH`と`0.000004684649223388 ETH`です。 この2件では実行費用が大部分ですが、別の時刻、データ、スカラーでも同じ比率になるとは限りません。また、`l1GasUsed × l1GasPrice`をそのまま`l1Fee`とみなすこともできません。Fjordの圧縮推定、L1とBlobの基準手数料、それぞれのスカラーを含むチェーン側の計算結果を、レシートの`l1Fee`で確認します。 ### Baseの`blobGasUsed`は「利用者がL1 Blobガスを直接使った量」ではない 今回のレシートには`blobGasUsed`があり、0バイトの例で`14,800`、1,348バイトの例で`38,776`でした。しかしJovian仕様では、この項目はトランザクションの**データ可用性に関する使用量**を表すために再利用されています。ブロックヘッダー側でも、この使用量を上限判定と基準手数料の更新に使います。 したがって、Baseのレシートにある`blobGasUsed`を、Ethereum L1のタイプ3トランザクションにあるBlobガスと同一視しません。利用者のL2トランザクションが自分専用のBlobをL1へ直接投稿した証拠でもありません。一括投稿者が複数のトランザクションをまとめる境界や、Ethereum側のBlob供給変更は[PeerDASとBlob処理量の記事](/archives/6023)で分けて確認できます。 ## Arbitrum Oneは投稿者費用をL2ガスへ換算する Arbitrum Nitroでは、L1へデータを投稿する見積費用をL2ガス単位のバッファーへ変換します。完了後のレシートでは、今回確認したノードが`gasUsedForL1`を返しました。 ```text totalFee = gasUsed × effectiveGasPrice posterFee = gasUsedForL1 × effectiveGasPrice executionFee = (gasUsed - gasUsedForL1) × effectiveGasPrice ``` | Arbitrum One | 呼び出しデータ | 使用ガス | L1用ガス | 実行 | 投稿 | 合計 | | --- | ---: | ---: | ---: | ---: | ---: | ---: | | [短い呼び出し`0xb7bb…de5`](https://arbiscan.io/tx/0xb7bbde476fdf093fc600e4b39916e9795157913e2a54a78bdfd7232813283de5) | 4バイト | 1,470,652 | 85 | 29,411,340,000,000 wei | 1,700,000,000 wei | 29,413,040,000,000 wei | | [長い呼び出し`0x7951…636e`](https://arbiscan.io/tx/0x7951759d7fb4eec78894870ffe91bc7d53bd8d43d8e0c9cd16b4ebea643d636e) | 814バイト | 159,833 | 280 | 3,191,060,000,000 wei | 5,600,000,000 wei | 3,196,660,000,000 wei | どちらもブロック`500,440,832`、`effectiveGasPrice = 20,000,000 wei`です。投稿者部分を足し直すとレシートの合計と一致します。 ここで4バイトの呼び出しの方が814バイトの呼び出しより高額です。呼び出しデータが短くても、呼び出したコントラクトの処理が重ければ実行ガスは増えます。反対に、データが長くても実行パスが軽いことがあります。 この2件を「1バイトあたりのチェーン価格」や「Arbitrumの平均」として比較してはいけません。 ## データ量と基準手数料の大小を同じ表で見る 一時的な値を普遍化しないため、最小と最大は固定した1,024ブロックの観測範囲内だけで定義しました。 | チェーン | 観測窓 | 基準手数料の最小 | 基準手数料の最大 | | --- | --- | ---: | ---: | | Base | ブロック50,712,977〜50,714,000 | 5,000,000 wei | 5,030,833 wei | | Arbitrum One | ブロック500,440,468〜500,441,491 | 20,000,000 wei | 21,248,000 wei | これは長期の最小・最大、平均、通常値、将来の上限ではありません。数分の固定窓における観測値です。 ### Base：同じ実行ガスでデータ量だけを変える Baseの`GasPriceOracle.getL1FeeUpperBound`へ、200バイトと2,200バイトの未署名トランザクションを直列化したときのサイズを渡しました。呼び出しデータだけの長さではなく、トランザクション全体の形式を含む概算サイズです。実行ガスは比較のため50,000に固定しています。 | L2観測条件 | 直列化後のサイズ | 実行 | L1手数料の上限 | 合計の上限 | | --- | ---: | ---: | ---: | ---: | | 窓内基準手数料最小 | 200バイト | 250,000,000,000 wei | 1,363,923,801 wei | 251,363,923,801 wei | | 窓内基準手数料最小 | 2,200バイト | 250,000,000,000 wei | 13,057,659,001 wei | 263,057,659,001 wei | | 窓内基準手数料最大 | 200バイト | 251,541,650,000 wei | 889,502,027 wei | 252,431,152,027 wei | | 窓内基準手数料最大 | 2,200バイト | 251,541,650,000 wei | 8,515,735,364 wei | 260,057,385,364 wei | 観測窓の中では、L2基準手数料が高いブロックの方がL1手数料の上限は低くなりました。矛盾ではありません。L2の実行需要とEthereum由来のデータ価格は別の軸だからです。 「混雑が高い」という一語だけで総額の全構成要素が同方向に動くとは限りません。 ### Arbitrum：`NodeInterface`の構成要素を分ける 4バイトと2,048バイトの固定データをEOA宛ての呼び出しとして`NodeInterface.gasEstimateComponents`へ渡しました。表の価格はヘッダーの値ではなく、プリコンパイルが計算用に返した`baseFee`です。 | L2観測条件 | 入力 | 実行ガス | L1用の予備ガス | 実行 | 投稿 | 合計見積もり | | --- | ---: | ---: | ---: | ---: | ---: | ---: | | 窓内のヘッダー基準手数料が最小 | 4バイト | 21,230 | 117 | 424,812,300,000 wei | 2,341,170,000 wei | 427,153,470,000 wei | | 窓内のヘッダー基準手数料が最小 | 2,048バイト | 54,535 | 1,767 | 1,091,245,350,000 wei | 35,357,670,000 wei | 1,126,603,020,000 wei | | 窓内のヘッダー基準手数料が最大 | 4バイト | 21,230 | 159 | 424,684,920,000 wei | 3,180,636,000 wei | 427,865,556,000 wei | | 窓内のヘッダー基準手数料が最大 | 2,048バイト | 54,538 | 2,391 | 1,090,978,152,000 wei | 47,829,564,000 wei | 1,138,807,716,000 wei | データ量が多い例では、投稿費用に備えるガスが増えました。ただし圧縮率はバイト数だけでは決まらず、同じ長さでもデータの並び方で変わります。また、組み込み前の見積もりを後のレシートへ流用せず、組み込み後は実際の`gasUsed`と`gasUsedForL1`を使います。 ## ウォレット見積もり・RPC見積もり・レシートがずれる理由
トランザクション組み込み前の可変見積もり、実行とデータ投稿の独立した条件、採用後に固定されるレシート構成要素を3MIKANのキャラクターが照合する概念図
見積もりは将来のレシートではありません。方法、ブロックタグ、状態、手数料引数、安全余裕を保存して比較します。
`eth_estimateGas`は「この呼び出しに必要なガス単位」の見積もりであり、全チェーン共通の最終手数料見積もりではありません。Baseでは実行見積もりとL1手数料の問い合わせを分けます。Arbitrumでは標準のガス見積もりに投稿費用分の余裕が含まれるため、`gasLimit`から実行ガスを引いた値を一律に「余った無駄なガス」とは判断できません。 ウォレット表示はさらに、ガス上限の安全余裕、最大手数料、優先度手数料、独自RPC、法定通貨換算、スポンサー負担、画面上の丸めを加える場合があります。表示値が同じでも、どのRPCメソッドとブロックタグを使ったかが分からなければ再計算できません。 見積もりからレシート取得までに変わる主な要素は次です。 - 呼び出し直前のコントラクト状態と実際の実行経路 - 組み込まれたブロックの基準手数料と実際の優先度手数料 - L1基準手数料・Blob基準手数料・チェーン側のデータ価格見積もり - 圧縮の見積もり、直列化後のトランザクションサイズ、一括処理の条件 - 運用者スカラーと定数、最低手数料、ネットワーク更新 - トランザクションの`revert`、返金、置換、スポンサー負担条件 レシートが得られたら、ガス上限やウォレットの最大表示ではなく、レシートの構成要素から合計を作り直します。ブロック番号だけでなくハッシュも固定する理由は[RPCスナップショットの作り方](/archives/6024)で整理しています。 ## Blob手数料が下がっても利用者手数料が同率で下がるとは限らない EIP-4844のBlobガスは、Ethereumの実行ガスとは別の手数料市場です。ただしL2利用者が払うデータ費用は、Blob基準手数料だけでなく、圧縮の推定、スカラー、最低トランザクションサイズ、呼び出しデータの下限、運用者の回収設計を通じて決まります。 したがって、EthereumのBlob基準手数料が50%下がったとしても、L2総額が50%下がるとは限りません。実行が大部分なら総額への影響は小さくなります。チェーンが呼び出しデータを使う場合、Alt-DAを使う場合、スカラーを変更した場合も別です。 ## スポンサー・ペイマスター・代替手数料トークンは支払者と単位を分ける 「利用者の画面で0円」と「ネットワーク手数料が0」は同じではありません。 - ERC-4337ペイマスターは利用者の代わりに手数料を支払えますが、バンドラーのトランザクションにかかる実行費用とデータ費用は残ります - トークンペイマスターがERC-20で後精算する場合、ネイティブ手数料とトークン請求、取引所率、上限、返金を別に記録します - OP StackのCustom Gas Tokenを使うチェーンでは、ネイティブの手数料通貨自体がETH以外になり得ます。トークンシンボルだけでなく、アドレス、小数桁、チェーンIDを固定します - DAppのスポンサー負担では、期間、対象操作、上限、失敗時の負担がサービス側の条件です。プロトコルの計算式とは分けます ペイマスターを含む`UserOperation`の検証境界は[Account Abstractionの段階分解](/archives/6013)も参照してください。スポンサー表示がある場合でも、この記事の比較表や測定結果へ広告条件を混ぜません。今回のデータにスポンサー、アフィリエイト、トークン換算はありません。 ## ブリッジでは一つの操作に複数トランザクションがある ブリッジ画面に出る「手数料」は、送信元のトランザクション、メッセージの中継、送信先での実行、流動性提供者への手数料などをまとめて表示する場合があります。この記事で計算するレシートは、**一つのL2トランザクション**だけです。 送金全体を確認する場合は、[送信元・メッセージ・送信先を結ぶ手順](/archives/6027)と[L2出金の証明・確定・実行](/archives/6028)へ分けます。送信元側のL2手数料が安くても、別の段階にあるL1トランザクション、ブリッジサービス手数料、トークンの価格影響まで安いとは限りません。 シーケンサー停止やRPC遅延が疑われるときも、ガス価格だけでネットワーク状態を決めません。[L2シーケンサーフィードの停止境界](/archives/6042)のように、稼働状況、猶予期間、ブロック時刻、複数のRPCを照合します。 ## 再計算するときに保存する確認項目 1. チェーン名だけでなくチェーンIDと、メインネットかテストネットかを保存する 2. ネットワーク更新、手数料計算式バージョン、確認日を保存する 3. トランザクションハッシュ、型、ブロック番号、ブロックハッシュ、タイムスタンプを一組にする 4. 入力バイト数と内容の圧縮しやすさを分ける 5. レシートの`gasUsed`、`effectiveGasPrice`、チェーン固有項目をRPCが返した数量表現のまま保存する 6. Baseなら`l1Fee`と運用者手数料の引数、Arbitrumなら`gasUsedForL1`と`NodeInterface`のメソッドを確認する 7. 見積もりはRPCメソッド、要求内容、ブロックタグ、安全余裕を保存する 8. 手数料トークン、アドレス、小数桁、支払者、ペイマスター、スポンサー条件を保存する 9. ブリッジや一括処理なら別トランザクションの手数料を同じレシートへ足さない 10. 単発例を平均、ランキング、将来保証へ広げない 今回の4件のレシート、固定したブロックハッシュ、RPCが返した数量表現、8通りの条件、再計算結果は[検証用JSON](/fixtures/l2-fee-components-6054.json)で確認できます。計算にはwei単位の値を使い、ETH価格や法定通貨換算は使っていません。 ## まとめ Baseのように実行費用、`l1Fee`、運用者手数料を足すチェーンと、Arbitrumのように投稿費用をL2ガスへ換算して`gasUsed`へ含めるチェーンでは、同じ項目名だけを横並びにできません。 まずチェーンとバージョンを固定し、次に実行、データ可用性、運用者、支払者、建値の単位を分けます。見積もりは上限や余裕を含む予測で、レシートは組み込み後の観測です。最後に各構成要素を同じwei単位へそろえて合計すると、「L2なら常に安い」「Blobが下がれば総額も同率で下がる」「ガス価格×使用ガスだけで十分」という一般化を避けられます。 この記事にスポンサー掲載はありません。将来L2、RPC、ウォレット、手数料監視関連の広告を掲載する場合も、広告枠と計算式、公開データ、比較結果を明確に分離します。 ## 確認した一次情報 - [EIP-1559 fee market](): 確認日 2026-09-01 - [EIP-4844 shard blob transactions](): 確認日 2026-09-01 - [OP Stack transaction fees](): 確認日 2026-09-01 - [Base network fees](): 確認日 2026-09-01 - [Base transaction receipt RPC](): 確認日 2026-09-01 - [OP Stack Jovian execution specification at pinned commit](): 確認日 2026-09-01 - [Arbitrum Nitro whitepaper](): 確認日 2026-09-01 - [Arbitrum gas estimation tutorial at pinned commit](): 確認日 2026-09-01 - [ERC-4337 account abstraction and paymasters](): 確認日 2026-09-01 - [OP Stack custom gas token](): 確認日 2026-09-01 - [Ethereum JSON-RPC API](): 確認日 2026-09-01 --- # アドレスポイズニングとは？似た送金履歴・ゼロ送金・クリップボード改ざんの確認 送金履歴に似たアドレスやゼロ送金が現れたとき、独立した入手元、アドレス全文、チェーン、トークンコントラクト、Transferイベント、貼り付け後の値を順に確認します。 正規URL: https://3mikan.com/archives/6056 著者: みかん 公開: 2026-09-02T03:00:00.000Z 更新: 2026-09-02T05:35:00.000Z 送金履歴に、いつもの取引先と先頭・末尾が同じアドレスがあっても、そこから再送金しないでください。アドレスポイズニングは、よく似たアドレスを履歴へ混ぜ、利用者が次回それをコピーすることを狙います。ゼロ送金、少額送金、同じシンボルの偽トークンイベントなど、履歴への混ぜ方は一つではありません。 **送金先は履歴から選ばず、取引先の公式請求書、事前に検証したアドレス帳、認証済みの連絡経路など、履歴とは独立した情報で確認します。** そこから得たアドレス全文とチェーンを確認し、トークンならコントラクトと`Transfer`イベント、最後に貼り付け後の値と署名画面を照合します。 この記事は、実ウォレット、被害者アドレス、実資産、署名、トランザクション送信を使っていません。クリップボードマルウェアや似たアドレスの生成方法も実装しません。公開仕様と安全な合成データから、送金前の停止条件だけを整理します。 ## いま送金画面を開いているなら先に止める 次のどれか一つでも当てはまれば、送信確認や署名へ進まず画面を閉じます。 - 受取先をウォレットやブロックエクスプローラーの履歴からコピーした - アドレスの先頭と末尾しか比較していない - チェーン名やチェーンIDを、履歴とは独立した情報元と照合していない - トークン名・シンボルだけを見てコントラクトアドレスを確認していない - コピー元のアドレス全文と貼り付け後のアドレス全文が一文字でも違う - ウォレットやハードウェア端末の最終画面で受取先全体を確認できない - DMの相手がシードフレーズ、秘密鍵、遠隔操作、追加送金を求めている 少額テスト送金を先に済ませていても、この停止条件は変わりません。前回の一件が成功したことは、今回のクリップボード、履歴、アドレス帳、送金画面が同じ値を保持している証明ではないからです。 ## 4種類を同じ「怪しい履歴」にまとめない 履歴の一行だけでは、何が起きたかを決められません。まず表示の種類を分けます。 | 見え方 | チェーン上・端末上で確認するもの | その行だけで言えないこと | 送金前の判断 | | --- | --- | --- | --- | | 通常のネイティブ資産・トークン送金 | チェーンID、トランザクションハッシュ、送信元と送信先の全文、値。トークンならコントラクトと`Transfer`ログ | 表示された受取先が今も意図した相手か | 履歴からコピーせず、独立した確認元へ戻る | | ゼロ値送金 | トークンコントラクト、`Transfer`イベントの送信元、送信先、値、似たアドレス | 秘密鍵が漏れたこと、トークンを失ったこと、意図した相手のアドレスであること | 履歴行を宛先情報に使わない | | 同じシンボルの偽トークンイベント | イベントを出したコントラクト、シンボル、小数桁、送信元、送信先、値 | 有名トークンと同じコントラクトであること、正規エアドロップであること | シンボルではなくコントラクトから確認する | | クリップボード差し替え | コピー元の値、貼り付け後の値、最終確認画面にあるアドレス全文 | チェーン履歴だけから差し替え時点やマルウェアを特定できること | 一文字でも違えば署名前に停止する | ERC-20仕様では値が0の送金も通常の送金として扱い、`Transfer`イベントを発生させます。したがって、ゼロ値のイベントが存在すること自体は規格外ではありません。一方で、その行にあるアドレスを次の受取先として信頼する理由にもなりません。 偽トークンは、正規トークンと同じ名前やシンボルを表示できます。ブロックエクスプローラーやウォレットに「USDC」のような見慣れたシンボルがあっても、イベントを発行したコントラクトが違えば別トークンです。トークンの識別情報は、対象チェーン上のコントラクトアドレスから確認します。 クリップボード改ざんはチェーン外で起きます。コピーした値が貼り付け時に変わっても、署名してネットワークへ送る前なら、チェーン上のイベントはありません。履歴を調べる前に、独立した確認元と貼り付け後のアドレス全文を比較し、違えばそこで止めます。 ## 確認順は「独立した確認元 → チェーン → アドレス全文 → コントラクト → イベント → 最終画面」 ### 1. 履歴の外にある受取先の確認元へ戻る 取引先の公式請求書、交換所やサービスがログイン後の公式画面で発行した入金アドレス、事前に検証したアドレス帳、組織内の承認済み台帳などへ戻ります。検索結果、SNSの返信、依頼していないDM、履歴の行は確認元にしません。 アドレス帳も、登録時の入手元が誤っていれば安全ではありません。登録日、チェーン、用途、承認者を確認できない情報は、履歴と同じく未検証として扱います。ENSなどの名前を使う場合も、名前解決後のチェーンとアドレス全文を最終確認します。 ### 2. チェーンを名前とチェーンIDで固定する 同じ`0x`形式でも、Ethereum、Base、Arbitrumなどの状態は別です。請求書や入金画面が示すネットワークと、ウォレットで選択したチェーンをチェーンIDまで照合します。トークンの場合は、そのチェーン上のコントラクトアドレスも一組で保存します。 チェーンが違う、テストネットかメインネットか不明、ウォレットの独自ネットワーク情報を出所不明の相手から渡された場合は止めます。すでに別チェーンや別アドレスへ送った疑いがあるなら、新しい送金を作らず[誤ったネットワーク・アドレスの確認順](/archives/6009)へ進んでください。 ### 3. アドレス全文を比較する `0x1234…abcd`のような短縮表示は一覧を読む補助で、識別情報ではありません。先頭4文字と末尾4文字が同じでも、中間32文字が違えば別アドレスです。MetaMaskも、アドレスポイズニングでは中間文字まで確認し、履歴からアドレスをコピーしないよう案内しています。 EIP-55の大文字・小文字チェックサムは、入力誤りを検出しやすくする符号化です。チェックサムが有効でも、そのアドレスが意図した相手であることは証明しません。攻撃者側の別アドレスも、それ自身の有効なチェックサム表記を持てます。 比較するときは、次の三つの値を別々に表示します。 1. 独立した確認元から得たアドレス全文 2. ウォレットの受取先欄へ貼り付けたアドレス全文 3. 署名直前にウォレットまたはハードウェア端末が示すアドレス全文 三つが完全一致し、チェーンと用途も一致して初めて次へ進みます。見えない、途中が省略される、比較元が同じ端末の履歴しかない場合は停止します。 ### 4. トークンはコントラクトアドレスを確認する トークン送金では、トランザクションの`to`が受取先ではなくトークンコントラクトになる場合があります。ウォレットの資産名だけでなく、対象チェーン上のトークンコントラクトを公式プロジェクトやサービスの独立した案内と照合します。 コントラクトが違う、プロキシや移行の関係が不明、シンボルだけ同じ、未知のトークンを「受け取ったから換金できる」と案内された場合は、そのコントラクトを呼び出しません。偽トークンの行を非表示にすることと、そのトークンを交換、`approve`、送金することは別の操作です。 ### 5. トランザクションと`Transfer`イベントを分けて読む ネイティブ資産の送金なら、トランザクションの`from`、`to`、`value`を確認します。ERC-20なら、イベントを発行したコントラクトと`Transfer(from, to, value)`を確認します。ブロックエクスプローラーの操作履歴一覧は複数の種類をまとめる場合があるため、一覧の方向矢印やシンボルだけを証拠にしません。 | 確認対象 | ネイティブ資産 | ERC-20トークン | | --- | --- | --- | | 識別情報 | チェーンのネイティブ資産 | チェーン + トークンコントラクト | | 受取先 | トランザクションの`to` | `Transfer`イベントの`to` | | 数量 | トランザクションの`value` | `Transfer`イベントの`value`とトークンの小数桁 | | ゼロ表示 | 0値のトランザクションか別のイベントかを確認 | 仕様上、ゼロ値の`Transfer`イベントがあり得る | | 履歴行の限界 | 正しい相手を示す確認元にはならない | シンボルや行だけではコントラクトを識別できない | ゼロ値行と同じシンボルの偽トークン行は、似た表示でも根拠が異なります。一つの「スパム判定」にまとめず、コントラクトとイベント項目を保存してください。 ### 6. 貼り付け後と最終確認画面をもう一度比較する クリップボードからウォレットへ貼り付けた直後に、独立した確認元とアドレス全文を比較します。送金内容を編集した、別のタブへ移動した、ウォレットが再接続した、QRコードを読み直した場合も比較し直します。 ハードウェアウォレットを使う場合は、ホストのPCや電話ではなく端末自身の画面で受取先、チェーン、数量を確認します。ただし端末に十分な項目が出ない要求を「ハードウェアウォレットだから安全」として承認しません。機種ごとの表示境界は[ハードウェアウォレット5機種の公式仕様比較](/archives/6034)で整理しています。 ## 少額テスト送金が証明する範囲 少額テストは、特定時点の一回の送金が、特定チェーン・特定アドレスへ届いたかを確認する手段です。次のことまでは証明しません。 - 次回もクリップボードが同じアドレスを貼り付ける - 履歴の最新行がテスト時の受取先である - アドレス帳が更新・差し替えされていない - 同じシンボルのトークンコントラクトが同じである - 相手が今もそのアドレスを管理し、今回の入金用途に使う - 本送金が取引所の最低入金額、Memo・Tag、法令や規約上の条件を満たす テスト後も毎回、独立した確認元、チェーン、アドレス全文、トークンコントラクト、貼り付け後の値、端末表示を確認します。履歴から「前に成功した行」を選び直すと、テスト送金を行った意味が失われます。 取引所入金が反映されない場合は、同じ送金を繰り返さず、[TxID・承認数・Memo・Tagの確認手順](/archives/6008)でチェーン上の成功とサービス内の反映を分けてください。 ## ウォレットやブロックエクスプローラーの警告は補助情報にすぎない MetaMaskは、過去のアドレスと似て中間が異なる受取先や、初めて使う受取先に警告を出すと案内しています。Etherscanも、ゼロ値送金や低評価トークンを非表示にしたり警告したりする対策を説明しています。 これらは誤操作を減らす補助ですが、警告が出ないことを安全の証明にはできません。ウォレットのバージョン、表示する画面、チェーン、トークン、攻撃手法によって検出範囲は変わります。反対に警告が出たからといって、秘密鍵の漏えいや資産損失が確定したわけでもありません。 判断は警告の有無ではなく、独立した確認元とアドレス全文の一致へ戻します。 ## 貼り付けた値が違う、または誤送金したとき ### ネットワークへの送信前なら署名しない 受取先が違う、クリップボードの値が変わった、チェーンやコントラクトが不明なら送信を確定しません。問題を調べるために、同じ端末で新たにシードフレーズ、秘密鍵、パスワード、2FAバックアップコードを表示・入力しないでください。 コピー元、貼り付け後の値、時刻、ウォレット、ブラウザー、OSのバージョン、導入済み拡張機能の入手元を、秘密情報を含めず保存します。端末の検査や隔離方法はOSや組織ごとに異なるため、使用中のOS提供元やセキュリティ担当者の公式手順へ引き継ぎます。 ### ネットワークへの送信後なら追加送金を止めて証拠を固定する 次を一つのメモへ保存します。 - トランザクションハッシュ、チェーン名、チェーンID、ブロック、状態、日時とタイムゾーン - `from`と`to`の全文、ネイティブ資産の値 - トークンならコントラクトアドレス、`Transfer`イベントの送信元、送信先、値、小数桁 - 独立した確認元にあった受取先と、実際に送った受取先 - ウォレット、ブラウザー、OS、拡張機能のバージョンと確認時刻 - 相手やサポートを名乗る連絡のURL、アカウント、要求内容 確定済みトランザクションをウォレット提供者が取り消したり、凍結、返金、回収を保証したりすることはできません。追加の「確認送金」「回収用ガス」「解除料」を送りません。シードフレーズや秘密鍵を要求するDM、遠隔操作ツール、画面共有、先払い、「必ず回収できる」という案内は、二次詐欺を疑って対応を止める条件です。 自分が作っていないトランザクション、他チェーンでも続く動き、シード入力や不審拡張機能の事実がある場合は、原因をアドレスポイズニングだけに決めず、[ウォレット侵害時に権限層を分ける初動ガイド](/archives/6026)でシード、利用許可、Permit、セッション、委任、端末を切り分けてください。 ## 組織・ウォレット画面の予防確認項目 - 受取先の確認元を履歴と分離し、チェーン、用途、登録日、承認者を記録する - 新規・変更アドレスは別経路で確認し、同じDMスレッドだけで承認しない - 一覧の短縮アドレスからコピーできない、または全文表示を先に開く設計にする - ゼロ値、不明コントラクト、同一シンボル衝突を一つの通常履歴へ混ぜない - トークン名よりコントラクトアドレスを表示し、イベント発行元と受取先を分ける - 貼り付け直後と署名前にアドレス全文の比較を行う - 高額送金は複数人の承認や承認済み宛先リストを使い、履歴の再利用を禁止する - 警告を閉じた事実、確認元、チェーン、受取先の全文を監査ログへ残す ## 最終確認項目 - [ ] 受取先は履歴ではなく独立した確認元から取得した - [ ] チェーン名とチェーンIDを固定した - [ ] アドレス全文を中間部分まで含めて比較した - [ ] チェックサムを、意図した相手のアドレスであることの証明にしていない - [ ] トークンはシンボルではなくコントラクトアドレスを確認した - [ ] トランザクションと`Transfer`イベントを分けた - [ ] ゼロ値送金と偽トークンイベントを分けた - [ ] コピー元、貼り付け後、最終確認画面のアドレス全文が一致した - [ ] 少額テスト送金を将来の安全保証にしていない - [ ] 不一致があれば署名・追加送金・非公式DM対応を止めた アドレスポイズニングへの最短の対策は、怪しい行を完全に消すことではありません。**履歴を受取先の確認元にせず、チェーンとアドレス全文を独立した情報で確認し、トークンコントラクト、イベント、貼り付け後の値、最終確認画面を順に照合すること**です。 この記事にアフィリエイト、スポンサー、回収サービスへの導線はありません。緊急時の確認手順と商業案内は分離します。 ## 確認した一次情報 - [MetaMask address poisoning scams](): 確認日 2026-09-02 - [MetaMask clipboard hacking](): 確認日 2026-09-02 - [MetaMask compromised wallet guidance](): 確認日 2026-09-02 - [Etherscan address poisoning attacks](): 確認日 2026-09-02 - [Etherscan zero-value token transfer attack](): 確認日 2026-09-02 - [ERC-20 Token Standard](): 確認日 2026-09-02 - [ERC-55 mixed-case checksum address encoding](): 確認日 2026-09-02 - [Ledger address poisoning guidance](): 確認日 2026-09-02 --- # トークンを送れない・売れない原因｜送金手数料・拒否リスト・残高変動を確認 ERC-20の送金・交換失敗を、送金時に差し引かれる手数料、残高変動、停止、拒否リスト、最大取引量、売却制限、流動性、許容価格差に分け、読み取り専用の操作で確認します。 正規URL: https://3mikan.com/archives/6061 著者: みかん 公開: 2026-09-01T16:30:00.000Z 更新: 2026-09-02T05:35:00.000Z トークンを送れない、受取額が減った、買えたのに売れない、交換の見積もりだけ失敗する。これらを全部「許容価格差」や「ウォレットの不具合」にまとめると、原因が分からないまま利用許可や失敗トランザクションを重ねることになります。 最初に分けるのは、**トークンコントラクト自身の送金条件**、**プールの流動性と価格影響**、**ルーターの最低受取額と有効期限**、**ウォレットやインデックスサービスの表示**です。ブロックエクスプローラーの検証済み表示、過去に購入できた事実、シンボル、一つの検出器による判定は、現在の売却や送金が成功する証明になりません。 この記事は公式仕様とローカルの合成コントラクトだけを使います。実在トークンの売買、ウォレット接続、利用許可、署名、送金、交換、ブリッジ、公開トランザクションは行いません。 ## 原因が分かるまで止める操作 次の操作は、調査ではなく新しいリスクを増やします。 - 失敗のたびに許容価格差を上げる - 別ルーターや未知の「売却専用サイト」へウォレットを接続する - コントラクトを直接呼び出しすれば回避できるという案内に従う - 利用許可を取り消しては付け直す操作を繰り返す - トークン名やエラーメッセージに書かれたURLを開く - 「トークン税」「解除手数料」「回収用ガス」を先払いする - シードフレーズ、秘密鍵を渡す、遠隔操作や画面共有を許可する まず公開情報だけを保存し、どの層で止まったかを分類します。秘密情報、署名、追加送金は証拠に含めません。 ## 一つの調査メモへ固定する値 | 層 | 保存する値 | 混同しないもの | | --- | --- | --- | | 識別情報 | チェーンID、トークンコントラクトのアドレス全文、確認したブロック番号とハッシュ | シンボル、名前、アイコン | | アカウント | 送信者と受取先のアドレス全文、RPCから取得した残高、小数桁 | ウォレットの丸めた表示だけ | | トランザクション | トランザクションハッシュ、レシートの状態、呼び出されたアドレス、関数セレクター、`revert`データ | 一覧の「失敗」表示だけ | | 送金の会計 | 送信者の減少額、受取先の増加額、手数料の収集先または焼却、`Transfer`ログ | 交換の許容価格差 | | 権限 | プロキシ、実装、所有者、役割、管理者、タイムロック、更新イベント | 検証済みバッジ | | 市場 | ペアやプール、経路、有効流動性、価格影響 | トークンコントラクトの拒否リスト | | ルーター | 正確な入力と出力、最低受取額、有効期限、利用許可額 | トークンを送金できるかどうか | | 観測 | RPC、ブロック、`from`、`to`、数量、経路、確認時刻 | 将来のトランザクション保証 | トークンがウォレットへ出ないだけなら、先に[チェーン・コントラクト・小数桁から表示を確認する手順](/archives/6029)を使います。`balanceOf`はあるのに一覧へ出ない問題と、`transfer`自体が`revert`する問題は別です。 ## 標準ERC-20を基準に差を見る [ERC-20](https://eips.ethereum.org/EIPS/eip-20)は、`transfer`と`transferFrom`が`bool`を返すインターフェース、残高、利用許可額、`Transfer`と`Approval`イベントを定めています。呼び出し側は`false`を無視してはいけません。 ただしERC-20という名前だけで、次の機能がないことまでは保証されません。 - 送金時の手数料や焼却 - 残高を伸縮させるリベースや持分会計 - 停止、拒否リスト、許可リスト - 1回の最大量、待機時間、保有期間 - 特定プール、ルーター、送信者、受取先だけを対象にする条件 - プロキシ更新で後から変わる実装 基準にする観測は単純です。固定ブロックの前後で、送信者が`amount`減り、受取先が同じ`amount`増え、成功を示す戻り値と対応するイベントがあるかを見ます。一つでも違えば、すぐに悪意や詐欺と断定せず、差の説明へ進みます。 ## 6種類のトークン挙動を分ける | 例 | 決定的な証拠 | 主な影響 | 一つの信号で断定しないこと | | --- | --- | --- | --- | | 標準 | 送信者の減少額と受取先の増加額が指定数量に一致 | 通常の連携処理の前提 | 安全・公式・十分な流動性 | | 送金時手数料型 | 減少額、増加額、収集先または焼却が同じ送金で説明できる | 受取額の減少、見積もりとの差、ルーター非対応 | 差額はすべて既知の手数料 | | 残高変動・持分 | 持分や指数は一定または変化し、表示残高が送金以外でも変わる | ウォレットとインデックスサービスの差、プールの会計差 | イベントがないから資産を失った | | 停止・拒否リスト | 現在の状態、役割、固有の`revert`、対象アカウント | 全体停止またはアカウント別の停止 | `revert`文字列だけで対象コントラクトを特定 | | `maxTx`・待機時間 | 必要な数量、直前の操作、ブロックや時刻の条件 | 数量や時点で結果が変わる | 少額で成功すれば将来も成功 | | 売却制限 | 設定されたプールや受取先でだけ条件が変わる | 購入と通常送金は通っても売却は失敗 | 1回の失敗だけでハニーポットと断定 | 「ハニーポット」は市場や検出器で広く使われる呼び方ですが、この記事では一つのラベルにまとめません。プール宛てだけの制限、可変手数料、所有者が変更できる状態、ルーター非対応、少ない流動性を別々に記録します。 ## 送金時手数料型は指定額・受取額・手数料を三列にする 送金時手数料型では、`1,000`を指定しても受取先の増加が`975`、手数料の収集先または焼却が`25`になるような実装があります。確認式は次の形です。 ```text 送信者の減少額 = 受取先の増加額 + 確認できた手数料または焼却額 + 説明できない差 ``` ローカルの例では`1,000 = 975 + 25 + 0`となりました。ところが受取先の増加が`950`で、確認できる手数料が`25`しかなければ、残る`25`を「たぶんトークン税」と推測で埋めません。手数料率、対象アドレス、除外一覧、収集先、焼却、イベント、確認したブロックの状態を読み、説明できない差として止めます。 トークン手数料とDEXのプール手数料も別です。トークンコントラクトが送金時に徴収する手数料を、プールが価格曲線やプロトコル手数料として取る額と合算しないでください。 Uniswap V2 Router02には送金時手数料型向けの別関数がありますが、どのトークン実装も扱える保証ではありません。Uniswap V3の中核は、送信者の減少額と受取先の増加額が指定数量に一致するトークンを前提としています。Uniswap Labsは、送金時手数料型、リベース、リフレクショントークンをV3とV4で非対応と案内しているため、ルーターを変える前に対象プロトコルとバージョンの公式な対応範囲を確認します。 ## 残高変動は持分と表示残高を分ける 残高変動トークンには複数の設計があります。ローカル例ではアカウントが持分を持ち、次の式で表示残高を計算しました。 ```text 表示残高 = 持分 × 換算係数 ``` 同じ`1,000`の持分でも係数が変わると、表示残高が`1,250`または`800`になります。この例では利用者が送金しなくても残高が変わります。すべてのリベース、リフレクション、利息付きトークンがこの式やイベント設計を使うわけではありません。 確認するのは合計供給量だけではなく、アカウントの持分と残高の単位、換算係数や指数、リベースイベント、ウォレットとインデックスサービスの更新時点、プールコントラクトが保持する残高です。`Transfer`イベントがない変化を即座に盗難とみなさず、逆にウォレット表示だけをチェーン上残高の確定値にしません。 ## 停止・拒否リスト・`maxTx`・待機時間を状態へ対応させる OpenZeppelinの`ERC20Pausable`は送金、発行、焼却を停止条件へ結び付けますが、公開する`pause`関数と権限設計は利用側のコントラクトが定義します。`Ownable`、`AccessControl`、独自修飾子では、同じ「管理者」に見えても変更できる項目が異なります。 次の順で固有の状態と失敗を対応させます。 1. 呼び出し先がトークン、ルーター、プロキシのどれかを確認する 2. プロキシなら現在実装を固定ブロックで解決する 3. `revert`データをデコードし、ソース内の条件へ対応させる 4. 停止、拒否リスト、許可リスト、`maxTx`、待機時間、プール設定を同じブロックで読む 5. 所有者、役割管理者、タイムロック、更新権限が誰かを確認する 6. 過去イベントから、設定がいつ変更されたかを確認する 「停止関数がABIにない」だけでは、停止に相当する独自条件がない証拠にはなりません。反対に`paused()`が存在しても、それが今回通った送金経路へ適用されるかは、ソースと呼び出し経路で確認します。 ## 購入できても売却できる証明にはならない 購入と売却では、トークン送金の送信者と受取先が逆になります。独自処理が、設定されたプール、ルーター、受取先、送信者、数量、ブロックを条件にすると、プールから利用者への購入は通り、利用者からプールへの売却だけ`revert`することがあります。 同様に、ウォレット間の少額送金が通っても、プール宛て、取引所の入金コントラクト宛て、ブリッジコントラクト宛てが通る保証にはなりません。過去の成功を安全の証明にせず、現在の実装と状態を確認します。 ただし、売却が1回失敗しただけで、悪意のあるハニーポット、違法、回収不能とも断定しません。利用許可額の不足、有効期限、最低出力、経路変更、流動性不足、ネットワーク手数料不足、停止中のプールなど、別の層の失敗もあります。検出器の結果は調査候補であり、コントラクトの識別情報やRPCから得たデータの代わりにはなりません。 ## 流動性・価格影響・許容価格差・有効期限は市場とルーターの層 | 信号 | 層 | 確認する値 | トークン制限との違い | | --- | --- | --- | --- | | 流動性不足 | 市場 | プール、有効流動性、経路、ペアの識別情報 | トークン送金前に見積もりが成立しない場合がある | | 大きな価格影響 | 市場 | 入力数量、中間価格、平均約定価格 | 注文自体が見積もりを動かす | | 最低受取額 | ルーター | 見積もり、許容差、想定出力と最低出力 | 実行時の出力が境界を下回る | | 有効期限 | ルーター | 署名済み要求の有効期限、ブロックタイムスタンプ | 時間条件でルーターが止める | | 停止・拒否リスト・`maxTx` | トークン | 実装状態、アカウント、数量、`revert` | 許容価格差を変えても条件自体は直らない | | 送金手数料 | トークンと連携処理 | 減少額、増加額、手数料、ルーターの対応状況 | 見積もり計算と実際の受取額の前提が変わる | 価格影響と許容価格差の計算、最低出力、MEVは[DEXの価格影響と許容価格差を分ける手順](/archives/741)で確認できます。オラクルやTWAPがトークンの送金制限を示すわけでもないため、価格情報の取得元を調べる場合は[小数桁・鮮度切れ・TWAP・L2停止の検証](/archives/6042)へ分けます。 ## `false`・空戻り値・`revert`は同じ失敗ではない EVM呼び出しの結果には少なくとも次の違いがあります。 - 呼び出しが`revert`し、`revert`データや独自エラーを返す - 呼び出し自体は`revert`しないが、ERC-20の`bool`として`false`を返す - 呼び出しは`revert`せず戻り値データが空で、古い非標準トークンとして組み込み側が扱う - `true`を返しても、受取残高やイベントが想定と一致しない ERC-20は呼び出し元が`false`を処理するよう求めます。OpenZeppelinの`SafeERC20`は`false`を失敗として扱い、戻り値データが空で`revert`しないトークンもサポートします。したがって「トランザクションの状態が成功」「EVMが`revert`しなかった」「戻り値が`true`」「受取先残高が増えた」を別々に保存します。 独自エラーの名前も、信頼できるソースと識別子対応があって初めて意味を持ちます。ウォレットやサイトが整形した文字列だけで、どのコントラクトがどの条件を判定したか決めません。 ## 検証済みソースからプロキシ・権限・更新を追う順番 ブロックエクスプローラーの検証済みソースが直接示すのは、提示ソースとデプロイバイトコードの対応です。売却可能、安全、公式、更新不能という保証ではありません。再構築と一致の境界は[コンパイラー・コンストラクター・プロキシまで確認する手順](/archives/6033)で扱っています。 調査順は次のとおりです。 1. チェーンID、トークンアドレス全文、ブロック番号とハッシュを固定する 2. `eth_getCode`でプロキシか直接実装かを確認する 3. ERC-1967なら実装、ビーコン、管理者スロットと更新イベントを読む 4. 実装の検証済みソース、コンパイラー、実行時バイトコードを照合する 5. `transfer`と`transferFrom`から内部の更新経路、手数料、制限を追う 6. 所有者、役割、役割管理者、タイムロック、マルチシグ、更新権限を列挙する 7. プールとルーターのアドレス、流動性、価格影響、最低出力を別の記録へ分ける 8. 固定入力の読み取り専用シミュレーションを行い、ブロック識別情報と戻り値または`revert`を保存する プロキシのストレージはプロキシ側にあり、処理は実装側にあります。実装ソースだけを読み、プロキシ状態や管理者を見ない調査は不完全です。更新後は、以前のシミュレーションやソースレビューを現在の保証として使いません。 ## シミュレーション成功は将来のトランザクション成功ではない `eth_call`は公開トランザクションを送らずに、指定ブロックの状態に対して呼び出しを評価できます。再現条件には次を含めます。 ```text チェーンID、RPCの識別情報、ブロック番号、ブロックハッシュ from、to、value、呼び出しデータ、ガスの前提 トークン実装、トークンの状態、残高、利用許可額 プール、経路、入力、最低出力、有効期限 戻り値またはrevertの生データ ``` 同じ入力でも、所有者が手数料や拒否リストを変更した、プロキシが更新された、残高や利用許可額が変わった、プール価格が動いた、有効期限を過ぎた、別ブロック生成者環境になった場合は結果が変わります。シミュレーション成功は、記録した条件で`revert`しなかったという証拠であり、メモリープールへの受理、ブロック組み込み、実行順、最終成功、受取額を保証しません。 シミュレーション失敗も原因を自動確定しません。RPCの状態、`from`、ガス、ブロック引数、ルーター、呼び出しデータが本番要求と違う可能性を先に排除します。 ## ローカルの合成コントラクトで再現した範囲 Solidity `0.8.36`、Prague EVMの自己完結したローカルコントラクトをコンパイルし、次を分けました。 | 例 | ローカル観測 | 記事で使う境界 | | --- | --- | --- | | 標準 | 引き落とし`1,000`、残高`1,000` | 基準であって安全評価ではない | | 送金時手数料型 | 減少額`1,000`、増加額`975`、手数料`25` | 差額を会計で説明する | | 持分リベース | 持分は一定、表示残高は`1,250`または`800` | 一つの設計例に限定する | | 制限付き | 停止、拒否リスト、`maxTx`、待機時間、プール宛て売却を別々の独自エラーで再現 | 制限同士を混ぜない | | 非標準戻り値 | 空戻り値と`false`を別コントラクトで再現 | EVM `revert`と戻り値を分ける | この検証は実在するトークンの検出器ではありません。公開RPC、実際のトークン、ウォレット、アカウント、資産、利用許可、署名、ネットワークへの送信、交換を使わず、攻撃目的のデプロイや制限の回避方法も含みません。 ## 公式サポートやセキュリティレビュー担当者へ渡す証拠パッケージ ```text 確認日時とタイムゾーン: チェーン名、チェーンID: トークンコントラクトのアドレス全文: ブロック番号、ブロックハッシュ: プロキシ、実装、ビーコン、管理者: 所有者、役割、タイムロック、直近の更新: 送信者、受取先またはプールの役割（秘密情報は除く）: RPCが返した数量、小数桁: 送信者の減少額、受取先の増加額、確認できた手数料、説明できない差: レシートの状態、呼び出されたアドレス、関数セレクター: 戻り値またはrevertの生データ: 停止、拒否リスト、maxTx、待機時間、プールの状態: プール、経路、有効流動性、価格影響: 想定出力、最低受取額、有効期限: シミュレーション条件（RPCの識別情報、from、to、呼び出しデータ、ブロック）: 画面を使った場合のウォレット、アプリ、ブラウザーのバージョン: ``` 公開アドレスやトランザクションであっても、問い合わせ先と共有してよい範囲を確認します。シードフレーズ、秘密鍵、パスワード、2FAコード、セッションCookie、APIキー、端末の完全なバックアップ、遠隔操作の権限は渡しません。 ## 症状別の停止条件 | 症状 | 次の読み取り専用確認 | 停止する操作 | | --- | --- | --- | | 受取額が少ない | 引き落とし、残高、手数料の収集先、焼却、イベント | 手数料と決めつけて再送しない | | 残高が勝手に変わった | 持分、指数、リベース、固定したブロックでの残高 | イベントがないだけで盗難と断定しない | | 全送金が`revert` | 実装、停止、役割、直近の更新 | 直接呼び出しで回避しない | | 特定アカウントだけ`revert` | 拒否リスト、許可リスト、送信者・受取先条件 | 別アカウントで試して制限を回避しない | | 大きな数量だけ`revert` | `maxTx`、上限の単位、現在の状態 | 小分け送金を自動推奨しない | | 売却だけ`revert` | プール設定、手数料、ルーターの対応状況、利用許可額、流動性 | 許容価格差の変更や未知のルーターを繰り返し試さない | | 見積もりが出ない | ペアの識別情報、経路、有効流動性 | 同じシンボルの別トークンを選ばない | | シミュレーションだけ成功 | 固定入力、ブロック、変更可能な状態 | 実トランザクション成功と表示しない | 「売却代行」「凍結解除」「税金を払えば解除できる」「必ず回収できる」という、依頼していないDMは二次被害の兆候です。この記事にはトークン検出器、ウォレット、DEX、取引所、監査、回収サービスのアフィリエイトやスポンサー導線を置いていません。 ## 最終チェックリスト - [ ] チェーンIDとトークンコントラクトのアドレス全文を固定した - [ ] シンボル、名前、アイコンを識別情報にしていない - [ ] ウォレット表示と固定したブロックでの`balanceOf`を分けた - [ ] 送信者の引き落とし、受取先残高、手数料または焼却、説明できない差を保存した - [ ] リベースの持分、指数、イベント設計を対象ソースで確認した - [ ] 停止、拒否リスト、`maxTx`、待機時間、プール制限を別状態として読んだ - [ ] 流動性、価格影響、最低受取額、有効期限をトークン制限と分けた - [ ] `false`、空戻り値、`revert`、残高変化を別結果として扱った - [ ] プロキシ、実装、所有者、役割、更新イベントを同じブロックへ対応させた - [ ] シミュレーションの`from`、`to`、呼び出しデータ、ブロック、経路を保存した - [ ] シミュレーションを将来のトランザクション成功保証にしていない - [ ] 利用許可、署名、送金、交換、別ルーター、直接呼び出しを追加していない - [ ] 一つの検出器だけで詐欺・ハニーポット・回収不能と断定していない - [ ] 秘密情報、遠隔操作、解除料、回収代行を渡していない トークンを送れない・売れないときの最短経路は、設定を緩めることではありません。**チェーンとコントラクトを固定し、送金の会計、制限の状態、市場、ルーター、シミュレーションを順番に分け、最初に説明できない差が出たところで追加操作を止めること**です。 ## 確認した一次情報 - [ERC-20 Token Standard](): 確認日 2026-09-02 - [OpenZeppelin Contracts 5.x ERC20 API](): 確認日 2026-09-02 - [OpenZeppelin Contracts 5.x Access Control](): 確認日 2026-09-02 - [OpenZeppelin SafeERC20 v5.6.1 source](): 確認日 2026-09-02 - [Uniswap V2 Router02 source](): 確認日 2026-09-02 - [Uniswap V3 core token assumptions](): 確認日 2026-09-02 - [Uniswap fee-on-transfer and rebase token support boundary](): 確認日 2026-09-02 - [Uniswap transaction failure guidance](): 確認日 2026-09-02 - [ERC-1967 Proxy Storage Slots](): 確認日 2026-09-02 - [Ethereum JSON-RPC API](): 確認日 2026-09-02 - [Solidity 0.8.36 errors and revert](): 確認日 2026-09-02 --- # セキュリティキー4製品を公式仕様で比較｜FIDO2・NFC・パスキー・復旧 Yubico、Google Titan、Token2、FEITIANのUSB-C・NFC対応セキュリティキーを、FIDO2、パスキー容量、PIN、認証情報の管理、紛失時の復旧設計から公式情報で比較します。 正規URL: https://3mikan.com/archives/6069 著者: みかん 公開: 2026-09-01T23:30:00.000Z 更新: 2026-09-02T05:35:00.000Z セキュリティキーを選ぶ前に、何を守る道具かを分けてください。この記事で扱うのは、取引所、メール、パスワード管理サービス、Gitホスティング、クラウドなどの**アカウントへのログインをFIDO2とWebAuthnで保護する物理認証器**です。暗号資産ウォレットのシードフレーズや秘密鍵を保存し、チェーン上トランザクションへ署名するハードウェアウォレットではありません。 この記事は2026-09-02時点で公式の販売・サポート情報を確認できた、Yubico Security Key C NFC、Google Titan Security Key USB-C・NFC、Token2 PIN+ Release3.3 TypeC、FEITIAN ePass FIDO-NFC K40を比較します。4製品ともUSB-CとNFCを備えた近い製品区分にそろえました。 重要な制限があります。3MIKANは今回、4製品の実機を購入しておらず、貸与も受けていません。登録、PINの誤入力、パスキーの一覧・削除、NFC接続、初期化、紛失からの復旧、耐久性を確認した実機レビューではなく、公式の製品情報、サポート情報、規格、認証から候補を絞るための記事です。 実機評価点や「最も安全」という順位は付けません。 ## 先に結論：1本の価格だけでなく復旧まで考える 候補を選ぶ順番は次のとおりです。 1. 守りたいサービスがFIDO2パスキー、またはFIDO U2Fの第二要素に対応するか確認する 2. 使用端末のUSB-CとNFCで、対象OS・ブラウザー・サービスの組み合わせが動くか確認する 3. パスワードなしで使うなら、キー内へ保存する認証情報の数とPINの管理方法を決める 4. 普段使うキーとは別のセキュリティキーを同じアカウントへ個別登録し、別の場所へ保管する 5. サービスが発行する復旧コードやアカウント復旧を、普段使うキーと予備キーの両方を失った経路として確認する セキュリティキー上のパスキーは、普段使うキーから予備キーへ自動でコピーされません。Google Chromeの公式案内も、セキュリティキーに保存したパスキーはバックアップされず、キーを紛失または初期化すると復元できないと説明しています。したがって購入予算は「1本の値段」ではなく、必要なら**2本と安全な復旧手段**まで含めて考えます。 ## セキュリティキーがフィッシングに強い理由と限界 WebAuthnでは、認証情報がRelying Party ID（RP ID）へ紐づき、ブラウザーは呼び出し元オリジンがその範囲に合うか確認します。サービス側はサーバーで作ったチャレンジ、返されたオリジン、RP ID、署名、利用者の操作確認（UP）、必要なら利用者確認（UV）を検証します。 偽ドメインへ同じパスワードやTOTPコードを入力する方式と異なり、正規サイト用の認証情報を別RP IDへそのまま使えないことがフィッシング耐性の中心です。ただし、次まで自動で防ぐ道具ではありません。 - サービス側のアカウント復旧やサポート手続きの乗っ取り - ログイン後のセッションCookie盗難 - すでに許可したAPIトークンやOAuthアクセス - 端末マルウェア、悪意ある拡張機能、遠隔操作 - セキュリティキーを登録できないサービスで使うパスワードやTOTP - 自分で攻撃者を新しい認証手段として追加する操作 「セキュリティキーがあればフィッシングを完全防止できる」とは判断せず、アカウントの既存セッション、復旧メール、電話、APIトークン、管理者権限も別に確認します。不審な操作履歴がすでにある場合は、設定変更を急ぐ前に[ウォレット・アカウント侵害時の証拠保存と初動](/archives/6026)で追加操作を止め、対象サービスの公式窓口へ引き継いでください。 ## 4製品の公式仕様比較 表は2026-09-02に各社の公式情報で確認した範囲です。容量は、セキュリティキー内へ保存する「発見可能な認証情報（discoverable credential）」の数です。U2F型の発見不可能な認証情報（non-discoverable credential）はサーバー側の認証情報IDを使うため、同じ数え方にはなりません。 | モデル | FIDOと主な機能 | 接続 | パスキー容量 | PINと生体認証 | 認証情報管理 | ファームウェア方針 | 公式ストアの確認状態 | | --- | --- | --- | ---: | --- | --- | --- | --- | | Yubico Security Key C NFC、ファームウェア5.8 | FIDO2、WebAuthn、U2F、CTAP2.1、FIDO2 Level 2 | USB-C、NFC | 100 | PINあり、生体認証なし | Yubico Authenticatorで一覧・削除・PIN | 製造後のファームウェア更新不可 | 地域別ページで€35.09、販売中 | | Google Titan Security Key USB-C・NFC | FIDO2、FIDOの公開標準、Google Advanced Protection対応 | USB-C、NFC | 250超 | PINあり、生体認証なし | OSやブラウザーのセキュリティキー管理機能 | Google設計のファームウェアとSecure Element。利用者向けの更新方法は今回未確認 | 日本ストアで¥5,625、入荷通知状態 | | Token2 PIN+ Release3.3 TypeC | FIDO2.1、U2F、FIDO2 Level 2、TOTP、HOTP、PIV、OpenPGP | USB-C、NFC | 300 | 6桁以上のPINという複雑性要件、生体認証なし | Token2 Companion Appなどで一覧・削除・PIN | ファームウェア更新不可。新機能は新バージョン | $26.78、在庫あり表示 | | FEITIAN ePass FIDO-NFC K40 | FIDO2、U2F、OTP、現行一覧でCTAP2.1 | USB-C、NFC | モデル固有値は未確認 | PINあり、生体認証なし | FEITIAN SK Managerで一覧・削除・PIN・初期化 | バージョン履歴あり。K40の利用者向け更新可否は今回未確認 | $35、公式ストア掲載 | 価格、税、為替、送料、関税、在庫、配送地域は変わります。Titanは日本の公式ストアでUSB-C・NFCモデルを選んだ状態に「ログインして入荷通知を登録する」と表示されていたため、地域対応国に日本が含まれていても、すぐ買える在庫とは扱いません。購入直前に公式ストアで選択したモデルとカートを再確認してください。 4製品とも購入しておらず、貸与品やスポンサー提供品もありません。この記事にアフィリエイトリンクはなく、価格、掲載順、セキュリティ評価に販売手数料を反映していません。 ## Yubico Security Key C NFC：FIDO専用に絞る候補 [Security Key C NFC公式ページ](https://www.yubico.com/product/security-key-c-nfc-by-yubico-black/)は、ファームウェア5.8、USB-C、NFC、FIDO2、WebAuthn、U2F、100個のFIDO2認証情報、FIDO2 Level 2、IP68を案内しています。OATH、PIV、OpenPGP、Yubico OTPには対応しないFIDO専用モデルです。 用途をFIDOログインへ限定し、別プロトコルの設定項目を増やしたくない人には分かりやすい構成です。一方、同じ物理キーでPIVやOpenPGPも使いたい場合は、Security Key Seriesではなく別シリーズとの比較が必要です。 Yubico Authenticatorではパスキーの一覧・削除、FIDO2 PINの設定・変更ができます。PINを忘れた場合はFIDO2アプリケーションを初期化し、保存済みパスキーをすべて削除する必要があります。初期化後もアカウント側に古い認証情報登録が残るため、予備キーでログインして失った・初期化したキーを各サービスから削除します。 ファームウェアは製造時に書き込まれ、後から別バージョンへ更新できません。これは「更新しなくてよいから常に安全」という意味ではなく、脆弱性や必要機能が後のファームウェアで解決されても手元の個体へ適用できない注意点です。購入時にファームウェアとサポート対象を確認します。 ## Google Titan Security Key USB-C・NFC：Googleの高リスク運用も見る候補 [Google StoreのTitan公式ページ](https://store.google.com/jp/product/titan_security_key?hl=ja)は、USB-C、NFC、専用Secure Element、Google設計のファームウェア、FIDOの公開標準、Advanced Protection Program対応を案内しています。2023年に導入された現行世代は250を超えるパスキーを保存できるとGoogleが説明しています。 Googleアカウント、Workspace、Cloudを中心に使い、GoogleのAdvanced Protectionを含む運用を確認したい人の候補です。ただしTitanはGoogle専用ではなく、対応する他サービスでもFIDOキーとして利用できます。逆に、Titanという製品名だけで対象取引所やパスワード管理サービスの対応が保証されるわけではありません。 GoogleのサポートはUSB・NFCに必要なOSとブラウザーの条件、日本を含む販売地域を示しています。NFC対応電話でも、OS、ブラウザー、サービスの実装、PIN要求によって挙動が変わります。iPhoneとiPadでもNFC条件が同じとは限らないため、端末名だけで互換と判断しません。 今回、現行USB-C・NFCモデルの利用者向けファームウェア更新経路や、パスキーを個別管理する専用Titanアプリケーションは確認できませんでした。「非対応」ではなく、OSやブラウザーの標準管理画面を含め、購入後の実機確認へ残す項目です。 ## Token2 PIN+ Release3.3 TypeC：容量とPIN方針を明示する候補 [Token2 PIN+ Release3.3 TypeC公式ページ](https://www.token2.com/shop/product/t2f2-pin-release3-typec)は、USB-C、NFC、FIDO2.1、U2F、FIDO2 Level 2、300個のパスキー、6桁以上のPINという複雑性要件、静電容量式タッチを案内しています。TOTP、HOTP、PIV、OpenPGPも同じキーに含みます。 多くの発見可能な認証情報を保存したい、組織でPINの最低要件をそろえたい、FIDO以外のプロトコルも一つのキーへ集約したい場合の候補です。ただし機能が多いからといって、FIDOログインの安全性が自動的に高くなるわけではありません。 特にTOTPはFIDO2とは別の共有秘密方式です。Token2自身も、TOTPとHOTPはフィッシング耐性がFIDO2と同じではなく、従来方式との互換性を保つための機能と説明しています。FIDO非対応サービスへTOTPを使う場合は、FIDOで守られていると混同しないでください。 PIN+のファームウェアについては、ソースコードの公開範囲と第三者監査の対象範囲が示されています。提供元のFAQでは端末のファームウェアを更新できず、変更は新しい製品バージョンで提供すると説明しています。リリース番号、型番、認証、在庫が同じ製品を指しているか照合してから購入します。 ## FEITIAN ePass FIDO-NFC K40：K40とファームウェアを識別する候補 [FEITIAN ePass FIDO-NFC公式ストア](https://www.ftsafe.com/store/product/epass-fido-nfc-security-key/)は、K9BをUSB-A、K40をUSB-Cとして選択でき、NFC、FIDO2、U2F、OTP、Secure Elementを案内しています。現行製品一覧ではK40のCTAP2.1、COS、FIDO、OTPの各バージョンとAAGUIDが掲載されています。 同じePass FIDO-NFC名でも外装とファームウェア世代があるため、「FEITIAN対応」だけでまとめず、K40、USB-C、AAGUID、ファームウェアを確認します。古い製品ガイドと現行CTAP2.1一覧を混ぜないことが重要です。 FEITIAN SK ManagerはFIDO2 PIN、認証情報一覧・個別削除、FIDO2初期化を案内しています。初期化は認証情報、PIN、対応モデルの指紋を削除します。選定したK40には生体認証センサーがなく、タッチは利用者の操作確認です。 FEITIANの一般FAQはFIDO2認証情報を128個保存できると説明していますが、今回のK40製品ページではモデル固有容量を確認できませんでした。そのため比較表へ128を確定値として転記せず「未確認」としています。購入判断に容量が必要なら、型番とファームウェアを添えて公式サポートへ確認します。 ## タッチ・PIN・生体認証は別の証拠 4製品のタッチ部分は、操作している人がその場にいることを示す利用者の操作確認です。指紋で本人を照合する生体認証センサーではありません。 FIDO2の利用者確認は、セキュリティキー内のPINや生体認証で実行されます。サービスは`userVerification`を`required`、`preferred`、`discouraged`から選べるため、同じキーでも毎回PINを求めるとは限りません。 | 状態 | 分かること | 分からないこと | | --- | --- | --- | | タッチ・UP | 物理的な操作があった | 登録者本人か | | PIN・UV | 認証器がローカル検証を完了した | アカウント復旧やセッションが安全か | | 生体認証・UV | 対応キーがローカルの生体認証を完了した | 生体認証画像がサービスへ送られたこと。通常その意味ではない | | NFC | 認証器との通信方式 | FIDOバージョン、PIN、UV、サービスの対応状況 | PINの誤入力上限や初期化条件は、実機とファームウェアで確認します。PINを忘れたときにパスキーを書き出して救出できるとは考えず、予備キーとサービス側の復旧経路を先に用意します。 ## セキュリティキー・端末側パスキー・TOTP・ハードウェアウォレットを分ける | 手段 | 主に守る対象 | フィッシング耐性の中心 | バックアップと復旧 | | --- | --- | --- | --- | | セキュリティキー上のFIDO2パスキー | ウェブやアプリのアカウントへのログイン | RP ID、オリジン、チャレンジ、公開鍵署名 | キー内パスキーは通常バックアップされない。別キーを個別登録 | | 電話やパスワード管理サービスの端末側パスキー | ウェブやアプリのアカウントへのログイン | WebAuthnと端末のロック解除 | プロバイダーやOSにより同期・バックアップ・端末との紐付け方が異なる | | TOTP | ウェブやアプリの第二要素 | 時間で変わる共有秘密コード | シードまたはプロバイダーの復旧。偽サイトへコードを入力できる | | ハードウェアウォレット | ブロックチェーン秘密情報とチェーン上署名 | 鍵をホストから分離し端末画面で署名内容を確認 | 復旧フレーズ、分割片、パスフレーズ等。セキュリティキーとは別 | パスキーのチャレンジ、オリジン、RP ID、UP、UV、バックアップフラグをコントラクトアカウントへつなぐ実装は[パスキースマートアカウントのWebAuthn検証](/archives/6016)で扱っています。セキュリティキーを暗号資産取引所のログインへ使うことと、ウォレットのチェーン上署名鍵にすることも別です。後者を選ぶ場合は[EVM向けハードウェアウォレット5機種の比較](/archives/6034)と[ハードウェアウォレット初日の安全設定](/archives/6035)へ進んでください。 ## 紛失前に普段使うキー・予備キー・復旧を試す 復旧手順はブランドではなく、認証情報を登録したサービスごとに成立させます。 ### 1. 普段使うキーと予備キーを別々に登録する 同じアカウントへ2本以上のセキュリティキーを登録できるかを確認し、表示名には保管場所が分かる識別子を付けます。普段使うキーのパスキーを予備キーへコピーするのではなく、各サービスで予備キーを別の認証情報として登録します。 ### 2. 予備キーを別の場所へ保管する 普段使うキーと同じキーリングやバッグに付けると、同時に紛失します。予備キーは火災、盗難、水害、移動、組織の退職・休職を考え、権限のある人だけが取り出せる別の場所へ保管します。チームでは、個人の私物キーだけに管理者アカウントを依存させません。 ### 3. 復旧コードと代替認証手段を確認する サービスが発行する復旧コードはセキュリティキーの認証情報を復元するコードではなく、別経路でアカウントへ戻る手段です。正規ドメイン以外へ入力せず、普段使うキー・予備キーと同じ場所へ置きません。SMS、メール、サポート復旧を残す場合は、その経路が新しい弱点になることも含めて判断します。 ### 4. ロックアウトを避けながら紛失時の手順を試す 普段使うキーを接続せず予備キーでログインできること、登録済みキーの一覧で識別できること、紛失したキーを削除できること、復旧コードの再発行で旧コードが失効することを、サービスの公式手順で確認します。削除や再発行を試す場合は検証用のキーとアカウントを使い、普段のアカウントをロックアウトさせる試験は行いません。 ## 購入前確認項目 - [ ] 対象サービスがFIDO2パスキーまたはFIDO U2Fを公式にサポートしている - [ ] パスワードなしと第二要素のどちらで登録するか決めた - [ ] USB-CとNFC、OS、ブラウザー、サービスの組み合わせを確認した - [ ] 必要なパスキー数が製品容量内に収まる - [ ] PIN忘れ・誤入力・初期化で消える範囲を理解した - [ ] 普段使うキーとは別の予備キーを同じアカウントへ登録できる - [ ] 復旧コード、代替認証手段、アカウント復旧の保管と失効手順がある - [ ] 公式ストア、端子の種類、型番、ファームウェア、在庫、配送地域、税・送料、保証を購入日に確認した - [ ] FIDO以外のTOTP、PIV、OpenPGP機能を必要性なしに有効化していない - [ ] セキュリティキーをハードウェアウォレットやシードバックアップと混同していない ## 未実機確認と再検証 物理端末を確保した場合は、個人アカウントではなく検証専用のWebAuthnサーバーとテスト用アカウントを使い、4製品へ同じ登録、認証、オリジン不一致、PIN、認証情報管理、USB-C、NFC、初期化、予備キー、復旧の手順を適用します。 現時点では4製品とも実機確認は未実施です。製品写真、端末UI、PIN画面、認証情報ID、復旧コード、生体認証データを生成画像で代用せず、実機結果を装った評価点も作りません。 モデル、価格、在庫、配送地域、ファームウェア、認証、OSとブラウザーの対応状況は変わるため、2026-12-01までに再確認します。この記事は公式仕様から候補と復旧設計を絞る比較であり、実機で互換性・耐久性・初期化時の挙動を確認した順位ではありません。 この記事にアフィリエイトリンク、スポンサー、レビュー用貸与品、販売誘導はありません。将来商用リンクを置く場合も広告であることを明示し、通常の公式リンクを残し、販売手数料をセキュリティ評価や掲載順へ含めません。 ## 確認した一次情報 - [W3C Web Authentication Level 3](): 確認日 2026-09-02 - [FIDO Alliance passkeys](): 確認日 2026-09-02 - [Yubico Security Key C NFC official product page](): 確認日 2026-09-02 - [Yubico firmware and credential storage](): 確認日 2026-09-02 - [Yubico FIDO2 credential and reset management](): 確認日 2026-09-02 - [Google Titan Security Key Japan store](): 確認日 2026-09-02 - [Google Titan passkey capacity announcement](): 確認日 2026-09-02 - [Google Titan platform and regional availability](): 確認日 2026-09-02 - [Google Chrome passkey storage and recovery guidance](): 確認日 2026-09-02 - [Token2 PIN+ Release3.3 TypeC official product page](): 確認日 2026-09-02 - [Token2 FIDO2 security key FAQ](): 確認日 2026-09-02 - [Token2 certifications and audit scope](): 確認日 2026-09-02 - [FEITIAN ePass FIDO-NFC K9B/K40 official product page](): 確認日 2026-09-02 - [FEITIAN current CTAP and firmware list](): 確認日 2026-09-02 - [FEITIAN credential and reset manager](): 確認日 2026-09-02 - [FEITIAN FIDO key FAQ](): 確認日 2026-09-02 --- # 直コンとは？verified contract・ABI・simulationを安全に確認 直コンでコントラクトを操作する前に、chain・公式address・verified source・proxy・ABI・approve/revoke・simulation・receiptを確認する順番を解説します。 正規URL: https://3mikan.com/archives/1005 著者: みかん 公開: 2021-05-24T08:59:27.000Z 更新: 2026-08-30T14:25:00.000Z 「直コン」は、dappの画面を経由せず、Block ExplorerのRead / Write画面やコードからコントラクト関数を直接呼ぶことです。画面が省かれるだけで、コントラクトの権限、停止条件、残高、期限、手数料を回避できるわけではありません。 この記事では、**接続や署名より先に、読む・照合する・simulationする**順番を扱います。Ethereum mainnetのCircle USDCを公開画面の例に使いますが、特定トークンの取得や操作を勧めるものではありません。掲載画面ではwallet接続、入力、署名、transaction送信を行っていません。 > verifiedは安全証明ではない > > `Source Code Verified`は、公開されたsourceとcompiler設定からon-chain bytecodeを再現できたことを示します。公式プロジェクト、安全、監査済み、変更不能を意味しません。 ![公式addressの照合からABI、Read、simulation、署名確認、receipt確認へ進む直コンの安全確認フロー](/diagrams/contract-safety/1005-safe-flow.svg) ## 最初に確認する6項目 Explorerで関数名を探す前に、次の6項目を一つのメモへ固定します。 | 項目 | 確認する内容 | 間違えたときの影響 | | --- | --- | --- | | chain | Ethereum、Arbitrum、Baseなど対象network | 同じ形式のaddressでも別のcontractを参照する | | address | project公式docsとExplorerのaddressが一致するか | 偽物や別versionを操作する | | verification | exact matchか、similar matchか、未検証か | source・ABIを誤って信用する | | proxy | proxyか、現在のimplementationとadminは何か | 表示sourceと実行codeを取り違える | | call | function、引数、native tokenの`value` | 別の権限・数量・送付を実行する | | account | 読み取り対象、署名account、nonce | 別walletのstateでsimulationする | トークンaddressは検索結果やSNS投稿だけで決めません。たとえばCircleは[chain別のUSDC contract address](https://developers.circle.com/stablecoins/usdc-contract-addresses)を公式docsで公開しています。Explorerのlabelは補助情報として使い、chainとaddressはproject側の一次情報でも照合します。 ## verified contractで分かること [Etherscanの説明](https://docs.etherscan.io/contract-verification/whats-contract-verification)では、contract verificationはデプロイ済みcontractのsource codeを公開・照合する仕組みです。`Exact Match`なら、source、compiler version、optimizerなどの設定が対象bytecodeと一致しています。
EtherscanのContractタブにSource Code Verified、Exact Match、Proxy、implementationが表示されたUSDC公開画面
2026年8月28日のEtherscan公開画面。Ethereum mainnetのUSDC proxyをログアウト状態で確認。verificationは安全性の証明ではありません。
2026-08-28にEthereum mainnetのUSDC公開ページを確認した時点では、次の表示がありました。 - `Source Code Verified`と`Exact Match` - contract name `FiatTokenProxy` - `Proxy`と現在のimplementation address - `Read as Proxy`、`Write as Proxy`、`Past Implementations` これは「このaddressにあるproxyのcodeを読める」という証拠です。Etherscan自身も、source verifiedは安全に操作できるという意味ではないと説明しています。監査の有無、owner権限、停止機能、upgrade権限、経済設計は別に確認します。 Exact / Similar表示をさらに追試する場合は、[compiler・constructor・library・metadataからverified sourceを再buildする手順](/archives/6033)で、creationとruntime、immutable、proxy先を分けて確認できます。 ### proxyならimplementationも追う proxyはstateを保持したまま、別のimplementationへ処理を委譲できます。[OpenZeppelinの解説](https://docs.openzeppelin.com/upgrades-plugins/proxies)にあるように、upgrade可能な構成ではimplementationが後から変わる場合があります。 確認時は次を記録します。 1. 操作先のproxy address 2. 現在のimplementation address 3. implementationのverification状態とABI 4. upgradeを実行できるadmin、owner、governance 5. 確認日時とchain Etherscanの`Read as Proxy` / `Write as Proxy`は、検出したimplementationのABIをproxy addressに対して使うための表示です。表示されたcodeが将来も同じとは限らないので、署名前にもう一度確認します。 ## Read Contractから始める Readは通常`eth_call`で実行され、stateを変えず、transactionも送信しません。wallet接続が不要な読み取りは、書き込み条件を把握する入口になります。
EtherscanのRead as Proxyにallowance、balanceOf、decimalsなどの読み取り関数が並ぶUSDC公開画面
Read as Proxyの公開画面。walletを接続せず、allowance、balanceOf、decimalsなどの関数名を確認しました。
ERC-20なら、少なくとも次の値を確認します。 | Read | 入力 | 分かること | | --- | --- | --- | | `balanceOf(account)` | 対象account | contractが認識するtoken残高 | | `allowance(owner, spender)` | ownerとspender | spenderが使える上限 | | `decimals()` | なし | raw amountを人が読む桁へ直す基準 | | `paused()`など | contractごと | 書き込み停止状態。ただし関数がない場合もある | | role / owner系 | contractごと | 特定functionを実行できる主体 | Readが成功しても、同名のWriteが成功するとは限りません。Writeでは`msg.sender`、残高、allowance、期限、role、現在blockのstateが追加条件になります。 ## ABIとfunction selectorを照合する ABIは、function名、引数の型、返り値、eventを機械が読むためのinterfaceです。Explorerの入力欄を見ただけで判断せず、現在のimplementationに対応するABIでcalldataをencode / decodeします。 たとえばERC-20の`approve(address,uint256)`は、先頭4 bytesのfunction selectorが`0x095ea7b3`です。しかしselectorだけでは、対象chain、contract address、spender、amountが正しいとは分かりません。 calldataとevent logsの読み方は[ABI・function selector・calldata・event logsを手で読む方法](/archives/6005)で、固定した例と一緒に確認できます。 proxyの場合は結合ABIだけで終わらせず、[ERC-1967のimplementation・admin・beacon slotからupgrade履歴まで読む方法](/archives/6020)で、raw storage、call path、authority、storage layoutを分けて確認できます。 ## Write Contractを開いても、すぐ接続しない `Write as Proxy`にはstateを変えるfunctionが並びます。公開画面を読むだけなら、walletを接続する必要はありません。
EtherscanのWrite as Proxyにapproveのspenderとvalue、その他の書き込み関数が並ぶUSDC公開画面
Write as Proxyの公開画面。approveのspenderとvalueを観察し、wallet接続、入力、署名、transaction送信は行っていません。
署名画面へ進む前に、予定するcallを次の形で書き出します。 ```text chain = Ethereum mainnet to = proxy address function = approve(address,uint256) arguments = spender, amount value = 0 ETH account = owner address ABI source = current verified implementation ``` `to`はtokenの移転先とは限りません。approveの場合、transactionの`to`はtoken contractで、引数の`spender`が利用権限を渡す相手です。この2つを混同すると、意図しないcontractへ権限を残します。 ## approve・allowance・revokeを分けて考える ![ERC-20のowner、token contract、spenderとallowanceの関係を示す図](/diagrams/contract-safety/1005-approval-triangle.svg) [ERC-20](https://eips.ethereum.org/EIPS/eip-20)では、`approve(spender, value)`がspenderの利用上限を設定し、`allowance(owner, spender)`で現在値を読み取ります。 - owner: tokenを持ち、承認を出すaccount - spender: ownerに代わって`transferFrom`できるaddress - amount: tokenの最小単位で表した上限 - token contract: allowanceを保存するcontract 「サイトとの接続解除」と「allowanceの取消」は別です。allowanceは変更されるまでon-chainに残ります。 MetaMaskの`Spending cap request`でtoken・spender・amount・chainを照合し、PortfolioやExplorerからrevoke後のallowanceを確認する手順は、[MetaMaskのSpending cap・approve・revokeを安全に確認する方法](/archives/6007)で詳しく説明しています。 ### revokeの確認順 1. `allowance(owner, spender)`で現在値と正確なspenderを読む 2. tokenが標準的なERC-20動作か、特殊な制約がないか確認する 3. walletの承認管理画面、またはverified contractの`approve(spender, 0)`を候補にする 4. chain、token、spender、0の桁をsimulationする 5. 署名後はreceiptの成功と、更新後のallowanceが0かを再度読む `approve(spender, 0)`は一般的なERC-20でallowanceを0へ更新する方法ですが、token固有の実装やproxy変更があるため万能な手順ではありません。[MetaMask Portfolioのspending caps](https://support.metamask.io/manage-crypto/portfolio/spending-caps-portfolio)からrevokeする場合も、on-chain transactionなのでnetwork feeが必要です。 また、`permit`などの署名でallowanceを作るcontractもあります。「gasが表示されない署名だから安全」と判断せず、typed dataのdomain、chainId、verifying contract、spender、value、deadlineを読みます。 ## simulationでrevertと入力を先に確認する [viemの`simulateContract`](https://viem.sh/docs/contract/simulateContract)は、`eth_call`を使ってcontract callを検証し、stateを変更せずにresultやrevertを確認します。 ```ts const { request, result } = await publicClient.simulateContract({ address: tokenAddress, abi: erc20Abi, functionName: 'approve', args: [spender, amount], account: owner, }) // ここでは送信しない。 // request.address / functionName / args / accountを別途照合する。 ``` 変数は、先に固定したchain、official address、current ABI、owner、spender、amountから作ります。simulation後は次を確認します。 - 実行したRPCのchainId - `request.address`と予定した`to` - calldataをdecodeしたfunction名と引数 - native tokenを送る場合の`value` - resultまたはrevert reason / custom error - simulationに使ったaccountとblock時点 ### simulation成功は安全や本番成功の保証ではない simulationと実transactionの間に、price、balance、allowance、nonce、deadline、paused状態、proxy implementationが変わることがあります。simulationは「その時点・そのaccount・その入力で再現した結果」であり、悪意あるcontractを安全に変えるものでもありません。 gas estimationやrevertの切り分けは[estimateGasが失敗する理由とsimulationの確認順](/archives/6003)、custom errorは[revert dataをデコードする方法](/archives/6002)も参照してください。 ## walletの署名画面で最後に止まる 署名要求が出たら、Explorerやdappで見た内容をwallet側でも照合します。 1. network / chainId 2. signing account 3. transactionの`to` 4. functionと引数のデコード表示 5. token、spender、spending cap 6. native tokenの`value`とnetwork fee 7. warningやsimulation結果 walletが内容をdecodeできず、blind signingに近い表示になるなら、先へ進まずcalldataを別のdecoderで確認します。急ぐ理由、限定キャンペーン、supportを名乗るDMは、確認項目を省略する理由になりません。 ## 送信後はreceiptと最終stateを確認する transaction hashが表示されても、成功とは限りません。receiptを取得し、少なくとも次を残します。 ```ts const receipt = await publicClient.getTransactionReceipt({ hash }) console.log({ status: receipt.status, blockNumber: receipt.blockNumber, transactionHash: receipt.transactionHash, logs: receipt.logs, }) ``` - `receipt.status` - chain、block number、transaction hash - transactionの`to`とinput calldata - 発行元addressを含むevent logs - approveなら`Approval` eventと更新後の`allowance` - transferやwithdrawなら、関係する残高の更新 eventが見えただけで全体成功を断定しません。別contractが同名eventを出す場合や、期待したstateが更新されていない場合があります。[receipt・calldata・logsを追う確認順](/archives/6001)で、失敗transactionを含む見方を確認できます。 ## よくある失敗を切り分ける | 症状 | 最初に確認すること | それでも分からないとき | | --- | --- | --- | | sourceが未検証 | official address、bytecode、projectの公開repo | ABIを推測して書き込まない | | exact matchではなくsimilar | 対象addressのruntime bytecode | 別contractのsourceを根拠にしない | | Readは成功、Writeはrevert | account、role、balance、allowance、paused、deadline | revert data / custom errorをdecodeする | | simulation成功後に失敗 | state、nonce、deadline、gas、implementationの変化 | 同じblock条件との差分を記録する | | 関数名は同じだが結果が違う | current implementationとABI | proxy upgrade履歴とadmin eventを見る | | revokeしたのに残る | token、owner、spender、receipt.status | pending / failed tx、別spender、permitを確認する | | 数量が大きすぎる・小さすぎる | `decimals()`とraw units | 表示値だけで再送しない | ## サイトが消えても、資金回収を保証できない front-endが停止していても、verified contractのRead / Writeから状態を確認できる場合はあります。しかし直コンはcontractの条件を迂回しません。 - withdraw functionがない、または対象accountに権利がない - contractがpausedされている - owner / adminがimplementationや権限を変更した - tokenやLPに流動性・価値がない - blacklist、deadline、lock、feeなどの条件がある - 悪意あるcallしか残っていない このような場合、Explorerから直接呼んでも資金を取り戻せるとは限りません。追加approveや不明な署名を止め、official address、transaction hash、receipt、allowance、proxy履歴を保存して状況を整理します。 ## 最終チェックリスト - [ ] chainとofficial addressを一次情報で照合した - [ ] exact match / similar / unverifiedを区別した - [ ] proxy、current implementation、upgrade権限を確認した - [ ] Readでbalance、allowance、decimals、必要条件を確認した - [ ] ABIでfunction、args、selector、valueを照合した - [ ] approveならowner、token、spender、amountを分けて記録した - [ ] 同じaccount・chain・入力でsimulationした - [ ] simulation成功を安全保証として扱っていない - [ ] wallet画面のto、function、args、spending capを再確認した - [ ] 送信後にreceipt.status、logs、最終stateを確認した 直コンで大切なのは、早く送ることではありません。**addressからreceiptまで、同じcallを説明できる状態にしてから判断すること**です。 ## 確認した一次情報 - [Etherscan What’s Contract Verification](): 確認日 2026-08-28 - [Etherscan Explore a Contract Address](): 確認日 2026-08-28 - [Etherscan Contract Code tab](): 確認日 2026-08-28 - [Etherscan Proxy Contract](): 確認日 2026-08-28 - [viem simulateContract](): 確認日 2026-08-28 - [ERC-20 Token Standard](): 確認日 2026-08-28 - [OpenZeppelin Proxy Upgrade Pattern](): 確認日 2026-08-28 - [MetaMask Spending Caps](): 確認日 2026-08-28 - [Circle USDC Contract Addresses](): 確認日 2026-08-28 --- # Binance JapanでUSDTを買える？日本円・P2P旧手順の現在 旧Binance GlobalのUSDT購入、P2P、銀行振込、カード、LINE Pay手順を現在使えない理由と、Binance Japanの取扱暗号資産・日本円入出金を確認する順番を整理します。 正規URL: https://3mikan.com/archives/152 著者: みかん 公開: 2021-01-30T05:00:13.000Z 更新: 2026-08-30T02:45:00.000Z このURLでは以前、旧Binance GlobalのP2P画面でUSDTを選び、銀行振込、card、LINE Pay等で相手方へ支払う手順を案内していました。**その画面と手順を現在のBinance Japanで使う記事ではありません。** 2026年8月30日に確認したBinance Japanの公式取扱暗号資産一覧には、`USDT`は掲載されていません。service一覧には日本円の入出金、現物、販売所等はありますが、P2Pとcard購入は列挙されていません。これはBinance Japanの当日一覧にないという意味であり、GlobalでUSDTが存在しないという意味ではありません。 > **現在の結論** > > 2026年8月30日時点の公式一覧からは、Binance JapanでUSDTをP2P、銀行振込、card、LINE Payにより購入できるとは確認できません。**USDTという名称、支払手段、日本円入金を別々に確認し、一つでも一覧にない場合は旧手順へ進まない**でください。 この記事の確認では、口座開設、本人確認、P2P相手との連絡、送金、card入力、暗号資産の購入・交換・送付を行っていません。別地域のBinance、VPN、第三者仲介、非公式なP2Pへ誘導しません。 ## 旧記事から撤去した内容 - 紹介code付きの新規登録URL - P2PでUSDTを選択する旧画面 - 銀行振込、credit card、LINE Payを支払方法に絞る手順 - 相手方とのchat、支払完了通知、資金walletから現物walletへの振替 - 当時のseller名、rate、上限、本人確認画面 - USDTを旧SavingsやBNB Vaultへ回して年利を得る提案 P2Pでは、暗号資産の移転と相手方への法定通貨支払が別の状態で進みます。古い画面や過去の成功例を使うと、提供主体、相手方、支払先、asset、release条件を誤るおそれがあります。 ## 3つの一覧を順番に確認する ### 1. Binance Japanの取扱暗号資産 公式の「Binance Japanにて提供される暗号資産及びサービスについて」で、asset名とtickerを検索します。2026年8月30日の確認時点ではUSDTを確認できませんでした。 金融庁の2026年8月21日時点登録一覧にあるBinance Japanの取扱暗号資産欄にも、USDTは掲載されていません。どちらの一覧も更新され得るため、この記事の日付ではなく当日の最新版を確認してください。 ### 2. 目的のservice assetが一覧にあっても、現物、販売所、入出庫、貸し暗号資産等のすべてで利用できるとは限りません。Binance Japan公式一覧は、assetごとに利用できるserviceが異なると注記しています。 2026年8月30日時点のservice一覧はP2Pとcard購入を列挙していません。Global版のmenu、Academy、検索結果にP2Pやcardが表示されても、日本向け提供の根拠にしません。 ### 3. 日本円の入出金 「日本円を入金できること」と「USDTを買えること」は別です。日本円入金が利用できても、その先で対象asset / pairが提供されていなければ目的の取引はできません。 銀行側の振込fee、名義、反映status、出金先等も別に確認します。第三者が指定した個人口座へ振り込むことを、Binance Japanへの公式入金とみなさないでください。 ## USDTが必要だと思ったときに確認すること USDTは米ドルそのものでも、日本円預金でもありません。別のserviceやprotocolで`USDT`と表示されても、chain、contract、入出庫、利用資格が一致するとは限りません。 3MIKANは、USDTを得るための代替取引所、海外account、個人間取引、bridge、wallet swapをこのページで推奨しません。目的のserviceが本当にUSDTだけを受け付けるのか、法定通貨やBinance Japanの別assetで代替できるのかは、そのserviceの公式条件を確認してください。 | 確認項目 | 記録する内容 | | --- | --- | | 目的 | なぜUSDTが必要なのか、受取先service名 | | 提供主体 | 契約する法人、居住地条件、規約URL | | asset | ticker、正式名称、contractが必要ならaddress | | network | 送付元と送付先で完全一致するchain | | 費用 | 購入、交換、入出庫、network fee | | 停止条件 | 一覧不掲載、入出庫停止、network不一致、最小額未満 | ## phishingとP2P詐欺を避ける 旧記事の支払方法や画面を検索すると、偽support、偽seller、画面共有を求める相手へ誘導される可能性があります。 - SNSやchatで指定された口座へ送金しない - payment完了、release、返金を急がせる連絡に従わない - password、認証code、本人確認書類、画面共有を第三者へ渡さない - 「日本からP2Pを使えるようにする」とするVPNや居住地変更を使わない - 送金後の追加支払で解除できるという説明を信用しない ## 現物注文を確認する場合 Binance Japanの公式一覧にあるassetを日本円等で売買する場合も、販売所と取引所は別です。pair、売買方向、注文種別、数量、price、fee、statusは[Binance Japanの現物注文](/archives/2603)で確認してください。 ## 最終checklist - [ ] Binance Japanの最新取扱暗号資産一覧でUSDTを検索した - [ ] 金融庁の最新一覧でもBinance Japanの取扱assetを確認した - [ ] 日本円入金、USDT取扱、P2P、card購入を別々に確認した - [ ] Global版のmenuや古いP2P画面を日本向け提供の根拠にしていない - [ ] 紹介code、旧seller、旧rate、旧支払方法を使っていない - [ ] 代替経路の居住地、法人、asset、networkを想像で補っていない - [ ] 個人口座への振込や第三者chatを公式supportとみなしていない - [ ] 不一致があれば資金を送らず、公式一覧へ戻る 将来USDTが公式一覧へ追加された場合も、掲載だけで購入方法を決めず、対象service、pair、入出庫network、fee、最小額、accountの確定前表示を同じ日に確認してください。 ## 確認した一次情報 - [Binance Japan: 提供される暗号資産及びサービス](): 確認日 2026-08-30 - [Binance Japan: 利用規約](): 確認日 2026-08-30 - [金融庁: 暗号資産交換業者登録一覧](): 確認日 2026-08-30 --- # Binance先物クイズの旧記事を今使わない理由｜日本向け提供状況 旧Binance Globalの先物クイズ、最大レバレッジ、注文画面を現在のBinance Japan手順として使えない理由と、現物・先物・証拠金を分ける確認方法を整理します。 正規URL: https://3mikan.com/archives/2066 著者: みかん 公開: 2021-08-15T18:26:33.000Z 更新: 2026-08-30T02:45:00.000Z このURLは以前、Binance Globalの先物口座を開き、先物クイズへ回答し、最大125倍のレバレッジ、cross / isolated margin、TP / SLを設定する手順を掲載していました。**現在は、その旧手順を実行するための記事ではありません。** 2026年8月30日に確認したBinance Japanの公式商品一覧には、現物取引、販売所、貸し暗号資産、Launchpool等はありますが、futures（先物）とmargin取引は列挙されていません。同一覧は、記載以外のBinance.comのserviceはBinance Japanで提供されないと説明しています。 > **旧先物クイズ、旧画面、旧倍率を使わないでください** > > Global向け技術資料や画面が現在も公開されていても、日本向けserviceの提供根拠にはなりません。**Globalの機能が見えることと、Binance Japanで利用できることは別**です。 この記事は提供範囲と旧記録を確認するもので、先物口座の開設、クイズ回答、注文、position操作、入出金、本人確認は行っていません。居住地制限を回避する方法や、別地域のplatformへ移る方法も案内しません。 ## 旧記事と現在を分ける | 旧記事の内容 | 2026年8月30日時点の扱い | 理由 | | --- | --- | --- | | 先物クイズの設問と正解 | 現行手順から撤去 | 設問、規約、商品、UIを現在のBinance Japanで確認できない | | 最大125倍、後に20倍へ変更 | 撤去 | Globalの時期・利用者・pair別の旧値で、日本向け提供の根拠ではない | | cross / isolated margin | 歴史用語としてのみ説明 | 担保範囲と清算riskを伴い、現物口座とは別 | | long / short、TP / SL | 操作手順を撤去 | positionを作る誘導になり、日本向け商品一覧に先物がない | | 紹介code、fee割引 | 削除 | 現行条件と無関係な登録・取引促進 | | 旧UI画像 | 削除 | Globalのaccount画面を現在の日本向けUIと誤認させる | ## 現物・margin・futuresは同じものではない | 区分 | 基本的な取引対象 | 主な追加risk | Binance Japan一覧での確認 | | --- | --- | --- | --- | | 現物 | 保有するassetの売買 | 価格変動、未約定、slippage | 現物取引として掲載 | | margin | 借りたassetを含む売買 | 利息、担保不足、強制清算、負債 | 掲載を確認できない | | futures | 将来価格を参照するderivative position | leverage、資金調達料、強制清算、mark price | 掲載を確認できない | 現物の「売る」は、原則として保有するassetを売却する操作です。借りたassetを先に売るshortや、derivativeのshort positionとは契約とriskが異なります。現物注文の確認は[Binance Japanの現物注文](/archives/2603)へ分けています。 ## 先物クイズがあってもriskを消せない 旧クイズは、leverage、清算価格、wallet残高、service障害等を確認させるものでした。しかし、クイズへ正解することは、次を保証しません。 - 損失が証拠金内に必ず収まる - 希望価格で決済できる - 急変時にも注文や清算が遅れない - feeや資金調達料が固定される - 自分のaccountが商品を利用できる - 日本の法令・規約上の利用条件を満たす leverageを上げるほど、小さな価格変動が証拠金に対して大きく作用します。cross marginでは複数positionや残高が同じ担保範囲へ影響し、isolated marginでも指定した証拠金を失う可能性があります。これは旧用語の説明であり、利用を勧めるものではありません。 ## 旧記事を見つけたときの確認順 1. URLのlocale、footer、運営法人、規約を確認する 2. Binance Japanの現行商品一覧に目的の商品があるか確認する 3. Global向けhelpやAPI資料を日本向け可否の証拠にしない 4. 古い倍率、quiz、button名、fee、bonusを現在値として使わない 5. accountに見慣れないpositionや残高がある場合は、新規注文せずread-onlyで履歴を確認する 6. 公式supportへ連絡するときは、日時、product名、position / order ID、statusを保存する password、二段階認証code、API secret、seed phraseをsupportや第三者へ渡してはいけません。「日本から先物を継続する方法」等をうたうSNS、紹介link、VPN案内からloginしないでください。 ## 空売りの旧記事との関係 このページは旧futures全体とquizの訂正記録です。旧marginでassetを借りてshortする手順は、[Binanceの空売り旧手順を今使わない理由](/archives/2754)で分けています。 どちらも、2026年8月30日時点のBinance Japan商品一覧に掲載されている現物取引へ読み替えることはできません。商品が将来追加・変更された場合も、古い手順を復活させず、その時点の製品規約、契約締結前交付書面、account表示を確認します。 ## 最終checklist - [ ] 旧記事がBinance Globalの2021〜2022年画面であると理解した - [ ] Binance Japanの現行商品一覧を当日確認した - [ ] futuresとmarginが一覧にないことを確認した - [ ] Globalのhelp、API、画面を日本向け提供の根拠にしていない - [ ] 現物売却、margin short、futures shortを分けた - [ ] 旧quizの正解やleverage倍率を現在の条件に使っていない - [ ] 紹介code、bonus、地域回避の導線を使っていない - [ ] 新規操作より先に、公式規約と自分の履歴を確認する Binance Japanの提供一覧が更新された場合は、商品名が追加されたことだけで操作せず、製品規約、対象者、asset、fee、担保、清算、終了条件まで同じ日付で確認してください。 ## 確認した一次情報 - [Binance Japan: 提供される暗号資産及びサービス](): 確認日 2026-08-30 - [Binance Japan: 利用規約](): 確認日 2026-08-30 - [金融庁: 暗号資産交換業者登録一覧](): 確認日 2026-08-30 - [Binance Developer: Derivatives change log（Global技術資料）](): 確認日 2026-08-30 --- # Binance Japanとは？運営会社・金融庁登録・提供サービスを確認 Binance Japanと旧Binance Globalを分け、運営法人、金融庁登録、現行サービス、本人確認、取扱暗号資産、手数料を公式情報で確認する順番を整理します。 正規URL: https://3mikan.com/archives/2560 著者: みかん 公開: 2021-09-09T18:26:07.000Z 更新: 2026-08-30T02:45:00.000Z このURLでは以前、Binance Globalの登録、入出金、取引、言語変更を2021〜2022年の画面で案内していました。現在、日本居住者が確認する対象は、**Binance Japan株式会社が提供するBinance Japanサービス**です。旧Global画面や紹介URLを現在の手順として使わないでください。 この記事は2026年8月30日に、金融庁の登録一覧、Binance Japanの利用規約、提供商品一覧、手数料ページを確認して全面更新しました。口座開設、login、本人確認、入出金、注文、貸付、寄託は行っていません。 > **結論** > > Binanceを確認するときは、**ブランド名、運営法人、提供サービスの3つを同じ日付で確認する**ことが出発点です。Webページが開くことやGlobal版に機能があることだけでは、Binance Japanでの提供や自分の利用資格を確認したことになりません。 ## 2026年8月30日時点の現在地 | 確認項目 | 一次情報で確認できること | ここから断定しないこと | | --- | --- | --- | | 運営法人 | 日本向けWebサイトはBinance Japan株式会社が運営 | Binanceグループの全サービスを日本で使えること | | 金融庁登録 | 関東財務局長 第00031号として登録一覧に掲載 | 暗号資産の価値、安全、利益の保証 | | 利用対象 | 規約は日本居住、18歳以上、本人確認等の条件を定める | 申請すれば必ず口座が開設されること | | 商品 | 公式の「提供される暗号資産及びサービス」に9種類を掲載 | Global版の先物、margin、P2P等も提供されること | | 費用 | 現物のfee pageでlevel、Maker / Taker等を確認できる | 過去記事の固定rateが現在も適用されること | 金融庁の2026年8月21日時点の一覧には、Binance Japan株式会社、関東財務局長 第00031号、取扱暗号資産が掲載されています。ただし、同一覧は登録業者や暗号資産の価値を金融庁が保証・推奨するものではないと明記しています。 ## 旧Binance GlobalとBinance Japanを分ける Binance Japan株式会社名義の2023年発表によると、日本向けserviceは2023年8月に開始され、当時のGlobal口座利用者向けserviceは同年11月末までに段階的に終了すると案内されました。 したがって、2021〜2022年の記事にある次の情報は、現在のBinance Japan手順として再利用できません。 - Global版の登録URL、紹介code、fee割引 - 本人確認なしで利用できるという説明 - Global版のasset、wallet、入出金、言語設定画面 - futures、margin、P2P、旧Earn商品のmenu - 当時のfee、上限、最小額、取扱銘柄数 URLに`binance.com`が含まれていても、footer、利用規約、製品規約、居住地条件を確認します。検索結果や古いbookmarkから開いた画面の表示だけで判断しません。 ## Binance Japanが列挙する9つのservice Binance Japanの公式商品一覧は、2026年8月30日時点で次を列挙しています。 1. 日本円の入出金と暗号資産の入出庫 2. 暗号資産取引所（現物取引） 3. 暗号資産販売所（Convert・暗号資産売買service） 4. 貸し暗号資産 5. Launchpool（寄託暗号資産） 6. OTC取引 7. Convertの定期購入 8. Binance Pay 9. Binance Japan提供serviceに限ったAPI接続 同ページは、**上記以外のBinance.comの暗号資産・serviceはBinance Japanで提供されない**と説明しています。Global版の紹介記事やAcademyで商品名を見つけても、まずこの日本向け一覧と製品規約へ戻ってください。 | 知りたいこと | このclusterの確認先 | | --- | --- | | 現物の成行・指値・条件付き注文 | [Binance Japanの現物注文](/archives/2603) | | USDT、P2P、card購入の旧記事 | [Binance JapanでUSDTを買えるか](/archives/152) | | 旧Savings / Simple Earnと現在の貸付条件 | [Binance Japan貸し暗号資産](/archives/576) | | BNBを使うLaunchpool | [Binance Japan Launchpool](/archives/394) | | 旧futures / margin / short | [Binance先物の旧記事](/archives/2066)、[Binance空売りの旧記事](/archives/2754) | ## 口座条件と本人確認を先に読む Binance Japan利用規約は、個人利用者について18歳以上、日本居住者であること等を適格条件に定めています。また、本serviceへのアクセス前に本人確認手続へ従い、完全・正確・真実な情報を提出する必要があるとしています。 旧記事の「本人確認は任意」「一定額までは本人確認なし」という記載は撤去しました。別の居住地を申告する、VPN等で地域判定を回避する、他人名義の口座を使う方法も案内しません。 申請前には少なくとも次を確認します。 - URLを自分で開き、footerの運営法人と登録番号を見る - 利用規約の更新日、適格性、本人確認、口座制限を読む - passwordを使い回さず、多要素認証と復旧方法を確認する - 検索広告、SNSのDM、紹介codeから本人情報を送らない - 審査結果や追加資料の要求を、第三者ではなく公式画面で確認する ## assetとserviceは別々に確認する 金融庁一覧にasset名があることは、そのassetについて全serviceをいつでも使えることを意味しません。Binance Japanの公式一覧も、assetごとに利用できるserviceが異なると注記しています。 たとえば、現物pairがあるか、販売所で交換できるか、入出庫が動いているか、貸し暗号資産の募集があるかは別です。次を同じ日時で確認してください。 | gate | 確認する表示 | | ---: | --- | | 1 | 公式取扱asset一覧に名称・tickerがある | | 2 | 目的のserviceに対象asset / pairが表示される | | 3 | maintenance、申込上限、口座制限がない | | 4 | fee、spread、最小額、期間等が確定前に表示される | | 5 | 実行後に履歴、status、残高を照合できる | ## feeは「割引」ではなく一連の費用で見る 旧記事の紹介code10％割引、BNB支払25％割引、固定0.1％等は現行情報として残していません。feeはlevel、Maker / Taker、asset、pair、BNB利用、campaign等で変わり得ます。 現物取引なら、fee pageだけでなく注文確認画面と約定履歴を照合します。販売所なら、手数料表示だけでなく提示された買値と売値の差、受取数量を見ます。日本円入出金や暗号資産入出庫が伴う場合は、その費用も別に加えます。 ## 最終checklist - [ ] 金融庁の最新一覧でBinance Japan株式会社と登録番号を確認した - [ ] 登録を価値、安全、利益の保証と解釈していない - [ ] footerと利用規約がBinance Japan向けである - [ ] 年齢、居住地、本人確認等の適格条件を読んだ - [ ] 目的のassetとserviceを公式一覧で別々に確認した - [ ] Global版にあることを日本向け提供の根拠にしていない - [ ] fee、spread、最小額、上限、期間を当日の確定前表示で確認する - [ ] 紹介code、bonus、旧UI、過去の固定値を判断材料にしていない - [ ] password、認証code、本人確認書類を第三者へ共有していない 表示や規約がこの記事と異なる場合は、操作を進めず、確認日、URL、法人名、service名、asset、画面表示を記録して最新の公式情報を優先してください。 ## 確認した一次情報 - [金融庁: 暗号資産交換業者登録一覧](): 確認日 2026-08-30 - [Binance Japan: 利用規約](): 確認日 2026-08-30 - [Binance Japan: 提供される暗号資産及びサービス](): 確認日 2026-08-30 - [Binance Japan: 現物取引手数料率](): 確認日 2026-08-30 - [Binance Japan: 国内platformへの移行に関する2023年発表](): 確認日 2026-08-30 --- # Binance Japanの現物注文｜成行・指値・ストップリミットの確認 Binance Japanの現物取引で、販売所と取引所、売買方向、成行・指値・ストップリミット、trigger、未約定、一部約定、feeを注文前後に確認する方法を整理します。 正規URL: https://3mikan.com/archives/2603 著者: みかん 公開: 2021-09-10T13:53:58.000Z 更新: 2026-08-30T02:45:00.000Z Binance Japanの公式商品一覧には、暗号資産取引所（現物取引）と暗号資産販売所が別々に掲載されています。注文前に、どちらを開いているかを確認してください。 この記事は2026年8月30日に、Binance Japanの商品一覧、利用規約、現物fee pageと、Binance公式Spot APIの注文定義を確認して全面更新しました。login、入金、注文送信、取消、売買は行っていません。 > **注文送信は約定ではありません** > > 現物注文では、**pair、売買方向、注文種別、数量、価格、fee、statusを一組で確認**します。特にstop-limitは、triggerした後にlimit注文が出る仕組みであり、triggerしても約定しない場合があります。 ## 販売所と取引所を分ける | 項目 | 販売所 | 取引所（現物） | | --- | --- | --- | | 価格 | 事業者が買値・売値を提示 | order book上の注文で決まる | | 主な入力 | 支払額または受取数量 | pair、side、type、price、quantity等 | | 費用確認 | 提示価格、spread、受取数量 | Maker / Taker fee、約定価格、数量 | | 注文後 | 取引履歴と残高 | open order、一部約定、約定、取消、fee | 同じassetでも、販売所と取引所では価格の決まり方が違います。「手数料無料」という表示だけで比較せず、最終的な支払額と受取数量を確認します。 ## 注文前の7項目 | 項目 | 確認する内容 | 主な間違い | | ---: | --- | --- | | 1. pair | base asset / quote asset | BTC/JPYとBTC/別assetを混同する | | 2. side | BUY / SELL | 保有assetと売買方向を逆にする | | 3. type | MARKET / LIMIT / 条件付き注文 | 名前だけで執行方法を決めつける | | 4. quantity | base数量またはquote金額 | 入力欄の単位を見落とす | | 5. price | limit price | 桁、小数点、最小刻みを誤る | | 6. trigger | stop price等 | triggerを約定価格だと思う | | 7. cost | fee、見込総額、受取見込 | 旧rateや紹介割引を使う | assetやpairごとに最小数量、価格刻み、利用できる注文種別が異なる場合があります。この記事の例ではなく、自分の注文画面に表示される単位と取引parameterを優先してください。 ## 成行注文：価格より執行を優先する Binance公式Spot API資料は、MARKET注文を利用可能な最良価格から約定させる注文として定義しています。order bookの一つの価格で全数量が約定する保証はありません。 注文数量が大きい、または流動性が薄い場合、複数価格で約定して平均価格が画面で見た直近値からずれることがあります。これがslippageです。 成行注文前には次を確認します。 - BUYかSELLか - asset数量を入れる欄か、支払金額を入れる欄か - order bookの厚さと見込受取数量 - feeを含む見込総額 - 価格急変時に許容できる差か ## 指値注文：価格を指定するが約定は保証されない LIMIT注文は、指定価格またはそれより有利な価格での売買を試みます。条件に合う相手注文がなければopen orderとして残り、一部だけ約定する場合もあります。 たとえば買い指値では、入力した価格以下で買える可能性がありますが、市場価格がそこまで下がらなければ約定しません。売り指値では逆に、指定価格以上を待ちます。 送信後は「残高が減った／増えた」だけで判断せず、open order、executed quantity、average price、fee、statusを確認します。取消を選んでも、取消処理前に一部が約定している場合があります。 ## stop-limit：triggerとlimit priceを分ける 旧`/archives/2289`にあった逆指値の固有内容は、このページへ統合しました。 Binance公式Spot API資料では、STOP_LOSS_LIMITは条件が満たされたときにLIMIT注文を出す注文種別です。画面上の名称や提供可否は変わり得るため、Binance Japanの当日の現物画面にそのtypeが表示される場合だけ、製品規約とparameterを確認します。 | 値 | 役割 | | --- | --- | | trigger / stop price | 条件を判定し、limit注文を有効化する基準 | | limit price | 有効化後にorder bookへ出す指値 | | quantity | 売買を試みるasset数量 | **trigger到達 = 約定完了ではありません。** 値動きが速くlimit priceを通過した場合、注文は未約定または一部約定で残ることがあります。損失を一定額に固定する機能、指定価格で必ず売れる機能と解釈しないでください。 ## 注文statusを分けて読む | statusの例 | 意味 | 次に確認すること | | --- | --- | --- | | submitted / new | serviceが注文を受け付けた | open orderのpair、side、type、price、quantity | | partially filled | 一部だけ約定 | 約定数量、残数量、平均価格、fee | | filled | 全数量が約定 | 約定履歴、受取asset、残高、fee | | canceled | 未約定残が取消された | 取消前の一部約定がないか | | rejected / expired | 注文が成立しなかった | 理由、parameter、残高、取引rule | 画面の日本語表記が異なる場合は、statusの文字列を記録し、公式helpかsupportで意味を確認します。エラー後に同じ注文を連続送信すると重複する可能性があるため、履歴を確認するまで再送しません。 ## feeは約定履歴で確定する 現物feeはMaker / Taker、account level、pair、BNB利用等で変わり得ます。旧記事の0.1％、25％割引、紹介code10％割引を現在値として使わないでください。 注文前は公式fee pageと確定前表示、注文後は約定履歴のfee assetと数量を確認します。指値を出しただけでは、最終的にMakerになるかTakerになるかを注文名だけで断定できない場合があります。 ## 最終checklist - [ ] 販売所と取引所（現物）のどちらを使うか確認した - [ ] pairのbase / quote assetを確認した - [ ] BUY / SELLと入力単位を確認した - [ ] MARKET / LIMIT / 条件付き注文の動きを区別した - [ ] stop-limitのtriggerとlimit priceを別々に確認した - [ ] triggerしても未約定になり得ると理解した - [ ] fee、spread、最小数量、価格刻みを当日の表示で確認した - [ ] 送信後にopen、一部約定、filled、canceledを分けて確認する - [ ] futures / marginの旧画面を現物注文へ読み替えていない - [ ] 紹介codeや過去の固定feeを使っていない 不明なparameterやstatusが一つでもあれば送信せず、画面、日時、pair、side、typeを記録してBinance Japanの公式情報へ戻ってください。 ## 確認した一次情報 - [Binance Japan: 提供される暗号資産及びサービス](): 確認日 2026-08-30 - [Binance Japan: 利用規約](): 確認日 2026-08-30 - [Binance Japan: 現物取引手数料率](): 確認日 2026-08-30 - [Binance Developer: Spot注文種別の定義](): 確認日 2026-08-30 --- # Binanceの空売り旧手順を今使わない理由｜日本向けMargin確認 旧Binance Globalのmargin借入・空売り・short手順を現在使えない理由を、Binance Japanの商品一覧、現物売却との違い、借入・清算・leverageリスクから整理します。 正規URL: https://3mikan.com/archives/2754 著者: みかん 公開: 2021-09-22T16:37:02.000Z 更新: 2026-08-30T02:45:00.000Z このURLでは以前、Binance Globalのmargin口座へassetを振り替え、借入、売却、買戻し、返済を行う「空売り」手順を案内していました。現在は、その旧操作を実行しないための訂正記録です。 2026年8月30日に確認したBinance Japanの商品一覧には現物取引等はありますが、**margin取引とfuturesは列挙されていません**。同一覧は、記載以外のBinance.com serviceはBinance Japanで提供されないと説明しています。 > **日本向け現物取引をshortへ読み替えない** > > 保有assetを現物で売ることと、assetを借りて先に売るmargin short、derivativeのshort positionは別です。**旧Globalの借入・返済画面をBinance Japanの手順として使わない**でください。 この記事の確認では、借入、振替、注文、position、返済、入出金を行っていません。VPN、居住地変更、別地域account等の回避策も案内しません。 ## 旧記事から撤去した内容 - cross margin / isolated marginへの旧振替画面 - assetの借入、売却、買戻し、返済button - 最大3倍・10倍・125倍等の旧leverage値 - 「追証がないから借金の心配がない」という断定 - 「下落相場でも利益」「初心者は先物がおすすめ」という促進 - 当時の借入rate、fee、最小数量 - 紹介code、登録CTA、旧account画像 「追証なし」という表示があっても、強制清算、fee、利息、slippage、急変、system遅延による損失が消えるわけではありません。損失範囲を旧記事の一文から判断しないでください。 ## 現物売却・margin short・futures shortの違い | 区分 | 開始時に行うこと | 終了時に必要なこと | 主なrisk | | --- | --- | --- | --- | | 現物売却 | 保有assetを売る | 必要なら後で買い直す | 価格変動、未約定、slippage | | margin short | assetを借りて売る | 買い戻して元本・利息を返す | 借入rate、担保不足、清算、負債 | | futures short | derivativeのshort positionを持つ | positionをcloseする | leverage、funding、mark price、清算 | 現物注文の成行・指値・条件付き注文は[Binance Japanの現物注文](/archives/2603)で確認します。これはshortの代替戦略を勧めるものではありません。 ## margin shortの仕組みを歴史として読む 旧Globalのmargin shortでは、一般に次の状態がありました。 1. collateralをmargin accountへ移す 2. 売りたいassetを借りる 3. 借りたassetを売る 4. 後で同assetを買い戻す 5. 借入元本と利息を返す 価格が下がれば買戻し価格との差が生じ得ますが、逆に価格が上がると損失は拡大します。売値を下限0までと考えた利益余地に対し、価格上昇の上限は決まっていません。 さらに、借入利息は時間とasset条件で変わり、collateral ratioが基準を下回れば強制清算される場合があります。注文が未約定でも利息や市場riskが続く可能性があります。 これは仕組みの説明であり、2026年のBinance Japanで実行できるという案内ではありません。 ## crossとisolatedを旧値で判断しない cross marginは複数position・assetで担保範囲を共有し、isolated marginは特定pair等へ担保範囲を分ける設計を指す場合があります。 名称だけで損失上限、清算順、他残高への影響を断定できません。product、jurisdiction、規約、risk engineによって条件が変わるため、旧Global画面の「3x」「10x」を現在値にしません。 ## Globalの技術資料が残っていても日本向けではない BinanceのDeveloper siteにはderivativesのchange logやAPI資料があります。これらはGlobal productの技術情報であり、Binance Japanでの提供、個人accountの利用資格、日本向け契約条件を示しません。 | evidence | 確認できること | 確認できないこと | | --- | --- | --- | | Japanの商品一覧 | 日本向けに列挙されるservice | 個別accountの利用可否、将来追加 | | Japan利用規約 | 契約、適格性、一般条件 | Global productの利用権 | | Global API / help | Global機能の技術仕様 | 日本居住者向け提供 | | 旧3MIKAN記事 | 2021年当時の記録 | 現行UI、rate、倍率、適法性 | ## 既存の旧履歴を確認する場合 古いmargin履歴がaccountに残る場合は、新規借入や注文をせずread-onlyで次を保存します。 - product名、account区分、法人・規約 - borrow / repay履歴とasset数量 - order、fill、fee、interest、liquidation履歴 - collateral、liability、availableの表示 - official noticeとsupport case 不明な負債やpositionがある場合、3MIKANは決済時刻、asset、送付先を指定しません。公式supportと、必要に応じて資格のある専門家へ確認してください。 ## 最終checklist - [ ] 旧記事がBinance Globalのmargin画面であると確認した - [ ] Binance Japanの商品一覧にmargin / futuresがないことを確認した - [ ] 現物売却、margin short、futures shortを分けた - [ ] 借入元本、利息、collateral、清算を別々に確認した - [ ] 「追証なし」を損失・負債なしと解釈していない - [ ] 旧leverage、旧rate、旧UI、紹介codeを使っていない - [ ] GlobalのAPI資料を日本向け提供の証拠にしていない - [ ] 地域制限を回避していない 将来Binance Japanの商品一覧が変わっても、旧手順を再利用せず、その時点の製品規約、契約締結前交付書面、担保・清算・fee条件を確認してください。 ## 確認した一次情報 - [Binance Japan: 提供される暗号資産及びサービス](): 確認日 2026-08-30 - [Binance Japan: 利用規約](): 確認日 2026-08-30 - [金融庁: 暗号資産交換業者登録一覧](): 確認日 2026-08-30 - [Binance Developer: Derivatives change log（Global技術資料）](): 確認日 2026-08-30 --- # BinanceのDeFiステーキング旧記事｜On-Chain Yieldsと日本向け商品の違い 旧Binance GlobalのDeFiステーキング、Global向けOn-Chain Yields、Binance Japanの貸し暗号資産を分け、契約、protocol、償還、価格変動リスクを整理します。 正規URL: https://3mikan.com/archives/2805 著者: みかん 公開: 2021-09-29T15:13:02.000Z 更新: 2026-08-30T02:45:00.000Z このURLは2021年のBinance Globalにあった「DeFiステーキング」の画面と申込手順を扱っていました。現在は、旧名称を検索した人が、Global向けOn-Chain YieldsやBinance Japanの貸し暗号資産へ誤って読み替えないための確認ページです。 2026年8月30日に確認したBinance Japanの商品一覧には「貸し暗号資産」と「Launchpool」はありますが、`DeFi Staking`と`On-Chain Yields`は列挙されていません。Globalの公式blogがOn-Chain Yieldsを説明していても、日本向け提供の根拠にはなりません。 > **同じEarn系の名称でも契約と資産の行き先は同じではありません** > > 旧名称、Globalの商品名、Binance Japanの製品規約を分けてください。**Globalで説明されるOn-Chain Yieldsと、Binance Japanの貸し暗号資産は同じ商品ではない**ため、rateや償還条件を相互に当てはめません。 この記事の確認では、貸付、寄託、wallet接続、署名、staking、protocol操作、入出金を行っていません。 ## 3つの名称を分ける | 名称 | このページでの位置付け | 2026年8月30日の日本向け確認 | | --- | --- | --- | | DeFiステーキング | 2021年の旧Binance Global記事・旧UI | 現行商品一覧に名称なし | | On-Chain Yields | Binance Globalの公式blogが説明するon-chain protocol参加商品 | 現行商品一覧に名称なし | | 貸し暗号資産 | Binance Japanの現行製品規約にある貸付・寄託service | 商品一覧と規約に掲載 | Binance Japanの利用規約は、公式商品一覧以外のBinance.comのserviceをBinance Japanで提供せず、利用する権利がないと説明しています。Global向けページが日本語表示される、menuが見える、Academy記事が読めるという理由だけで利用可能と判断しません。 ## GlobalのOn-Chain Yieldsとは Binance Globalの公式blogは、On-Chain Yieldsを、Binance accountからon-chain protocolへ参加し、token、point等のrewardを得る機会として説明しています。walletや複雑な操作をBinance側が仲介するという説明ですが、次のriskは消えません。 - 参加先protocolやvalidatorの障害、hack、smart contract不具合 - slashingやprotocol ruleによる数量減少 - lock、unstaking、queue、network混雑による償還遅延 - reward tokenや預けたassetの価格変動 - APR / APY、募集枠、reward条件の変更 - 地域、本人確認、accountごとの利用制限 この説明はGlobal商品の一般的な位置付けです。Binance Japanで利用できること、特定protocolが安全であること、元本数量や法定通貨価値が保証されることを意味しません。 ## Binance Japanの貸し暗号資産とは Binance Japanの2026年7月17日更新規約は、利用者が暗号資産をBinance Japanへ貸し付け、または寄託し、貸借料・利息としてrewardを得るserviceを定めています。 規約上、BNBは寄託対象、BNB以外は貸付対象です。貸付暗号資産は分別管理の対象ではなく、Binanceグループ事業体へ貸し付けられる場合や、on-chain stakingに使われる場合があります。 つまり、画面上のrateだけでなく、次を同時に読みます。 | 確認項目 | 貸し暗号資産規約で読むこと | | --- | --- | | 法的関係 | 貸付か寄託か | | 管理 | 分別管理の対象か、混蔵保管され得るか | | 運用 | group貸付、staking等に使われる可能性 | | 期間 | 定期期間、満了日、自動申込 | | reward | rate、計算開始、分配頻度、変動・固定の別 | | 償還 | 満期返還、早期償還の可否、返還までの時間 | | failure | group破綻、slashing、hack、network停止、返還不能のrisk | 詳細は[Binance Japan貸し暗号資産の確認guide](/archives/576)へ分けています。 ## 「staking」と書かれていても同じではない stakingは、PoS networkの検証にassetを使う行為を指す場合があります。一方、利用者とBinance Japanの契約は、規約上の貸付または寄託です。その先でBinance側がstakingを行う可能性があっても、利用者が自分のwalletから直接protocolへdelegationした契約と同じではありません。 | 質問 | 確認できない場合の判断 | | --- | --- | | 誰と契約するか | 申込まない | | assetの所有・管理関係は何か | 申込まない | | どのprotocol / validatorへ使われるか | 不明riskとして扱う | | いつ、何が返るか | 申込まない | | early redemptionは権利か裁量か | 規約の表現を優先する | | reward rateは固定か変動か | offer条件を確認する | ## 旧UIと固定rateを撤去した理由 旧記事は、2021年のasset、APY、期間、申込button、wallet画面を掲載していました。これらは募集ごとに変わり、現在の法人・地域・契約を示しません。 「高利回り」「簡単」「取引所が選定するから安全」「元本保証」といった評価も撤去しました。token数量が同じで返る条件があっても、法定通貨換算の価格下落、返還遅延、counterparty、protocolのriskは残ります。 ## 確認の順番 1. Binance Japanの公式商品一覧で名称を確認する 2. 利用規約と、その商品固有の製品規約を開く 3. Global向け資料なら日本向け可否の根拠から外す 4. 貸付・寄託・直接on-chain参加のどれかを確認する 5. asset、期間、rate、上限、償還、早期解除、failure時の扱いを記録する 6. 一つでも不明なら申込やasset移動を行わない ## 最終checklist - [ ] 旧DeFiステーキング、Global On-Chain Yields、日本向け貸し暗号資産を分けた - [ ] Global公式blogを日本向け提供の証拠にしていない - [ ] 現行のBinance Japan商品一覧と製品規約を確認した - [ ] 貸付と寄託、分別管理の違いを確認した - [ ] protocol、validator、slashing、hack、返還遅延のriskを確認した - [ ] rate、期間、募集枠、reward tokenを固定値だと思っていない - [ ] 元本数量と法定通貨価値を同じ「元本保証」と解釈していない - [ ] 旧UI、紹介link、wallet接続、地域回避を使っていない 商品名や画面が変わった場合は、似た名称へ推測で移行せず、最新の商品一覧、利用規約、製品規約、offer条件を同じ日付で確認してください。 ## 確認した一次情報 - [Binance Japan: 提供される暗号資産及びサービス](): 確認日 2026-08-30 - [Binance Japan: 貸し暗号資産規約](): 確認日 2026-08-30 - [Binance Japan: 利用規約](): 確認日 2026-08-30 - [Binance Global: On-Chain Yields Made Simple](): 確認日 2026-08-30 --- # BNB Vault旧記事を読む前に｜Binance JapanのBNB・貸し暗号資産 旧Binance GlobalのBNB Vaultを現在のBinance Japan商品へそのまま読み替えず、BNBの取扱、貸し暗号資産の寄託、Launchpool、償還リスクを確認します。 正規URL: https://3mikan.com/archives/388 著者: みかん 公開: 2021-03-20T20:22:43.000Z 更新: 2026-08-30T02:45:00.000Z このURLは以前、2021年のBinance Globalにあった`BNB Vault`を「BNBを預けると複数商品へ自動配分されるservice」として紹介していました。現在は旧Global商品の訂正記録です。 2026年8月30日に確認したBinance Japanの商品一覧にはBNB、貸し暗号資産、Launchpoolがありますが、**BNB Vaultというservice名は列挙されていません**。旧BNB Vaultを現在の貸し暗号資産やLaunchpoolと同一商品だとみなさないでください。 > **旧名称から現在の契約を推測しない** > > BNBを扱う複数の商品があっても、資産の法的関係、管理、reward、解除条件は同じとは限りません。**BNB Vaultという名前を、Binance JapanのBNB寄託へ自動的に読み替えない**ことが重要です。 この記事ではBNBの購入、貸付、寄託、Launchpool参加、wallet操作を行っていません。 ## 旧BNB Vault記事から撤去した内容 - 「自動で最も利益が大きい商品へ切り替える」という訴求 - Launchpool、Savings、DeFi staking等から複数rewardを得る旧説明 - 旧APY、asset数、申込・解除button - 毎日rewardが得られる、risk分散になるという評価 - 紹介code、fee割引、登録CTA - 2021年のGlobal wallet、Vault履歴、残高画像 これらは現在のBinance Japan規約やoffer条件を示さず、BNBの価格変動、契約相手、償還、service変更のriskを過小評価します。 ## Binance JapanでBNBについて確認できること Binance Japanの公式取扱暗号資産一覧にはBNBがあります。ただし、取扱一覧にあることは、すべてのserviceでBNBを使えることを意味しません。 貸し暗号資産規約は、BNBを「寄託貸し暗号資産」の対象として記載しています。また、BNBの寄託について、Launchpoolで取得した利息が貸し暗号資産rewardに加えて発生する場合を定めています。 | 確認対象 | 公式規約上の位置付け | 毎回確認すること | | --- | --- | --- | | BNB取扱 | Binance Japanの取扱暗号資産 | 利用できるservice、入出庫、pair | | BNB貸し暗号資産 | 寄託として規定 | offer、数量、期間、rate、解除 | | Launchpool | 別のLaunchpool規約が適用 | 対象offer、適格性、allocation、利息 | | 旧BNB Vault | 現行Japan一覧に名称なし | 旧UIを使わない | ## 「寄託」と「貸付」の違いを確認する Binance Japan貸し暗号資産規約は、BNBを寄託対象、BNB以外を貸付対象として分けています。寄託BNBはBinance Japanのcold walletで分別管理されると説明されています。 一方で、分別管理があることを価格・返還・service継続の保証へ読み替えてはいけません。規約はstaking activityで使われる可能性、極端な相場変動やnetwork・validator障害等による返還遅延、例外的状況での損失riskも説明しています。 貸付・寄託全体の確認は[Binance Japan貸し暗号資産](/archives/576)を参照してください。 ## Launchpoolは別のoffer条件を読む Launchpool規約は、対象暗号資産を貸し暗号資産serviceに寄託し、各offerの条件に基づいて利息を得る仕組みを定めています。対象asset、期間、最小・最大量、allocation、利息の付与時期はofferごとに異なります。 旧BNB Vaultの「預ければ自動参加」という説明は使いません。現行accountでBNBの貸し暗号資産とLaunchpoolがどのように関連付けられるかを、申込前のoffer条件と規約で確認します。詳細は[Binance Japan Launchpool](/archives/394)に整理しています。 ## BNBの数量が増えても損失はあり得る rewardがBNBや別assetで付与されても、法定通貨換算の価値は変動します。次の値を分けて記録してください。 - 寄託したBNB数量 - 発生・付与されたreward assetと数量 - 申込時と償還時のBNB価格 - 解除・償還までの時間 - 売買、入出庫、networkにかかるfee - 税務記録に必要な日時と時価 「BNB数量が減らない条件」と「日本円換算で損をしないこと」は同じではありません。 ## 確認の順番 1. Binance Japanの商品一覧でBNBと目的のserviceを確認する 2. 貸し暗号資産規約で寄託関係を読む 3. Launchpoolなら、そのoffer条件とLaunchpool規約を追加で読む 4. rate、期間、対象数量、解除、償還、failure時の扱いを記録する 5. BNB Vaultという旧menuや旧画面へ進まない 6. 不明な場合はBNBを移動・寄託しない ## 最終checklist - [ ] BNB Vaultが2021年の旧Global記事であると確認した - [ ] 現行Japan一覧にBNB Vaultという名称がないことを確認した - [ ] BNB取扱、BNB寄託、Launchpoolを別々に確認した - [ ] 寄託と貸付、分別管理の違いを読んだ - [ ] offerごとのrate、期間、allocation、解除条件を確認する - [ ] reward数量と法定通貨価値を分けた - [ ] 旧APY、旧UI、紹介code、自動運用の説明を使っていない - [ ] 名称が似ているだけで商品移行を断定していない Binance Japanの商品名や規約が変わった場合は、旧BNB Vaultの説明を復活させず、最新の商品一覧と製品規約を正本にしてください。 ## 確認した一次情報 - [Binance Japan: 提供される暗号資産及びサービス](): 確認日 2026-08-30 - [Binance Japan: 貸し暗号資産規約](): 確認日 2026-08-30 - [Binance Japan: Launchpool規約](): 確認日 2026-08-30 - [Binance Japan: 利用規約](): 確認日 2026-08-30 --- # Binance Liquid Swap旧記事｜現物・Convert・流動性poolの違い 旧Binance GlobalのLiquid Swapを現在のBinance Japan商品として使わず、現物取引・Convert・AMM流動性poolの違いとimpermanent loss等のリスクを整理します。 正規URL: https://3mikan.com/archives/390 著者: みかん 公開: 2021-03-26T06:14:52.000Z 更新: 2026-08-30T02:45:00.000Z このURLでは以前、2021年のBinance Globalにあった`Liquid Swap`へ2種類のassetを預け、swap feeやrewardを得る画面を案内していました。現在は旧商品の仕組みとriskを残す訂正ページです。 2026年8月30日に確認したBinance Japanの公式商品一覧には、現物取引と販売所（Convert等）はありますが、**Liquid Swapや流動性提供serviceは列挙されていません**。Global版やWeb3 walletのswap、他protocolのpoolを、Binance JapanのLiquid Swapとして扱わないでください。 > **swapと流動性提供は別です** > > asset Aをasset Bへ交換することと、2資産をpoolへ預けて市場流動性を提供することでは、保有状態とriskが異なります。**現物取引、Convert、AMM poolを同じ「swap」として扱わない**でください。 この記事ではwallet接続、token approval、署名、swap、流動性追加・削除、asset移動を行っていません。 ## 旧記事から撤去した内容 - 「年利30％超」「損をしない」「取引所運営だから安全」等の訴求 - 旧pool、APY、reward、fee、asset pair - 1 assetまたは2 assetで流動性を追加する旧画面 - share、未実現損益、解除buttonの旧UI - 紹介code、登録CTA、fee割引 rateやfee収入が表示されても、price ratioの変化、pool構成、withdraw時の数量、protocol failureを含めなければ結果を比較できません。 ## 3つの取引を分ける | 区分 | 何をするか | 注文・持分 | 主なrisk | | --- | --- | --- | --- | | 現物取引 | order bookでassetを売買 | market / limit等のorder | 未約定、一部約定、slippage、価格変動 | | Convert・販売所 | 提示rateでassetを交換 | 見積と受取数量 | spread、見積期限、価格変動 | | 流動性pool | 1〜2 assetをAMM等へ提供 | pool share / LP token等 | impermanent loss、smart contract、asset・pool risk | Binance Japanの現物注文は[現物注文の確認guide](/archives/2603)へ分けています。これはLiquid Swapの代替を勧めるものではありません。 ## 流動性poolの仕組み Binance Academyの現行解説では、AMM型poolはorder bookではなく、pool内のasset比率と数式で価格を調整します。流動性提供者はpoolの持分を表すLP token等を受け取り、取引feeの一部を得る場合があります。 しかし、預けた2 assetが同じ数量で返るとは限りません。取引によってpool比率が変わり、withdraw時はその時点の持分に応じたassetが返ります。 ### Impermanent loss 2 assetの相対価格が預入時から変わると、単に両assetをwalletで保有していた場合より、pool持分の価値が低くなることがあります。これがimpermanent lossです。 「impermanent」は損失が起きないという意味ではありません。price ratioが戻らないままwithdrawすれば差は確定し、feeやrewardが必ず上回る保証もありません。 ### 追加のrisk - pool contractのbug、hack、停止 - LP tokenの紛失・誤送付・approval悪用 - 片方のassetのdepeg、流動性低下、上場廃止 - reward tokenの価格下落や発行条件変更 - fee、slippage、gasを含めた損益計算の誤り - third-party protocolの運営主体・規約・地域制限 ## GlobalやWeb3 walletの画面を混同しない BinanceというbrandのGlobal exchange、Binance Japan、Binance Wallet、third-party dAppは、規約と提供主体が異なる場合があります。 | 画面で確認するもの | 理由 | | --- | --- | | footer / Terms | 誰と契約するか | | custody | assetを誰が管理するか | | chain / contract | どのprotocolへ接続するか | | approval / signature | 何の権限を与えるか | | pool assets | price・depeg・相関risk | | withdrawal | LP token、解除期間、受取asset | 公開pageが見えることだけで、日本居住者の利用資格やBinance Japanによる提供を判断しません。 ## 旧positionがある場合 古い履歴や残高が見える場合も、このページを操作manualにしないでください。新たな流動性追加や再承認を行わず、公式画面で次をread-only確認します。 1. service名と提供主体 2. pool / pairと自分のshare 3. 預入履歴、reward、fee、withdraw履歴 4. assetごとの受取見込数量 5. 終了・移行・回収に関する公式通知 6. support caseとtransaction hash 秘密鍵、seed phrase、認証codeをsupportへ渡さず、回収のための追加送付や未知のcontract署名を行わないでください。 ## 最終checklist - [ ] Liquid Swapが旧Binance Global記事であると確認した - [ ] Binance Japanの現行商品一覧に名称がないことを確認した - [ ] 現物、Convert、流動性poolを分けた - [ ] pool shareと預入asset数量を同じだと思っていない - [ ] impermanent loss、smart contract、depeg、LP tokenのriskを確認した - [ ] Global、Binance Japan、Wallet、third-party protocolの規約を分けた - [ ] 旧APY、旧pool、旧UI、紹介codeを使っていない - [ ] 不明なcontractへapproval・署名・asset送付をしていない 将来、類似する商品名がBinance Japanへ追加されても、旧Liquid Swapの仕組みを当てはめず、その時点の製品規約、custody、pool、withdraw条件を確認してください。 ## 確認した一次情報 - [Binance Japan: 提供される暗号資産及びサービス](): 確認日 2026-08-30 - [Binance Japan: 利用規約](): 確認日 2026-08-30 - [Binance Academy: Liquidity Pool tokenとrisk](): 確認日 2026-08-30 - [Binance Academy: Impermanent Loss](): 確認日 2026-08-30 --- # Binance Japan Launchpoolとは？BNB寄託・利息・解除条件 Binance JapanのLaunchpoolを、対象暗号資産の寄託、offer条件、allocation、利息、適格性、解除遅延、貸し暗号資産との関係から確認します。 正規URL: https://3mikan.com/archives/394 著者: みかん 公開: 2021-04-08T18:00:40.000Z 更新: 2026-08-30T02:45:00.000Z Launchpoolは、2026年8月30日時点でBinance Japanの公式商品一覧と製品規約に掲載されています。ただし、2021年の旧Binance Global画面、過去project、固定reward、旧参加手順を現在のofferへ使うことはできません。 Binance JapanのLaunchpool規約では、指定された暗号資産を貸し暗号資産serviceへ寄託し、各offerの条件に基づく利息を得るserviceとして定められています。 > **offerごとに条件を読み直す** > > Launchpoolというservice名だけでは、対象asset、期間、allocation、利息、適格性、解除を確定できません。**利用規約、貸し暗号資産規約、Launchpool規約、個別offer条件の4つを一組で確認**してください。 この記事の確認では、BNB購入、貸し暗号資産申込、寄託、Launchpool参加、解除、取引を行っていません。 ## 仕組みを4段階で確認する 1. Binance JapanがLaunchpool offerを提示する 2. 利用者が指定された対象暗号資産を貸し暗号資産serviceへ寄託する 3. 寄託数量・期間とpool全体に占める割合等からallocationが計算される 4. offer条件と規約に基づいて利息が現物口座へ付与される 規約は、project tokenを利息計算の参照となるdigital assetとして定義し、利用者は原則として寄託した対象暗号資産と同種の暗号資産を利息として得ると説明しています。Global版の「新tokenをそのまま受け取る」という旧説明を日本向け規約へ当てはめません。 ## 確認する4文書 | 文書 | 主に確認すること | | --- | --- | | Binance Japan利用規約 | account、適格性、一般risk、fee、制限 | | 貸し暗号資産規約 | 寄託関係、管理、reward、償還、failure時の扱い | | Launchpool規約 | service定義、利息、allocation、解除遅延 | | 個別offer条件 | 対象asset、期間、上限、参照project、具体的な条件 | 一つのpageだけを読んで「預ければ自動で新tokenがもらえる」「元本はいつでも戻る」と判断しないでください。 ## 対象assetとBNBの関係 貸し暗号資産規約は、BNBを寄託貸し暗号資産の対象とし、Launchpoolで取得した利息が貸し暗号資産rewardに加えて発生する場合を定めています。 ただし、すべてのBNB保有、すべての貸し暗号資産申込、すべての期間が自動的に対象になるとは限りません。個別offerで対象、開始・終了、snapshotや計算条件、最小・最大数量を確認します。 旧BNB Vaultとの違いは[BNB Vault旧記事の確認](/archives/388)を、貸し暗号資産全体は[Binance Japan貸し暗号資産](/archives/576)を参照してください。 ## allocationは固定数量の約束ではない Launchpool規約は、利息量がofferごとに異なり、通常は自分の寄託額がpool総額に占める割合に基づいて計算されるとしています。 参加者やpool総額が増減すれば、自分の見込allocationも変わり得ます。画面の推定値、過去projectの結果、SNSの計算を、確定rewardとして扱いません。 | 変動要因 | 確認する表示 | | --- | --- | | 自分の寄託数量 | eligible / subscribed amount | | pool総額 | offer pageのcurrent pool | | 参加期間 | 開始、終了、計算対象時間 | | rate / allocation | 推定か確定か、更新時点 | | 利息asset | 規約上の支払assetと数量 | | 付与 | 現物口座の履歴、日時、status | ## 解除できても即時とは限らない 規約は、貸し暗号資産規約に従って対象assetのlockを解除できる一方、極端な市場変動、network遅延、validator / protocol障害、多数の同時解除、予期せぬ事象等で遅延する可能性を説明しています。 また、offer期間中に対象の貸し暗号資産serviceを終了した場合、Launchpoolの利息を受け取れない場合があります。解除buttonの表示だけで、即時返還やreward確定を判断しないでください。 ## 主なrisk - 寄託したBNB等の価格変動 - rate、allocation、pool総額、offer条件の変更 - 解除・返還・利息付与の遅延 - validator、protocol、networkの障害 - account、居住地、KYC、complianceによる適格性変更 - 参照projectやreward assetの価格・流動性risk - 税務記録で寄託、利息付与、売却時価を混同するrisk 「rewardがある」ことを、法定通貨換算で利益が出る、安全である、元本が保証されるという意味にしません。 ## 旧記事から撤去した内容 - 過去projectと配布数量を現在の例として使うこと - 「眠っている通貨で無料token」「簡単に利益」とする訴求 - 旧pool、APY、参加button、wallet画面 - 紹介code、登録CTA、fee割引 - BNB VaultやSavingsへ預ければ自動参加するという一般化 ## 最終checklist - [ ] Binance Japanの現行商品一覧にLaunchpoolがあることを確認した - [ ] 4文書を同じ日付で確認した - [ ] 対象asset、期間、最小・最大数量を個別offerで確認した - [ ] 寄託数量とpool総額からallocationが変わり得ると理解した - [ ] 推定値と現物口座へ付与された利息を分けた - [ ] 解除遅延と、途中終了時の利息条件を読んだ - [ ] BNB価格、network、validator、protocolのriskを確認した - [ ] 旧Global UI、旧project、紹介codeを使っていない offer表示と規約が違う、または対象asset・利息・解除のどれかが不明な場合は寄託せず、表示日時とoffer名を保存してBinance Japanの公式supportへ確認してください。 ## 確認した一次情報 - [Binance Japan: Launchpool規約](): 確認日 2026-08-30 - [Binance Japan: 貸し暗号資産規約](): 確認日 2026-08-30 - [Binance Japan: 提供される暗号資産及びサービス](): 確認日 2026-08-30 - [Binance Japan: 利用規約](): 確認日 2026-08-30 --- # Binance Japan貸し暗号資産とは？期間・償還・分別管理リスク 旧Savings・Simple Earnと現在のBinance Japan貸し暗号資産を分け、貸付・寄託、期間、報酬率、早期償還、分別管理、返還不能リスクを規約から確認します。 正規URL: https://3mikan.com/archives/576 著者: みかん 公開: 2021-04-20T12:26:32.000Z 更新: 2026-08-30T02:45:00.000Z このURLでは以前、Binance Globalの「Flexible Savings」「Locked Savings」を、いつでも解除できる運用や自動複利として案内していました。現在は、Binance Japanの**貸し暗号資産規約**を正本にする確認ページです。 Binance Japanのfooterは貸し暗号資産を「旧Simple Earn」と表記していますが、2026年7月17日更新の製品規約は、serviceを定期貸し暗号資産として定めています。旧Flexible Savings、旧Locked Savings、Global Simple Earnの条件を現在の日本向け商品へ当てはめないでください。 > **預金ではありません** > > Binance Japanの規約は、貸し暗号資産が預金または預金類似商品ではなく、預金保険の対象でもないと説明しています。**報酬率より先に、貸付か寄託か、分別管理、期間、償還、返還不能時の扱いを確認**してください。 この記事の確認では、申込、貸付、寄託、償還、asset移動を行っていません。 ## 2026年8月30日時点の要点 | 項目 | 規約で確認できること | 注意点 | | --- | --- | --- | | service | 定期貸し暗号資産 | 旧Flexible Savingsの条件を使わない | | BNB | 寄託貸し暗号資産 | 寄託条件とLaunchpool条件を分ける | | BNB以外 | 貸付貸し暗号資産 | 分別管理・優先弁済の対象ではない | | reward | rate、期間、分配頻度をofferで確認 | rateは変更され得る。複利とは限らない | | 満期 | 原則、期間満了後72時間以内に現物口座へ返還 | 自動申込や例外条件を確認する | | 早期償還 | Binance Japanが裁量で認める場合がある | 利用者の権利ではなく、reward控除や遅延があり得る | | failure | group破綻、slashing、hack、network停止等 | 一部または全部を失う可能性がある | ## 貸付と寄託を分ける ### BNB以外：貸付 規約は、BNB以外を貸付貸し暗号資産としています。貸付assetは他のassetと分けて管理されず、Binance group事業体やその顧客のassetと混蔵保管される場合があります。 また、Binance Japanの裁量でgroup事業体へ貸し付けられたり、on-chain stakingに使われたりする場合があります。貸付先の破綻やslashing等で返還を受けられず、Binance Japanの返還能力へ影響する可能性が規約に示されています。 ### BNB：寄託 規約はBNBを寄託貸し暗号資産とし、Binance Japanのcold walletで分別管理すると説明しています。BNBはstaking活動に使われる場合があり、Launchpoolの利息が追加で発生する場合もあります。 分別管理を、BNBの価格、reward、即時償還、service継続の保証と解釈しないでください。旧BNB Vaultとの違いは[BNB Vault旧記事の確認](/archives/388)に整理しています。 ## 申込前にoffer条件を記録する 貸し暗号資産の募集はasset・時期ごとに変わります。次を一枚の表へ記録してください。 | field | 記録する内容 | | --- | --- | | asset | 正式名称、ticker、数量 | | relation | 貸付 / 寄託 | | term | 開始日、満了日、日数 | | rate | 固定 / 変動、年率表示、適用開始時点 | | distribution | reward asset、計算開始、分配頻度 | | limits | 最小・最大数量、申込上限 | | redemption | 満期返還、早期償還、返還先、所要時間 | | renewal | 自動申込の有無、停止期限 | | failure | 遅延、強制償還、asset喪失時の条項 | 規約は、rewardが申込翌日から発生し、毎日計算される一方、定期貸し暗号資産では複利計算されないと定めています。旧記事の「自動更新すれば自動複利」という説明を現在の一般条件として使いません。 ## 早期償還はいつでも自由とは限らない 旧Flexible Savings記事は「いつでも解除」を利点としていました。しかし、現行規約は定期貸し暗号資産について、原則として期間満了まで償還できないとしています。 Binance Japanが早期償還を裁量で認める場合もありますが、利用者に早期償還の権利があるとはされていません。認められた場合も、既に分配されたrewardと同数量が返還assetから控除され、通常72時間以内の返還予定が遅延する場合があります。 「早期償還buttonが見える」「過去にすぐ返った」という事実を、次回も同じ条件で返る保証にしないでください。 ## 同じ数量が返っても価格損失はあり得る 暗号資産建てで同じ数量が返る条件と、日本円換算で元本を維持することは別です。期間中にasset価格が下がれば、rewardを含めても法定通貨換算で損失になる可能性があります。 さらに、売却時のspread / fee、入出庫fee、税務上の時価評価も結果へ影響します。旧記事のAPYだけで「効率よく利益を得られる」と判断しません。 ## Launchpoolとの関係 BNB寄託ではLaunchpoolが関係する場合がありますが、貸し暗号資産規約だけでofferの対象、allocation、利息を確定できません。[Binance Japan Launchpool](/archives/394)で、offer条件とLaunchpool規約を追加確認してください。 ## 最終checklist - [ ] 旧Savings / Global Simple Earnと現在のJapan規約を分けた - [ ] 預金・預金保険対象・元本保証ではないと理解した - [ ] 貸付か寄託かを確認した - [ ] 分別管理と優先弁済の対象を確認した - [ ] term、rate、分配、上限、自動申込をofferで確認した - [ ] 早期償還が権利か裁量かを読んだ - [ ] reward控除、72時間、返還遅延の条件を確認した - [ ] group破綻、slashing、hack、network停止のriskを確認した - [ ] asset数量と日本円価値を分けた - [ ] 旧APY、旧UI、紹介codeを使っていない offer画面と規約が異なる場合は申込を止め、日付、asset、数量、term、rate、償還条件を保存してBinance Japanの公式supportへ確認してください。 ## 確認した一次情報 - [Binance Japan: 貸し暗号資産規約](): 確認日 2026-08-30 - [Binance Japan: 提供される暗号資産及びサービス](): 確認日 2026-08-30 - [Binance Japan: 利用規約](): 確認日 2026-08-30 - [Binance Japan: Launchpool規約](): 確認日 2026-08-30 --- # BTCCへ送付できる？事業者・Travel Rule・networkの確認手順 BTCCへの暗号資産送付を検討する前に、提供主体と金融庁登録、bitFlyerの送付先list、終了したDMM Bitcoin・LINE BITMAX、通貨・network・address・Tag / Memo・最小入金額・反映状況を一次情報で確認する順番を整理します。 正規URL: https://3mikan.com/archives/4865 著者: みかん 公開: 2022-04-04T13:20:04.000Z 更新: 2026-08-30T01:55:00.000Z BTCCへ暗号資産を送付できるかは、wallet addressをコピーするだけでは決まりません。事業者と居住地の条件、送付元の送付先list、暗号資産、network、address、Tag / Memo、最小入金額が同時に合う必要があります。 2026年8月30日に公式情報を確認したところ、旧記事で扱っていた3つの経路は、そのまま再利用できません。 - bitFlyerは事前審査済みの「暗号資産送付先list」にある取引所・金融機関だけへ送付でき、確認日時点のlistにBTCCはありません - DMM Bitcoinは2025年3月8日にserviceを終了しました - LINE BITMAXは2026年6月1日にserviceを終了しました > この記事は実送付の代行や個別の利用可否を判断するものではありません。公式情報が一つでも確認できない、両画面の表示が一致しない、送付先事業者を正しく選べない場合は、addressを登録せず送付を止めてください。 ## 結論：2022年の3経路は現在の送付手順ではない | 旧記事の送付元 | 2026年8月30日時点の公式情報 | この記事での判断 | | --- | --- | --- | | bitFlyer | 2025年7月30日から、事前審査済みの送付先listにある取引所・金融機関だけへ送付可能。公開中のlistにBTCCの掲載を確認できない | BTCCが当日の公式listにない限り、bitFlyerからの直接送付は進めない | | DMM Bitcoin | 2025年3月8日にservice終了。口座と預かり資産はSBI VCトレードへ移管 | DMM Bitcoinの旧app・旧address登録画面は使わない | | LINE BITMAX | 2026年6月1日にservice終了。終了時の残高には返金・供託の案内がある | LINE BITMAXの旧出庫画面は使わない | 「以前は送れた」「古いaddressを登録済み」「画面に『その他』があるはず」という記憶は、現在の送付可否の根拠になりません。送付元を変える場合も、別の事業者の条件で最初から確認し直します。 ## BTCCの提供主体と日本向け条件を分けて確認する 2026年8月30日に表示された[BTCCの利用規約](https://www.btcc.com/ja-JP/terms)は、契約当事者を香港で設立されたBTCC Limited（Company No. 1956541）としています。規約上、serviceの利用可否は適用法、jurisdiction、本人確認、account状態などの影響を受け、提供内容や対応assetも変更され得ます。 一方、[金融庁の暗号資産交換業者登録一覧](https://www.fsa.go.jp/menkyo/menkyoj/kasoutuka.pdf)は2026年8月21日現在の27業者を掲載していますが、BTCCまたはBTCC Limitedの名称は見つかりませんでした。 ここから分かる範囲を混同しないことが重要です。 | 確認できる事実 | それだけでは確認できないこと | | --- | --- | | 日本語のWeb pageとhelpが表示される | 日本の暗号資産交換業者として登録されていること | | 規約にBTCC Limitedと記載される | 日本居住者の個別accountが現在すべてのserviceを利用できること | | 金融庁の登録一覧に名称がない | 個別行為の適法性、安全性、資産回収可能性に関する一律の結論 | | accountへログインできる | 送付元がBTCCを送付先として承認していること | [金融庁の利用者向け案内](https://www.fsa.go.jp/policy/virtual_currency/index.html)と最新の登録一覧、BTCCの規約・account通知を確認し、自分の居住地と利用目的に関する条件が確定できない場合は入金しないでください。規約pageに記載された日付は2022年6月20日であるため、表示されているだけで現行の個別条件を補完できるとは扱いません。 ## 送付前に通す7つのgate 送付元がbitFlyer以外でも、次の7項目を順番に確認します。前の項目が未確認なら、後のaddress入力へ進みません。 | gate | 送付元で確認すること | BTCC側で確認すること | 止める条件 | | ---: | --- | --- | --- | | 1. 事業者・利用条件 | 送付先の選択肢、対象国、本人・受取人情報 | 契約主体、居住地、本人確認、account制限 | 事業者を正しく選べない、利用条件が未確認 | | 2. 暗号資産 | 送付可能なasset名・ticker | 入金pageに現在表示されるasset | 名称、ticker、tokenのどれかが違う | | 3. network | 送付時に選べるchain / network | 同じassetの入金pageで選んだnetwork | 表示名やchainが一対一で一致しない | | 4. address | network選択後に登録する送付先 | 同じ画面で新しくコピーした入金address | 一文字でも違う、古い保存addressしかない | | 5. Tag / Memo | addressと一緒に登録・入力する欄 | Tag / Memo / Commentの表示と値 | 必須表示なのに欄がない、空欄、値が違う | | 6. 金額 | 送付手数料を引いた後の数量 | asset別の最小入金額 | 着金見込みが最小額未満、正確な値が不明 | | 7. 最終status | 送付確認画面のasset、network、宛先、受取人 | 入金pageの同じ4項目 | 画面を並べて再照合できない | 同じ英数字のaddress形式に見えても、networkが同じとは限りません。asset名が同じでも、別chain上のtokenや異なるcontractを送付できるとは限りません。 「少額test」も、送付先未承認、非対応network、Tag欠落、最小入金額未満を解決しません。7つのgateを通っていない経路を、少額だから安全として試さないでください。 ## BTCCの入金pageで確認する項目 [BTCCの入金方法](https://www.btcc.com/ja-JP/support-center/detail/48947536755481)は、assetを選び、次に入金networkを選び、表示されたaddressを送付元へ貼り付ける流れを案内しています。help内のUSDTとTRON（TRC20）は操作例であり、すべての送付元に使える推奨networkではありません。 ### assetとnetwork BTCCの入金pageで、その時点に表示されるassetとnetworkを確認します。送付元にも同じ組み合わせがなければ中止します。過去の記事、検索結果、SNS、以前の入金履歴にある固定listを現在の対応表として使いません。 BTCCの公式helpも、入金側と出金側でnetworkが一致しない場合は資産を失う可能性があると警告しています。似た名前や同じaddress形式ではなく、両画面のnetwork表記を一対一で照合します。 ### addressとTag / Memo [addressとTagの公式help](https://www.btcc.com/ja-JP/support-center/detail/48947790129689)では、XRPやXLMなど一部のassetでTag / Memo / Commentが必要な場合があると説明しています。必要な場合は、addressだけでなく、同じ入金pageに表示された値もセットで送付元へ登録します。 - addressとTag / Memoは手入力せず、公式画面からcopyする - copy後に先頭・末尾を含めて両画面を照合する - QR codeを使っても、asset、network、Tag / Memoを別に確認する - 送付先をcustodial serviceなのにprivate walletとして登録しない - ほかの取引所名や「その他」を代わりに選ばない addressやTagが正しく見えても、事業者の選択が誤っていればTravel Rule情報と実際の受取先が一致しません。 ### 最小入金額とfee BTCCのhelpは、最小入金額がassetごとに異なり、最新値を各assetの入金pageで確認するよう案内しています。本文に固定値を置かないのは、対応asset、network、最小額、feeが変更され得るためです。 「入金feeが0」と表示されても、送付元の出庫feeやnetwork feeまで0とは限りません。送付数量ではなく、fee控除後にBTCCへ到達する見込み数量と、当日の最小入金額を比較します。 ## bitFlyerからBTCCへは、まず送付先listで止まる [bitFlyerのTravel Rule FAQ](https://bitflyer.com/ja-jp/faq/5-28)は、2025年7月30日から、bitFlyerが事前審査した「暗号資産送付先list」にある取引所・金融機関だけへ送付できると説明しています。「その他」を選び、listにない事業者名を自由入力する旧手順ではありません。 2026年8月30日に[bitFlyerが公開する送付先list](https://bitflyer.com/ja-jp/FAQ/send_bitcoin)の3画像を確認した範囲では、BTCCは掲載されていませんでした。このlistは更新され得るため、将来の可否も固定しません。 確認時は次の順番です。 1. bitFlyerの当日の公式送付先listを開く 2. BTCCまたは規約上の提供主体を正確に探す 3. 掲載がなければ、address登録や数量入力へ進まない 4. 掲載が追加されていた場合も、送付可能assetのgroupとBTCC側networkを照合する 5. 最終確認画面で受取人、事業者、asset、network、address、Tag / Memoを再確認する private walletを経由して送付先listを回避する手順は案内しません。自己管理walletへの送付と、custodial serviceであるBTCCへの入金は、受取人情報と管理主体が異なります。実態と違う送付先区分を選ばないでください。 ## DMM Bitcoinからは送付できない [DMM Bitcoinの終了告知](https://bitcoin.dmm.com/useful_information/market_report/20220406)によると、serviceは2025年3月8日に終了し、口座と預かり資産はSBI VCトレードへ移管されました。[SBI VCトレードの移管案内](https://www.sbivc.co.jp/newsview/3dkw7ks3mu)も同日付の移管を案内しています。 そのため、旧DMM Bitcoin appでassetを選び、BTCCを「その他」として追加する画面は現在の送付手順ではありません。元利用者が移管後の資産を確認する場合はSBI VCトレードの現在の案内とsupportを使い、BTCCへの送付可否はSBI VCトレード側の当日の送付先条件から新しく確認します。 ## LINE BITMAXからも送付できない [LINE BITMAXの公式help](https://help2.line.me/BitMax/?contentId=20015860&lang=ja)は、serviceが2026年6月1日に終了したと案内しています。終了時に残った暗号資産は日本円へ換価して返金する案内があり、返金できなかった残高には供託手続の案内があります。 旧LINE BITMAX画面でBTCCのaddressや事業者名を入力する操作は、現在利用できる経路ではありません。旧address、QR code、画面captureを再利用せず、残高や取引報告書に関する確認はLINE BITMAXの終了後窓口へ行います。 ## 送付依頼とBTCCへの反映を分ける 送付元のbuttonを押した時点は、BTCC残高への反映完了ではありません。少なくとも次の状態を分けます。 | 状態 | 確認する証拠 | 次に確認する場所 | | --- | --- | --- | | 送付依頼を受け付けた | 送付元の受付status、受付時刻 | 送付元の履歴・support | | blockchainへ未送信 | TxIDがまだ発行されていない | 同じ依頼を繰り返さず送付元で待つ | | blockchainで処理中 | TxID、対象network、confirmation数 | 対応するblock explorer | | blockchainでconfirmed | TxIDの成功status、to address、asset、数量 | BTCCの入金記録 | | BTCCで確認中 | 入金記録のstatus、必要確認数 | BTCCの入金記録・support | | BTCC残高へ反映 | 入金成功statusと残高履歴 | 記録を保存する | [BTCCの進捗確認help](https://www.btcc.com/ja-JP/support-center/detail/48946966308633)は、入金記録で金額、status、時刻を確認でき、TxIDからblock explorerへ移動できると説明しています。blockchain上で成功していても、所定のnetwork確認数とBTCC側の確認が終わるまで、残高への反映とは分けて扱います。 ## 未反映・誤送付のときに保存する証拠 残高へ反映されないときは、追加送付で確認しようとせず、次の情報を保存します。 - 送付元serviceと受付status - asset名、ticker、送付数量、fee控除後の数量 - 選んだnetworkとchain - TxID / transaction hash - to address - 入力したTag / Memo / Comment - 送付日時と各statusを確認した日時 - 送付元履歴、block explorer、BTCC入金記録の画面capture TxIDがない場合は、まず送付元で処理状況を確認します。TxIDが成功していてBTCCに反映されない場合は、asset、network、address、Tag / Memo、最小入金額を再確認し、BTCCの公式supportへ証拠を添えて問い合わせます。 [BTCCの未反映理由](https://www.btcc.com/ja-JP/support-center/detail/48953590837785)は、network確認の遅延、異なるtoken、addressまたはnetworkの誤り、Tagの欠落、最小入金額未満などを挙げています。supportへの申請は回収保証ではなく、誤ったchainやaddressへの送付は回収できない場合があります。 seed phrase、private key、password、二段階認証codeをsupportや第三者へ渡してはいけません。「回収のために追加送付が必要」という連絡だけで資産を送らず、公式siteから辿った窓口かを確認してください。 ## 最終checklist - [ ] BTCCの契約主体、居住地条件、account制限を当日の公式情報で確認した - [ ] 金融庁の最新登録一覧と利用者向け注意を確認した - [ ] 送付元の公式送付先listにBTCCが正しく掲載されている - [ ] 別事業者やprivate walletとして登録していない - [ ] 送付元とBTCCでassetが一致している - [ ] 送付元とBTCCでnetworkが一対一で一致している - [ ] 同じBTCC入金pageからaddressと必要なTag / Memoをcopyした - [ ] fee控除後の着金見込みが当日の最小入金額以上である - [ ] 受取人、事業者、asset、network、address、Tag / Memoを最終画面で再照合した - [ ] 送付依頼、TxID、confirmation、BTCC入金記録、残高反映を別statusとして記録できる - [ ] 不一致や未確認が一つでもあれば送付を止めた BTCCへの送付で最初に用意するものはaddressではなく、その日の事業者条件と、送付元・送付先の表示がすべて一致することを示す確認表です。古い画面や過去の成功例を現在の可否へ置き換えず、条件が変わるたびに最初のgateから確認してください。 ## 確認した一次情報 - [BTCC: Terms of Service](): 確認日 2026-08-30 - [金融庁: 暗号資産交換業者登録一覧（令和8年8月21日現在）](): 確認日 2026-08-30 - [金融庁: 暗号資産の利用者のみなさまへ](): 確認日 2026-08-30 - [BTCC: BTCCへの暗号資産の入金方法](): 確認日 2026-08-30 - [BTCC: 入金アドレスとタグ（Tag）の確認方法](): 確認日 2026-08-30 - [BTCC: 入金の進捗を確認する方法](): 確認日 2026-08-30 - [BTCC: 暗号資産の入金が反映されない理由](): 確認日 2026-08-30 - [bitFlyer: 暗号資産の預入・送付](): 確認日 2026-08-30 - [bitFlyer: Travel Ruleで外部へ送付できなくなる場合](): 確認日 2026-08-30 - [bitFlyer: Travel Ruleの対応変更（2025年7月25日）](): 確認日 2026-08-30 - [DMM Bitcoin: サービス終了のお知らせ](): 確認日 2026-08-30 - [SBI VCトレード: DMM Bitcoinからの口座・預かり資産の移管](): 確認日 2026-08-30 - [LINE BITMAX: サービス終了後の案内](): 確認日 2026-08-30 --- # 暗号資産の税金はいつ発生する？売却・交換・決済と計算の確認手順 日本の個人が暗号資産の税務を確認するときに、売却・商品購入・暗号資産同士の交換・報酬取得・贈与を分け、取得価額、必要経費、評価方法、所得区分、20万円基準を国税庁の現行FAQに沿って整理します。 正規URL: https://3mikan.com/archives/2441 著者: みかん 公開: 2021-09-02T09:52:51.000Z 更新: 2026-08-30T01:10:00.000Z 暗号資産の税務では、「日本円へ換えたか」だけを見ても年間の所得を計算できません。暗号資産で商品を買ったとき、別の暗号資産へ交換したとき、stakingなどで報酬を受け取ったときにも、記録すべき取引が生じる場合があります。 この記事は、日本の個人（居住者）を主な対象に、国税庁が2025年12月26日に公表した「暗号資産等に関する税務上の取扱いについて（FAQ）」をもとに、確認順を整理します。同FAQは2025年12月1日時点の法令・通達等に基づく一般例で、この記事では2026年8月30日に公開状態を再確認しました。 > 税務上の結論は、対象年、居住地、所得区分、帳簿、他の所得、取引内容によって変わります。この記事は一般的な確認手順であり、個別の申告・節税判断をするものではありません。対象年の国税庁資料、所轄税務署、税理士へ確認してください。 ## 最初に「保有」と「取引・取得」を分ける 価格が上がったという情報だけで税務計算を始めるのではなく、その年に何をしたかを時系列で並べます。国税庁FAQの個人向け一般例では、次のような取引・取得が別々に扱われています。 | その年に起きたこと | FAQで示される一般的な確認 | 最低限残す記録 | | --- | --- | --- | | 暗号資産を日本円などへ売却 | 譲渡価額と譲渡原価等の差を計算 | 日時、資産、数量、売却価額、手数料 | | 暗号資産で商品・serviceを購入 | 支払った暗号資産を譲渡したものとして計算 | 商品価額、支払数量、支払時の円換算額 | | 暗号資産AをBへ交換 | AでBを購入したものとして、Aの譲渡を計算 | 両資産、数量、交換時価、手数料 | | mining・staking・lending等で取得 | 取得時点の時価を総収入金額へ算入する一般例 | 取得日時、数量、時価の根拠、関連費用 | | 暗号資産を贈与・低額譲渡 | 贈与者と受贈者の双方で別の税目・計算を確認 | 当事者、日時、数量、時価、対価、関係 | | hard forkで新資産を取得 | 分裂時の市場・価値の有無と、その後の売却・使用を確認 | 分裂日時、受取数量、取引相場、後の処分 | wallet間の自己移動、bridge、wrapped token、liquidity提供、airdrop、NFT、derivativesなどは、見た目が「送金」「交換」「受取」でも契約と経済実態が同じとは限りません。上の表へ無理に当てはめず、何を渡し、何を得て、どの権利が変わったかを記録します。 ## 売却代金と所得金額は同じではない [国税庁FAQ 1-1](https://www.nta.go.jp/publication/pamph/pdf/virtual_currency_faq_03.pdf)には、4 BTCを400万円で取得し、そのうち0.2 BTCを21万円で売却する架空例があります。売買手数料を考慮しないという前提では、次の計算です。 ```text 1 BTC当たりの取得価額 = 4,000,000円 ÷ 4 BTC = 1,000,000円 0.2 BTCの譲渡原価 = 1,000,000円 × 0.2 BTC = 200,000円 所得金額 = 210,000円 - 200,000円 = 10,000円 ``` この例では、受け取った21万円の全額が所得金額ではありません。実際には、選定している評価方法で1単位当たりの取得価額を求め、売却時に直接要した費用も確認します。 逆に、銀行口座へ日本円を出金していないから所得計算が不要、とも限りません。商品購入と暗号資産同士の交換は、支払った暗号資産の譲渡としてFAQに計算例があります。[暗号資産を日本円にする流れと税務記録](/archives/3809)も、銀行着金と損益認識を分けて確認してください。 ## 商品購入と暗号資産同士の交換 ### 暗号資産で商品・serviceを購入した場合 FAQ 1-2では、商品価額を支払った暗号資産の譲渡価額として扱い、譲渡原価等との差を計算しています。cardや決済serviceの表示が自動換算でも、暗号資産を使った数量、商品価額、換算時点、手数料を保存します。 ### 暗号資産AをBへ交換した場合 FAQ 1-3では、暗号資産Aで暗号資産Bを購入したものとして、Aの譲渡損益を計算します。日本円を途中で受け取らない交換でも、Bの購入価額に相当するAの譲渡価額と、Aの譲渡原価等を確認します。 円換算の根拠は、利用した交換業者の約定履歴だけで済む場合もあれば、公表相場などの追加資料が必要な場合もあります。複数service、DEX、海外取引を使う場合は、後から同じ値を再現できる出典を一緒に残します。 ## 報酬取得とhard forkを同じにしない FAQ 1-7では、mining、staking、lendingなどで暗号資産を取得した場合、取得時点の時価を総収入金額へ算入し、これらに要した費用を必要経費に算入する一般例が示されています。その後に売却・使用するときの取得価額にも関わるため、受取数量だけでなく取得時点の円換算額を保存します。 一方、FAQ 1-6のhard fork例は、分裂時点で取引相場がなく価値を有していなかったという前提です。その例では取得時点の所得は生じず、取得価額を0円として、後の売却・使用時に所得を計算します。 「無料でもらったものはすべて取得時に非課税」「airdropはすべてstakingと同じ」とは整理できません。受領条件、市場価値、対価性、事業との関係を確認し、根拠が足りない場合は個別相談へ進みます。 ## 取得価額と必要経費を分ける 暗号資産を購入したときの手数料は、FAQ 1-5の一般例では購入代価に加えて取得価額を構成します。売却時の手数料は、FAQ 2-3で必要経費の例に挙げられています。 | 支出 | 一般的な確認先 | 注意点 | | --- | --- | --- | | 暗号資産の購入代価・購入手数料 | 取得価額 | 資産の種類、数量、取得時点と対応させる | | 売却した暗号資産の譲渡原価 | 必要経費 | 総平均法または移動平均法で算出する | | 売却時に支払った手数料 | 必要経費 | 売却履歴と支払資産を対応させる | | 回線利用料など | 直接必要な部分 | 私用分と明確に区分できる金額に限る一般例 | | PCなど長期間使う資産 | 減価償却を含め確認 | 購入年に全額を計上できるとは限らない | 「暗号資産に関係した支出だから全額経費」とは限りません。所得区分が事業所得か、業務に係る雑所得か、その他雑所得かによっても確認範囲が変わります。 ## 総平均法と移動平均法を取引ごとに選び直さない 個人の暗号資産の評価方法は、暗号資産の種類ごとに総平均法または移動平均法を選定します。 - **総平均法**: 年初の繰越分と年中取得分の価額・数量をまとめ、年の平均単価を計算する - **移動平均法**: 暗号資産を取得する都度、保有分と新規取得分から平均単価を更新する 初めて暗号資産を取得した場合や、従来と異なる種類の暗号資産を取得した場合は、[所得税の暗号資産の評価方法の届出手続](https://www.nta.go.jp/taxes/tetsuzuki/shinsei/annai/shinkoku/annai/21kasou.htm)を確認します。国税庁は、取得した年分の確定申告期限までの提出を案内しており、選定の届出をしなかった場合は総平均法としています。 現在の方法を変更する場合は、別の変更承認申請が必要です。利益が小さく見える方法を取引ごと・年ごとに選び直すのではなく、届出と継続適用を確認してください。 国内交換業者の年間取引報告書を使う場合、国税庁の[暗号資産の計算書](https://www.nta.go.jp/publication/pamph/shotoku/kakuteishinkokukankei/kasoutuka/index.htm)ページは総平均法用の利用を案内しています。国外service、自己管理wallet、DEXなども含め、年間取引報告書に入らない履歴を別に集めます。 ## 「必ず雑所得」ではない FAQ 2-2では、個人の暗号資産取引による利益を原則として雑所得（その他雑所得）としています。ただし、すべての人を一律に同じ区分へ固定していません。 同FAQの2025年12月更新部分では、その年の暗号資産取引に係る収入金額が300万円を超える場合について、帳簿書類の保存があれば原則として事業所得、なければ原則として業務に係る雑所得とする考え方が示されています。ただし、帳簿があっても営利性が認められない場合などは個別判断です。 この300万円は利益額ではなく収入金額であり、超えれば自動的に事業所得になるという単独基準でもありません。暗号資産取引が事業に付随する場合も含め、事実関係と帳簿をそろえて区分を確認します。 ## 「20万円」だけで確定申告を決めない [令和7年分の確定申告案内](https://www.nta.go.jp/taxes/shiraberu/shinkoku/tokushu/shinkoku-nagare/shinkoku-nagare.htm)では、例えば次の条件を満たす給与所得者について、給与所得・退職所得以外の所得金額の合計が20万円を超えることを申告要件の一つに挙げています。 - 給与を1か所から受けている - その給与の全部が源泉徴収の対象である - 給与の年間収入など、ほかの申告要件にも該当しない 20万円は暗号資産の売却代金、銀行着金額、1回の利益の基準ではありません。暗号資産以外の所得も合計して判断します。給与を2か所以上から受ける場合、給与収入が一定額を超える場合、他の所得や申告理由がある場合は、見る条件が変わります。 [Tax Answer No.1900](https://www.nta.go.jp/taxes/shiraberu/taxanswer/shotoku/1900_qa.htm)は、20万円以下のため所得税の確定申告を要しない給与所得者でも、医療費控除などの還付申告をするなら、その所得を合わせて申告する必要があると説明しています。所得税の確定申告が不要でも、住民税など別の手続まで不要とは決めず、自治体の案内も確認してください。 学生、扶養、専業、年金、非居住者を一つの金額でまとめることもできません。対象年の所得要件、扶養する人・される人の関係、他の所得を含めて確認します。 ## 損失は所得区分を確認してから扱う FAQ 2-11では、雑所得の金額の計算上生じた損失を、給与所得など他の所得から差し引くことはできないと説明しています。 この結論を「暗号資産の損失は、どの所得区分でも何とも相殺できない」と広げないでください。まず所得区分を確認し、同じ区分内の計算、他所得との損益通算、翌年以後の扱いを、対象年の制度に沿って分けます。株式等に用意された特例を、そのまま暗号資産へ当てはめることもできません。 ## 贈与は贈与者側も確認する 旧記事では、暗号資産を贈与した人に税金はかからないと説明していました。しかし、現行FAQはそのように一律整理していません。 FAQ 2-10と4-1では、個人が暗号資産を贈与などで移転した場合、贈与者側の所得税計算で贈与時の時価を総収入金額へ算入する取扱いと、受贈者側で贈与税の課税対象となる取扱いが示されています。低額譲渡にも別の計算例があります。 相続、死因贈与、遺贈、個人間・法人への贈与では条件が分かれます。贈与時の時価、取得価額、当事者の関係をそろえ、この一般説明だけで申告額を決めないでください。 ## 年間で再計算できる記録を残す 取引履歴を「買った」「売った」だけでまとめると、交換、報酬、wallet移動、feeの支払資産を区別できません。最低限、次を年・資産ごとに保存します。 - 年初の保有数量と前年から繰り越す評価額 - 購入・取得の日時、数量、円換算額、取得理由 - 売却・交換・使用の日時、数量、円換算額 - 約定履歴、年間取引報告書、CSV、receipt - wallet間・service間の移入出とTXID - chain、contract address、Memo / Tagなど資産を識別する情報 - 取引手数料、出庫手数料、network feeと支払資産 - mining・staking・lending等の報酬日時、数量、時価の根拠 - 贈与・低額譲渡の当事者、対価、時価の根拠 - 年末数量と翌年へ引き継ぐ取得価額 serviceによって履歴をdownloadできる期間は異なります。accountを閉じる前、serviceを変更する前、年末前にexportし、同じ計算を再現できる形式で保管します。 ## 迷ったときに税務署・税理士へ持っていくもの 「暗号資産の税金はいくらですか」だけでは、前提を確認できません。相談時は、次をまとめておくと事実関係を伝えやすくなります。 - 対象年と居住地 - 給与、事業、年金など他の所得の概要 - 採用している評価方法と届出状況 - 資産別の年間集計と元データ - 特殊取引のcontract、利用規約、transaction記録 - 贈与・相続なら当事者関係、日時、数量、時価資料 - 自分で判断できない論点を一問ずつ書いたメモ 一般的な制度の質問は[国税庁の電話相談](https://www.nta.go.jp/taxes/shiraberu/sodan/denwa-sodan/)を確認できます。申告書や取引資料を見ながら相談する必要がある場合は、所轄税務署への面接相談や税理士への相談を検討してください。 ## 最終チェックリスト - [ ] 対象年と居住地を固定した - [ ] 売却、商品購入、暗号資産同士の交換を分けた - [ ] 報酬取得、hard fork、airdropを同じルールにまとめていない - [ ] 売却代金と所得金額を分けた - [ ] 資産の種類ごとに評価方法と届出状況を確認した - [ ] 取得価額、売却手数料、その他の必要経費を分けた - [ ] 所得区分を「必ず雑所得」と決めつけていない - [ ] 300万円を利益額・自動判定の基準にしていない - [ ] 20万円を全員共通・売却代金の基準にしていない - [ ] 雑所得の損失と他の所得を勝手に通算していない - [ ] 贈与者と受贈者の双方の課税関係を確認した - [ ] 対象年の国税庁資料と個別相談の要否を確認した 暗号資産の税務で先に作るものは、税率表ではなく、その年に何を取得し、何を手放し、いくらと評価し、どの記録から再現したかが分かる一覧です。その一覧をもとに所得区分と申告要否を確認し、条件が分かれる取引は一般例だけで結論を出さないようにしてください。 ## 確認した一次情報 - [国税庁: 暗号資産等に関する税務上の取扱い及び計算書（令和7年12月）](): 確認日 2026-08-30 - [国税庁: 暗号資産等に関する税務上の取扱いFAQ（令和7年12月26日）](): 確認日 2026-08-30 - [国税庁 Tax Answer No.1524: 暗号資産を使用することにより利益が生じた場合](): 確認日 2026-08-30 - [国税庁: 所得税の暗号資産の評価方法の届出手続](): 確認日 2026-08-30 - [国税庁: 令和7年分 申告が必要かなどを調べる](): 確認日 2026-08-30 - [国税庁 Tax Answer No.1900: 給与所得者で確定申告が必要な人](): 確認日 2026-08-30 - [国税庁: 国税に関する相談窓口](): 確認日 2026-08-30 --- # Rexx Exchangeカードは現在申し込める？契約主体・発行条件・費用を確認 Rexx Exchangeカードの旧申込記事を、現在の利用資格、契約主体、カード発行会社、本人確認、費用、限度額、返金・解約条件を確認するガイドへ更新します。 正規URL: https://3mikan.com/archives/101 著者: みかん 公開: 2021-01-22T08:15:57.000Z 更新: 2026-08-30T00:25:00.000Z このURLは以前、Rexx Exchangeカードの特徴、手数料、利用限度額、登録、本人確認、カード申込、発行費用の支払いまでを2021〜2022年の画面で案内していました。**現在は、旧画面を使ってカードを申し込むための記事ではありません。** 2026年8月30日時点で、Rexx Exchangeの公式Cardページ、FAQ、利用規約は公開されています。しかし、ページが表示されることと、日本居住者が現在新規申込できること、カードが発行・配送されること、入出金や決済を利用できることは別です。 > **個人情報や資金を送る前に、契約条件を確認してください** > > 旧記事の紹介者コード付きURL、メールアドレス・password入力、profile登録、KYC、申請書アップロード、郵送、発行費用の支払い手順は利用しないでください。3MIKANは登録、カード申込、本人確認書類の受け付け、資金送付の仲介を行いません。 この記事の更新では、会員登録、login、本人確認、個人情報送信、カード申込、入出金、wallet接続、署名、transaction、資産移動を行っていません。個別の契約可否、送金方法、返金、解約、法的評価も断定しません。 ## 2026年8月30日時点で確認できたこと | 確認先 | 公開情報で確認できたこと | この記事で確定しないこと | | --- | --- | --- | | 公式Cardページ | カード、申請、審査、配送、チャージ、ATM・加盟店利用、費用・限度額に関する説明が掲載されている | 説明の更新日、現在の申込受付、個別審査、発行・配送の実行可能性 | | 公式FAQ | 登録、本人確認、入出金、カード利用に関する回答が掲載されている | 日本居住者へ現在適用される条件、回答の更新日、個別アカウントの状態 | | 公式利用規約 | 最終更新日を2020年8月1日、運営主体をGLOW CO., LTD.、所在地をLao PDRと記載している | 現在のカード発行会社、提携銀行、決済事業者、資金保全の実態 | | 金融庁登録一覧 | 2026年8月21日現在の暗号資産交換業者を掲載している | カード・決済・海外サービスを含む事業全体の法的評価 | | 自分の契約前画面・公式回答 | 個別に提示された利用資格、契約相手、費用、本人確認、解約条件を確認できる可能性がある | 公開ページだけでは確認できないため、この記事では未確認 | 公式Cardページには、世界のATMや加盟店、審査、配送期間、費用、限度額などの具体的な説明が残っています。FAQにも、口座開設、本人確認、カード発行、ATM、送金に関する回答があります。 ただし、これらのページには、2026年8月30日時点で日本居住者の新規申込を受け付けていること、現在のカード発行会社・銀行・配送地域、掲載された全条件が今も適用されることを一括して確認できる更新日や契約前資料が見当たりません。古い数値を現在の確定条件として再掲しない理由はここにあります。
公開中のカードページから、契約主体、発行会社、利用資格、本人確認、費用、返金・解約、公式回答を順に確認する図
公開ページの説明だけで申込可否を決めず、自分へ提示される契約条件まで照合します。
## 旧記事から撤去した案内 以前の本文には、現在の公式フローとして案内できない内容が含まれていました。 - 紹介者コード付き`secure.rexx.exchange`登録URL - 「利用開始はこちら」「公式サイト」などの登録CTA - メールアドレス、password、profile、KYCの旧入力手順 - 本人確認書類、署名済み申請書のアップロード・郵送手順 - カード発行費用、初回deposit、年会費、再発行費用等の固定値 - ATM、決済、入出金、送金の固定手数料・限度額 - BTC・USDTチャージ、VISA加盟店、海外ATM、法定通貨送金を現在も利用できるという一般化 - 「超優秀」「信用審査がない」「利用できる店舗が多い」などの推奨 - 旧UI、カード画像、fee表、申請画面のスクリーンショット 公開ページに同様の説明が残っていても、旧記事の数値や操作画面を現在の契約条件として再利用しません。申込時に別の条件が表示される可能性、居住地や審査で利用できない可能性、ページ更新が追跡できない可能性を分けて扱います。 ## まず契約主体と規約日を確認する [公式利用規約](https://rexx.exchange/jp/terms/)は、最終更新日を**2020年8月1日**、`rexx.exchange`の運営主体を**GLOW CO., LTD.**、所在地をLao PDRと記載しています。規約は、居住地によってすべての機能を利用できない場合があることや、利用者が適用法を確認する責任を負うことも説明しています。 ここから確認できるのは、公開中の規約に記載された主体と日付です。カード申込時の契約相手、カード発行会社、提携銀行、決済network、資金の保管先が現在も同じであることまでは確認できません。 申込を検討する場合は、個人情報や資金を送る前に、契約前画面または公式からの書面回答で次を照合します。 1. 契約相手の法人名、所在地、問い合わせ先 2. 規約の版、更新日、適用開始日 3. カード発行会社、program manager、提携銀行、決済network 4. 日本居住者の申込資格、配送地域、利用制限 5. 本人確認書類と個人情報の受領者・共有先・保存条件 6. 発行、配送、維持、チャージ、決済、ATM、為替、返金に関する全費用 7. 利用限度額、保留、拒否、取消、解約、残高返還の条件 法人名や発行会社が曖昧なまま、旧記事の画面や紹介者コードを使って申込を進めないでください。 ## カードページとFAQは「現在使える証拠」とは限らない [公式Cardページ](https://rexx.exchange/jp/card/)は、カードへのチャージ、審査、配送、ATMや加盟店での利用、費用・限度額を説明しています。[FAQ](https://rexx.exchange/jp/faq/)も、登録、本人確認、カード、入出金、送金に関する回答を掲載しています。 これらは、公式ドメインで公開されている説明として確認できます。一方で、ページの公開だけでは次を確定できません。 - 日本居住者の新規申込を現在受け付けているか - 表示された会員登録からカード申込まで完了できるか - 審査主体と現在のカード発行会社はどこか - 日本へカードを配送し、ATM・加盟店利用を有効化できるか - 入金、出金、チャージ、返金が現在処理されているか - 掲載された費用・限度額・日数が現在の契約に適用されるか ページの文言と、個別の契約前表示・公式回答が異なる場合は、申込を止めて差分を確認します。検索結果、第三者記事、過去のスクリーンショットで不足情報を補わないでください。 ## 金融庁登録一覧は対象範囲を限定して読む 金融庁の[暗号資産交換業者登録一覧](https://www.fsa.go.jp/menkyo/menkyoj/kasoutuka.pdf)は、2026年8月21日現在で27業者を掲載しています。この一覧に、Rexx ExchangeまたはGLOW CO., LTD.という名称は確認できませんでした。 したがって、この記事ではRexx Exchangeを**日本の登録暗号資産交換業者として確認できたサービス**とは扱いません。ただし、一覧への不掲載だけで、カード、決済、海外でのサービス提供を含む事業全体の違法性や安全性を断定することもできません。 確認対象は、暗号資産交換、法定通貨送金、カード発行、決済、資金保管、勧誘などで異なります。個別の法律上の判断が必要な場合は、契約主体、提供地域、資金の流れ、利用目的を整理し、資格のある専門家へ確認してください。 ## 個人情報を送る前に確認する 旧記事は、メールアドレス、password、profile、本人確認書類、署名済み申請書を順に送る手順を掲載していました。現在は、その手順を案内しません。 [利用規約](https://rexx.exchange/jp/terms/)は、KYCのための書類・個人情報や、第三者への情報共有の可能性を説明しています。だからこそ、送信前に次を確認します。 - URLが公式ドメインか - 個人情報を受領する法人はどこか - 何の審査に使われるか - カード発行会社や銀行へ何が共有されるか - 保存期間、削除、訂正、問い合わせの方法 - 申込を中止した場合のデータと支払済み費用の扱い 3MIKANや個人のSNS、LINE、メールへ、登録名、password、本人確認書類、申請書、送金記録を送らないでください。 ## 費用と限度額は契約前画面で一覧化する 公式CardページとFAQには複数の費用・限度額が掲載されていますが、ページ間で説明や数字が異なる箇所があり、いつから適用されるかを一つの更新日で追跡できません。そのため、この記事では過去のfee表を現在の仕様として転載しません。 申込前には、少なくとも次を同じ通貨・同じ時点で一覧化します。 | 区分 | 確認する項目 | | --- | --- | | 初期費用 | 発行、配送、関税、初回入金、本人確認 | | 維持費用 | 年会費、口座維持、休眠、残高不足 | | 資金移動 | 入金、出金、チャージ、銀行、中継銀行、暗号資産network | | 利用費用 | 決済、海外利用、ATM、為替rate・spread、残高照会 | | 事故・終了 | PIN、再発行、紛失、chargeback、返金、解約、残高返還 | | 限度額 | 1回、1日、1か月、ATM回数、居住地・審査別制限 | 「無料」「無制限」「世界中で利用可能」といった単独の表現だけで判断せず、例外、第三者費用、為替、拒否・保留条件まで確認してください。 ## 既存利用者は読み取り確認から始める すでにアカウントやカードを持っている場合も、この記事では入出金、チャージ、決済、ATM操作を指示しません。まず、公開情報と自分の契約・履歴を分けて確認します。 - 契約相手とカード発行会社 - カードの有効状態、利用地域、失効日 - 残高、保留中の処理、未反映の入出金 - 適用された費用、為替、ATM・加盟店側の追加費用 - 返金、紛失、停止、解約、残高返還の公式手続き - 問い合わせ番号、日時、公式回答 認証情報、本人確認書類、カード番号、残高を公開せず、問い合わせは公式ドメインの窓口から行います。緊急の利用停止や不正利用の疑いがある場合は、契約書に記載されたカード発行会社・公式サポートへ直接確認してください。 ## 代理店制度とカード申込を分ける Rexx Exchangeの代理店制度については、[/archives/234](/archives/234)で旧紹介者コード、個人情報送付、固定報酬表を訂正しています。代理店ページが公開されていることは、カード申込の受付、発行、配送、入出金の可用性を証明しません。 第三者の紹介リンクや広告コードではなく、自分へ適用される契約主体、利用資格、費用、個人情報の流れを先に確認してください。 ## 参考資料 - [Rexx Exchange: Card](https://rexx.exchange/jp/card/) - [Rexx Exchange: FAQ](https://rexx.exchange/jp/faq/) - [Rexx Exchange: Terms of Service](https://rexx.exchange/jp/terms/) - [Rexx Exchange: Agents](https://rexx.exchange/affiliate/) - [金融庁: 暗号資産交換業者登録一覧](https://www.fsa.go.jp/menkyo/menkyoj/kasoutuka.pdf) 最終確認日: 2026年8月30日 ## 確認した一次情報 - [Rexx Exchange: Card](): 確認日 2026-08-30 - [Rexx Exchange: FAQ](): 確認日 2026-08-30 - [Rexx Exchange: Terms of Service](): 確認日 2026-08-30 - [Rexx Exchange: Agents](): 確認日 2026-08-30 - [金融庁: 暗号資産交換業者登録一覧（2026年8月21日現在）](): 確認日 2026-08-30 --- # Bitgetコピートレード終了前の確認｜Close-Only・自動執行・損失リスク Bitgetの旧コピートレード開始記事を、日本居住者向け終了日程と現在の確認ガイドへ更新。自動執行、価格差、スリッページ、損失、Close-Only、履歴保存を一次情報から整理します。 正規URL: https://3mikan.com/archives/3023 著者: みかん 公開: 2021-10-11T17:08:28.000Z 更新: 2026-08-29T23:51:00.000Z このURLは以前、Bitgetでコピートレードを始めるための登録、フォロー、取引設定、トレーダー申請を2021〜2022年の画面で案内していました。**現在は、コピートレードを開始するための記事ではありません。** Bitgetは2026年8月3日、日本居住者向けサービスの終了を公表しました。日本向けの日程、対象判定、公式通知は、[Bitgetの日本向けサービス終了ガイド](/archives/3076)を正本として確認してください。 > **自動執行と安全な運用は同じ意味ではありません** > > コピートレードは、参照するトレーダーの操作に連動して注文が自動で始まる仕組みです。しかし、同じ価格、数量、時刻、損益を再現する保証はありません。Bitget自身の規約、リスク開示、注文制限ガイドも、大きな損失、価格差、注文不成立、サービス制限の可能性を説明しています。 この記事の更新では、Bitgetへの登録、ログイン、本人確認、入出金、注文、コピートレード設定、wallet接続、署名、transaction、資産移動を行っていません。個別のフォロー解除、決済、出金、税務判断も指示しません。 ## 日本居住者が先に確認する日程 | 日時 | Bitget公式案内 | コピートレードでの確認 | | --- | --- | --- | | 2026年8月3日以降 | 日本居住者の新規登録を停止 | 旧登録リンク、紹介特典、開始手順を使わない | | 2026年9月17日以降 | 公式通知を受けた利用者を日本居住者と暫定判定する予定。通知がなければ原則として対象扱いしない | 通知とアカウントの判定を照合する | | 2026年11月1日 11時（GMT+9） | 対象アカウントを`Close-Only`へ制限予定 | コピートレードを含む対象機能と残存ポジションを確認する | | 2026年12月31日 11時（GMT+9） | 残存する未決済ポジションを強制決済する予定 | 価格、費用、損益、処理結果を保証しない | FAQは、2026年9月17日前後に通知を受けていなければ日本居住者として初期判定しないこと、`Close-Only`の対象例に現物、先物、P2P、Convert、Earn、カード、コピートレード、取引botなどを含むことを説明しています。通知内容や判定が実際の居住地と異なる場合は、検索結果や古い記事ではなく、最新の公式案内とサポートで確認してください。
公式通知、コピー中のポジション、未約定注文、執行差、Close-Only、履歴保存を順に確認する図
旧画面を再現する図ではありません。2026年8月30日時点で、現在の状態を確認する順番を示しています。
## 旧記事から撤去した案内 以前の本文には、現在の日本居住者へそのまま案内できない開始手順と利益訴求が含まれていました。 - 短縮URLや端末別の口座開設リンク - 体験金、紹介特典、登録を急がせる案内 - 本人確認、入金、契約口座への振替 - トレーダーのフォロー、通貨ペア、数量、比率、レバレッジの旧設定 - コピートレーダー申請、報酬、コミッション獲得の旧条件 - 古い利用者数、収益率、勝率、必要残高の固定値 - 手間をかけず安全に利益を得られるように読める推奨 これらは撤去しました。古いスクリーンショットや検索結果が表示されても、現在の利用資格、機能、価格、費用、資産保全を示す証拠にはなりません。 ## コピートレードは「同じ結果を複製する仕組み」ではありません コピートレードでは、参照するトレーダーの取引をきっかけに、自分のアカウントでも注文が自動執行されます。ただし、参照先の結果がそのまま自分の結果になるわけではありません。 BitgetのOne-Click Copy Trade User Agreementは、利用者の手動操作なしで取引が開始・終了すること、コピートレードが高い投機性を持ち、コピーへ使った金額を大きく超える損失もあり得ることを説明しています。Bitgetの注文制限ガイドは、流動性やリスク管理上の上限によって、コピー数量が制限されたり注文が成立しなかったりする場合があると説明しています。 この記事は、個別の投資助言や利益保証ではありません。 ### 約定価格と時刻がずれる 参照するトレーダーが注文した時点と、自分の注文が処理される時点には差が生じます。相場が急に動いている場合、同じ方向の取引でも約定価格が変わり、損益差が広がることがあります。 この差には、流動性、注文方式、利用できる数量、価格変動、注文の集中などが影響します。参照先の取引履歴だけを見て、自分も同じ価格で売買できたと判断しないでください。 ### 数量と損失額が一致しない 自分の残高、設定上限、リスク管理、利用できる商品により、注文数量は参照先と一致しない場合があります。注文が一部だけ実行される、実行されない、参照先とは異なるタイミングで終了する可能性もあります。 BitgetのRisk Disclosureは、暗号資産取引で大きな損失や全損が生じ得ることを案内しています。自動で動くことを、損失が制限されることや常時監視されることへ読み替えないでください。 ### 過去の勝率や収益率は将来の保証ではない 過去の成績は、その期間に決済された取引や表示条件を示す履歴です。現在残っているポジション、含み損、将来の相場、フォロワー側の執行差まで保証しません。 トレーダー一覧の順位、フォロワー数、勝率、収益率だけを根拠に「安全」「再現できる」「今後も利益になる」と判断しないでください。Bitgetのリスク開示も、過去の実績が将来の結果を示すものではないとしています。 ## 残っている状態を分けて確認する 旧記事のように「登録してフォローする」という開始手順へ進むのではなく、すでに利用している場合は、何が残っているかを分けて確認します。 ### 1. 公式通知と対象判定 まず、Bitget公式ドメインの終了案内、FAQ、自分のアカウントへ届いた通知を確認します。FAQでは、2026年9月17日前後に通知を受けていない利用者は日本居住者として初期判定しないとしています。通知内容やアカウントの判定が実際の居住地と異なる場合は、公式案内に記載された確認手続きまたはサポートで照合してください。 日程や対象機能が更新された場合は、[/archives/3076](/archives/3076)の確認日と内容を先に更新します。 ### 2. コピー中のポジションと未約定注文 コピートレードの画面では、少なくとも次を別々に確認します。 - コピー中または未決済のポジション - 未約定、部分約定、取消済みの注文 - 参照しているトレーダーと自分の注文履歴 - 手動で持ったポジション - 取引botや他の商品に残る注文・資産 「フォロー中」と表示されることと、未決済ポジションが存在することは同じではありません。反対に、フォロー状態だけを変更しても、すでに発生した注文やポジションの状態が自動的に同じ形で解消されるとは限りません。 ### 3. 自分の約定・費用・残高 参照先の成績ではなく、自分のアカウントにある約定価格、数量、手数料、資金調達料、実現損益、未実現損益、残高推移を確認します。 画面表示だけで判断せず、取引履歴や明細を保存し、後から同じ注文を照合できるようにします。問い合わせる場合も、日時、商品、注文ID、履歴の状態を整理すると確認しやすくなります。 ## `Close-Only`は希望どおりの終了を保証しない `Close-Only`は、新しいポジションを開く、既存ポジションへ追加するといった操作を制限する予定を示す言葉です。希望価格で必ず終了できる、注文が失敗しない、費用が増えない、損失が補償されるという意味ではありません。 コピートレードでは参照先とフォロワー側の状態が異なるため、通常時の説明だけで終了処理を推測しないでください。最新FAQ、アカウント内の表示、公式サポートの回答を優先します。 2026年12月31日11時（GMT+9）以降の残存ポジション強制決済予定についても、実際の約定価格、順序、費用、履歴反映、税務上の扱いをこの記事では確定できません。 ## 履歴を保存して公式サポートへ照合する 取引履歴、注文履歴、ポジション履歴、入出金履歴、手数料、残高推移、公式通知を保存します。個人情報や認証情報を第三者へ公開せず、問い合わせはBitget公式ドメインのサポート導線から行ってください。 3MIKANは個別の決済方法、注文数量、出金先、税務処理を判断しません。損益や税務の扱いは取引内容、居住地、所得区分などで変わるため、必要に応じて資格のある専門家へ確認してください。 ## 旧開始手順ではなく公式日程を正本にする 日本向けの新規登録停止、対象判定、`Close-Only`、残存ポジションの強制決済予定は、[Bitgetの日本向けサービス終了｜新規登録停止・制限日程](/archives/3076)で更新します。 このページは、古いコピートレード開始記事を検索で見つけた人が、旧画面を再実行せず、自動執行のリスクと現在の確認項目へ移るための訂正ページです。 ## 参考資料 - [Bitget: 日本居住者向けサービス終了のお知らせ](https://www.bitget.com/ja/support/articles/12560603890270) - [Bitget: 日本居住者向けサービス終了FAQ](https://www.bitget.com/support/articles/12560603890271) - [Bitget: Risk Disclosure](https://www.bitget.com/support/articles/12560603797276/) - [Bitget: One-Click Copy Trade User Agreement](https://www.bitget.com/support/articles/9104577718297/) - [Bitget: Why Your Futures Copy Trading Order May Be Limited or Not Executed](https://www.bitget.com/support/articles/12560603883269) 最終確認日: 2026年8月30日 ## 確認した一次情報 - [Bitget: 日本居住者向けサービス終了のお知らせ](): 確認日 2026-08-30 - [Bitget: 日本居住者向けサービス終了FAQ](): 確認日 2026-08-30 - [Bitget: Risk Disclosure](): 確認日 2026-08-30 - [Bitget: One-Click Copy Trade User Agreement](): 確認日 2026-08-30 - [Bitget: Why Your Futures Copy Trading Order May Be Limited or Not Executed](): 確認日 2026-08-30 --- # Bitgetの旧使い方記事を読む前に｜日本向け終了日程と確認順 Bitgetの2021年版登録・KYC・入金・先物操作ガイドを、2026年の日本居住者向けサービス終了日程を確認する記事へ更新。旧画面や紹介リンクを使わず、公式通知と自分のアカウントで確認すべき項目を整理します。 正規URL: https://3mikan.com/archives/2010 著者: みかん 公開: 2021-08-13T09:32:44.000Z 更新: 2026-08-29T11:40:00.000Z このURLは以前、Bitgetの登録、KYC、入金、口座振替、先物注文、レバレッジ、利確・損切りを2021年当時の画面で案内していました。**現在は、その旧手順を実行するための記事ではありません。** Bitgetは2026年8月3日、日本居住者向けサービスを終了すると公表しました。日本居住者の新規登録は同日以降停止されています。現在の日程と公式通知の確認は、更新済みの[Bitgetの日本向けサービス終了ガイド](/archives/3076)を正本として参照してください。 > **旧画面を見ながら操作しないでください** > > 2021〜2022年の登録、本人確認、入金、振替、注文画面は、現在の提供条件・表示・機能を保証しません。紹介リンク、ボーナス、最大レバレッジ、固定手数料などの旧記載も現行情報として扱いません。 この記事の更新では、Bitgetへの登録、ログイン、本人確認、入出金、注文、wallet接続、署名、transaction、資産移動を行っていません。個別の決済、売却、出金先、network、注文方法も指示しません。 ## 先に確認する4つの日程 | 日時 | Bitget公式案内 | このページでの扱い | | --- | --- | --- | | 2026年8月3日以降 | 日本居住者の新規登録を停止 | 旧登録リンク・紹介コードは案内しない | | 2026年9月17日以降 | 公式通知を受けた利用者を日本居住者と暫定判定する予定 | 通知の有無だけで対象外と判断しない | | 2026年11月1日 11時（GMT+9） | 対象アカウントをClose-Onlyへ制限予定 | 新規ポジションや追加取引の旧手順は案内しない | | 2026年12月31日 11時（GMT+9） | 残存ポジションを強制決済する予定 | 約定価格、費用、損益を保証しない |
旧Bitget操作記事を使わず、公式通知、対象判定、残高とポジション、記録を順に確認する図
画面の再現ではなく、2026年8月29日時点で確認すべき順序を示した図です。
## 旧記事から撤去した内容 以前の本文には、現在の日本居住者へそのまま案内できない情報が含まれていました。 - bit.ly短縮URLや紹介コード付き登録URL - 「5 USD体験金」「最大575ドル」などの期限切れボーナス訴求 - 口座開設、KYC、暗号資産入金、口座振替の旧画面手順 - 先物注文、レバレッジ、利確・損切りの操作手順 - 「コピートレードが最強」「おすすめ」といった利用促進 - 古い利用者数、ライセンス、最大レバレッジ、対応通貨の固定値 これらは削除しました。公開ページや古いスクリーンショットが残っていても、現在の利用資格、注文可否、価格、費用、資産保全を示す証拠にはなりません。 ## 既存利用者が確認する順番 ### 1. 公式通知と対象判定 まずBitget公式ドメインの終了案内、FAQ、自分のアカウントへ届いた通知を確認します。SNS投稿、古い記事、検索結果の要約より公式通知を優先してください。 2026年9月17日以降の対象判定については、[/archives/3076](/archives/3076)で日程と注意点を更新します。通知が来ていないことや画面が開くことだけを「自分は対象外」の根拠にしません。 ### 2. 残高・注文・ポジションを別々に確認 「資産がある」と「未決済ポジションがある」は別です。確認画面では少なくとも、現物残高、先物等のポジション、未約定注文、コピートレードやbot等の自動機能を分けて見ます。 旧記事のように「入金→振替→注文」という開始手順へ進むのではなく、**現在残っているものを把握するためのread-only確認**を先にします。 ### 3. 11月1日以降のClose-Onlyを確認 BitgetのFAQは、対象アカウントを2026年11月1日11時（GMT+9）からClose-Onlyへ移行する予定と説明しています。どの機能が制限されるかは最新FAQとアカウント表示で確認してください。 Close-Onlyは「必ず希望価格で決済できる」「費用が増えない」「損失が出ない」という意味ではありません。3MIKANは個別の注文判断を行いません。 ### 4. 履歴を保存して照合する 取引履歴、入出金履歴、約定履歴、手数料、残高推移など、自分の記録を保存しておくと、後から約定・税務・問い合わせ内容を照合しやすくなります。 税務上の扱いは取引内容、居住地、所得区分などで変わるため、このページでは断定しません。必要に応じて資格のある専門家へ確認してください。 ## コピートレードは「自動だから安全」ではない 旧記事ではコピートレードを強い利点として扱っていましたが、現在はそのような推奨をしません。Bitget自身のRisk Disclosureも、暗号資産取引に大きな損失可能性があることを説明しています。 自動執行では、参照するトレーダーと同じ価格・数量・タイミングになるとは限りません。サービス終了やClose-Onlyの時期には、通常時とは異なる制限も考慮する必要があります。コピートレード固有の確認は、[Bitgetコピートレード終了前の確認](/archives/3023)へ進んでください。 ## 金融庁警告とサービス終了案内を混同しない 金融庁は2023年3月31日、Bitget Limitedについて、日本居住者を相手方として無登録で暗号資産交換業を行っていたとして警告を公表しました。 この警告と、Bitgetが2026年に公表した日本居住者向けサービス終了日程は別の資料です。警告資料の存在だけで個別取引の法的評価や資産回収可否を断定せず、現在の提供状況は最新の公式通知と公的資料を分けて確認します。 ## 旧手順ではなく `/archives/3076` を正本にする 日本向けの日程、対象判定、Close-Only、残存ポジションの強制決済予定は、[Bitgetの日本向けサービス終了｜新規登録停止・制限日程](/archives/3076)で更新します。 この `/archives/2010` は「古い使い方記事を検索で見つけた人が、旧画面を実行せず現行情報へ移る」ための訂正・確認ページです。今後Bitgetの公式日程が更新された場合は、まず `/archives/3076` の確認日と内容を更新し、このページとの整合を取ります。 ## 参考資料 - [Bitget: 日本居住者向けサービス終了のお知らせ](https://www.bitget.com/ja/support/articles/12560603890270) - [Bitget: 日本居住者向けサービス終了FAQ](https://www.bitget.com/support/articles/12560603890271) - [Bitget: Risk Disclosure](https://www.bitget.com/support/articles/12560603797276/) - [金融庁: Bitget Limitedへの警告](https://www.fsa.go.jp/policy/virtual_currency02/BitgetLimited_keikokushiryo.pdf) 最終確認日: 2026年8月29日 ## 確認した一次情報 - [Bitget: 日本居住者向けサービス終了のお知らせ](): 確認日 2026-08-29 - [Bitget: 日本居住者向けサービス終了FAQ](): 確認日 2026-08-29 - [Bitget: Risk Disclosure](): 確認日 2026-08-29 - [金融庁: Bitget Limitedへの警告](): 確認日 2026-08-29 --- # Binance NFTは今も使える？2026年の仕組み・手数料・確認点 Binance NFT Marketplaceの現行公開ページ、販売形式、Verified区分、手数料、カストディ、地域・アカウント条件を2026年8月29日時点で整理します。 正規URL: https://3mikan.com/archives/3446 著者: みかん 公開: 2021-10-20T14:43:33.000Z 更新: 2026-08-29T04:30:00.000Z **2026年8月29日時点で、Binance NFTの公開Marketplaceページと公式help centerは表示できます。** 公開画面では`Verified`、`Unverified`、`Buy Now`、`Live Auction`、`Has Offers`などの区分を確認しました。そのため「Binance NFTは全面終了した」とは扱いません。 ただし、公開ページが見えることと、日本居住者や個別アカウントが本人確認、購入、販売、mint、入出庫のすべてを利用できることは別です。地域、居住国、アカウント状態、対象商品、networkごとの条件は変わり得ます。本記事は**現行サービスの確認方法**を整理し、実際の取引操作へ進む前で止めます。 > 今回の確認範囲 > > 日本からログアウト状態のChromeで、公開ページと公式資料を読み取りました。ログイン、アカウント作成、本人確認、入金、購入、入札、offer、出品、mint、withdraw、Wallet接続、署名、transaction送信は行っていません。個別アカウントでの利用可否や最終手数料は未確認です。 ## 結論：公開サービスと自分の利用条件を分けて確認する 現在の状態は、次の4つに分けると誤解しにくくなります。 | 確認層 | 2026年8月29日に確認できたこと | それだけでは分からないこと | | --- | --- | --- | | 公開Web | Marketplaceとhelp centerが表示される | 自分の居住地域・アカウントで取引できるか | | アカウント | 公式ガイドは本人確認を利用条件として案内 | 審査結果、機能制限、個別の利用可能商品 | | NFT | itemごとに販売形式、通貨、collection区分がある | 作者、著作権、将来価値が保証されるか | | blockchain | network、contract、token ID、履歴を照合できる | off-chain画像の永続性や権利まで自動保証するか | 「ページが開いたから使える」「`Verified`だから本物」「NFTを買えば画像の著作権も得る」という推論は、いずれも確認を飛ばしています。
Binanceのアカウント、Marketplace、blockchain、metadata、権利を別々に確認する5層の図
1つの画面表示から残りの層を推測せず、同じNFTを5つの層で照合する。
## 2021年の記事から何が変わったか この記事はもともと2021年の登録・購入・出品手順でした。現在も公式に残る古いhelp記事はありますが、公開日が2021年の案内を2026年の画面仕様としてそのまま使うことはできません。 | 旧記事の説明 | 現在の扱い | | --- | --- | | BUSD・ETH・BNBが一律の対応通貨 | 撤回。公開画面ではUSDTやBNBの例を確認したが、itemと確認画面の表示を優先する | | 買い方は固定価格とauctionの2種類 | 更新。現行公開画面と公式販売ガイドには固定価格、auction、offerがある | | creator royaltyは一律1% | 撤回。現行fee FAQではroyalty feeを0〜10%と案内している | | 一般利用者はmintできない | 撤回。現行help centerにはMint項目とmint feeの案内がある。ただし個別利用可否は未確認 | | listing reviewに4〜8時間かかる | 撤回。現行販売ガイドは通常約10分と案内するが、保証時間として扱わない | | 旧画面のボタン位置どおりに操作する | 廃止。表示、地域、アカウント、item条件が変わるため、現行画面と最終確認を読む | 旧記事にあった紹介URLと「手数料が安い」「お得」といった勧誘は削除しました。本記事からアカウント登録や資金移動を促すこともありません。 ## Binance NFTはカストディ型Marketplace [Binance Academyの説明](https://academy.binance.com/en/articles/custodial-vs-non-custodial-nfts-what-s-the-difference)では、Binance NFTをカストディ型Marketplaceの例に挙げています。利用者はプラットフォームのアカウントを通じて残高とNFTを管理し、必要に応じて対応networkへwithdrawする構造です。 この構造では、次の5層を別々に確認します。 1. **アカウント層**：居住国、本人確認、アカウント制限、残高 2. **Marketplace層**：item URL、販売形式、価格表示、status、collection区分 3. **blockchain層**：network、contract address、token ID、transaction履歴 4. **metadata層**：画像・動画のURI、保存先、更新可能性、表示不能時の挙動 5. **権利層**：作者の帰属、copyright、商用利用、二次利用license Marketplace内で保有表示があっても、対応network、withdraw条件、受取Walletの対応規格が一致しなければ外部へ移せない場合があります。反対にtokenをwithdrawできても、画像データや利用権が永続するとは限りません。 ## 販売形式は固定価格・auction・offerを分ける 現行の公開Marketplaceでは、少なくとも次の表示を確認できます。 | 表示 | 意味の確認点 | 決めつけてはいけないこと | | --- | --- | --- | | `Buy Now` | 表示価格で購入する固定価格形式 | 手数料込みの最終支払額、利用可能通貨 | | `Live Auction` | 期間とbidで進むauction形式 | 最高額を入れれば必ず取得できること | | `Has Offers` | holderがofferを受け取れる状態 | offerが必ず受諾されること | | `Coming soon` | 販売開始前の表示 | 開始時刻、地域条件、購入権の保証 | [公式の販売ガイド](https://www.binance.com/en/support/faq/detail/8d777e415339400e91d74047926ea1bf)には固定価格、auction、offerが案内されています。同じガイドにはauction期間やminimum bidなどの運用値もありますが、itemや時期で変わり得るため、本記事では一律の入力値として案内しません。 特に、bidやofferでは資金が一時的に拘束される場合があります。キャンセル条件、期限、返却条件、利用可能残高への反映を、実行前の現行案内で確認してください。 ## `Verified`と`Unverified`は何を示すか 現行公開画面と販売ガイドは、NFTを`Verified`と`Unverified`に分けています。これはBinance NFT内のcollection区分、review、表示、settlement条件を読む手がかりです。 しかし、`Verified`表示だけから次を保証されたとは判断できません。 - 画像を作った本人がmintしたこと - copyrightや商用利用権がtoken holderへ移ること - metadataや外部保存先が永久に維持されること - security riskや偽装が完全にないこと - 将来も価格や流動性が維持されること 同様に`Unverified`は、blockchain上にtokenが存在しないという意味ではありません。Marketplaceの区分と、chain上のidentity、作者の公表、権利文書を分けて調べます。 公式販売ガイドは、`Unverified` collectionのinitial sale proceedsに10日のclearing periodがあると案内しています。これは2026年8月29日の確認時点における運用説明であり、対象itemの最終画面と最新規約を優先してください。 ## 手数料は「1%だけ」ではない [Binance NFTのfee FAQ](https://www.binance.com/en/support/faq/detail/b0a16587e5394ce9b994d336a38dfb7f)で2026年8月29日に確認した主な値は次のとおりです。 | 手数料区分 | 公式FAQの確認時点の表示 | 確認場所 | | --- | ---: | --- | | Marketplace platform fee | 1% | 売買条件・最終確認 | | Listing fee | 0 | listing時の確認画面 | | Royalty fee | 0〜10% | item・collection条件 | | Minting fee | BNB Smart Chain: 0.005 BNB / Ethereum: 0.001 ETH | network選択と確認画面 | | Collection minting fee | BNB Smart Chain: 1 BNB / Ethereum: 0.50 ETH | collection作成時の確認画面 | | Deposit・withdraw・burnのnetwork fee | 変動 | 実行直前のnetwork fee表示 | この表は固定料金表ではありません。売買代金だけでなく、platform fee、royalty、network fee、使用通貨、為替変動を分けて合計します。公式FAQと画面が異なる場合は、操作を止めて最新資料を確認し、**最終確認画面に表示されるasset・network・数量・fee**を優先してください。 また、listing feeが0でも、mint、withdraw、再送、別networkへの移動まで無料という意味ではありません。「1%」だけで総費用を計算しないことが重要です。 ## NFTの所有とcopyrightは別 NFTを保有すると、特定のcontractとtoken IDに紐づくtokenの所有状態をchain上で確認できます。一方、画像、音楽、動画などのcopyrightや商用利用権が自動的に移るわけではありません。 [Ethereum.orgのNFT解説](https://ethereum.org/en/nft/)も、NFTのownershipと、紐づくコンテンツの権利を分けて扱っています。購入を検討する場合は、次を別資料で確認します。 - creatorまたは権利者は誰か - collectionのlicenseはどこにあり、誰が公開したか - personal use、commercial use、改変、再配布のどこまで許されるか - tokenを移転した後もlicenseが残るか - metadataとmediaがどこに保存され、変更可能か Marketplaceの説明文や画像だけで権利範囲を補完せず、license本文が見つからなければ「権利範囲は未確認」と扱います。 ## 実行前に止まって確認する6項目
地域とアカウント、network、NFT identity、費用、区分、withdraw経路を順に確認する6項目
6項目のどこかが未確認なら、資金移動や署名へ進まない。
1. **運営・地域・アカウント**：開いているdomain、利用規約、居住国、本人確認、個別制限 2. **network**：NFTが存在するchain、入出庫で選ぶnetwork、受取Walletの対応 3. **NFT identity**：collection、contract address、token ID、creatorの公式公表 4. **費用**：価格のquote asset、platform fee、royalty、network fee、最終支払額 5. **区分とsettlement**：`Verified` / `Unverified`、review、clearing period、期限 6. **withdraw経路**：対応Wallet、address、network、minimum、fee、反映確認方法 不一致が1つでもあれば、ログイン、入金、bid、offer、purchase、listing、mint、withdrawへ進まず、[Binance NFT help center](https://www.binance.com/en/support/faq/list/130)、[利用規約](https://www.binance.com/en/terms)、[risk warning](https://www.binance.com/en/risk-warning)の現行内容を確認してください。 ## よくある質問 ### Binance NFTは終了しましたか 2026年8月29日時点では、公開Marketplaceとhelp centerを確認できたため、本記事では全面終了と扱いません。ただし、個別商品、地域、アカウント、mint、withdrawなどの機能がすべて利用できるとは限りません。 ### 日本から使えますか 公開ページが日本から表示できたことだけでは、利用可否を断定できません。居住国、本人確認、アカウント、商品、現行規約ごとに案内や制限が変わり得ます。本記事では日本居住者の登録、本人確認、取引、入出庫を実行していないため、利用可能とは判定していません。 ### BUSD・ETH・BNBだけで取引しますか 旧記事の固定説明は使えません。現行公開画面ではUSDTやBNBの表示例を確認しましたが、すべてのitemに共通する通貨とは扱いません。対象itemと最終確認画面に表示されるquote assetを確認してください。 ### `Verified`なら本物ですか Marketplace内の区分を示す重要な情報ですが、作者、copyright、license、metadataの永続性、将来価値を一括して保証する表示ではありません。contract address、token ID、creatorの公表、権利文書を別々に照合します。 ### 手数料は1%ですか Marketplace platform feeの確認時点の値は1%ですが、royalty、mint、collection作成、deposit・withdraw・burnのnetwork feeなどは別です。実行直前の合計と確認画面を優先してください。 ### NFTを買うと画像を自由に使えますか token ownershipとcopyright・licenseは別です。collectionやcreatorが示す権利条件を確認し、商用利用、改変、再配布が明記されていなければ許可されたと推測しないでください。 ## まとめ Binance NFTは2026年8月29日時点で公開Marketplaceを確認できますが、それだけで自分のアカウントの利用可否は決まりません。**地域と本人確認 → network → contractとtoken ID → 費用 → `Verified`区分 → withdraw経路**の順に、同じ対象を照合してください。 本記事は公開情報の確認で止めています。地域・アカウント条件、手数料、販売形式、対応networkは変わるため、実行前には公式help centerと最終確認画面を読み直し、未確認項目があれば操作を中断してください。 ## 確認した一次情報 - [Binance NFT Marketplace: 現行公開マーケット画面](): 確認日 2026-08-29 - [Binance Support: Binance NFT help center](): 確認日 2026-08-29 - [Binance Support: Binance NFT Marketplaceの利用開始ガイド](): 確認日 2026-08-29 - [Binance Support: NFTの販売形式とlisting review](): 確認日 2026-08-29 - [Binance Support: Binance NFTの手数料](): 確認日 2026-08-29 - [Binance Academy: カストディ型とノンカストディ型NFT](): 確認日 2026-08-29 - [Binance Terms of Use](): 確認日 2026-08-29 - [Binance Risk Warning](): 確認日 2026-08-29 - [Ethereum.org: NFT ownershipとmetadataの基礎](): 確認日 2026-08-29 --- # Rexx Exchange代理店制度の現況｜旧登録手順と報酬表を訂正 Rexx Exchange代理店制度について、旧紹介リンク、3MIKAN LINEでの個人情報送付、固定報酬表を撤去し、2026年8月29日時点の公式制度ページ・規約・金融庁登録一覧で確認できる範囲を整理します。 正規URL: https://3mikan.com/archives/234 著者: みかん 公開: 2021-02-16T17:29:45.000Z 更新: 2026-08-29T01:30:00.000Z この記事は、2021年に公開したRexx Exchangeカードの代理店募集記事を全面的に訂正したものです。**旧記事の紹介者コード、代理店登録リンク、3MIKAN LINEへ登録名・メールアドレスを送る手順、固定の報酬表は利用しないでください。** 3MIKANでは、Rexx Exchangeの代理店登録の仲介や、登録情報の受け付けを行いません。 2026年8月29日時点では、Rexx Exchangeの公式Agentsページは公開されています。しかし、ページを表示できることと、日本居住者が現在申し込めること、カードを発行できること、代理店として承認されること、特定の報酬率が適用されることは別です。 この記事では、**確認できた事実、公開情報だけでは確認できない条件、確認先**を分けます。登録やカード発行を勧める記事ではありません。 ## 2026年8月29日時点の要点 | 項目 | 公開情報で確認できたこと | この記事で確定しないこと | | --- | --- | --- | | 代理店制度 | [公式Agentsページ](https://rexx.exchange/affiliate/)が公開され、紹介した利用者の手数料の一部を受け取る制度を説明している | 新規受付の可否、審査、個別報酬率、支払条件 | | 登録方法 | 公式ページは登録方法と報酬率の詳細をRexx Exchangeへの問い合わせ事項としている | 旧紹介者コードや3MIKAN経由の有効性 | | 運営主体 | [公式利用規約](https://rexx.exchange/jp/terms/)はGLOW CO., LTD.とLao PDRの所在地を記載している | 現在の各国での許認可、提携先、資産保全の状態 | | 日本の登録一覧 | 金融庁の2026年8月21日現在の暗号資産交換業者登録一覧に、Rexx ExchangeまたはGLOW CO., LTD.の名称は確認できない | カード、決済、代理店活動を含むサービス全体の法的評価 | | カード・口座 | 公式CardページとFAQページが公開されている | 日本居住者の新規申込、発行、配送、入出金、利用可能地域、現在の手数料・限度額 | 公開ページの表示だけを根拠に、利用可能性や契約条件を補わないことが重要です。個別条件は、公式窓口からの書面回答と、申込時に表示される契約前画面で確認する必要があります。 ## 確認先を3つに分ける 同じ「公式情報」でも、確認できる範囲が違います。 | 確認先 | 主に確認すること | それだけでは確認できないこと | | --- | --- | --- | | 公式Agentsページ | 制度の公開説明、公式の問い合わせ先 | 個別の承認、現在の報酬率、支払実績 | | 利用規約・契約前画面・公式サポート | 契約相手、居住地条件、本人確認、手数料、解約・支払条件 | 日本の公的登録一覧における位置づけ | | 公的登録一覧・必要に応じた専門家 | 一覧の対象業務について登録名を確認 | 個別サービス全体の適法性や安全性の保証 |
Rexx Exchange代理店制度について、公式制度ページ、規約と契約前画面、公的登録一覧を分けて確認する図
一つのページだけで、制度、契約条件、公的登録状況のすべてを判断しない。
まず制度の概要を公式Agentsページで確認し、次に自分へ適用される条件を規約・契約前画面・公式サポートで確認します。日本の登録状況や法的な判断が必要な場合は、公的資料の対象範囲を読み、必要に応じて資格のある専門家へ相談します。 ## 旧募集手順を削除した理由 旧記事には、紹介者コード付きURLから登録し、登録名とメールアドレスを3MIKANのLINEへ送ると、代理店機能が有効になるという手順がありました。現在の公式Agentsページは、その手順を掲載していません。登録方法と報酬率は、Rexx Exchangeへ問い合わせるよう案内しています。 そのため、旧手順を現在も有効な公式フローとして案内できません。3MIKANが利用者の登録情報を受け取り、第三者サービスのアカウント有効化を仲介する根拠も確認できないため、個人情報の送付案内を撤去しました。 旧記事に掲載していたカード発行や入出金などの固定報酬額・割合も削除しています。報酬は契約条件であり、対象取引、支払時期、取消条件、税務上の扱いなどを含めて確認するものです。古い数値だけを切り取って、現在の収益見込みとして扱わないでください。 ## 公式Agentsページで確認できる範囲 [Rexx ExchangeのAgentsページ](https://rexx.exchange/affiliate/)は、代理店が紹介した利用者の手数料の一部を報酬として受け取れる仕組みを説明しています。また、登録方法と報酬率の詳細はRexx Exchangeへ問い合わせるよう案内しています。 ここから確認できるのは、**代理店制度を説明する公式公開ページがあること**です。次の条件までは確認できません。 - 日本居住者からの新規代理店申請を現在受け付けているか - 申請者へどの審査・本人確認・契約条件が適用されるか - 報酬率、対象取引、支払通貨、最低支払額、取消条件 - 紹介先のカード発行や入出金が現在利用できるか - 旧紹介者コードや旧代理店アカウントが現在も有効か 問い合わせる場合でも、氏名、メールアドレス、本人確認書類などを非公式の第三者へ送らず、公式ドメインとプライバシー条件を確認してください。 ## 運営主体と規約日を確認する [公式利用規約](https://rexx.exchange/jp/terms/)は、サービス運営者を**GLOW CO., LTD.**、所在地をLao PDRと記載し、最終更新日を**2020年8月1日**としています。規約には、居住地によってすべての機能を利用できない場合があることや、適用法を利用者が確認する旨も記載されています。 最終更新日が古いことは、規約が直ちに無効であることを意味しません。一方で、2026年の申込資格、カード発行、銀行・カード発行会社との関係、手数料を自動的に裏付けるものでもありません。 契約を検討するときは、申込直前に表示される最新版の規約について、次を保存して比較します。 1. 契約相手の法人名と所在地 2. 規約の版・更新日と適用開始日 3. 居住国、本人確認、利用制限の条件 4. 入出金、カード、代理店報酬に関わる全費用 5. 解約、資金返還、報酬取消、問い合わせの手続き 公開中の[FAQページ](https://rexx.exchange/jp/faq/)も確認先の一つですが、一般的な回答と自分の契約条件が一致するとは限りません。相違がある場合は、契約前画面と公式からの書面回答を優先して確認します。 ## 金融庁の登録一覧は対象範囲を限定して読む 金融庁が公開する[暗号資産交換業者登録一覧](https://www.fsa.go.jp/menkyo/menkyoj/kasoutuka.pdf)は、2026年8月21日現在で27業者を掲載しています。この一覧で、Rexx ExchangeまたはGLOW CO., LTD.という名称は確認できませんでした。 したがって、この記事ではRexx Exchangeを**日本の登録暗号資産交換業者として確認できたサービス**とは扱いません。ただし、この不掲載だけで、カード、決済、海外でのサービス提供、代理店活動を含むすべての法的評価を決めることもできません。業務の実態、勧誘対象、契約主体、資金の流れ、居住地などで確認対象が変わります。 登録や紹介を検討する際に法的な判断が必要な場合は、公的資料の名称検索だけで結論を出さず、業務範囲を整理して資格のある専門家へ相談してください。 ## カードの手数料・限度額を固定情報にしない [公式Cardページ](https://rexx.exchange/jp/card/)は公開されていますが、ページの表示だけでは、日本居住者向けの新規発行、配送、利用可能地域、チャージ・出金方法、カード発行会社、現在の手数料や限度額まで確認できません。 カードや口座の条件は、居住地、本人確認の結果、通貨、決済経路、カード区分、提携先の変更で変わる可能性があります。検索結果や古い比較表ではなく、申込時点の画面で次を確認します。 | 確認項目 | 確認する内容 | | --- | --- | | 利用資格 | 日本居住者の新規申込可否、年齢、本人確認、対象国 | | 契約主体 | サービス運営者、カード発行会社、資金を預かる主体 | | 全費用 | 発行、維持、チャージ、決済、為替、ATM、出金、解約 | | 資金移動 | 対応通貨・ネットワーク、反映時間、取消・返金条件 | | 利用制限 | 地域、加盟店、上限、凍結・停止の条件 | | サポート | 公式連絡先、対応言語、紛失・不正利用・返金の手続き | 金額や割合だけでなく、いつ、何に、どの通貨で課される費用かを合わせて確認してください。 ## 契約・紹介前のチェックリスト 代理店制度やカードについて情報を共有する前に、少なくとも次を確認します。 1. 公式ドメインから制度ページと最新版の規約へ到達したか 2. 日本居住者の申込可否について、日付入りの公式回答があるか 3. 契約相手、審査、本人確認、対象地域が明記されているか 4. 報酬率だけでなく、対象取引、支払時期、取消条件、費用が書面にあるか 5. カード発行会社、資金管理、返金・解約手続きが確認できるか 6. 紹介コードや報酬を開示し、利益があることを読み手へ明示できるか 7. 氏名、メールアドレス、本人確認書類を非公式な第三者へ送らない流れか 8. 公的登録や法的評価について、一覧の対象範囲を超えた断定をしていないか 一つでも確認できない場合は、「昔の手順と同じだろう」と進めず、申込や紹介を止めて公式窓口へ確認してください。 ## 現時点で確認できない事項 この記事では、アカウント作成、本人確認、カード申込、入出金、代理店申請を行っていません。そのため、次は未確認です。 - 日本居住者向け新規アカウントとカード発行の可否 - 現在の本人確認・審査・配送・利用可能地域 - 入出金、チャージ、決済、ATM、為替などの現在の全費用 - 代理店の新規受付、承認基準、報酬率、支払・取消条件 - 旧アカウント、旧カード、旧紹介コードの継続利用条件 - 現在のカード発行会社、銀行、決済・資金管理の提携関係 公式から個別回答を得た場合も、回答日、対象国、対象アカウント、規約の版を一緒に保存し、他の利用者へ一般化しないでください。 ## よくある質問 ### いまもRexx Exchangeの代理店へ登録できますか？ 公開Agentsページは確認できますが、日本居住者の新規受付、審査、承認までは確認できません。公式窓口と契約前画面で、対象国と日付を含む条件を確認してください。3MIKANでは登録を仲介しません。 ### 旧記事の代理店リンクや紹介者コードは使えますか？ 現在の公式手順として裏付けられないため、本記事から撤去しました。旧リンクを試したり、3MIKANのLINEへ個人情報を送ったりしないでください。 ### Rexx Exchangeカードは日本で発行できますか？ この記事では確認できていません。Cardページが表示されることは、日本居住者向けの新規発行、配送、決済、ATM利用を保証しません。 ### 金融庁の一覧に名称がないと違法ですか？ 一覧への不掲載だけで、サービス全体の法的評価は断定できません。一方で、日本の登録暗号資産交換業者としても確認できないため、そのように紹介しないでください。必要な判断は、実際の業務と契約関係を整理して専門家へ確認します。 ## まとめ - 旧紹介者コード、3MIKAN LINEへの個人情報送付、固定報酬表は利用しない - 公式Agentsページの公開と、個別の申込・承認・報酬条件を分ける - 規約はGLOW CO., LTD.と2020年8月1日の更新日を記載しているが、現在の個別条件は契約前画面で確認する - 2026年8月21日現在の金融庁登録一覧でRexx Exchange / GLOWの名称は確認できないが、それだけでサービス全体の法的評価を断定しない - 日本居住者のカード発行、入出金、代理店受付、報酬率は未確認として扱う この記事は、古い募集手順を現在の申込方法として残さないための訂正です。新しい条件を確認できるまでは、登録や紹介へ進まず、公式情報と契約文書を分けて確認してください。 ## 確認した一次情報 - [Rexx Exchange: Agents](): 確認日 2026-08-29 - [Rexx Exchange: Card](): 確認日 2026-08-29 - [Rexx Exchange: FAQ](): 確認日 2026-08-29 - [Rexx Exchange: Terms of Service](): 確認日 2026-08-29 - [金融庁: 暗号資産交換業者登録一覧（2026年8月21日現在）](): 確認日 2026-08-29 --- # バンクシーNFTの3事件を検証｜無許可・焼却・偽物の見分け方 バンクシー関連NFTのSpike、焼却されたMorons、偽装出品事件を検証。トークン、作者、Pest Controlの認証、著作権、売買記録を分けて確認する方法を解説します。 正規URL: https://3mikan.com/archives/3299 著者: みかん 公開: 2021-10-18T15:38:08.000Z 更新: 2026-08-29T01:00:00.000Z **2026年8月29日時点で、この記事が扱う3件を「バンクシー本人が作ったNFT」と確認できる一次資料はありません。** ただし、3件は同じ意味での「偽物」でもありません。 - `Spike`は、物理作品の所有者とValuartが制作したと説明するdigital interpretation - `Morons`は、第三者groupが物理printを焼却し、別のtokenとして流通させた事例 - `Great Redistribution of the Climate Change Disaster`は、Banksy作と受け取られる形で売られたものの、Banksy側が関与を否定した事例 ここで混同してはいけないのは、**tokenがblockchain上に存在すること、作品の作者、物理作品の真正性、著作権・利用許諾、marketplace掲載、売買履歴**です。本記事はこの6つを分けて検証します。 > 今回の確認で行っていないこと > > Wallet接続、署名、Approve、offer、bid、purchase、transaction送信、asset移動は行っていません。公開pageと公式資料をsigned-outのChromeで読み取った確認です。また、本記事は個別の作品の真正性を認定するものでも、法律・投資の助言でもありません。 ## 最初に分ける6つの証拠 | 層 | 確認するもの | それだけでは証明しないもの | | --- | --- | --- | | token | chain、contract address、token ID、standard | 誰が原作品を作ったか | | creator | mint元、出品者、制作説明、本人の公表 | 著作権が移ったか | | physical | Pest Controlのcertificate、対象作品 | そのcertificateがNFTにも及ぶか | | rights | copyrightの譲渡、商用license、利用範囲 | token ownershipだけでは代替できない | | listing | marketplaceのcollection・item page | marketplaceが作者を保証したか | | sale | transfer、支払、返金、現在のholder | 真正性や将来価値 | トークン、作者、物理作品の認証、著作権、掲載、売買履歴を別々に確認する6層の図 [ERC-721](https://eips.ethereum.org/EIPS/eip-721)では、NFTの識別はcontract addressとtoken IDの組み合わせで行います。[ERC-1155](https://eips.ethereum.org/EIPS/eip-1155)も、1つのcontractで複数のtoken IDを管理でき、IDごとにmetadataやsupplyを持てます。作品名や画像が同じでも、contractかtoken IDが違えば別のtokenです。 反対に、contractとtoken IDが確認できても、作者名やcopyrightまでblockchainが自動審査するわけではありません。metadataの画像、説明、外部URLと、作者・権利の証拠は分けて読みます。 ## 3事件の時系列 2021年3月のMorons焼却、7月のSpike、8月から9月の偽装NFT、2026年の公開page再確認を並べた時系列 | 時期 | 出来事 | この記事での扱い | | --- | --- | --- | | 2021年3月 | 第三者groupが`Morons`のprintを焼却し、tokenを販売 | 物理作品とtoken、焼却と権利を分ける | | 2021年7月 | Valuartが`Spike`を基にしたdigital workのauctionを公表 | project側説明とBanksy本人の承認を分ける | | 2021年8〜9月 | Banksy公式siteに一時的に現れたlinkからNFTが100 ETHで購入され、Banksy側が関与を否定。sellerが返金 | tokenの実在と作者表示の偽装を分ける | | 2026年8月29日 | Valuartと2つのOpenSea item pageを再確認 | 現在の掲載は確認できるが、過去の権利関係を追加で証明しない | ## 事例1: Spikeは「本人のNFT」と確認できない [Valuartの現行site](https://valuart.com/)には、2026年8月29日にも`SPIKE BY BANKSY`の掲載があります。[2021年のproject側release](https://ihodl.com/press-releases/2021-07-21/valuart-launches-auction-nft-derived-banksys-spike/)は、物理作品の所有者Vittorio GrigòloとValuartが、CGIによるdigital interpretationを制作したと説明しています。収益の50%を紛争被害者支援へ充てる計画も、同release内の説明です。 ここから確認できるのは、Valuart側が何を制作・販売したと主張したかです。**Banksy本人またはPest ControlがNFT化を承認したこと、商用licenseを与えたことまでは確認できません。** 逆に、公開資料でlicenseを見つけられないことだけから、契約が絶対に存在しなかったとも断定しません。 [Banksy公式のlicensing案内](https://www.banksy.co.uk/licensing.html)は、作品の商用利用を許諾できる窓口をPest Control Officeとしています。したがって、物理作品を所有しているという説明だけでなく、次を別に確認する必要があります。 1. 物理作品は何で、誰が所有していたのか 2. digital workは原作品の複製、翻案、撮影、別作品のどれとして制作されたのか 3. 商用利用のlicenseを誰が、誰に、どの範囲で与えたのか 4. tokenのcontract、token ID、mint元は何か 5. 慈善目的の説明と権利処理の証拠を混同していないか 旧記事は`Spike`を「無許可」と断定していました。今回の公開資料だけでは契約の不存在まで証明できないため、**「Banksy本人の承認・商用licenseを確認できない」へ訂正します。** ## 事例2: Moronsを燃やしてもcopyrightはtokenへ移らない [OpenSeaの現行item](https://opensea.io/item/ethereum/0xdfef5ac9745d24db881fef3937eab1d2471dc2c7/1)は、Ethereum上のERC-1155として表示されます。itemの識別情報は次のとおりです。 ```text contract: 0xdfef5ac9745d24db881fef3937eab1d2471dc2c7 token ID: 1 ``` [2021年3月のThe Art Newspaper報道](https://www.theartnewspaper.com/2021/03/04/art-enthusiasts-burn-a-banksy-print-then-sell-it-as-an-nft)によると、販売側はPest Controlのcertificateが付いた`Morons`のprintを焼却し、その出来事とdigital imageをtoken化したと説明しました。ここでは、次の3つを分けます。 - 物理printについてcertificateがあったという販売側の説明 - その物理物を第三者groupが焼却した出来事 - Ethereum上に発行された別のERC-1155 token [Pest Controlの現行terms](https://pestcontroloffice.com/terms.asp)によると、certificate of authenticityは対象となる物理作品についてPest Controlが裁量で発行するものです。すでに認証済みの作品を購入前に照会する`Check Before You Buy`も、投資価値や将来価格を保証するserviceではありません。物理作品のcertificateを、NFTの作者・license・価値のcertificateとして読み替えることはできません。 また、物理物を燃やすことはNFT発行の技術要件ではありません。ERC-1155 tokenはcontract上の処理で発行され、物理作品の存否をprotocolが確認する仕様ではないためです。 [英国政府のcopyright案内](https://www.gov.uk/using-somebody-elses-intellectual-property/copyright)も、絵画などの物理物を買うことと、その作品を複製・利用するcopyrightを得ることは別だと説明しています。copyrightの譲渡には署名を含む書面が必要で、licenseなら許された用途と範囲を確認します。**焼却は、copyrightの譲渡書でも商用licenseでもありません。** 旧記事は「現物とdigitalの両方に本物の所有者ができるため、NFT化には燃やす必要があった」と説明していました。この説明は撤回します。物理物を残したままtokenを発行することは技術上可能で、何を所有・利用できるかは販売条件と権利文書の問題です。 ## 事例3: 偽装NFTもtokenとしては実在する 2021年8月、collectorのPranksyは、Banksy公式siteに一時的に置かれたlinkからNFT marketplaceへ進み、`Great Redistribution of the Climate Change Disaster`を100 ETHで購入したと報じられました。その後、Banksy側はNFT制作とauctionへの関与を否定し、sellerは100 ETHを返しました。networkのtransaction feeは購入者負担として残ったと[The Guardian](https://www.theguardian.com/technology/2021/sep/01/collector-buys-fake-banksy-nft-for-244000)と[The Art Newspaper](https://www.theartnewspaper.com/2021/08/31/were-banksy-and-pranksy-both-pranked-in-dollar330000-nft-sale)が伝えています。 この事例で「偽物」だったのは、blockchain上にtokenが存在しないという意味ではありません。**Banksy作だと受け取らせる帰属と販売導線が虚偽だった**という意味です。 つまり、tokenはon-chainに実在しますが、tokenの実在はBanksyが制作・承認した証拠ではありません。 [OpenSeaの現行item page](https://opensea.io/item/ethereum/0x495f947276749ce646f68ac8c248420045cb7b5e/769987281610794526370432769847587291321402667277633018751858935165377052673)は、現在もERC-1155 itemとowner `Pranksy`を表示します。 ```text contract: 0x495f947276749ce646f68ac8c248420045cb7b5e token ID: 769987281610794526370432769847587291321402667277633018751858935165377052673 ``` このcontractは、当時OpenSeaで複数creatorが使ったshared storefront contractです。contract名やmarketplace domainだけではcreatorを特定できません。token ID、mint・transfer履歴、creator address、外部siteでの本人の告知を一組で確認します。 また、「公式siteからlinkされた」ことも単独では十分ではありません。この事件では、公式site上のlink自体が攻撃または不正な変更の疑いを生む材料になりました。domainが正しくても、公開日時、site側の告知、関係者の否定、link先のcontractを照合します。 ## Banksy作品の真正性はPest Controlで確認する [Banksy公式FAQ](https://www.banksy.co.uk/faq.html)は、作品の認証窓口としてPest Control Officeを案内し、Banksyを名乗るSNS accountや他のgallery・institutionを公式代理とみなさないよう示しています。 ただし、Pest Controlの役割にも範囲があります。 - certificateは、申請できる物理作品について発行判断される - 公共空間から取り外されたstreet artなど、対象外となるものがある - `Check Before You Buy`は、すでにcertificateがある作品についての購入前照会 - 価格、投資価値、将来の値上がりを保証しない - NFTのcontractやseller accountを自動的に認証するserviceではない したがって、「Pest Controlのcertificateあり」という画像だけで判断しません。certificateの対象作品、番号、sellerとの関係、照会結果を確認し、その後にNFT側のcontractとlicenseを別に確認します。 ## copyright・所有権・NFTを混同しない [GOV.UKのcopyright ownership案内](https://www.gov.uk/guidance/ownership-of-copyright-works)では、通常、作品を制作した人がcopyrightの最初のownerになります。例外や契約はありますが、物理作品やNFTを買っただけでcopyrightが自動移転するわけではありません。 | 取得したもの | 通常確認できること | 追加で必要な証拠 | | --- | --- | --- | | 物理作品 | その物理物の占有・所有 | copyright譲渡、複製・商用利用license | | NFT | 指定contract・token IDのholder | artworkの利用条件、作者との関係、metadata保存先 | | certificate | 対象物理作品に対する認証判断 | NFTとの対応、copyright、商用license | | marketplace listing | itemを掲載・売買できる状態 | creator本人、権利者、公式collectionの証明 | NFTの保有者が得る利用範囲は、tokenの販売条件やlicenseによって異なります。「NFTを買ったから画像を自由に商品化できる」「高額で売れたからcopyrightも含む」とは限りません。 ## 購入前に残す検証メモ 高額なNFTを確認するときは、画面名や画像ではなく、次の順で記録します。 1. chain名を記録する 2. contract addressをblock explorerとmarketplaceの両方で照合する 3. token IDを省略せず記録する 4. token standard、mint元、transfer履歴を読む 5. metadata URIと画像保存先が変更可能か確認する 6. 作者の公式siteから同じcontractとtoken IDが案内されているか確認する 7. 物理作品ならPest Controlの対象範囲とcertificateを確認する 8. copyright譲渡または商用licenseの文書と範囲を確認する 9. seller、marketplace、紹介者の説明を同じ証拠として数えない 10. 不一致が1つでもあれば、Wallet接続、offer、bid、purchaseへ進まない 名前の似たcollection、検索広告、SNSのDM、sellerが渡す画像だけを入口にしないでください。seed phrase、秘密鍵、recovery phraseを入力させるsiteは利用せず、Wallet接続前にURLと権限要求を止めて確認します。 ## よくある質問 ### marketplaceに載っていれば本物ですか？ いいえ。掲載は、marketplaceが作者・copyright・物理作品の真正性を全面保証したという意味ではありません。chain、contract、token ID、creator、本人の告知、権利文書を分けて確認します。 ### Pest ControlのcertificateがあればNFTも本物ですか？ certificateの対象は物理作品です。その物理作品とNFTの対応、NFT制作への関与、商用license、contract・token IDは別の証拠が必要です。 ### 作品を燃やせばNFTだけが本物になりますか？ なりません。焼却は物理物の状態を変えますが、NFTを作者本人の作品にしたり、copyrightを移転したりする手続きではありません。 ### blockchainの履歴は何を証明しますか？ 指定chain・contract・token IDについて、mint、transfer、holderなどの記録を検証できます。addressの背後にいる人物、原作品の作者、契約の有効性まで自動的に証明するものではありません。 ### 2026年のOpenSeaに表示される価格は当時の落札額ですか？ 必ずしも同じではありません。法定通貨換算はasset価格で変動し、表示仕様も変わります。本記事は2026年8月29日にitem pageの存在と公開表示を再確認しましたが、現在のドル換算を過去事件の固定価格として使いません。 ## まとめ バンクシー関連NFTの3事件から得られる結論は、「NFTは全部偽物」でも「blockchainにあれば本物」でもありません。 - `Spike`: project側の制作説明はあるが、Banksy本人の承認・商用licenseは公開資料で確認できない - `Morons`: 物理printの焼却と、第三者が発行したERC-1155 tokenは別。焼却はNFT化やcopyright移転の要件ではない - 偽装NFT事件: tokenと売買記録は実在しても、Banksy作という帰属は虚偽になり得る **contract addressとtoken IDは検証の開始点であり、作者・認証・権利の結論ではありません。** 6層の証拠が同じ対象を指しているかを確認し、不一致があれば取引操作へ進まないでください。 ## 確認した一次情報 - [Banksy公式site: 作品の商用利用とPest Control Office](): 確認日 2026-08-29 - [Banksy公式site: 公式窓口・SNS・galleryに関するFAQ](): 確認日 2026-08-29 - [Pest Control Office: 認証書とCheck Before You Buyの条件](): 確認日 2026-08-29 - [GOV.UK: 他者の著作物を利用する場合のcopyright](): 確認日 2026-08-29 - [GOV.UK: copyrightの初期帰属と譲渡](): 確認日 2026-08-29 - [Ethereum EIP-721: NFTのcontractとtoken ID](): 確認日 2026-08-29 - [Ethereum EIP-1155: Multi Token Standardとmetadata](): 確認日 2026-08-29 - [Ethereum.org: NFTのownershipとsecurity](): 確認日 2026-08-29 - [Valuart: SPIKE BY BANKSYの現行掲載](): 確認日 2026-08-29 - [Valuart配信release: Spike NFTの制作・auction・寄付計画に関するproject側説明](): 確認日 2026-08-29 - [OpenSea: Original Banksy Morons #1の現行item record](): 確認日 2026-08-29 - [The Art Newspaper: Morons printの購入・certificate・焼却・NFT auctionの当時報道](): 確認日 2026-08-29 - [OpenSea: Great Redistribution of the Climate Change Disasterの現行item record](): 確認日 2026-08-29 - [The Art Newspaper: Banksy側の否定と100 ETH返金の当時報道](): 確認日 2026-08-29 - [The Guardian: 公式site上のlink・購入・否定・返金の当時報道](): 確認日 2026-08-29 --- # Mars Ecosystem（XMS・USDm）の現在｜公式appとLibraSwapを検証 Mars EcosystemのXMS・USDmと180日vestingの設計、2021〜2023年の変化、2026年に確認できる公式app・contract・LibraSwap poolの状態を整理します。 正規URL: https://3mikan.com/archives/3886 著者: みかん 公開: 2021-11-10T14:43:55.000Z 更新: 2026-08-29T00:20:00.000Z **2026年8月29日時点で、Mars Ecosystemの公式siteとappには到達できます。** ただし、公式appのLive PoolsとLive Farmsには公開状態で参加先が表示されず、古いClaim欄やWallet接続前のSwap画面が残っています。一方、2023年に公式Xが移行先として案内したLibraSwapには、USDm-USDT poolとtoken残高があります。 この状態を「終了」と「通常営業中」の二択で表すことはできません。**siteが見えることと、現在の公式serviceを実行できることを同じにしない**のが、この記事の結論です。 > 今回の検証で行っていないこと > > Wallet接続、account入力、message署名、Approve・revoke、farm、pool、swap、liquidity追加・解除、mint、redeem、claim、contract write、transaction送信、asset移動は行っていません。signed-outのChrome、公式資料、Explorer、BNB Smart Chain公式public RPCへのread-only callだけを確認しました。 ## Mars Ecosystemの現在地 | 確認項目 | 2026年8月29日の観測 | ここから言える範囲 | | --- | --- | --- | | 公式site / app | `marsecosystem.com`と`app.marsecosystem.com`へ到達できる | 公開frontendが配信されている。Wallet接続後の全機能は未確認 | | Live Pools / Farms | どちらも参加先の行がなく、新しいPoolsを待つ表示 | 公開状態では現在のreward先を確認できない。将来の追加や接続後表示までは断定しない | | Claim | 180日vesting、旧IHO・IMO・airdrop等の欄を表示 | 旧設計の画面が残る。特定accountの残高、権利、claim成功は未確認 | | Mint / Genesis Claim | routeは残るが、signed-outではprovider関連errorを伴い初期化が完了しない | Wallet未接続の観測。mint / redeemが稼働・停止しているとは断定できない | | XMS / USDm / Core | bytecode、相互参照、supply、pause状態をread-onlyで確認 | contract stateの一部。operator、oracle、価格安定、UIの実行可否は別 | | LibraSwap | USDm-USDT pool、Swap form、残高とTVL表示がある | 公開poolが存在する。任意数量の約定、価格、slippage、redeemは未検証 | | 公開更新 | signed-outの公式Xで見える新しいproject投稿は2023年。公式Mediumの公開一覧で新しい記事は2023年2月 | 公開timelineで確認できた時点。非公開開発や将来更新の不存在は示さない | 2021年のUSDm GenesisとFarms、2022年のLibra構想、2023年の流動性移行、2026年の公式app・contract・pool確認を分ける時系列 ## XMSとUSDmは何だったのか Mars Ecosystemは、BNB Smart Chain上の2 token設計として説明されました。 | token | 2021年docsでの役割 | 読み違えやすい点 | | --- | --- | --- | | XMS | governance、USDm供給上限の基準、redeem時に渡すasset | total supplyやmarket capが、USDmの償還可能性を単独で保証するわけではない | | USDm | Mars Treasuryへwhitelist assetを入れてmintするstablecoin | symbolや「stablecoin」という名称だけで、現在$1で売買・償還できるとは限らない | [公式docsの当時の設計](https://docs.marsecosystem.com/whitepaper/minting-redeeming-mintage-control)では、$1相当のwhitelist assetをTreasuryへ入れて1 USDmをmintし、1 USDmを返すと$1相当のXMSを受け取ると説明しています。mint assetとredeem assetが同じではない、非対称な設計です。 USDmが$1を下回ると、安く買ったUSDmをXMSへredeemして裁定するという価格安定ロジックでした。しかし[価格安定のdocs](https://docs.marsecosystem.com/whitepaper/usdm-price-stability)自身も、redeem後に受け取るXMSへ十分なmarket liquidityがあることを前提にしています。 したがって、次の4つは別々に確認する必要があります。 1. USDm contractが存在する 2. mint / redeem functionがpauseされていない 3. frontendや直接のcallでtransactionを成立させられる 4. 受け取ったassetを想定価格・数量で交換できる この記事で確認したのは主に1と、contract全体のpause flagの一部です。2のfunction別条件、3、4は確認していません。 ## 正しいcontract addressをsymbolより先に見る 公式docsが掲載するBNB Smart Chainの主要addressは次のとおりです。 | 役割 | address | 2026年8月29日のread-only値 | | --- | --- | --- | | XMS | `0x7859B01BbF675d67Da8cD128a50D155cd881B576` | `Mars Ecosystem Token` / `XMS`、18 decimals、total supply 10億、`paused() == false` | | USDm | `0xBb0fA2fBE9b37444f5D1dBD22e0e5bdD2afbbE85` | `USD Mars` / `USDm`、18 decimals、total supply 3,608,798.128300670486134785、`paused() == false` | | Core | `0x00789cfb69499c65ac9a3a68fb4917c9b4fca2a7` | XMS / USDm参照が上記addressと一致、XMS Support Ratio 250% | XMSはUSDmとCoreを、USDmはXMSとCoreを参照し、相互のaddressは公式docsと一致しました。これはtokenの同定に役立ちます。 ただし、`paused() == false`はtoken contract全体の読取値です。**stablecoin frontend、個別module、oracle、Treasury、mint上限、redeem結果、流動性まで「稼働中」と判定する値ではありません。** また、XMSの10億はtotal supplyであり、circulating supplyや売買可能数量ではありません。USDm supplyも確認blockのsnapshotで、transfer・mint・burnにより変化します。 ## 250% support ratioの意味と限界 旧docsは、直近3分のXMS平均market capをXMS Support Ratioで割り、Treasury-owned USDmを加えてUSDm supply capを求めると説明していました。launch時のratioは250%です。Coreから2026年8月29日に読んだ値も、precisionを考慮すると250%でした。 この数値は「USDm 1に対して現金やstablecoin 2.5が保管されている」というreserve ratioではありません。基準はXMSのmarket capで、価格取得、market depth、Treasury asset、role権限、mint / redeem routeが別に関わります。 旧docsの数式と現在のparameterが一致することから、設計の痕跡は確認できます。しかし、それだけで現在のUSDmが$1を維持する、または$1相当のXMSへ確実にredeemできるとは言えません。 ## 180日vestingは旧Claim画面にも残る 公式appのClaimは、Farms & Pools Rewardsについて次の表示を残しています。 - 180 days linear vesting - 3日に1回vesting - claimごとにgas feeが必要 同じ画面にはUPやPARKのIHO、IMO、airdrop、old XMS poolなど、2021〜2022年の複数の欄も並びます。Wallet未接続では金額が表示されず、buttonはdisabledでした。 旧記事は、この180日vestingを高APRの理由として説明し、PoolsやFarmsの操作を案内していました。現在の公開Live一覧に対象行がないため、2021年のAPRやrewardを現在の運用条件へ延長できません。 vesting表示が残ることは、次を証明しません。 - 読者のaddressに未請求rewardがある - 旧rewardが現在も増えている - buttonを押せばclaimが成功する - 受け取るXMSに表示どおりのmarket valueがある 個別残高を確認するために、検索結果、SNS reply、DMで案内された別siteへWalletを接続しないでください。 ## 2021年から2023年に導線が変わった ### 2021年: Genesis、Farms、Pools USDmのGenesisは2021年11月に始まり、旧記事も同時期のFarms、Pools、MarsSwap、Claim、IHOを紹介していました。高いAPRと引き換えに、XMS rewardを180日かけてreleaseする設計でした。 これはlaunch時の説明です。旧TVL、479% APR、画面上のtoken価格を2026年の数字として再掲しません。 ### 2022年: Libra Finance構想 [2022年4月の公式AMA recap](https://mars-ecosystem.medium.com/ama-recap-roadmap-stableswap-and-mars-treasury-c27e9f56a88c)は、MarsSwapでのUSDm交換はslippageが大きいという課題を挙げ、stable asset向けのLibra Financeを開発中だと説明しました。 「stablecoinだから常に低slippage」だったのではなく、交換先のpoolとdepthが必要だったことを示すproject側の説明です。 ### 2023年: Lending研究とLibraSwapへの移行 [2023年2月の公式Medium](https://mars-ecosystem.medium.com/latest-updates-for-mars-lending-platform-46d9a99e1a32)は、Lending Platformのmodel調査、risk設計、contract・adapter開発、testnet debuggingを報告しました。進捗報告であり、本番serviceの公開や預入可能性の証拠ではありません。 [2023年10月18日の公式X](https://x.com/MarsEcosystem/status/1714515734695731558)は、Mars TreasuryのUSDm-BUSD流動性をMarsSwapからLibraSwapへ段階的に移し、USDmをtradeする利用者へLibraSwapを案内しました。 [2023年12月2日の公式X](https://x.com/MarsEcosystem/status/1730803653076979884)は、BinanceによるBUSD product support終了を受け、TreasuryのBUSD reserveとUSDm-BUSD liquidityをUSDTへ置き換えると告知しました。 ここで確認できるのはprojectの告知内容です。移行の全工程、Treasury残高、2026年の運営体制を独立に証明するものではありません。 ## 公式appで現在見えるもの signed-outのChromeで、公式appを画面別に確認しました。 | 画面 | 公開状態の表示 | 検証していないこと | | --- | --- | --- | | Pools | Liveにrowなし。「new Pools」を待つ表示 | Wallet接続後のprivate data、将来のpool | | Farms | Liveにrowなし。Poolsと同じ案内 | LP deposit、harvest、withdraw | | Swap | BNBとtoken選択、Connect Wallet | quote、route、price impact、swap成功 | | Liquidity | create / add liquidity、Connect Wallet | pair reserve、add / remove成功 | | Claim | 旧vesting / IHO / IMO等、disabled button | account balance、eligibility、claim成功 | | IHO | 過去projectのentry | 現在募集中のsale、購入可能性 | | Mint / Genesis Claim | routeは残るがsigned-outでprovider error | Wallet接続後のmint / redeem / claim | signed-outでerrorが出たことだけを理由に「故障」や「終了」と断定しません。一方で、読者がWalletを接続すれば解決すると仮定して手順を出すこともしません。 ## LibraSwapのUSDm-USDT poolに残高がある Libra Financeの公開Pool一覧には、2026年8月29日時点で`USDm-USDT 2POOL`が表示されました。詳細画面は次の値を表示しました。 | UI項目 | 公開表示のsnapshot | | --- | --- | | Currency Reserves | 約117.1万 USDm / 約82.9万 USDT | | TVL | 約200万ドル | | Fee | 0.05% | | Admin Fee | 0.05%の50% | | action | Swap / Add Liquidity / Remove Liquidity、実行前にConnect Wallet | frontend bundleが参照するpool addressは`0xe5b083282aa7A2210bEd76A3D5640fD17bb7458C`です。BNB Smart Chainのblock 118,669,387へread-only callを行うと、pool addressのtoken balanceは次の値でした。 - 1,171,358.574391012 USDm - 829,311.7391290375 USDT UI観測とRPC snapshotの時刻には差があり、残高はその間にも変化します。UIの約200万ドルというTVLは価格評価を含む表示で、on-chainに「200万ドル」と保存されているわけではありません。 公式site・公開UI・contract state・pool残高で確認できる事実と、account・transaction・mint redeem・価格・slippageの未検証領域を分ける図 poolにtoken残高があることは重要な事実ですが、次は別問題です。 - 入力数量に対するactual quote - price impactとslippage - frontendとpool contractの現在の整合 - transfer制限やtransaction revert - USDmからUSDTへ交換した後の最終受取額 - USDm自体の$1 redeem そのため本記事は、LibraSwapへのWallet接続やswapを勧めません。balanceは「資産がpool addressにある」というread-only evidenceとして扱います。 ## CertiK監査は安全保証ではない 旧記事は、CertiK監査を「安心につながる」材料として紹介していました。監査はscope、version、finding、statusまで読まなければ意味が変わります。 [CertiKの2021年report](https://certik-public-assets.s3.amazonaws.com/REP-MarsEcosystem-2021-08-25.pdf)は63 filesを対象とし、2021年5月5日にrequested、8月21日にrevisedと記録されています。集計上は200 findingsで、2件がPartially Resolvedでした。 特に`GLOBAL-02 Privileged Ownership on Asset Management`はMajor、Partially Resolvedです。reportはGovernor、Minter、Guardian、PCV Controller等が、Treasury tokenの送付、XMS／USDm mint、liquidity除去、PCV allocationからのwithdrawやharvestなどを行える設計を指摘しました。 teamは24時間Timelockとmultisig等をalleviationとして回答し、Burner roleの一部を削除したとしています。それでもreportの最終statusはPartially Resolvedです。 監査から言えるのは、**2021年の対象codeに対して指摘と対応が記録されたこと**です。2026年のfrontend、role holder、Treasury、oracle、LibraSwap、全deployed code、個別transactionの安全性を保証しません。 ## 2021年の高APR・操作案内は撤回します 旧記事には、現在の判断材料にできない表現がありました。 - Mars Ecosystemなら高利回りで運用できる - 479% APRは資金が増えやすいことを意味する - XMSの売買にはMarsSwapを使うほうがよい - Pools / Farmsへdepositし、Swap / Liquidity / Claim / IHOを操作する - audit済みであることを安心材料にする - XMSのburnやUSDm公開を将来価格への期待につなげる これらは、2021年の一時点におけるUI、emission、price、liquidity、project planに依存します。2026年の公開Live Pools／Farmsには参加先がなく、流動性の主な案内先もMarsSwapからLibraSwapへ変わりました。 APRは将来のfiat利益ではありません。token emission、vesting、価格、pool depth、impermanent loss、fee、gas、withdraw可能性を含みません。「表示APRが高いから増えやすい」という旧説明は撤回します。 ## 同名token・偽site・救済DMを避ける `XMS`や`USDm`というsymbolだけではtokenを一意に識別できません。確認するときは、少なくとも次を一緒に記録してください。 1. chainがBNB Smart Chainか 2. 省略していないcontract address 3. addressを掲載する公式docsまたは過去のproject告知 4. Explorerで読むname、symbol、decimals、linked contract 5. 情報を確認した日とblock number 「旧rewardを回収できる」「Genesis Claimを再開した」「migrationが必要」などとして、seed phrase、秘密鍵、recovery phrase、message署名、unlimited Approve、先払い送金を求めるsiteや相手には応じないでください。 ## よくある質問 ### Mars Ecosystemは現在も稼働していますか？ 公式siteとappは配信され、XMS／USDm contractとLibraSwap poolも確認できます。一方、公開Live Pools／Farmsは空で、mint / redeem、個別claim、Wallet接続後のswapは未確認です。「何が稼働しているか」を画面・module・contractごとに分ける必要があります。 ### USDmは今も1ドルでredeemできますか？ 2021年docsは、1 USDmを$1相当のXMSへredeemする設計を説明しています。しかし2026年のsigned-out検証では、redeem transaction、受取XMS量、oracle、上限、slippage、最終換金額を確認していません。本記事は$1償還を保証しません。 ### `paused() == false`ならmintやswapが使えますか？ いいえ。今回はXMS／USDm tokenのpause flagを読みました。Coreや個別moduleの条件、role、oracle、frontend、allowance、gas、poolをまとめて証明する値ではありません。 ### LibraSwapに約200万ドルのTVLがあれば、USDmを売れますか？ UIはそのTVLを表示し、pool addressにはUSDmとUSDTの残高があります。しかし任意数量のquote、price impact、slippage、transaction成功、最終受取額は未検証です。残高と売却可能性を同じにしないでください。 ### 旧Claim画面に金額があるか確認してもよいですか？ 本記事ではaccountを接続していないため、個別の確認方法やclaim成功を案内できません。まず公式address、過去transaction、allowanceをread-onlyで整理し、DMや検索広告のlinkから接続しないでください。 ### 公式XやMediumが2023年までなら、projectは終了していますか？ 今回、signed-outで確認できた新しいproject投稿は2023年でした。公開更新が見当たらないことは注意材料ですが、法的な終了、非公開開発の不存在、将来の更新停止までは証明しません。 ## まとめ Mars Ecosystemは、XMS、USDm、MarsSwap、Farms／Pools、180日vestingを組み合わせた2021年のDeFi / stablecoin ecosystemでした。その後、USDm流動性の案内はLibra Financeへ移り、2023年にはBUSDからUSDTへ置き換える方針が告知されました。 2026年8月29日時点では、公式app、XMS／USDm／Core contract、LibraSwapのUSDm-USDT poolを公開状態とread-only callで確認できます。しかし、公開Live Pools／Farmsは空で、mint / redeem、個別claim、任意数量のswap、価格安定は検証していません。 古いAPRや操作画面を現在の手順に使わず、**site、UI、contract、pool balance、account、transaction、market liquidityを別々の証拠として扱う**ことが必要です。 ## 確認した一次情報 - [Mars Ecosystem公式siteの公開状態と公式導線](): 確認日 2026-08-29 - [Mars Ecosystem公式app: Live Poolsの公開表示](): 確認日 2026-08-29 - [Mars Ecosystem公式app: Live Farmsの公開表示](): 確認日 2026-08-29 - [Mars Ecosystem公式app: 旧reward・IHO・IMOのClaim表示](): 確認日 2026-08-29 - [Mars Ecosystem公式app: stablecoin Mint routeのsigned-out観測](): 確認日 2026-08-29 - [Mars Ecosystem公式docs: USDmのmint・redeem・mintage control設計](): 確認日 2026-08-29 - [Mars Ecosystem公式docs: USDm価格安定設計と前提](): 確認日 2026-08-29 - [Mars Ecosystem公式docs: BNB Smart Chainのcontract addresses](): 確認日 2026-08-29 - [Mars Ecosystem公式Medium: 2022年のLibra Finance構想](): 確認日 2026-08-29 - [Mars Ecosystem公式Medium: 2023年のLending Platform調査・開発報告](): 確認日 2026-08-29 - [Mars Ecosystem公式X: USDm-BUSD流動性をLibraSwapへ移す告知](): 確認日 2026-08-29 - [Mars Ecosystem公式X: BUSD reserve・liquidityをUSDTへ置換する告知](): 確認日 2026-08-29 - [Mars Ecosystem公式token list repositoryの公開commit履歴](): 確認日 2026-08-29 - [BscScan: XMS tokenとverified source](): 確認日 2026-08-29 - [BscScan: USDm tokenとverified source](): 確認日 2026-08-29 - [BscScan: Mars Ecosystem Core contract](): 確認日 2026-08-29 - [BNB Chain公式docs: BSC public JSON-RPC endpoint](): 確認日 2026-08-29 - [Libra Finance: USDm-USDT 2POOLのsigned-out公開表示](): 確認日 2026-08-29 - [BscScan: Libra Finance USDm-USDT 2POOL address](): 確認日 2026-08-29 - [CertiK: Mars Ecosystem audit履歴とfinding status](): 確認日 2026-08-29 - [CertiK 2021 Mars Ecosystem Security Assessment PDF](): 確認日 2026-08-29 --- # Dollaremon（DY・4DP）のその後｜Money PocketとFantom移行を検証 DollaremonのDY・4DP・Money Pocketの仕組み、2021年のFantom／V2移行告知、2026年に確認できるdomain・公開source・contractの状態を整理します。 正規URL: https://3mikan.com/archives/1507 著者: みかん 公開: 2021-06-25T21:18:04.000Z 更新: 2026-08-28T23:45:00.000Z **2026年8月29日時点で、Dollaremonの公式frontendや現在の利用手順は確認できません。** 当時使われた`dollaremon.com`、`dollaremon.finance`、`dollaremon.fi`と各subdomainはDNSで名前解決できず、旧公式Xの`@Dollaremon1`も「ユーザープロフィールが見つかりません」と表示されます。 BNB Smart Chain（BSC）にはDYと4DPのcontractが残り、2026年8月にも`swapToRads`の成功記録があります。しかし、**contractが呼び出せることは、公式serviceの運営、十分な流動性、希望価格での売却、旧資産の回収を意味しません。** 古いURLや検索で見つけた同名siteへWalletを接続しないでください。 > 検証で行っていないこと > > Wallet接続、account入力、message署名、Approve・revoke、farm、pool、swap、bridge、contract write、transaction送信、asset移動は行っていません。運営投稿、公開repository、DNS、signed-outのChrome、Explorer、公式のread-only RPCだけを確認しました。 ## Dollaremonの現在地 | 確認項目 | 2026年8月29日の観測 | ここから言える範囲 | | --- | --- | --- | | 旧公式web | main domainと旧farm・swap・Money Pocket subdomainは`ERR_NAME_NOT_RESOLVED` | 当時のfrontendへ到達できない。検索結果の別siteを公式とは判断できない | | X / Telegram | X profileはnot found。Telegramの公開ランディングは「Dollaremon&CBD CASH」と456 membersを表示 | Telegram URLが残ることは確認できる。最近の投稿、管理者、support継続は未確認 | | 公式GitHub | contractの最終公開commitは2021年6月22日。swap coreは6月2日、peripheryは5月31日 | 公開sourceの更新時点。非公開開発の不存在や現在のdeployed state全体を証明しない | | BSC版DY / 4DP | verified contract、相互参照、最近のtransactionを確認できる | 公式UI、運営継続、market price、liquidity、exitを証明しない | | Fantom版FDY / F4DP | 公表FDYにbytecodeがあり、現在の参照先F4DPをread-onlyで確認できる | V2移行の完了、旧→新交換窓口、現在のfarmやbridgeを証明しない | 2021年のBSC版Dollaremon公開、Fantom版公開、V2停止・再発行告知、公開GitHub更新、2026年のdomainとcontract確認を分ける時系列 ## DY・4DP・Money Pocketは何だったのか Dollaremonは2021年、AMMのswapとfarm / pool、手数料分配を組み合わせたDeFiとして案内されました。運営投稿と公開sourceで使われた主要な名称は次の3つです。 | 名称 | 2021年の設計上の役割 | 読み違えやすい点 | | --- | --- | --- | | DY（DollarYaki） | farm reward、swapやpoolで使うBSC版token | dollar建ての価値、償還、価格維持を保証するstablecoinではない | | 4DP（Four-Dimensional Money Pocket） | 一部farmで得るshare token。DYへ変換でき、Money Pot分配の比率にも使う | 1 4DP = 1 DYが常時・即時・無条件という設計ではない | | Money Pot | fee managerから入る複数tokenを4DP holderへblock単位で分配する仕組み | 表示reward、contract残高、実際に受け取れる価値は同じではない | [DYの公開source](https://github.com/dollaremon/dollaremon-contract/blob/7da44311afbd41ab1743490821eacfdb09f44065/DY.sol)では、ownerまたは指定された4DP contractがDYをmintでき、通常transferではamountの2%をburnして98%をrecipientへ送ります。[4DPの公開source](https://github.com/dollaremon/dollaremon-contract/blob/7da44311afbd41ab1743490821eacfdb09f44065/4DP.sol)では、4DPをburnし、保有block数に応じたpenaltyを引いたDYをmintする`swapToRads`が実装されています。 この`swap`はAMMでDYを買い手へ売る処理ではありません。4DPを消してDYを新規発行するtoken変換です。DYを別tokenや法定通貨へ換えられるか、どの価格でどれだけ売れるかは、別のpoolと流動性の問題です。 ## 「72時間で1対1」はblock数の説明だった 旧docsと旧記事は、4DPを72時間保有すると1:1でDYへ変換でき、早い場合は受取量が70%・80%・90%になると説明していました。BSC deployed contractのread-only値は、最大penaltyが30%、penaltyが0になる期間が`86,400 blocks`です。sourceではpenaltyがblockごとに直線的に減ります。 | 旧表示の目安 | 2021年当時の読み方 | contract上の本質 | | --- | --- | --- | | 直後: 70%受取 | 最大30% penalty | holderの平均取得blockからの経過block数で計算 | | 24時間: 約80% | 約20% penalty | wall-clockの24時間を保存しているわけではない | | 48時間: 約90% | 約10% penalty | block intervalが変われば実時間も変わる | | 72時間: 100% | penalty 0 | deployed値では86,400 blocks到達が条件 | 2021年のBSCは約3秒blockだったため、86,400 blocksは約72時間に対応しました。ところが[BNB Chainの現在の公式docs](https://docs.bnbchain.org/bnb-smart-chain/introduction/)は、hardforkを経たmainnetのblock intervalを約0.45秒としています。単純計算では同じ86,400 blocksが約10.8時間です。実際のblock productionには揺れがあるため、古いfrontendの「72時間」を現在の時計として使えません。 これは利用を勧めるための換算ではありません。**古いDeFiが時間をblock数で実装している場合、chain側の高速化だけでUIの時間説明がずれる**という検証例です。 ## farmとMoney Potには管理権限があった [MasterDollaremonの公開source](https://github.com/dollaremon/dollaremon-contract/blob/7da44311afbd41ab1743490821eacfdb09f44065/MasterDollaremon.sol)では、ownerがpoolの追加・allocation・deposit feeを設定でき、deposit feeとharvest feeは最大10%です。rewardはpoolのallocationと1 blockあたりのemissionから計算され、dev address向けmintも組み込まれていました。 source commentはemission reductionの`28,800 blocks`を「約24時間」と説明していますが、これも2021年当時のblock intervalを前提にした表現です。現在のBSCでは同じwall-clockになりません。 [Money Potの公開source](https://github.com/dollaremon/dollaremon-contract/blob/7da44311afbd41ab1743490821eacfdb09f44065/DollaremonMoneyPot.sol)では、fee managerだけが通常rewardをdepositできる一方、ownerはfee managerの更新、分配tokenの追加・削除、bonus rewardの投入、reward対象外addressの更新を行えます。 この設計から「手数料を4DP holderへ分ける仕組みだった」ことは説明できます。しかし、2021年の旧画面にあったDaily Money Pocketの金額や筆者の損益を、2026年の収益性へ延長することはできません。 ## Fantom公開とV2再発行告知 Bitcointalkのthreadは、Dollaremonの旧siteと`@Dollaremon1`を案内していた「CBD CASH」accountによる運営投稿です。[2021年6月30日の投稿](https://bitcointalk.org/index.php?topic=5333060.40)は、Fantom版を6月25日に公開したとして、次のaddressを掲載しました。 | 役割 | 当初公表address | | --- | --- | | FDY | `0x2Ee2F3676b0AFf2c43A7927A48901ecBf8fdC1B0` | | F4DP | `0x16E4Ee0947527e4A0d6d691a1F92fC191bf8B843` | | masterDollaremon | `0xA475429E8bbF7b318Cc6E5Fb7Df970384d383068` | | Money Pot | `0x2be04A1B00663b04773a518607d5db72B3C5E66e` | | multi-chain | `0x133B87ffF18eB3A36ABDc9a7edd6c097a5156a30` | 同じthreadの7月14日投稿は、Fantom版を一時停止し、FDYとF4DPを再発行すると告知しました。旧farm / poolから全assetをwithdrawし、旧FDY→新FDY、旧F4DP→新F4DPを5%追加で交換する計画、multi-chain V2の再開予定も書かれています。 ここで確認できるのは**運営が移行計画を発表したこと**です。すべての利用者への交換完了、5%追加分の履行、現在の交換窓口は、今回確認した一次資料から独立に証明できません。 ## Fantom contractに残るV2の痕跡 Fantom Operaの[公式public RPC](https://docs.fantom.foundation/build-on-opera/api/public-endpoints)へread-only callを行うと、当初公表されたFDY addressには現在もbytecodeがあり、nameは`Fantom DollarYaki`、symbolは`FDY`です。 重要なのは、FDY contractが現在返す4DP参照先です。 | 読取項目 | 2021年6月の公表 | 2026年8月29日のread-only値 | | --- | --- | --- | | FDY | `0x2Ee2F3676b0AFf2c43A7927A48901ecBf8fdC1B0` | 同じaddressにbytecodeあり | | FDYの`sRads` | 初期F4DPは`0x16E4…B843` | `0x025172c530d46b0093e241d132c93f2a8d65763b` | | 新しい参照先のname / symbol | V2で再発行すると告知 | `Fantom Four-Dimensional Money Pocket` / `F4DP` | | 新しいF4DPの`rads` | FDYとの組合せを想定 | 上記FDY addressを返す | 初期F4DPと現在の参照先F4DPには、どちらもbytecodeが残っています。FDYの設定が別のF4DPへ切り替わった事実は、V2再発行告知と整合するオンチェーン上の痕跡です。ただし、どのsnapshotが使われ、誰が交換を完了し、frontendがいつまで稼働したかまでは分かりません。 ## BSC contractは2026年にも呼び出されている BscScanで確認できるBSC版の正しい組合せは、DYが`0xc07c3a89357171dcbea4b34f92e4c39da4446f45`、4DPが`0xE036460679640C703490DeFB7c2c9c73a7976622`です。DYの`sRads`は4DP、4DPの`rads`はDYを返し、どちらのownerも同じcontract `0x3021730B1a7dfC15D94aC086DA983d36Fd63b51A`です。 2026年8月22日23時26分02秒（JST）の[transaction `0x6fb8…c2d16`](https://bscscan.com/tx/0x6fb8c49af5751b9dc0f60536d8009574c13ddd053f967c09af66a937458c2d16)では、`swapToRads`が成功しました。3,422.700609… 4DPがburnされ、2,397.150170… DYがmintされています。受取量は元の70%で、contractの最大30% penaltyと一致します。 この記録から言えるのは、特定のblockで特定のcontract callが成功し、4DP burnとDY mintが起きたことです。次は証明しません。 - Dollaremonの公式frontendが復旧した - 2021年の運営teamが操作した - DYに継続的な買い手や十分なpool depthがある - 表示価格で希望数量を売れる - 旧farmへ預けたLPやFantom資産を回収できる 公開source、contract bytecode、相互参照、transactionで確認できる事実と、公式UI、運営継続、流動性、換金性、移行完了の未確認領域を分ける図 ## 2021年のfarm戦略は撤回します 旧記事は、DY-BNB farmへ約60ドルを入れ、3日で約4 4DPを得た体験を紹介し、72時間後にDYへ交換する流れを「基本戦略」としていました。画面上のAPRやDY価格、Daily Money Pocketの約0.01ドルという個人記録も掲載していました。 これらは2021年6月の一時点におけるUIと個人結果です。現在の公式URL、reward、価格、liquidity、回収可能性を示しません。次の旧案内を現在の手順として使わないでください。 - farmして4DPを得れば利益になる - 72時間待てば必ず1:1の価値で換金できる - 2% burnでDY価格が上がる - APR表示を将来の受取額として扱う - old domain、検索広告、SNS reply、DMからWalletを接続する 2% burnはtransfer時の供給減少ロジックです。需要、emission、pool depth、slippage、owner権限を相殺して価格を上げる保証ではありません。4DP→DYが1:1でも、DY→他assetのmarket価値は別です。 ## 同名tokenと偽frontendを避ける `DY`、`FDY`、`4DP`は短いsymbolで、検索結果やWalletのtoken listだけではprojectを一意に識別できません。Dollaremonを調べる場合も、次を分けて記録してください。 1. chain名（BSCかFantom Operaか） 2. 省略しないcontract address 3. そのaddressを掲載した2021年の運営投稿 4. Explorerで読むname、symbol、linked contract 5. transaction hash、block number、timestamp 照合はread-onlyでできます。「残高確認」「migration」「救済」「再Claim」のためとしてseed phrase、秘密鍵、recovery phrase、message署名、unlimited Approve、先払い送金を求めるsiteや相手には応じないでください。 ## よくある質問 ### 4DPを持っていれば、今もDYへ交換できますか？ BSCでは2026年8月に`swapToRads`が成功した記録がありますが、この記事は実行を案内しません。固定block数のpenalty、DYの2% transfer burn、gas、流動性、売却先、偽frontendを別に評価する必要があります。contract call成功と資産回収は同じではありません。 ### 「72時間待つ」という旧ルールは今も正しいですか？ deployed parameterは72時間ではなく86,400 blocksです。BSCのblock intervalが約3秒から約0.45秒へ短縮されたため、wall-clockとの対応は変わりました。古いUIや記事の時間表示を現在の手順に使わないでください。 ### Fantom V2への交換は完了したのですか？ 運営が旧FDY／F4DPの再発行と交換計画を告知し、現在のFDYが初期とは別のF4DPを参照することは確認できます。全対象者への履行完了や2026年の交換窓口は確認できません。 ### 最近のtransactionがあるなら、Dollaremonは稼働中ですか？ いいえ。transactionはcontractが呼び出された事実です。公式frontend、継続運営、support、market liquidity、換金性の証明ではありません。 ### Explorerに価格が表示されたら売れますか？ 表示価格、少額の直近trade、希望数量を実際に交換できる価格は別です。poolの深さ、route、slippage、transfer burnで結果が変わります。本記事はswap先や売却手順を案内しません。 ## まとめ Dollaremonは、DY、4DP、Money Pot、farm、swapを組み合わせた2021年のDeFiでした。公開sourceから、DYの2% burn、4DPのblock基準penalty、fee分配、owner controlを確認できます。運営投稿にはFantom公開とV2再発行計画も残り、FDYが初期とは別のF4DPを参照する現在値は、その告知と整合します。 一方、2026年8月29日時点で旧公式webへ到達できず、X profileも見つかりません。BSCに最近のcallがあっても、公式service、運営、流動性、換金性、移行完了は確認できません。 この事例から残すべき教訓は、**contractが動くことと、公式serviceが使えることを同じにしない**ことです。古いDeFiを調べるときは、運営告知、公開source、deployed parameter、current transaction、公式導線を別々の証拠として扱ってください。 ## 確認した一次情報 - [CBD CASH運営投稿: Dollaremon、DY、4DPの初期設計と公開予定](): 確認日 2026-08-29 - [CBD CASH運営投稿: Fantom公開address、multi-chain、V2停止・再発行告知](): 確認日 2026-08-29 - [Dollaremon公式contract repositoryの最終公開commit](): 確認日 2026-08-29 - [Dollaremon公開source: DYのmint権限と2% burn](): 確認日 2026-08-29 - [Dollaremon公開source: 4DPのblock基準penaltyとDY mint](): 確認日 2026-08-29 - [Dollaremon公開source: farm emission、deposit・harvest fee、owner権限](): 確認日 2026-08-29 - [Dollaremon公開source: Money Potの分配とowner・fee manager権限](): 確認日 2026-08-29 - [Dollaremon swap coreの最終公開commit](): 確認日 2026-08-29 - [Dollaremon swap peripheryの最終公開commit](): 確認日 2026-08-29 - [BscScan: BSC版DollarYaki（DY）tokenとverified source](): 確認日 2026-08-29 - [BscScan: BSC版Four-Dimensional Money Pocket（4DP）tokenとverified source](): 確認日 2026-08-29 - [BscScan: 2026年8月22日のswapToRads transaction](): 確認日 2026-08-29 - [BNB Chain公式docs: BSCの現在のblock interval](): 確認日 2026-08-29 - [Fantom Opera公式docs: read-only public RPC endpoint](): 確認日 2026-08-29 - [Fantom Explorer: 2021年公表のFDY address](): 確認日 2026-08-29 - [Fantom Explorer: FDYが現在参照するF4DP address](): 確認日 2026-08-29 - [Dollaremon旧公式X profileの公開状態](): 確認日 2026-08-29 - [Dollaremon・CBD CASH Telegram公開ランディング](): 確認日 2026-08-29 - [Dollaremon旧公式domainのDNS到達確認](): 確認日 2026-08-29 - [Dollaremon旧frontend domainのDNS到達確認](): 確認日 2026-08-29 --- # SafeDollarとTITAN向けエアドロップのその後｜SDO v1事故・v2移行を検証 2021年のTITAN保有者向けSafeDollarエアドロップ、SDO v1の事故、v2移行・補償計画を一次情報で整理し、旧Claim手順と現在確認できる範囲を分けます。 正規URL: https://3mikan.com/archives/1448 著者: みかん 公開: 2021-06-26T12:25:02.000Z 更新: 2026-08-28T23:10:00.000Z **2026年8月29日時点で、2021年のTITAN保有者向けSafeDollar（SDO）エアドロップを新たに受け取れる公式Claim画面は確認できません。** 旧appとdocsはDNSで名前解決できず、当時の公式domainはSafeDollar protocolの操作画面ではなく、フィンランド語の金融系メディアを表示しています。Walletを接続したり、Claim・Approve・swapを試したりしないでください。 この配布はIron Financeの損失を法的に補償する制度ではなく、SafeDollar運営が2021年6月に行った一回限りのsupport / airdrop施策でした。さらに、この記事の初回公開から2日後、SDO v1はreward計算を悪用されました。運営は後日、v1が事故で壊れたとしてv2移行と別の補償計画を発表しています。 > 検証で行っていないこと > > Wallet接続、account入力、message署名、Claim、Approve・revoke、swap、liquidity提供、contract write、transaction送信、asset移動は行っていません。公式発表、公開profile、DNS、Chrome、GitHub、PolygonScanをsigned-out / read-onlyで確認しました。 ## SafeDollarとTITAN向け配布の現在地 | 確認項目 | 2026年8月29日の観測 | ここから言える範囲 | | --- | --- | --- | | TITAN向けSDO airdrop | 2021年6月の公式発表と終了方向の更新が残る | 当時の配布施策を確認できる。現在のeligibilityやClaim権を示さない | | 旧app / docs | `app.safedollar.fi`と`docs.safedollar.fi`は`ERR_NAME_NOT_RESOLVED` | 旧frontendとdocsへ到達できない。別のClaim siteを公式とは判断できない | | 旧公式domain | `safedollar.fi`はフィンランド語のFinTech / finance記事を表示 | 当時のprotocol siteではない。現在の運営主体や移管経緯までは不明 | | 公式Medium / X | Medium最終記事は2021年8月4日。X公開profileで確認できた最新投稿は同年9月19日 | 公開channelの更新履歴。非公開活動や法的な終了を証明しない | | 公式GitHub | `safedollar-contracts`の最終公開commitは2021年5月22日 | 公開sourceの更新時点。現在のdeployed bytecodeとの一致を証明しない | | SDO v1 / v2 | Polygon上に旧v1とv2のtoken contractが残る | contractの存在だけでは、1ドル償還、peg、流動性、公式serviceの稼働を証明しない | 2021年6月の初期エアドロップとTITAN向け配布、SDO v1事故、v2計画、公開更新、2026年の旧appとdocsの到達不能を分ける時系列 ## TITAN向けエアドロップは何だったのか [2021年6月10日のSafeDollar発表](https://safedollar.medium.com/safedollar-the-next-generation-algo-stablecoin-on-polygon-bf1453b50155)では、Basis Cash、Mithril Cash、PolyDoge、Safemoon、QuickSwap、bDollar、Iron Finance、MidasDollarの8 community、合計35,984 walletを対象に100,000 SDOを配る計画でした。 当初の条件は、1 walletにつき約6.89 SDOを一度だけ、100,000 SDOがなくなるまで先着順でClaimするというものです。開始日は2021年6月12日で、4週間後に未請求分をburnすると説明されていました。 その後、Iron FinanceでTITANが急落しました。[6月17日のSafeDollar発表](https://safedollar.medium.com/all-funds-are-safu-safedollar-is-not-affected-by-iron-finance-incident-7bf963253725)は、SafeDollar自体はIron Financeのbank runの影響を受けていないと主張したうえで、TITAN communityへのsupportとして50,000 SDOを割り当てるとしています。対象はincident前のTITAN holder snapshotで決めるという説明でした。 ここで重要なのは、次の3つを同じ「補償」と呼ばないことです。 1. Iron Finance側で発生したTITANの損失 2. SafeDollarがTITAN holderへ配った販促・support目的のSDO airdrop 3. 後日のSafeDollar自身の事故に対して発表したSDO v2 migration / compensation plan [6月20日の公式更新](https://safedollar.medium.com/safedollar-updates-e2f79c966c00)は、初期airdropを終了方向としました。旧記事も6月26日の公開時点で「配布期間は終了」と記録しています。したがって、旧画面の数字やClaimボタンは、2026年の操作手順ではありません。 ## SDO・SDS・SDBはどんな設計だったか SafeDollarは、SDOを1米ドル付近へ誘導することを目標にしたalgorithmic stablecoinとして始まりました。当時の公式説明では、役割の異なる3 tokenを組み合わせる設計です。 | token | 当時の役割 | 注意点 | | --- | --- | --- | | SDO | 1米ドルを目標に供給・taxを調整するtoken | 「目標価格」は法定通貨の裏付けや1対1償還の保証ではない | | SDS | protocolのshare token | 価格、運営権限、liquidityなど別のriskを持つ | | SDB | SDOがpegを下回る局面で使うbond token | bond mechanismがあるだけでpeg回復は保証されない | 公式launch記事は、SDOが1ドル以上ならtaxなし、1ドル未満なら価格差に応じたtax、Jackpot、Boardroomへの配分を使うと説明していました。これは2021年当時の設計説明です。「SDOを1ドルと考えて入れて大丈夫」「安心安全」という意味にはできません。 algorithmic stablecoinは、需要、liquidity、oracle、arbitrage、contract実装、運営権限が同時に機能しなければ目標価格を維持できません。token名、protocolの説明、画面上の価格だけを担保として扱わないでください。 ## 公開2日後にSDO v1で何が起きたか [SafeDollarの2021年6月28日post-mortem](https://safedollar.medium.com/safedollar-post-mortem-analysis-cb2769fe059)によると、問題はPLX v1を預けるreward poolで起きました。PLXはdeposit時に0.15%がburnされるdeflationary tokenでしたが、poolの会計はその性質を安全に扱えていませんでした。 運営の説明を概念的に並べると、次の流れです。 1. 攻撃者がPLXのdepositとwithdrawを繰り返す 2. burnによりpoolが計算に使う`lpSupply`が極端に小さくなる 3. `accSdoPerShare = reward ÷ lpSupply`が異常に大きくなる 4. 過大なpending SDO rewardをharvestする 5. mintされたSDOをliquidity poolへ売却する 公式発表上の損失は202,230 USDCと46,000 USDTです。[攻撃transaction](https://polygonscan.com/tx/0x1360315a16aec1c7403d369bd139f0fd55a99578d117cb5637b234a0a0ee5c14)とattacker addressもpost-mortemから追跡できます。 ただし、post-mortemの「protocol自体は正常でPLX v1 poolだけの問題」という記述は運営自身の当時の評価です。SDOの供給と市場価格が壊れた影響まで含め、現在の安全性を保証する第三者評価には置き換えません。 ## SDO v1とv2、2種類のClaimを分ける [2021年7月1日のMove Forward plan](https://safedollar.medium.com/safedollar-compensation-and-move-forward-plan-c3220a8d339d)で、SafeDollar運営は「SDO v1はexploitでdestroyed」と説明し、incident前snapshotに基づくSDO v2へのmigrationを発表しました。 | Claimの文脈 | 対象 | 当時の発表 | 2026年の扱い | | --- | --- | --- | --- | | 初期airdrop | 8 communityとTITAN holder | 一回限りのSDO v1配布。未請求分は4週間後にburn | 終了済みの歴史記録。操作先を案内しない | | incident後migration | incident前のSDO v1 holder | 同量のSDO v2を4週間vestingでClaimする計画 | 当時発表された計画。現在の請求可否を断定しない | | LP compensation | SDO/USDC・SDO/USDT LP | SDO分をv2、USDC/USDT分をSafeUSDCで補う計画 | 履行完了や現在の償還を独立確認できていない | planではSDO v2を2021年7月12日にlaunchする予定でした。PolygonScanには現在、[旧SDO v1 `0x86bc…d967f`](https://polygonscan.com/token/0x86bc05a6f65efdada08528ec66603aef175d967f)と、[SDO v2 `0x66c5…49a35`](https://polygonscan.com/token/0x66c59dded4ef01a3412a8b019b6e41d4a8c49a35)が別contractとして表示されます。 v2 contractが存在することは、v1とv2を混同しないための証拠です。一方、snapshot対象、vesting済み数量、全LPへの補償完了、現在のClaim権、1ドルでの償還を証明するものではありません。 ## 2026年に確認できること・できないこと 2026年8月29日、PolygonScanのv2 token transfer一覧には、8月26日13時21分31秒（JST）のblock 92,675,376でSDO transferを含む[QuickSwap transaction](https://polygonscan.com/tx/0xc612b9c5c38e3ae044682411ceea690b0f017397f4c0805c85c2c2a04a562661)が表示されました。これは「on-chainでtokenが動いた」という観測です。 しかし、第三者が小さなpoolでswapできることと、公式protocolが運営され、SDOを1ドルで償還できることは別です。Explorerのtoken price、market cap、holder数も、参照元やliquidityを確認せずに価値保証へ使えません。 旧Claimと現在の受取資格、SDO v1とv2、token transferと公式service、Explorer価格と償還可能性を同一視しないための証拠境界 現在の公開情報は、次の境界で読んでください。 - **公式発表が残る**: 2021年に何を発表したかは確認できる。計画の完全な履行や現在の責任主体までは証明しない - **contractが残る**: addressと履歴を確認できる。frontend、安全性、peg、redeemabilityは証明しない - **transferがある**: tokenが移動した事実を確認できる。十分なliquidityや公式活動は証明しない - **domainが表示される**: 現在のweb contentを確認できる。2021年のSafeDollar運営によるsiteとは限らない - **公開更新が止まって見える**: Medium、X、GitHubの公開履歴を確認できる。法人解散や永久終了までは断定しない ## 2021年のClaim・swap手順は撤回します 旧記事には、SafeDollar Protocolへアクセスし、WalletをPolygonへ接続し、Claimボタンを押す手順がありました。また、筆者が約80ドル相当を受け取り、すぐUSDCへswapした体験を紹介していました。 これらは2021年の終了済み施策に関する記録です。現在の期待受取額、公式URL、Claim成功、swap可能性を示しません。次の旧案内を現在の手順として使わないでください。 - `Connect Wallet`を押してClaim対象を調べる - 検索やDMで見つけた「SafeDollar Claim」へWalletを接続する - v1とv2のaddressを確認せずtokenを追加・swapする - Explorerに価格が表示されるため1 SDO = 1 USDと考える - 「補償」「migration」「airdrop」という名前だけで署名する 旧取引の記録を保存したい場合は、既に手元にあるtransaction hash、chain、block timestamp、token contractをread-onlyで照合し、v1 / v2を分けてください。照合だけのために新しいsiteへWalletを接続する必要はありません。 ## 偽Claimと復旧代行に注意する 旧appとdocsが開かない状況では、検索広告、同名domain、SNS reply、DMが公式窓口のように見えることがあります。次を求める相手は止めてください。 - seed phrase、秘密鍵、秘密のrecovery code - 「確認だけ」と説明するmessage署名 - unlimited Approveや不明contractへのtransaction - 補償解除料、税金、gas代などの先払い送金 - remote desktop、画面共有、Wallet fileの送付 public addressやtransaction hashは秘密鍵ではありませんが、保有履歴と結び付く公開情報です。相談時も必要な範囲だけ共有し、相手が示すaddressを2021年の公式発表と同一だと推測しないでください。 ## よくある質問 ### TITANを持っていたら今もSDOをClaimできますか？ 確認できません。公式発表は2021年の一回限りの配布で、未請求分は4週間後にburnする設計でした。旧appは現在DNSで名前解決できません。新しいClaim siteを探して接続しないでください。 ### SDO v2がPolygonScanにあるならSafeDollarは稼働中ですか？ token contractと最近のtransferは確認できますが、公式frontend、docs、継続運営、peg、1ドル償還の証明ではありません。contractの存在とserviceの稼働を分けてください。 ### SafeDollarの補償は完了したのですか？ 2021年7月1日にv2 migrationとLP compensationの計画が発表されたことは確認できます。今回確認した一次情報だけでは、すべての対象者への履行完了や2026年の請求可能性まで独立に確認できません。 ### Explorerに価格があるなら売却できますか？ 価格欄は参照市場、更新方法、poolの深さ、slippageを省略することがあります。表示価格、少額transfer、実際に希望数量を交換できる価格は同じではありません。この記事はswap手順を案内しません。 ### 旧記事で受け取った約80ドルは誤りですか？ 2021年当時の筆者個人の体験記です。現在の価格、一般的な配布額、受取保証としては使えません。歴史的な文脈だけを残し、現在の判断材料から外します。 ## まとめ TITAN保有者向けのSDO配布は、2021年6月の一回限りのairdropでした。その直後、SDO v1はPLX poolのreward accountingを悪用され、運営はv1を壊れたものとしてv2 migrationと別のcompensation planを発表しました。 2026年8月29日時点では、旧appとdocsへ到達できず、main domainも当時のprotocol siteではありません。v2 contractとtransferが残っていても、旧Claimの復活、1ドルpeg、償還可能性、公式serviceの継続は意味しません。 この事例から残すべき教訓は、**airdrop、補償、migration、token contract、価格表示を一つの「価値保証」にまとめないこと**です。古いClaim記事を見つけてもWalletを接続せず、発表日、対象snapshot、v1 / v2 address、現在の公式channelを分けて確認してください。 ## 確認した一次情報 - [SafeDollar運営: 初期airdropとSDO・SDS・SDBの設計](): 確認日 2026-08-29 - [SafeDollar運営: TITAN保有者向けairdrop発表](): 確認日 2026-08-29 - [SafeDollar運営: 初期airdrop終了方向の更新](): 確認日 2026-08-29 - [SafeDollar運営: 2021年6月28日のSDO v1事故報告](): 確認日 2026-08-29 - [SafeDollar運営: v2移行・補償計画](): 確認日 2026-08-29 - [SafeDollar公式Mediumの公開記事一覧](): 確認日 2026-08-29 - [SafeDollar公式Xの公開profile・投稿履歴](): 確認日 2026-08-29 - [SafeDollar旧公式domainの現在の表示内容](): 確認日 2026-08-29 - [SafeDollar旧app URL: DNS・browser到達確認](): 確認日 2026-08-29 - [SafeDollar旧docs URL: DNS・browser到達確認](): 確認日 2026-08-29 - [SafeDollar公式contract repositoryの最終公開commit](): 確認日 2026-08-29 - [PolygonScan: 旧SDO v1 token](): 確認日 2026-08-29 - [PolygonScan: SDO v2 token](): 確認日 2026-08-29 - [PolygonScan: 2021年6月28日の攻撃transaction](): 確認日 2026-08-29 - [PolygonScan: 2026年8月に確認したSDO v2 transferを含むtransaction](): 確認日 2026-08-29 --- # ForTubeの現況｜旧Bankの停止状態と預入・借入の確認手順 ForTubeの公式サイトが開けず旧Bankがpause中の現在、BSC・Ethereumの公式address、fToken、借入残高、allowanceをread-onlyで確認する順番を整理します。 正規URL: https://3mikan.com/archives/1235 著者: みかん 公開: 2021-06-09T22:07:58.000Z 更新: 2026-08-28T22:30:00.000Z **2026年8月29日7時23分（JST）時点で、ForTubeの旧公式サイトとdocsには到達できず、公式GitHubのREADMEに掲載されたBSC・EthereumのBank 4件はすべて `paused() == true` でした。** 確認時点では、2021年の記事にあった通常の預入・借入・返済・引出手順を、そのまま現在の操作として案内できません。 `paused`は確認時点の変更可能なcontract stateです。「永久に終了した」「資産が消えた」「必ず回収できる」のいずれも意味しません。この記事は旧ForTubeを使った可能性がある読者が、chain、account、transaction receipt、Bank、Controller、fToken、allowanceをread-onlyで突き合わせ、署名やtransactionへ進む前に止まるための現況記録です。 > 検証で行っていないこと > > wallet接続、account addressのsite入力、message署名、Approve・revoke、deposit、borrow、repay、withdraw、liquidation、swap、LP作成、farmへの預入、contract write、transaction送信、asset移動は行っていません。公開source、Explorer、DNS、Chrome、read-only RPCだけを確認しています。 ## ForTubeの現在地 | 確認項目 | 2026年8月29日の観測 | ここから言える範囲 | | --- | --- | --- | | 旧公式site / docs | `for.tube`、`www.for.tube`、`app.for.tube`、`wk.for.tube`はDNSでIP addressを取得できず、Chromeは`ERR_NAME_NOT_RESOLVED` | 確認時点で旧frontend・docsへ到達できない。終了理由や復旧予定までは不明 | | 公式GitHub | `thefortube/fortube`の最終公開commitは2023年2月21日 | 公開repoの更新履歴。非公開開発や現在の運営体制を証明しない | | BSC Bank | README掲載のInnovation / Main Bankはblock 118,654,966で`paused() == true` | そのblockで通常writeの停止flagが立っている。将来のstateは変わり得る | | Ethereum Bank | README掲載のInnovation / Main Bankはblock 25,856,702で`paused() == true` | 同上。read可能でも返済・引出の成功を保証しない | | 2023年の事故 | 運営は精度・丸め処理を悪用した攻撃、約80K BUSDの損失、Reserveによる補填、当時の修正を発表 | project自身の説明。独立検証や現在の安全性・補填完了の証明ではない | | Bank 2.0 audit | 2020年9月4日付のSlowMist報告書が公開されている | 提供された特定zip hashと当時のcontract scopeに対する時点評価 | on-chainの観測時刻は、BSC block 118,654,966が2026年8月29日7時23分45秒、Ethereum block 25,856,702が同7時23分35秒（いずれもJST）です。現在の値を確認するときは、この記事の値を固定値として使わず、chain、block number、timestampを一緒に記録してください。 2020年のBank 2.0監査、2021年のV3、2023年の公開commitと事故報告、2026年の旧domain到達不能とBank pauseを分ける時系列 ## 旧ForTube Bankはどんな仕組みだったか [2021年3月のV3発表](https://medium.com/fortube/fortube-v3-new-upgrade-of-4-major-sections-556e04ba0dda)と[公式contract repository](https://github.com/thefortube/fortube)では、ForTubeは複数chain・複数assetを扱うlending marketとして説明されていました。利用者がassetを供給し、その供給を担保として別assetを借り、利用率に応じた金利と清算条件が動く設計です。 旧画面の一つの「Deposit」や「Borrow」を、wallet内の単純なtoken残高として読むと判断を誤ります。公開sourceでは概ね次のcomponentを通ります。 1. **Bank**: 利用者向けのdeposit、borrow、repay、withdrawなどの入口 2. **Controller**: market、担保条件、price oracle、fToken、利用可否を管理 3. **fToken**: marketごとの供給shareと借入状態を記録 4. **underlying token**: BNB、stablecoin、その他ERC-20 / BEP-20など実際の対象asset 5. **oracle / interest rate model**: 担保評価、health、金利計算に関係 そのため、walletにunderlying tokenが見えないことだけで消失とは判断できません。一方、fTokenの`balanceOf(account)`が0より大きいことだけでも、同量のunderlyingを現在引き出せるとは判断できません。exchange rate、market cash、borrow、pause、oracle、token decimalsを分けて読む必要があります。 ## 監査済みという表示の範囲 [SlowMistのFortube Bank 2.0監査報告書](https://github.com/slowmist/Knowledge-Base/blob/master/open-report-V2/smart-contract/SlowMist%20Audit%20Report%20-%20Fortube%20Bank%202.0_en-us.pdf)は、2020年8月25日に依頼を受け、同年9月4日をaudit dateとしています。対象は提供された`Fortube2.zip`の特定SHA-256 hashで、Bank、BankController、FToken、oracle、interest rate modelなど当時のfile群です。 報告書は1件のcritical、4件のmedium、4件のlow riskを記録し、最終結論を`Passed`としました。ただし、報告書自身が発行前までに存在した事実と提供資料に基づく評価であり、発行後のsecurity statusを判断しないと明記しています。 | 境界 | 監査報告書が示すもの | 記事での扱い | | --- | --- | --- | | source snapshot | 2020年に提供された2つのzip hash | 2021年V3、2023年の変更、現在のproxy implementationを自動で含めない | | contract scope | 当時のBank / Controller / FToken等 | frontend、wallet、運営、oracle運用、後続deployment全体の保証にしない | | findings | 当時のissueと最終結論 | 現在の資産回収可否や無事故の証明にしない | | time | audit dateは2020年9月4日 | 2023年の事故報告や2026年のpauseとは別の時点 | 「監査レポートがある」は有用な歴史資料です。「今も安全」「現在のdeployed bytecodeも同じ」「withdrawできる」への言い換えはできません。 ## 2023年の事故報告を現在の保証にしない [ForTube運営の2023年5月6日発表](https://fortube.medium.com/flashloan-reviewed-and-lesson-learned-63001882912e)は、操作されたdepositを繰り返す際の精度・切り捨てに関係する複合攻撃を受けたと説明しています。運営は、損失は約80K BUSD、ForTube Reserveで補填、問題を修正し当時は機能が戻ったと述べました。 これは事故の存在と、運営が当時どう説明したかを知る一次資料です。ただし次の証明には使えません。 - すべての利用者への補填が独立に完了確認された - 事故後の全implementationが公開repoと一致する - 2026年現在も同じ運営・監視・Reserveが機能する - pause中の各marketから現在withdrawできる 公式GitHubの最終公開commit `26971ca…` は2023年2月21日で、この発表より前です。公開sourceの最終更新と事故後のdeployed implementationを同一と推定しないでください。 ## 公式README掲載Bankとpause状態 旧記事はBSCの画面を開き、assetを選び、`Deposit / Withdraw`や`Borrow / Repay`を押す手順でした。現在はまず、歴史的な公式addressとon-chain stateを分けて確認します。 | chain / market | Bank proxy | Controller | 観測block | `paused()` | | --- | --- | --- | ---: | --- | | BSC Innovation | [`0x0cEA…7672`](https://bscscan.com/address/0x0cEA0832e9cdBb5D476040D58Ea07ecfbeBB7672#readProxyContract) | `0xc782…5469` | 118,654,966 | `true` | | BSC Main | [`0x2f4F…Df5A`](https://bscscan.com/address/0x2f4F03eA63B0dB1dcEED3c1C84295bd62Bd5Df5A#readProxyContract) | `0x89Aa…aa70` | 118,654,966 | `true` | | Ethereum Innovation | [`0xdE7B…9ca9`](https://etherscan.io/address/0xdE7B3b2Fe0E7b4925107615A5b199a4EB40D9ca9#readProxyContract) | `0x936E…F9eF` | 25,856,702 | `true` | | Ethereum Main | [`0x2378…43C3`](https://etherscan.io/address/0x2378a77296904C767e6570365ceB5819d34D43C3#readProxyContract) | `0xb283…F094C5` | 25,856,702 | `true` | この4組は、[公式GitHub README](https://github.com/thefortube/fortube)が掲載するBankとControllerです。BscScan / Etherscanの`Read as Proxy`でも代表Bankの`paused`が`True bool`と表示されることを照合しました。 Explorerが示すEIP-1967 implementationは、BSCの2 Bankが`0xa51e…4fe5`、Ethereumの2 Bankが`0x37c7…55e3`です。proxyのimplementation、admin、pauser、Controllerは変更可能な境界です。公開repo最終commitと現在のimplementationについて、source・compiler・bytecodeの完全一致は確認していません。 BscScan / Etherscanが現在のimplementationとして表示するverified sourceでは、deposit、borrow、withdraw、repay、liquidate、token in / out、flashloanが`whenUnpaused`の対象です。したがって観測blockでは、旧記事の通常write pathは停止状態です。read functionが応答すること、contractにcodeやtoken残高があることは、writeの成功や運営継続を意味しません。 ## 旧positionをread-onlyで確認する順番 chainとaccount、transaction receipt、公式BankとController、fTokenの供給shareと借入、underlyingとallowanceを順に照合し、write操作の前で止まる図 ### 1. chainとaccountを固定する 最初に、当時使ったchainがBSCかEthereumかを分けます。旧ForTubeは時期によってPolygonやOECなども告知していましたが、上の4 Bankは公式READMEに現在残るBSC・Ethereumのaddressです。別chainへ同じaddressを当てはめないでください。 使ったaccountも、現在walletで選択しているaccountと同じとは限りません。自分のwallet history、保存したtx hash、Explorerの履歴から候補を絞ります。公開addressは秘密ではありませんが、第三者siteへ入力すると閲覧行動とのlinkageが増える点に注意してください。 ### 2. transaction receiptで操作を分類する 旧UIの記憶やscreen captureより、成功・失敗が確定したreceiptを優先します。chain、from、to、method、status、block time、eventを記録します。 - `Approve`はtokenのspenderへallowanceを設定した記録で、depositの証拠ではない - `Deposit`は供給側positionの手掛かり - `Borrow`は借入元本と利息計算の手掛かり - `Repay`は一部返済か全返済かをreceiptと後続stateで確認する - `Withdraw`は要求額ではなく、statusと実際のTransfer eventまで分ける - swap、LP作成、Autofarm depositはForTube Bankとは別contractのposition receipt、calldata、eventの読み分けは[ABI・calldata・event logの確認順](/archives/6005)、反映されないtransactionは[receiptから戻る確認手順](/archives/6004)も参照できます。 ### 3. BankとControllerを公式記録へ結ぶ receiptの`to`を、検索結果やtoken symbolではなく、公式READMEのBank / Controllerと照合します。proxyならimplementationも同じblock付近で記録します。 次に`paused()`をread-onlyで確認します。記事執筆時の`true`を現在値として転載せず、確認したblockとtimestampを残します。別address、別chain、別marketならこの記事の観測を流用できません。 [verified contract・proxy・ABIの確認境界](/archives/1005)で、verified表示が安全証明ではない理由も確認してください。 ### 4. ControllerからmarketとfTokenを確認する 公開sourceのControllerには、market一覧を返す`getAllMarkets`、underlyingからfTokenを引く`getFTokeAddress`、accountが担保に使うmarketやliquidityを読むfunctionがあります。 確認したいのは、少なくとも次の組です。 1. chain 2. Bank 3. Controller 4. fToken address 5. underlying token address 6. token decimals 7. deposit / borrow / withdraw / repayの利用停止flag 名前やsymbolだけで同一tokenと判断しません。Controllerが返すfTokenと、receiptに出たmarket、公式記録、Explorerのverified sourceを組み合わせます。 ### 5. 供給share、借入、cashを別々に読む 公開fToken sourceには、`balanceOf(account)`、`borrowBalanceStored(account)`、`getAccountState(account)`、`exchangeRateStored()`、`totalCash()`、`totalBorrows()`などがあります。 | 値 | 主に示すもの | 単独では分からないこと | | --- | --- | --- | | fToken `balanceOf` | accountの供給share | 現在受け取れるunderlyingの確定量 | | `borrowBalanceStored` | 保存済みの借入状態 | 最新blockまで利息反映した最終返済額 | | `exchangeRateStored` | shareとunderlying換算の手掛かり | market cash不足やpauseを越えた引出成功 | | `totalCash` | market contract側のcash指標 | 自分の全額引出可否、tokenの市場価値 | | `totalBorrows` | market全体のborrow指標 | 自分のdebtや清算risk | fToken残高をunderlying tokenの表示数量としてコピーしないでください。decimalsとexchange rateの桁を誤ると大きくずれます。また、`getAccountLiquidity`やhealth factorはoracleとmarket設定に依存し、revert、無効値、古い値の可能性があります。dashboardの色や一つの比率だけで安全余裕を決めません。 ### 6. allowanceをpositionと分ける 旧記事は1inchの`Infinite Unlock`やForTubeでのApproveを案内していました。Approveはowner、token、spender、chainの組で残ります。 公開ForTube sourceのdeposit flowでは、underlying tokenを引くspenderとしてControllerが関係します。過去のreceiptと実際の`allowance(owner, spender)`を照合し、Bank、Controller、router、LP farmを同じspenderだと思わないでください。 > Approve ≠ Deposit ≠ fToken share ≠ Borrow ≠ LP position walletをdisconnectしてもallowanceは自動で0になりません。一方、revokeも署名とgasを伴うon-chain transactionです。本記事では実行手順を掲載しません。[Spending capとrevokeの確認手順](/archives/6007)で、owner・token・spenderの読み方とwrite前の確認事項を整理できます。 ## 2021年の高利回り・MAX借入手順は撤回します 旧記事は、BNBを預け、ARPAを`MAX`近くまで借り、1inchで交換してBNB-ARPA LPを作り、Autofarmの高APYで借入金利を上回るという流れを紹介していました。これは現在の推奨ではありません。 | 旧記事の表現 | 現在の記事での扱い | | --- | --- | | ARPAの借入APRよりAutofarm APYが高いので「ペイできる」 | APY、borrow rate、reward価格、LP比率、liquidity、gasは別々に変動する。利益保証として使わない | | 借入画面で`MAX`を選ぶ | price・oracle・担保率の小さな変化でも清算余地を減らすため、推奨を撤回 | | health index 1.36は「そこまで心配しなくてよい」 | asset volatility、oracle、利息、清算条件を欠いた一時値。安全判定として撤回 | | 1inchで`Infinite Unlock` | 継続的なspender権限。現在の操作案内から削除 | | LP作成後にAutofarmへdeposit | ForTubeとは別のpair、router、farm、pool ID、allowance、receiptとして追跡 | | farm.armyで全体を確認 | 第三者推定値は補助情報。official addressとon-chain receiptの代わりにしない | LP tokenがwalletにない場合も、ForTubeの借入、DEXのLP作成、Autofarmのfarm depositを順に分けます。PancakeSwap系LPの確認は[V2・V3 positionの見分け方](/archives/821)、farmのpool IDは[MasterChefの_pidを照合する方法](/archives/1791)も参照してください。 ## write操作へ進まず人手reviewへ回す 旧positionらしい値が見つかっても、`paused == true`のまま直接contractへtransactionを送らないでください。少なくとも次のread-only記録を揃え、EVM lending contractとproxy upgradeを読める第三者へ確認を依頼します。 1. chain ID、account、確認block、timestamp 2. deposit / borrow / repay / withdraw / approveのtx hashとreceipt 3. 公式記録に結び付くBank、Controller、proxy implementation 4. fToken、underlying token、decimals、market設定 5. fToken balance、borrow balance、exchange rate、market cash 6. owner・token・spenderごとのallowance 7. 現在のpause、admin / pauser、oracleの状態 8. 期待する操作と受取asset、失敗時の影響 検索広告、復旧を名乗るDM、旧domainのclone、同名token、秘密鍵・seed phrase・remote accessを求めるsupportは使わないでください。人手reviewに必要なのは公開address、tx hash、read結果です。秘密鍵やseed phraseではありません。 ## よくある質問 ### ForTubeはサービス終了しましたか？ 2026年8月29日時点で旧公式site / docsへ到達できず、公式README掲載Bank 4件はpause中です。しかし、終了を明記した現在の公式発表は確認できていないため、「永久終了」とは断定しません。 ### fTokenが残っていれば引き出せますか？ fTokenは供給shareの手掛かりですが、それだけでは判断できません。Controllerとの対応、exchange rate、underlying decimals、market cash、pause、oracle、借入・担保状態を確認する必要があります。執筆時点の通常Bank write pathはpause中で、個別の引出可否は未確認です。 ### 借入が残っているかはwallet残高で分かりますか？ 分かりません。borrowed tokenをすでにswap・LP化・別accountへ移動していても、debtはmarket側に残り得ます。receipt、Controller、fTokenのborrow stateを組み合わせます。 ### 監査済みならdirect contractを使っても安全ですか？ いいえ。確認できた監査は2020年の特定file snapshotが対象です。現在のproxy implementation、admin state、oracle、liquidity、frontend、事故後の変更を包括する保証ではありません。 ### 公式siteが再び表示されたら接続してよいですか？ 表示されることだけでは不十分です。domainの公式な継続性、TLS、公式channelからの案内、Bank / Controller / implementation、pause、transaction previewを独立に確認してください。この記事の古いaddressやscreenをwallet接続の根拠にしないでください。 ### ARPAやBNB-ARPA LPはForTube残高ですか？ 同じとは限りません。ARPA借入はForTube側のdebt、swap後のtokenはwalletまたはrouter、BNB-ARPA LPはpair token、Autofarm depositはfarm contract側のpositionです。それぞれ別のreceiptとaddressで追跡します。 ## まとめ 2021年のForTube操作記事を、現在のdeposit・borrow推奨として使わないでください。2026年8月29日の観測では、旧公式site / docsへ到達できず、公式README掲載のBSC・Ethereum Bank 4件はすべてpause中でした。 旧positionを確認するときは、chainとaccountから始め、receipt、公式Bank / Controller、fToken、underlying、borrow、allowanceの順で証拠をつなぎます。contractの存在、監査PDF、fToken残高、一つのhealth factorだけで、稼働・安全・回収成功を決めないことが重要です。 この記事の次回確認期限は2026年9月29日です。domain、公式更新、proxy implementation、pause stateのどれかが変わった場合は、期限前でも記述を更新します。 ## 確認した一次情報 - [ForTube旧公式URL: DNS・browser到達確認](): 確認日 2026-08-29 - [ForTube公式contract repository・deployed address一覧](): 確認日 2026-08-29 - [ForTube公式repositoryの最終公開commit](): 確認日 2026-08-29 - [ForTube運営: 2023年5月の攻撃に関する発表](): 確認日 2026-08-29 - [ForTube運営: 2021年3月のV3発表](): 確認日 2026-08-29 - [SlowMist: Fortube Bank 2.0監査報告書](): 確認日 2026-08-29 - [BscScan: BSC Innovation Bank proxy](): 確認日 2026-08-29 - [BscScan: BSC Main Bank proxy](): 確認日 2026-08-29 - [Etherscan: Ethereum Innovation Bank proxy](): 確認日 2026-08-29 - [Etherscan: Ethereum Main Bank proxy](): 確認日 2026-08-29 --- # 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を同一視しないでください。 2021年のFrankenstein Finance公開・監査・最終commitから、2026年の旧domain到達不能とchain上に残るcontractまでを分ける時系列 ## 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で探す順番 chainとaccount、deposit receipt、MasterChefのpool IDとuserInfo、strategy、underlying farm、allowanceを順に照合し、write操作の前で止まる図 ### 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到達確認](): 確認日 2026-08-29 - [FrankenDefi公式GitHub organization](): 確認日 2026-08-29 - [FrankenDefi公式contract repository](): 確認日 2026-08-29 - [Frankenstein Finance旧公式README](): 確認日 2026-08-29 - [TechRate: Frankenstein smart contract security audit](): 確認日 2026-08-29 - [TechRate監査対象commit](): 確認日 2026-08-29 - [監査報告に記載された修正commit](): 確認日 2026-08-29 - [Internet Archive: 旧公式Smart Contracts](): 確認日 2026-08-29 - [Internet Archive: 旧公式Emergency Withdraw BSC](): 確認日 2026-08-29 - [Internet Archive: 旧公式Emergency Withdraw FTM](): 確認日 2026-08-29 - [BscScan: Frankenstein Finance FRANK token](): 確認日 2026-08-29 - [BscScan: Frankenstein MasterChef](): 確認日 2026-08-29 - [FTMScan documentation: Explorer・APIのdeprecated表示](): 確認日 2026-08-29 - [Fantom Opera公式docs: chain ID・public RPC](): 確認日 2026-08-29 - [Sonic Labs: Fantom Opera維持方針の2026年6月更新](): 確認日 2026-08-29 --- # ApeBoardの現況｜Nansen Portfolioへの移行と残高確認の注意点 ApeBoardの旧URLが現在どこへ移動するか、Nansenによる買収発表と現行Portfolioの公開範囲を整理。画面上の残高をオンチェーン記録と照合し、読み取り・ウォレット・資産操作の境界を確認する方法を解説します。 正規URL: https://3mikan.com/archives/1782 著者: みかん 公開: 2021-07-18T19:01:01.000Z 更新: 2026-08-28T21:10:45.000Z **2026年8月29日時点でApeBoardの旧URLはNansen Portfolioへ移動します。** Nansenは2022年5月17日にApe Boardの買収を発表しており、現在は`apeboard.finance`と旧Dashboard URLのどちらも`app.nansen.ai/portfolio`へredirectされます。 ただし、「旧URLが移動すること」「NansenがApe Boardを買収したこと」「旧ApeBoardの全機能が同じ条件で提供されていること」は別の主張です。この記事では、旧ApeBoardの操作手順を現行手順として使わず、現在の公開画面で確認できる範囲と、Portfolio表示をオンチェーン記録で照合する順番を整理します。 > 読み取りと資産操作を分ける > > 本記事の確認では、NansenへのSign In／Sign Up、アドレス登録、外部ウォレット接続、Nansen Walletの作成、deposit、withdraw、trade、署名、approval、transaction送信を行っていません。画面が残高を表示することは、資産がその画面に保管されていることや、現在すぐに引き出せることを意味しません。 ## ApeBoardの現在地を先に確認する 今回、`https://apeboard.finance/`と旧`/dashboard`へ直接アクセスすると、どちらもNansen Portfolioへ移動しました。Nansenの未ログイン画面にはPortfolio、Nansen Wallet、外部ウォレットを使う資産追跡、deposit・withdraw・tradeなどの案内がありますが、個別walletの残高やpositionは表示されていません。 | 確認項目 | 2026年8月29日の観測 | ここから言える範囲 | | --- | --- | --- | | ApeBoard旧トップ | Nansen Portfolioへ301 redirect | 旧URLの現在の到達先 | | ApeBoard旧Dashboard | 同じNansen Portfolioへ301 redirect | 2021年のApeBoard UIは表示されない | | Nansen買収発表 | 2022年5月17日の公式記事が公開中 | NansenがApe Board買収を発表した歴史 | | Nansen未ログイン画面 | Portfolio、Sign In／Sign Up、Nansen Wallet等を案内 | 公開コピーと入口。ログイン後の利用可否や個別表示は未確認 | | Portfolio API文書 | wallet balanceとDeFi holdingsの集計項目を説明 | 集計構造の公開仕様。Web UIの全実装と同一とは限らない |
Nansen Portfolioの未ログイン公開画面でPortfolio、Nansen Wallet、外部ウォレット追跡の案内が表示されている
旧ApeBoard URLから到達したNansen Portfolioの公開画面。wallet未接続・未ログインで確認し、個人のaddressやbalanceは表示していない。
このredirectは現在の到達先を示す観測です。ApeBoardが独立した製品名として今後どう扱われるか、旧機能が一対一で移植されたか、Nansenの料金・対応chain・利用条件が将来も同じかまでは証明しません。利用時はNansenの現行画面、公式文書、利用条件を改めて確認してください。 ## 2021年の紹介からNansenへの移動まで 旧記事は2021年7月時点のApeBoardを、複数chainのwallet残高、運用額、LP内のtoken構成をまとめて見るDashboardとして紹介していました。当時のProfile登録、address追加、`View Dashboard`、対応chain、表示金額は歴史的な画面記録です。 | 日付 | 出来事 | 記事での扱い | | --- | --- | --- | | 2021-07-19 | 3MIKANの旧ApeBoard紹介記事を公開 | 当時のUI・対応先・表示例としてのみ扱う | | 2022-05-17 | [NansenがApe Board買収を発表](https://nansen.ai/post/building-the-super-app-of-web3-with-ape-board) | 買収と当時の統合方針を示す公式発表 | | 2026-08-29 | ApeBoard旧URLからNansen Portfolioへのredirectを確認 | 現在の到達先として記録 | 買収発表には、Ape Boardを無料で開かれた状態に保つという当時の方針や、両製品の機能を組み合わせる計画も書かれていました。これは2022年に発表された計画です。2026年現在の価格、アカウント条件、機能提供、対応chainの保証として引用しません。 旧記事では公開されている第三者addressを例にし、具体的な運用額を掲載していました。公開chainのaddressは読み取れても、そのaddressを人物やSNSアカウントと結び付けて再掲載するとプライバシー上の文脈が増えます。今回の改稿では第三者address、残高、具体的な運用額を継承していません。 ## 現在のNansen Portfolioで公開確認できた範囲 未ログインのNansen Portfolioでは、Portfolioの入口に加え、次の公開コピーを確認しました。 - Nansen Walletを使ってアプリ内でcryptoを管理し、deposit・withdraw・tradeできるという案内 - 外部walletでassetを追跡するAll-in-One Crypto Trackerの案内 - Home、Trade、Smart Money、Tokens、Profiler、Chains、Portfolio、Walletなどのnavigation - Sign InとSign Upの入口 ここで確認できたのは**機能の案内**です。ログイン後のPortfolio作成手順、address登録方法、表示できるprotocol、Nansen Walletの鍵管理、入出金・取引の確認画面までは未検証です。 [NansenのPortfolio Tracker公式ページ](https://nansen.ai/crypto-portfolio-tracker)は、複数chainのPortfolio、PnL・transaction表示、外部wallet、Privyを利用するnon-custodialなNansen Walletを案内しています。non-custodialという説明だけで、復元、端末変更、認証、対応asset、手数料、各transactionの安全性を判断しないでください。実際に使う場合は、作成前に最新の鍵管理・復元・利用条件を確認する必要があります。 ## Portfolio表示はオンチェーン証拠そのものではない Portfolio trackerは、chainから読める値をそのまま一行に並べるだけではありません。protocolごとのposition解釈、token metadata、price、indexing、表示上の集約が加わります。 ApeBoard旧URLからNansen Portfolioへ移動し、読み取り・追跡とアカウント・ウォレット・資産操作を分け、画面表示と出金可能額を区別する図 [Nansen Portfolio API文書](https://docs.nansen.ai/api/portfolio)では、Portfolio summaryをDeFi positionとwallet balanceの合計として扱い、DeFi holdingsをdeposit・lending、borrow、staking、position、locked、reward、farmなどに分類しています。API keyが必要なAPIの説明であり、未ログインのWeb画面にすべて同じ項目が出るという意味ではありませんが、集計値が複数の層から構成されることを確認できます。 | 証拠レイヤー | 例 | ずれる主な理由 | | --- | --- | --- | | wallet balance | native coin、ERC-20等の`balanceOf` | chain・account・token contractの取り違え | | protocol state | deposit、borrow、stake、LP、NFT position | adapter未対応、pool移行、position形式の違い | | transaction・event | deposit、withdraw、transfer、mint、burn | index遅延、internal call、失敗txの誤読 | | token metadata | symbol、decimals、logo | 同名token、誤ったdecimals、偽token | | price source | token価格とUSD換算 | 価格源、流動性、更新時刻、depeg | | tracker UI | protocol別・chain別の集計 | cache、分類、重複除外、表示filter | したがって、次の二つを分けます。 - **trackerに出ない ≠ 資産が消えた**：別chain、別account、未対応protocol、古いcontract、staking中、index遅延などを確認する - **trackerに金額が出る ≠ その金額を今すぐ出金できる**：lock、debt、reward、LP構成、price impact、contract状態、withdraw routeを確認する ## 読み取り・アカウント・資産操作の境界 「Portfolioを見る」ための行為は、すべて同じ権限ではありません。画面のボタン名だけでなく、何を渡し、何がchain上で変わるかを確認します。 | 段階 | 渡す情報・起きる変化 | 主な注意点 | | --- | --- | --- | | 公開Explorerで読む | public address、tx hash。chain上の変化なし | addressと本人情報を結び付けて共有しない | | trackerへaddressを登録 | public address、account上のlabel等。通常はchain上の変化なし | service側にaddressと利用accountの関連が残り得る | | NansenへSign In | email、認証情報等。chain上の変化なし | phishing domain、account recovery、session管理 | | 外部wallet接続 | account address、chain、接続許可。接続だけなら通常はchain上の変化なし | 接続後のmessage署名やtransactionを別に読む | | 組み込みwalletを作成 | wallet作成・認証・復元に関する情報。作成だけでは通常はchain上の変化なし | 鍵管理、復元、端末変更、提供者の最新説明 | | deposit・withdraw・trade | asset、amount、recipient、route。transaction次第でstateが変わる | network、contract、fee、minimum received、宛先 | | signature・approval・送信 | messageまたはspender権限、calldata。approvalや送信でstateが変わる | unlimited allowance、悪意ある署名、実資産移動 | `Connect`、`Sign`、`Approve`、`Deposit`は同義ではありません。接続後に出る署名がlogin用messageなのか、token allowanceなのか、assetを動かすtransactionなのかをwallet側で読みます。address確認だけが目的なら、署名や資産操作へ進む必要はありません。 ## 残高やpositionをExplorerで照合する順番 [Block explorerの基礎](https://ethereum.org/developers/docs/data-and-analytics/block-explorers/)を使い、trackerとは独立したread-onlyの証拠をそろえます。EVM chainを例にしていますが、chainごとにExplorer、account形式、program・contract、token形式は異なります。 ### 1. chainとaccountを固定する 最初にEthereum、BNB Chain、Polygonなど対象chainを確定し、当時使ったaccount addressとExplorerを一致させます。同じ見た目のaddressでも、別chainの履歴を見れば別の残高です。 ### 2. wallet内のasset contractを確認する native coinとtokenを分け、tokenはsymbolではなくcontract address、decimals、発行元を確認します。同名・同symbolのtokenは作成できるため、trackerのlogoだけを根拠にしません。 ### 3. 最初のdeposit transactionを探す protocolへ預けたtransaction hashがあれば、status、from、to、method、token transfer、event logsを確認します。wallet残高が減ったことだけで、どのpoolやpositionへ入ったかは確定しません。 ### 4. protocol contractとposition識別子を記録する V2 LP tokenならPair contractと残高、V3ならNFT position managerとtoken ID、farmならpool IDとuser state、lendingならdeposit token・debtを分けます。ABIとevent logsの読み方は[transactionとeventを照合する手順](/archives/6005)を参照してください。 ### 5. 現在stateと入出金履歴を一本化する deposit、追加deposit、claim、withdraw、transferを時刻順に並べ、現在のcontract stateと照合します。成功receiptがあるか、assetの受取先がどこか、positionが別accountへ移っていないかを確認します。[トランザクションが反映されないときの確認順](/archives/6004)も併用できます。 ### 6. priceと出金可能性を別に確認する 画面のUSD換算はprice sourceに依存します。positionのshare、underlying asset、debt、lock、未回収rewardを確認し、表示額をそのままwithdraw quoteとみなしません。実行を検討する場合も、まず現行protocolの公式domain・contract・withdraw条件を確認し、受取assetとminimum receivedをtransaction前に読みます。 ### 7. allowanceはpositionとは別に確認する 過去にtoken approvalを与えている場合、owner、token contract、spender、allowance、chainを確認します。残高がtrackerへ出ないことと、spenderに権限が残ることは別問題です。[Spending capとrevokeの確認手順](/archives/6007)では、disconnectとrevokeの違いを説明しています。 Revokeはon-chain transactionでgasが必要です。ApeBoardやNansenを名乗るDM・広告から接続せず、信頼できるwalletまたはExplorerでspenderとcalldataを確認してください。 ## LPはV2 tokenとV3 NFT positionを分ける 旧ApeBoard記事はLPの「金額」と「中のtoken数」を一括して紹介していましたが、LPの所有形式はprotocol versionで異なります。 | 形式 | 主な識別情報 | trackerに出ないときの確認 | | --- | --- | --- | | V2型LP | Pair contract、LP token balance、reserve、pool share | walletかfarm contractのどちらがLP tokenを持つか | | V3型position | NFT contract、token ID、pool、fee tier、price range | owner、liquidity、range、closed状態、別accountへのtransfer | | farm・staking | staking contract、pool ID、user amount、reward debt等 | wallet残高ではなくstaking contractのuser state | PancakeSwapの現行例は[V2 LP tokenとV3 NFT positionの見分け方](/archives/821)、価値の変化は[インパーマネントロスの計算](/archives/580)で確認できます。V2 LPをcontractから直接扱う必要がある場合も、[addLiquidityの引数](/archives/1663)と[removeLiquidityの引数](/archives/1788)を分け、推測したpairやpoolへtransactionを送らないでください。 ## Portfolioに表示されないときのチェックリスト 1. 旧ApeBoardのbookmarkではなく、現在の最終URLと運営主体を確認した 2. 使ったchainとaccount addressを確定した 3. trackerのchain・protocol・asset filterを確認した 4. wallet balance、protocol state、transaction receiptを別々に確認した 5. V2 LP token、V3 NFT position、farm stakeを同じ形式として探していない 6. token symbolではなくcontract addressとdecimalsを確認した 7. USD表示と、実際のunderlying amount・debt・lockを分けた 8. 登録や閲覧だけを目的に、不要な署名・approval・送信へ進んでいない 9. 不明な場合はtx hash、contract address、token ID、pool IDを保存し、transactionを止めた ## よくある質問 ### ApeBoardは終了したのですか？ 2026年8月29日時点で旧ApeBoard URLはNansen Portfolioへredirectされ、旧UIは表示されません。Nansenは2022年にApe Board買収を発表しました。ただし、この二点だけからブランド・backend・全機能の恒久的な終了や完全移行までは断定しません。 ### 2021年と同じ方法でaddressを入れれば見られますか？ 旧記事のProfile、address追加、`View Dashboard`は2021年のApeBoard UIの手順です。現在のNansenで同じ操作名・保存条件が使えるとは限りません。今回の未ログイン確認ではaddressを入力せず、ログイン後の登録手順も未検証です。 ### trackerにpositionが出ないと資産は失われていますか？ それだけでは判断できません。chain、account、deposit receipt、protocol contract、position識別子、current stateの順に確認します。adapter未対応やindex遅延と、実際のwithdraw・transferは別の原因です。 ### Portfolioに100万円と出れば100万円を出金できますか？ 同じとは限りません。価格更新、流動性、debt、lock、未回収reward、LPのunderlying構成、price impact、withdraw feeなどで結果が変わります。表示値は現在のwithdraw quoteや受取保証ではありません。 ### 公開addressなら他人の残高を掲載してもよいですか？ 公開chainから読めることと、特定の人物・SNS・行動履歴へ結び付けて再掲載することは別です。調査や説明には自分が共有権限を持つaddress、または個人との関連を示さない検証用データを使い、不要なaddress・残高は公開しないでください。 ### Nansen Walletを作ればApeBoardの資産が移りますか？ そのような自動移動を示す根拠は確認していません。tracker表示、外部wallet、組み込みwallet、depositは別の機能です。新しいwalletを作る前に鍵管理と復元条件を確認し、asset移動はchain、recipient、amount、fee、transaction内容を別途確認してください。 ## まとめ ApeBoardの旧URLは、2026年8月29日時点でNansen Portfolioへ移動します。Nansenは2022年にApe Board買収を発表していますが、旧ApeBoardの2021年UI、対応chain、登録手順、表示例を現在のNansenへそのまま当てはめることはできません。 Portfolio trackerは全体像をつかむ入口です。資産の存在や出金可否を確定するときは、chain、account、token contract、deposit receipt、protocol state、position識別子、price、allowanceを分けて確認してください。表示されないことを資産消失と決めず、表示されたUSD額を出金可能額とも決めず、読み取りから署名・approval・transactionへ移る境界で一度止まることが大切です。 ## 確認した一次情報 - [ApeBoard旧URL: 現在のredirect確認](): 確認日 2026-08-29 - [Nansen Portfolio: 未ログイン公開画面](): 確認日 2026-08-29 - [Nansen: Ape Board買収発表](): 確認日 2026-08-29 - [Nansen: Crypto Portfolio Tracker](): 確認日 2026-08-29 - [Nansen API: Portfolio endpoints](): 確認日 2026-08-29 - [Nansen API: Endpoints overview](): 確認日 2026-08-29 - [Nansen API: Portfolio endpoint changelog](): 確認日 2026-08-29 - [ethereum.org: Block explorers](): 確認日 2026-08-29 --- # Growing.fiの現況｜2021年incidentと旧positionの確認手順 Growing.fiで2021年に公表されたincident、補償plan、Growing Farm退役の経緯と、現在のdomain状態を一次情報から整理。旧position・transaction・allowanceをExplorerで確認する順番を解説します。 正規URL: https://3mikan.com/archives/1534 著者: みかん 公開: 2021-06-26T14:08:44.000Z 更新: 2026-08-28T20:48:22.000Z Growing.fiは、ウォレット内の資産をまとめて表示するDashboardと、Growing Farmのpool・vaultを提供していたDeFi projectです。旧記事では2021年6月の画面、APR、GROWを使うPRO機能を、利用できるサービスとして紹介していました。 しかし、**2026年8月29日時点でgrowing.fiは旧dappを表示せず、ドメイン販売ページへ移動します。** また、公式チームは2021年9月のGrowing Farm incident、project売却方針、補償planを公表し、同年10月にはGrowing Farmを退役させてBonsai Farmを開発すると発表していました。 この記事はGrowing.fiの現在の使い方や投資先を案内するものではありません。公式発表で確認できる経緯と、自分の旧position・transaction・allowanceを別々の証拠から確認する順番を整理します。ウォレット接続、署名、approval、revoke、claim、withdraw、token購入、資産移動は行っていません。 ## 2026年8月29日時点の現況 今回、`https://growing.fi/`、`https://www.growing.fi/`、旧補償用subdomainへアクセスすると、いずれもCatcha.fiの`growing.fi`販売ページへ移動しました。現在のページは旧Growing.fi dappではなく、ウォレットを接続する画面でもありません。 | 確認項目 | 今回の結果 | ここから言えること | | --- | --- | --- | | `growing.fi` | domain販売ページへredirect | 旧dappはこのdomainで表示されていない | | `www.growing.fi` | 同じ販売ページへredirect | `www`側にも旧UIは確認できない | | 旧補償用subdomain | 同じ販売ページへredirect | 現在のclaim受付や個別補償状況は確認できない | | Growing.fi contracts | [GitHub repository](https://github.com/growingfi/contracts)は公開 | 2021年の公開codeと履歴は読める | | Bonsai Farm core | [GitHub repository](https://github.com/bonsaifarm/core)は公開 | 2021年の公開codeと履歴は読める | この観測だけから、旧運営主体の現在の状態、すべてのfrontendの有無、個別の補償結果までは分かりません。「domainが販売中」と「projectの全活動が恒久的に終了した」は同じ主張ではないため、この記事では前者だけを現在の事実として扱います。 現在のdomain所有者や、Growing.fiを名乗る別サイトへウォレットを接続しないでください。旧記事のbookmarkや検索結果から開いた場合も、URL、運営者、chain、contract addressをゼロから照合する必要があります。 ## Growing.fiは何を提供していたのか 2021年当時のGrowing.fiには、ウォレットのNet Worth、token、lending、farmなどをまとめるDashboardと、Growing Farmのpool・vaultがありました。旧記事は、GROWのstakeによるPRO機能、Profit Reward、IGO、USDT vaultのAPYなども紹介していました。 これらは**2021年当時の画面と条件の記録**です。現在の提供、利回り、流動性、価格、withdraw可否を示す証拠にはなりません。旧APR、TVL、手数料、GROWの価格、PRO条件、BANANA・SWAMPの運用先は現行案内から外しました。 公式GitHubの公開履歴も2021年で止まっています。repositoryが公開中・非archiveであることは、frontend、indexer、RPC、contract、管理鍵、流動性が現在も動く証明ではありません。 ## 2021年incidentから現在までの時系列 公式発表と今回の観測を、役割の異なる証拠として並べます。 | 日付 | 公式発表・観測 | 読み取れる範囲 | | --- | --- | --- | | 2021-09-14 | [Growing Farm incident report](https://medium.com/@GrowingFi/growing-farm-sep-14th-incident-report-71de3abd172a) | BSC・Polygonのv2 poolが攻撃され、公式推計で約120万ドルの損失が発生したとの報告 | | 2021-09-14 | [Growing.fi projectの売却方針](https://medium.com/@GrowingFi/the-growing-fi-project-is-on-sale-df8b8f12a70d) | Dashboard、BSC・Polygon Farm等を含むprojectを売却すると発表 | | 2021-09-15 | [補償と今後のplan](https://medium.com/growingfi/updates-on-the-compensation-and-going-forward-plan-3bd94f66ed25) | 10万ドルの拠出、Farmの分離・rebrand、GROW・PLOW emission停止などを発表 | | 2021-09-18 | [補償planの詳細](https://medium.com/growingfi/growing-farm-incident-compensation-plan-details-90905985644f) | 99,361 USDC、tier別の扱い、rGROWを用いる案と予定日を公表 | | 2021-10-28 | [Bonsai Farmの発表](https://medium.com/@GrowingFi/announcing-bonsai-farm-and-the-bonsai-token-45b4d6ae7102) | Growing Farmを退役させ、Bonsai Farmを開発すると説明 | | 2026-08-29 | `growing.fi`の直接確認 | 旧dappではなくdomain販売ページへ移動 | 2021年9月のincident、project売却方針、補償plan、同年10月のGrowing Farm退役発表、2026年のdomain販売ページを時系列で分ける図 この時系列では、「発表されたplan」と「実際に各walletへ起きた結果」を分けてください。発表日や予定日は、個別の補償完了、現在のclaim可否、tokenの価値を証明しません。 ## incident reportが説明した原因 [公式incident report](https://medium.com/@GrowingFi/growing-farm-sep-14th-incident-report-71de3abd172a)によると、影響を受けたのはBSC・PolygonのGrowing Farm v2 poolです。報告では、v2の`_withdraw`に元本額との照合がなく、攻撃者が少額をdepositした後、`withdraw()`へ大きな`wantedAmount`を渡せたことが原因として説明されています。 簡略化すると、本来は「そのaccountが預けた範囲」を超えるwithdraw要求を止めるべき境界が不足していました。攻撃者はその境界を利用し、poolから資産を取り出したと公式チームは説明しています。 ここでの「約120万ドル」「v2のみ」「原因」は、Growing.fi公式発表の要約です。独立した監査や全transactionの再計算結果ではありません。個別walletの損失額は、自分のdeposit・withdraw・transfer履歴とcontract eventから別に確認してください。 ## 補償planは個別の支払証明ではない 2021年9月15日の公式発表では、remedyへ10万ドルを用意すると説明されました。9月18日の詳細では99,361 USDCを用いるtier別のplanと、300ドルを超える未補償部分にrGROWを割り当てる案が示されています。 ただし、公開記事から確認できるのは**当時公表されたplan**までです。次の三つは別の証拠です。 | 証拠 | 確認できること | 確認できないこと | | --- | --- | --- | | 公式発表 | 方針、予定額、tier、予定日 | 自分が対象だったか、実際に受け取ったか | | onchain transaction | 特定address間の資産移動、時刻、数量 | その移動の法的意味や全補償の完了 | | 自分の記録 | deposit tx、wallet address、受取tx、当時の案内 | 他の利用者やproject全体の結果 | 当時の予定日を現在のclaim期限として使ったり、rGROWを現在価値のある補償資産とみなしたりしないでください。現在の公式受付先は今回確認できていません。 ## 旧positionを確認する順番 portfolio画面がなくても、公開chain上の記録はBlock explorerから確認できます。[トランザクション状態の確認方法](/archives/6004)と[ABI・event logsの読み方](/archives/6005)も併用してください。 ### 1. chainと自分のaccountを確定する 当時利用したのがBSCかPolygonかを、wallet履歴、送金元、保存したtransaction hashから確定します。同じaddressでもchainを取り違えると、残高もcontractも別物です。 ### 2. 最初のdeposit transactionを探す 自分のaddressのtransaction一覧から、Growing Farmへdepositした時期を絞ります。token transferだけでなく、transactionの宛先、method、internal transfer、event logsを一緒に確認します。 ### 3. pool contractとposition識別子を記録する UI名やtoken symbolではなく、transactionが実際に呼んだcontract addressを控えます。pool ID、share token、MasterChef形式のuser情報など、positionを識別する値があれば同じtransactionとeventから照合します。 ### 4. 入出金と現在残高を一本の時系列にする deposit、withdraw、emergency withdraw、reward、compensationらしきtransferを時刻順に並べます。wallet balanceが0でも、預け先contractのpositionが0とは限りません。反対に、古いUIへpositionが残っていた記録だけでは、現在withdrawできるとは限りません。 ### 5. 補償らしき入金は送付元まで照合する USDCやrGROWと同名のtokenを見つけても、symbolだけで補償と判断しません。chain、token contract、送付元、transaction hash、公式発表に記載された時期を突き合わせます。 ### 6. allowanceを別に確認する position残高とtoken allowanceは別です。過去にGrowing Farmのspenderへapprovalしていた場合、owner、token contract、spender、許可量を同じchainで確認します。[Spending capとrevokeの確認手順](/archives/6007)では、この四点を分けて説明しています。 Revokeはwallet disconnectと異なるonchain transactionで、gasが必要です。見覚えのないサイトからrevokeを促されても接続せず、walletや信頼できるExplorerが示すchain・spender・calldataを確認してください。 ## GROW・PLOW・rGROW・BONSAIをsymbolだけで探さない 公式発表にはGROW、PLOW、補償案のrGROW、後継構想のBONSAIが登場します。これらは役割も発表時期も異なります。 | 表記 | 公式発表上の位置づけ | 現在の扱い | | --- | --- | --- | | GROW | Growing.fi ecosystem token、旧PRO機能等 | 旧記事の購入・stake案内を削除 | | PLOW | Growing Farm側で言及されたtoken | emission停止方針が2021年に発表された歴史記録 | | rGROW | 補償planで未補償部分に用いるとされたtoken | 個別配布や現在価値をこの記事では確認できない | | BONSAI | Bonsai Farm announcementで説明されたtoken | 2021年の発表を現在の販売・稼働情報に転用しない | 同名tokenは誰でも作れます。symbolやlogoだけでwalletへ追加したり、swapしたり、claim transactionを送ったりしないでください。公式発表、chain、contract address、発行transactionが一致しない場合は操作を止めます。 ## 確認前に止めるチェックリスト - 開いているURLは旧bookmarkと同じでも、現在の運営者・用途が同じとは限らない - current domainの販売ページへwalletを接続する理由はない - 「補償を受け取れる」というDMや検索広告を公式受付先とみなさない - seed phrase、秘密鍵、復元phraseをWeb pageへ入力しない - GROW・PLOW・rGROW・BONSAIはsymbolではなくcontract addressで照合する - position確認のためだけに署名、approval、claim、withdrawへ進まない - transactionを検討する場合は、宛先、function、calldata、asset移動、gasを確認する - 独力で判断できない場合は、transactionを送らず記録だけ保存する ## よくある質問 ### Growing.fiは終了したのですか？ 公式チームは2021年10月にGrowing Farmを退役させ、Bonsai Farmを開発すると発表しました。また、2026年8月29日の確認では`growing.fi`はdomain販売ページへ移動します。ただし、この二点から旧projectに関するすべての活動が永久に終了したとまでは断定しません。 ### 今のgrowing.fiへwalletを接続すれば旧残高を見られますか？ いいえ。今回表示されたのは旧dappではなくdomain販売ページです。旧positionは、当時使ったchain、account、deposit transaction、pool contract、event logsから確認してください。 ### 補償は完了したのですか？ この記事で確認できたのは2021年の公式planです。個別の支払完了や現在の受付状況は確認できません。自分のwalletと当時の記録にあるtransactionを照合してください。 ### GROWやBONSAIを買えば旧positionを回収できますか？ そのような根拠は確認できません。古い記事や同名tokenを根拠に購入、stake、送金、claimをしないでください。 ## まとめ Growing.fiは2021年にDashboardとGrowing Farmを提供していましたが、同年9月にv2 poolのincidentと補償planが公表され、10月にはGrowing Farmの退役とBonsai Farmの開発方針が発表されました。2026年8月29日時点の`growing.fi`は、旧dappではなくdomain販売ページへ移動します。 旧positionを確認するときは、現在のdomainや見た目の似たUIへ戻るのではなく、chain、account、deposit transaction、contract、event、transfer、allowanceの順に証拠をそろえます。公式発表は経緯を知る資料ですが、個別の補償完了や現在の資産価値を証明するものではありません。 ## 確認した一次情報 - [Growing.fi: 現在のredirect確認](): 確認日 2026-08-29 - [Catcha.fi: growing.fi domain販売ページ](): 確認日 2026-08-29 - [Growing.fi: 2021-09-14 incident report](): 確認日 2026-08-29 - [Growing.fi: project sale announcement](): 確認日 2026-08-29 - [Growing.fi: compensation and going-forward plan](): 確認日 2026-08-29 - [Growing.fi: compensation plan details](): 確認日 2026-08-29 - [Growing.fi: Growing Farm retirement and Bonsai announcement](): 確認日 2026-08-29 - [Growing.fi: contracts repository](): 確認日 2026-08-29 - [Bonsai Farm: core repository](): 確認日 2026-08-29 - [ethereum.org: Block explorers](): 確認日 2026-08-29 - [MetaMask: token approval](): 確認日 2026-08-29 - [MetaMask: token approvalのrevoke](): 確認日 2026-08-29 --- # JDIYIELDの現況｜公開画面が残る旧DeFiツールの確認手順 JDIYIELDは2026年8月29日時点で公開画面が応答しますが、公式docsは2021年更新で、wallet接続後のデータや取引機能は未確認です。旧Harvest・Revoke・PRO特典を現在の推奨とせず、接続・approval・transactionの境界とExplorerでの照合順を解説します。 正規URL: https://3mikan.com/archives/1208 著者: みかん 公開: 2021-05-30T13:04:56.000Z 更新: 2026-08-28T20:19:57.000Z JDIYIELDは、複数のDeFi positionを一つの画面で見たり、対応farmの操作をまとめたりする目的で作られたツールです。旧記事では2021年の画面を使い、資産管理、Harvest、Revoke、JDI tokenの特典を現在も使える機能として紹介していました。 **2026年8月29日時点でJDIYIELDの公開画面は応答していますが、wallet接続後の機能は確認していません。** 公式siteが開くことだけでは、portfolio data、価格、対応farm、contract version、PRO plan、transactionの安全性までは判断できません。 この記事では、今回確認できた公開範囲、公式資料に残る旧機能、古いDeFi dappを開いたときにどこで止まるかを整理します。wallet接続、message署名、token approval、Harvest、Unstake、Revoke、LP removal、subscription、token購入、実資産操作は行っていません。 ## 2026年8月29日時点の確認結果 最初に、「公開ページが表示される」と「資産操作まで検証できた」を分けます。 | 確認項目 | 今回の結果 | 判断 | | --- | --- | --- | | public home | `jdiyield.com`から`www.jdiyield.com`へ移動し、HTTPS 200で応答 | **確認済み:** 公開frontendへ到達できる
**未確認:** wallet data、保守体制、安全性 | | home表示 | `Connect Wallet`、Vault、PRO Features、Farm Support list等を表示 | **確認済み:** navigationと公開copyが残る
**未確認:** 各機能が現在のcontractへ対応するか | | PRO Features | Harvest、Revoke、2,000 / 500 / 50 JDIのplan等を表示 | **確認済み:** page上の説明を読める
**未確認:** planの受付、価格、利用条件、提供継続 | | Token approvals | 未接続では`Please connect your wallet`を表示 | **確認済み:** 機能利用にwallet接続が必要
**未確認:** allowance取得、spender判定、Revoke transaction | | official docs | homeとPRO pageの最終更新表示は2021年8月26日 | **確認済み:** 2021年時点の目的と設計
**未確認:** 現行UI・contract・integrationとの差分 | | official Medium | publicationの最終公開表示は2021年9月25日 | **確認済み:** 当時の告知
**未確認:** 以後の運営・保守状況 | | public GitHub | profile用READMEのrepositoryだけを確認 | **確認済み:** 公開profile
**未確認:** application source、deploy、integrationの変更履歴 | 画面上部には`Buy JDI $0`という表示もありますが、これを現在価格、流動性、売買可能性の証拠には使えません。価格feedが取れない場合も0表示になり得るため、0円で買える、価値がない、取引できない、のいずれもこの表示だけでは断定できません。 同じ理由で、Farm Support listにprotocol名が並んでいても、すべてのcontract versionとpositionを現在取得できるとは限りません。対応表示は、保守済み・監査済み・安全という認証ではありません。 ## JDIYIELDは何をするツールだったのか [公式Guidebook](https://docs.jdiyield.com/master.md)では、JDIYIELDをyield farmer向けのportalとして説明し、siteが停止した場合でもstake・unstake等へ進めること、portfolio、token graph、Harvestを一画面へまとめることを目的に挙げています。 [Basic Features](https://docs.jdiyield.com/features-basic.md)には、wallet内token、farm、LPの評価、複数address、reward claim、approvalのRevoke、Vault、pollが記録されています。[旧操作guide](https://docs.jdiyield.com/archives/how-to-use-the-site.md)には、Harvest、stake、unstake、LP removal、Approve、Revokeまで載っています。 これらは、**公式資料で確認できる2021年当時の機能と構想**です。資料が公開され続けていることと、2026年に同じcontractへ安全にtransactionを送れることは別です。 旧記事にあったwallet残高、token比率、Vault・Farm表示、`Harvest all farm in 1 click`、2,000 JDI保有、毎週15 JDI、DINOP airdropは、現行の利用方法や特典から外しました。現在も有効だと確認できない条件を、購入・保有・接続の理由にしないでください。 ## 「画面が開く」だけでは確認できない5つの層 古いdappを確認するときは、次の層を一つずつ分けます。 | 層 | 確認できる証拠 | UIだけでは確認できないこと | | --- | --- | --- | | frontend | page、copy、navigation、assetが配信される | backend、indexer、RPCが正しく動くか | | portfolio data | address・chain・取得時刻と表示値 | 未対応position、古い価格、欠落したreward | | integration | protocol名、想定contract、対応操作 | 現行contract version、proxy、migration | | permission | owner、token、spender、allowance | spenderの安全性、必要な上限、将来の挙動 | | transaction | to、value、calldata、gas estimate | 実行後の受取額、成功、損失回避 | たとえばportfolioが空でも、資産がないとは限りません。chain、account、protocol version、staking先、indexer対応のどこかが違う可能性があります。反対に残高が表示されても、価格sourceが古い、withdraw条件が変わった、contractが移行済みという場合があります。 ## 閲覧・接続・署名・allowance・資産操作は別 画面を開いた後に要求される操作は、次の5段階に分けてください。 ### 1. 公開画面・公開addressを読む pageを表示したり、Explorerで公開address、残高、transaction historyを読んだりする段階です。wallet request、署名、transactionは必要ありません。 addressをsiteへ入力する場合は、資産移動権限を渡さなくても、そのaddressとアクセス元が結び付く可能性があります。privacy上の境界は残ります。 ### 2. Walletを接続する [MetaMaskの説明](https://support.metamask.io/more-web3/dapps/why-am-i-being-asked-to-connect-to-a-dapp/)では、接続によりsiteが選択accountのaddressを見られる一方、接続だけでtokenを動かせるわけではないとされています。 JDIYIELDの公開homeとToken approvals pageは接続を求めます。しかし、残高を確認するだけなら、先にExplorerで公開dataを読めます。domain、運営元、必要性を確認できない場合は接続せずに止めます。 ### 3. Messageへ署名する message署名は、accountの鍵を持つ人が内容を承認した証拠になります。gasが不要でも「読むだけ」ではありません。login、permit、注文などへ利用される場合があるため、要求元、全文、domain、期限、purposeを理解できない場合は署名しません。 ### 4. ApprovalまたはRevokeを送る token approvalは、指定したspenderが特定tokenへアクセスし、許可上限の範囲で動かせる権限です。[MetaMaskの解説](https://support.metamask.io/stay-safe/safety-in-web3/what-is-a-token-approval/)でも、ownerがdappへtoken利用権限を与える仕組みとして説明されています。 Revokeはwallet disconnectと違います。[MetaMaskのRevoke guide](https://support.metamask.io/more-web3/learn/how-to-revoke-smart-contract-allowances-token-approvals/)では、allowanceを変更するonchain操作であり、1件ごとにgasが必要になると説明されています。 古いapproval一覧を見たという理由だけで、表示されたspenderへ機械的にtransactionを送りません。chain、token contract、owner、spender、現在allowanceをExplorerや現行wallet toolで照合します。 ### 5. Harvest・Unstake・LP removalを実行する Harvest、Unstake、Withdraw、LP removalはchain stateを変更するtransactionです。接続や表示と違い、contract、function、引数、recipient、minimum amount、deadline、gasが結果へ影響します。 旧UIが生成したcalldataを、そのまま現行contractへ使えるとは限りません。protocol migration、MasterChefの差し替え、pool ID、LP token、proxy、reward contractが変わると、同じボタン名でも対象が違います。
公開画面の閲覧、wallet接続、message署名、approvalとRevoke、HarvestやUnstakeの資産操作を分ける5段階
公開pageが応答しても、接続・署名・allowance変更・資産操作はそれぞれ別の確認が必要です。
owner・token・spender・allowanceの組み合わせは、[token approvalをExplorerで照合する方法](/archives/6007)で詳しく説明しています。contractとcalldataの読み方は[ABI・function selector・event logsの確認手順](/archives/6005)を参照してください。 ## 旧PRO plan・airdrop表示を現在の特典にしない 2026年8月29日に確認した`/features`は、次のcopyを表示していました。 - 2,000 JDIをstakeするplan - 年額500 JDI - 月額50 JDI - Harvest all、code change alert - `Holdings Overview`とchatbotの`coming soon` [公式JDI token page](https://docs.jdiyield.com/jdi-token.md)にも同様の条件が残っています。ただし、関連docsの最終更新表示は2021年です。現在の申込み受付、contract、料金、提供機能、解約・返金条件、JDIの市場や流動性は今回確認できていません。 旧記事にあった「2,000 JDIを持つメリット」「翌週に15 JDI」「DINOPを受け取れる」という記載も、当時のcampaign記録です。現在有効な特典とは確認できません。古いpageや記事だけを根拠に、JDIを購入・stake・送金しないでください。 ## JDIYIELDを使わずにpositionを照合する順番 portfolio toolの表示に頼らず、元のchain dataへ戻るときは次の順番で記録します。 1. **chainとaccountを固定する** 過去のwallet履歴とTx hashから、利用したnetworkと完全なaddressを確認します。 2. **deposit・stakeのtransactionを探す** Explorerでstatus、to、token transfer、event logs、block時刻を確認します。 3. **protocolとcontract versionを特定する** 公式資料にある現行contract、migration、deprecated versionと照合します。 4. **wallet内と預け先を分ける** wallet balance、LP token、vault share、staked amount、未請求rewardを別々に追います。 5. **allowanceを別表で確認する** chain、owner、token、spender、amountを揃え、wallet disconnectと混同しません。 6. **操作前にcalldataを読む** to、function、引数、recipient、minimum amount、deadline、value、gasを確認します。 7. **価格とAPRは最後に評価する** token数量とpositionを確定した後、価格source、取得時刻、流動性、withdraw条件を確認します。 [ethereum.orgのBlock explorer解説](https://ethereum.org/developers/docs/data-and-analytics/block-explorers/)では、account、transaction、token、contract source、ABI、event等の確認項目が整理されています。transactionがpending、failed、replacedのどれかを調べる場合は、[receipt・nonce・statusの確認フロー](/archives/6004)で切り分けてください。 LP tokenとNFT positionの違い、versionごとの解除条件は[PancakeSwapのV2・V3 LP確認手順](/archives/821)で扱っています。表示APRやLP評価額を読む場合は、[インパーマネントロスの計算と前提](/archives/580)も合わせて確認してください。 ## 症状別チェックリスト | 状況 | 最初に確認すること | 進めない操作 | | --- | --- | --- | | public pageは開く | 確認日、domain、docs更新日 | 稼働・安全と断定してconnect | | portfolioが空 | chain、account、deposit Tx、staking先 | 同じdepositやapprovalの繰り返し | | `Buy JDI $0`と表示 | price source、取引市場、流動性 | 0円・無価値・購入可能と断定 | | PRO planが表示 | 更新日、現行contract、提供・解約条件 | 古い特典を理由にtoken購入 | | Revoke候補が表示 | owner、token、spender、allowance | spenderを確認せず一括送信 | | Harvest / Unstakeを求める | protocol、contract、pool、calldata | 旧UIからmainnet transaction | | migration後にpositionがない | old contract、share token、event logs | 新versionへ同じ資産を再deposit | ## よくある質問 ### JDIYIELDはいまも使えますか？ 公開pageが表示されることは確認できました。ただし、wallet接続後のportfolio data、対応farm、Harvest、Revoke、PRO planの現在動作は確認していません。「siteが開く」という範囲を超えて、利用可能・保守中・安全とは断定できません。 ### 残高を見るためにwalletを接続してもよいですか？ 接続だけでtoken移動権限にはなりませんが、選択accountのaddressをsiteへ共有します。残高確認が目的なら、まずExplorerへ公開addressを入力して確認できます。必要性を説明できない接続、署名、approvalへ進まないでください。 ### `Buy JDI $0`はJDIが0円という意味ですか？ その表示だけでは判断できません。price feedの欠落、market dataの取得失敗、流動性不足などを区別できないため、価格・価値・売買可能性の根拠には使いません。 ### 2,000 JDIでPRO機能を使えますか？ public pageと2021年更新のdocsには2,000 JDI等の条件が残っています。しかし、現在の受付、contract、機能提供、返金・解約条件は確認できていません。現在有効なplanとしてこの記事では案内しません。 ### Revokeを押せばwallet接続も解除されますか？ 別の操作です。disconnectはsiteからaccount情報への接続を外します。Revokeはtoken allowanceを変更するonchain transactionで、gasが必要です。owner、token、spender、allowanceを確認してから個別に判断します。 ### 旧記事の画面どおりにHarvestできますか？ 現行手順としては使えません。旧画面は2021年の記録で、protocol contract、pool ID、reward、transaction引数が現在も同じとは確認できませんでした。 ## まとめ - 2026年8月29日時点でJDIYIELDの公開pageはHTTPS 200で応答した - page表示だけではwallet data、integration、contract、transactionの現況を確認できない - 公式docsの更新表示とMediumの告知は2021年で、旧機能・plan・airdropを現在の推奨にしない - 公開閲覧、wallet接続、message署名、approval / Revoke、Harvest等の資産操作を分ける - `Buy JDI $0`や対応farm一覧を、価格・安全性・保守の証拠にしない - positionはchain、account、contract、event、allowance、calldataへ戻って照合する 古いdappは、画面が残っているほど「そのまま使えそう」に見えます。最初に確認するのはボタンではなく、更新日とchain上の証拠です。残高を見るだけなら接続せず、署名・allowance変更・資産操作へ進む前に止まってください。 ## 確認した一次情報 - [JDIYIELD: public home](): 確認日 2026-08-29 - [JDIYIELD: PRO Features](): 確認日 2026-08-29 - [JDIYIELD: Token approvals](): 確認日 2026-08-29 - [JDIYIELD: Farm Support list](): 確認日 2026-08-29 - [JDI Yield Guidebook: overview](): 確認日 2026-08-29 - [JDI Yield Guidebook: basic features](): 確認日 2026-08-29 - [JDI Yield Guidebook: PRO version](): 確認日 2026-08-29 - [JDI Yield Guidebook: JDI token](): 確認日 2026-08-29 - [JDI Yield Guidebook: historical operation guide](): 確認日 2026-08-29 - [JDIYIELD official Medium publication](): 確認日 2026-08-29 - [JDIYIELD public GitHub profile repository](): 確認日 2026-08-29 - [MetaMask: dappへのwallet接続](): 確認日 2026-08-29 - [MetaMask: token approval](): 確認日 2026-08-29 - [MetaMask: token approvalのrevoke](): 確認日 2026-08-29 - [ethereum.org: Block explorers](): 確認日 2026-08-29 --- # farm.armyの現況｜接続できないときの確認と旧機能の記録 farm.armyは2026年8月29日時点で公開Webサービスへ接続できず、現行機能を確認できません。公式GitHubに残る旧機能、アドレス閲覧・ウォレット接続・署名・承認の違い、表示値をExplorerで照合する順番を解説します。 正規URL: https://3mikan.com/archives/827 著者: みかん 公開: 2021-05-15T14:43:29.000Z 更新: 2026-08-28T19:48:28.000Z farm.armyは、ウォレットアドレスからDeFiの残高やLP、運用先をまとめて表示していたポートフォリオ確認ツールです。旧記事では2021年の画面を使い、現在も操作できるサービスとして紹介していました。 しかし、**2026年8月29日時点で、この環境からfarm.armyの公開Webサービスへ接続できず、現行機能を確認できません。** DNSの記録と公式GitHubのコードは残っていますが、それだけでサービスの稼働、保守、データの鮮度、安全性までは判断できません。 この記事では、今回確認できた範囲、farm.armyが過去に備えていた機能、ポートフォリオ表示を別の証拠で照合する順番を整理します。ウォレット接続、署名、token approval、transactionは行っていません。 ## 2026年8月29日時点の確認結果 まずは、「ドメインが残っている」と「Webサービスを利用できる」を分けます。 | 確認項目 | 今回の結果 | ここから分かること | | --- | --- | --- | | DNS | `farm.army`はA record `78.47.195.191`を返した | ドメインの名前解決先は残っている | | HTTPS | port 443へ接続できなかった | この環境ではHTTPS画面を確認できない | | HTTP | port 80へ接続できなかった | この環境ではHTTP画面も確認できない | | backend | [公式GitHub](https://github.com/farm-army/farm-army-backend)は公開・非archive | 過去の設計とソースコードを確認できる | | frontend | [公式GitHub](https://github.com/farm-army/farm-army-frontend)は公開・非archive | 過去の画面実装を確認できる | | 最終commit | backendは2022年4月18日、frontendは2022年2月22日 | 少なくとも公開repositoryの最終活動は2022年 | 接続できなかった原因や、ほかの地域・時刻でも同じ状態かは確認できていません。そのため、この記事では「恒久的に終了した」「すべての環境で停止している」とは断定しません。 また、repositoryがarchiveされていないことも、現在の運用を保証する証拠ではありません。画面が再び開けた場合でも、取得時刻、対応chain、価格source、protocol versionを改めて確認する必要があります。 ## farm.armyは何を表示していたのか [backendのREADME](https://github.com/farm-army/farm-army-backend)では、BSC、Polygon、Fantom、KCC、Harmony、Celo、Moonriver、Cronos、Moonbeamを対象に、farm、wallet、NFT、yieldを取得するendpointが説明されています。 たとえば、公開アドレスを受け取る`wallet`や`yield`のendpointがあり、各platformからfarm、残高、報酬などを集める設計でした。旧画面にあったwallet残高、LP内訳、ドル換算、運用先一覧は、このように複数のchain dataと価格情報をまとめて見せる機能です。 ここで大切なのは、これは**公式ソースから確認できる過去の機能**だという点です。2026年8月29日に同じendpointが動くこと、現在のprotocolへ対応していること、表示額が正しいことは確認できていません。 旧記事にあった`UseWallet`、`Open random address`、`Farming Pools`などの画面名、対応サイト数、CAKE・BANANAの運用先、表示APRは、現行手順から外しました。2021年の残高やLP構成も、現在の利用例としては扱いません。 ## 公開アドレスから読める情報と、計算された表示を分ける ウォレットアドレスは公開情報です。[ethereum.orgのBlock explorer解説](https://ethereum.org/developers/docs/data-and-analytics/block-explorers/)でも、アドレスに紐づくETH残高、token、transaction historyなどを確認できると説明されています。 一方、ポートフォリオ画面の「何ドル」「APR何%」「LPの中身」は、chainにそのまま書かれた一つの答えではありません。元データを取得した後、token情報、価格、protocolごとのposition解釈を重ねた表示です。 | 情報の層 | 例 | 確認時の注意 | | --- | --- | --- | | onchain data | 残高、transfer、contract call、block時刻 | chainとcontract addressを一致させる | | token情報 | symbol、decimals、token種別 | 同名tokenや古いcontractを取り違えない | | position解釈 | LP、vault share、staked balance、未請求reward | wallet内だけでなく預け先contractも見る | | 価格評価 | USD換算、LP内の各資産評価 | 価格sourceと取得時刻で変わる | | 利回り表示 | APR、APY、reward換算 | 計算式、報酬価格、更新時刻で変わる | たとえばUSD表示が0になっても、token数量まで0になったとは限りません。反対に金額が表示されても、流動性が少ないtokenや終了したvaultでは、その評価額で換金・withdrawできるとは限りません。 ## アドレス閲覧・接続・署名・承認は別の操作 ポートフォリオを確認するときは、画面に表示される要求がどの段階かを分けてください。 ### 1. 公開アドレスを入力する アドレスを入力し、chain上の公開データを読む段階です。wallet request、署名、transactionは必要ありません。 ただし、入力したアドレスとアクセス元がsite側で結び付く可能性はあります。資産を動かす権限は渡しませんが、プライバシー上の境界は残ります。 ### 2. ウォレットを接続する [MetaMaskの説明](https://support.metamask.io/more-web3/dapps/why-am-i-being-asked-to-connect-to-a-dapp/)では、dappへの接続によりsiteが選択accountのアドレスを見られる一方、接続だけでtokenを移動できるわけではないとされています。 接続は資産移動ではありませんが、公開アドレスをsiteへ明示する操作です。ドメインや運営元を確認できない場合は、接続せずに止めます。 ### 3. メッセージへ署名する 署名は、accountの鍵を持つ人がそのメッセージを承認したことを証明します。[MetaMaskのsignature解説](https://support.metamask.io/configure/transactions/what-is-a-signature-in-metamask/)では、メッセージは通常chainへ公開されない点がtransactionとの主な違いとして説明されています。 ただし、「gasが不要だから読むだけ」という意味ではありません。署名済みメッセージはログイン、注文、permitなどの権限確認に利用されることがあります。要求元、全文、対象domain、期限を理解できない場合は署名しないでください。 ### 4. token approval・transactionを送る token approvalは、指定したspenderが特定tokenへアクセスし、上限の範囲で動かせるようにする権限です。[MetaMaskのtoken approval解説](https://support.metamask.io/stay-safe/safety-in-web3/what-is-a-token-approval/)では、approval後にdappが`transferFrom`を呼べる仕組みが説明されています。 transactionはchain上の状態を変更します。portfolio残高を眺める目的だけなら、token approvalや資産移動transactionへ進む理由はありません。 次の図では、要求が一段進むごとに何を確認するかを並べています。
公開アドレス閲覧、ウォレット接続、メッセージ署名、token approvalとtransactionの権限境界
接続だけで資産移動権限にはなりませんが、署名・approval・transactionは内容に応じて権限やchain stateへ影響します。
approvalを詳しく確認する場合は、[token・owner・spender・allowanceを照合する方法](/archives/6007)で、見るべき組み合わせを整理しています。 ## ポートフォリオ表示がずれる主な理由 表示がおかしい場合に、すぐ「資産が消えた」「利益が出た」と判断しないでください。まず、どの層で差が出たかを分けます。 ### chainまたはaccountが違う 同じ`0x`アドレスでも、Ethereum、BNB Chain、Polygonなどでは残高とpositionが別です。画面が対応していないchainを見ている場合もあります。 ### token contract・decimals・価格sourceが古い 同じsymbolの別token、移行前contract、誤ったdecimals、価格取得不能があると、数量やUSD換算がずれます。symbolだけでなくcontract addressを確認します。 ### LP・vault・staking先に預けられている LP tokenやvault shareを別contractへstakeすると、単純なwallet残高だけではpositionを追えません。deposit transaction、受取token、staking contract、現在の持分を順に確認します。 PancakeSwapのV2 LP tokenとV3 NFT positionの違いは、[LPを追加・解除する前のversion確認](/archives/821)で説明しています。LP評価と単純保有の差は、[インパーマネントロスの計算例](/archives/580)も合わせて確認してください。 ### protocolやvaultが更新・終了している 古いcontractに残るpositionを、現行UIやindexerが取得しないことがあります。新しい画面へ表示されないことと、chain上の残高が0であることは別です。 ### APR・reward・USD評価の更新時刻が違う APRは将来の収益保証ではありません。報酬量、報酬token価格、TVL、計算期間、複利換算が変われば表示も変わります。古いスクリーンショットの数値を現在値として使わないでください。 ## farm.armyへ接続できないときに行うこと 公開画面へ接続できない場合は、検索結果に出た似たドメインやmirrorへ移動する前に止まります。デザインやサービス名が同じでも、同じ運営元とは限りません。 1. ブックマークや過去の公式GitHubから、元のdomain表記を確認する 2. DNSが残ることと、HTTPS画面が正しく応答することを分ける 3. 公式から移転案内を確認できないmirror・コピーsiteへwalletを接続しない 4. 残高閲覧を理由に署名、token approval、transactionを求められたら進めない 5. 「復旧」「同期」を理由に秘密鍵やSecret Recovery Phraseを入力しない farm.armyの画面が開かないことだけで、underlying protocol上のpositionが消えたとは判断できません。表示ツールではなく、chainとcontractへ戻って確認します。 ## Explorerでpositionを照合する順番 ここからは、ポートフォリオツールがなくても確認できる証拠を並べます。難しく感じる場合は、最初の3項目だけでも記録してください。 1. **chainを固定する** どのnetworkで預けたかを、過去のtransactionやwallet履歴から確認します。 2. **自分のaddressを固定する** 途中でaccountを切り替えていないか、完全なaddressで照合します。 3. **Explorerでnative coin・token・transaction historyを見る** token数量、transfer、contract interaction、block時刻を確認します。 4. **protocol contractを特定する** deposit先、LP pair、vault、staking contractを公式資料やverified sourceと照合します。 5. **wallet内と預け先を分ける** wallet残高、LP token、vault share、staked amount、未請求rewardを別々に確認します。 6. **価格と利回りは最後に評価する** token数量と持分を確認した後、価格source、更新時刻、withdraw条件を確認します。 contractの入力やevent logsまで追う場合は、[ABI・calldata・logsの読み方](/archives/6005)を参照してください。transactionがpending、failed、replacedのどれかを調べる場合は、[receipt・nonce・statusの確認順](/archives/6004)で切り分けます。 ## 確認チェックリスト | 状況 | 最初に確認すること | 進めない操作 | | --- | --- | --- | | farm.armyが開かない | 確認日時、HTTP / HTTPS、公式の移転案内 | 検索で見つけたmirrorへの接続 | | portfolioを見るためconnectを求められる | domain、選択account、共有するaddress | 不明なsiteへの接続 | | signatureを求められる | 要求元、全文、目的、期限 | 読めないmessageへの署名 | | approvalを求められる | chain、token、owner、spender、上限 | 残高確認だけの無制限approval | | USD表示が0または極端 | token数量、contract、decimals、価格source | 表示額だけで消失・利益を断定 | | LP・vaultが見つからない | chain、account、version、staking先 | 同じdepositやapprovalの繰り返し | ## よくある質問 ### farm.armyはサービス終了したのですか？ この記事の確認だけでは断定できません。2026年8月29日に、この環境から公開WebサービスのHTTP / HTTPS接続を確立できなかった、という範囲です。DNSと公式GitHubは残っていますが、現行機能、保守、データ鮮度は確認できていません。 ### 公開アドレスを入力しただけで資産を動かされますか？ 公開アドレスだけでは、秘密鍵による署名やtokenの利用許可にはなりません。ただし、siteがアドレスを知ることで、公開残高や履歴とアクセスを結び付けられる可能性があります。 ### ウォレット接続とtoken approvalは同じですか？ 同じではありません。接続は選択accountのアドレスをsiteへ見せる段階です。token approvalは、spenderへ特定tokenを動かせる権限を与えるonchain操作です。 ### ポートフォリオ表示が0なら資産はありませんか？ 表示だけでは判断できません。chain違い、未対応position、staked balance、古いcontract、価格取得不能でも0や空欄になることがあります。Explorerでtoken数量とcontract interactionを先に確認します。 ### 旧記事の画面通りに操作できますか？ 現行手順としては使えません。旧画面は2021年時点の記録で、2026年8月29日には同じUIと機能を確認できませんでした。 ## まとめ - 2026年8月29日時点で、この環境からfarm.armyの公開Webサービスへ接続できなかった - DNSと公開repositoryが残ることは、現在の稼働・保守・安全性の保証ではない - 旧画面の残高、LP内訳、APR、USD評価、対応先は現在値として使わない - 公開アドレス閲覧、wallet接続、message署名、token approval / transactionを分ける - portfolio表示は、chain、contract、position、価格sourceへ戻って照合する - 公式の移転案内を確認できないmirrorへ接続・署名・approvalをしない farm.armyの表示がなくても、確認の起点は公開chain dataです。まず数量とcontractを確認し、その後で価格や利回りを評価してください。 ## 確認した一次情報 - [farm.army: HTTP / HTTPS接続確認](): 確認日 2026-08-29 - [farm.army: backend repository](): 確認日 2026-08-29 - [farm.army: frontend repository](): 確認日 2026-08-29 - [farm.army backend: 2022-04-18 commit](): 確認日 2026-08-29 - [farm.army frontend: 2022-02-22 commit](): 確認日 2026-08-29 - [ethereum.org: Block explorers](): 確認日 2026-08-29 - [MetaMask: dappへのウォレット接続](): 確認日 2026-08-29 - [MetaMask: メッセージとトランザクションの署名](): 確認日 2026-08-29 - [MetaMask: token approval](): 確認日 2026-08-29 --- # Bitgetの日本向けサービス終了｜新規登録停止・制限日程 Bitgetが公表した日本居住者向けサービス終了について、新規登録停止、Close-Only、残存ポジションの強制決済予定を時系列で整理。金融庁警告、現行規約、コピートレードと出金前の確認事項も一次情報から確認します。 正規URL: https://3mikan.com/archives/3076 著者: みかん 公開: 2021-10-12T17:12:53.000Z 更新: 2026-08-28T18:52:37.000Z Bitgetは2026年8月3日、日本居住者向けの暗号資産交換サービスを終了すると公表しました。**日本居住者の新規登録は2026年8月3日以降受け付けられません。** この記事は2026年8月29日に、Bitgetの終了案内・FAQ・現行規約と金融庁資料を確認し、予定されている制限を時系列で整理したものです。登録、取引、コピートレード、アフィリエイトを勧める記事ではありません。 > **最初に公式通知を確認してください** > > BitgetのFAQは、日本居住者と判定されたアカウントについて、2026年11月1日11時（GMT+9）からClose-Only、2026年12月31日11時（GMT+9）から残存ポジションの強制決済を案内しています。対象判定、時刻、利用できる機能は更新される可能性があります。検索結果やSNSではなく、Bitget公式ドメインの最新のお知らせ、自分のアカウントへ届く通知、公式サポートの回答を確認してください。 3MIKANは個別の法律判断、投資判断、ポジション決済、出金先の選択を行いません。この記事の確認では、Bitgetへの登録、ログイン、本人確認、入出金、注文、wallet接続、署名、transaction、資産移動を実施していません。 ## 2026年8月29日時点の要点 | 日時 | Bitget公式案内 | 読み違えないための注意 | | --- | --- | --- | | 2026年8月3日以降 | 日本居住者の新規登録を停止 | 登録リンクや紹介コードを利用できるという案内ではない | | 2026年9月17日以降 | 公式通知を受けた利用者を日本居住者と暫定判定する予定 | 8月29日時点では通知開始前。通知がまだないことを対象外の根拠にしない | | 2026年11月1日 11時（GMT+9） | 対象アカウントをClose-Onlyへ制限 | 新規・追加ポジションや多くのサービスを利用できなくなる予定 | | 2026年12月31日 11時（GMT+9） | 残存する未決済ポジションを強制決済する予定 | 実際の処理、価格、費用、税務上の扱いをこの記事では確定できない | BitgetのFAQは、Close-Onlyの対象に現物、先物、P2P、Convert、Earn、カード、コピートレード、取引botなどを挙げています。入金は制限付き、暗号資産の出金は継続して利用できると説明していますが、これはBitget自身が公表した予定です。将来の可用性や資産保全を3MIKANが保証するものではありません。
2026年8月3日の新規登録停止、11月1日のClose-Only、12月31日の残存ポジション強制決済予定を示す時系列
日程はBitgetの2026年8月3日付案内とFAQに基づきます。最新の公式通知を優先してください。
## 旧「評判・安全性」記事を現況判断に使わない このURLでは以前、2021年時点の評判、取引高、利用者数、ライセンス、最大レバレッジ、ボーナス、コピートレード、登録手順、アフィリエイト申込を一つの記事で紹介していました。 しかし、現在の検索意図で優先すべきなのは「おすすめか」ではなく、**日本居住者向けサービス終了の対象、日程、自分のアカウントで確認すべき項目**です。古い数値や口コミを現行の安全性・利用資格・利益の根拠にはできません。 | 旧記事の判断材料 | 現在の扱い | 理由 | | --- | --- | --- | | 匿名SNSの利益・損失投稿 | 削除 | 本人、条件、期間、再現性を確認できない | | 取引高・利用者数・ランキング | 削除 | 変動値であり、日本向け提供資格や安全性を示さない | | 海外の登録・ライセンス表 | 削除 | 法人、地域、許可の対象業務を追跡できず、日本の登録とは別 | | ボーナス・紹介リンク | 削除 | 新規登録停止後の日本居住者へ取引を促すため不適切 | | 3MIKANのLINE経由のアフィリエイト申込 | 削除 | 氏名・UIDの収集や申込仲介を現在の案内として行わない | | コピートレードで利益を得る説明 | 削除 | 自動執行・価格差・損失のリスクを省いていた | ## 公式日程を4段階で確認する ### 1. 8月3日：日本居住者の新規登録停止 Bitgetの日本語告知は、2026年8月3日以降、日本居住者の新規登録を受け付けないと明記しています。したがって、このページから登録先、紹介コード、アプリ登録、ボーナスの導線は案内しません。 公開ページが表示できること、アプリが端末に残っていること、古い紹介リンクが開くことは、新規登録や商品の利用資格を意味しません。居住地を別の国として申告したり、VPNなどで地域判定を回避したりする方法も案内しません。 ### 2. 9月17日以降：公式通知と居住地判定 BitgetのFAQは、2026年9月17日以降に公式通知を受けた利用者を、日本居住者と暫定的に判定すると説明しています。この記事の確認日は8月29日であり、この通知開始前です。 通知がまだ届いていない、画面が通常どおり表示されるという理由だけで、対象外とは判断できません。日本国外に居住しているのに誤って判定された場合について、FAQは住所証明によるLevel 2本人確認または公式サポートへの連絡を案内しています。これは誤判定を訂正するための案内であり、日本居住者が制限を回避する手順ではありません。 ### 3. 11月1日：Close-Only FAQによると、2026年11月1日11時（GMT+9）から対象アカウントはClose-Onlyとなり、新しいポジションを開く、既存ポジションへ追加する、多くの商品を利用するといった操作が制限される予定です。 対象機能の例として、現物、先物、P2P、Convert、Earn、カード、コピートレード、取引botが挙げられています。単に注文画面だけを確認するのではなく、未決済注文、コピートレード、bot、Earnなどに資産やポジションが残っていないかを、アカウント内の公式表示で分けて確認する必要があります。 ### 4. 12月31日：残存ポジションの強制決済予定 FAQは、2026年12月31日11時（GMT+9）から、対象アカウントに残る未決済ポジションを強制決済し、カードサービスを停止するとしています。 「強制決済予定」は、有利な価格で処理される、損失が補償される、税務処理が自動で完了するという意味ではありません。具体的な約定、費用、履歴、損益、税務上の扱いは、個別のアカウントと取引記録で確認し、必要に応じて資格のある専門家へ相談してください。 ## 金融庁の警告とBitgetの終了案内は別々に読む 金融庁は2023年3月31日、「Bitget Limited」がインターネットを通じて日本居住者を相手方として無登録で暗号資産交換業を行っていたとして警告を公表しました。警告資料は、所在地をシンガポール共和国としつつ、業者名や所在地はインターネット上の情報に基づき、現時点のものではない可能性があると注記しています。 一方、2026年8月14日更新のBitget Terms of Useは、プラットフォームの運営主体を「BTG Technology Holdings Limited」と記載しています。文書に現れる法人名が異なるため、3MIKANは両者が同一法人である、または法的責任が承継されたとは断定しません。 | 確認先 | 確認できること | ここから断定しないこと | | --- | --- | --- | | 金融庁の2023年警告 | 当時、Bitget Limitedへの警告が公表された事実 | 現在の運営主体との法的同一性、個別利用の法律判断 | | 金融庁の2026年8月21日時点登録一覧 | Bitgetの名称を登録業者として確認できないこと | 利用者ごとの契約、資産、税務の結論 | | Bitgetの2026年終了案内・FAQ | 運営側が公表した日本居住者向け制限日程 | 日程どおりの可用性、資産保全、価格、補償の保証 | | Bitgetの現行規約 | 規約上の運営主体と一般条件 | 金融庁警告に記載された法人との同一性 | 日本語ページが見えること、海外で何らかの登録があること、Proof of Reservesやセキュリティ機能が掲載されていることを、日本の暗号資産交換業者としての登録や資産保全の保証へ置き換えないでください。 ## コピートレードは「自動で利益を得る機能」ではない 旧記事は、トレーダーの取引をコピーすれば自分で判断せずに運用できるという方向で紹介していました。この説明では重要なリスクが抜けます。 BitgetのOne-Click Copy Trade User Agreementは、コピートレードを非常に投機的とし、追随に使った金額より大きな損失が生じる可能性を説明しています。また、利用者の操作なしに取引が開始・終了する自動執行もリスクとして挙げています。 BitgetのRisk Disclosureも、暗号資産取引では大きな損失や全損があり得ること、過去の実績が将来の結果を示さないこと、サービスが法令対応などで制限・停止される場合があることを案内しています。 コピートレードでは、次の違いも結果へ影響します。 - フォローしたトレーダーと自分の約定価格・注文数量・レバレッジが一致しない - 急な相場変動や流動性によりスリッページが生じる - 残高、上限、risk controlにより注文が一部だけ実行される、または実行されない - 自動執行のため、自分が画面を見ていない間にpositionが変わる - Close-Onlyやサービス終了の日程が通常の運用より優先される 過去の利益率、フォロワー数、ランキング、著名人の紹介を安全性や将来利益の根拠にはしません。 ## 既存利用者が操作前に確認する項目 BitgetのFAQは、対象利用者にポジションを閉じ、資産の出金を始めるよう案内しています。ただし、3MIKANは決済する商品・時刻・価格、売却する資産、送付先、networkを個別に指定しません。操作前に、自分の公式画面と受取先の公式情報を照合してください。 | 確認項目 | 自分で照合する場所 | 注意点 | | --- | --- | --- | | 公式通知 | Bitget公式ドメイン、アカウント内通知、登録メール | SNSのDM、検索広告、短縮URL、第三者LINEを公式通知とみなさない | | 居住地判定 | 自分に届いた通知、登録情報、公式サポート回答 | 虚偽の居住地申告や回避手段を使わない | | 未決済状態 | 現物注文、先物position、copy trade、bot、Earn、P2P等 | spot残高だけを見て全資産を確認したことにしない | | 出金可能残高 | 各accountのavailable / locked表示 | 未決済注文や商品に拘束された残高は直ちに出金できない場合がある | | 受取先条件 | 受取先の入金画面 | 資産、network、address、Memo / Tag、最小入金額、入金停止を確認する | | Bitget側条件 | 資産とnetworkを選択した出金画面 | 最小出金額、手数料、受取見込額、security制限、network停止を確認する | | 実行記録 | 注文履歴、出金履歴、TxID、公式support case | 日時、status、手数料、回答を後から確認できる形で保存する | Bitgetの出金制限ヘルプは、最低出金額、本人確認、利用可能残高、security変更後の一時制限、addressとnetworkの不一致、Memo / Tag、network保守などを確認項目として挙げています。条件は資産、network、アカウントで変わるため、この記事へ固定値を転載しません。 受取先が特定のnetworkやMemo / Tagを要求する場合、送付元と受取先の表示が完全に一致しない状態では進めないでください。addressの選択やtest送付の要否も、資産・network・費用・受取先の仕様を確認したうえで判断します。 ## 終了案内を装うフィッシングに注意する サービス終了や強制決済という言葉は、急いでログイン・送金させるフィッシングに悪用される可能性があります。Bitgetの公式注意喚起は、未知のリンクやQRコードを開かず、公式ドメインを確認し、anti-phishing codeや公式channel検証を利用するよう案内しています。 - メールやSNSのリンクからではなく、自分で保存・確認した公式URLを開く - 「制限解除」「移行」「強制決済回避」を理由に、password、認証code、秘密鍵、seed phraseを渡さない - 3MIKANや第三者へ氏名、UID、残高、address、本人確認書類を送らない - 不審な連絡は、そのメッセージ内の窓口ではなく、公式サイトからsupportを開き直す - addressは貼り付け後に先頭・末尾だけでなく、可能な範囲で全体とnetworkを照合する 本記事に外部の登録用短縮URL、LINE申込、紹介コードはありません。 ## 最後のチェックリスト - 日本居住者の新規登録が2026年8月3日以降停止されたことを確認した - 9月17日の通知開始予定、11月1日のClose-Only、12月31日の強制決済予定を別々に確認した - 自分に届いた公式通知と、Bitget公式FAQの最新版を確認した - 金融庁の警告とBitgetの終了案内を、同じ文書や同じ法人名として扱っていない - 現物、先物、copy trade、bot、Earn、P2Pなどを別々に確認した - 出金可能残高と、商品・注文に拘束された残高を分けて確認した - 受取先の資産、network、address、Memo / Tag、最小額、入金statusを確認した - Bitget側の最小額、fee、受取見込額、security制限、network statusを最終画面で確認した - 短縮URL、検索広告、SNSのDM、第三者LINEからログインしていない - password、認証code、秘密鍵、seed phrase、本人確認書類を第三者へ共有していない 日程や画面がこの記事と異なる場合は操作を急がず、確認日、公式URL、通知、画面表示を記録し、Bitgetの公式サポートと必要な専門家へ確認してください。 ## 確認した一次情報 - [Bitget: 日本居住者向けサービス終了のお知らせ](): 確認日 2026-08-29 - [Bitget: 日本居住者向けサービス終了FAQ](): 確認日 2026-08-29 - [金融庁: 無登録で暗号資産交換業を行う者について（Bitget Limited）](): 確認日 2026-08-29 - [金融庁: 暗号資産交換業者登録一覧](): 確認日 2026-08-29 - [Bitget: Terms of Use](): 確認日 2026-08-29 - [Bitget: Risk Disclosure](): 確認日 2026-08-29 - [Bitget: One-Click Copy Trade User Agreement](): 確認日 2026-08-29 - [Bitget: 出金制限・停止時の確認事項](): 確認日 2026-08-29 - [Bitget: フィッシングへの注意喚起](): 確認日 2026-08-29 --- # 暗号資産取引所の選び方｜登録・売買方法・手数料 暗号資産取引所を順位ではなく、金融庁の登録、販売所と取引所の違い、スプレッド、売買・入出金・送付費用、対応chainの確認順で比較します。 正規URL: https://3mikan.com/archives/2117 著者: みかん 公開: 2021-08-18T16:06:18.000Z 更新: 2026-08-28T18:30:00.000Z 暗号資産取引所は、世界順位や「手数料無料」という一語だけでは比較できません。日本居住者が最初に確認するのは、**現在の提供主体が金融庁・財務局の登録一覧にあるか**です。そのうえで、販売所と取引所のどちらを使うか、入金から売却・送付までに何の費用が発生するかを分けて読みます。 この記事は2026年8月29日に、金融庁の登録一覧と、旧記事に掲載していた各サービスの公式ページを確認して全面更新しました。口座開設、本人確認、入出金、売買、外部walletへの送付は行っていません。 > **先に確認する重要事項** > > 金融庁が2026年8月21日時点として公開する暗号資産交換業者登録一覧には27業者が掲載されています。ただし、登録は暗号資産の価値、安全性、利益を金融庁が保証または推奨するものではありません。登録一覧は「比較のスタート地点」であり、損失しない証明ではありません。 この記事は特定の事業者や暗号資産を勧めるものではありません。手数料、取扱銘柄、利用条件は変わるため、最終判断では金融庁の最新一覧、各社の契約締結前交付書面、手数料ページ、自分の確定前画面を確認してください。 ## 結論：順位ではなく5段階で比較する 1. **提供主体と登録を確認する**：サービス名ではなく法人名と登録番号を照合する 2. **利用目的を一つに絞る**：日本円で購入、板取引、積立、外部送付などを分ける 3. **販売所と取引所を分ける**：同じ事業者でも価格の決まり方と費用が違う 4. **一連の費用を合計する**：入金、スプレッドまたは売買手数料、送付、出金を別々に確認する 5. **資産とchainの条件を確認する**：取扱銘柄数だけでなく、入出庫可否、対応chain、最小額を見る
提供主体と登録、利用目的、売買方式、総費用、送付条件の順に暗号資産取引所を比較するフロー
一つ前の確認ができない場合は、口座や注文へ進まず公式情報へ戻ります。
## 金融庁の登録一覧を最初に見る [金融庁の登録業者一覧ページ](https://www.fsa.go.jp/menkyo/menkyo.html)から、最新日付の「暗号資産交換業者」PDFまたはExcelを開きます。広告やアプリに表示されるブランド名だけでなく、利用規約やWebサイト下部にある運営法人名を一覧内で検索してください。 2026年8月21日時点の一覧で、旧記事に掲載していたサービスのうち、現在も比較例として扱う5社は次のとおりです。 | サービス表示 | 登録一覧の事業者名 | 登録番号 | この表に残した理由 | | --- | --- | --- | --- | | bitFlyer | 株式会社bitFlyer | 関東財務局長 第00003号 | 旧記事掲載先で、現行の公式費用表を確認できる | | bitbank | ビットバンク株式会社 | 関東財務局長 第00004号 | 旧記事掲載先で、現行の公式費用表を確認できる | | GMOコイン | GMOコイン株式会社 | 関東財務局長 第00006号 | 旧記事掲載先で、現行の公式費用表を確認できる | | Coincheck | コインチェック株式会社 | 関東財務局長 第00014号 | 旧記事掲載先で、現行の公式費用表を確認できる | | Binance Japan | Binance Japan株式会社 | 関東財務局長 第00031号 | 旧記事のBinance Global表記と現在の日本向け提供主体を分けるため | これは全登録業者の一覧でも、おすすめ順でもありません。**2021年版の旧記事に登場し、2026年8月29日に登録と公式費用ページを追跡できた事業者**を、比較方法の例として残しています。名称、登録番号、取扱暗号資産は今後変わり得るため、利用時は金融庁の最新版を確認してください。 ### 登録から分かること・分からないこと | 登録一覧から確認できること | 登録一覧だけでは判断できないこと | | --- | --- | | 登録を受けた法人名と登録番号 | 暗号資産の将来価格や元本の安全 | | 一覧作成時点の取扱暗号資産 | 現在の入出庫、メンテナンス、個別accountの利用可否 | | 所管財務局と登録年月日 | UIの使いやすさ、supportの速さ、障害が起きないこと | | 登録業者かを調べる入口 | 最安の総費用、最良の約定、損失補償 | [金融庁の注意点](https://www.fsa.go.jp/policy/virtual_currency/04.pdf)も、登録の確認に加え、価格変動やcyber security等のリスクについて事業者の説明を理解するよう案内しています。「登録済み」を「安全保証」に読み替えないことが大切です。 ## 販売所と取引所は価格の決まり方が違う 同じ事業者の中に「販売所」と「取引所」「板取引」「Lightning」等が併存する場合があります。画面が似ていても、相手と価格の決まり方が違います。 | 比較項目 | 販売所 | 取引所・板取引 | | --- | --- | --- | | 主な取引相手 | 事業者 | 注文を出す利用者同士を事業者が媒介 | | 価格 | 事業者が買値と売値を提示 | 板の注文価格から指値・成行等で約定 | | 主な費用表示 | 売買手数料が無料でも、買値と売値の差がある | Maker/Taker、取引量、銘柄等で料率が変わる場合がある | | 注文前に見るもの | 買値、売値、受取数量、確定前の総額 | 売買方向、価格、数量、注文種別、手数料率、板の厚さ | | 注文後に見るもの | 約定価格、受取数量、残高 | 未約定、一部約定、約定価格、取引手数料、残高 | 販売所の「売買手数料無料」は、買値と売値が同じという意味ではありません。たとえばCoincheckとbitFlyerの公式費用ページは、販売所の売買手数料とは別に、価格差または手数料相当額の負担があると説明しています。GMOコインの販売所ページも、売値と買値の差が実質的な費用になると案内しています。 取引所では、指値が板に残るMakerと、既存注文を約定させるTakerで料率が違う場合があります。成行注文は価格を指定しないため、画面に見えた一つの価格ですべて約定するとは限りません。売買方法を決めてから、同じ条件の費用を比べます。 ## 5社の費用は「確認場所」で比べる 2026年8月29日に確認した各社公式ページを、順位や固定の最安表ではなく、**どの費用をどこで確認するか**で整理します。 | サービス | 売買で確認する項目 | 日本円で確認する項目 | 暗号資産送付で確認する項目 | 公式確認先 | | --- | --- | --- | --- | --- | | bitFlyer | 販売所の価格差、かんたん取引所・Lightningの取引量別料率 | 振込元、クイック入金方法、出金先銀行、金額帯 | 銘柄別の送付手数料、最小数量 | [手数料一覧・税](https://bitflyer.com/ja-jp/s/commission) | | bitbank | Maker/Taker、銘柄、キャンペーン適用条件 | 振込元銀行の費用、日本円出金の金額帯 | 銘柄別の出金手数料、入出庫可否、対応network | [手数料](https://bitbank.cc/docs/fees/) | | GMOコイン | 販売所の価格差、現物取引の銘柄別Maker/Taker | 即時入金と振込入金の違い、通常出金と大口出金 | 送付可否、誤送付時の条件、送付先の受入条件 | [入出金・取引手数料](https://coin.z.com/jp/corp/guide/fees/) | | Coincheck | 販売所の手数料相当額、取引所の銘柄別条件 | 銀行・コンビニ・クイック入金、日本円出金 | 銘柄・network状況による送金手数料 | [手数料](https://coincheck.com/ja/info/fee) | | Binance Japan | 現物のMaker/Taker、level、BNB利用等の適用条件 | 日本円入出金の対応方法と確定前表示 | 銘柄・network別の入出庫可否、最小額、出庫費用 | [手数料と取引概要](https://www.binance.com/ja/fee/trading) | 表の目的は、現時点の数字を一列に並べることではありません。自分が使う経路が違えば、必要な費用も変わります。公式ページがlogin状態、居住地、銘柄、取引量で表示を変える場合は、自分の確定前画面を優先してください。 ### 「無料」を見たときの確認項目 - 販売所なら、同時点の買値と売値の差 - 板取引なら、対象銘柄とMaker/Takerの料率 - 日本円入金なら、事業者側だけでなく振込元銀行の費用 - 日本円出金なら、出金先銀行と金額帯 - 暗号資産送付なら、銘柄、chain、最小額、送付手数料 - キャンペーンなら、対象者、期間、上限、終了後の通常条件 「口座維持無料」「入金無料」「売買無料」は、それぞれ別の項目です。一つが無料でも、一連の経路が無料になるとは限りません。 ## 総費用を一つの経路で計算する 比較前に、予定している動きを一行で書きます。 > 日本円を入金 → BTCを購入 → 外部walletへ送付 この場合は、少なくとも次を同じ金額・同じ銘柄・同じchainで確認します。 | 段階 | 記録する値 | 確認画面 | | ---: | --- | --- | | 1. 日本円入金 | 銀行側費用、即時入金等の事業者側費用 | 振込元銀行と入金方法の案内 | | 2. 購入 | 販売所なら提示買値と受取数量、板なら約定価格と売買手数料 | 注文確定前と取引履歴 | | 3. 外部送付 | 送付手数料、最小額、最終受取見込み | 資産とchainを選んだ出庫画面 | | 4. 結果確認 | 実際の引落額、受取数量、TXID、送付先の反映 | 残高・履歴・explorer・送付先履歴 | 日本円へ戻す予定なら、売却時の価格差または売買手数料と、日本円出金費用も加えます。費用を比較するときは、異なる日時の暗号資産価格を混ぜず、同じ時点の確定前表示を記録してください。 ## 取扱銘柄数より先にchainと入出庫を確認する 金融庁の一覧に銘柄名があっても、任意のchainで自由に入出庫できるとは限りません。同じ`USDT`、`ETH`、`BTC`等の表示でも、事業者が受け付けるnetwork、入出庫停止、最小額、Memo / Tagの条件は別です。 外部walletや別の取引所へ送る目的がある場合は、次を一組で確認します。 1. 送付元と送付先の両方が同じ資産を扱う 2. 両方が同じchainまたはnetworkを明示している 3. 入出庫がメンテナンス中ではない 4. 最小送付額と最小入金額の両方を満たす 5. Memo / Tagが必要な資産では、送付先表示と一致する 6. 確定前に宛先、chain、数量、手数料、最終受取見込みを読む 送付先やchainを間違えると、回収できない場合があります。少額のtest送付が可能でも、最低額と固定費用のために適さない場合があるので、条件を先に確認します。送金トラブルの一般的な切り分けは[誤ったnetworkへ送金したときの確認手順](/archives/6004)を参照してください。 ## 海外サイトと日本向け事業者を混同しない Webページが日本語で表示されること、アプリを入手できること、世界の取引高順位に載ることは、日本の暗号資産交換業者として登録されていることと同じではありません。 旧記事はBinance Global、Bybit、Bitget等を国内業者と同じ表で順位付けしていました。現在の記事では、まず金融庁一覧の法人名を確認します。Binanceについても、旧Global記事の名称をそのまま使わず、**Binance Japan株式会社が運営する日本向けページか**をfooter、利用規約、登録番号で確認します。 Bybitについては、金融庁資料、地域制限、公開ページ、account条件を分けて[Bybitは日本で使える？](/archives/1945)に整理しています。公開画面が見えることだけを、登録や個別利用資格の根拠にはしません。 ## 旧比較から外したサービスと数値 2021年版にあったCoinMarketCapの順位、24時間取引高、週訪問数、銘柄数は、比較日時と取得条件が異なるため撤去しました。順位が高くても、日本での登録、目的の売買方法、総費用、送付条件は別途確認が必要です。 旧表のDMM Bitcoinも現行比較から外しました。[DMM Bitcoinの公式告知](https://bitcoin.dmm.com/news/20210710_01)によると、サービスは2025年3月8日に終了し、顧客口座と預かり資産はSBI VCトレードへ移管されています。終了したサービスの旧手数料やアプリを、現在選べる取引所として掲載しません。 アフィリエイトURL、紹介code、口座開設CTA、期間限定bonus、主観的な「一番使いやすい」「安心」「世界一だからおすすめ」といった表現も撤去しました。 ## 自分用の比較表を作る 最後に、候補ごとに同じ質問へ回答します。空欄がある事業者を想像で補わず、公式情報へ戻ってください。 | 質問 | 候補A | 候補B | 証拠URL・確認日時 | | --- | --- | --- | --- | | 運営法人名と登録番号は何か | | | 金融庁の最新一覧 | | 利用するのは販売所か板取引か | | | 商品説明・注文画面 | | 同じ金額で受け取れる数量はいくらか | | | 同時点の確定前画面 | | Maker/Takerまたは価格差はどう表示されるか | | | 手数料・価格表示 | | 日本円入出金の方法と費用は何か | | | 公式費用ページ | | 外部送付する資産・chain・最小額・費用は何か | | | 入出庫画面・公式案内 | | 2要素認証、出庫先管理、復旧手順を確認したか | | | security・support案内 | | 障害・メンテナンス・行政処分の最新情報を見たか | | | 公式status・金融庁 | ## 最後のチェックリスト - 金融庁の最新一覧で、サービス名ではなく運営法人名を照合した - 登録を価値、安全性、利益の保証だと解釈していない - 販売所と取引所・板取引を分けた - 「無料」以外に、価格差、Maker/Taker、銀行側費用、送付費用を確認した - 同じ金額・同じ銘柄・同じchain・同じ時点で比較した - 取扱銘柄数だけでなく、実際の入出庫可否と最小額を確認した - 海外サイトの表示と、日本の登録や自分の利用資格を分けた - 公式情報と確定前画面が違う場合は操作を止めた - 認証code、秘密鍵、seed phraseを第三者へ共有していない 手数料や提供条件がこの記事と違う場合は、古い数値で判断せず、現在の日付、URL、商品名、資産、chainを記録して最新の公式情報を優先してください。 ## 確認した一次情報 - [金融庁: 免許・許可・登録等を受けている事業者一覧](): 確認日 2026-08-29 - [金融庁: 暗号資産交換業者登録一覧](): 確認日 2026-08-29 - [金融庁: 暗号資産を利用する際の注意点](): 確認日 2026-08-29 - [Coincheck: 手数料](): 確認日 2026-08-29 - [bitFlyer: 手数料一覧・税](): 確認日 2026-08-29 - [bitbank: 手数料](): 確認日 2026-08-29 - [GMOコイン: 手数料](): 確認日 2026-08-29 - [Binance Japan: 手数料と取引概要](): 確認日 2026-08-29 - [DMM Bitcoin: サービス終了のお知らせ](): 確認日 2026-08-29 --- # MEXCは日本で使える？金融庁警告・地域制限・手数料 MEXCの日本向け登録状況、金融庁警告、地域制限、アプリ配布、手数料、安全確認を一次情報で整理。公開ページが見えることと利用資格を分け、旧ボーナスや紹介コードを撤去しました。 正規URL: https://3mikan.com/archives/4652 著者: みかん 公開: 2022-03-14T14:43:42.000Z 更新: 2026-08-28T18:00:00.000Z MEXCの日本語Webページは日本から表示できます。しかし、**ページが見えること、日本の暗号資産交換業者として登録されていること、個別のサービスを利用できることは別**です。 この記事は2026年8月29日に、金融庁資料とMEXCの公開情報を確認し、日本向けの登録状況、地域制限、アプリ配布、手数料、セキュリティ情報を整理したものです。口座開設や取引を勧める記事ではありません。確認は公開ページだけで行い、登録、ログイン、本人確認、入出金、注文は実施していません。 > **日本居住者向けの重要事項** > > 金融庁は2024年11月28日、MEXC Globalについて、日本居住者を相手方として無登録で暗号資産交換業を行っていたとして警告しました。また、2026年8月21日時点の暗号資産交換業者登録一覧に、MEXCの名称は確認できません。MEXC側の地域制限ページに日本が禁止地域として列挙されていないことを、日本での登録や個別利用の適法性を示す根拠にはできません。 個別の法律上の判断はこの記事では行いません。実際の判断では、金融庁の最新一覧と警告、MEXCの最新規約、居住地と対象サービスに適用される条件を確認し、必要に応じて専門家へ相談してください。 ## 2026年8月29日時点の結論 | 確認先 | 確認できたこと | ここから判断できないこと | | --- | --- | --- | | 金融庁の登録一覧 | 2026年8月21日時点の一覧にMEXCの名称は見当たらない | 個別の利用行為に対する法律判断 | | 金融庁の警告 | 2024年11月28日にMEXC Globalへの警告が公表された | 現在の営業実態や利用者ごとの状況 | | MEXCの地域制限 | 2026年4月17日更新のページで、日本はサービス禁止地域に列挙されていない | 日本の交換業登録、全サービスの提供、個別利用資格 | | MEXCアプリ | 同じページは、日本でiOS・Androidアプリをダウンロードできないと案内している | 既に入手したアプリの状態、将来の配布状況 | | MEXC Web | 日本語の公開ページをログアウト状態で表示できた | 登録、本人確認、入出金、注文が完了できるか | | 手数料 | 公式ページに手数料の分類と確認欄がある | 地域・商品・利用者に実際に適用される固定料率 | つまり「日本で使えるか」を一つのYesまたはNoで決めることはできません。少なくとも、登録情報、運営側の地域条件、利用経路、アカウントと商品の条件を分けて確認します。
金融庁の登録と警告、MEXCの地域条件、Webとアプリ、個別サービス条件を順に確認する流れ
公開ページの表示だけで結論を出さず、異なる根拠を順番に確認します。
## MEXCの「特徴」は公式資料と利用可能性を分けて読む MEXCの利用規約は、サービスの例として暗号資産取引、入出金、先物、P2Pなどを挙げています。一方で、サービスの外観、利用可能性、価格、運用は居住国などにより変わり、提供内容を変更・停止する場合があるとも説明しています。 そのため、機能名が公式ページに掲載されていることだけで、日本居住者がその機能を利用できるとは判断できません。 | 情報の種類 | 記事での扱い | 理由 | | --- | --- | --- | | 金融庁の登録一覧・警告 | 外部の公的根拠として確認 | MEXC自身の説明とは別に確認できる | | MEXCの規約・地域制限 | 運営側が示す条件として確認 | 地域・商品・アカウントで変わる場合がある | | MEXCの手数料・セキュリティ説明 | MEXC自身の説明として確認 | 独立した安全性評価や利用可能性の証明ではない | | 公開Web画面 | 表示できた事実だけを記録 | 登録、本人確認、入出金、注文の成否は確認していない | | 口コミ・SNS投稿 | 現況判断の根拠にしない | 投稿者の条件や結果を再現できず、代表性も確認できない | 設立年、利用者数、取扱銘柄数、最大レバレッジ、提携先、受賞歴などの数値は変わります。現在の公式資料で確認できたとしても、サービスの優位性や日本での利用資格を証明するものではありません。 ## 日本向け条件は3段階に分ける ### 1. 金融庁の登録と警告 金融庁の暗号資産交換業者登録一覧は2026年8月21日時点で27業者を掲載しています。同一覧は、利用する事業者が登録を受けているかを金融庁・財務局のWebサイトで確認するよう案内しています。MEXCの名称はこの一覧で確認できませんでした。 別の金融庁資料では、MEXC Globalに対し、インターネットを通じて日本居住者を相手方として暗号資産交換業を行っていたとして、2024年11月28日に警告したことが公表されています。 ### 2. MEXC側の地域条件 MEXCの地域制限ページは、日本をサービス禁止地域の一覧に含めていません。ただし、同じページは日本をiOS・Androidアプリのダウンロード対象外として明記しています。また、利用規約の禁止地域一覧と地域制限ページでは列挙内容に差があるため、片方だけを固定情報として使えません。 地域制限ページ自体も、法令・規制・運用上の事情により内容を更新すると説明しています。確認日と最終更新日を一緒に記録し、古い検索結果や転載だけで判断しないでください。 ### 3. Web・アプリ・個別サービス 日本語Webが表示されても、登録、本人確認、入出金、現物、先物などの利用可否は確認できません。アプリの配布状況もWebの表示とは別です。 規約と画面が食い違う、居住地を正しく選べない、対象サービスの条件が確認できない場合は、回避方法を探さず操作を止めます。所在地を別の国として申告したり、非公式な配布元からアプリを入手したりする方法は案内しません。 ## 「評判」は確認できる項目へ分解する 「使いやすい」「銘柄が多い」「安全性が高い」といった評判は、読む人の目的や時点で意味が変わります。取引所を比較するときは、感想を一つの総合点にせず、次の根拠へ分けます。 | 確認項目 | 一次情報で見るもの | 注意点 | | --- | --- | --- | | 登録・規制 | 金融庁の登録一覧、警告 | 運営側の地域制限とは別の根拠 | | 地域・商品 | 利用規約、制限地域、商品の個別条件 | 日本語表示だけでは利用資格を判断できない | | 費用 | 手数料ページ、確定前表示、履歴 | 固定料率や「最安」という表現を引き継がない | | セキュリティ | 公式ドメイン、認証方法、フィッシング対策、障害時の案内 | 機能の存在は損失防止や補償の保証ではない | | 資産管理 | 入出金status、対応chain、停止情報、履歴 | 公開ページだけでは利用者資産の状態を確認できない | | サポート | 公式窓口、回答の記録、本人確認方法 | SNSの個別メッセージを公式窓口とみなさない | 旧記事に掲載されていた匿名のSNS投稿や、短期間で利益が増えたという体験談は削除しました。個人の結果は再現性を確認できず、将来の利益や安全性の根拠にならないためです。 ## 手数料は固定表ではなく最終表示を確認する MEXCの手数料概要ページは、メイカーとテイカーを分けたうえで、料率がイベントや利用地域によって異なる場合があると案内しています。MXによる控除も、アカウント条件により表示されない場合があると説明しています。 古い記事にあった現物・先物の固定料率や段階割引は、現在の全利用者へ適用される条件として残していません。 | 費用 | 発生する場面 | 確認先 | | --- | --- | --- | | 送信元のネットワーク手数料 | 他のwalletや取引所から送る | 送信元の確定前画面 | | 入金条件 | MEXCへ暗号資産を送る | 対象資産・chainの入金画面 | | 出金手数料 | MEXCから外部へ送る | 資産とchainを選択した出金画面 | | 現物・先物取引手数料 | 注文が約定する | 自分に表示される料率、確定前表示、取引履歴 | | 資金調達料 | 無期限先物を対象時点で保有する場合 | 契約ごとのrate、時刻、履歴 | | キャンペーン条件 | 対象企画へ参加する場合 | 期間、地域、対象者、達成条件、受取期限 | 記事内の表だけで総費用を確定せず、商品、maker・taker、資産、chain、地域、アカウント条件を含む最終表示を確認します。 ## セキュリティ情報は「機能」と「保証」を分ける MEXCの公式セキュリティ記事は、偽サイト、SMS、メール、QRコード、サポート担当者のなりすましを挙げ、正しいドメインの確認、認証コードの非共有、フィッシング対策コードなどを案内しています。 これらの機能があることを「資産が必ず守られる」「取引所全体が安全」という保証には置き換えません。利用前だけでなく、既にアカウントを持つ場合も次を確認します。 - 検索広告、紹介リンク、SNSのDMではなく、保存済みの正規URLから開いたか - ドメイン、TLS表示、遷移先を入力前に確認したか - パスワード、メール・SMS・認証アプリのコード、秘密鍵、シードフレーズを第三者へ渡していないか - 「凍結解除」「移行」「強制決済回避」などを理由に、送金や画面共有を求められていないか - 公式のお知らせ、status、入出金履歴を別々に確認したか 不審な連絡を受けた場合は、そのメッセージ内のリンクや連絡先を使わず、正規サイトから公式窓口を開き直してください。 ## 2022年の情報を現況へ引き継がない このURLでは以前、2021年のMX・BNB騰落率、4つのライセンス、600種類以上の取扱通貨、最大125倍、限定入金ボーナス、紹介コード、登録・本人確認手順を掲載していました。これらは2022年3月時点の記事構成であり、現在有効な条件として扱いません。 特に、次の内容は撤去しました。 - 期間が終了した新規登録・初回入金ボーナス - 紹介コード付きURLと口座開設CTA - 過去の値上がり率を使った取引訴求 - 出典と対象時点を追跡できない利用者数、ライセンス、提携、受賞、安全性の断定 - 旧UIに依存する登録、本人確認、サービス操作 - 匿名の口コミと利益体験談 MEXCの現物・先物注文画面に表示される項目を調べる場合は、[MEXC注文方法と約定・取消の確認手順](/archives/4911)を参照してください。こちらも公開画面と公式ヘルプを読むための記録であり、登録や取引を推奨するものではありません。 ## 最後に確認するチェックリスト - 金融庁の登録一覧とMEXC Globalへの警告を、現在の日付で確認した - MEXCの禁止地域に日本がないことを、日本で登録済みという意味に置き換えていない - Web表示、アプリ配布、登録、本人確認、商品利用を別々に確認した - 規約と地域制限ページの最終更新日を確認した - 手数料を古い固定表で決めず、商品と自分の条件に応じた最終表示を確認した - セキュリティ機能の存在を、資産保全や補償の保証に置き換えていない - ボーナス、紹介コード、過去の騰落率を判断材料にしていない - 認証コード、秘密鍵、シードフレーズを第三者へ共有していない 公式情報がこの記事と違う場合は操作を進めず、確認日、URL、表示内容を記録して最新情報を優先してください。 ## 確認した一次情報 - [金融庁: 暗号資産交換業者登録一覧](): 確認日 2026-08-29 - [金融庁: 無登録で暗号資産交換業を行う者について（MEXC Global）](): 確認日 2026-08-29 - [MEXC: 制限国とアプリをダウンロードできない地域](): 確認日 2026-08-29 - [MEXC: 利用規約](): 確認日 2026-08-29 - [MEXC: 手数料概要](): 確認日 2026-08-29 - [MEXC: リスク告知](): 確認日 2026-08-29 - [MEXC: フィッシング攻撃を防ぐ方法](): 確認日 2026-08-29 --- # ラグプル時に資産回収できる？front-end停止後の確認順 DeFiのfront-endが消えたとき、wallet token・LP token・staked LP・vault shareを分け、source、proxy、残高、simulationから回収候補・阻害・未確定を判断する手順を解説します。 正規URL: https://3mikan.com/archives/1655 著者: みかん 公開: 2021-07-06T21:22:36.000Z 更新: 2026-08-28T17:00:48.000Z DeFiのfront-endが突然開けなくなっても、それだけでは「資産を回収できる」「すでに失われた」のどちらにも決まりません。画面はcontractへrequestを送る入口であり、実際の権利、残高、停止条件はchain上のstateとcurrent codeで決まります。 この記事では、結果を次の三つに分けます。 - **回収候補**：必要なread-only証拠が一致し、対象accountのsimulationも成功した状態 - **阻害あり**：pause、資産不足、transfer制限、simulation revert等を確認した状態 - **未確定**：source、proxy、position、支払原資等の証拠が足りない状態 回収候補は「回収可能」の保証ではありません。この記事は特定projectを安全と判定せず、mainnetでwallet接続、署名、transaction送信、実資産移動を行いません。 > 緊急時ほど、追加署名を止める > > front-endが消えた後に届くDM、復旧tool、recovery agent、追加depositの案内を先に試さないでください。Secret Recovery Phrase、private key、passwordは誰にも渡しません。 ## まず保存し、書き込まない 異常に気づいたら、最初に新しいapprove、Permit署名、token送付、gas代名目の追加送金を止めます。既存positionを調べるだけなら、公開addressとread-only RPCを使えます。 次の情報を時刻付きで保存してください。 1. network名とchain ID 2. 自分の公開account address 3. 利用していたprojectのURLと、以前から確認していた公式channel 4. deposit、approve、stake等のtransaction hash 5. token、Pair、farm、vaultのcontract address 6. 表示されたerror、incident告知、撮影時刻 「rug pull」は、運営による流動性引き抜き、悪意あるupgrade、出金制限、front-end放棄等をまとめて呼ぶ俗称として使われます。故意、攻撃、運用障害のどれかは、ラベルではなくtransaction、events、code変更、残高で分けます。 ## wallet token・LP token・staked LP・vault shareを分ける 同じprojectで操作していても、walletが持つ権利は一種類ではありません。まずは「何を、どのaddressが保有しているか」を確定します。
wallet token、LP token、staked LP、vault shareを区別する図
| state | 権利の場所 | 最初のRead | exit候補 | | --- | --- | --- | --- | | wallet token | token contractの`balanceOf(user)` | balance、既存allowance、transfer制限 | 回収Writeは不要。必要ならrevokeを別検討 | | wallet内V2 LP token | Pair contractの`balanceOf(user)` | Pair、token0 / token1、reserves、total supply | V2 Router / Pair固有のremove | | farmへstakedしたLP | farm contractの内部帳簿 | deposit証拠、`poolInfo`、`userInfo`、farmのLP balance | 実装固有のwithdraw / emergency function | | vault share | vault shareの`balanceOf(user)` | underlying、limits、preview、accounting | ERC-4626型ならwithdraw / redeem候補 | wallet内のtoken残高が見えているなら、そのtokenは「farmから回収するposition」ではありません。ただし、spenderへのallowanceが残っている場合やtoken自体にtransfer制限がある場合は、別のriskがあります。 V2 LP tokenがwalletにある場合は、farmからのwithdrawではなくPair持分の解除を調べます。反対に`userInfo`だけにamountがあり、walletのLP balanceが0なら、まずfarmからLPを戻す経路が必要です。 vault shareはunderlying tokenそのものではありません。share balanceがあっても、現在の交換比率、limit、fee、流動性、strategy側の資産状態によって受取候補は変わります。 ## chain・contract・current codeを固定する function名を探す前に、次の値を一つのcase sheetへ固定します。 ```text checkedAt: chainName / chainId: checkedBlock: account: asset state: token / Pair / farm / vault address: official address source: source verification: proxy / beacon: current implementation: admin / owner / relevant roles: paused state and affected functions: current ABI: incident transaction / announcement: ``` addressは、incident後に届いたDMや検索広告から採用しません。利用開始時のtransaction `to`、deposit logs、projectの既知の公式資料、Explorerを突き合わせます。 ### verified sourceは安全証明ではない [Etherscanのcontract verification](https://docs.etherscan.io/contract-verification/whats-contract-verification)は、deployed contractのsource codeを公開・照合する仕組みです。verifiedという表示から、公式project、監査済み、upgrade不能、支払能力あり、回収可能までは分かりません。 sourceが未検証なら、function名とABIの意味を十分に確認できません。類似contractのABIを流用せず、Write候補を未確定として止めます。 ### proxyは現在のimplementationと履歴を読む proxyでは、addressとstateを維持したまま、呼び出すlogicを変更できる場合があります。[ERC-1967](https://eips.ethereum.org/EIPS/eip-1967)型なら、implementation、beacon、adminの標準storage slotと`Upgraded`、`BeaconUpgraded`、`AdminChanged` eventsが手掛かりです。 次を同じchecked blockで記録します。 - proxy addressとcurrent implementation address - proxyとimplementationの両方のverified source - admin / upgrade roleと、その保有account - deposit時からincident後までのupgrade events - current implementationに対応するABI implementationが変わった事実だけで悪意とは断定しません。ただし、変更前sourceで成功したsimulationや古い監査結果は、current codeの証拠として再利用できません。 ### pausedは全function停止とは限らない OpenZeppelinの`Pausable`は、継承しただけで全functionを止めません。source上で`whenNotPaused`や`whenPaused`等のmodifierが付いたfunctionに条件が適用されます。 そのため、`paused() = true`だけを見て「すべて出金不可」「emergencyWithdrawだけ可能」と決めません。対象のwithdraw、emergencyWithdraw、redeemに、どのmodifierとrole checkが付いているかを読みます。 ## Readだけで現在positionを確認する [ethereum.orgのJSON-RPC説明](https://ethereum.org/developers/docs/apis/json-rpc/#eth_call)では、`eth_call`はblockchain上へtransactionを作らずmessage callを実行します。`balanceOf`等のReadはwallet接続や署名を必要としません。 | 対象 | Read候補 | 分かること | まだ分からないこと | | --- | --- | --- | --- | | ERC-20 token | `balanceOf(user)` | checked blockのwallet残高 | transferできるか、価格、発行者権限 | | token approval | `allowance(user,spender)` | spenderがまだ利用できる上限 | すでに移動した資産の回収可否 | | V2 Pair | LP `balanceOf`、`token0`、`token1`、`getReserves`、`totalSupply` | LP持分とpool accountingの候補 | token transfer成功、minimum amount、Router route | | MasterChef系 | `poolInfo(pid)`、`userInfo(pid,user)` | poolとuserの内部記録 | functionの意味、LP支払能力、reward放棄 | | ERC-4626型vault | share `balanceOf`、`asset`、`totalAssets`、`maxRedeem`、`previewRedeem` | share、underlying、current limitと見込額 | 実装の正しさ、依存strategy、将来の支払能力 | ERC-20の`allowance(owner,spender)`は、spenderがownerのtokenをまだ利用できる上限です。残高とは別のstateなので、同じchain、token、owner、spenderの組み合わせで読みます。 MasterChef系では、deposit transactionのinputまたはevent、`poolInfo(pid).lpToken`、`userInfo(pid,user).amount`の三つを合わせます。pidを画面の並び順やtoken symbolで推測しないでください。詳しい照合は[MasterChefの_pid確認手順](/archives/1791)で説明しています。 ERC-4626では`maxRedeem(owner)`が0なら、規格上はcurrent conditionでredeemできるshare上限が0です。一方、`previewRedeem(shares)`はredemption limitを考慮しないため、見込assetsが返っても受け付けられる証拠にはなりません。両方を別に読みます。 ## revoke・remove・withdraw・redeemを混同しない 候補になるWriteは、資産stateとcurrent sourceで決まります。動詞が似ていても目的は違います。 ### revokeは将来のallowanceを減らす revokeは通常、token contractのallowanceを0等へ更新します。悪意が疑われるspenderの将来の`transferFrom`範囲を減らせますが、すでに移動したtokenを取り戻しません。 revoke自体もon-chain transactionです。token、spender、chainを間違えず、receipt後に`allowance`を読み直します。Disconnectとの違い、Permit / Permit2を含む確認は[Spending cap・approve・revokeの確認順](/archives/6007)を参照してください。 ### removeはwallet内V2 LPをunderlying候補へ戻す V2 LP tokenがwalletにある場合、current Router / Pair sourceに対応するremove functionを調べます。Pair address、token0 / token1、Factory、LP balance、allowance、reserves、total supply、minimum amounts、recipient、deadlineを固定します。 Pairのreservesがdrainされている、片方のtokenがtransferをrevertする、Routerが違う、LP tokenを別contractへ預けている場合は、front-endを変えても解決しません。V2型`removeLiquidity`の引数と失敗条件は[V2 LP解除の確認順](/archives/1788)へ進んでください。 LPを作成した過去transactionからPairとtoken比率を復元する場合は、[V2 LP作成の確認順](/archives/1663)を補助資料に使えます。旧記事のように「作成したDEXの画面でしか解除できない」とは限りませんが、任意のRouterで解除できるわけでもありません。 ### withdrawはfarmの内部帳簿を減らしてLP等を返す候補 staked LPでは、対象farmのcurrent sourceからwithdraw function、pid、amount、fee、lock、reward処理、recipient、pause条件を読みます。`userInfo`のamountがあっても、farmが必要なLP tokenを保有していることや、transferが成功することまでは証明しません。 farmのLP token balanceが自分のrecorded amount以上でも、全利用者への債務や別accountingまで満たすとは限りません。必要条件の一つとして記録し、solvencyの証明へ読み替えないでください。 ### emergencyWithdrawは名前では判断しない historical PancakeSwap MasterChefでは、`emergencyWithdraw(pid)`がrecorded LPを返す一方でpending rewardを支払わない実装でした。これはhistorical sourceの一例で、すべてのfarmの仕様ではありません。 別実装では、emergency functionが存在しない、pause中も呼べない、feeやlockがある、別recipientへ送る、LP transferでrevertする場合があります。source、ABI、role、state、simulationが一致しない限り、緊急という名前を成功保証にしません。 ### redeemはvault shareをunderlying候補へ交換する ERC-4626型なら、`asset()`、share balance、`maxRedeem(owner)`、`previewRedeem(shares)`、fee、receiver / owner、allowanceを確認します。規格に似た独自vaultやasync withdrawalでは、requestなど別段階が必要な場合があります。 `totalAssets()`はvaultがmanagedと報告するamountであり、規格でも表示向けestimateとして使われます。share balanceと`totalAssets`だけで、即時に全額支払えると断定しません。strategy、bridge、lending market等の依存contractも確認対象です。 ## 回収候補・阻害・未確定の分岐
front-end停止後に資産回収候補を確認する5段階フロー
| outcome | 例 | 次の行動 | | --- | --- | --- | | wallet-held | tokenがwalletの`balanceOf`にあり、farmから戻すpositionではない | balanceと既存allowanceを保存し、revokeは別に判断 | | candidate | identity、position、exit source、backingの必要条件が一致し、account指定simulationが成功 | 回収保証とせず、人間reviewまで署名しない | | blocked | 対象exitがpaused、支払原資不足、transfer revert、simulation revert | Writeせず、block・error・balance・incident情報を保存 | | unknown | source未検証、proxy不明、implementation変更、position不一致、solvency不明 | 不明を成功へ読み替えず、追加のread-only証拠を探す | ### drained Pair reserves、farmのLP balance、vaultの利用可能資産等が必要量を満たさない状態です。Explorer上に大きなtoken balanceがあっても、それがwithdraw対象token、全利用者への支払原資、自由にtransferできる資産とは限りません。 不足を確認したら、gasを上げたり別front-endを使ったりしても支払原資は増えません。receipt、Transfer events、incident前後のbalance変化を保存します。 ### transfer restriction token側にpause、blacklist、allowlist、fee、max amount、recipient制限、外部hook等があると、farmやPairの記録が残っていてもtransferがrevertする場合があります。ERC-20という表示だけで標準挙動を仮定せず、current token sourceを読みます。 少額のmainnet送付を「テスト」として追加しません。対象accountを指定した`eth_call`でrevert dataを保存し、[custom errorの読み方](/archives/6002)でcurrent ABIと照合します。 ### paused pause flagと、exit functionへ実際に付いたmodifierを分けます。停止中だけ呼べるemergency functionを持つ設計も、停止中はwithdrawまで止まる設計もあります。 誰がpause / unpauseできるか、roleが変更されたか、official incident responseに再開条件が示されているかも記録します。再開予定を第三者DMの約束で補完しません。 ### malicious upgradeの疑い implementation、beacon、admin、owner、roleの変更をeventsとstorageで追います。deposit後にlogicが変わり、transfer先、fee、withdraw条件、upgrade権限が変わっているなら、古いABIとsimulation結果を捨ててcurrent codeからやり直します。 「悪意あるupgrade」という結論は、変更されたsource、calldata、events、資産移動等の証拠が揃うまで保留します。upgradeableであること自体を被害の証拠にはしません。 ### insolvency internal accounting上の債権と、実際に支払える資産の差を確認します。farmやvaultが他protocolへ資産を預けている場合、直接保有balanceだけでも、自己申告的なaccounting値だけでも不十分です。 solvencyを確認できなければ、outcomeは未確定です。「自分のamountだけなら先に出せる」と推測してWrite候補へ進めません。 ## local fixtureで停止条件を再現する ここでは、証拠不足を成功へ読み替えないため、再現用の入力データで停止条件を確認します。実在プロジェクトを判定する仕組みではありません。 ```text checkedAt: 2026-08-29 environment: local deterministic fixture chainId: 31337 checkedBlock: 24000000 target contracts: 0x2222...2222 〜 0x5555...5555（架空address） wallet / RPC / private data: none transactionHash / receipt: none simulation evidence: local-simulation-only ``` 成功fixtureの結果は次の通りです。 | case | position evidence | result | | --- | --- | --- | | wallet token | balance 250、allowance 100 | `wallet-held-no-recovery-write` | | wallet V2 LP | LP balance 100、source / backing照合、remove simulation success | `write-candidate-requires-human-review` | | staked V2 LP | pool / user amount 100、source / backing照合、withdraw simulation success | `write-candidate-requires-human-review` | | vault share | share 80、maxRedeem 80、previewAssets 72、current proxy照合 | `write-candidate-requires-human-review` | 別caseでは、source未検証、proxy admin不明、implementation変更、position 0、pool不一致、pause、transfer制限、backing不足、vault limit 0、simulation revertをそれぞれ停止理由にします。9 testsはtransactionを送らずに通り、すべてのresultへ`recoveryGuaranteed: false`を付けています。 fixtureの数値は市場価格、実際のtoken decimals、特定projectのsolvencyを表しません。架空addressの結果をmainnet contractへ転用しないでください。 ## accountを固定してsimulationする Write候補まで証拠が揃った場合も、署名前に同じ条件で`eth_call`します。 ```text simulation record: chainId = confirmed chain block = fixed block number from = affected account to = confirmed current contract value = expected native value input = current ABIでencodeしたfunctionと引数 implementation= checked implementation result = return data または revert data ``` `from`を省略すると、account固有のbalance、role、position、allowance、lock条件を再現できない場合があります。block numberを残さないと、後でbalance、pause、implementationが変わったときに同じ結果を追えません。 simulation成功は、指定stateでcallがrevertしなかった証拠です。次は保証しません。 - contractやtokenの安全性 - 受取assetの市場価値 - front-runningやstate変化後の本番成功 - fee、tax、price impactを含む経済的な妥当性 - 全利用者へのsolvency - 実資産の回収完了 `estimateGas`が返ったことも成功保証ではありません。gas見積りとcall結果の切り分けは[estimateGas失敗の確認方法](/archives/6003)を参照してください。 ## 署名前・receipt・最終stateを分ける High riskのため、この記事だけを根拠に署名へ進まないでください。対象contractを理解する人間reviewで候補が承認された場合でも、wallet画面で次を再確認します。 1. signing accountとchain ID 2. transaction `to`とcurrent implementationの関係 3. function selectorと全引数 4. pid、LP amount、share amount、receiver / owner 5. native tokenの`value` 6. 新しいapprove、Permit、multicall、delegatecallが混ざっていないか 7. simulationしたblockからpause、balance、implementationが変わっていないか 送信後はtransaction hashが出ただけで成功としません。[失敗transactionの確認順](/archives/6001)に沿って、receiptの`status`、block、input、logsを読みます。 さらに、意図したstateへ変わったかを確認します。 | action候補 | expected evidence | final Read | | --- | --- | --- | | revoke | token contractの成功receiptとApproval event | `allowance(owner,spender)` | | V2 remove | Pair / Router関連のBurn・Transfer等をsourceどおり確認 | LP balance、token A / B balances、Pair reserves | | farm withdraw | farmのWithdraw等とLP tokenのTransfer | `userInfo`、wallet LP balance、reward state | | vault redeem | Withdraw eventとunderlying Transferをcurrent sourceどおり確認 | share balance、underlying balance、limits | receipt成功はEVM実行がrevertしなかったことを示します。予想と違うrecipient、fee、tokenを受け取った場合まで「回収成功」とまとめず、calldata、events、最終balanceを比較します。 ## incident情報と証拠を保存する 回収候補がない場合も、公開証拠は後の調査、公式support、法執行機関等への相談に役立つ可能性があります。次を変更せず保存します。 - transaction hash、block number、timestamp、from / to - calldata、receipt status、logs、internal calls - contract source、compiler設定、proxy implementation、admin / role - incident前後のtoken、LP、farm、vault balances - projectの公式announcement URLと確認時刻 - front-end errorのscreenshotとURL - simulation request、block、result / revert data SNSの投稿やDMは削除される場合がありますが、screenshotだけでon-chain事実を置き換えません。hash、address、blockと対応づけます。個人情報やSecret Recovery Phraseは証拠ファイルへ入れません。 ## 「回収します」というDMを信用しない [MetaMaskの公式support案内](https://support.metamask.io/stay-safe/safety-in-web3/what-are-metamasks-official-support-channels/)では、supportが未依頼DMで連絡したりSecret Recovery Phraseを求めたりしないと説明しています。被害や障害を公開投稿すると、偽supportやrecovery agentから接触されることがあります。 次の要求には応じません。 - Secret Recovery Phrase、private key、passwordの入力・送信 - walletを「同期」「検証」「再有効化」する外部site - remote desktopや画面共有でのwallet操作 - 回収前の税金、保証金、解除fee、gas代の送付 - 不明contractへのapprove、Permit、blind signature - 「急がないと消える」とDMだけで迫る追加transaction 公式supportへ相談する場合は、自分で保存していた公式URLから入り、公開addressやtransaction hash等、必要最小限の情報だけを共有します。誰かへseed phraseを渡してしまった場合は、この記事のcontract回収フローとは別のwallet compromiseとして扱ってください。 ## 最終チェックリスト - [ ] 追加approve、署名、送付を止めた - [ ] chain ID、account、checked blockを記録した - [ ] wallet token、wallet LP、staked LP、vault shareを区別した - [ ] official addressと過去transaction `to`を照合した - [ ] verified sourceの範囲と、未検証部分を分けた - [ ] proxy、current implementation、admin、upgrade historyを確認した - [ ] paused flagだけでなく対象exitのmodifierとroleを読んだ - [ ] `balanceOf`、`allowance`、`poolInfo`、`userInfo`等をread-onlyで確認した - [ ] exit functionのsource、引数、recipient、fee、eventsを確認した - [ ] drained、transfer restriction、pause、upgrade、insolvencyを分岐した - [ ] accountとblockを固定したsimulation結果を保存した - [ ] simulation成功を安全・本番成功・回収保証にしていない - [ ] 署名、receipt、events、最終stateを別々に確認する - [ ] DM、recovery agent、追加送金、Secret Recovery Phrase共有を避けた 最短の判断は、front-endの代替URLを探すことではありません。**権利の場所、current code、支払原資、account固有simulationを順に読み、一つでも未確定なら署名前に止めること**です。 contract address、ABI、proxyの共通確認は[直コンの安全確認](/archives/1005)へ戻ってください。 ## 確認した一次情報 - [ERC-20 Token Standard](): 確認日 2026-08-29 - [ERC-1967 Proxy Storage Slots](): 確認日 2026-08-29 - [ERC-4626 Tokenized Vaults](): 確認日 2026-08-29 - [Etherscan What’s Contract Verification](): 確認日 2026-08-29 - [OpenZeppelin Pausable source](): 確認日 2026-08-29 - [OpenZeppelin AccessControl source](): 確認日 2026-08-29 - [OpenZeppelin Proxy Upgrade Pattern](): 確認日 2026-08-29 - [ethereum.org JSON-RPC eth\_call](): 確認日 2026-08-29 - [ethereum.org Smart contract security](): 確認日 2026-08-29 - [ethereum.org Revoke token access](): 確認日 2026-08-29 - [Uniswap V2 Router02 source](): 確認日 2026-08-29 - [PancakeSwap legacy MasterChef source](): 確認日 2026-08-29 - [MetaMask Official support channels](): 確認日 2026-08-29 - [MetaMask Basic security tips](): 確認日 2026-08-29 - [MetaMask Spoofing scams](): 確認日 2026-08-29 --- # PancakeSwapでLPを追加・解除する方法｜V2・V3 positionの見分け方 PancakeSwapの現行Liquidity画面をもとに、V2 LP tokenとV3 NFT position、StableSwapの見分け方、流動性の追加・解除、positionが表示されないときの確認順を解説します。 正規URL: https://3mikan.com/archives/821 著者: みかん 公開: 2021-05-15T20:28:44.000Z 更新: 2026-08-28T16:40:00.000Z PancakeSwapで「LP」と呼ばれるものは一種類ではありません。現在のLiquidity画面では、少なくとも**V3、StableSwap、V2**を別々のfilterで確認します。V2ではfungibleなLP token、V3ではtoken IDを持つNFT positionを管理するため、追加・解除の入口も確認項目も違います。 この記事では、2026年8月29日にwallet未接続で確認したPancakeSwapの現行Web画面を使い、**versionの判別 → 流動性の追加 → positionの管理・解除 → 表示されない場合の切り分け**の順に説明します。画面内の価格、APR、fee tierの利用割合、slippage toleranceは撮影時点の観測値であり、推奨値や将来の収益を示すものではありません。 > 実資産を動かす前に > > 公式domain、chain、接続account、2種類のassetのcontract address、受取asset、walletの署名内容を毎回確認してください。本記事の検証ではwallet接続、署名、transaction送信を行っていません。 ## 最初に、自分が持っているものを見分ける PancakeSwapのLiquidity画面を開き、まず`All`、`V3`、`StableSwap`、`V2`のfilterを確認します。`Hide closed positions`が有効だと、閉じたpositionは一覧から隠れます。
PancakeSwapの流動性一覧でAll、V3、StableSwap、V2のフィルターが並ぶ画面
2026年8月29日の現行Liquidity画面。wallet未接続のため個人のpositionは表示していない。
| 形式 | 所有状態の目印 | 主な設定・情報 | 管理の入口 | | --- | --- | --- | --- | | V2 | pairごとのLP token残高 | 2 asset、pool share | V2のadd / remove flow | | V3 | NFT positionとtoken ID | fee tier、min / max price、Active / Inactive | position詳細 | | StableSwap | Liquidity画面のStableSwap filter | pool固有のasset構成と条件 | StableSwap側のflow | [PancakeSwapのLiquidity Guide](https://docs.pancakeswap.finance/get-started/liquidity-guide)も、V2ではLP token、V3ではNFT positionを受け取ると分けています。「LP」という表示名だけで操作方法を決めないことが最初のポイントです。
V2 LP tokenとV3 NFT positionの違い。V2はLP token残高、V3はtoken IDと価格範囲を持つ
PancakeSwapには[Infinityという別のprotocol設計](https://developer.pancakeswap.finance/contracts/infinity/overview)もあります。ただし、今回実機確認したLiquidity一覧のfilterはV3、StableSwap、V2です。Infinityのpoolやpositionを扱う場合は、V2 / V3の説明をそのまま当てはめず、Infinityの現行資料と画面を確認してください。 ## 追加する前の5項目 Add Liquidityを押す前に、次の5項目を一つずつ固定します。 1. URLが`pancakeswap.finance`の公式domainか 2. walletのnetworkが、対象poolのあるchainか 3. token symbolではなくcontract addressが意図したassetと一致するか 4. V2、V3、StableSwapのどれへ追加するか 5. gas用のnative tokenと、2 assetの必要残高があるか 同じsymbolの偽tokenや別chainのtokenは存在できます。検索結果、SNS、walletの表示名だけでaddressを決めず、projectとasset発行元の一次情報を照合してください。 また、流動性提供にはprice変動、smart contract、token、approval、chain、インパーマネントロスなどのリスクがあります。LPを持てば必ず利益になるわけではありません。保有だけの場合との数量差は[インパーマネントロスの計算](/archives/580)、許容差の考え方は[Price impactとslippageの違い](/archives/741)で確認できます。 ## V3は価格範囲を決めてpositionを作る 現行V3 Add画面では、pairと`v3` badgeに加え、fee tier、price chart、min / max price、deposit amountが表示されます。
PancakeSwap V3のBNBとUSDTの流動性追加画面で、価格範囲とfee tierを設定する欄
BNB-USDT V3の観測画面。価格、APR、0.01% fee tier、0.50% slippageは撮影時点の表示であり推奨値ではない。
### V3追加の確認順 1. Liquidityから`Add Liquidity`へ進み、pairの2 assetとcontract addressを確認する 2. 画面上部のversionが`v3`であることを確認する 3. fee tierごとのpool状態、流動性、取引量、条件を確認する 4. `MIN PRICE`と`MAX PRICE`を入力し、現在価格との位置関係を見る 5. deposit amountと、両assetの使用見込みを確認する 6. wallet接続後に表示されるapprovalやposition作成の内容を署名前に読む 7. 送信した場合はreceiptと、作成されたNFT token IDを確認する fee tier横の`Pick`や割合は、画面が示す当該時点の情報です。「多く選ばれているから安全」「APRが高いから有利」とは限りません。poolごとの取引、流動性、値動き、range外になる可能性を分けて考えます。 price rangeを狭くすると、資本を現在価格付近へ集中できます。一方、価格がrange外へ出るとpositionは取引に使われず、feesを得ません。[PancakeSwap Pools](https://docs.pancakeswap.finance/products/pancakeswap-exchange/pancakeswap-pools)では、range外のpositionが片方のtokenだけになる場合も説明されています。`Full Range`も含め、rangeの広さだけで優劣を決めないでください。 ## position詳細で見る場所 V3の追加後は、LP token残高ではなくNFT positionの詳細を確認します。現行画面では、status、`V3 LP #...`のtoken ID、fee tier、liquidity、unclaimed fees、min / max / current priceを一画面で確認できます。
PancakeSwapの公開V3ポジション詳細でActive、token ID、fee tier、価格範囲が表示された画面
公開on-chain BNB-USDT position #6883117の観測画面。ownerやwallet addressは表示していない。数量と価格は変動する。
| 表示 | 確認する意味 | | --- | --- | | `Active` | 現在価格が設定range内にある状態 | | `Inactive` | 現在価格がrange外にあり、当該positionが取引に使われない状態 | | `Closed` | liquidityを取り除いたpositionとして現行UIで表示される状態 | | `V3 LP #...` | NFT positionを識別するtoken ID | | fee tier | positionが属するpoolのfee tier | | Liquidity | position内のasset量と評価表示。価格とともに変動する | | Unclaimed Fees | まだ回収していないfeesの表示 | | Price Range | min、max、current priceの位置関係 | `Inactive`は故障や消失を意味しません。まずcurrent priceがrangeのどちら側へ出たかを見ます。range変更は既存positionの単純な数値編集ではなく、liquidityの取り出しと新しい条件での追加を伴うため、受取asset、fees、slippage、gasを改めて確認します。 ## V3 positionを減らす・閉じる position詳細の`Remove`から進むと、削除割合、受け取るpooled assets、earned fees、slippage toleranceなどが表示されます。
PancakeSwap V3ポジションの削除画面で、削除割合と受取トークンが並ぶ
公開V3 positionのread-only確認。wallet未接続のため削除、回収、署名は行っていない。
1. positionのpair、token ID、fee tierを再確認する 2. 25%、50%、75%、Maxなどから削除割合を選ぶ 3. `YOU WILL RECEIVE`の2 assetと数量、feesを確認する 4. native BNBかWBNBかなど、受取形式を変えるoptionがあれば意図と照合する 5. slippage toleranceは観測値をそのまま採用せず、quoteと許容条件を確認する 6. walletのtransaction内容、network、contract、受取先を読んでから署名する 7. receipt、NFT positionの残存liquidity、wallet残高、feesの回収結果を確認する liquidityの削除とfeesの回収が画面上でまとめられるか、別操作になるかはpositionと現行UIを確認してください。「Removeを押したから全feesが必ずwalletへ入った」と決めず、receiptと最終stateで判断します。 ## V2は2枚のtokenを預けてLP tokenを受け取る V2 Add画面では`v2` badgeと2 assetのdeposit欄が表示され、V3のprice range selectorはありません。
PancakeSwap V2のBNBとUSDTの流動性追加画面で、2種類の入金欄が表示されている
BNB-USDT V2の観測画面。価格、APR、0.25%表示、0.50% slippageは撮影時点の情報。
### V2追加の確認順 1. LiquidityのV2 filterまたはV2 flowへ進み、`v2` badgeを確認する 2. 2 assetのcontract address、balance、poolのreserve比を確認する 3. 片方の数量を入力し、もう片方の使用見込みと余る数量を見る 4. tokenごとのapproval対象が、公式情報で確認したV2 Routerか確認する 5. minimum amounts、slippage、deadline、受取accountを署名前に確認する 6. 送信後はreceiptと、受取accountのV2 LP token残高を確認する BNB ChainのV2 Router addressは、2026年8月29日時点の[公式V2 Addresses](https://developer.pancakeswap.finance/contracts/v2/addresses)で`0x10ED43C718714eb63d5aA57B78B54704E256024E`と確認しました。addressは記事からだけコピーせず、利用時に公式資料、chain、contract sourceを再照合してください。 V2 Routerを直接操作する必要がある場合は、通常のWeb UIより確認項目が増えます。[V2 LPを直コンで作成する前の確認順](/archives/1663)で、allowance、minimum amounts、deadline、receiptまで分けています。 ## V2 LP tokenを引き出す V2のremove画面では、削除する割合と、受け取る2 assetの見込みが表示されます。
PancakeSwap V2の流動性削除画面で、削除割合とBNB、USDTの受取欄が並ぶ
BNB-USDT V2 removeの観測画面。wallet未接続でtransactionは送信していない。
1. V2 filterで対象pairを選ぶ 2. LP tokenがwalletにあるか確認する 3. Farmへ預けている場合は、正しいpoolからLP tokenをwalletへ戻す 4. 削除割合と、受け取る2 assetの見込みを確認する 5. LP tokenのapproval、minimum received、slippage、deadlineを確認する 6. 署名後はreceipt、LP token減少、2 assetの増加を照合する LP tokenがwalletへ見えない状態で、別のpairやpool IDを推測して解除しないでください。V2 Routerの直接解除は[V2 LPを直コンで解除する前の確認順](/archives/1788)、Farm側のpool照合は[MasterChefの`_pid`を照合する方法](/archives/1791)に分けています。 ## positionが見つからないときの確認順 「前に作ったLPが一覧にない」ときは、同じ操作を繰り返す前に所有stateを切り分けます。
positionが表示されないときにchain、account、filter、version、staking、migrationの順で確認するフロー
| 順番 | 確認すること | 読み取り証拠 | | ---: | --- | --- | | 1 | BNB Chainなど、positionを作ったchainか | wallet network、chain ID、explorer | | 2 | mint時の受取accountを接続しているか | receiptのrecipient、NFT owner、LP `balanceOf` | | 3 | `All`を選び、`Hide closed positions`の状態を確認したか | 現行Liquidity UI | | 4 | V2、V3、StableSwapの正しいfilterを見ているか | LP token address、NFT token ID、pool情報 | | 5 | V2 LPをFarmへstakeしていないか | Farm / MasterChefのuser state | | 6 | 過去にV2をremoveしてV3へmigrationしていないか | V2 removeとV3 mintのreceipt | V3のNFTが見つからない場合、BNB ChainのNonfungible Position Managerは、2026年8月29日時点の[公式V3 Addresses](https://developer.pancakeswap.finance/contracts/v3/addresses)で`0x46A15B0b27311cedF172AB29E4f4766fbE7F4364`と確認できます。まずread-onlyでownerとtoken IDを照合し、公式address、chain、receiptが一致しないまま書き込みへ進まないでください。 UIのindexingやRPC表示が一時的に遅れている可能性と、実際に別account・別versionへある可能性は分けます。画面の再読込だけで解決したと断定せず、explorerのreceiptとon-chain stateを基準にします。 ## V2からV3へ移行するとき [公式Migration Guide](https://docs.pancakeswap.finance/welcome-to-pancakeswap/how-to-guides/v3-v2-migration/how-to-migrate)の流れは、概ね次の3段階です。 1. V2またはStableSwapのLPをFarmへ預けている場合はunstakeする 2. 旧poolからliquidityをremoveし、2 assetへ戻す 3. V3でfee tierとprice rangeを決め、新しいNFT positionを作る V2 LP tokenが同じ形のままV3 NFTへ自動変換されるわけではありません。removeとaddは別のtransactionで、それぞれ受取数量、slippage、gas、price変動を確認します。 [公式Migration FAQ](https://docs.pancakeswap.finance/welcome-to-pancakeswap/how-to-guides/v3-v2-migration/faq)では、migration対象が表示されない場合に、V2 Farmがまだ稼働しているか、FarmsのV2 filter、LiquidityのV2 filterから手動で確認する方法も案内しています。V2が一覧に残っているから即座に異常、あるいは必ず移行すべき、と判断しないでください。 ## LP提供で確認する主なリスク | risk | 何が起きるか | 先に確認すること | | --- | --- | --- | | インパーマネントロス | 価格比の変化で、単純保有とLPの価値がずれる | price scenario、feesを含む損益 | | V3 range外 | 取引に使われずfeesを得ず、片方のassetへ偏る場合がある | current / min / max price | | fee・APR変動 | 画面表示が将来も続くとは限らない | 算出期間、取引量、liquidity、incentive | | slippage | quoteと実行時の条件が変わる | minimum received、許容条件、deadline | | token risk | transfer制限、偽token、価値の急変がありうる | official address、source、発行主体 | | contract・approval | bug、upgrade、過大allowanceの影響を受ける | official contract、spender、allowance | | phishing | 偽domainや悪意ある署名へ誘導される | domain、walletのtransaction / signature内容 | APRからgas、IL、range外時間、token価格を引かずに「利益」とみなさないでください。小額であっても、署名内容が読めない、official addressが一致しない、受取assetが不明な場合は止めます。 ## よくある質問 ### V2 LP tokenがwalletに表示されません walletの表示filterだけでなく、正しいchainのPair contractで受取accountの`balanceOf`を確認します。Farmへstake済みならwallet残高は減り、Farm側のstateを確認する必要があります。transaction receiptのstatus、recipient、Pair addressも照合してください。 ### V3 positionは普通のLP tokenですか いいえ。PancakeSwap V3では、fee tierとprice rangeを持つpositionがNFTとして表され、token IDで識別されます。V2 LP tokenのamountやPair addressだけを探しても、同じ方法では見つかりません。 ### `Inactive`になったら資金はなくなりますか `Inactive`は、現在価格が設定range外にある状態です。position詳細でasset量とprice rangeを確認できます。range外では当該positionは取引に使われずfeesを得ませんが、直ちに資金消失を意味する表示ではありません。token自体の価格やcontract riskは別に残ります。 ### 画面の0.50% slippageを使えばよいですか 一律の推奨値ではありません。本記事の0.50%は撮影時の観測表示です。pairのliquidity、price変動、token仕様、quote、minimum receivedを確認し、許容できない結果を受け入れるほど広げないでください。 ### V2はもう解除できませんか 公式Migration FAQではV2から手動でremoveする導線も説明されています。現行V2 filterと対象pairを確認し、Farmへstakeしていれば先に正しいpoolから戻します。V2の表示があることと、利用を推奨することは別です。 ### StableSwapもV2と同じ手順ですか 同じと決めないでください。現行Liquidity画面でもStableSwapは独立filterです。poolのasset構成、LP形式、追加・解除画面、contractをその時点の公式資料で確認します。 ## 最終チェックリスト - 公式domain、chain、接続accountを確認した - token symbolではなく2 assetのofficial contract addressを確認した - V2、V3、StableSwapのどれを操作するか固定した - V3ならfee tier、token ID、min / max / current priceを確認した - V2ならPair、LP token残高、Farmのstaking stateを確認した - APR、fee tier割合、slippage表示を推奨値として扱っていない - approvalのspender、amount、deadlineを確認した - remove時の割合、受取asset、native / wrapped形式を確認した - walletの署名内容とtransactionの送信先を読んだ - 送信後にreceipt、残高、positionの最終stateを照合する LP追加・解除は、ボタン名を覚えるより「いま所有している形式」を先に特定する方が安全です。V2 LP token、V3 NFT position、staked LPを分け、画面表示とon-chain evidenceが一致してから次の操作へ進んでください。 ## 確認した一次情報 - [PancakeSwap Liquidity Guide](): 確認日 2026-08-29 - [PancakeSwap Pools](): 確認日 2026-08-29 - [PancakeSwap V2 to V3 Migration Guide](): 確認日 2026-08-29 - [PancakeSwap V2 to V3 Migration FAQ](): 確認日 2026-08-29 - [PancakeSwap V3 Addresses](): 確認日 2026-08-29 - [PancakeSwap V2 Addresses](): 確認日 2026-08-29 - [PancakeSwap Infinity Overview](): 確認日 2026-08-29 - [PancakeSwap V2 Router source](): 確認日 2026-08-29 --- # MasterChefの\_pidを照合する方法｜withdraw前の確認順 MasterChef系contractの_pidを、deposit transactionのinput・event、poolInfoのLP token、userInfoのamountで照合し、withdrawとemergencyWithdrawの違い、シミュレーション、receipt、回収不能条件を解説します。 正規URL: https://3mikan.com/archives/1791 著者: みかん 公開: 2021-08-20T19:20:42.000Z 更新: 2026-08-28T16:00:20.000Z `_pid`は、すべてのDeFiで共通する「LPの番号」ではありません。特定のMasterChef系contractが、内部のpool一覧を参照するために使う引数名です。同じLP tokenでも、chainやfarm contractが違えばpidは変わります。 この記事では、**過去のdeposit transaction → `poolInfo(pid).lpToken` → `userInfo(pid,user).amount`**の三つを照合し、withdraw候補を確認する順番を説明します。historical PancakeSwap MasterChef sourceを実装例に使いますが、現在の全farmへ一般化しません。wallet接続、署名、transaction送信は行わず、緊急時の資金回収も保証しません。
deposit transactionのinputまたはevent、poolInfoのLP token、userInfoのamountを順に照合するMasterChef pid確認フロー
## `_pid`はcontract固有ABIの引数 historical PancakeSwap MasterChefには、次のようなfunctionがありました。 ```solidity deposit(uint256 _pid, uint256 _amount) withdraw(uint256 _pid, uint256 _amount) emergencyWithdraw(uint256 _pid) poolInfo(uint256 _pid) userInfo(uint256 _pid, address _user) ``` ここでpid 7が意味を持つのは、そのMasterChef contractのpool一覧の中だけです。別contractのpid 7、画面上の並び順、token symbolが同じでも同一poolとは限りません。 [Solidity ABI specification](https://docs.soliditylang.org/en/latest/abi-spec.html)に基づき、transaction inputのfunction selectorと引数を、対象contractのcurrent ABIでdecodeします。入力欄のlabelや外部サイトの番号だけで決めません。 ## LPの三つのstateを分ける pidを探す前に、資産がどこにあるかを分けます。 | state | 読み取り候補 | 次の処理 | | --- | --- | --- | | wallet内V2 LP | Pair `balanceOf(user)` | V2 Routerでremove候補 | | MasterChefへstakedしたLP | `userInfo(pid,user).amount` | contract固有のwithdraw候補 | | V3 NFT position | owner / position data | Position Manager系contract | `userInfo`のamountは、MasterChef側の内部帳簿です。walletのLP balanceやPair reservesとは別です。withdraw後にwalletへLPが戻っても、token A / Bへ戻すにはさらにV2 Routerの解除処理が必要です。[V2 LPを解除する確認順](/archives/1788)と混同しないでください。 ## chain・MasterChef・sourceを固定する 次の値を一つのメモへ固定します。 1. network名とchain ID 2. user account 3. project公式情報にあるMasterChef / farm contract address 4. verified sourceとcompiler設定 5. proxyか、現在のimplementationとadminは何か 6. current ABIのdeposit、withdraw、emergency function、Read、events 7. 預けたV2 Pair addressとtoken0 / token1 8. 過去のdeposit transaction hash [Etherscanのcontract verification](https://docs.etherscan.io/contract-verification/whats-contract-verification)はsourceとdeployed bytecodeを照合しますが、安全、公式、回収可能を意味しません。project公式address、chain、proxy implementationを別に確認します。 address、ABI、proxy、シミュレーションの共通手順は[直コンの安全確認](/archives/1005)も参照してください。 ## deposit transactionのinputからpid候補を読む 自分が預けたtransactionが分かる場合、総当たりより先にinputをdecodeします。 1. transactionのchain、`from`、`to`、hashを確認する 2. `to`が固定したMasterChef addressか照合する 3. receiptの`status`を確認する 4. current ABIでinputをdecodeする 5. functionがdeposit系か、最初の引数が何かを読む 6. amountと、同じtransactionのLP `Transfer` logsを確認する historical PancakeSwap実装の`deposit(uint256,uint256)`なら、最初の引数がpid候補、2番目がLPのraw amountです。ただし別実装では引数順、function名、vault share、beneficiaryなどが異なります。 失敗receiptのinputにもpidは含まれますが、depositが成立した証拠にはなりません。receipt statusとstateを分けます。 ## eventからpid候補を照合する historical PancakeSwap MasterChefには、次のeventが定義されていました。 ```solidity event Deposit(address indexed user, uint256 indexed pid, uint256 amount); event Withdraw(address indexed user, uint256 indexed pid, uint256 amount); event EmergencyWithdraw(address indexed user, uint256 indexed pid, uint256 amount); ``` eventを使うときは、名前だけでなく次を確認します。 - logを発行したaddressが固定したMasterChefか - event topicがcurrent ABIと一致するか - indexed userが自分のaccountか - pidとamountを正しい型でdecodeしたか - receiptが成功しているか - LP tokenの`Transfer` logとamountの関係 別contractも同名eventを発行できます。Explorerの見出しだけでなく、log addressとtopics / dataを読みます。 ## `poolInfo(pid).lpToken`でPair addressを照合する inputやeventから得たpidはまだ候補です。Readで`poolInfo(pid)`を呼び、返されたLP token addressを、預けたV2 Pair addressと完全一致で比較します。 ```text deposit evidence: chainId = 確認済みchain contract = 確認済みMasterChef pid = 7 poolInfo(7): lpToken = 0x4444...4444 expected pair: pair address = 0x4444...4444 ``` symbol、token名、Explorer labelが同じだけでは不十分です。Pairの`token0()` / `token1()`、Factory、bytecode、official sourceも照合します。 `poolLength`がある実装では0から件数未満をread-onlyで列挙できますが、deposit証拠があるなら候補を先に絞ります。大量RPCや外部toolの結果を、transactionとcontract stateより優先しません。 ## `userInfo(pid,user).amount`で現在positionを読む 次に、同じMasterChef、pid、userの組み合わせで`userInfo`を読みます。 ```text userInfo(7, user): amount = 100000000000000000000 rewardDebt = 3000000000000000000 ``` amountが100 LP相当でも、表示値へ直すにはLP contractの`decimals()`が必要です。`rewardDebt`は一般に「受取可能reward残高」そのものではなく、reward計算用の内部値です。意味は対象sourceの計算式で確認します。 amountが0なら、次を分けます。 - 別pid、別MasterChef、別account、別chain - すでにwithdraw済み - positionが別contractへmigrationされた - vault share等、別の帳簿で管理されている - proxy implementationが変わった - deposit transactionが失敗していた ## historical sourceでwithdrawの差を読む [PancakeSwapのlegacy MasterChef source](https://github.com/pancakeswap/pancake-farm/blob/master/contracts/MasterChef.sol)では、通常の`withdraw(_pid, _amount)`はpoolとuserを更新し、pending CAKEを計算・transferした後、指定LP amountをuserへ戻す構成でした。 一方、同sourceの`emergencyWithdraw(_pid)`は、概ね次の順です。 1. `poolInfo[_pid]`と`userInfo[_pid][msg.sender]`を読む 2. 記録された`user.amount`のLP tokenをsenderへtransferする 3. `EmergencyWithdraw` eventを発行する 4. `user.amount`と`user.rewardDebt`を0にする このfunctionはpending rewardを計算・支給しません。固定例で100 LPを預け、未請求reward相当が12.3あるなら、historical modelでは100 LPを戻す一方、12.3は支給されない想定です。 > これはhistorical PancakeSwap実装の説明です > > 同名functionでも、別farmはfee、lock、paused、role、proxy、vault share、複数reward、別recipientなどを持つ場合があります。対象contractのsourceとABIを読まずに呼びません。 ## emergencyでも失敗・回収不能はある `emergencyWithdraw`という名前は、成功や救済を保証しません。 - pidが違い、別poolを参照している - `userInfo` amountが0 - contractが必要なLP tokenを保有していない - LP tokenのtransferがrevertする - farmがpausedされ、emergency functionも止まる実装 - proxy implementationが変更された - access control、lock、withdraw feeがある - malicious token callbackやblacklistがある - LPは戻ってもPair reservesがdrainされ、tokenへ解除できない - contractにwithdraw経路自体がない [ethereum.orgのsmart contract security](https://ethereum.org/developers/docs/smart-contracts/security/)が扱うaccess control、emergency stop、外部call等の条件は、contractごとに確認が必要です。追加approveや不明な署名を「緊急だから」で通さないでください。 ## シミュレーションで対象accountの条件を再現する 候補functionと引数を固定したら、対象accountを`from`にして`eth_call`します。 確認する値は次の通りです。 - RPCのchain ID、block number - MasterChefのproxy / implementationとcurrent ABI - `from`、transaction `to`、function、pid、amount - `poolInfo(pid).lpToken` - `userInfo(pid,user)` - MasterChefのLP token balance - resultまたはrevert reason / custom error シミュレーションが成功しても、transactionは送信されず、stateも保存されません。本番までにbalance、paused状態、implementation、gas、deadline相当の条件が変わる可能性があります。悪意あるcontractを安全に変えるものでもありません。 ## 署名前・receipt・最終stateを分ける 署名要求が出た場合は、少なくとも次を再照合します。 1. networkとsigning account 2. transaction `to`が確認済みMasterChefか 3. functionが`withdraw`か`emergencyWithdraw`か 4. pidとamount 5. native tokenの`value` 6. wallet warningとシミュレーション結果 送信後は、transaction hashが出ただけで成功としません。 - receiptの`status`、block number、transaction input - MasterChef addressが発行したWithdraw / EmergencyWithdraw event - LP token addressが発行したTransfer event - walletのLP `balanceOf` - `userInfo(pid,user).amount`とreward state - 次にLPを解除するならPair reservesとRouter条件 receipt、calldata、logs、最終stateを追う方法は[transaction receiptの確認順](/archives/6001)、decodeできないrevertは[custom errorの読み方](/archives/6002)を参照してください。 ## pidが決まらないときの分岐 | 状況 | 止める理由 | 次に読むもの | | --- | --- | --- | | transaction `to`が違う | 別farm / helper経由の可能性 | internal calls、logsの発行元、official docs | | inputをdecodeできない | ABI / implementation不一致 | verified source、proxy履歴、selector | | event pidとinputが違う | 別eventまたは別処理の可能性 | log address、topics、source | | `poolInfo(pid).lpToken`不一致 | wrong pidまたはmigration | Pair address、pool update events | | `userInfo` amountが0 | 現在positionの証拠がない | account、chain、withdraw履歴、別帳簿 | | source未検証 | functionの意味を確認できない | 書き込みを止め、公式sourceを探す | 三つの証拠が一致しない状態でpidを推測して書き込まないでください。 ## 最終チェックリスト - wallet内LP、staked V2 LP、V3 NFT positionを区別した - chain、user、MasterChef address、proxy、implementation、ABIを固定した - 成功したdeposit transactionのinputまたはeventからpid候補を得た - logの発行元addressとABIを確認した - `poolInfo(pid).lpToken`と預けたPair addressが一致した - `userInfo(pid,user).amount`が現在positionを示した - withdrawとemergencyWithdrawのsource上の差を読んだ - reward放棄、LP transfer失敗、paused、upgrade、insolvencyを確認した - シミュレーション、署名、receipt、event、最終balanceを別々に確認する - 緊急時の資金回収を保証していない LPがwalletへ戻った後の解除は[removeLiquidityの引数と確認順](/archives/1788)、LPを作る側のdesired / minimum amountsは[addLiquidityの引数と確認順](/archives/1663)で確認してください。 ## 確認した一次情報 - [ethereum.org Interacting with smart contracts](): 確認日 2026-08-29 - [ethereum.org Smart contract security](): 確認日 2026-08-29 - [Etherscan What’s Contract Verification](): 確認日 2026-08-29 - [Solidity ABI specification](): 確認日 2026-08-29 - [ERC-20 Token Standard](): 確認日 2026-08-29 - [PancakeSwap legacy MasterChef source](): 確認日 2026-08-29 --- # 直コンでV2 LPを解除する前に｜removeLiquidityの引数と確認順 V2型RouterのremoveLiquidityを直接呼ぶ前に、LP残高・allowance・reserve・totalSupply・minimum amounts・deadline・シミュレーション・receiptと回収不能条件を確認する順番を解説します。 正規URL: https://3mikan.com/archives/1788 著者: みかん 公開: 2021-07-09T19:40:57.000Z 更新: 2026-08-28T16:00:10.000Z V2型LPを解除すると、LP tokenをburnし、Pairが保有する2種類のtokenを持分に応じて受け取ります。ただし、walletにLPがない、別versionのRouterを見ている、minimum amountsや期限が合わない、token transfer自体が失敗する、といった条件では実行できません。 この記事では、Uniswap V2 Router02の`removeLiquidity`を公開sourceの例に使います。**LPの所在 → contractとABI → 受取見込み → allowance → minimum amountsとdeadline → シミュレーション → receiptと最終balance**の順に確認します。直コンによる資金回収やRug pull回避を保証するものではありません。
LPの所在確認、受取見込みとminimum amounts、シミュレーション、receiptと最終balanceへ進むV2 LP解除フロー
## 解除する前にLPの所在を確認する 同じ「流動性position」でも、解除方法は所有stateで変わります。 | 読み取れたstate | 何を持っているか | 次の入口 | | --- | --- | --- | | Pairの`balanceOf(user) > 0` | wallet内のV2 LP token | V2 Routerのremove系function候補 | | MasterChef等の`userInfo(pid,user).amount > 0` | farmへstakedしたV2 LP | farmのwithdraw条件を確認し、LPをwalletへ戻す | | NFT owner / positionが確認できる | V3型position | Position Manager系contractを確認 | | どれも確認できない | chain、account、version、移転履歴が違う可能性 | transaction履歴とaddressを再照合 | MasterChefのpool IDは[deposit記録から`_pid`を照合する方法](/archives/1791)で確認します。stakedしたままのLPをV2 Routerへ渡すことはできません。 ## chain・Router・Pair・tokenを固定する 次を一つの確認メモへまとめます。 1. network名とchain ID 2. signing accountとLP owner 3. project公式情報にある対象versionのRouter address 4. Routerが参照するFactory address 5. Pair address、`token0()`、`token1()` 6. token A / Bのofficial addressと`decimals()` 7. Router、Factory、Pair、tokenのverified source 8. proxyなら現在のimplementation、admin、ABI V2互換を名乗っていても、functionやfee-on-transfer対応、permit、proxy構成が違う場合があります。[contract verification](https://docs.etherscan.io/contract-verification/whats-contract-verification)はsource照合の入口であり、安全証明ではありません。 直コン共通のaddress・proxy・ABI確認は[verified contractとシミュレーションの確認順](/archives/1005)も参照してください。 ## `removeLiquidity`の7引数を読む [Uniswap V2 Router02](https://github.com/Uniswap/v2-periphery/blob/master/contracts/UniswapV2Router02.sol)のERC-20同士の関数は次の形です。 ```solidity function removeLiquidity( address tokenA, address tokenB, uint liquidity, uint amountAMin, uint amountBMin, address to, uint deadline ) public returns (uint amountA, uint amountB); ``` | 引数 | 意味 | 確認する値 | | --- | --- | --- | | `tokenA` / `tokenB` | Pairを構成する2 token | Pairの`token0` / `token1`とofficial address | | `liquidity` | burnするLPのraw amount | LP `decimals()`と`balanceOf(user)` | | `amountAMin` / `amountBMin` | 受取量の下限 | reserve、total supply、token仕様、quote時block | | `to` | 2 tokenの受取先 | 意図したaccount / contract | | `deadline` | 実行を許す期限 | 最新block timestampと意図した有効時間 | Router02では、PairのLP tokenをRouterからPairへ移し、Pairの`burn(to)`を呼びます。返り値のtoken順を`tokenA` / `tokenB`へ対応させ、各minimumと比較します。 片方がnative tokenなら`removeLiquidityETH`系、fee-on-transfer tokenなら対応variantが用意される場合があります。名前が似ていてもsignature、返り値、処理が違うため、対象RouterのsourceとABIを基準にします。 ## LP残高とallowanceをraw amountで読む 通常の`removeLiquidity`では、PairというERC-20 contractでRouterへのallowanceが必要です。 ```text Pair.balanceOf(user) >= liquidity Pair.allowance(user, Router) >= liquidity transaction.to = Router approve transaction.to = Pair approve argument spender = Router ``` LP tokenの表示桁を18と決め打ちせず、Pairの`decimals()`を読みます。unlimited approveを既定にせず、解除量、既存allowance、token固有のapprove動作を確認します。 `removeLiquidityWithPermit`系は、LP allowanceの代わりにpermit署名を使うvariantです。署名だから安全、gas表示がないから無料、とは判断できません。domain、chain ID、verifying contract、owner、spender、value、nonce、deadlineと、対象Pairがpermitを実装しているかを確認します。 ## reserveとtotal supplyから受取見込みを読む 単純化したV2 Pairでは、持分比率は次の形で確認できます。 ```text share = burnするLP / total LP supply amountAQuote = reserveA × share amountBQuote = reserveB × share ``` 固定例を使います。 | state | 値 | | --- | ---: | | reserve A / B | 1,000 A / 500 B | | total LP supply | 1,000 LP | | burnするLP | 100 LP | | 単純な受取見込み | 100 A / 50 B | token Aが6 decimals、token Bが18 decimalsならraw amountはそれぞれ`100000000`と`50000000000000000000`です。 これは確認用の基準値です。実行前のswapでreservesが変わる、feeがPairへ蓄積する、tokenがtransfer feeやrebasingを持つ、protocol固有処理がある場合は結果が変わります。Pairの現在stateと対象Router sourceを読みます。 ## minimum amountsは受取下限として作る `amountAMin` / `amountBMin`を0にすると、そのtoken側の受取下限を外します。 先ほどのquoteへ「1%の差を許容する」という仮定だけを置くと、次の計算です。 ```text amountAMin = 100 × (1 - 0.01) = 99 A amountBMin = 50 × (1 - 0.01) = 49.5 B ``` 1%は推奨値ではありません。許容範囲を広げればrevertしにくくなる一方、少ない受取量を受け入れる幅も広がります。quoteのblock、reserves、tokenのtransfer仕様、市場変動を確認し、raw unitsへ変換します。 slippageを上げて不明なtoken制限を解決しようとせず、[Price impact・slippage・MEVの違い](/archives/741)も分けて確認してください。 ## `deadline`は古い入力を止める条件 Router02は`deadline < block.timestamp`ならrevertします。Explorerへ遠い未来のtimestampを貼るのではなく、対象chainの最新block timestampへ意図した有効時間を加えます。 - Unix秒か - 対象chainのblock timestampを基準にしたか - quoteや確認内容を有効とみなせる時間か - 署名直前にまだ期限内か 期限を延ばすことは、minimum amountsやcontractの安全性を改善しません。 ## 固定例で成功・失敗を比較する 固定したV2 stateで100 LPを解除すると、単純計算では100 A / 50 Bです。minimumが99 A / 49.5 B、LP allowanceが100 LP、期限内なら、入力条件を満たします。 次の条件は別々に止めます。 | 変更した条件 | 判定 | | --- | --- | | Pair allowanceが0 | RouterがLPを移せず失敗 | | walletのLP balanceが99、解除量が100 | LP不足 | | `amountAMin`が101 A | 見込み100 Aが下限未満 | | `deadline`が最新blockと同じか過去 | 期限切れ | | Pairのtoken addressが確認メモと違う | 対象contract不一致として中止 | この成功判定は、その入力とstateを使ったV2型の計算結果です。実transactionのreceiptでも、deployed contractの安全性証明でもありません。 ## シミュレーションでrevertと入力を先に確認する 対象accountを`from`に指定し、同じRouter address、calldata、`value`、block条件で`eth_call`します。 確認するものは次の通りです。 - RPCのchain IDとblock number - Router addressとcurrent ABI - decodeした`removeLiquidity`の7引数 - LP balance / allowance、reserves、total supply - token A / Bの受取見込みとminimum amounts - resultまたはrevert data シミュレーション成功後にもreserves、allowance、deadline、proxy implementationは変わりえます。成功は本番実行や資金回収の保証ではありません。 ## 署名前・receipt・final stateを別々に見る 署名前はnetwork、account、transaction `to`、function、7引数、native tokenの`value`、spending cap、warningを照合します。walletがcalldataをdecodeできない場合は先へ進まず、別のdecoderとverified ABIで確認します。 送信後は次の順に確認します。 1. receiptの`status`、block number、transaction hash 2. transaction `to`とinput calldata 3. Pair addressが発行した`Burn`、`Transfer`等のlogs 4. walletのLP balance減少 5. recipientのtoken A / B balance増加 6. Pair reservesと残allowance receipt成功だけ、eventだけ、画面表示だけでは証拠が足りません。[receipt・calldata・logs・stateの確認順](/archives/6001)で発行元addressも含めて確認します。 ## 解除できない条件を分ける front-endが停止していても、contractが動作し、正しいLPをwalletが所有し、Router / Pairの条件を満たせば、公開interfaceから状態を確認できる場合はあります。しかし次の状態では、直コンでも回収を保証できません。 - LPがfarmやvaultへ移っており、walletが所有していない - withdraw経路がない、paused、role制限、lock期間がある - proxy implementationやRouterが悪意あるcodeへ変わった - Pair reservesがdrainされ、LPに対応する資産がない - tokenがblacklist、transfer停止、fee、malicious callbackを持つ - Pair / Router / token sourceが未検証で、ABIを安全に特定できない - LP token自体が別Pairまたは偽物 - gas tokenがなく、transactionを送れない [ethereum.orgのsmart contract security](https://ethereum.org/developers/docs/smart-contracts/security/)が示すように、access controlやemergency stopなどの実装条件はcontractごとに異なります。追加approveや不明な署名を急がず、chain、address、source、transaction履歴、receipt、allowanceを保存して状況を分けます。 ## 症状別チェック表 | 症状 | 最初に読む値 | 次の確認 | | --- | --- | --- | | LPが0 | Pair `balanceOf(user)` | chain、account、farm `userInfo`、NFT position | | allowance不足 | Pair `allowance(user, Router)` | spender、解除量、permit variant | | minimum系revert | reserves、total supply、quote block | decimals、token順、transfer fee | | transfer失敗 | token source、paused / blacklist | Pair balance、Router variant、revert data | | receipt成功だが残高が違う | logsの発行元とrecipient | token fee、別account、最終state | | sourceが違う | official address、proxy implementation | 書き込みを止め、ABIを推測しない | ## 最終チェックリスト - wallet内V2 LP、staked LP、V3 NFT positionを区別した - chain、Router、Factory、Pair、token A / Bを公式情報で照合した - verified source、proxy、implementation、ABI、adminを確認した - LP balance、decimals、allowance、reserves、total supplyを読んだ - 受取見込みとminimum amountsをraw unitsで記録した - minimum amountsを0、deadlineを任意の遠い値にしていない - unlimited approveを既定にしていない - シミュレーション、署名、receipt、logs、最終balanceを分けた - front-end停止やRug pull時の回収を保証していない V2 LPを作る側は[addLiquidityの引数と確認順](/archives/1663)、LPをfarmから戻す前のpool ID確認は[MasterChefの`_pid`を照合する方法](/archives/1791)へ進んでください。 ## 確認した一次情報 - [ethereum.org Interacting with smart contracts](): 確認日 2026-08-29 - [ethereum.org Smart contract security](): 確認日 2026-08-29 - [Etherscan What’s Contract Verification](): 確認日 2026-08-29 - [ERC-20 Token Standard](): 確認日 2026-08-29 - [Uniswap V2 Router02 source](): 確認日 2026-08-29 - [Uniswap V2 Pair source](): 確認日 2026-08-29 --- # 直コンでV2 LPを作成する前に｜addLiquidityの引数と確認順 V2型RouterのaddLiquidityを直接呼ぶ前に、chain・公式address・ABI・reserve・decimals・allowance・minimum amounts・deadline・シミュレーション・receiptを確認する順番を解説します。 正規URL: https://3mikan.com/archives/1663 著者: みかん 公開: 2021-07-07T12:03:59.000Z 更新: 2026-08-28T16:00:00.000Z V2型DEXでLPを作成する処理は、2種類のtokenをRouterへ預ければ終わり、というものではありません。対象chain、RouterとPair、tokenの桁数、poolのreserve比、利用許可、minimum amounts、期限を一組で確認する必要があります。 この記事では、Uniswap V2 Router02の`addLiquidity`を公開sourceの例に使い、**読み取り → 入力作成 → シミュレーション → 署名前確認 → receiptと最終state**の順に整理します。特定DEXやtokenの利用を勧めるものではなく、wallet接続、署名、transaction送信は行いません。 > 対象はV2型のfungible LP tokenです > > V3のpositionはtoken IDを持つNFTで、price rangeやfee tierも必要です。MasterChefへ預けたLPはwallet残高とは別のstaking stateです。V2 Routerの手順をそのまま使いません。
addressとABIの照合、allowance、minimum amountsとdeadline、シミュレーション、receipt確認へ進むV2 LP追加フロー
## まずV2・V3・stakingを分ける | state | 所有状態 | 追加・解除の入口 | この記事の対象 | | --- | --- | --- | --- | | V2 liquidity | ERC-20形式のLP token | V2 Routerの`addLiquidity` / `removeLiquidity`系 | 対象 | | V3 liquidity | NFT positionとtoken ID | Position Manager系contract | 対象外 | | staked V2 LP | farm / MasterChef側の`userInfo`等 | `withdraw`等でLPをwalletへ戻してから解除 | 対象外 | 「LP」という表示名だけでは判別できません。walletのtoken一覧、Pair contractの`balanceOf`、NFT ownership、farmの`userInfo`を読み、いま何を所有しているかを先に固定します。 ## chain・contract・ABIを固定する 書き込み画面で`addLiquidity`を探す前に、次の値を一つのメモへまとめます。 | 項目 | 確認する内容 | | --- | --- | | chain | network名とchain ID | | Router | project公式情報にある対象versionのaddress | | Factory | Router sourceが参照するFactory address | | Pair | `getPair(tokenA, tokenB)`の結果。未作成なら作成条件も確認 | | token A / B | official address、symbol、`decimals()`、特殊なtransfer制限 | | source | Router、Factory、Pair、tokenのverification状態 | | proxy | proxyか、現在のimplementationとadminは何か | | ABI | 現在のimplementationに対応するfunctionとevent | [Etherscanのcontract verification](https://docs.etherscan.io/contract-verification/whats-contract-verification)は、公開sourceとdeployed bytecodeを照合する仕組みです。verified表示は、project公式、安全、監査済み、upgrade不能を意味しません。Explorerのlabelだけでaddressを決めず、project側の一次情報とchainを照合します。 共通の確認順は[直コンでverified contract・ABI・simulationを確認する方法](/archives/1005)で詳しく説明しています。 ## `addLiquidity`の8引数を読む [Uniswap V2 Router02のsource](https://github.com/Uniswap/v2-periphery/blob/master/contracts/UniswapV2Router02.sol)にあるERC-20同士の関数は、次の形です。 ```solidity function addLiquidity( address tokenA, address tokenB, uint amountADesired, uint amountBDesired, uint amountAMin, uint amountBMin, address to, uint deadline ) external returns (uint amountA, uint amountB, uint liquidity); ``` | 引数 | 意味 | 署名前に照合するもの | | --- | --- | --- | | `tokenA` / `tokenB` | 2種類のERC-20 address | chain、公式address、Pairの`token0` / `token1` | | `amountADesired` / `amountBDesired` | 最大で使うraw amount | `decimals()`、wallet balance、現在reserve比 | | `amountAMin` / `amountBMin` | 実際の使用量として許容する下限 | quoteの前提block、許容差、0ではないこと | | `to` | mintしたLP tokenの受取先 | signing accountと意図したrecipient | | `deadline` | 実行を許す期限のUnix timestamp | 最新block timestamp、意図した有効時間 | 返り値の`amountA` / `amountB`は実際に使用された量で、`liquidity`はmintされたLP token量です。desired amountsの全量が必ず使われるわけではありません。 片方がnetwork native tokenの場合は`addLiquidityETH`など別のsignature、引数、`msg.value`になります。wrapped tokenとの関係をsourceで確認せず、名前だけで置き換えないでください。 ## reserve比と`decimals()`からraw amountを作る 既存poolでは、Routerがreserve比に合う組み合わせを計算します。一方を多く指定しても、比率から外れた分は使われない場合があります。 条件を固定した例を見ます。 | 条件 | token A | token B | | --- | ---: | ---: | | decimals | 6 | 18 | | reserve | 1,000 | 500 | | desired amount | 100 | 50 | | raw amount | `100000000` | `50000000000000000000` | この例はreserve比が2:1なので、100 Aと50 Bが使われる計算です。token Aを18 decimalsと決め打ちすると、数量が1兆倍ずれます。symbolや画面表示ではなく、対象token contractの`decimals()`を読みます。 最初のliquidityを入れるpoolでは、価格比を最初の預け入れ側が実質的に決め、minimum liquidityの扱いも既存poolと異なります。既存poolの例をそのまま使わず、Factory / Pair sourceと経済的影響を別途確認します。 ## approveはtokenごとに確認する Routerがtoken A / BをPairへ移すには、通常それぞれのtoken contractでRouterに対するallowanceが必要です。 ```text token A allowance(owner, Router) >= 使用予定のA token B allowance(owner, Router) >= 使用予定のB ``` `approve` transactionの`to`はtoken contractで、引数の`spender`がRouterです。Router addressをtoken address欄へ入れるなど、`to`と`spender`を混同しないでください。 unlimited approveを既定にせず、今回必要な量、token固有のapprove仕様、既存allowanceを確認します。LP追加後に残るallowanceと、サイト接続解除は別のstateです。[ERC-20](https://eips.ethereum.org/EIPS/eip-20)の基本とrevokeの確認は[approve・allowance・revokeの安全確認](/archives/6007)も参照してください。 ## minimum amountsを0にしない `amountAMin` / `amountBMin`は、実行時の使用量が下限を下回ったときにrevertさせる条件です。0にすると、そのtoken側の下限保護を外します。 固定例では、quote 100 A / 50 Bに対して「1%の差を許容する」という仮定を置くと、計算は次のようになります。 ```text amountAMin = 100 × (1 - 0.01) = 99 A amountBMin = 50 × (1 - 0.01) = 49.5 B ``` これは推奨値ではありません。許容差を広げるほど実行しやすくなる一方、意図と違う比率を受け入れる範囲も広がります。流動性、価格変動、transfer fee、rebasing、token制限、routeの違いを確認し、quoteを取得したblockとraw amountを記録します。 Price impactとslippageの違いは[DEXのPrice impact・slippage・MEVを確認する方法](/archives/741)、LP保有中の数量変化は[インパーマネントロスの計算](/archives/580)で確認できます。 ## `deadline`は最新blockを基準にする Router02は`deadline >= block.timestamp`を確認し、期限切れならrevertします。`deadline`は「いつでも通る大きな数字」ではなく、quoteや確認内容を有効とみなす時間の境界です。 1. 対象chainの最新block timestampを読む 2. 意図した短い有効時間を明示して加算する 3. Unix秒であることを確認する 4. 署名画面へ進む直前に期限切れでないか再確認する 端末時刻、別chainのblock、ミリ秒を混ぜると誤った値になります。長すぎる期限は古い条件を実行可能なまま残し、短すぎる期限は署名前後にrevertしやすくなります。一律の秒数ではなく、操作と確認に必要な時間を意識して決めます。 ## 数値例で成功と失敗を分ける 先ほどの固定条件で、V2 Routerの比率計算を再現すると次の結果になります。 | 入力・状態 | 値 | | --- | ---: | | reserve A / B | 1,000 A / 500 B | | total LP supply | 1,000 LP | | desired A / B | 100 A / 50 B | | minimum A / B | 99 A / 49.5 B | | 使用されるA / B | 100 A / 50 B | | mint見込み | 100 LP | 同じ条件でも、次は実行前に止めるべき状態です。 - `amountAMin`または`amountBMin`が0 - token A / Bのallowanceがdesired amountを下回る - reserve Bが500から400へ変わり、使用見込み40 Bが`amountBMin` 49.5 Bを下回る - 最新block timestampが`deadline`以上 - Pair、Router、chain、ABIのいずれかが確認メモと一致しない この計算はV2型の説明用です。fee-on-transfer token、rebasing token、callbackを持つ実装、異なるRouter、初期liquidityなどは同じ結果になりません。 ## シミュレーションと本番結果を分ける [ethereum.orgの説明](https://ethereum.org/developers/docs/smart-contracts/interacting/)にあるように、書き込みはtransactionですが、同じcallを`eth_call`で事前評価し、revertや返り値を確認できます。 シミュレーションでは、少なくとも次を記録します。 - RPCのchain IDとblock number - `from`、Routerの`to`、native tokenを使う場合の`value` - current ABIでdecodeしたfunctionと8引数 - token balances、allowances、reserves、deadline - result、revert reason、custom error 成功してもtransactionはまだ送信されていません。シミュレーション後にreserve、allowance、balance、deadline、proxy implementationが変わる場合があり、contractやtokenの安全性も保証しません。 ## 署名前と送信後に確認する 署名要求が出た場合は、入力メモとwallet表示を再照合します。 1. networkとsigning account 2. transactionの`to`が確認済みRouterか 3. `addLiquidity`と8引数 4. native tokenの`value` 5. token A / Bとspending cap 6. minimum amountsとdeadline 7. warningとシミュレーション結果 送信後はtransaction hashだけで終わらせません。 - receiptの`status`、block number、transaction `to`、input - Pair addressが発行した`Mint`とLP tokenの`Transfer`等のlogs - token A / Bの減少量 - recipientのLP `balanceOf` - Routerに残ったallowance - 未使用分と想定外の残高差 event名だけで発行元を確認しないと、別contractの同名eventを取り違えます。receipt、calldata、logs、最終stateの読み方は[transaction receiptの確認順](/archives/6001)を参照してください。 ## よくある失敗を切り分ける | 症状 | 最初に確認すること | 次に確認すること | | --- | --- | --- | | `EXPIRED` | 最新block timestampとdeadline | 秒 / ミリ秒、別chain、署名待ち時間 | | minimum amount系のrevert | quote時と現在のreserves | decimals、token順序、transfer fee | | `TRANSFER_FROM_FAILED`等 | balance、allowance、spender | blacklist、paused、token固有return値 | | Pairが見つからない | Factoryとtoken pair | 対象version、未作成pool、token順序 | | LPがrecipientに見えない | receipt.statusとPair logs | `to`、別chain、wallet表示filter | | シミュレーション成功後に失敗 | stateとdeadlineの差 | nonce、gas、proxy upgrade、MEV | revert dataをABIで読む方法は[custom errorのデコード](/archives/6002)、gas estimationの切り分けは[estimateGasが失敗する理由](/archives/6003)に分けています。 ## 最終チェックリスト - V2 LP tokenであり、V3 NFT positionやstaked LPではない - chain、Router、Factory、Pair、token A / Bを公式情報と照合した - verified source、proxy、implementation、ABI、adminを確認した - `decimals()`、reserves、balances、allowancesを同じblock付近で読んだ - desired amountsと実際の使用見込みを分けた - minimum amountsは0ではなく、前提とraw unitsを記録した - deadlineは最新blockを基準に、意図した期限として作った - シミュレーションと署名、receipt、logs、最終stateを別々に確認する - unlimited approveや資金回収を既定・保証にしない LPをwalletへ戻す側は[直コンでV2 LPを解除する前の確認順](/archives/1788)、farmへ預けたLPのpool IDは[MasterChefの`_pid`を照合する方法](/archives/1791)へ進んでください。 ## 確認した一次情報 - [ethereum.org Interacting with smart contracts](): 確認日 2026-08-29 - [Etherscan What’s Contract Verification](): 確認日 2026-08-29 - [ERC-20 Token Standard](): 確認日 2026-08-29 - [Solidity ABI specification](): 確認日 2026-08-29 - [Uniswap V2 Router02 source](): 確認日 2026-08-29 - [Uniswap V2 Pair source](): 確認日 2026-08-29 --- # 暗号資産を日本円に現金化する方法｜交換・出金・税務記録を確認 暗号資産を日本円へ現金化する前に、金融庁登録業者、対応資産・ネットワーク、売却と銀行出金、匿名性の誤解、国税庁資料に基づく税務イベント・取引記録を確認する順番を解説します。 正規URL: https://3mikan.com/archives/3809 著者: みかん 公開: 2021-11-02T13:57:05.000Z 更新: 2026-08-28T14:12:00.000Z 暗号資産を日本円に現金化する場合、一般的には「暗号資産を売る」と「日本円を銀行口座へ出金する」の2段階があります。ウォレットから交換業者へ送るなら、その前に入金という段階も加わります。 ここで先に分けたいのが、**銀行へ着金する時点**と**税務上の損益を計算する時点**です。国税庁の現行FAQでは、日本円への売却だけでなく、暗号資産での商品購入や暗号資産同士の交換にも所得計算が必要になる例が示されています。 この記事では、日本の個人（居住者）を主な対象として、現金化の経路、匿名性の誤解、残す記録、税務確認の順に整理します。特定の交換業者、売却時期、銘柄を勧めるものではありません。 > 税務上の取扱いは、対象年、居住地、所得区分、他の所得、取引内容で変わります。この記事は一般的な確認順です。個別の申告判断は、対象年の国税庁資料、所轄税務署、税理士へ確認してください。 ![暗号資産から日本円の銀行着金までと各段階で残す記録の流れ](/diagrams/crypto-cashout/3809-cashout-record-flow.svg) ## 現金化の前に固定する5項目 「どこで売るか」を決める前に、資産と記録の状態を一つずつ確認します。 | 項目 | 確認する内容 | 確認せず進んだときの問題 | | --- | --- | --- | | 資産 | 正式名称、contract address、数量 | 同じsymbolの別tokenを選ぶ | | network | 現在のchainと入金先が受け付けるchain | 対応しないnetworkへ送る | | 現在地 | 自己管理wallet、国内外のservice、DeFiなど | どの履歴を保存すべきか分からなくなる | | 売却先 | 金融庁登録、対応資産、入出金条件、手数料 | 未登録または非対応の経路を選ぶ | | 記録 | 取得日、取得価額、移動履歴、fee、bank明細 | 売却後に譲渡原価を再計算できない | [金融庁の暗号資産交換業者登録一覧](https://www.fsa.go.jp/menkyo/menkyoj/kasoutuka.pdf)は随時更新されます。利用時点で登録状況、行政処分、取扱資産を確認してください。 登録されていることは、暗号資産の価値、安全性、収益を金融庁が保証・推奨するという意味ではありません。サービスのsecurity、fee、入出金条件も別に確認します。 ## 国内の登録業者を経由する基本の流れ 自己管理walletや別serviceにある暗号資産を銀行口座の日本円にする場合、全体は次の流れです。 ### 1. 入金先の資産とnetworkを確認する 交換業者が同じ資産とnetworkの入金を受け付けているか確認します。symbolが同じでも、contractやchainが違えば同じ入金先とは限りません。 Memo / Tagなど追加情報が必要な資産もあります。入金画面のaddressだけをコピーし、資産、network、Memo / Tag、最低入金額、停止情報を読まずに送らないでください。 ### 2. on-chainと交換業者側のstatusを分ける 送金後は、TXID、chain、from、to、token、amount、confirmationsを保存します。そのうえで、交換業者の入金履歴が受付中、反映済み、要確認のどれかを見ます。 Explorerでsuccessでも、交換業者側の確認数、Memo / Tag、取扱条件を満たしていなければ、残高反映まで完了したとは言えません。[取引所への入金が反映されないときの確認手順](/archives/6008)では、chainと受取側を分けて確認しています。 ### 3. 売却の注文と結果を確認する 入金残高を確認した後、売却するpair、数量、注文種別、見積価格、feeを確認します。販売所と取引所、成行と指値では、表示方法と結果が同じとは限りません。 注文を出しただけで売却済みと判断せず、約定数量、平均価格、未約定数量、取引履歴、feeを保存します。売却で得た日本円残高と、税務計算に使う売却価額・譲渡原価は分けて記録します。 ### 4. 日本円出金と銀行着金を確認する 交換業者側で、日本円出金の最低額、fee、受付時間、登録名義と銀行口座の条件を確認します。これらはserviceごとに変わるため、古い記事の固定額や固定時間を使いません。 出金後は、交換業者の出金履歴と銀行明細の両方を保存します。交換業者側の完了表示と銀行着金が一致しない場合は、同じ出金を繰り返さず、受付番号と時刻を添えてsupportへ確認します。 ## P2P・card・ATM・DEXは同じ「現金化」ではない 旧記事ではP2P、暗号資産card、ATMを一律に現金化方法として紹介していました。しかし、現在利用できるか、誰が相手か、どの法定通貨へ換えるか、銀行へ出金できるかは別々です。 | 経路 | 実際に行うこと | 利用前に確認すること | | --- | --- | --- | | 国内登録業者 | 暗号資産を売却し、日本円残高を銀行へ出金 | 登録、対応資産・network、注文、fee、銀行条件 | | P2P・直接取引 | 相手方と暗号資産・支払手段を交換 | 相手方、本人確認、支払取消、詐欺、価格、契約・税務記録 | | 暗号資産card | 決済時などに暗号資産または法定通貨を使用 | 日本居住者向け提供、発行者、本人確認、換算時点、fee、利用停止条件 | | 暗号資産ATM | 端末を通じて購入・売却等を行う | 国内の現行運営者、登録、設置、本人確認、対応資産、fee | | DEX・stablecoin交換 | 暗号資産Aを暗号資産Bへ交換 | 日本円の銀行着金ではない。交換時の価額と履歴も確認する | 「銀行を挟まない」「海外serviceを使う」という理由だけで、簡単・安い・匿名とは判断できません。現在の公式条件を確認できない経路は、現行手順として使わないでください。 ## 「匿名なら分からない」を前提にしない wallet addressは氏名そのものではありませんが、取引が自動的に匿名になるわけではありません。登録交換業者では対象取引で取引時確認が行われ、交換業者の履歴、銀行明細、on-chain transactionなど、異なる場所に記録が残ります。 大切なのは「誰かに見つかるか」ではなく、取引内容から所得と申告要否を正しく計算することです。匿名性や追跡回避を理由に、本人確認を迂回するserviceや他人名義の口座を使わないでください。 ### CARFの対象を広げて読まない 国税庁の[CARF制度資料](https://www.nta.go.jp/taxes/shiraberu/kokusai/carf/pdf/0025009-025.pdf)によると、日本では2026年から暗号資産交換業者等による対象取引の特定手続を行い、2027年に2026年分の報告と税務当局間の情報交換を開始する予定です。 ただし、この資料が説明するのは**非居住者に係る暗号資産等取引情報**の自動交換です。日本の居住者による全wallet・全transactionが同じ仕組みで一律報告される、という説明ではありません。CARFを過度に広げず、個別の課税関係は国税庁FAQと対象年の申告案内で確認します。 ## 現金化できない・止まったときの確認 | 症状 | 最初に確認するもの | やらないこと | | --- | --- | --- | | 入金addressが出ない | 資産、network、入金停止、account条件 | 別networkのaddressへ送る | | TXIDがpending | Explorerのstatus、nonce、fee、replacement | 同じ内容をすぐ再送する | | chain上はsuccess、残高未反映 | to、token、amount、Memo / Tag、confirmations、入金status | successだけで受取完了と断定する | | 売却注文が残る | 未約定数量、指値、流動性、取消status | 約定済みと考えて出金へ進む | | 日本円出金が保留 | 名義、bank情報、受付時刻、service status | 本人確認や審査を迂回する | | 価格が極端に不利 | 入力桁、pair、注文種別、spread、fee | 知らない両替業者へ急いで移す | pending、dropped、replacedをchain上で分ける場合は[transaction statusの判定フロー](/archives/6004)を使い、元hashと置換hashの両方を残してください。 ## 税務確認は日本円化より前から始まる [国税庁の暗号資産等FAQ](https://www.nta.go.jp/publication/pamph/pdf/virtual_currency_faq_03.pdf)は、令和7年12月1日時点の法令・通達等に基づく一般例をまとめています。 | 取引 | FAQでの考え方 | 残す記録 | | --- | --- | --- | | 暗号資産を日本円へ売却 | 譲渡価額と譲渡原価等の差を計算 | 売却数量、価格、日時、fee、取得価額 | | 暗号資産で商品・serviceを購入 | 支払った暗号資産を譲渡したものとして計算 | 商品価額、支払数量、時価、取得価額 | | 暗号資産AをBへ交換 | AでBを購入したものとしてAの譲渡を計算 | 両資産、数量、交換時価、fee | | mining・staking・lending等で取得 | 取得時点の価額を収入へ算入する一般例 | 取得日時、数量、時価、関連費用 | つまり、「銀行へ出金しなければ税務確認は不要」とは限りません。年末に売却履歴だけを集めるのではなく、暗号資産同士の交換や商品購入も含め、発生時点から記録します。 ## 売却代金と所得金額は同じではない 国税庁FAQ 1-1の例では、4 BTCを400万円で取得し、そのうち0.2 BTCを21万円で売却しています。手数料をいったん除くと、計算は次の通りです。 ```text 1 BTC当たりの取得価額 = 4,000,000円 ÷ 4 BTC = 1,000,000円 0.2 BTCの譲渡原価 = 1,000,000円 × 0.2 BTC = 200,000円 所得金額 = 210,000円 - 200,000円 = 10,000円 ``` 銀行へ入る21万円の全額が利益ではありません。一方で、21万円だけを見て少額と判断するのでもなく、選択した評価方法で譲渡原価を計算し、売却時feeなど直接必要な費用を確認します。 ## 年間で再計算できる記録を残す 個人の暗号資産の評価方法には総平均法と移動平均法があります。どちらを使うか、届出や継続適用を含め、[国税庁の現行FAQ](https://www.nta.go.jp/publication/pamph/shotoku/kakuteishinkokukankei/kasoutuka/index.htm)で確認してください。売却ごとに都合のよい取得単価へ変えるものではありません。 国内交換業者の年間取引報告書を使う場合、国税庁は「暗号資産の計算書（総平均法用）」を案内しています。国外serviceや個人間取引などで年間取引報告書がない場合も、bankの入出金、serviceの取引履歴、公表相場などから取得価額・売却価額を確認する方法がFAQに示されています。 最低限、次を年ごと・資産ごとにまとめます。 - 年始数量と年始評価額 - 購入・取得の日時、数量、円換算額 - 売却・交換・使用の日時、数量、円換算額 - wallet間・service間の移入と移出 - TXID、chain、from、to、Memo / Tag - trading fee、withdrawal fee、network feeと支払資産 - 年間取引報告書、CSV、bank明細、receipt - 年末数量と、翌年へ引き継ぐ取得価額 取引履歴を後からdownloadできる期間はserviceごとに異なります。accountを閉じる前、serviceを変更する前、年末前にexportし、読み取れる形式で保存してください。 ## 20万円だけで申告要否を決めない 令和7年分の国税庁案内では、1か所から給与を受け、その給与の全部が源泉徴収の対象である場合など、一定条件の給与所得者について、給与・退職所得以外の**所得金額**の合計が20万円を超えることを申告要件の一つに挙げています。 この20万円は売却代金や銀行着金額ではありません。また、給与が複数ある、給与収入が一定額を超える、他の所得がある、控除や還付を申告するなど、条件によって確認項目が変わります。「20万円以下なら全員が何もしなくてよい」と一律に判断しないでください。 暗号資産取引の利益は原則として雑所得に区分されますが、国税庁の令和7年12月FAQでは、収入金額、帳簿保存、営利性、事業への付随性などにより所得区分を個別に判断する例も示されています。雑所得に区分された損失は、給与所得など他の所得と通算できません。 法人、非居住者、相続・贈与、事業としての取引、低額譲渡、DeFiやNFTを含む複雑な取引は、この記事の一般例だけで結論を出さないでください。資料と事実関係を確認する必要がある相談は、[国税庁の電話・面接相談案内](https://www.nta.go.jp/taxes/shiraberu/sodan/denwa-sodan/)または税理士へ確認します。 ## 最終チェックリスト - [ ] 資産名、contract、数量、networkを確認した - [ ] 売却先が金融庁登録業者か、利用時点の一覧で確認した - [ ] 対応資産、入金network、Memo / Tag、停止情報を確認した - [ ] TXIDと交換業者側の入金statusを分けて保存した - [ ] 注文の約定数量、平均価格、未約定、feeを確認した - [ ] 日本円出金履歴とbank明細を保存した - [ ] 日本円売却以外の交換・使用・取得も年間記録へ含めた - [ ] 総平均法または移動平均法と前年繰越を確認した - [ ] 20万円を売却代金の基準として使っていない - [ ] 対象年の国税庁資料と個別相談の要否を確認した 現金化で大切なのは、最短経路を探すことではありません。**資産とnetworkを間違えず、売却から銀行着金までを確認し、同じ記録から税務上の所得を再計算できる状態にすること**です。 ## 確認した一次情報 - [金融庁: 暗号資産交換業者登録一覧（2026年8月21日時点）](): 確認日 2026-08-28 - [金融庁: 暗号資産・電子決済手段関係](): 確認日 2026-08-28 - [金融庁: 暗号資産交換業者の取引時確認に関する事後評価](): 確認日 2026-08-28 - [国税庁: 暗号資産等に関する税務上の取扱い及び計算書](): 確認日 2026-08-28 - [国税庁: 暗号資産等に関する税務上の取扱いFAQ（令和7年12月最終改訂）](): 確認日 2026-08-28 - [国税庁: 令和7年分 申告が必要かなどを調べる](): 確認日 2026-08-28 - [国税庁: 国税に関する相談窓口](): 確認日 2026-08-28 - [国税庁: 非居住者に係る暗号資産等取引情報の自動的交換制度](): 確認日 2026-08-28 --- # Bybitは日本で使える？登録状況・KYC・入出金・注文・手数料を確認 Bybitの日本向け登録状況、地域制限、KYC、入出金、注文種別、手数料を金融庁とBybit公式情報で整理。公開ページが見えることと登録済みであることを分け、確認日付きで案内します。 正規URL: https://3mikan.com/archives/1945 著者: みかん 公開: 2021-08-10T14:44:13.000Z 更新: 2026-08-28T13:40:00.000Z Bybitの日本語ページは日本から表示できます。しかし、**公開ページが見えることと、日本の暗号資産交換業者として登録されていることは別**です。 この記事は、2026年8月28日に金融庁資料、Bybit公式ヘルプ、Bybit Webの公開画面を確認し、日本向け条件、本人確認、入出金、注文、手数料を一つの入口へ整理したものです。確認した公開画面は日本語・ログアウト状態で、登録、ログイン、本人確認、入出金、注文は行っていません。 > **先に確認する重要事項** > > 2026年8月21日時点として公開されている金融庁の暗号資産交換業者登録一覧に、Bybitは掲載されていません。金融庁の無登録業者に関する公表資料にはBybit Fintech Limitedが記載されています。一方、Bybitの公式サービス制限国一覧は日本を列挙していません。これらは同時に成立する情報であり、Bybitのページが表示できることや制限国一覧に日本がないことを、日本での登録や利用の適法性を示す根拠にはできません。 この記事は口座開設や取引を勧めるものではありません。居住地、対象商品、本人確認の状態により条件が変わるため、実際の判断では金融庁の最新一覧、Bybitの規約・地域制限、必要に応じて専門家の助言を確認してください。 ## 2026年8月28日時点の結論 | 確認先 | 確認できたこと | 判断できないこと | | --- | --- | --- | | 金融庁の登録一覧 | Bybitという名称は確認できない | 個別の利用行為に対する法的判断 | | 金融庁の無登録業者資料 | Bybit Fintech Limitedに対する警告の記録がある | 現在の営業実態。資料自体も現況を示すとは限らないと注記している | | Bybitの制限国一覧 | 2026年8月6日更新の記事で日本は列挙されていない | 日本の交換業登録、全機能の提供、利用者ごとの適格性 | | Bybit日本語Web | 公開の現物取引画面をログアウト状態で表示できた | 登録、KYC、入出金、注文が完了できるか | つまり、「日本から使えるか」は一つのYes/Noでは整理できません。少なくとも次を別々に確認します。 1. 金融庁の登録・警告情報 2. Bybitが定める居住地と地域制限 3. アカウント登録時の国・地域判定 4. 本人確認レベルと対象商品 5. 入出金する資産・chain・送付先の条件 この順番を飛ばし、公開価格や日本語表示だけを見て判断しないでください。 ![登録状況と地域条件から、本人確認、入出金、注文と手数料、履歴確認へ進む順序](/diagrams/bybit/1945-verification-flow.svg) ## アカウント登録とKYCの確認ポイント Bybitの登録ガイドでは、登録時に居住国を選択し、地域の規則によって別ページへの案内や制限が行われる場合があると説明しています。また、個人本人確認FAQでは、標準レベル以上の本人確認が各種サービスの前提になると案内しています。必要なレベルや利用可能な商品は、地域と商品によって異なる場合があります。 | 段階 | 画面で確認するもの | 止めて確認する場面 | | --- | --- | --- | | 登録前 | 居住国、利用規約、地域制限、対象サービス | 居住国を正しく選べない、規約と画面が食い違う | | 登録 | メールまたは電話番号、認証方法、公式ドメイン | 紹介ページから別ドメインへ移動する、認証情報を第三者へ求められる | | 本人確認 | 必要レベル、提出書類、対象商品、審査status | 居住地と書類が一致しない、対象商品が表示されない | | 利用前 | 入出金・取引の利用可否、本人確認の有効期限 | 「公開画面が見える」以外の根拠を確認できない | 固定の出金上限や「本人確認なしでも使える」といった旧情報は引き継いでいません。Bybit公式内でもアカウントや地域により表示が変わり得るため、ログイン後の自分の画面を最終条件として確認します。 ## 入金と出金は同じchainを選ぶ オンチェーン入出金では、同じ銘柄名でも複数のchainが使われます。`USDT`のように複数chainへ存在する資産は、銘柄が一致していてもchainが違えば反映されない、または回収が難しくなる可能性があります。 | 確認項目 | 入金 | 出金 | | --- | --- | --- | | 資産 | Bybitの入金画面に表示された銘柄 | 送付先が受け付ける銘柄 | | chain | Bybitが表示した対応chain | Bybitと送付先の両方が対応する同一chain | | アドレス | Bybitが発行した入金アドレス | 自分で確認した送付先アドレス | | Memo / Tag | 入金画面に表示される場合は必須 | 送付先が指定する場合は必須 | | 最低額 | 入金画面の最小入金額 | 出金画面の最小出金額 | | 手数料 | 送信元や購入事業者の手数料を含める | Bybitの出金画面に表示される額 | | 結果 | 入金履歴、confirmations、TXID、status | 出金履歴、メール・2FA、TXID、送付先status | Bybit公式の入金ガイドは、対応資産、chain、最小入金額、スマートコントラクト経由の可否、Memo / Tagが資産ごとに異なると説明しています。出金ガイドでは、メール認証とGoogle認証、chain、手数料、最小額に加え、送付先確認やTravel Ruleに関する入力が必要になる場合があります。 ### 入金前の確認順 1. Bybitの現行条件と、自分のアカウントで入金が利用できるか確認する 2. Bybitの入金画面で資産とchainを選ぶ 3. 表示されたアドレス、Memo / Tag、最小入金額、注意書きを読む 4. 送信元で同じ資産と同じchainを選ぶ 5. 確定前画面で、宛先、chain、金額、Memo / Tag、手数料を読み直す 6. 送信後はTXID、chain status、Bybitの入金履歴を分けて確認する 入金が反映されないときは、同じ送金を繰り返さず、[取引所への入金が反映されないときの確認手順](/archives/6008)でTXID、confirmations、入金条件、取引所statusを順に確認してください。Bybitに絞った画面項目は[Bybit入金方法](/archives/2846)へ分離しています。 ### 出金前の確認順 1. 送付先が受け付ける資産とchainを確認する 2. Bybitで同じ資産とchainを選び、アドレスとMemo / Tagを入力する 3. 最小出金額、出金手数料、最終受取見込み、認証方法を確認する 4. Travel Ruleなど追加情報が表示された場合は、送付先情報と一致させる 5. 申請後は出金履歴、メール、TXID、送付先の入金履歴を確認する 出金先アドレスを第三者へ送って確認してもらう場合も、認証コード、秘密鍵、シードフレーズは共有しません。詳しい確認表は[Bybit出金方法](/archives/2201)にまとめています。 ## 公開画面で確認できた注文種別 2026年8月28日、日本からBybit Webの`BTC/USDT`現物公開画面を日本語・ログアウト状態で確認しました。画面には「買い」「売り」「指値」「成行」「利食/損切」が表示され、注文結果の確認先として「未約定注文」「注文履歴」「取引履歴」がありました。登録や注文操作は行っていません。
BybitのBTC/USDT現物公開画面に指値、成行、利食損切と未約定注文、注文履歴、取引履歴が表示された状態
2026年8月28日のBybit Web。日本語・ログアウト状態。価格と注文板は撮影時の観測値で、将来の価格や利用可否を示すものではありません。
Bybit現物画面の注文板と、買い売り、指値、成行、利食損切、登録、ログインが並ぶ注文パネル
同じ公開画面の注文板と注文panelを拡大。account残高は表示されておらず、注文操作も行っていません。
Bybit公式の注文種別ガイドは、基本注文として成行、指値、条件付き注文を挙げ、商品によってTP/SL、Post Only、GTC・IOC・FOK、trailing stop、TWAPなどの高度な注文があると説明しています。 | 注文 | 主な入力 | 注文後に確認すること | | --- | --- | --- | | 指値 | 売買方向、価格、数量または合計 | 未約定、一部約定、約定、取消、maker/takerの扱い | | 成行 | 売買方向、数量または合計 | 約定価格、slippage、一部約定、取消された残量 | | 条件付き | trigger、trigger後の成行または指値、数量 | 未trigger、trigger後の未約定・約定、参照価格 | | TP/SL | trigger、注文価格または成行、対象数量 | 対象positionまたは資産、trigger後の約定状態 | | Post Only | 指値、数量、有効期間 | 即時約定と判定され取消・拒否されていないか | Bybitの現物取引ルールでは、価格・数量制限や流動性により、成行注文が一部だけ執行され、残りが取り消される場合があると案内しています。「成行なら表示価格で必ず全量約定する」とは限りません。注文量とslippageの関係は[Price impactとslippageの違い](/archives/741)で確認できます。 条件付き注文は、triggerしたことと約定したことを分けて確認します。詳しくは[Bybitの逆指値・条件付き注文](/archives/3640)へ分離しました。先物のワンウェイ/ヘッジモードとマージンの違いは[Bybitの両建てとポジションモード](/archives/3596)で扱います。 ## 手数料は一つではない Bybit公式の手数料ガイドは、入出金、法定通貨、取引、資金調達、強制決済、利息などを別の費用として説明しています。古い記事にある一つの料率だけで総費用を判断できません。 | 費用 | 発生する場面 | 最終確認先 | | --- | --- | --- | | オンチェーン送信元手数料 | 他walletや取引所からBybitへ送る | 送信元の確定前画面 | | 暗号資産購入・決済事業者の手数料 | 法定通貨や外部事業者で購入する | 注文ページと決済事業者の表示 | | オンチェーン出金手数料 | Bybitから外部アドレスへ出す | 資産・chainを選んだ出金画面 | | 現物取引手数料 | 現物注文が約定する | 自分の手数料率、注文確認、取引履歴 | | デリバティブ取引手数料 | 先物などが約定する | 商品、maker/taker、VIP条件、自分の手数料率 | | 資金調達料 | 無期限契約を対象時刻に保有する場合 | 契約のrate・次回時刻・履歴 | | 借入利息・強制決済関連 | margin、loanなどを利用する | 商品ルールとaccountの表示 | 具体的な料率は地域、商品、VIP level、maker/taker、キャンペーンによって変わるため、この記事では固定しません。分類と確認場所は[Bybitの手数料一覧](/archives/2344)、資金調達率の読み方は[Bybitの資金調達率](/archives/2939)で確認してください。 ## Bybit記事群の使い分け 重複していた登録、入出金、注文、手数料、レバレッジの説明を、このページを入口として次の検索意図へ分けました。 | URL | このページで扱うこと | 扱わないこと | | --- | --- | --- | | `/archives/1945` | 日本向け条件と全体の確認順 | 個別操作の細部、投資判断 | | [入金 `/archives/2846`](/archives/2846) | chain、アドレス、Memo / Tag、反映status | 出金操作、購入の推奨 | | [出金 `/archives/2201`](/archives/2201) | 送付先、認証、手数料、履歴 | 固定の出金時間・上限 | | [条件付き注文 `/archives/3640`](/archives/3640) | triggerと実際の注文、未約定 | 損失を必ず防ぐという断定 | | [ポジションモード `/archives/3596`](/archives/3596) | ワンウェイ/ヘッジ、margin mode | 両建てによる利益・安全の保証 | | [資金調達率 `/archives/2939`](/archives/2939) | rate、position value、支払/受取 | 全契約共通の固定時刻・固定率 | | [手数料 `/archives/2344`](/archives/2344) | 費用の種類と確認場所 | 「最安」という固定比較 | | [旧キャンペーン `/archives/2937`](/archives/2937) | 2021〜2022年掲載内容の終了扱いと現行特典の確認方法 | 現在有効と確認できない招待・ボーナス訴求 | 旧ページのURLと公開日は維持しています。2021〜2022年の紹介リンク、固定料率、ボーナス、旧UIを現行手順としては残していません。 ## 最後に確認するチェックリスト - 金融庁の登録一覧と警告資料を、確認日付きで読んだ - Bybitの地域制限に日本がないことを、登録済みという意味に置き換えていない - 居住国、本人確認レベル、対象商品を自分の画面で確認した - 入出金では資産、chain、アドレス、Memo / Tag、最低額、手数料を一組で確認した - 注文では現物/先物、売買方向、注文種別、価格、数量、単位を確認した - 注文後は未約定注文、注文履歴、取引履歴、残高またはpositionを確認した - キャンペーンは期間、対象地域、対象者、達成条件、受取期限、有効期限を個別規約で確認した - 認証コード、秘密鍵、シードフレーズを第三者へ共有していない 画面やヘルプがこの記事と違う場合は、操作を進めず、現在の日付、URL、アカウント状態を記録して最新の公式情報を優先してください。 ## 確認した一次情報 - [金融庁: 暗号資産交換業者登録一覧](): 確認日 2026-08-28 - [金融庁: 無登録で暗号資産交換業を行う者の名称等](): 確認日 2026-08-28 - [Bybit: サービス制限国](): 確認日 2026-08-28 - [Bybit: アカウント登録方法](): 確認日 2026-08-28 - [Bybit: 個人本人確認FAQ](): 確認日 2026-08-28 - [Bybit: オンチェーン入金](): 確認日 2026-08-28 - [Bybit: オンチェーン出金](): 確認日 2026-08-28 - [Bybit: 入出金履歴とstatus](): 確認日 2026-08-28 - [Bybit: 注文種別](): 確認日 2026-08-28 - [Bybit: 現物取引ルール](): 確認日 2026-08-28 - [Bybit: 手数料体系](): 確認日 2026-08-28 --- # Bybit出金方法｜アドレス・chain・Memo/Tag・手数料の確認 Bybitから暗号資産を出金するときに、送付先、chain、Memo/Tag、最小額、手数料、認証、Travel Rule、TXIDを確認する順序を公式情報に基づいて整理します。 正規URL: https://3mikan.com/archives/2201 著者: みかん 公開: 2021-08-21T20:01:44.000Z 更新: 2026-08-28T13:40:00.000Z Bybitから暗号資産を出金するときは、**送付先が受け付ける資産とchainを先に確認**します。Bybitで選べるchainでも、送付先が同じchainに対応しているとは限りません。 この記事は2026年8月28日にBybit公式ヘルプを確認し、オンチェーン出金の確認項目へ絞って更新しました。「即時出金」、固定の上限・所要時間、キャンペーン、紹介リンク、旧画面は現行情報として引き継いでいません。 > 出金操作の前に、日本向け登録状況、地域制限、本人確認の前提を[Bybitは日本で使える？](/archives/1945)で確認してください。この記事は出金の実行を勧めるものではありません。 ## 出金前に確認する項目 | 項目 | 確認する内容 | 主な誤り | | --- | --- | --- | | 送付先 | 自分が管理するwalletか、交換業者の入金先か | 第三者の指示だけで宛先を決める | | 資産 | Bybitと送付先で同じ資産か | tickerが似た別資産を選ぶ | | chain | 両方が対応する同一chainか | 手数料の安さだけで選ぶ | | アドレス | 送付先が今回表示した値か | 古い履歴やaddress poisoningを使う | | Memo / Tag | 送付先が指定しているか | 未入力、別欄への入力、値の変更 | | 最小額・手数料 | 出金額、手数料、最終受取見込み | 手数料差引後の金額を見ない | | 認証 | メール認証、Google認証など | 認証コードを第三者へ共有する | | 追加情報 | 送付先区分、受取人、Travel Rule関連 | 推測で入力する、送付先と不一致になる | Bybit公式ガイドでは、オンチェーン出金にメール認証とGoogle認証が必要とされ、資産・chainごとの最低出金額と手数料は出金画面に表示されると説明しています。送付先により追加の確認項目が表示される場合があります。 ## オンチェーン出金の確認順 1. 送付先で、受け付ける資産、chain、アドレス、Memo / Tagを表示する 2. Bybitで対象資産の出金画面を開く 3. 送付先と同じchainを選ぶ 4. アドレスと、必要ならMemo / Tagを入力する 5. 最小出金額、出金手数料、最終受取見込みを確認する 6. 送付先区分や受取人情報が表示された場合は、実態と一致する内容を入力する 7. 確定前画面で資産、chain、宛先、金額、手数料を読み直す 8. メール認証とGoogle認証を自分で完了する 9. 申請後にBybitの出金履歴を確認する 10. TXIDが発行されたらchain explorerと送付先の入金履歴を確認する 出金先の画面を開けない、対応chainを確認できない、Memo / Tagの要否が分からない場合は、推測して進めません。 ## アドレスを照合するときの注意 copy & pasteだけでは、clipboard malwareやaddress poisoningを見落とす場合があります。 - 送付先の公式画面から今回のアドレスを取得する - 貼り付け後に先頭・末尾だけでなく、複数箇所を照合する - address bookを使う場合も、登録時のchainと宛先を再確認する - test送金を行う場合は、最小出金額・手数料・送付先の最小入金額を先に確認する - QR codeを使った場合も、資産とchainを確認する 少額のtest送金でも、chainとMemo / Tagが違えば安全確認にはなりません。また、手数料や最低額によってはtest送金が成立しない場合があります。 ## 出金statusの読み方 | 観測 | 意味の候補 | 確認先 | | --- | --- | --- | | 申請が履歴にない | 確定前、認証未完了、入力エラー | Bybitの出金画面・認証メール | | 審査・処理中 | Bybit側の処理中 | 出金履歴、公式status、通知 | | TXIDがない | まだオンチェーン送信前 | Bybitの出金履歴 | | TXIDがある | networkへ送信済み | chain explorer | | chainで確定 | 送付先までの送信は確認できる | 送付先の入金条件と履歴 | | 送付先に反映しない | confirmations、Memo / Tag、最小額、maintenanceなど | 送付先support | 「完了」と表示されても、送付先への残高反映まで同じ時刻とは限りません。TXID、chain confirmations、送付先の入金statusを分けて確認します。 ## 出金手数料と所要時間 Bybit公式は、オンチェーン出金の手数料と最小出金額を、選択した資産・chainの出金画面に表示すると案内しています。古い記事の固定値ではなく、確定前に表示された値を使います。 所要時間も次の区間に分けます。 1. Bybitでの申請・認証・審査 2. networkへbroadcastされるまで 3. chainで必要confirmationsを得るまで 4. 送付先が入金を反映するまで 「即時」「何分で必ず届く」とは断定できません。遅延時に同じ出金を重ねず、出金履歴とTXIDを先に確認してください。 ## 出金を止めるべきサイン - supportや知人を名乗る相手が認証コードを求める - 秘密鍵やシードフレーズの入力を求められる - 画面共有中に出金操作を指示される - 解除料、税金、保証金を別アドレスへ送るよう求められる - 送付先の公式画面と異なるアドレスが届く - chainやMemo / Tagを確認できないまま急かされる 認証コード、秘密鍵、シードフレーズは出金確認のために第三者へ渡す情報ではありません。 ## 最終チェック - Bybitと送付先で同じ資産・同じchainを選んだ - アドレスを複数箇所で照合した - Memo / Tagの要否と値を確認した - 最小出金額、手数料、最終受取見込みを確認した - 送付先情報とTravel Rule関連の入力が一致している - 認証を自分で行い、コードを共有していない - 出金履歴、TXID、chain explorer、送付先履歴を確認できる Bybitへの入金側の確認は[Bybit入金方法](/archives/2846)、費用の分類は[Bybitの手数料一覧](/archives/2344)で確認できます。 ## 確認した一次情報 - [Bybit: サービス制限国](): 確認日 2026-08-28 - [Bybit: オンチェーン出金](): 確認日 2026-08-28 - [Bybit: 入出金履歴とstatus](): 確認日 2026-08-28 - [Bybit: 手数料体系](): 確認日 2026-08-28 --- # Bybit手数料一覧｜入金・出金・取引・資金調達料の確認場所 Bybitで発生しうるオンチェーン入出金、購入、現物・先物取引、資金調達、借入、強制決済関連の費用を分け、確定前画面と履歴で確認する順序を整理します。 正規URL: https://3mikan.com/archives/2344 著者: みかん 公開: 2021-08-24T14:59:54.000Z 更新: 2026-08-28T13:40:00.000Z Bybitの費用は、取引手数料だけではありません。オンチェーン出金、暗号資産購入、資金調達、借入利息など、**別の条件で発生する費用を合計**して確認します。 この記事は2026年8月28日にBybit公式の手数料ガイドを確認し、費用の種類と確認場所へ絞って更新しました。「最安」という比較、2021〜2022年の固定料率、手数料割引や紹介特典は現行案内として残していません。 > Bybitの日本向け条件、登録状況、本人確認の前提は[Bybitは日本で使える？](/archives/1945)で確認してください。この記事は特定の取引所や商品を勧めるものではありません。 ## まず費用を分類する | 費用 | 発生する場面 | 確認先 | | --- | --- | --- | | network・送信元手数料 | 他walletや取引所からBybitへ送る | 送信元の確定前画面 | | 暗号資産購入手数料 | 法定通貨や外部決済事業者で購入する | 注文画面、決済事業者の明細 | | オンチェーン出金手数料 | Bybitから外部addressへ出す | 資産・chainを選択した出金画面 | | 現物取引手数料 | 現物注文が約定する | 自分の手数料率、注文確認、取引履歴 | | デリバティブ取引手数料 | 無期限・先物・optionなどが約定する | 商品、maker/taker、自分の手数料率 | | 資金調達料 | 無期限positionを対象時刻に保有する | rate、position value、次回時刻、履歴 | | 借入利息 | marginやloanで借入を使う | 借入額、rate、経過時間、履歴 | | 強制決済関連 | 商品ごとの清算条件に達する | 商品ルール、account明細 | | conversionなど | 資産交換や関連serviceを使う | 確定前のrate・fee表示 | 「入金無料」「取引手数料0.1%」のような一つの表示だけでは、利用全体の費用は分かりません。 ## 入金に関する費用 Bybit公式の手数料ガイドは、暗号資産のオンチェーン入金とBybit内送金について、Bybit側の入金手数料は無料と案内しています。ただし、送信元側では次の費用が発生する場合があります。 - network fee - 送信元取引所の出金手数料 - 暗号資産を購入した決済事業者の手数料 - 法定通貨の両替や振込に関する費用 Bybitへ届く前の費用はBybitの入金画面だけでは確認できません。具体的な資産・chain・最低額は[Bybit入金方法](/archives/2846)で確認してください。 ## 出金手数料 Bybit公式は、オンチェーン出金について、選択した資産とchainに応じた出金手数料と最低出金額を出金画面へ表示すると説明しています。固定表より、確定前画面を優先します。 出金時は次をまとめて確認します。 1. 出金額 2. 資産とchain 3. Bybitの出金手数料 4. 最終受取見込み 5. 送付先の最小入金額 6. 送付先で発生する可能性のある費用 手数料が安いchainでも、送付先が未対応なら選べません。出金の安全確認は[Bybit出金方法](/archives/2201)へ分離しています。 ## 取引手数料 取引手数料は、現物、無期限・先物、optionなど商品で異なり、maker/taker、VIP level、地域、キャンペーンなどでも変わる場合があります。 Bybit公式の総合手数料ガイドは、2026年4月8日更新時点の非VIP例として次を掲載しています。 | 商品 | taker | maker | この表の扱い | | --- | ---: | ---: | --- | | 現物 | 0.1% | 0.1% | 公式ガイドの確認時点の例 | | 無期限・先物 | 0.055% | 0.02% | 公式ガイドの確認時点の例 | | option | 0.03% | 0.02% | 公式ガイドの確認時点の例 | これは将来の固定料率ではありません。Bybitの取引手数料体系ページも、地域により実際のrateが異なる場合があり、本人確認後に「マイ手数料率」で確認するよう案内しています。 ### makerとtaker - makerは、原則として注文板へ流動性を追加する約定 - takerは、注文板にある注文とすぐ約定し流動性を取る約定 指値注文を選んでも、すぐ約定する価格ならtakerになる場合があります。Post Onlyはmakerとして板へ残すための条件ですが、即時約定すると判定されると取消・拒否される場合があります。最終的な区分は取引履歴で確認します。 ## 資金調達料 資金調達料は無期限contractのpositionを対象時刻に保有する場合に発生し、取引手数料とは別です。Bybit公式は、正のrateではLongからShortへ、負のrateではShortからLongへ支払うと説明しています。 ```text funding fee = position value × funding rate ``` rate、次回時刻、intervalはcontractごとに確認します。詳しくは[Bybitの資金調達率](/archives/2939)を参照してください。 ## 借入利息と強制決済関連 現物margin、暗号資産loan、統合取引アカウントの借入などでは、借入額と時間に応じた利息が発生する場合があります。無期限・先物のmarginと、資産を借りるloanの利息を混同しないでください。 強制決済に関する扱いも商品ごとに異なります。手数料ガイドの一行だけでなく、利用する商品の清算ルール、margin mode、維持証拠金、account明細を確認します。 ## 総費用を比べる方法 他の取引所と比較するときは、広告の最小rateではなく、同じ条件で見積もります。 | 条件 | そろえるもの | | --- | --- | | 取引 | 同じ商品、約定数量、maker/taker、VIP level | | 入出金 | 同じ資産・chain・金額・送付先 | | デリバティブ | 同じposition value、保有時間、funding interval | | 借入 | 同じ資産、借入額、利率、時間 | | 法定通貨 | 同じ通貨、決済方法、決済事業者、為替rate | 料金だけでなく、日本向け登録状況、地域制限、資産の回収可能性、support、税務記録なども別に確認します。「最安」という一語では判断できません。 ## 注文前後の確認 ### 確定前 - 自分に適用される手数料率 - maker/takerの想定 - quantity、position value、概算fee - 出金なら資産、chain、fee、最終受取見込み - 無期限ならfunding rateと次回時刻 - 借入ならinterest rateと計算間隔 ### 完了後 - 注文履歴と取引履歴の実際のfee - funding historyの支払/受取 - 出金履歴のfeeとTXID - 借入・返済履歴のinterest - account残高と損益明細 ## 最終チェック - 入金、出金、取引、funding、interestを別々に確認した - 古い固定rateを使わず、自分の手数料率を確認した - 指値なら必ずmakerになるとは考えていない - 資産とchainをそろえて出金feeを確認した - position valueとfunding rateを確認した - 確定前の概算と、履歴の実績を両方確認した 条件付き注文の約定状態は[Bybitの逆指値・条件付き注文](/archives/3640)、position modeとmargin riskは[Bybitの両建てとポジションモード](/archives/3596)で確認できます。 ## 確認した一次情報 - [Bybit: 手数料体系](): 確認日 2026-08-28 - [Bybit: 取引手数料体系](): 確認日 2026-08-28 - [Bybit: 資金調達率](): 確認日 2026-08-28 --- # Bybit入金方法｜chain・最低額・Memo/Tag・反映状況の確認 Bybitへ暗号資産をオンチェーン入金するときに、資産、chain、アドレス、Memo/Tag、最小入金額、TXID、反映statusを確認する順序を公式情報に基づいて整理します。 正規URL: https://3mikan.com/archives/2846 著者: みかん 公開: 2021-10-01T13:13:21.000Z 更新: 2026-08-28T13:40:00.000Z Bybitへ暗号資産を入金するときは、入金アドレスだけでなく、**資産、chain、Memo / Tag、最小入金額**を一組で確認します。銘柄名が同じでもchainが違えば、通常の入金として反映されない可能性があります。 この記事は2026年8月28日にBybit公式ヘルプを確認し、オンチェーン入金の確認項目へ絞って更新しました。2021年の購入方法、キャンペーン、紹介リンク、旧画面は現行手順として残していません。 > Bybitの日本向け登録状況、地域制限、本人確認の前提は[Bybitは日本で使える？](/archives/1945)で先に確認してください。公開ページが見えることは、日本の暗号資産交換業者として登録済みであることを意味しません。 ## 入金前にそろえる6項目 | 項目 | Bybit側 | 送信元側 | | --- | --- | --- | | 資産 | 入金画面に表示された銘柄 | 同じ銘柄を選ぶ | | chain | Bybitが対応すると表示したchain | 同じchainで送れることを確認する | | アドレス | Bybitが発行したアドレス | 宛先へ正確に入力する | | Memo / Tag | 表示された場合は値を確認する | 専用欄へ正確に入力する | | 最小入金額 | 資産・chainごとの表示を読む | 手数料差引後も条件を満たすか確認する | | 送信方法 | スマートコントラクト経由の可否などを読む | 利用するwallet・取引所の送信方法を確認する | Bybit公式は、利用できる資産とchain、最小入金額、Memo / Tag、スマートコントラクト経由の入金可否が資産ごとに異なると案内しています。以前使ったアドレスや別銘柄の記録ではなく、今回の入金画面を基準にします。 ## オンチェーン入金の確認順 1. 自分のアカウントで入金機能と対象資産が利用できるか確認する 2. Bybitの入金画面で資産を選ぶ 3. chainを選び、対応状況と注意書きを読む 4. 表示されたアドレスと、必要ならMemo / Tagを確認する 5. 最小入金額と、反映に必要なconfirmationsを確認する 6. 送信元で同じ資産・同じchainを選ぶ 7. 確定前画面で宛先、Memo / Tag、金額、送信元手数料を読み直す 8. 送信後にTXIDを保存し、Bybitの入金履歴を確認する 送信元の画面でchain名の表記がBybitと違う場合は、名前が似ているという理由だけで選ばないでください。公式chain explorerや両サービスの案内で、同じnetworkであることを確認できない場合は操作を止めます。 ## Memo / Tagが表示された場合 一つの入金アドレスを複数利用者で共有するサービスでは、MemoやTagで受取人を区別する場合があります。Bybitの入金画面にMemo / Tagが表示された場合は、アドレスと同じ重要度で扱います。 - Memo / Tagの入力欄が見つからない場合は送信しない - 任意と推測せず、Bybitと送信元の説明を確認する - 数字、英字、記号を変えない - アドレス欄へMemo / Tagを混ぜない - QR codeを使った場合も、確定前に文字列を読む 入力を誤った送金は、自動では反映されず、回収できない、または追加の手続きや費用が必要になる場合があります。 ## 入金が反映されないとき まず「送信済み」と「Bybitへ反映済み」を分けます。 | 状態 | 確認先 | 次に見るもの | | --- | --- | --- | | TXIDがない | 送信元の出金履歴 | 受付・審査・送信前のどこか | | TXIDはあるが未確定 | chain explorer | block inclusion、confirmations、network congestion | | chainでは確定 | Bybitの入金条件 | 資産、chain、アドレス、Memo / Tag、最小額 | | Bybitで処理中 | 入金履歴 | status、必要confirmations、maintenance | | 条件を満たすが反映しない | Bybit support | TXID、資産、chain、金額、日時。秘密情報は送らない | 同じ入金をすぐ再送すると、原因が解消していないまま資金移動を重ねることになります。[取引所への入金が反映されないときの確認手順](/archives/6008)で、TXID、chain status、confirmations、取引所statusを順に確認してください。 ## 手数料の見方 Bybit公式の手数料ガイドでは、暗号資産のオンチェーン入金についてBybit側の入金手数料は無料と案内しています。ただし、次の費用まで無料という意味ではありません。 - 送信元walletが支払うnetwork fee - 送信元取引所の出金手数料 - 暗号資産を購入する際の決済事業者の手数料 - 誤送金の回収など例外対応の費用 「入金無料」という表示だけで総費用を判断せず、送信元の確定前画面も確認します。Bybit内の費用分類は[Bybitの手数料一覧](/archives/2344)に分けています。 ## 入金前の最終チェック - 日本向け条件と自分のアカウントの利用可否を確認した - 資産名とcontractの種類を確認した - Bybitと送信元で同じchainを選んだ - アドレスを先頭・末尾を含めて照合した - Memo / Tagが必要か確認した - 手数料差引後の金額が最小入金額を満たすか確認した - TXIDとBybitの入金履歴を確認する場所を把握した - 認証コード、秘密鍵、シードフレーズを誰にも共有していない 画面の表示がこの記事と違う場合は、現在のBybit入金画面と公式ヘルプを優先してください。 ## 確認した一次情報 - [Bybit: サービス制限国](): 確認日 2026-08-28 - [Bybit: オンチェーン入金](): 確認日 2026-08-28 - [Bybit: 入出金履歴とstatus](): 確認日 2026-08-28 - [Bybit: 手数料体系](): 確認日 2026-08-28 --- # Bybitキャンペーン・特典の確認方法｜旧ボーナス記事の扱い 2021〜2022年に掲載したBybitのキャンペーンと招待特典を終了済みの記録として整理し、現行特典の対象地域、期間、条件、受取期限、有効期限を公式規約で確認する方法を案内します。 正規URL: https://3mikan.com/archives/2937 著者: みかん 公開: 2021-10-15T08:39:04.000Z 更新: 2026-08-28T13:40:00.000Z このURLに以前掲載していた「2022年開催中」のキャンペーン、入金ボーナス、招待コード、手数料割引は、**現在有効な特典として扱いません**。個別の終了日を確認できないものも含め、当時の掲載内容と紹介リンクを現行案内から削除しました。 この記事は2026年8月28日にBybit公式の特典センターFAQとプロモーション案内を確認し、現行特典を自分で確認する方法へ更新しています。特定キャンペーンへの参加や取引を勧めるものではありません。 > キャンペーンの確認より先に、日本向け登録状況、地域制限、本人確認の前提を[Bybitは日本で使える？](/archives/1945)で確認してください。特典ページが表示されることだけで、対象地域・対象者だとは判断できません。 ## 旧掲載内容の扱い 2021〜2022年の旧記事では、次のような企画を「開催中」として掲載していました。 - 入金や取引を条件とするbonus - 紹介・招待program - 手数料割引 - 上場記念や期間限定event - staking関連企画 これらの名称、期間、対象者、達成条件、特典額を現行情報として再掲しません。古いscreenshotや検索結果、SNS投稿、紹介URLも、現在の適用条件を示す根拠にはなりません。 ## 現行特典で確認する8項目 Bybit公式の特典センターFAQは、taskや特典が定期的に更新され、特典ごとに用途と有効期限があると説明しています。参加前に次を個別規約で確認します。 | 項目 | 確認する内容 | 見落としやすい点 | | --- | --- | --- | | 主催・URL | Bybit公式domain内か | 広告、偽site、短縮URL | | 期間 | 開始、終了、timezone | 日本時間への換算、早期終了 | | 対象地域 | 居住地が対象か | page表示と参加資格の混同 | | 対象者 | 新規/既存、招待、本人確認level | 登録日や過去利用の条件 | | task | 入金、取引量、保有、申請など | net deposit、対象商品、最低額 | | 受取方法 | 自動付与かclaimが必要か | claim期限と配布時期 | | 有効期限 | 付与後いつまで使えるか | 未使用の失効、延長不可 | | 利用制限 | margin、fee相殺、出金可否など | bonus本体と利益の扱いの違い | 「最大○○」は全員が同額を受け取れる意味ではありません。抽選、先着、上限、段階制、対象商品、本人確認、純入金額などの条件を確認します。 ## 確認の順序 1. 金融庁資料とBybitの地域制限を確認する 2. 特典ページがBybit公式domainか確認する 3. eventの個別利用規約を開く 4. 期間とtimezoneを確認する 5. 対象地域、対象account、本人確認levelを確認する 6. taskの定義、対象商品、最低額、除外取引を確認する 7. claim方法、配布日、受取期限を確認する 8. 特典の有効期限と利用制限を確認する 9. 自分の特典センターでstatusを確認する 規約へのlinkがない、条件が画像にしかない、終了日時を確認できない、別domainへ認証情報を入力するよう求められる場合は参加しません。 ## bonus・coupon・fee discountを混同しない 特典センターFAQでは、bonus、coupon、fee discount、airdrop、APY boosterなど複数の特典が案内されています。名称が違えば、使える商品や失効条件も同じとは限りません。 | 種類 | 確認すること | | --- | --- | | bonus | marginや損失・fee相殺に使えるか、引出可否、失効 | | coupon | 対象商品、使用条件、上限、期限 | | fee discount | 対象fee、割引率、期間、上限 | | airdrop | 配布資産、claim、対象account、税務記録 | | APY booster | 対象product、元本条件、期間、rate上限 | 特典を使うために取引を増やせば、取引手数料、slippage、funding、価格変動riskが増える場合があります。特典額だけで損益を判断しません。 ## 紹介link・招待codeの注意 このサイトは現在、Bybitの紹介linkや招待codeを掲載していません。第三者の紹介linkを使う場合も、次を確認してください。 - link先がBybit公式domainである - 紹介者が説明する特典と、公式の個別規約が一致する - 対象地域・対象者・期間を満たす - 紹介者に報酬が発生する関係を理解する - 「必ず受け取れる」「損失を補填できる」といった断定を信用しない - 認証code、本人確認書類、秘密鍵、seed phraseを紹介者へ渡さない 招待codeを入力したことだけで特典が確定するとは限りません。最終statusは自分のaccountと公式規約で確認します。 ## 特典が反映されないとき | 症状 | 確認先 | 主な確認項目 | | --- | --- | --- | | taskが表示されない | 特典センター | 地域、対象者、期間、本人確認 | | 達成にならない | event規約・status | net deposit、対象商品、集計時間 | | claimできない | claim画面 | 受取期間、上限、account状態 | | 配布されない | 特典履歴 | 配布日、審査、除外条件 | | 使えない | 特典詳細 | 対象商品、minimum、失効日 | | 出金できない | 利用規約 | bonus本体と利益の扱い | supportへ問い合わせる場合は、event名、公式URL、参加日時、task status、該当規約を記録します。password、認証code、秘密鍵、seed phraseは送らないでください。 ## 最終チェック - 2021〜2022年の旧企画を現在有効と扱っていない - 日本向け条件と対象地域を別々に確認した - 公式domainと個別規約を確認した - 期間、timezone、対象者、taskを確認した - claim期限、配布日、有効期限を確認した - 特典の用途、出金可否、上限を確認した - 特典を得るための取引費用とriskを別に確認した - 第三者へ認証情報を渡していない 取引・入出金を含む費用の分類は[Bybitの手数料一覧](/archives/2344)で確認できます。 ## 確認した一次情報 - [Bybit: 特典センターFAQ](): 確認日 2026-08-28 - [Bybit: プロモーション公式ヘルプ](): 確認日 2026-08-28 - [Bybit: サービス制限国](): 確認日 2026-08-28 --- # Bybit資金調達率とは？確認場所・計算・支払と受取を整理 Bybitの無期限契約で使われる資金調達率について、position valueとの関係、正負で変わる支払方向、次回時刻、変動する決済間隔、履歴の確認順を整理します。 正規URL: https://3mikan.com/archives/2939 著者: みかん 公開: 2021-10-22T21:47:08.000Z 更新: 2026-08-28T13:40:00.000Z 資金調達率（funding rate）は、無期限contractの価格を現物の参照価格へ近づけるために使われるrateです。対象時刻にpositionを保有していると、rateとposition valueに応じた資金調達料を支払う、または受け取る場合があります。 この記事は2026年8月28日のBybit公式情報に基づいて更新しました。「毎日必ず3回」「固定の時刻・rate」「受取で利益を得られる」といった旧記事の表現は、全contract共通の現行仕様として残していません。 > Bybitの日本向け条件とデリバティブ取引の前提は[Bybitは日本で使える？](/archives/1945)で確認してください。この記事は無期限contractの利用やposition保有を勧めるものではありません。 ## 資金調達料は取引手数料と別 | 費用 | 主な発生条件 | 確認する値 | | --- | --- | --- | | 取引手数料 | 注文が約定する | maker/taker、約定数量、手数料率 | | 資金調達料 | 対象時刻に無期限positionを保有する | funding rate、position value、方向 | | 借入利息 | marginやloanで借入を使う | 借入額、利率、経過時間 | | 強制決済関連 | 商品ルール上の清算条件に達する | margin mode、維持証拠金、商品別ルール | positionをopen・closeする取引手数料と、保有中の資金調達料は別々に損益へ影響します。 ## 基本的な計算の読み方 Bybit公式は、計算された資金調達率をposition valueへ適用し、対象時刻の支払または受取額を決めると説明しています。概念上は次のように確認します。 ```text funding fee = position value × funding rate ``` 実際のposition valueの定義、contractの単位、丸め、上限・下限は商品ルールで確認します。証拠金として差し入れた額だけにrateを掛けるとは限りません。 ### 正のrate Bybitの手数料ガイドでは、rateが正の場合、Long側がShort側へ資金調達料を支払うと説明しています。 ### 負のrate rateが負の場合、Short側がLong側へ支払うと説明しています。 受取側であっても、取引手数料、slippage、価格変動、清算riskが消えるわけではありません。fundingだけを見た取引結果は保証されません。 ## 確認する5つの値 | 値 | 意味 | 注意点 | | --- | --- | --- | | funding rate | 次回交換に向けて変動するrate | 現在表示は最終確定値とは限らない | | next funding time | 次の対象時刻 | contractごと、状況により間隔が異なる場合がある | | position value | rateを適用する基準額 | margin amountと同じとは限らない | | position direction | LongまたはShort | rateの正負で支払/受取方向が変わる | | funding history | 実際に計上された額 | 予測表示ではなく結果を確認する | Bybit公式は、資金調達率を次回時刻までリアルタイムで更新すると案内しています。画面を開いた時点のrateを、将来の確定rateとして固定しないでください。 ## 「8時間ごと」を固定仕様にしない Bybit公式の資金調達率ガイドは8時間間隔を例に計算を説明していますが、同じページで、上限・下限に達した場合に決済頻度を1時間ごとへ動的に切り替える場合があると案内しています。プレマーケットなど別条件の商品もあります。 したがって、確認するのは記事に書かれた時刻ではなく、対象contractの画面にある次の情報です。 1. contract名 2. 現在表示のfunding rate 3. 次回fundingまでの時間 4. funding interval 5. 上限・下限や特別ルールの告知 日本時間へ換算する場合も、画面のtimezoneと夏時間の有無を確認します。 ## 資金調達率はどう決まるか Bybit公式は、資金調達率を利率と平均premium indexから計算し、上限・下限を適用すると説明しています。premium indexは無期限contractと参照価格の乖離、注文板のimpact priceなどから構成されます。 一般の確認では、複雑な式を暗記するより次を分ける方が安全です。 - rateは市場状況により変動する - 次回時刻に近づくまで表示値が変わり得る - contractごとにintervalや上限が異なる場合がある - position valueにrateが適用される - 実際の支払/受取は履歴で確定する ## position保有前後の確認順 ### 保有前 1. 対象contractとposition方向を確認する 2. funding rateと次回時刻を確認する 3. intervalと商品固有ルールを確認する 4. position valueと概算額を確認する 5. 取引手数料、slippage、margin、清算価格も確認する ### 対象時刻の後 1. funding historyを開く 2. contract、方向、position sizeを確認する 3. 計上された支払/受取額を確認する 4. account残高と損益表示を確認する 5. 取引手数料と混同していないか確認する ## よくある見落とし - rateが正なら自分が必ず受け取ると思う - margin amountだけで概算する - 記事の固定時刻を全contractへ当てはめる - 次回rateを確定値として扱う - 両建てならfundingが完全に相殺されると思う - fundingを得るためのopen/close手数料とslippageを無視する - funding historyを確認せず、表示損益だけで判断する ヘッジモードでLongとShortを同時保有しても、position size、contract、margin mode、rate、手数料により結果は変わります。詳しくは[Bybitの両建てとポジションモード](/archives/3596)を確認してください。 ## 最終チェック - 無期限contractのfundingであることを確認した - rate、次回時刻、interval、position valueを確認した - rateの正負と自分のposition方向を確認した - 取引手数料、slippage、margin、清算riskを別に確認した - 表示rateを最終確定値と決めつけていない - 対象時刻後にfunding historyで結果を確認した 入出金や取引を含む費用全体は[Bybitの手数料一覧](/archives/2344)で分類しています。 ## 確認した一次情報 - [Bybit: 資金調達率](): 確認日 2026-08-28 - [Bybit: 手数料体系](): 確認日 2026-08-28 - [Bybit: 実際と過去の資金調達率](): 確認日 2026-08-28 --- # Bybitの両建てとは？ワンウェイ・ヘッジモードと証拠金リスク Bybitのワンウェイモードとヘッジモード、open/close、Reduce-Only、分離・クロス・ポートフォリオマージンを分け、両建てで残る手数料・清算リスクを整理します。 正規URL: https://3mikan.com/archives/3596 著者: みかん 公開: 2021-10-28T18:32:30.000Z 更新: 2026-08-28T13:40:00.000Z Bybitで同じcontractのLongとShortを同時に持つには、対応する商品で**ヘッジモード**を使います。ただし、両方向のpositionを持っても価格変動リスクが消えるわけではなく、取引手数料、資金調達料、証拠金、清算のリスクは残ります。 この記事は2026年8月28日のBybit公式ヘルプをもとに、position modeとmargin modeの違いへ絞って更新しました。「両建てで利益を確保できる」「損失を抑えられる」といった保証、旧contractの固定仕様、紹介リンクは引き継いでいません。 > 日本向け登録状況、地域制限、本人確認の前提は[Bybitは日本で使える？](/archives/1945)で確認してください。この記事はデリバティブ取引やレバレッジ設定を勧めるものではありません。 ## ワンウェイとヘッジの違い Bybit公式は、ワンウェイをdefaultのposition modeとし、ヘッジモードでは同一contractのLongとShortを独立して持てると説明しています。 | 項目 | ワンウェイモード | ヘッジモード | | --- | --- | --- | | 同一contractのposition | LongかShortの一方向 | LongとShortを別々に保有できる | | 反対方向の注文 | 既存positionを減らし、数量超過時は反転する場合がある | openなら反対方向のpositionを新しく持てる | | 注文時の指定 | 売買方向、Reduce-Onlyなど | Long/Shortとopen/closeを組み合わせる | | 管理 | netの一position | LongとShortを個別に管理 | | 証拠金 | positionと注文に応じて計算 | 両側とmargin modeに応じて計算 | ヘッジモードでShortをopenしても、既存Longが自動的にcloseされるとは限りません。Longを閉じる場合は、Long側のcloseを選び、対象数量を確認します。 ## open・close・Reduce-Only ### open positionを新しく持つ、または増やす指定です。ヘッジモードではLong openとShort openを別々に扱います。 ### close 既存positionを減らす、または閉じる指定です。どちらの方向をcloseするか、数量がposition size以内かを確認します。 ### Reduce-Only Bybit公式は、Reduce-Onlyを既存positionの縮小・決済だけに使い、positionの増加や反転を防ぐ機能として説明しています。ワンウェイモードで既存positionより大きな反対注文を出すとき、Reduce-Onlyの有無で結果が変わります。 | 確認項目 | 誤ると起こりうること | | --- | --- | | open / close | 閉じるつもりで反対positionを増やす | | Long / Short | 対象方向と反対の注文を作る | | quantity | positionを全量closeできない、または超過する | | Reduce-Only | net positionが反転する | | current orders | 未約定注文が後からpositionを変える | ## position modeを切り替える前 Bybit公式は、対象contractに保有positionまたは未約定注文がある場合、position modeを切り替えられないと説明しています。 1. 対象contractを確認する 2. LongとShortのpositionを確認する 3. 未約定注文、条件付き注文、TP/SLを確認する 4. 必要な注文を取消し、必要なpositionをcloseする 5. 取引履歴とpositionが反映されたことを確認する 6. 対応商品と適用範囲を確認してmodeを切り替える 「すべてのpairへ適用」のような表示がある場合は、意図しないcontractまで変更しないか確認します。 ## position modeとmargin modeは別 position modeはLongとShortの持ち方、margin modeは損益・証拠金をどの範囲で評価するかです。 | margin mode | 主な評価単位 | 確認するリスク | | --- | --- | --- | | 分離マージン | 原則として各positionへ割り当てた証拠金 | positionごとの必要・維持証拠金、追加証拠金、清算 | | クロスマージン | account内の対象資産・positionを共有 | 一つのpositionの損失が広いaccount equityへ影響する可能性 | | ポートフォリオマージン | 複数資産・positionの総合risk | model、適格性、scenario変化、複雑な清算条件 | Bybitの統合取引アカウント（UTA）は、分離、クロス、ポートフォリオの三つを説明しています。対応商品、切替条件、証拠金計算はaccount状態で変わり得ます。名前だけで「安全なmode」を決められません。 ### ヘッジでも証拠金はゼロにならない 分離マージンではLongとShortを独立して維持し、それぞれの証拠金を計算します。クロスマージンではaccount levelで両方向のrisk exposureを考慮する場合があります。同じ数量のLongとShortでも、必要証拠金が単純に相殺されるとは限りません。 ## 両建てで残る費用とリスク - LongとShortの両方を建てる・閉じる取引手数料 - 各positionの約定時に生じるslippage - 無期限contractの資金調達料 - margin modeに応じた必要証拠金と維持証拠金 - 一方または両方の清算risk - mode、contract、数量、open/closeの操作ミス - 未約定注文が後で成立するrisk 両方向を同時に持つと値動きの一部が相殺される場面はありますが、費用を含めた損益が固定されるとは限りません。片側だけをcloseすると、その時点から残った方向の価格変動riskを受けます。 資金調達率はcontractごとに変動し、決済間隔も動的に調整される場合があります。[Bybitの資金調達率](/archives/2939)で、rate、position value、支払/受取を分けて確認してください。 ## 注文前と注文後の確認 ### 注文前 1. 対象contractとposition mode 2. margin modeとaccount equity 3. Long/Short、open/close、Reduce-Only 4. order type、price、quantity 5. 必要証拠金、維持証拠金、推定清算価格 6. 手数料、資金調達率、次回時刻 7. 既存の未約定注文とTP/SL ### 注文後 1. 未約定注文の方向、残量、status 2. positionの方向、size、entry price 3. margin、維持証拠金、清算価格 4. 注文履歴と取引履歴 5. 資金調達料と取引手数料 ## 最終チェック - position modeとmargin modeを区別した - Long/Shortとopen/closeを一組で確認した - Reduce-Onlyの有無を確認した - 切替前にpositionと未約定注文を確認した - 両建てでも手数料、資金調達料、清算riskが残ると理解した - 片側close後に残るpositionを確認した - 利益や損失限定を保証する手法として扱っていない 条件付き注文とTP/SLは[Bybitの逆指値・条件付き注文](/archives/3640)、費用全体は[Bybitの手数料一覧](/archives/2344)で確認できます。 ## 確認した一次情報 - [Bybit: ワンウェイモードとヘッジモード](): 確認日 2026-08-28 - [Bybit: 統合取引アカウントのマージンモード](): 確認日 2026-08-28 - [Bybit: 統合取引アカウントの強制決済ルール](): 確認日 2026-08-28 - [Bybit: 資金調達率](): 確認日 2026-08-28 --- # Bybit逆指値・条件付き注文｜triggerと指値・成行、未約定の確認 Bybitの逆指値に相当する条件付き注文、TP/SL、OCOについて、triggerと実際の注文、指値・成行、参照価格、未約定・取消を分けて確認します。 正規URL: https://3mikan.com/archives/3640 著者: みかん 公開: 2021-11-01T12:26:12.000Z 更新: 2026-08-28T13:40:00.000Z Bybitで「逆指値」を探すと、画面や商品によって**条件付き注文、利食/損切（TP/SL）、stop entry**などの名称が使われます。大切なのは名称より、triggerした後に成行注文と指値注文のどちらが出るかです。 この記事は2026年8月28日にBybit公式ヘルプと公開の現物画面を確認し、条件付き注文の読み方へ絞って更新しました。2021年の旧画面、利益や損失回避を保証する表現、紹介リンクは削除しています。 > Bybitの日本向け条件と公開画面の確認範囲は[Bybitは日本で使える？](/archives/1945)を先に確認してください。この記事は注文の実行や設定値を勧めるものではありません。 ## triggerと約定は別の出来事 条件付き注文は、二段階で考えます。 1. 選んだ参照価格がtriggerへ到達する 2. trigger後に成行注文または指値注文が発注される triggerへ到達しても、指値注文に相手注文がなければ未約定のままになる可能性があります。成行注文でも、流動性や価格制限により一部約定または未約定部分の取消が起こる場合があります。 | 設定 | 決めるもの | 結果として確認するもの | | --- | --- | --- | | trigger price | いつ注文を発注するか | trigger済みか、未到達か | | reference price | 何の価格で判定するか | LTP、mark、indexなど選択した基準 | | order type | trigger後に成行か指値か | 注文板へ出た注文の種類 | | order price | 条件付き指値の希望価格 | 未約定、一部約定、約定 | | quantity | 対象数量 | 利用可能残高、position、約定数量 | | time in force | 注文をどの条件で残すか | GTC、IOC、FOKなどの結果 | ## 条件付き成行と条件付き指値 ### 条件付き成行 trigger後、利用可能な価格で約定を試みます。注文価格は先に固定できません。注文板が薄い、市場が急変する、価格制限にかかると、想定価格から離れる、一部だけ約定する、残量が取り消される可能性があります。 ### 条件付き指値 trigger後、指定した価格の指値注文を出します。価格を指定できますが、triggerしただけでは約定しません。市場が指値へ届かない、または相手注文が不足すると未約定になります。 | 重視すること | 成行 | 指値 | | --- | --- | --- | | trigger後の約定優先 | 高い | 相手注文と価格条件による | | 約定価格の固定 | できない | 指値を設定する | | 主な未完了 | 一部約定、価格制限、残量取消 | 未約定、一部約定 | | 確認先 | 取引履歴、注文履歴 | 現在の注文、注文履歴、取引履歴 | ## 現物のTP/SL・OCO・条件付き注文 Bybit公式の現物TP/SLガイドは、資産の拘束タイミングが注文種別で異なると説明しています。 - TP/SL注文は、発注時点から対象資産が拘束される - OCOは二つの条件を連携させ、一方の成立により他方を取り消す - 条件付き注文は、trigger後に必要資産が拘束される 画面の利用可能残高が想定より少ない場合は、他の指値注文やTP/SLが資産を拘束していないか確認します。OCOも、一方の注文がtriggerまたは約定したら必ず希望価格で全量成立する、という保証ではありません。 ## 先物のTP/SLで追加する確認 先物では、注文だけでなくpositionとの関係を確認します。 1. 対象contractとposition方向 2. ワンウェイかヘッジか 3. openかcloseか、Reduce-Onlyか 4. triggerの参照価格 5. position全体か一部数量か 6. trigger後の成行または指値 7. margin mode、清算価格、未約定注文 ショートを新規openすることと、ロングをcloseすることは同じではありません。ポジションモードの違いは[Bybitの両建てとポジションモード](/archives/3596)で確認してください。 ## 注文前の確認順 1. 現物か先物か、対象pair・contractを確認する 2. 買い/売り、またはopen/closeとLong/Shortを確認する 3. triggerの参照価格を確認する 4. trigger priceを確認する 5. trigger後の成行/指値を確認する 6. 指値ならorder priceを確認する 7. quantity、単位、利用可能残高を確認する 8. 確定前に手数料、価格制限、time in forceを確認する 9. 発注後に現在の注文と注文履歴を確認する 10. 約定した場合は取引履歴と残高またはpositionを確認する ## 動かない・約定しないとき | 症状 | 最初の確認 | 次の確認 | | --- | --- | --- | | triggerしない | reference price、trigger price | 市場が条件へ到達したか | | triggerしたが未約定 | 注文履歴、現在の注文 | 指値と市場価格、流動性 | | 一部だけ約定 | 取引履歴、残量 | 残量のstatus、価格制限 | | 注文が取り消された | 注文履歴 | IOC/FOK、Post Only、価格制限、残高 | | 残高不足 | 利用可能残高 | 他の注文による拘束、手数料 | | positionが増えた | open/close、Reduce-Only | position modeと方向 | | 結果が分からない | 現在の注文、注文履歴 | 取引履歴、残高、position | 通信後に画面が止まっても、同じ注文をすぐ再送しないでください。最初の注文が受け付けられ、表示だけ遅れている可能性があります。 ## 最終チェック - triggerと約定を分けて考えた - 参照価格とtrigger priceを確認した - trigger後が成行か指値か確認した - 指値の場合、未約定になる可能性を確認した - quantity、単位、残高、拘束中の注文を確認した - 注文後の現在の注文、注文履歴、取引履歴を確認した - TP/SLが損失を必ず限定する保証ではないと理解した 注文量と約定価格のずれは[Price impactとslippageの違い](/archives/741)、手数料の分類は[Bybitの手数料一覧](/archives/2344)で確認できます。 ## 確認した一次情報 - [Bybit: 注文種別](): 確認日 2026-08-28 - [Bybit: 現物の利食・損切](): 確認日 2026-08-28 - [Bybit: 注文約定と強制決済FAQ](): 確認日 2026-08-28 - [Bybit: 現物取引ルール](): 確認日 2026-08-28 --- # MEXC注文方法｜現物・先物の注文種別と約定・取消の確認手順 MEXC Webの現行画面で、現物と先物の指値・成行・条件付き注文を分け、発注前、未約定、約定、取消、資金調達率の確認順を解説。日本居住者向けの注意点も公式情報と金融庁資料で確認します。 正規URL: https://3mikan.com/archives/4911 著者: みかん 公開: 2022-03-21T13:55:48.000Z 更新: 2026-08-28T11:00:00.000Z MEXCの注文画面では、現物と先物で同じ「指値」「成行」という名前が使われます。しかし、入力項目も、注文後に確認する場所も、損失が生じる仕組みも同じではありません。 この記事では、2026年8月28日に日本から確認したMEXC Webの公開画面と公式ヘルプをもとに、**注文前の確認から、未約定・一部約定・約定・取消まで**を整理します。確認時は日本語、ログアウト状態です。登録、ログイン、入出金、注文、ポジション操作は行っていません。 > **日本居住者向けの重要事項** > > 金融庁は2024年11月28日、MEXC Globalについて、日本居住者を相手方として暗号資産交換業を行っていたとして警告しました。この記事は画面の読み方を記録するもので、MEXCでの口座開設や取引を勧めるものではありません。利用を判断する前に、金融庁の登録一覧、警告、MEXCの最新規約と地域制限を自分で確認してください。 ## 日本から画面を確認するときの前提 MEXCの公式地域制限記事は、サービス禁止国の一覧に日本を明記していません。一方で、同じ記事は**日本ではiOS・Androidアプリをダウンロードできない**と案内しています。利用規約の地域制限は変更される場合があり、公開Webページが表示できることだけで、口座機能や各商品を利用できるとは判断できません。 2026年8月28日時点の確認範囲は次の通りです。 | 項目 | 確認できたこと | ここから判断できないこと | | --- | --- | --- | | Web | 日本語の現物・先物公開画面をログアウト状態で表示 | 日本居住者の登録、本人確認、入出金、注文が許可されるか | | アプリ | MEXC公式記事は日本でiOS・Androidアプリをダウンロードできないと案内 | 既に入手したアプリの機能、今後の配布状況 | | 法規制 | 金融庁がMEXC Globalへ警告 | 個別の利用行為に対する法的判断 | | 画面の数値 | 公開価格、資金調達率、次回までの時間を観測 | 将来の価格、固定手数料、固定の資金調達時刻 | 地域、本人確認の状態、銘柄、商品によって制限が異なる場合があります。画面やヘルプが食い違う場合は、操作を進めず、日付を付けて最新の公式情報を確認してください。 ## 現物と先物を先に分ける **現物**は、取引ペアの一方を売ってもう一方を買う取引です。**先物**は、証拠金を使って価格変動に対するポジションを持つ契約で、現物にはない清算、資金調達料、margin mode、position modeがあります。 | 確認項目 | 現物 | 先物 | | --- | --- | --- | | 主な対象 | 売買する暗号資産 | 先物契約のポジション | | 基本入力 | 売買方向、価格、数量または合計 | オープン/クローズ、Long/Short、価格、数量 | | 追加設定 | 条件付き注文のtriggerなど | margin mode、position mode、レバレッジ、TP/SL | | 注文後 | 現在の注文、注文履歴、取引履歴、残高 | 未決済注文、ポジション、注文履歴、清算価格、資金調達料 | | 主なリスク | 価格変動、slippage、流動性、銘柄固有リスク | 左記に加え、レバレッジ、清算、証拠金共有、資金調達料 | 先物のHedge modeは、LongとShortを同時に持てる設定です。「両建てにすれば損失を防げる」という意味ではありません。両側の注文に手数料や資金調達料が発生し、証拠金や清算のリスクも残ります。 ## 注文前に共通で確認する7項目 注文種別を選ぶ前に、次の順番で画面を読みます。 1. **サービス条件**: 地域、本人確認、アカウント、商品ごとの制限を最新の公式情報で確認する 2. **取引ペア・契約**: `BTC/USDT`の現物か、`BTCUSDT`の先物契約かを確認する 3. **売買・ポジション方向**: 現物の買い/売りか、先物のオープン/クローズとLong/Shortかを分ける 4. **注文種別**: 指値、成行、条件付き注文のどれかを確認する 5. **入力値**: 価格、数量、合計、trigger、margin modeなど、表示中の全項目を読む 6. **最終表示**: 手数料、最低数量、利用可能残高、想定清算価格など、確定前に表示される値を確認する 7. **結果の確認先**: 現在の注文、注文履歴、取引履歴、先物のポジションを開いておく 価格や数量をコピーするときは、小数点と単位も確認します。`BTC`の数量欄へ`USDT`の合計額を入れるような単位の取り違えは、注文種別を正しく選んでも防げません。 ## 現物の注文種別 2026年8月28日の現物Web画面と公式FAQでは、指値、成行、利確/損切り、OCO、トレーリング逆指値を確認できました。 | 注文種別 | 目的 | 主な入力 | 注文後に起こりうること | | --- | --- | --- | --- | | 指値 | 指定価格以下で買う、または指定価格以上で売る | 価格、数量または合計 | 未約定、一部約定、全量約定、残量の取消 | | 成行 | 現在の注文板にある価格で優先的に約定を試みる | 数量または合計 | 複数価格での約定、slippage、一部約定、未約定部分の取消 | | 利確/損切り | trigger到達後に注文を出す | trigger、注文価格、数量など | 未trigger、trigger後の未約定・約定 | | OCO | 利確側と損切り側の2条件を組み合わせる | 指値価格、trigger、数量など | 一方の成立時にもう一方を取り消す。約定自体は保証されない | | トレーリング逆指値 | 市場価格の動きに追随する条件を使う | 追随幅または率、数量など | 条件未到達、trigger後の未約定・約定 |
MEXC現物画面で利確損切り、OCO、トレーリング逆指値が並ぶ注文種別メニュー
2026年8月28日のMEXC Web現物画面。日本語・ログアウト状態。注文種別の名称は画面更新により変わる場合があります。
### 指値注文：価格を先に決める **目的**は、希望価格を決めて注文板へ注文を置くことです。 入力するのは、買い/売り、指値価格、数量または合計です。最終確認では、ペア、方向、単位、価格、数量を読み直します。現在価格から大きく離れた指値は、注文を出せても約定しない可能性があります。 注文後は「現在の注文」を確認します。注文の一部だけが約定した場合、残量は未約定のまま残ることがあります。取消を行っても、すでに約定した部分まで元に戻るとは限りません。最終結果は「注文履歴」と「取引履歴」の両方で確認します。 ### 成行注文：価格を固定せず約定を試みる **目的**は、注文板にある価格を使って、約定を優先することです。指値注文と違い、約定価格を先に固定できません。 入力は画面が求める数量または合計です。確定前に注文板の厚さ、概算の受取量、単位を確認します。流動性が浅い場合は、見えている直近価格から離れた複数の価格で約定し、slippageが大きくなることがあります。 MEXCの公式説明では、流動性が不足すると成行注文でも一部だけ約定し、残りが取り消される場合があります。「成行なら必ず表示価格で全量約定する」とは限りません。slippageと注文量の関係は[Price impactとslippageの違い](/archives/741)で分けて解説しています。 ### 条件付き注文：triggerと実際の注文を分ける 利確/損切り、OCO、トレーリング逆指値は、**条件が成立する時点**と**注文が約定する時点**を分けて確認します。 1. どの価格または変化幅でtriggerするか 2. trigger後に成行または指値のどちらとして扱われるか 3. 指値なら、実際に約定可能な価格か 4. 数量、残高、最低注文量を満たしているか 5. 一部約定や取消後に、もう一方の条件がどうなるか triggerへ到達しても、指値価格に相手注文がなければ未約定になる可能性があります。OCOも「損失を必ず止める」仕組みではなく、二つの条件を連携させる注文です。 ## 注文は「送信」で終わりではない 注文後は、画面に成功表示が出たかだけで判断せず、状態を次の順に確認します。 ![注文入力から現在の注文、約定または取消、履歴確認へ進む流れ](/diagrams/mexc/4911-order-lifecycle.svg) 1. **現在の注文**: 未約定数量、一部約定、残量、取消可能な数量を見る 2. **注文履歴**: 注文が受付、約定、取消、拒否のどの状態になったかを見る 3. **取引履歴**: 実際に約定した価格、数量、回数、手数料を見る 4. **残高またはポジション**: 最終的な資産またはpositionの変化を確認する 通信が止まったように見える場合も、同じ注文をすぐ再送しないでください。画面表示だけが遅れ、最初の注文が受け付けられている可能性があります。現在の注文と履歴を確認してから、次の操作を判断します。 ## 先物注文で追加される設定 先物では、注文価格と数量の前に、positionの持ち方と証拠金の範囲を確認します。 ### オープンとクローズ **オープン**はpositionを新しく持つ、または増やす操作です。**クローズ**は既存positionを減らす、または閉じる操作です。 反対方向のオープン注文を出すことと、既存positionをクローズすることは同じではありません。特にHedge modeではLongとShortが別々に残る可能性があるため、オープン/クローズ、方向、数量を一組で確認します。 ### IsolatedとCross - **Isolated margin**: 原則として、そのpositionへ割り当てた証拠金を基準に管理する - **Cross margin**: 対象範囲の利用可能証拠金をposition間で共有する Crossは清算を必ず防ぐ設定ではありません。複数positionの損益が証拠金へ影響し、損失範囲が広がる場合があります。画面上の日本語では「分離マージン」など別の訳が使われることがあります。 ### One-way modeとHedge mode - **One-way mode**: 同じ契約のpositionを一つのネット方向として扱う - **Hedge mode**: 同じ契約でLongとShortを別々に持てる MEXC公式ヘルプでは、未決済注文やpositionがある状態ではposition modeを変更できず、変更は先物ペア全体へ適用されると説明しています。注文を作る前にmodeを確認してください。
MEXC先物の指値注文パネルに分離マージン、レバレッジ、オープンとクローズが表示された画面
2026年8月28日のMEXC Web先物画面。表示中のレバレッジや価格は撮影時の観測値であり、推奨値ではありません。
レバレッジを上げると、同じ証拠金に対するposition valueと損益の変化が大きくなり、清算価格までの距離も変わります。倍率だけで決めず、position size、必要証拠金、推定清算価格、手数料を最終画面で確認します。 ## 先物の注文種別 現行の先物Web画面と公式用語ガイドでは、指値、成行、追跡指値、トリガー、トレーリング逆指値、Post Onlyを確認できました。 | 注文種別 | 確認する条件 | 主な未完了・失敗 | | --- | --- | --- | | 指値 | 価格、数量、オープン/クローズ、方向 | 市場が価格へ届かず未約定、一部約定 | | 成行 | 数量、方向、概算、注文板 | slippage、流動性不足、一部約定 | | 追跡指値 | 追跡ルール、価格、数量 | 追跡条件、変更された指値が約定しない | | トリガー | trigger、trigger後の注文価格と数量 | 条件未到達、trigger後の指値が未約定 | | トレーリング逆指値 | activation条件、追随幅または率 | 未activation、変動幅が条件へ届かない | | Post Only | maker注文として板へ残る価格か | すぐ約定する価格なら取消または拒否 | 画面の注文名だけで動作を推測せず、入力欄の説明と確定前表示を読んでください。先物のTP/SLは、注文へ付ける場合と、保有positionへ設定する場合で対象数量や取消条件が異なることがあります。 ### 先物注文の確認順 1. 対象の先物契約を確認する 2. position modeとmargin modeを、未決済注文・positionがない段階で確認する 3. オープン/クローズ、Long/Short、position sizeを確認する 4. 注文種別と、その注文に必要な価格・trigger・数量を入力する 5. 必要証拠金、推定清算価格、手数料、TP/SLを確認する 6. 注文後は未決済注文を確認する 7. 約定したらpositionの方向、entry price、size、清算価格、資金調達率を確認する 8. クローズ後はpositionだけでなく、注文履歴と取引履歴も確認する ## 資金調達率とカウントダウン 無期限先物では、先物価格を現物の参照価格へ近づける仕組みとして、一定の時点でLong側とShort側の間に資金調達料が発生する場合があります。MEXC公式計算ガイドの基本式は次の通りです。 ```text funding fee = funding rate × position value position value = fair price × contracts × contract size ``` 資金調達率が正ならLong側からShort側へ、負ならShort側からLong側へ支払うと説明されています。実際の対象position、計算方法、上限、精算間隔は契約ルールで確認してください。
MEXC先物ヘッダーのインデックス価格、公正価格、資金調達率とカウントダウン
撮影時のインデックス価格、公正価格、資金調達率、カウントダウン。数値と次回までの時間は変動するため、固定値として使わないでください。
資金調達料は、レバレッジ倍率を掛けた証拠金だけでなく、position valueを基準に考えます。また、画面のカウントダウンがゼロになる前にpositionを閉じれば常に得になる、という単純なものではありません。売買手数料、slippage、価格変動、再エントリーの条件が別にあります。 ## 注文が通らない・約定しないときの確認表 症状から設定を変えるのではなく、現在の注文と履歴を先に確認します。 | 症状 | 主な確認先 | 次に確認すること | | --- | --- | --- | | 注文ボタンを押せない | 地域・本人確認・商品制限、利用可能残高 | 公式規約・support、最低注文量、単位 | | 数量エラー | 数量欄、最小数量、桁数 | 数量と合計の取り違え、step size | | 残高不足 | available balance、未決済注文 | 他の注文で拘束中の残高、手数料分 | | 指値が約定しない | 現在の注文、注文板 | 市場価格と指値、残量、流動性 | | 成行が一部だけ約定 | 取引履歴、注文履歴 | 約定価格ごとの数量、未約定部分の状態 | | 条件付き注文が動かない | trigger、参照価格の種類 | 条件未到達、trigger後の注文状態 | | Post Onlyが取り消された | 注文履歴、指値 | 即時約定する価格になっていないか | | modeを変更できない | 未決済注文、position | すべての対象契約で注文・positionが残っていないか | | クローズ数量エラー | position size、クローズ方向 | 対象positionと数量、mode | | 通信後に結果が不明 | 現在の注文、注文履歴、取引履歴 | 重複送信せず、最初の注文が受理済みか | エラー文を検索するときは、銘柄、価格、残高、注文ID、メールアドレスなどを公開投稿へそのまま載せないでください。問い合わせに記録を残す場合も、日時、現物/先物、注文種別、状態を中心にし、個人情報や認証情報は伏せます。 ## 最後に確認するチェックリスト - 日本居住者向けの警告、地域制限、アプリ配布条件を最新情報で確認した - 現物と先物、取引ペアと先物契約を取り違えていない - 売買またはLong/Shortと、オープン/クローズを分けて確認した - 指値、成行、triggerなど、注文が成立する条件を説明できる - 先物ではmargin mode、position mode、レバレッジ、清算価格を確認した - 注文後に現在の注文、注文履歴、取引履歴、positionを確認した - 一部約定後の取消では、約定済みの部分が残る可能性を確認した - 資金調達率とカウントダウンを、その時点・その契約の表示として確認した MEXCの画面や商品条件は更新されます。古いスクリーンショットのボタン位置を覚えるより、**対象、方向、注文条件、現在の状態、最終履歴**の順で読む方が、UIが変わっても確認を続けられます。 ## 確認した一次情報 - [金融庁: 無登録で暗号資産交換業を行う者の名称等について（MEXC Global）](): 確認日 2026-08-28 - [MEXC: Restricted Countries](): 確認日 2026-08-28 - [MEXC: 利用規約](): 確認日 2026-08-28 - [MEXC: 現物取引FAQ](): 確認日 2026-08-28 - [MEXC: 現物の成行注文](): 確認日 2026-08-28 - [MEXC: 現物のOCO注文](): 確認日 2026-08-28 - [MEXC: Webでの先物取引](): 確認日 2026-08-28 - [MEXC: One-way modeとHedge mode](): 確認日 2026-08-28 - [MEXC: 先物取引画面の用語](): 確認日 2026-08-28 - [MEXC: 先物計算ガイド](): 確認日 2026-08-28 --- # Price impactとslippageの違い｜DEXエラー・MEVを安全に確認 DEXのPrice impactとslippageを混同せず、x*y=kの数値例、集中流動性、最大スリッページ、MEV・sandwich、現行Uniswap画面から安全な確認順を解説します。 正規URL: https://3mikan.com/archives/741 著者: みかん 公開: 2021-05-14T16:37:00.000Z 更新: 2026-08-28T10:30:00.000Z **Price impact**は、注文の大きさが流動性に対してどれくらい価格を動かすかです。**slippage（スリッページ）**は、見積もりから実行までに価格が変わり、最終結果がずれることです。 似た数字に見えますが、原因も確認するタイミングも違います。ここを混同すると、「Price impactが高いから最大スリッページを上げる」という危険な対処になりがちです。 この記事では、v2型AMMの小さな数値例、v3・v4の集中流動性、現行Uniswap Webの設定と警告、MEV・sandwichの順に確認します。実機画面は2026年8月28日、Ethereum、日本語UI、ウォレット未接続で撮影し、署名や取引は行っていません。 ## Price impact・slippage・MEVの違い まずは、3つを分けます。 | 用語 | 何を表すか | 主な原因 | いつ確認するか | | --- | --- | --- | --- | | Price impact | 注文によってmid-priceと平均約定価格に生じる差 | 注文量、active liquidity、route、fee | 署名前のquote | | execution slippage | quoteと実際の約定結果の追加差 | 待ち時間中の価格変動、他の取引、MEV | quoteとminimum output、実行後 | | 最大スリッページ | quoteからどこまで不利な変化を許すか | 利用者またはUIの設定 | 署名前の設定・確認画面 | | MEV | block内の取引順などから抽出される価値 | mempool、ordering、routeの仕組み | 送信経路と保護機能 | Uniswapの用語集では、slippageを「期待価格と実行価格の総差」と広く定義し、Price impactを含む場合があると説明しています。一方、操作画面を確認するときは、**quoteの時点ですでに見える注文影響**と、**送信後に増える差**を分けると原因を追いやすくなります。 最大スリッページは手数料ではありません。1%に設定したから必ず1%失うわけではなく、結果が条件を下回ったときに実行を止める境界です。 ## v2型の`x*y=k`でPrice impactを計算する Uniswap v2型の定積AMMでは、手数料をいったん除くと、2つのreserveが次の関係を保ちます。 ```text x * y = k ``` - `x`: 売る側のtoken reserve - `y`: 受け取る側のtoken reserve - `k`: 定積 ここでは、次の単純なpoolを考えます。 ```text 100 ETH 200,000 USDC mid-price = 2,000 USDC / ETH k = 20,000,000 ``` このpoolへ10 ETHを入れるとします。手数料を無視した新しいUSDC reserveは次の通りです。 ```text 20,000,000 / (100 + 10) = 181,818.18 USDC ``` 受け取れるUSDCと平均約定価格は次のようになります。 ```text amount out = 200,000 - 181,818.18 = 18,181.82 USDC execution price = 18,181.82 / 10 = 1,818.18 USDC / ETH ``` 見積もり前の2,000 USDCと比べると、Price impactは約9.09%です。 ```text 1 - 1,818.18 / 2,000 = 0.0909... ``` ![定積型AMMで10 ETHを売ると平均約定価格が動く数値例](/diagrams/price-impact/741-v2-price-impact.svg) この例は、仕組みを切り出すためにpool fee、複数poolへの分割、gas、外部市場の価格変動を省略しています。数値は`examples/amm-price-impact.mjs`で再計算できます。 実際のUniswap Webは、eligibleな場合のUniswapXと、v2・v3・v4のliquidityを含めてrouteを探します。そのため、画面のquoteを一つのv2 poolだけで再現できるとは限りません。 ## 最大スリッページは約定条件の下限 先ほどのquoteが18,181.82 USDCだったとします。最大スリッページを1%にすると、最低受取量は18,000 USDCです。 ```text minimum output = 18,181.82 * (1 - 0.01) = 18,000.00 USDC ``` 実行時の計算結果が18,000 USDC以上なら条件内、18,000 USDC未満なら条件外です。条件外でtransactionがrevertした場合でも、実行に使われたnetwork costが戻らないことがあります。 つまり、最大スリッページを上げると「Price impactが消える」のではありません。**より不利な実行結果まで受け入れられるようになる**だけです。
Uniswap WebのETHからUSDCへの見積もり画面で、最大スリッページが自動0.25パーセントと表示された設定パネル
2026年8月28日のUniswap Web。自動0.25%は、この時点・このquoteでの観測値であり、固定の既定値や推奨値ではありません。
Uniswapの自動設定は、quoteやsimulationに応じて値が変わります。古い記事にある0.5%や1%をそのまま入力するのではなく、現在の画面でminimum outputとrouteを確認してください。 ## v3・v4ではactive liquidityを見る v2型では0から無限大までのフルレンジを前提にreserve全体を考えます。Uniswap v3・v4の集中流動性では、LPが価格rangeを選び、その時点の価格を含むpositionだけがactiveになります。 価格がtickを跨ぐと、swapに使えるpositionが切り替わります。したがって、同じtoken pairで総TVLが大きく見えても、現在価格付近のactive liquidity、fee tier、routeによってPrice impactは変わります。 ![フルレンジと集中流動性で取引時に使える流動性が異なる図](/diagrams/price-impact/741-concentrated-liquidity.svg) 「pool全体の何%をswapするか」だけでv3・v4のPrice impactを断定できません。現在のquote、route、pool、active rangeを合わせて見ます。 LP側の価格range、資産構成、インパーマネントロスを確認したい場合は、[インパーマネントロスのAMM式と集中流動性](/archives/580)で分けて解説しています。 ## 現行UIでは警告文が変わることがある 2021年頃のUIでは`Price impact too high`という文言がよく使われていました。2026年8月28日に確認したUniswap Webの日本語UIでは、極端なquoteに対して**「大きな価格差」**と表示されました。
Uniswap Webの極端なETHからUSDCへの見積もりで、大きな価格差51.50パーセントと警告された画面
警告表示を確認するため100,000 ETHという極端な入力を使った未接続quote。取引・署名・送信は行っておらず、この数量やrouteを推奨するものではありません。
エラー名を検索して同じ文言がない場合でも、次を確認すれば意味を追えます。 1. 入力額と受取額の法定通貨換算差 2. Price impactまたは価格差の警告 3. minimum outputまたはminimum received 4. 最大スリッページ 5. token、chain、route、pool version 警告が大きいときは、まず署名せずに止めます。スリッページを上げる前に、contract address、chain、入力桁、route、liquidityを確認してください。 ## MEV・sandwichとslippageの関係 MEVは、blockへ入る取引の選択や順序などから抽出される価値です。DEXで問題になりやすい例がsandwichです。 1. searcherが利用者のswapより先に同方向の取引を入れる 2. 利用者のswapが動いた価格で実行される 3. searcherが利用者の後で反対売買を試みる ![sandwich取引と最大スリッページの関係](/diagrams/price-impact/741-sandwich-slippage.svg) 最大スリッページが広いほど、不利な価格でも利用者のswapが条件内に残る余地は広がります。ただし、**スリッページ設定だけでsandwichが必ず起きるわけではありません。** 注文規模、liquidity、価格変動、送信経路、保護routeの有無も関係します。 また、すべてのswapが同じ方法で公開mempoolへ送られるとは限りません。現在のUniswap WebはrouteによってUniswapXなどを使う場合があります。利用するDEXやwalletにMEV protection、private route、intent-based executionの表示がある場合は、その説明と適用条件を確認してください。 ## DEXの見積もり・エラーを安全に確認する順番 「通らないから設定を上げる」前に、次の順番で切り分けます。 ### 1. tokenとchainを確認する token symbolだけで判断せず、公式情報にあるcontract addressと一致するか確認します。同じsymbolの別token、別chain、wrapped tokenの取り違えがあると、liquidityもquoteも別物です。 ### 2. 入力額・受取額・価格差を見る 桁、decimals、法定通貨換算、Price impactまたは価格差を見ます。ここですでに大きく不利なら、最大スリッページを変えてもquote自体の悪さは直りません。 ### 3. routeとactive liquidityを確認する 同じpairでもpool version、fee tier、途中token、active liquidityが違います。UIがrouteを分割する場合もあります。特定versionへ固定する前に、default routeのquoteと比較します。 ### 4. 数量を下げたquoteと比較する 注文を小さくしたときにPrice impactが大きく下がるなら、注文量に対してliquidityが浅い可能性があります。ただし、小分けにすれば必ず総コストが下がるわけではありません。network cost、繰り返す間の価格変動、各swapのfeeも含めて比較します。 ### 5. 最大スリッページとminimum outputを確認する 自動値または現在値を基準に、最悪条件で何tokenを受け取るか確認します。失敗回避だけを目的に許容幅を上げ続けないでください。 ### 6. 送信経路とMEV保護を確認する 保護機能がある場合も、名称だけで安全を保証しません。どのchain、route、注文形式で有効かを公式説明で確認します。 ### 7. 不明なtoken仕様をslippageで解決しない transfer fee、売却制限、rebasing、reflection、contractの不具合や悪意が原因の場合、slippageを上げても安全にはなりません。[token contract・market・routerを分ける確認手順](/archives/6061)で、受取差、current state、proxy、roles、シミュレーションをread-onlyで確認します。知らないサイトへwalletを接続したり、追加承認を繰り返したりしません。 contract、calldata、event logsを読む場合は[ABI・function selector・event logsの確認方法](/archives/6005)、transactionの失敗理由をreceiptから追う場合は[receipt・revert・nonceのデバッグ手順](/archives/6001)を参照してください。 ## 症状別チェック表 | 症状 | 最初に確認するもの | やらないこと | | --- | --- | --- | | quote時点でPrice impact・価格差が大きい | 入力桁、token、chain、route、active liquidity | slippageだけを上げる | | quoteが出ない・liquidity不足 | contract address、chain、pool、対応token | 別tokenをsymbolだけで選ぶ | | `minimum received`条件で失敗 | 新しいquote、最大スリッページ、deadline、価格変動 | 失敗のたびに許容幅を広げる | | 売却だけ失敗する | token contract、transfer fee、制限、router対応 | 「税tokenだから」と根拠なく断定する | | transactionがpending | explorerのstatus、nonce、network、replacement | 同じnonceを理解せず連続送信する | | 50%など極端な損失警告 | 署名前に停止し、contractとrouteを再確認 | `Swap anyway`を機械的に選ぶ | pending、dropped、replacedの判定は[nonce・replacement・statusの確認フロー](/archives/6004)で扱っています。 ## よくある質問 ### Price impactが高いとき、slippageを上げればswapできますか？ 実行できる場合はありますが、安全な解決ではありません。Price impactはquoteへすでに含まれる注文影響で、最大スリッページはそのquoteからさらに許す変化です。まず数量、route、token、active liquidityを見直します。 ### 1%のslippageなら必ず1%損しますか？ いいえ。1%は許容境界です。quote通りに実行されれば追加差は小さくなります。一方、条件内なら1%近く不利な結果でも実行されうるため、minimum outputをtoken数量で確認します。 ### 注文を小分けにすれば必ず得ですか？ 必ずではありません。1回ごとのPrice impactが下がっても、複数回のnetwork cost、fee、途中の価格変動が増えます。分割前後の総受取額と総費用をquoteで比べます。 ### 高いslippageは必ずsandwichを招きますか？ 必ずではありません。ただし、不利な価格でも成立する幅が広がるため、注文規模や公開経路などの条件が揃うとsandwichの余地を広げます。必要以上に広げず、MEV保護routeの適用条件も確認します。 ### `Price impact too high`が表示されません UIの文言が変わっている可能性があります。Price impact、price difference、minimum received、rate warningなど、quoteと市場価格の差を示す項目を確認してください。文言より、入力額・受取額・割合・routeを見ることが大切です。 poolのspot価格をlendingやvaultの判定へ使う場合は、画面のquoteとは別に、feedの`decimals`、更新時刻、L2稼働状態、TWAP windowを確認します。詳しい判定順は[DeFi Oracleのdecimals・staleness・TWAP検証](/archives/6042)で整理しています。 ## まとめ - Price impactは、注文自身がliquidityに対して価格を動かす幅 - execution slippageは、quoteから実行までに増える差 - 最大スリッページは損失額ではなく、実行を許す境界 - v3・v4では総TVLだけでなくactive liquidityとrouteを見る - 高い許容幅はsandwichの余地を広げうるが、単独の発生原因ではない - 警告時は署名前に止まり、token、chain、数量、route、minimum outputを確認する この記事の数値は仕組みを検算する例です。特定のtoken、DEX、設定値、取引を推奨するものではなく、約定や損失回避を保証しません。 ## 確認した一次情報 - [Uniswap Developers: Glossary](): 確認日 2026-08-28 - [Uniswap Developers: How Uniswap Works](): 確認日 2026-08-28 - [Uniswap Developers: Concentrated Liquidity](): 確認日 2026-08-28 - [Uniswap Labs: What is price impact?](): 確認日 2026-08-28 - [Uniswap Labs: What is Slippage?](): 確認日 2026-08-28 - [Uniswap Labs: How to change default trade options](): 確認日 2026-08-28 - [Uniswap Labs: Why did my transaction fail?](): 確認日 2026-08-28 - [ethereum.org: Maximal extractable value](): 確認日 2026-08-28 - [Uniswap Web App: Ethereum swap UI](): 確認日 2026-08-28 --- # インパーマネントロスとは？AMM式・計算例・手数料との損益分岐 インパーマネントロスを、x*y=kのAMM式、価格比ごとの計算例、HODL比較、手数料で埋める損益分岐、集中流動性との違いまで再計算可能なコードで解説します。 正規URL: https://3mikan.com/archives/580 著者: みかん 公開: 2021-04-25T11:31:05.000Z 更新: 2026-08-27T14:34:00.000Z 流動性プールへ2種類のトークンを預けると、価格が動いたときに「そのまま保有していた場合」と違う数量構成になります。この差を表すのが**インパーマネントロス（Impermanent Loss、IL）**です。 ILは、預けた資産の円換算額が必ずマイナスになる、という意味ではありません。比較対象は、同じ初期資産をウォレットで持ち続けた場合です。LPの評価額が増えていても、HODLより増え方が小さければILは発生しています。 この記事では、50:50の定積型AMMを前提に、`x*y=k`、価格比ごとの計算、手数料で差を埋める損益分岐、集中流動性で前提が変わる点まで整理します。数値はリポジトリの`examples/impermanent-loss.mjs`で再計算できます。 ![価格変化に合わせて定積型AMMの2資産残高が変わる流れ](/diagrams/impermanent-loss/580-constant-product.svg) ## インパーマネントロスは「LPとHODLの差」 まず、次の3つを分けて考えます。 | 指標 | 比較しているもの | | --- | --- | | LP評価額 | 現在LPを解消したときに受け取る2資産の時価 | | HODL評価額 | 最初に預けた2資産を、そのまま持っていた場合の時価 | | IL | `LP評価額 ÷ HODL評価額 - 1` | たとえば、LP評価額が2,828ドル、HODL評価額が3,000ドルなら、ILは約`-5.72%`です。LP評価額そのものは初期の2,000ドルから増えていますが、HODLより171.57ドル少ないため、相対的な損失があります。 「impermanent」と呼ばれるのは、価格比が預入時へ戻れば、手数料を除いたこの差が理論上は解消するためです。ただし、価格が戻る保証はなく、LPを解消すればその時点の数量構成が確定します。名前だけを理由に、損失が必ず戻ると考えないでください。 ## `x*y=k`で保有数量が変わる Uniswap v2型の定積AMMでは、手数料をいったん無視すると、プール内の2資産量は次の関係を保ちます。 ```text x * y = k price = y / x ``` - `x`: 基準資産の数量 - `y`: 見積資産の数量 - `k`: 定積 - `price`: 見積資産で表した基準資産の価格 外部市場で価格が動くと、裁定取引によってAMMの価格も近づきます。その過程で、値上がりした資産はプールから減り、もう一方の資産が増えます。LPはプールの持分を保有しているため、引き出せる資産数量も変わります。 新しい価格を`P`とすると、定積型プールの残高は次のように求められます。 ```text x = sqrt(k / P) y = sqrt(k * P) ``` ## 価格が2倍になった例 初期状態を次のようにします。 ```text 1 ETH + 1,000 USDC 1 ETH = 1,000 USDC 初期評価額 = 2,000 USDC k = 1 * 1,000 = 1,000 ``` ETH価格が2,000 USDCになったとき、手数料を無視したAMM内の数量は次の通りです。 ```text ETH = sqrt(1,000 / 2,000) = 0.707106... USDC = sqrt(1,000 * 2,000) = 1,414.213... ``` ![ETH価格が2倍になったときのLPとHODLの評価額比較](/diagrams/impermanent-loss/580-hold-vs-lp.svg) | 比較 | 保有数量 | 2,000 USDC/ETHでの評価額 | | --- | --- | ---: | | LP | 0.7071 ETH + 1,414.21 USDC | 2,828.43 USDC | | HODL | 1 ETH + 1,000 USDC | 3,000.00 USDC | | 差 | — | -171.57 USDC | したがって、HODL比の差は次のようになります。 ```text 2,828.43 / 3,000 - 1 = -0.05719... ``` **価格が2倍のとき、手数料を除くILは約5.72%です。** 価格が半分になった場合も、同じ価格比の逆数なので相対差は約5.72%になります。 ## 価格比だけで計算する式 預入時からの価格比を`r`とすると、50:50のフルレンジ定積AMMで、手数料を除いたLP/HODL比は次の式になります。 ```text LP / HODL = 2 * sqrt(r) / (1 + r) IL = 2 * sqrt(r) / (1 + r) - 1 ``` 損失率を正の数で表示したい場合は、次のようにします。 ```text loss = 1 - 2 * sqrt(r) / (1 + r) ``` ### 価格比ごとの早見表 | 現在価格 ÷ 預入時価格 | HODL比の差 | | ---: | ---: | | 0.25倍 | -20.00% | | 0.50倍 | -5.72% | | 0.80倍 | -0.62% | | 1.00倍 | 0.00% | | 1.25倍 | -0.62% | | 1.50倍 | -2.02% | | 2.00倍 | -5.72% | | 3.00倍 | -13.40% | | 4.00倍 | -20.00% | | 5.00倍 | -25.46% | | 10.00倍 | -42.50% | `r`と`1/r`は同じILになります。たとえば4倍と0.25倍、2倍と0.5倍は同じ相対差です。 ## 手数料で埋める損益分岐 LPにはスワップ手数料が入ります。そのため、最終的な成績は、手数料を除いたILだけでは決まりません。 単純化して、同じ時点・同じ通貨単位で比較するなら、HODLへ追いつく条件は次の通りです。 ```text LP評価額 + 累積手数料 - 管理コスト >= HODL評価額 ``` 価格が2倍の例では、差は171.57 USDCです。 - HODL評価額に対して必要な手数料: `171.57 / 3,000 = 5.72%` - 手数料を除くLP評価額に対して必要な手数料: `171.57 / 2,828.43 = 6.07%` この6.07%は、今後その利回りが得られるという予測ではありません。あくまで、その時点の価格比でHODLとの差を埋めるために必要な累積収益率です。 実際には、次も同じ期間・同じ評価通貨で揃える必要があります。 - 受け取ったスワップ手数料 - 追加インセンティブ - ガス代、reposition、claimなどの管理コスト - 未収手数料を含めるか - トークン価格と報酬トークン価格 - positionを追加・削除した時刻 高い表示APRだけで判断せず、HODLとの差、実現した手数料、管理コストを分けて記録してください。 ## フルレンジと集中流動性では前提が違う ここまでの式は、50:50で0から無限大まで流動性を置く、Uniswap v2型またはフルレンジの定積ポジションを前提にしています。 Uniswap v3・v4の集中流動性では、LPが価格レンジを設定します。狭いレンジへ資本を集中させると、レンジ内では同じ資本でも深い流動性を提供できます。一方で、価格が境界へ近づくほど資産構成が一方向へ偏り、レンジ外ではポジションが単一資産になります。 ![フルレンジと集中流動性で価格範囲と資産構成が異なる図](/diagrams/impermanent-loss/580-concentrated-range.svg) | 状態 | 資産構成 | 手数料 | | --- | --- | --- | | レンジ内 | 2資産の比率が価格とともに変化 | 対象レンジで取引があれば獲得対象 | | 下限より下 | 一方の資産へ偏る | レンジ外のため獲得しない | | 上限より上 | もう一方の資産へ偏る | レンジ外のため獲得しない | 集中流動性の損益は、レンジ下限・上限、開始価格、終了価格、fee tier、手数料、再配置コストを含めて計算する必要があります。上の`2*sqrt(r)/(1+r)-1`を狭いレンジへそのまま当てはめないでください。 ## ILを確認するときのチェックリスト 1. 比較対象はHODLか、初期元本か 2. 価格比は同じ通貨建てか 3. フルレンジか、集中流動性か 4. 手数料・報酬を含めたか 5. ガス代と再配置コストを含めたか 6. positionがレンジ内か、レンジ外か 7. LPを追加・削除した時刻を揃えたか 8. トークン自体の価格下落やスマートコントラクトリスクと混同していないか DEX画面のPrice impactやslippageは、LPの長期的なILとは別の概念です。取引時の価格影響と許容差は[Price impact・slippage・MEVの解説](/archives/741)で扱います。 `x*y=k`を実装上の性質として複数swapの後にも検査する方法は、[Foundry invariant testの記事](/archives/6022)でunit・fuzz・stateful invariantを同じAMM fixtureにして再現しています。 LPを解消するトランザクションやcalldataを確認したい場合は[ABI・function selector・event logsを読む方法](/archives/6005)、PancakeSwapで流動性を追加・解除する操作は[PancakeSwapのLP解説](/archives/821)を参照してください。 ## まとめ インパーマネントロスは、LPの評価額が初期元本より減ったかではなく、**同じ初期資産を保有し続けた場合との差**です。 - 50:50のフルレンジ定積AMMでは、価格比`r`から再計算できる - 価格が2倍または半分なら、手数料を除くHODL比の差は約5.72% - 手数料がILと管理コストを上回れば、HODLへ追いつく可能性がある - 集中流動性ではレンジと資産構成が変わるため、フルレンジ式だけでは評価できない - レンジ外では単一資産になり、価格が戻るまで手数料を獲得しない LP提供は、手数料収入と引き換えに、価格変動、資産構成の変化、スマートコントラクト、トークン、管理コストのリスクを引き受ける行為です。この記事の数値は仕組みを確認する例であり、収益や損失回復を保証するものではありません。 ## 確認した一次情報 - [Uniswap Labs: What is Impermanent Loss?](): 確認日 2026-08-27 - [Uniswap Developers: Understanding Returns](): 確認日 2026-08-27 - [Uniswap Developers: Concentrated Liquidity](): 確認日 2026-08-27 - [Uniswap Labs: Out-of-range liquidity](): 確認日 2026-08-27 - [Uniswap Labs: Liquidity risks](): 確認日 2026-08-27 --- # ビットコインFXとは？現物との違い・レバレッジ・リスク管理の基本 ビットコインFXの仕組み、現物取引との違い、必要証拠金、ロスカット、手数料、リスク管理の基本を整理。旧記事3本の固有情報を統合し、期限切れの特典は推奨しません。 正規URL: https://3mikan.com/archives/2486 著者: みかん 公開: 2021-09-02T14:16:16.000Z 更新: 2026-08-27T05:20:00.000Z

2026年8月27日更新: 本ページは /archives/2501、/archives/2709、/archives/2853 の固有情報を統合しました。本文後半の取引所名、手数料、画面、キャンペーンは2021年時点の記録であり、現行の推奨ではありません。取引条件は契約する事業者の公式表示で確認してください。

現物取引とFX・証拠金取引の違い

比較項目現物取引FX・証拠金取引
取引対象実際の暗号資産を売買価格変動の差額を取引
資金原則として購入代金が必要証拠金を担保にポジションを持つ
売りからの取引保有資産の売却が基本ショートから開始できる商品がある
主な損失リスク資産価格の下落価格変動に加え、ロスカットと追加証拠金の条件

取引前に決めるリスク管理

  • 許容損失額を先に決め、ポジション量とレバレッジを後から決める。
  • ロスカット価格だけに頼らず、逆指値などの手仕舞い条件を注文前に設定する。
  • 取引手数料、資金調達率、スプレッド、出金コストを別々に確認する。
  • クロスマージンでは口座の利用可能残高が広く損失に露出し得る。分離マージンでも、割り当てた証拠金を失う可能性がある。
  • 「利益が出る方法」としてコピートレード、両建て、ハイレバレッジを信用しない。

2021年時点の解説記録

以下は統合前記事の画像や説明を歴史記録として保持したものです。

今回の記事では、『BTC(ビットコイン)FX』について解説していきたいと思います。

BTC（ビットコイン）FXはレバレッジ取引とも呼ばれ、このレバレッジ取引の認知度は年々高まっています。

【初心者向け】BTCFX（ビットコインFX）とは？レバレッジ・メリット・デメリット・おすすめの取引所を徹底解説します。の説明画像

一般社団法人日本暗号資産取引業協会が発表している統計からもわかるように、レバレッジ取引の人気が読み取ることができます。ただ、一方でリスクも大きいのがこのレバレッジ取引になります。

BTC（ビットコイン）FXを仮想通貨の運用として利用する前に、知ってほしいメリット・デメリットを今回は紹介していきたいと思います。注文方法やトレード方法などのすぐに利用できる知識も紹介していますので、是非最後まで読んでいただければと思います。

BTC(ビットコイン)FXとは？

BTC(ビットコイン)FXとは、今後の値動きを予測し買い注文（ロング）売り注文（ショート）にて取引をします。変動した差額分が自分の利益となり、そこにレバレッジをかけることで少ない資金でも大きな取引を行う事が可能です。

1万円（運用資金）×レバレッジ100倍＝100万円

100倍のレバレッジをかけることで100万円分のポジションを、1万円の資金で持つ事が可能になります。

※仮想通貨取引所によってレバレッジの振り幅は異なります。
（日本の取引所は最大2倍・海外は最大125倍）

これがビットコインFXの魅力だと思っています。では、この取引を可能とした『レバレッジ』とはどのような仕組みでしょうか。

レバレッジとは

aaaaaaaaaaa

レバレッジとは＞＞自分の資金を担保にし、数倍〜数十倍の取引が可能。

オーソドックスな取引と言えば『現物取引』の方が馴染み深いと思います。

しかし、この図から分かるように１BTCを購入する際にBTC（ビットコイン）FXの場合元金が2万円でも同じポジションを保有することができます。レバレッジを利用することで、現物と同じポジションを保有することができますがビットコインFXの場合は暗号資産そのものを保有しているわけではありません。

現物取引は、通貨を交換することで利益を生み出しますが、レバレッジ取引の場合実際に暗号資産を保有するわけではなく仮想通貨市場の今後の値動きを予測し売買を行いその差額で利益を生み出す取引方法です。

そのため、レバレッジを利用することで小さい資金でも運用することができます。

ビットコインFXのメリット３つ

ビットコインFXには３つのメリットがあります。

  • 少額で始められる
  • 自分のライフスタイルに合わせる事ができる
  • 売り注文が可能

現物取引をしたことがあるけど、ビットコインFXはしたことがないという方は比較しながらメリットを理解していただくといいと思います。

①少額ではじめられる

レバレッジ取引で説明したように、少額の資金でもポジションを持つことが可能です。

2021年9月現在１BTCは500万円ほどです。仮にBybitを利用して1BTCのポジションを持とうとすると、5万円の資金で100倍のレバレッジを利用し1BTC買えると言うことになります。

元手が少ない方でも、このレバレッジ取引を活用することでより大きなリターンを作ることが可能です。

②自分のライフスタイルに合わせる事ができる

仮想通貨取引所は24時間365日対応しています。

そのため、他の投資と違い取引ができない時間や期間が無いため自分の好きな時間に空き時間を利用して運用していくことが可能です。

③売り注文が可能

取引の多くが、安く買い高く売る事だと思いますが、レバレッジ取引は差額分が利益になる取引です。そのため、高い時に売り安くなったら買い戻すという売り注文も可能になります。

上がる時は比較的ゆっくりで下がる時は一気に下る相場であるため、売り注文もうまく活用することをおすすめします。

ビットコインFXのデメリット３つ

初心者の方は特に気をつけて確認してほしい内容になっています。

  • 取引コスト
  • 価格変動が激しい
  • 利益を出すほど税率が上がる

例えば、プラスで利確したはずなのに資産がマイナスになっている事もあると思います。自分の資金を丁寧に使う為にも、ビットコインFXの特徴を抑えて取り組んで行く必要があります。

①取引コスト

  • レバレッジ手数料（ロールオーバー）
  • スプレッド
  • 強制決済手数料
  • 必要証拠金
  • 拘束証拠金
  • 証拠金維持率

このように、レバレッジ取引には様々な手数料が発生します。取引所によってどんなコストが発生するかは異なるため、取引前に一度確認しておきましょう。

また、レバレッジ取引で一番気をつけたいのが強制決済です。取引所によって決められたポジション維持率を下回った場合、その不足額を解消せずに保有していると強制的にポジションが決済されます。

これがよく聞く、ロスカットです。決済された時点で損失が確定するため、不足分を入金するかポジションの一部または全部を決済し解消する必要があります。担保にする資金が少なすぎるとロスカットの確率も上がる為注意してください。

②価格変動が激しい

仮想通貨はレンジ相場が8割と言われており、価格変動がとても激しいです。

このレンジ相場がチャンスでもありますが、長期で保有する事がリスクになる場合もあるため、自分の担保とレバレッジによる損切りラインの確認は必ず行いましょう。

また、自分のルールを作ることも大切です。『翌日に繰り越さない』『手数料が発生する前に利確する』『価格が暴落する前に損切りする』といったリスク管理も重要になります。自分のやりやすいやり方にあわせてレバレッジ取引を行っていく事をおすすめします。

③利益を出すほど税率が上がる

仮想通貨ででた利益は雑所得に分類されます。

所得税は累進課税のため、住民税と合わせると最大55％にまでなる可能性があります。

ハイリスクハイリターンなレバレッジ取引ですが、利益を出すという点において損失が出た場合もリスクが大きく利益を出した場合もまた違う問題が出てきますので知識をつけた上で取引を行う事をおすすめします。

【2021年版】仮想通貨の税金はどう計算する？基礎知識から実際の計算方法を紹介【ビットコインFX】

ビットコインFXおすすめの取引所

ビットコインFXが利用できる取引所は数多くあります。

その中でも、私自身も個人的に利用しおすすめしたい取引所を紹介しますので是非参考にしてください。

Bitget(ビットゲット)で自動で取引！

銘柄数取引手数料最大レバレッジ
２１指値▶0.04%
成行▶0.06%		125倍

Bitget(ビットゲット)の一番の魅力はコピートレードが可能な所です。

自分自身がコピートレーダーになることも可能ですが、どんなトレードをしていいか分からないという方は、プロのトレーダーさんの運用方法をコピーし自分の資金を運用することが可能です。

更新（2026年8月29日）：Bitgetは日本居住者の新規登録停止とサービス終了予定を公表しています。上記の過去記事を現行の登録・運用手順として使わず、先にBitgetの日本向けサービス終了日程を確認してください。

Bybit(バイビット)で手数料を受け取る！

銘柄数取引手数料最大レバレッジ
１１指値▶−0.025%
成行▶0.075%		100倍

個人的にBybitの使いやすさ見やすさがおすすめです。

レバレッジ取引となると、重要になってくるのがタイミングです。価格変動が激しい相場だからこそ、使いやすさは重視したいポイントだと思います。

また、指値注文の場合手数料を受け取る事ができます。取引回数が多いという方は、他の取引所ではない大きなメリットなのでぜ参考にしてください。

その他の記事も参考になれば嬉しいです。

https://3mikan.com/archives/1945

Binance(バイナンス)でコスト削減！

銘柄数取引手数料最大レバレッジ
２６０指値▶0.02%
成行▶0.04%		１２５倍

取引可能な通貨数の豊富さ安定した流動性で取引がしたいという方には、Binance(バイナンス)がダントツでおすすめです。

初めての方からすると使い方が難しいと思う方もいると思います。ただ、国内で買うことができないアルトコインを投資したいという方は、BNBを利用すると手数料が半額になるというメリットなども多くあるのでぜひ参考にしてみてください。

Binance（バイナンス）はサービス内容がとても充実しています。気になる方は是非チェックしてください。

https://3mikan.com/archives/2066

ビットコインFXで活用したい注文方法

ビットコインFXで活用できる注文方法を2つ紹介したいと思います。

初心者の方はまずは、『指値注文・成行注文』から利用することをおすすめしますがその他にも活用できる注文方法を知ることでリスクヘッジの幅を広げられると思うので紹介していきたいと思います。

損切り・トレンドフォローで使いたい『逆指値注文』

逆指値注文は言葉通り、『指値注文』の逆を意味し『高くなったら買いたい・低くなったら売りたい』注文方法になります。

どんな時に活用できるかというと、相場が読みにくかったり予想と逆の動きをしてしまった際のリスクヘッジとして活用することができます。

『逆指値注文』の使い方からより具体的な意味はこちらで記載していますので利用したい方は参考にしてください。

損失を最小にする際の損切りとして利用する『逆指値注文』がおすすめです。

短期トレードで使いたい『両建て注文』

両建て注文は、買いと売りのポジションを２つとも持つことを意味します。

仮想通貨の相場は、８割がレンジ相場と言われていますが『両建て注文』はレンジ相場と相性がいいです。現物取引ではできない手法にもなりますので、ビットコインFXならではの利点が活かせる手法でもあります。

『両建て注文』についてはこちらから詳細を確認できますが、注意してほしい点を特に確認してほしいです。

損失を相殺したい場合や運が良ければどちらのポジションでも利益を作ることができます。

ビットコインFXで活用したいトレード方法

ビットコインFXで活用できるトレード方法を2つ紹介します。

現物取引よりも『手数料コスト』が大きくかかってしまうのが、ビットコインFXのデメリットです。そのため、このポジションコストを削減できるトレードを紹介したいと思います。

手数料負担を減らしお得にトレードする方法

ビットコインFXでは、ポジションを保有した場合『レバレッジ手数料』という一日決済せず保有した場合に発生する手数料があります。Bybitの場合0.05％決済手数料として発生し、取引所によってこの手数料は異なります。

『スキャルピング／デイトレード』は一日以内で終わらせるトレード方法になります。自分のトレードルールに合わせて、活用してみてください。

見落としがちな手数料ですので、長期保有する場合は利幅を作ることを意識しましょう。

手数料を受け取りお得にトレードする方法

全ての取引所ではありませんが、大手取引所を利用した場合（Binance／Bybitなど）1日に3回金利を受け取ることができます。逆を言うと支払う側になりうる可能性もあり、この仕組みを『資金調達率=ファンディングレート』と呼びます。

計算方法から数字の見方、レバレッジとの関係性はこちらの記事で紹介しています。

ビットコインFXをやる上で損しない為にも、『資金調達率』は知っておきたいワードです。

ビットコインFXまとめ

今回の記事では、BTC(ビットコイン)FXについて紹介しました。仮想通貨取引所によって最大レバレッジ数や取り扱い通貨も異なりますので、自分が利用したい通貨をどこで一番賢く運用できるかリサーチすることをおすすめします。

また、価格変動が激しい点を今回デメリットとしてあげましたが、逆にこの値動きがメリットだったりもします。レバレッジをうまく活用し、資金効率を上げた上で利益に繋げられればと思います。

注文方法・トレード方法については、各ブログを参考にしていただき理解を深めた上で実践していただくのがいいかと思います。

最後まで読んでいただきありがとうございました。

## 確認した一次情報 - [金融庁: 暗号資産を利用する際の注意点](): 確認日 2026-08-27 --- # NFTとは？仕組み・権利・ウォレットのリスクをイーサリアム基準で解説 NFTの一意性を支えるトークンIDとコントラクト、著作権との違い、メタデータ、ウォレット承認、売買時に確認したいリスクを整理します。 正規URL: https://3mikan.com/archives/3124 著者: みかん 公開: 2021-10-15T09:42:33.000Z 更新: 2026-08-27T05:20:00.000Z

2026年8月27日更新: 旧記事 /archives/3252 の初心者向け解説と注意点を本ページへ統合しました。本文後半のサービス、画面、価格、手数料は2021年時点の記録です。購入・出品前に、利用するチェーンとマーケットプレイスの現行条件を確認してください。

NFTを理解するための4つの確認点

  • トークンの識別: ERC-721では、コントラクトアドレスとトークンIDの組み合わせで個々のNFTを識別する。画像ファイルそのものがブロックチェーン上に保存されるとは限らない。
  • メタデータ: 名称、画像、属性などが外部ストレージを参照する設計では、参照先の停止や内容変更もリスクになる。
  • 権利: NFTの保有は、著作権や商用利用権の自動移転を意味しない。発行者の規約とライセンスを個別に確認する。
  • ウォレット: 送付先の誤り、秘密鍵の紛失、偽サイトへの接続、不必要なトークン承認によって資産を失う可能性がある。

売買前には、発行元、コントラクトアドレス、対象チェーン、付与される権利、ロイヤリティ、手数料、マーケットプレイスの対応範囲を確認します。「オンチェーンで所有者を確認できること」と「作品の真正性や価値が保証されること」は同じではありません。

2021年時点の解説・操作記録

以下は当時の市場例や操作画面を歴史記録として保持したもので、現行手順やサービスの推奨ではありません。

今回の記事では、NFT(非代替性トークン)の中で最も使われているブロックチェーンであるETH(イーサリアム)について解説していきたいと思います。

2021年からよく耳にするようになった『NFT』ですが、著名人の方を始め小学3年生の男の子が作成したNFTが合計380万円の取引高まで価値がつくなど「なんかすごそう」という話題ばかりですよね。

実際にイーサリアムを利用しNFTの売買の方法を画像つきで紹介していきたいと思います。『NFTに興味があった』『工程が難しいと思い挑戦できなかった』そんな方は是非最後まで読んでみてください。

NFT（非代替性トークン）とは？

NFTとは、非代替性トークンとも呼ばれ仮想通貨技術のブロックチェーンを利用したデジタルデータのアート作品です。

このブロックチェーンを利用する事で、デジタルデータに価値を創造することが可能になりBTC(ビットコイン)やETH(イーサリアム)のようにNFT(非代替性トークン)にも資産価値が発生します。

NFTの仕組みや特徴

この「NFT」は今までの仮想通貨（コイン・トークン）と何が違うのでしょうか？

また、どんなところで利用されることを想定しているものなのでしょうか？

NFTに関する理解を深めてもらうためにまずはNFTの特徴から説明していきます。

ブロックチェーンで「一意性」が証明される

NFT(非代替性トークン)は、デジタルデータ管理にブロックチェーン技術を利用したことにより他の作品とは交換することが不可能になり「一意性」が証明できるようになりました。

NFTを購入すると『Token ID』が発行され、モノを保有する権利を証明されます。

この『Token ID』が異なる場合は「違うモノ」とみなされるため、結果的に一意性が保てるということです。

トークン同様ウォレットに保存して利用することができる

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

NFTを購入した場合、そのデータは購入サイトだけでなく自分のウォレットにも保存されます。

そのため、トークン同様に利用（送金など）することが可能です。

誰でもNFTを作成することができる

NFTは、特に何かしらの技術や資格がなくてもだれでも作成することが可能です。

BTC(ビットコイン)やETH(イーサリアム)といった通貨を発行するとなると難しく感じますが、NFT(非代替性トークン)は自分で作成したデジタルアートのコンテンツをNFTマーケットプレイスで出品するだけです。

デジタルアートを作った事がある方などは、手順はさほど変わりませんのでより簡単にNFT化することが可能だと思います。

NFTのリスクや問題点

ただNFTにもまだ課題があります。

ガス代が高い(手数料)

今回取引の際に、ガス代が高いと一番最初に感じました。

手数料分を考えた価格設定が最初は大切になるかもしれません。または、ガス代が発生しないマーケットプレイスも存在します。どこのNFTマーケットを利用するのがいいのか、リサーチする必要があります。

個人的におすすめは、OpenSeaです。手数料は発生しますが、規模感が違うので安心した取引が可能です。

著作権問題

NFTは、自分が著作権を持っていなくても販売ができてしまいます。

そのため、権利者でないけどマネタイズが可能になってしまう場合もあるという事になります。

例えば有名な漫画のどらえもんやワンピースなどの画像を勝手に出品することができてしまいます。

気持ちがいい売買ができるように、この問題は個々に気をつける必要があります。

国内のNFT対応状況と対応例

NFTはジャンルとしては「仮想通貨」に該当するので、日本の場合は規制の関係で対応状況があまり良くないです。

その中でもどうにかNFTに対応しようと開発をしてる会社もあるので紹介していきます。

国内のNFTマーケット

今回は3つ取り上げて紹介しようと思います。

  • Coincheck NFT
  • SBI NFT Market（旧nanakusa）
  • Adam

Coincheck

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

Coincheck NFTは、当時国内で提供されていたNFTマーケットの一つです。

オフチェーンの為、手数料の多くが無料で取引することができます。出品時のネットワーク手数料(ガス代)は発生します。

SBI NFT Market（旧nanakusa)

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

SBIホールディングス連結子会社化に従い、リブライディングしたnanakusaはイーサリアム／Polygonにて売買が可能です。

数十件に及ぶ不正流出で安全性が問われていたnanakusaですが、AML対策としてウォレットスクリーニング機能を国内初導入し安全性強化に励んでいます。

nanakusaは、運営側が認定したパートナーやアーティスト飲みが一次販売可能なため、『質』としてはとても高いと感じます。

Adaｍ

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

GMOアダム株式会社が運営していたNFTマーケットプレイスは、2021年8月31日に販売を開始した当時のサービス例です。

多様な決済方法により、NFTを簡単に利用することが可能になっています。

日本人でNFTを出品している人の例

NFTはどんな方でも販売可能です。

日本で実際に販売されている例をいくつか紹介します。NFT販売に興味がある方など参考にしていただければと思います。

香取慎吾さん(著名人)

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

香取慎吾さんが企画した日本財団パラリンピックサポートセンターへの全額寄付チャリティとして、NFTが活用されました。

壁画がNFT化され、たった1日で上限の1万点が達成されました。

せきぐちあいみさん(VRアーティスト)

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

NFTは、イラストだけでなく音楽や映像など様々なものをNFT化することが可能です。

日本のVRアーティストのせきぐちあいみさんが最初に出品した作品が、1300万円で落札されデジタルアートに価値付がされたことが証明されたと思います。

通称Zombie Zoo (小学３年生)

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

通称Zombie Zooくんが夏休みの自由研究で作成した、NFTのピクセルアートが80万円ほどで売れました。

これはニュースでもよく出てきた話題だったと思います。最初の1週間は反応がなかったそうですが、有名DJさんがアイコンにしてくれたことにより売れるきっかけになったそうです。

NFTの利用例・やり方

NFTの利用例は様々あり、今もいろんなアイデアが出されているところですが現状の主な使われ方はこんな感じです。

  • ゲームのアイテムとして利用されている
  • ファームやステーキングのトークンとして使用できる
  • 画像などの電子コンテンツをトークン化して売買できる

ゲームのアイテムとして利用されている

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

2021年10月現在、過去30日間で1人以上のユーザーがいるNFTゲームは400件以上ありました。

ゲームにブロックチェーン技術を利用したことにより、ゲーム内のアイテムやキャラクターをNFTとして保有することが可能になりました。

従来のゲームでは、武器などのアイテムは他の武器と価値が同じだったと思いますが、NFT化することにより『ラスボスで利用した武器』『著名人が利用した武器』など価値を創造できるようになります。

また、ブロックチェーンゲームは年々増えています。これにより、別のゲームで利用したアイテムやキャラクターでもブロックチェーンを通じて違うゲームでも利用が可能になっています。

ファームやステーキングのトークンとして使用できる

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

NFTBOXは、NFTBOX内で購入したNFTを預けることでNBトークンのステーキングが可能です。

NFTはガチャ購入になり、何がでるかは購入まで不明になっています。レア度がマイニングパワーに比例しNFTを売ってNBトークンに変換することもできます。

このように、NFTを利用しファームやステーキングが可能になるサービスもあります。

画像などの電子コンテンツをトークン化して売買できる

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

一番多いNFTの活用方法だとおもいます。

大手NFTマーケットプレイスのOpenSeaでは、8項目のカテゴリーに分かれて電子コンテンツをトークン化し売買することが可能です。

  • Art(美術)
  • Music(音楽)
  • DomainNames（ドメイン名前）
  • VirtualWords（仮想単語）
  • TraidingCards（トレカ）
  • Collectibles（収集品）
  • Sports（スポーツ）
  • Utility（効用）

ETH（イーサリアム）でNFTが売買されているマーケット

ETH（イーサリアム）を利用した人気のNFTマーケットをピックアップしてみました。

全て海外のマーケットにはなりますが、日本人の方でも簡単に取引が可能になっています。

※参考サイトDappRadar

OpenSea

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像
OpenSea公式サイト

Axie Infinity

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像
Axie Infinity公式サイト

Rarible

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像
Rarible公式サイト

他のチェーンのNFTマーケット対応状況

  • Ethereum：1,144マーケット
  • Polygon：８マーケット
  • トロン：１マーケット
  • Waves：１マーケット
  • WAX：23マーケット
  • BSC：５マーケット
  • FLOW：１マーケット
  • Tezos：１マーケット

ETH（イーサリアム）でNFTを購入するやり方

今回利用したNFTマーケットプレイスは、OpenSeaです。

①商品の選択

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像
画面右上の『Marketplace』から自分が欲しい作品の選択を行います。

私は今回猫ちゃんを選びました(笑)

欲しい商品を決めたら『Buynow』で決済へ進んで行きます。

②商品の確認

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

商品内容が正しければ、同意マークにチェック✓を入れ『Confirm checkout』をクリックでウォレットにて商品の確認を行います。

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

自分のウォレットが表示されたら『確認』を押してください。

③Transaction完了待ち

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

『Complate』するまで数分の待ち時間がありましたが、これで購入が完了です。

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

購入したものをすぐ売ることも可能です。

これで購入の流れは終わりです。

ETH（イーサリアム）でNFTを出品する方法

次は自分でコンテンツを出品してみましょう。

①サイトとウォレットを連携させる

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

まずは、自分が使いたいNFTマーケットと自分のウォレットを連携させて行きます。

ウォレットを持っていないという方は、MetaMaskを作成することをおすすめします。

②自分の作品をアップロードする

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

ウォレットを連携すると、この画面が表示されます。

『Create』から自分の作品をアップロードしていきます。

※先にプロフィールを設定してもいいですが、出品後でも設定は可能です。

③必須項目の入力

  • Image, Video, Audio, or 3D Model（画像、ビデオ、オーディオ、または3Dモデル）
  • Name（名前）

上記2つが必須項目です。

これらの入力で出品は可能ですが、その他にも記入欄がありました。

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

商品説明は合ったほうが購入者側からすると、より馴染みやすいかもしれません。

その他は、レベル設定などでカードのような設定も可能ですし鍵を利用することで、他のコンテンツをNFTをもっていないと見れなくするような設定も可能でした。

④ブロックチェーンの選択

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

OpenSeaのブロックチェーンは、ETH(イーサリアム)／Polygon(ポリゴン)の2つから選択が可能です。

今回は、ETHを選択しています。

⑤価格設定

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

『Create』ボタンをタップするとこの画面が表示され商品のアップロードが完了です。

次に、価格の設定を行います。

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

右上に表示される『売る』のボタンをタップ。

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

設定を完了させたら、『Complete listing』をタップで完了です。

⑥ガス代(手数料)の支払い

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

最後に『ガス代の確認』『署名』をします。

【完全網羅】NFTとは？イーサリアムでのやり方・仕組みや特徴・出品方法を徹底解説の説明画像

この画面が最後に表示され、出品完了になります。

Viewitemをタップすると自分の作品に価格が表示された画面が表示されます。

ETH（イーサリアム）のNFTやり方まとめ

今回は、ETH(イーサリアム)を利用しNFTの購入と出品を行ってみました。

NFTに興味がある方や、やってみたかったけどやり方がわからなかった方などの参考になれば嬉しいです。

ブロックチェーンにイーサリアムを利用する場合は、ガス代が高いという事を覚えていただき仮想通貨の知識もある程度ある上でNFT取引を初める事をおすすめします。

https://youtube.com/playlist?list=PLc68AqeefY7Uj12dLBJ2varJtvpkIm5qk
## 確認した一次情報 - [ethereum.org: ERC-721 Non-Fungible Token Standard](): 確認日 2026-08-27 --- # Overbitとは？コピートレード・MT5を含む2022年当時の記録 Overbitの2022年当時の取引機能、コピートレード、MT5の記録を統合。旧公式ドメインの接続を確認できないため、現在の登録や入金は案内していません。 正規URL: https://3mikan.com/archives/4597 著者: みかん 公開: 2022-03-31T17:10:46.000Z 更新: 2026-08-27T05:20:00.000Z

2026年8月27日確認: Overbitの旧公式ドメインはDNS応答を確認できず、現在の運営状況、提供地域、出金方法、問い合わせ先を検証できません。このページから登録や入金は案内しません。以下は /archives/4825 を統合した2022年時点の歴史記録です。

旧記事から引き継ぐ取引上の注意点

  • コピートレード: コピー元の過去成績は将来の利益を保証しない。注文遅延、スリッページ、取引量の差、レバレッジ、清算、利益分配や手数料を考慮する。
  • MT5: MetaTrader 5は取引・分析用のクライアントであり、接続先事業者の安全性や約定品質を保証するものではない。
  • 自動売買: Expert Advisor（EA）の互換性、稼働環境、通信断、設定ミス、相場急変による損失を事前に検証する。
  • 事業者確認: 運営主体、ライセンス、利用規約、顧客資産の管理、出金条件、居住地での利用可否を確認できないサービスへ資金を送らない。

2022年時点の紹介・操作記録

今回の記事では、暗号資産取引所である『Overbit』について紹介したいと思います。

Overbitはビットコイン証拠金取引所であり、仮想通貨・外国為替(FX)・貴金属などの市場で取引することができます。

複数の市場に対応した暗号資産取引所であり、仮想通貨とFXのボットトレードとして今人気のコピートレードも利用することができます。

日本ではあまり聞き馴染みのない取引所ではありますが、この記事では『どんな機能を利用できるのか』『利用する上で知りたい安全性と評判はどうか』この二点について深堀りしていきたいと思います。

Overbit(オーバービット)とは？

仮想通貨Overbitの登録方法と使い方について紹介！評判・安全性・口コミについて調査【2022年最新版】の説明画像

Overbit(オーバービット)は2017年に設立され2019年に運営が開始された追証なしの暗号資産取引所です。

  • Overbitクラシック
  • MetaTrader5
  • cTrader

使える機能としてこの3種類に分けられています。

デリバティブ契約の種類は「無期限契約」になっており、Overbitクラシックでは仮想通貨22ペア・FX16ペア・商品2種類となっています。

この機能はパソコンのみ対応しているため『スマホで取引している』そんなユーザーには少々使いにくい取引所かもしれません。

では具体的な特徴・評判（口コミ）・使い方について紹介していきます。

Overbit(オーバービット)取引所の基本情報

Overbit(オーバービット)概要
業種暗号資産取引所
運営会社Abberton Trading Limited
拠点香港・シンガポール・ロンドン・セイシェル
スマホアプリOverbit - cTrader対応
取引方法仮想通貨・FX・金融商品
レバレッジ暗号通貨：最大100倍
外国為替：最大500倍
公式FacebookOverbit
公式サイトTwitterOverbit(日本語)
Overbit(英語)
公式お問い合わせ旧公式ドメイン（現在は接続を確認できません）

※日本語を始めとする６の国の言語に対応しています。

当時の記事に記載されていた問い合わせ先は現在確認できないため削除しました。

最新情報：ＭＴ５を導入

FOhBynFVIAAjyoN

Overbit(オーバービット)では、今月の2022年3月23日にMetaTrader5(MT5)を導入しました。

MT5とは＞＞＞

仮想通貨を含むより多くの資産クラスに対応しており、FX、株式、先物の取引をすべて1つのプラットフォームでつなげるソフトウェアです。

これによりトレーダーは、詳細な価格分析、各種指標、アルゴリズム取引アプリケーション（Expert Advisor（EA）・ボット取引など）、コピートレードに使用する優れたツールにアクセスすることができます。

こちらについては、より詳しい詳細・使い方を別の記事で紹介したいと思います。

Overbit(オーバービット)の特徴

  1. 最大レバレッジ500倍とされた商品
  2. CipherTraceとの提携
  3. Overbitリワードハブ
  4. 手数料払いの選択
  5. デモ用残高

Overbit(オーバービット)の特徴を５つほど紹介したいと思います。

最大レバレッジ500倍

Overbit(オーバービット)では、仮想通貨で最大100／FXでは最大500倍のレバレッジを利用することができます。

FX(外国為替)市場で許可されているレバレッジ比率の中でもっとも高い倍率になっておりこれを活かし資金効率のよいトレードを可能とします。

しかし、レバレッジは『高いほどよい』ものでもないので初心者の方はレバレッジの使うタイミングに気をつけ損失のリスクも意識した運用が必要になります。

CipherTraceと提携

ユーザーセキュリティに力を注ぐOverbit(オーバービット)ですが、CipherTraceと提携し入金の受け取りや送金が必要となる可能性のある高リスクのウォレットや取引所を識別しています。

リスクがあるとみなされるウォレットへのトランザクションを停止する場合がある為、慎重に測定されたアプローチを採用しています。

また、実行されるトランザクションごとにリアルタイムで監査を実施し、すべてのユーザーのウォレットと取引をチェックし調整しています。

しかし、ライセンスの取得を判断基準にしているユーザーにとっては金融ライセンスの取得は現在しておりませんので利用する上でご確認の上取引してください。

Overbitリワードハブ

仮想通貨Overbitの登録方法と使い方について紹介！評判・安全性・口コミについて調査【2022年最新版】の説明画像

当時はイベントやミッションの条件を満たすと、BTC／USDT建ての報酬を受け取れると案内されていました。

Overbitリワードハブ確認方法

仮想通貨Overbitの登録方法と使い方について紹介！評判・安全性・口コミについて調査【2022年最新版】の説明画像

チャート画面左にある『Reward』をタップすると画面右に詳細は表示されます。

イベント情報やミッションはこちらで確認することができます。

手数料払いの可否が選べる

仮想通貨Overbitの登録方法と使い方について紹介！評判・安全性・口コミについて調査【2022年最新版】の説明画像

Overbit(オーバービット)は取引を行う際『手数料またはスプレッド』を選択することができます。

スプレッドの場合＞＞＞手数料が発生しない。

手数料の場合＞＞＞ポジション保持後残高から引き落とされます。

取引ごとに手数料は発生してしまいますが、スプレッドを選択した場合であっても取引コストは差ほど変わりません。

2022年当時のデモ用残高

仮想通貨Overbitの登録方法と使い方について紹介！評判・安全性・口コミについて調査【2022年最新版】の説明画像

当時は新規登録時に8 BTC相当のデモ用残高が表示される仕様でした。現金や出金可能な資産を意味するものではなく、現在は利用を確認できません。

チャート画面でライブトレーダーをタップすると『デモトレーダー』の選択が行えます。

仮想通貨Overbitの登録方法と使い方について紹介！評判・安全性・口コミについて調査【2022年最新版】の説明画像

すると画面右上に『DEMO』と表示があり、利用可能残高に体験金が反映されていることを確認することができます。

Overbit(オーバービット)の評判・口コミ

https://twitter.com/MackynHakusyaku/status/1506626855310307328
https://twitter.com/churei_ta/status/1494981729328955392
https://twitter.com/nekonomanekino/status/1489635176552726529
https://twitter.com/TEGu_xx/status/1487431731669921792
https://twitter.com/nanajin1966/status/1480550307348496385

Overbit(オーバービット)の2022年当時の登録画面

以下は2022年当時の登録画面です。現在は公式サイトの接続を確認できないため、この手順を利用しないでください。

仮想通貨Overbitの登録方法と使い方について紹介！評判・安全性・口コミについて調査【2022年最新版】の説明画像

下に行くと電話番号またはメールアドレスどちらかの入力画面が出てきます。

入力したら『口座開設』をタップし進みます。

仮想通貨Overbitの登録方法と使い方について紹介！評判・安全性・口コミについて調査【2022年最新版】の説明画像

『メールアドレス』『パスワード』を入力し規約に同意します。

最後に『口座開設』をタップし以上でoverbitの口座登録が完了です。

Overbit(オーバービット)のまとめ

Overbit(オーバービット)の登録はとても簡単でシンプルになっています。

当時は『Overbitリワードハブ』の報酬機能が掲載されていましたが、現在の提供状況は確認できません。

個人的な懸念点としては、『スマホ版アプリが利用することができない』『操作画面がスムーズにいかない』この二点が少し利用のしづらさとして感じました。

当時掲載されていた体験金や登録特典は終了済みとして扱います。旧URLへ個人情報を入力したり、資金を送付したりしないでください。

## 確認した一次情報 - [Overbit旧公式ドメイン（DNS応答を確認できず）](): 確認日 2026-08-27 --- # Bitgetの手数料とは？取引・出金・コピートレードとBGBの注意点 Bitgetの取引手数料、資金調達料、出金手数料、コピートレードの利益分配を整理し、BGB割引・BGB Earn・Launchpad・KCGIで確認したい条件を解説します。 正規URL: https://3mikan.com/archives/4609 著者: みかん 公開: 2022-03-01T13:34:14.000Z 更新: 2026-08-27T05:20:00.000Z

2026年8月27日更新: 旧記事 /archives/4928 のBGB Earn、Launchpad、KCGIに関する固有情報を本ページへ統合しました。本文後半の料率、年率、割引、ボーナス、画面は2022年時点の記録です。実際の負担額はBitget公式の最新表示で確認してください。

現在の条件を確認する順番

  • 売買: 現物・先物など商品別のメイカー／テイカー手数料を確認する。指値注文でも約定方法によってテイカー扱いになる場合がある。
  • ポジション保有: 先物では売買手数料とは別に資金調達料が発生し得る。料率と決済時刻は市場に応じて変動する。
  • 入出金: 出金手数料と最低出金額は資産・ネットワークごとに異なる。送金先と同じネットワークを選ぶ。
  • コピートレード: 通常の取引コストに加え、利益分配などの条件を確認する。コピー元と同じ価格で約定する保証はない。
  • BGB: 手数料割引やBGB Earnの条件、対応商品、利率は変更される。割引額だけでなくBGB自体の価格変動と償還条件も考慮する。

LaunchpadやKCGIのような企画は、開催期間、参加地域、本人確認、保有条件、報酬計算が回ごとに異なります。古いキャンペーンの数値を現在の条件として使わず、参加時点の公式ルールを確認してください。

2022年時点の解説・操作記録

以下は当時の画面と条件を歴史記録として保持したもので、現行の特典や料率を示すものではありません。

今回の記事では、コピートレードで有名な取引所である『bitget(ビットゲット)』の手数料について解説していきたいと思います。

仮想通貨取引で注意したい事の一つに『手数料負け』があります。手数料負けは、トレードポジションをプラスでクローズしているにも関わらず、損益はマイナスになっている状態をいいます。

初心者にありがちなリスクでもあるので、これを避ける為にも手数料は無視できないコストです。そのため、『手数料を把握する』ことがとても重要になります。

Bitgetでは2021年11月29日に現物取引・契約手数料が変更されました。以下の数値は当時の記録です。

手数料を比較する際の考え方と、2022年当時の操作画面を確認できます。

bitget(ビットゲット)とは３つの特徴

Bitgetは2018年に設立されたデリバティブ取引所になります。

特徴としてBitget(ビットゲット)を利用し収益をあげることができるサービスを３つ紹介したいと思います。自分にあった方法を是非活用してみてください。

1.コピートレードで自動で稼ぐ

Bitget(ビットゲット)の一番の強みは『コピートレード』です。

何千人ものトレーダーが取引をシェアしており、その中から自分で好きなトレーダーをコピーし自分の資金を運用することが可能です。

  • 運用に自信がない方
  • 時間に余裕がない方

このような方にはおすすめのサービスになります。

https://3mikan.com/archives/2010

コピートレードの詳しい情報はこちらの記事を参考にしてみてください。

やり方や「注意点」をまとめています。

2.コピートレーダーとして手数料を稼ぐ

Bitget（ビットゲット）のトレーダーはだれでも申請するだけでなることができます。また、条件を満たすとプロトレーダーとして活躍することも可能です。

報酬は自分のトレードを利用したユーザーの利益の10%を受け取る事ができます。

  • 運用に自信がある方
  • 資金効率を高めたい方

このような方にはおすすめのサービスになります。

https://3mikan.com/archives/3023

トレーダーの詳しい条件はこちらの記事を参考にしてみてください。

やり方や「注意点」をまとめています。

3.トレードせず紹介制度で稼ぐ

Bitget(ビットゲット)では、アフィリエイト制度を導入しています。

Bitget(ビットゲット)を利用したいユーザーをBitgetの代わりに集客することで、手数料の一部を稼ぐことができる仕組みです。

  • 運用に自信がない方
  • アフィリエイトの仕組みに興味がある方

このような方にはおすすめのサービスになります。

https://3mikan.com/archives/3076

アフィリエイトの詳細はこちらの記事を参考にしてみてください。

やり方や「注意点」をまとめています。

bitget(ビットゲット)出金手数料

Bitget(ビットゲット)の出金手数料は、他の取引所同様に通貨によってことなります。

最低出金額・一度の出金限度額・一日の制限額も設けられているので、こちらの詳細もBitgetのガイドラインを拝見することをおすすめします。

Bitget公式サイト（出金手数料）

現在停止されているものもありますので、取引前に確認しましょう。

bitget(ビットゲット)取引手数料

Bitget(ビットゲット)の取引手数料は、2種類あります。

  1. スポット(現物)取引の手数料
  2. 先物(レバレッジ)取引の手数料

まずはこの2つについて紹介していきます。コピトレの手数料が知りたい方は飛ばして読み進めてください。

スポット(現物)取引の手数料

Bitget(ビットゲット)の現物取引は、USDT/BTC/ETH建ての３つがあります。

USDT７通貨ペア
BTC14通貨ペア
ETH100通貨ペア以上

メイカー手数料：0.10% テイカー手数料：0.10%

基本的には、0.1%が手数料になりますが通貨のよって異なるものもいくつかあるので取引する前にBitget(ビットゲット)のガイドをご確認ください。

Bitget公式サイト（スポット手数料）

先物取引の手数料

Bitget(ビットゲット)の契約取引は、USDT契約とインバース型契約の2種類に分かれています。取り扱い通貨は、50種類ほどになっています。

メイカー手数料：0.02% テイカー手数料：0.06%

手数料は、メイカーテイカーともに全部の通貨ペアがこの手数料になっています。

Bitget公式サイト（契約手数料）
E67EA41D-3833-49F8-A461-631F05305451

2022年4月27日には、日本市場向けの契約取引手数料割引が案内されていました。現在の料率としては使用できません。

maker fee0.02%（前の手数料）▶0.017%（日本市場限定の手数料）
taker fee0.06%（前の手数料）▶0.051%（日本市場限定の手数料）

bitget(ビットゲット)コピートレードの手数料

Bitget(ビットゲット)のコピートレードは、先物取引の手数料にプラスでトレーダーに入る報酬（手数料）が発生します。

BGB購入額コピートレード手数料収益
2,000 BGB4%
4,000 BGB6%
6,000 BGB8%

このようにトレーダー側は、BGBの購入額で手数料収入が変わります。最大10%なので、自分がコピートレードする際はフォローするトレーダーを選択すると手数料がわかるので事前に確認するようにしましょう。

2022年当時の手数料割引方法

Bitget(ビットゲット)で取引する際手数料を抑える方法が2つあります。

１．スポット(現物)取引で２０%削減する手順

【最新版】bitget(ビットゲット)の手数料に注意！取引手数料・出金手数料・コピトレの手数料について解説の説明画像

Bitget(ビットゲット)のマイアカウントページで「資産」をタップします。

「BGB支払いにすると・・・」という所を☑すると削減することが可能です。

BGB支払いとは＞＞＞

Bitgetが発行している独自トークンです。

※BGBの注意点はまとめに記載しています。

２．2022年当時の初回特典（終了）

当時は登録経路に応じた体験金や手数料割引が掲載されていましたが、このページで案内していた特典は終了しています。

bi

クーポン券と体験金が両方保有している場合は先に体験金が使用されます。

【体験金】

アカウント作成後すぐに契約資産の口座から確認することができます。

【クーポン】

アカウント内にある「報酬センター」から受け取る事ができます。

bitget(ビットゲット)手数料まとめ

今回は、Bitgetの手数料についてまとめてみました。

Bitgetは、コピトレだけではなく他の方法でも収益を上げることが可能ですので自分にあわせて取り組んでみてください。

ただ個人的な意見として、現物取引を考えている方はBGBを利用することで20%削減することが可能ですが「BGBの価格は変動してしまうもの」なので注意が必要です。20%割引が受けられるだけなので、安易に購入する必要はないかなと個人的には思います。

大手取引所と比較したい場合は、下記記事を参考にしてみてください。最後まで読んでいただきありがとうございました。

https://3mikan.com/archives/2344
## 確認した一次情報 - [Bitget: Fee schedule](): 確認日 2026-08-27 - [Bitget: BGB Earn](): 確認日 2026-08-27 - [Bitget: KCGI](): 確認日 2026-08-27 --- # BingXのコピートレードとは？仕組み・手数料・主なリスクを整理 BingXの旧紹介記事を統合し、コピートレードの仕組み、利益分配や手数料、スリッページ、レバレッジ、清算など利用前に確認したいリスクを整理します。 正規URL: https://3mikan.com/archives/4690 著者: みかん 公開: 2022-03-18T18:27:42.000Z 更新: 2026-08-27T05:20:00.000Z

2026年8月27日更新: 旧記事 /archives/4787 の評判・コピートレード解説を本ページへ統合しました。本文後半の順位、手数料、対応商品、画面、キャンペーンは2022年時点の記録であり、現行条件や利用可否を保証しません。

コピートレード利用前に確認すること

  • 実績: 表示された過去の成績は将来の利益を保証しない。短期間の収益率だけでなく、最大ドローダウン、取引回数、運用期間も確認する。
  • 注文差: コピー元とフォロワーでは、約定価格、ポジション量、利用可能残高が異なる。スリッページ、遅延、注文失敗により同じ損益にならないことがある。
  • 損失: レバレッジ取引では清算を含む大きな損失があり得る。損切り、1回当たりの配分、コピー停止条件を利用前に決める。
  • 費用: 取引手数料、資金調達料、スプレッドに加えて、利益分配などコピートレード固有の条件を確認する。
  • 利用条件: 商品、機能、本人確認、提供地域、規制上の利用可否は変わるため、居住地に適用される公式条件を確認する。

2022年時点の紹介・操作記録

以下は当時のサービス画面と比較を歴史記録として保持したもので、現在の登録や取引を勧めるものではありません。

今回の記事では、海外取引所である『BingX』について紹介したいと思います。

BingXは今人気の取引所であるBitget(ビットゲット)同様にコピートレードが利用可能な取引所です。取引手数料が安価であったり、スマホ画面が操作しやすいなどといった評判があり現在の世界仮想通貨デリバティブ取引所ランキングは７位と上位に位置しています。

Bitget(ビットゲット)とのコピトレの比較や違いを交えて解説していきたいと思うので興味がある方は是非最後まで読んでみてください。

この記事から分かること
  • 仮想通貨取引所BingXについて
  • BingXの利用できる機能について
  • Bitget(ビットゲット)との比較（コピトレの違い）
  • BingXの評判と安全性
  • 2022年当時の画面とキャンペーン記録
BingXの2022年当時の案内画像

仮想通貨取引所BingX(旧:Bingbon)とは？

BingX(旧:Bingbon)の特徴・使い方を総まとめ！Bitget(ビットゲット)との比較・気になる評判と安全性についても解説します。の説明画像

BingXは、Bingbonという取引所として、2018年にオープンして、昨年の11月にブランドチェンジして、「BingX」という取引所になりました。

創設チームは大手金融機関・Google・テンセント・アリババなどの第一線のインターネットチームで構成されてます。

幅広く日本語での対応もしており、Telegram・note・Twitterに関しては日本人向けに配信をしているので情報を取りやすくなっています。

BingX(旧:Bingbon)の基本情報（概要）

BingX会社概要
業種暗号資産取引所
ライセンスアメリカ・カナダ・エストニア・オーストラリア
スマホアプリスマホ対応
取引方法先物取引・現物取引・コピートレード
レバレッジ最大125倍（通貨によって異なる）
公式YouTubeBingX Japan
公式サイトTwitterBingX Japan(日本語)
公式サイトTelegramBingX Japan

※1２の言語に対応しており日本語にも対応しています。

お問い合わせサポートはこちらです（support@bingx.com）

BingX(旧:Bingbon)の手数料について

契約取引の手数料は0.075%ですが、現在0.045%の割引がされています。

コピー取引の手数料率：0.075％（現在のコピー取引手数料率は0.0375％割引）

計算方法：取引手数料=取引量*取引手数料率

資金調達率に関しては、Bybit同様に8時間毎になっています。

永久スワップ取引手数料
テイカー0.075％
現在の手数料率は0.040％として割引
メーカー0.045％
現在の手数料率は0.020％として割引

現物取引の手数料に関しては、こちらを参考にしてください。https://bingx.com/en-us/spot/fees/

外貨両替手数料は、0.2%になります。

通貨出金手数料
USDT-ERC2020 USDT
USDT-TRC201 USDT
USDT-OMNI28 USDT
USDC20 USDT
BTC0.0005 BTC
ETH0.007 ETH
XRP0.25 XRP

各通貨のスプレッドが気になる方は、こちらを参考にしてください。

https://support.bingx.com/hc/en-001/articles/360027240173

BingX(旧:Bingbon)の主な機能

BingXで利用可能な機能を紹介します。

  • 法定通貨での仮想通貨購入
  • 両替（OTC）
  • 現物取引
  • グリッド取引ボット
  • 契約取引
  • プロ版契約取引
  • コピー注文

これら７つの機能をBingXでは利用することが可能です。

グリッド取引ボットとは

グリッド取引ボットとは＞＞＞

ユーザーは通貨を選択するだけで、ロボットは価格が下がると購入し、価格が上がると販売します。

７つの機能の中でも、あまり聞き馴染みがないのがグリッド取引だと思います。

これは特定の価格帯で自動的に下限価格（グリッド設定最低金額）で買い、上限価格（グリッド設定最高金額）で売ることができる取引戦略方法になります。不安定な暗号資産市場では、アービトラージロボットを使用することで、人的要因によって引き起こされる誤った取引を大幅に回避できます。アービトラージロボットは、利用者が設定した最低金額で購入、最高価格で販売という取引戦略を厳密に実装してサポートしてくれます。

Bitget(ビットゲット)とBingX(旧:Bingbon)のコピトレ違い

BingX(旧:Bingbon)の特徴・使い方を総まとめ！Bitget(ビットゲット)との比較・気になる評判と安全性についても解説します。の説明画像

BingXのコピートレードの取引画面はこのようになっています。

BingX(旧:Bingbon)の特徴・使い方を総まとめ！Bitget(ビットゲット)との比較・気になる評判と安全性についても解説します。の説明画像

トレーダーを選択するとこのようにコピートレーダーの情報が表示されます。

BingX(旧:Bingbon)の特徴・使い方を総まとめ！Bitget(ビットゲット)との比較・気になる評判と安全性についても解説します。の説明画像

Bitgetとの違い＞＞＞

  • 資産を必ず見ることができる。
    （Bitgetは非表示設定ができ基本的に見れなくしている人が多い）
  • フォロワーの上限が多い。
  • 累計の損益が分かる。
  • 最大ドローダウンが分かる。

取引履歴やフォロワーに関しては似ていますが、Bitgetでは分からない情報も多くあり収益データはグラフで表示されています。

個人的に総資産を必ず見ることができるという点が嬉しいなと思いました！収益のパーセントだけでなく本人が入れている資金や出している利益の絶対量を確認することはトレーダーを選ぶ上で重要な点だと思っています。

BingX(旧:Bingbon)の特徴・使い方を総まとめ！Bitget(ビットゲット)との比較・気になる評判と安全性についても解説します。の説明画像

BingXではBinanceとAPIで繋いでトレードすることができます。

APIアクセス機能はコピートレーダーのみ利用することが可能で、コピートレーダーにもよりますが上記画像のようにバイナンスと接続し運用することが可能です。

この外部プラットフォームからのコピー取引は、Binance(バイナンス)で注文が処理されるので利用したい場合はBinance(バイナンス)の開設が必要です。

BingX(旧:Bingbon)の評判と安全性

BingX(旧:Bingbon)の特徴・使い方を総まとめ！Bitget(ビットゲット)との比較・気になる評判と安全性についても解説します。の説明画像

BingXは4年近くの歴史はありますが、これまでセキュリティブリーチ報告は一度もありません。これが安全性を証明するものではありませんが一つ安心材料ではあります。

また、ライセンスをアメリカ・カナダ・エストニア・オーストラリアの４つの国で取得しております。

BingX(旧:Bingbon)の口コミ

mikan_gra
BingXユーザー

待って、BingXって、ドル円とかゴールドも出来んの！？！？w これはクソアチーーーw

mikan_gra
BingXユーザー

今日はBingXのコピトレの方には結構大きな利益生まれた気がする！

mikan_gra
BingXユーザー

BingXはコピーがスムーズです！通貨ペアも多い

mikan_gra
BingXユーザー

BingXでUさんに稼いでもらった！感謝！そして凄い！！！

口コミからも、BingXはコピートレードをメインに利用されている方が多い印象です！

BingX(旧:Bingbon)の使い方・登録方法

BingX(旧:Bingbon)の特徴・使い方を総まとめ！Bitget(ビットゲット)との比較・気になる評判と安全性についても解説します。の説明画像

当時の口座開設画面を以下に記録しています。現行の登録手順と利用条件は公式サイトで確認してください。

BingXの2022年当時の登録案内画像

こちらのボタンをクリックし情報の入力を行います。

BingX(旧:Bingbon)の特徴・使い方を総まとめ！Bitget(ビットゲット)との比較・気になる評判と安全性についても解説します。の説明画像

メールアドレスまたは、電話番号で登録することができます。

  • アドレス
  • パスワード

この2つを入力し『次のステップ』をクリックすると認証コードの入力を求められます。

BingX(旧:Bingbon)の特徴・使い方を総まとめ！Bitget(ビットゲット)との比較・気になる評判と安全性についても解説します。の説明画像

入力が完了したら『登録』をクリックし以上でBingXの口座が開設されました。

冒頭にあるように簡単な手続きで始める事ができます！

BingX(旧:Bingbon)の特徴・使い方を総まとめ！Bitget(ビットゲット)との比較・気になる評判と安全性についても解説します。の説明画像

BingX(旧:Bingbon)の2022年当時のキャンペーン

BingX(旧:Bingbon)の特徴・使い方を総まとめ！Bitget(ビットゲット)との比較・気になる評判と安全性についても解説します。の説明画像

当時は賞金総額50万円と案内されたコンペが開催されていました。

BingX(旧:Bingbon)の特徴・使い方を総まとめ！Bitget(ビットゲット)との比較・気になる評判と安全性についても解説します。の説明画像

ランキングの報酬はこのようになっております。

BingX(旧:Bingbon)の特徴・使い方を総まとめ！Bitget(ビットゲット)との比較・気になる評判と安全性についても解説します。の説明画像

当時は新規登録者向けのタスク報酬も案内されていました。いずれも終了済みとして扱い、現在の取引判断には使用しないでください。

BingX(旧:Bingbon)のまとめ

今回はBingXについて紹介しました。

コピー注文に関しては、Binance(バイナンス)とのAPI機能の連携ができる点が魅力あるサービスだと感じました。

コピー注文を行う際に、一つこのBinanceのAPI機能を利用している人を基準で選ぶのもいいかと思います。質の高いトレーダーという判断材料になりそうです。

BingX(旧:Bingbon)の特徴・使い方を総まとめ！Bitget(ビットゲット)との比較・気になる評判と安全性についても解説します。の説明画像

また、クレジットカードからであれば日本円での購入も可能で簡単に通貨の購入が行えます。

掲載していた2022年3月の特典は終了しています。現在のキャンペーンを前提に判断せず、取引する場合は公式の最新条件とリスク説明を確認してください。

## 確認した一次情報 - [BingX: Copy Trading User Agreement](): 確認日 2026-08-27 --- # BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】 今回の記事では、仮想通貨取引所の一つである『BTCC』について解説していきたいと思います。 BTCCは中国で初のビットコイン取引所になり、中国国内の顧客を中心に拡大を広げてきた取引所になります。BTCCの魅力は様々ありますが、多くある仮想通貨取引所の中でも手数料が低いのも魅力の一つです。 また、追証なしのゼ… 正規URL: https://3mikan.com/archives/4414 著者: みかん 公開: 2022-01-17T16:55:15.000Z 更新: 2022-04-03T09:14:06.000Z

今回の記事では、仮想通貨取引所の一つである『BTCC』について解説していきたいと思います。

BTCCは中国で初のビットコイン取引所になり、中国国内の顧客を中心に拡大を広げてきた取引所になります。BTCCの魅力は様々ありますが、多くある仮想通貨取引所の中でも手数料が低いのも魅力の一つです。

また、追証なしのゼロカットシステムを導入しているので口座がマイナスになることがないデリバティブ取引所になります。海外の取引所に興味がある方やBTCCのデモ取引で必ず受け取れる100万円を利用して先物取引を初めて見たい方は是非最後まで読んでみてください。

【無料】ここからお得にBTCCに参加することができます！

【注意喚起】"BTCC"と"BTCC-FX"は別物

BTCCを取り組む前に口コミを調査してみると、『BTCCで投資詐欺に会いました』『BTCCは出金できない』など良くない評判がちらほら、、、、。皆さんも注意してほしいです。

"BTCC"と"BTCC-FX"は別物です。

でもどうやって詐欺じゃないと判断するの？という点ですが『ドメイン』を確認してください。

  • BTCCの公式サイトドメインは『btcc.com』
  • 取引画面のドメインは『trade.btcc.com』

これ以外のドメインは詐欺ですのでご注意ください！

仮想通貨取引所BTCCとは？

BTCCは世界で最も古い取引所で、仮想通貨無期限契約を初めて開始した取引所でもあります。

2011年に設立しましたが、翌年2012年には登録ユーザーが8000人にもなり世界2位の取引量を記録したこともあります。こんなにも歴史がある取引所ではありますが、日本には2020年に参入してきたのであまり日本国内では聞き馴染みがない取引所かもしれません。

急激な市場の変動の際はマイナス残高をカバーしユーザーの利益を保証ということで、追証なしのゼロカットシステムを導入しており、安心したトレードが行えそうです。では早速会社のより詳しい概要・特徴・ボーナス・使い方について紹介していきたいと思います。

BTCCの基本情報

BTCC会社概要
拠点ロンドン・イギリス
業種ビットコイン取引所
スマホアプリスマホ対応
取引方法先物取引
レバレッジ最大20・50・100・150倍（通貨によって異なる）
取り扱い通貨数無期限契約：9種類
週間契約：14種類
一日契約：2種類
公式YouTubeBTCC Official
公式サイトTwitter@YourBTCC (英語語)
＠BTCC_JP （日本語）
公式サイトInstagrambtccbitcoin
公式LINEBTCCお問い合わせ

※日本語／ベトナム語／簡体字中国語／繁体字中国語／英語／韓国語に対応しています。

最新情報：LUNA/SOLを含む４つの銘柄が上場

2022年1月18日より４つの銘柄がBTCCに上場しました。

LUNA・MANA・SOL・AVAX

上場した銘柄は上記4つです。

BTCCの４つの特徴

BTCCの特徴は大きく4つです。

  • コーヒー１杯分の資金からはじめられる
  • 24時間対応のカスタマーサービス
  • デモ取引で100万円分が使える
  • 手数料が低い

①コーヒー１杯分の資金からはじめられる

最小10USDTからの取引が可能です。

また、主要通貨のBTC・ETHのUSDT建てペアを含め19個の通貨に関しては150倍のレバレッジを利用することができるので資金効率を上げた運用ができます。また、無料ボーナスキャンペーンなどこの後に説明しているいくつかのキャンペーンを利用することで更にお得に取引が行えそうです。

②24時間対応のカスタマーサービス

カスタマーサービスが24時間対応していることで、自分の好きな時間に問い合わせることができます。

日本の場合は、オンラインチャット・メール・LINEの3つに対応しています。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

個人的に一番LINEが楽だと思い追加してみたらとても使いやすいと感じました。追加画面はこのようになっていますBTCCの公式LINEはこちらです。▶BTCCお問い合わせ

③デモ取引で100万円分が使える

BTCCでは、『デモ取引』を行うことが可能です。

新規ユーザーは初回ログイン時にバーチャルマネーを10,000USDT分無料で受け取ることができます。初めて取引をする場合は、このデモ取引を利用し使い方を慣れるという点においても魅力的な機能です。

④手数料が低い

各手数料を表にて確認してください。

入出金手数料

コイン入金手数料出金手数料
BTC０0.0004 BTC
ETH０0.005 ETH
XRP０1 XRP
USDT−ERC20０20 USDT
USDT−OMNI０10 USDT
USDT−TRC20０2 USDT
※最低出金額／最低入金額があります。

取引手数料

口座VIPレベル口座資金（USDT）コイン交換手数料契約取引手数料
VIP0（スタート）≥ 00.12%0.045%
VIP1≥１０ 00.12%0.04% 11%オフ
VIP２≥５0000.12%0.035% 22%オフ
VIP３≥５00000.12%0.03% 33%オフ
※VIPの条件に満たす際、オンラインサポートまでアップグレードの主旨を連絡する必要がある

BTCCのキャンペーン・ボーナス

14597814179746_0

BTCCでは定期的にキャンペーンを実施しています！

現在開催されているキャンペーン・ボーナスを紹介しますので是非お得に初めてみてください。

【無料】ここからお得にBTCCに参加することができます！

①毎日当たる宝くじ

一等賞は、１BTC/１ETH/が当たる？？

キャンペーン期間中、毎日01:00:00（日本時間）より、宝箱のカウントダウンが終了するたびに、アプリで1回宝くじを引くことができます。1日最大3回の抽選が可能です。未使用の抽選チャンスは、毎日の01:00:00（日本時間）に自動的に無効になります。一等は1BTC（約500万円相当）を獲得できます！

BTCC

②入金ボーナス

キャンペーン期間中条件を満たした場合10USDTがゲット！！

キャンペーン期間中に、次の条件のいずれかを満たすと10USDT を獲得できます。

BTCの入金額 ≧0.003BTC　
ETHの入金額≧0.04ETH　
XRPの入金額≧100XRP　
USDT、日本円の入金額≧100USDT

BTCC

また現在最大14000USDTをゲットできる入金ボーナスキャンペーンが開催中です。

定期的にボーナスが更新されているので、SNSからお得な情報をGetするのがおすすめです。

③キャッシュバック

取引でキャッシュバックゲット！

開催概要：キャンペーン期間中に取引を行う全ユーザーは、取引の翌営業日の24時間以内に15％の手数料が還元され、最大500USDTを獲得するができます。

BTCC

仮想通貨取引所BTCCの評判・安全性

BTCCは、資産を守るために複数のリスクコントロールを備えた独自の取引システムを構築しています。資産はマルチシグのコールドウォレットで保管され、極端な市場環境下でもプラットフォームの安定性を確保できるようになっています。

また2011年の設立からこの10年間一度もセキュリティ事故を起こすことなく運営ができているという実績がありますが評判や安全性について深堀りしていきたいと思います。

BTCCの取引高・ユーザー数

2011年に設立されたBTCCは、世界でも長い歴史を持つ仮想通貨取引所です。 現在、全世界で100万人以上の登録ユーザーに利用され、100以上の国と地域にサービスを提供しています。

  • 累計成約額　　　　：14,000,000,000
  • 会員登録ユーザー　：900,000
  • 取引人数　　　　　：430,000
  • 有効成約人数　　　：8,000,000
  • 一日あたりの取引量：1,000,000,000
  • 提携機関　　　　　：１00

※ホームページ参照データ

2021年の実績として、累計の取引高1,109,500,000,000USDT／1日の取引高34,100,000,000USDTを記録しています。

BTCCの使いやすさ

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

BTCCは、パソコン／スマホ共にアプリを活用することが可能で評価数と星の評価も高そうです。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

個人的には、パソコンでの操作が使いやすいと感じました。スマホ版アプリがあることで外出先でも、安心してトレードすることができます。

仮想通貨取引所BTCCの登録方法・使い方

BTCCは、有期契約と無期限契約の両方を提供しています。

期間契約は、限日契約と限週契約に分かれ実際の使い方や運用にあたるまでの事前準備について操作方法を解説していきたいと思います。

BTCCの登録手順

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

BTCC登録サイトからログインし、画面右上にある『会員登録』から登録に進む事ができます。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

『電話／メールアドレス』どちらか自分の好きな方で行います。

入力後『送信』をタップし認証コードを受け取りコピーして貼り付けてください。６以上の英数字のパスワードを入力し『会員登録』ボタンをタップし完了です。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

携帯番号を求められますが、登録しなくても『スキップ』し次に進むことは可能です。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

ここからの作業ですが、日本円での取引がしたい場合／24時間の出金限度額を上げたい場合は本人登録が必要です。しなくても大丈夫な場合は、画面右上の『戻る』ボタンでトレード画面が表示されます。※後からでも可能なので必要な場合本人登録を行う形もでもいいと思います。

顔認証登録は、すべてを埋めて次へ進みます。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

本人確認書類の選択をし『次へ』進みます。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

『運転免許書』を選択した場合、このようになります。

携帯のデータがあり携帯から操作したい場合や、これから写真をとってアップロードする場合は『お使いの携帯電話でドキュメントをアップロードする』をタップしてください。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

QRコードまたは、URLから写真のアップロードをします。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

後は、審査を待ちます。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

私の場合4時間ほど待つと口座開設の連絡が登録したメールアドレスにきました。以上がBTCCの登録手順です。登録自体は1分ほどで最初の項目だけで済みますが、本人登録までは時間がかかりそうです。

BTCCの入金方法

BTCCの入金方法は2つあります。

他の取引所からの送金かクレカによる日本円での購入です。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

『資産』をタップし『チャージ』を選択します。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

『入金』を選択し『通貨・チェーン』を選びます。この後の手順は他の取引所同様です。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

クレカによる購入の場合、『OTCコイン購入』をタップ『VISA／Master』の2種類を利用することができます。

BTCCの出金方法

入金同様に『資産』をタップし入金の隣にある『出金』を選択します。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

内容を確認したら、『出金を確認する』をタップし完了です。

入金・出金共に条件がありますので、資産を動かす前にここの内容をガイドラインで確認することをおすすめします。こちら▶BTCCヘルプセンター『入金・出金』について

BTCCのデモ取引やり方

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

アカウントにログイン後右上にある『リアル取引』をタップし『デモ取引』を選択します。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

切り替えると自分の運用可能資産が表示されています。

『初回ユーザー』は100万円分の運用資金をもらうことができるので是非これを利用しデモ取引からまずは始めてみることをおすすめします。

BTCC契約取引のやり方

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

BTCCで行える取引は3種類です。

限日契約とは＞＞＞毎日6:00〜8:00(日本時間)以外で取引が可能です。この時間は清算時間の為この時間に入る前に決済を終わらせる必要があります。期限が過ぎた場合は、自動決済される仕組みなので注意が必要です。

また、現在BTC・ETHが対応していますがレバレッジは最大の150倍が固定になります。

限週契約とは＞＞＞毎週日曜日の6:00〜8:00(日本時間)以外で取引が可能です。

現在1９の通貨が対応していますが、BTC／ETH以外は50倍のレバレッジが固定になっています。BTC／ETHは10倍・20倍・50倍・100倍を選択することができます。

無期限契約とは＞＞＞名前の通り期限がないのでいつでも取引可能です。

現在９の通貨が対応しており、レバレッジについては各通貨によって利用できる幅が決められているので利用する前にご確認ください。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

画面の操作方法は、右側で注文内容を指定することができます。

中央上ではローソク足の日時の指定や設定マークからスタイル／スケール／背景／タイムゾーンの設定が細かく行えます。

  1. 注文方法：成行／指値／逆指値から選択
  2. レバレッジの指定：通貨によって選択範囲は異なる
  3. 数量の指定
  4. 損切り／利食いの設定
  5. 売りを選択していた場合は『売り』をタップ

以上の入力項目でポジションを持つことができます。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

注文を出すとこのようになるので、『分かりました』を選択します。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

利確する場合は、『建玉』から決済をタップします。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

内容が良ければ、『決済を確認する』をタップしクローズします。

BTCC仮想通貨取引所の評判とは？他社比較・アプリの使い方・ボーナスのまとめ！安全性について徹底解説します！【2022年最新版】の説明画像

『分かりました』をタップしてポジションの決済は終了です。

仮想通貨取引所BTCCの評判まとめ

今回の記事では、BTCCの概要から特徴・ボーナス・使い方と幅広く解説しました。

個人的に使ってみての感想ですが、Bybit・Binanceと比べるとアプリの操作画面がシンプルで利用のしやすさはありました。しかし、レバレッジの固定が細かくできない点や通貨の種類が少ないという懸念点はあります。

ただ、あまり他の取引所でない『デモ取引』は非常に魅力的だと思います。100万円分のバーチャルマネーを利用し『リアル取引』同様の運用が行えるので初心者の方には仮想通貨先物取引の体験としておすすめです。

また、冒頭で説明したBTCCとBTCCFXですが別物ですので、利用する際や周りでBTCCの話題が出た際は詐欺サイトではないかこの記事を読んだ方は確認してほしいです。

利用する際はガイドラインを確認し利用してください。引き続きBTCCの進展を追っていきたいと思います。最後まで読んでいただきありがとうございました。

【無料】ここからお得にBTCCに参加することができます！

--- # 【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。 今回は、Fantom Network(ファントムネットワーク)のVaultsサービスである、『Supra Vaults』について解説していきます。 この記事では大きく３つに分けて、Supra vaultsについて解説していきます。まずそもそもVaults(ボルツ)が何なのか？わからない方もいると思うので、ま… 正規URL: https://3mikan.com/archives/958 著者: みかん 公開: 2021-05-15T21:03:59.000Z 更新: 2022-04-01T13:37:19.000Z

今回は、Fantom Network(ファントムネットワーク)のVaultsサービスである、『Supra Vaults』について解説していきます。

この記事では大きく３つに分けて、Supra vaultsについて解説していきます。まずそもそもVaults(ボルツ)が何なのか？わからない方もいると思うので、まずはそこから解説していきます。すでに知ってるよという方は飛ばして読んでいただいて大丈夫です。

仮想通貨は利率の変動が激しいこともあり、自力で運用するとなると全てのサービスをチェックしなければならないですよね。LPを組み直したり自分でCompoundボタンを押したりと、何かと面倒な作業があったりどのサービスを選べばいいのか分からない人も多いと思います。

そんな悩みがある方は是非この記事が参考になると嬉しいです。

Vaults(ボルツ)とは？

Vaultsとは「自動で仮想通貨の運用をしてくれるサービス」になります。

Vaultsの特徴５つ
  1. compoundが一回で済む！
  2. 運用先ファームは決まっている！
  3. 複利マンは、仕組みのみの提供で元手不要！
  4. 独自トークンを報酬で出すケースが多い！
  5. ファーム側は、TVLが増える！

簡単に特徴をまとめるとこの５つが挙げられます。

Vaultsができるサービスは多くあり、すべて自動で運用しくれるので簡単に複利効果を得ることができますが内容やリスクも異なるので利用する際は注意が必要です。

サービス例)Beefy finance, Autofarm, swamp finance, bearnなどあります。

複利(Compound)の自動化って何？

複利の自動化が具体的にどういうことなのか？画像を元に解説します。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

これはSPIRIT-FTMのLPです。画像の赤枠部分を見て欲しいのですが「Daily」のところに「2.120%」と表示してあります。これはLPを作り流動性を提供することで、1日 2.120%の利率で増えていくことを表しています。

そして「APY」は年利の表示になります。これは年間を通すと21万％に増えるという表示です。毎日預けることでどんどん複利が膨らんでいくということです。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

ただ、この複利を得るためにはこの画像にもあるように、まずはSPIRITのサイトを開いて『LPを組んで預ける』ことが必要です。預けて収穫してLPを組み直す、預けて収穫してLPを組み直すという作業を毎日やることになります。

正直この作業を毎日やるとなるとかなり面倒です。

この面倒な手間を代わりにやってくれるのがVaults(ボルツ)というサービスになります。

株式投資で言うところの投資信託みたいなものです。

そして今回紹介するSupraVaults(スプラボルツ)というVaultsサービスは、Binance smart chain(バイナンス スマートチェーン)で言うところの、Beefy finance, Autofarm, swamp finance, bearnと同じものです。

ちなみに、SupraVaults(スプラボルツ)もBinance smart chain(バイナンス スマートチェーン)に一部対応しています。「Binance smart chain(バイナンス スマートチェーン)用のVaultsもある」ということです。

SupraVaults(スプラボルツ)の使い方

使い方は簡単です。まずはLPを組んで預けるか、単体で預けるかを決めます。

LPを作る

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

まずはSPIRITのサイトを開いて「SPIRIT」を購入します。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

左上にある「Trade」をタップして「Exchange」をタップします。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

次にどの通貨でSPIRITを購入するのか「Select a currency」をタップして選択します。

ちなみに今回はFTMで購入します。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

通貨を選択したら、数量を選択します。

この時どちらか一方の数量を入力すると自動でもう片方も計算して表示されます。表示された数量を確認して問題なければ「swap」ボタンをタップします。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

「Confirm swap」をタップします。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

右側に表示された画面の「確認」をタップします。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

「Close」をタップします。これでLPの作成が完了しました。

預け入れる

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

再びSupra Vaultsのページを開きます。

SPIRITの右側に「APPROVE」ボタンが表示されるのでタップします。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

右側に表示された画面の「確認」をタップします。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

すると「Deposit」ボタンが表示されるのでタップします。

（この時、Depositボタンが表示されるまでに数秒ほどかかる場合があります。）

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

次に数量を入力します。

右下にある「Deposit All」をタップすれば全額Depositすることができます。今回は全額Depositします。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

Depositが完了すると「WITHDRAW」と表示されます。(表示されるまでに数十秒ほどかかる場合があります。)

これでDepositが完了しました。左側のDepositの数字も反映されています。あとは放置で大丈夫です。これで操作完了です。

Vaults(ボルツ)から引き出す

続いて、引き出したい時の解説をします。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

引き出したい時は「WITHDRAW」をタップします。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

続いて数量を入力します。

全額引き出したい場合は「WITHDRAW ALL」をタップします。今回は全額WITHDRAWします。

ちなみに、左上に表示されている「Withdraw fee」は引き出し手数料になります。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

数量を確認して、「WITHDRAW ALL」または「WITHDRAW」をタップしたら、右側に表示された画面の「確認」をタップします。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

右側に緑色で「Deposit」ボタンが表示されたら引き出し完了です。

今回は全額引き出したので、左側の「Deposit」の数量も０になっています。

SupraVault(スプラボルツ)の仕組み

SupraVaults(スプラボルツ)の使い方について説明してきましたが、このSupraVaultsがどのように運営されているのかその仕組みについて解説していきます。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

例えば、画面の大きい赤枠のようにLPを組んで預けていますが、botが勝手に「COMPOUND」してくれます。その一連の流れがどこのページから確認できるかというと画面左上にある「Workers」から確認できます。

【DeFi仕組み】SupraFinanceの紹介！Vaultsとは・使い方・仕組みを解説します。の説明画像

Workersのページを開くと、たくさんのCOMPOUNDボタンが並んでいます。このボタンをbotが自動で押してくれる。という仕組みです。

このCOMPOUNDボタンは、私たち一般ユーザーが押すこともできます。その際は、私たち一般ユーザーがガス代を払うことで、全員のCOMPOUNDが可能になり、その代わりに報酬の一部がもらえるという仕組みとなりす。

SUPRAの運営としては、自分のガス代を払わずに一般ユーザーがガス代を払ってCOMPOUNDしてくれるのでサービスの利便性が高まるという利点があります。

また、COMPOUNDを押しているユーザーにとってはReward(報酬)がもらえるという利点があります。

以上がSupraVaults(スプラボルツ)の仕組みになります。

まとめ

FantomNetworkは後から出てきたネットワークですが、今回紹介したSUPRAはVaultsサービスが利用できるので、気になる方は試しに利用してみてください。

また、FantomNetworkをしている方で、もしVaultsで運用した方が楽そうだなと感じるのであれば、試しに利用してみるのをお勧めします。

それでは今回はこれで終わります。最後まで読んでいただきありがとうございました。

https://3mikan.com/archives/738
--- # 【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。 今回の記事では、仮想通貨取引所の一つであるBingX(旧:Bingbon)の『コピートレード』について解説していきます。 コピートレードは、プロのトレーダーさんの取引をコピーし簡単に同じ運用をすることが可能です。チャートに張り付くことをしなくてもいいので、初心者の方でも気軽に取引することができます。 コピー… 正規URL: https://3mikan.com/archives/4755 著者: みかん 公開: 2022-03-20T14:20:18.000Z 更新: 2022-03-27T14:58:20.000Z

今回の記事では、仮想通貨取引所の一つであるBingX(旧:Bingbon)の『コピートレード』について解説していきます。

コピートレードは、プロのトレーダーさんの取引をコピーし簡単に同じ運用をすることが可能です。チャートに張り付くことをしなくてもいいので、初心者の方でも気軽に取引することができます。

コピートレードには様々なメリットがあり、実際に100万円の資金を数千万にした方や数十万・数万の担保から利益を出した方も多くいます。しかし、リスクもありますので色々調べた上で参加されるのがいいでしょう。

この記事では、BingX(旧:Bingbon)を使った『コピートレード』について深堀りしていきたいと思いますので是非最後のお得なキャンペーンまで読んでみてください。

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

【無料】BingX期間内のアカウント開設で500USDTゲット！ここだけの特典！

BingX(旧:Bingbon)のコピートレードとは？

BingX(旧:Bingbon)は2018年設立の現物／デリバティブ両方の取引を提供する海外取引所です。

仮想通貨のみならず、為替やCFD、商品先物などさまざまな金融取引を扱っており他の取引所と差別化を図っています。

海外取引所でありながら日本語にも対応しているため、日本人でもかんたんに使い始めることができます。

また、追証(預入金以上の損失時、追加の証拠金の要求すること)がないため、借金をする心配もありません。

さらに、BingX(旧:Bingbon)は有名トレーダーをフォローしてコピートレードができる機能を提供し、取引におけるSNS「ソーシャル取引プラットフォーム」をテーマに掲げています。

今回はこの『コピートレード』について深堀りしていきたいと思います。

BingX(旧:Bingbon)コピトレのメリット・良い点

BingXには、扱いやすいスマホアプリや独特のトレード法など利用してみたいコンテンツがあります。

  1. 最大レバレッジは150倍
  2. 初心者でも有名トレーダーのコピートレードが可能
  3. 日本語に対応している

BingXのメリットは主にこの3つになります。

最大レバレッジは150倍

BingX(旧:Bingbon)は海外取引所なので、国内の取引所のようにレバレッジ2倍までといった規制がありません。

そのため、主要ペアのBTC/USDTはレバレッジ150倍、ETH/USDTは100倍など、高いレバレッジを利用することができます。

レバレッジは通貨ペアによって変わりますが、それでも数十倍のレバレッジをかけることが可能です。

証拠金が少なくても大きなリターンを狙うことができるので、投資資金が少ない人にはうれしいですね。

初心者でも有名トレーダーのコピートレードが可能

BingX(旧:Bingbon)は他のトレーダーをSNSのようにフォローする機能を提供しています。

フォローすることで、そのトレーダーの取引をコピーし自動で行ってくれるようになります。

特に初心者の人はこの機能を活用することで、トレード経験がなくても効率的に収益を伸ばせる可能性があります。

また、コピートレードを利用することで有名トレーダーのエントリーポイントが見れるため、トレードの勉強にもなるでしょう。

日本語に対応している

BingX(旧:Bingbon)は海外に拠点を持つ取引所ですが、日本語のWebページ、スマホアプリ、チャットサポートに対応しています。

また、ツイッターアカウントをフォローすることでキャンペーン情報や相場の状況などを日本語で見ることができます。

公式YouTubeBingX Japan
公式サイトTwitterBingX Japan(日本語)
公式サイトTelegramBingX Japan

※日本語をはじめ1２の言語に対応しております。

お問い合わせサポートはこちらです（support@bingx.com）

【無料】BingX期間内のアカウント開設で500USDTゲット！ここだけの特典！

BingX(旧:Bingbon)コピトレのデメリット・リスク

まだ利用したことがない方はどのようなデメリットがあるのか、という部分が気になると思います。

  1. ユーザ数の増加ともない、コピートレードで稼ぎにくくなっている
  2. いつの間にか損失が増えてることもある
  3. 利用したいトレーダーを利用できるとは限らない

BingXのデメリットは主にこの3つになります。

ユーザ数の増加ともない、コピートレードで稼ぎにくくなっている

BingX(旧:Bingbon)はかなり使いやすいですが、人気のトレーダーはフォロワーが多くなると証拠金が分散されてしまうので低額でしかコピトレが出来ないようです。

大きく稼ぐためには他のトレーダーまたは他サービスに移らないといけない可能性があります。

人気のトレーダーをリサーチしながらも、少しフォロワーが少ないはじめたばかりで実績がありそうな人を選ぶのもいいかもしれません。

いつの間にか損失が増えてることもある

コピートレードでは、そのトレーダーのトレードをすべてコピーします。

もちろん損失をだしている場合もコピーされます。

そのため、トレーダーが調子が悪くなってしまった場合は損失が膨らんでしまう可能性もあります。

短期の利益率だけでなく、30日90日など長期の収益データを参考にしながらトレーダーの波を確認することをおすすめします。

過去の暴落時期の運用成績なども確認できるといいですね。あとは、投稿という所からトレーダーさんのSNS情報をチェックすることができるのでその雰囲気などで判断するのもおすすめです。

利用したいトレーダーを利用できるとは限らない

Bitget（ビットゲット）同様、トレーダーの実績によってフォロワーの数に上限があります。

自分がコピーしたかったトレーダーさんが満員でフォローができない場合があります。

たくさんのトレーダーがいますので、他のトレーダーさんを探すか空きがでるのを待つかの2択になります。

BingX(旧:Bingbon)コピトレのやり方

それでは実際の画面を見ながら契約取引の手順を追っていきます。

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

ホーム画面から『コピー注文』をタップする。

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

トレーダーリストが表示されるので、検索やフィルターを利用しながら運用したいトレーダーを選びます。

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

トレーダーを選択するとこのように情報がでてきます。

下に行くと過去の運用データがグラフで表示されていますので、自分が確認したいポイントをチェックしてください。

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

問題なければユーザー名の横にある『コピー注文』をクリックしてください。

BingX(旧:Bingbon)コピトレ設定方法

ここからは注文の設定方法になります。

１-1

これらの設定をしたのち、問題なければ『今すぐコピー注文』をクリックし終了です。

詳細設定の内容について

上記２つが注文の設定内容ですが、左側にある画像は詳細設定になります。設定しない場合『無制限』になっていますので注意が必要です。

  1. １日の元本
    例：この設定を100USDTにしたとします。

    最初のコピー注文で40USDT・2番目のコピーで60USDT使った場合合計が100に達した為3番目の注文が実行されません。
  2. 最大ポジション金額
    例：この設定を100USDTにしたとします。

    最初の注文ポジションで100USDT使い現在も保有しているとします。この場合2番目の注文が実行されません。
  3. 注文の損切り率
    例：80に設定したとします。

    市場価格が急変し損失が80%に達した場合損切り機能が実行されます。

上記すべての項目を入力しなくてもコピー注文は行うことができますが、詳細設定の３つはリスク管理として設定しておくことをおすすめします。

BingX(旧:Bingbon)コピトレ収益確認方法

コピー注文管理画面で収益を確認することができます。

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

今回私はVSTを利用しBingXのコピー注文を実際にやってみました。

VSTについてはこのあと説明したいと思います。最初の登録で全ユーザーがもらえるので是非VSTを利用してコピートレードの流れを掴む事をおすすめします！Bitget（ビットゲット）の場合体験金は契約取引でしか利用できないので、このコピートレードでも利用できるのはかなりラッキーですね。

【無料】BingX期間内のアカウント開設で500USDTゲット！ここだけの特典！

BingX(旧:Bingbon)おすすめトレーダーの選び方

コピートレードで重要なのは、トレーダー選びです。

「どのトレーダーをフォローするか？」を決めるうえで大事なポイントは下記の2つです。

  1. 30日間収益率
  2. フォロワー数

ポイント①：30日間収益率

コピー注文ページでは、7日・30日・90日の収益率を確認することができます。

この中の30日の収益がポイントだと思っています。30日を目安にすることでトレーダーがいかにUSDTを流通させ有益なトレードを行っているのかがわかります。

これらのトレーダーが動かしているのは自己資金のため、30日間の収益額が大きいとそれだけ信用ができるということになります。

初心者の方は、勝率を意識してしまいがちですが勝率だけだと莫大な含み損を抱えているポジションを放置しているトレーダーもいるため注意が必要です。

30日間収益率収益率が高い＝長期的に安定して稼いでいる目安になります。

なので、合計収益率が高いトレーダーを選ぶのがベターです！

ポイント②：フォロワー数

フォロワー数は、そのトレーダーの人気を示しています。

当然多い方が評判良く、優秀なトレーダーということが分かります！

コピートレードでは「稼いでいるトレーダー = 人気」となるため、フォロワー数が多いトレーダーほど人気が高くおすすめです。

ただ、デメリットでもお伝えしたようにフォロワーが多くなると証拠金が分散されてしまうのでトレーダー選びは慎重に行いましょう。

BingX(旧:Bingbon)VSTの使い方

BingXの新規登録ユーザーは自動的に100,000VSTがもらえます。

VST（Virtual USDT）とは＞＞＞

BingX公式プラットフォーム模擬金（価値なし、出金不可）であり、シミュレーションディスク操作トレーニングや機能体験として利用することができます。

体験金を発行している取引所は多くありますが、BingXの場合契約取引だけでなくコピートレードにも利用することができます。

BingX(旧:Bingbon)VSTの受け取り方

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

VSTは自分のウォレットの『標準版契約口座』で確認することができます。

BingX(旧:Bingbon)VSTの振替方法

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

振替画面をタップするとこのような表示がされます。

通貨の選択を行い資金口座またはプロ版契約口座に『振替』することができます。

BingX(旧:Bingbon)VSTで契約取引のやり方

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

画面上の『契約取引』をタップするとこのように表示されます。

デフォルトだと『USDTアカウント』になっていますので、そちらから『VSTアカウント』をタップします。

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

VSTのアカウント表記もUSDTアカウント同様になっています。

１．銘柄の選択

左側の銘柄をタップで自分が運用したい銘柄に変更することができます。

BTC/USDTなど主要ペアの場合、ホーム画面から直接選択できるようになっています。

ホーム画面にない取引ペアを選択したい場合は、画面下部中央の”契約”を選択しましょう。

※日経平均株価をトレードする場合は”契約”から『JAPAN』と検索し”JAPAN225″を選択します。

マージンモードの切り替え

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

マージンモードの切り替えは画面右側より行うことができます。

説明は省略しますが、よくあるレバレッジ取引（FX）ではクロスモードを採用している場合が多いためいつものような取引形式を希望する方は変更しておきましょう。（『Bitget)』なども初期設定はクロスモードです。）

なお、コピートレード適用中は”分離モード”にしておかないといけないため注意が必要です。

3.ポジションを注文する

上記の項目を埋めた後に『契約取引開始』をタップでポジションを保有します。

成行注文の場合と指値注文の違いを見ていきましょう。

成行注文

“市場価格”が選択されている場合は成行注文です。（初期画面）

レバレッジを選択し、元本（USDT）を入力し画面下部のロング/ショートをタップするだけで成行注文が完了します。

スプレッドがあるため、”推定成約価格”に表示されている金額で注文される点に注意しましょう。

画面左下の”詳細設定”を選択すると利食い/損切り価格を設定できるため、活用することをおすすめします。

指値注文

指値注文の場合は、”契約委託”を選択した状態になります。

指値注文したい価格を入力し元本を設定後にロング/ショートをタップして指値注文完了。

成行注文同様に推定成約価格にも注意して注文しましょう。

4.ポジションを決済する

チャート画面右下にある『決済』をタップするとポジションクローズします。

『未実現損益』となっている部分が利益/損失ですので、ここを確認しながら決済または利食い/損切りを選択してください。

“決済”が成行決済で”利食い/損切り”が指値決済となります。

BingX(旧:Bingbon)VSTでコピートレードのやり方

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

VSTを使ってコピートレードを行う場合『BingX』の運用をおこなっているコピートレーダーのみが利用することができます。

そのため、トレーダーリストのフィルターで選択することをおすすめします。

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

するとBingXでトレードしているユーザーが表示されるのでそこからトレーダーを選択しましょう。

ユーザーの右側にある『コピー注文』をタップし『VST模擬金』をタップします。するとコピトレ設定方法の画面が表示されるので『今すぐコピー注文』をタップで注文が完了です。

コピー注文決済したい場合

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

契約取引の画面にコピー注文のポジションが表示されています。

ワンクリックで一括決済か一つ一つのポジションの決済が行えます。

【無料】BingX期間内のアカウント開設で500USDTゲット！ここだけの特典！

BingX(旧:Bingbon)現在開催中のキャンペーン

BingXにはボーナスがありますが、ボーナスの中身まで詳しいことは知らない人がほとんどです。

しかし、ボーナスと聞くと、とりあえず手に入れておきたいと思う人も多くいると思うので現在BingXが展開しているボーナスについて詳しく解説していきます。

興味がある人はぜひ、新規口座開設をしてお得なボーナスを獲得してみてください。

BingX(旧:Bingbon)の新規口座開設100ドルボーナス

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

新規口座開設ボーナスとして新規登録をするだけで100ドルもらうことができます。

さらに「新規登録者限定特典」もありお得に今なら始めることができます。

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

条件がいくつかありますので、確認しましょう。

3月27日までの限定イベント開催中

jp_newlyaddedpairs_webbanner_944x472-huodong0322

イベント終了時刻：2022年3月27日17:00 (日本時間)

※ETH標準契約始値に基づきラッキーナンバーが決まります。

イベントの詳細はこちらから確認することが可能です。

https://bingx.com/ja-jp/act/template/2143

この記事限定のボーナス５００USDT

新規登録ユーザーは１００USDTのボーナスがもらえるという紹介はしましたが、このブログ記事からだと新規ユーザーは５００USDTのボーナスがもらえるチャンスがあります。

受け取り手順を紹介したいと思います。

  1. BingXのアカウント開設こちらから
    ▶http://bingx-japan.com/m83/
  2. 日本公式LINE登録こちらから
    ▶https://quattroe.ecai.jp/optin/3?ecaiad=KeV1RfRL
  3. 日本携帯認証＋81必須
  4. KYC本人確認登録
  5. ④まで完了後、日本公式LINE＠にDMで「UID 〇〇 +KYC完了」とメッセージを送る。

※UID通知後、担当者LINEから直接返信・確認メッセージを受け取ってから48時間以内に「私のクーポン券」に反映されます。

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

UIDはアプリで「ログイン」→「アカウントタップ」→「プロフィール画面」こちらで確認することが可能です。

BingX(旧:Bingbon)コピートレードまとめ

BingX(旧:Bingbon)は、取り扱い銘柄も多く取引しやすい仮想通貨取引所として多くのユーザーを抱えています。

とくにスマホアプリが扱いやすく、コピートレーディングやデモトレーディングなど初心者にも扱いやすい取引方法があるので、

はじめて仮想通貨の取引をしたいという人にはおすすめです。

BingX(旧:Bingbon)の長所をよく理解することで、多くの利益を狙ってみてくださいね。

【最新版】BingX(旧:Bingbon)コピートレードのやり方とは？コピトレの設定方法・体験金VSTの使い方も徹底解説します。の説明画像

【無料】BingX期間内のアカウント開設で500USDTゲット！ここだけの特典！

--- # GMOコインの評判は？最悪・やばいって本当？口座開設・キャンペーン・手数料・出金入金方法・アプリ操作方法・レバレッジ全て解説 仮想通貨投資（取引）を始めるには「仮想通貨用の口座開設」→「日本円の入金」→「仮想通貨の購入」が必要です。その後「仮想通貨の売却」→「日本円の出金」という取引の流れになります。 今回は、仮想通貨初心者の方でも簡単に始めやすい「GMOコイン」の口座開設から手数料などの情報について画像付きで詳しく説明します。 … 正規URL: https://3mikan.com/archives/224 著者: みかん 公開: 2021-02-28T10:27:49.000Z 更新: 2022-03-12T15:04:44.000Z

仮想通貨投資（取引）を始めるには「仮想通貨用の口座開設」→「日本円の入金」→「仮想通貨の購入」が必要です。その後「仮想通貨の売却」→「日本円の出金」という取引の流れになります。

今回は、仮想通貨初心者の方でも簡単に始めやすい「GMOコイン」の口座開設から手数料などの情報について画像付きで詳しく説明します。

「GMOコイン公式サイト」

GMOコインとは？

GMOコインの評判は？最悪・やばいって本当？口座開設・キャンペーン・手数料・出金入金方法・アプリ操作方法・レバレッジ全て解説の説明画像

GMOコインとは仮想通貨の取引所になります。GMOコインは他の取引所とは違って「入金・出金・送金・取引」すべての手数料が無料なので、費用を抑えて取引をしたい方におすすめです。さらに、専用のスマホアプリがあるのでいつでも状況を確認することができ、簡単に取引ができます。

次に、「買い」と「売り」の”金額の差額”を「スプレッド」と言うのですが、このスプレッドが小さいほどお得に取引ができます。GMOコインは、最近このスプレッドが小さくなってきているのでお得に取引ができます。

なお、他のGMOコイン以外のいくつかの取引所ではビットコインなどの仮想通貨を使って他の仮想通貨を買えますが、GMOコインでは日本円でしか仮想通貨が買えません。なので、初めて仮想通貨を買う方や不安な方は、始めのうちはGMOコインを利用して日本円で仮想通貨を購入して、取り引きに慣れてきたら、仮想通貨で仮想通貨を購入できる取引所に登録するのも一つの方法です。

では早速、GMOコイン口座の開設について説明していきます。口座開設はとても簡単です。

GMOコイン 基本情報

名称GMOコイン
取扱銘柄(取引所)8銘柄
取扱銘柄(販売所)14銘柄
取引所手数料Maker：-0.01%
Taker：0.05%
最低入金額1,000円
最低出金額10,000円
(全額出金の場合、出金額の制限はなし)
提供サービス取引所
販売所
レバレッジ取引所
暗号資産FX
貸仮想通貨
つみたて暗号資産
ステーキング
公式サイトGMOコインの公式サイト

GMOコインの取り扱い通貨

GMOコインで取り扱われている通貨の一覧です。

取引所と販売所で取り扱われている通貨が違うので注意してください。

取引所の取り扱い通貨
  • ビットコイン（BTC）
  • イーサリアム（ETH）
  • ビットコインキャッシュ（BCH）
  • ライトコイン（LTC）
  • リップル（XRP）
  • ネム（XEM）
  • ステラルーメン（XLM）
  • シンボル（XYM）

※2021年10月31日 現在8銘柄

販売所の取り扱い通貨
  • ビットコイン（BTC）
  • イーサリアム（ETH）
  • ビットコインキャッシュ（BCH）
  • ライトコイン（LTC）
  • リップル（XRP）
  • ネム（XEM）
  • ステラルーメン（XLM）
  • ベーシックアテンション（BAT）
  • オーエムジー（OMG）
  • テゾス（XTZ）
  • クアンタム（QTUM）
  • エンジンコイン（ENJ）
  • ポルカドット（DOT）
  • コスモス（ATOM）

GMOコインの評判は？

国内取引所としてはかなり有名なGMOコインですが、果たして評判はどうなんでしょうか？？

口コミをリサーチしていてみたいと思います。

※1ユーザーの意見のため、GMOコイン全体の評価ではありません。利用する際は自己判断で利用してみてください。

GMOコインの審査が遅いという意見

１３考える
アイコン名を入力

本人確認の審査が終わらない遅い・・・。

GMOコインでは、本人確認が通ると口座開設コードがメールで届き審査が完了となります。

最短で当日中に審査が完了しますが、遅れる場合も多々あるようです。

  • 混雑状況により審査が遅れている
  • 審査内容の不備がある
  • 迷惑メール宛に届いている
  • 受信側の受信拒否設定

基本的に遅れている理由としてこれら4つが考えられます。

会員ホームにて審査状況が把握できるそうなので、遅いと感じた場合は会員ページにて確認またはお問い合わせで確認するのがいいと思います。

GMOコインの手数料が高い

１３考える
アイコン名を入力

手数料が高すぎる・・・。

GMOに関わらず、国内の取引所を利用する場合は『手数料が高い』ということは一つ頭に入れておいていいでしょう。

取引回数が増えれば増えるほど、手数料は無視することができないコストです。

本格的に仮想通貨運用を考えている方は、『海外取引所』を利用することをおすすめします。

GMOコイン口座開設手順

GMOコイン口座の開設手順を説明します。口座開設は非常にスムーズで簡単なので、読みながらやってしまうことをおすすめします！

①公式サイトからメールアドレスを登録する

口座開設は簡単にできます。まず「GMOコイン公式サイト」を開いてメールアドレスを登録します。

「GMOコイン公式サイト」はこちらをタップ

公式サイトを開いたら中央部分に「口座開設はこちら」のボタンが表示されるのでそこをタップしてください。すると口座開設ページに移りますので、そこでメールアドレスを入力します。

メールアドレス

次に、私はロボットではありません。にチェックを入れて、「無料口座開設」ボタンをタップしましょう。タップしたのちすぐに、入力したメールアドレス宛に「パスワード設定」のメールが届きます。

②パスワードを設定する

届いたメールにはパスワード設定ページのURLが記載されているので、そのURLをタップします。

メールアドレス２

同じパスワードを二回打ち込んで、最後に「設定する」ボタンを押せばパスワード設定の完了です。

③電話番号の登録をしてコードを入力する

GMOコイン公式では、携帯電話の番号が推奨されています。固定電話の場合は音声通話、携帯電話の場合はSMSにてコードが案内されます。

電話番号

番号を記入したら「コードを送信」ボタンを押してください。（↑上記画像参照）次に、案内されたコードを入力し青の「認証する」ボタンをタップします。（↓下記画像参照）

二段階認証コード

これで「電話番号」と「二段階認証コード」が登録できます。コードというのは、口座のセキュリティ強化や安全性を高めるために必要になります。

④個人情報の登録をする

二段階認証が完了すると下の画面が表示されるので、下にある青ボタンの「開設申込みへ進む」をタップしましょう。（↓下記画像参照）

承認が完了

すると個人情報の登録画面に進むので、上から順に記入してください。下まで記入したらグレーの「次へ」ボタンをタップしてください。（↓下記画像参照）

個人情報記入

次の画面では収入状況に関して記入していきます。下まで記入したら青の「確認画面へ」ボタンをタップします。

個人情報記入２

記入した項目を確認後、赤の「口座開設申込」ボタンをタップします。

個人情報記入３

⑤本人確認書類の提出をする

先ほどの赤の「口座開設申込」ボタンを押すと下の画面が表示されます。

本人確認

本人確認では
「かんたん本人確認」
「本人確認書類の画像をアップロード」
「配達員へ提示する」

の３つのうちいずれかの方法を選択します。
おすすめは即日で口座開設と取引ができる「かんたん本人確認」です。なお、どの方法で本人確認をするかによって、提出可能書類が少しずつ変わってきます。

「かんたん本人確認の場合」

本人確認-1

こちらはスマホ専用のサービスになります。「自分の顔写真」と「指定の本人確認書類２点」を提出するだけで、その日のうちに口座開設とコイン取引ができるようになります。

かんたん本人確認に使える書類は以下になります。

  • 運転免許証
  • 個人番号カード
  • 在留カード
  • 住民基本台帳カード（顔写真あり）
  • 運転経歴証明書
  • 特別永住者証明書

「画像アップロードの場合」

本人確認２

「本人確認書類２点」の提出が必要です。提出した書類画像がぼやけていたり反射していたり見切れていたりすると承認不可の原因になるので、しっかり撮れているか確認してから提出しましょう。

画像アップロードに使える書類は以下になります。

  • 運転免許証
  • 各種健康保険証
  • パスポート
  • 個人番号カード
  • 住民票の写し
  • 住民基本台帳カード（顔写真あり）
  • 住民票記載事項証明書
  • 印鑑登録証明書
  • 在留カード
  • 特別永住者証明書

「配達員へ提示する場合」

本人確認３

配達員へ提示する場合は、郵送受け取り時に配達員に本人確認をしてもらう必要があり、本人が確実に受け取らないといけません。面倒な方はかんたん本人確認または画像をアップロードがおすすめです。

配達員へ提示に使える書類は以下になります。

  • 運転免許証
  • 個人番号カード（マイナンバーカード）
  • パスポート
  • 住民基本台帳カード（顔写真あり）dxd

⑤口座開設コードを入力する

本人確認が済むと数十分後または数日後に口座開設コードが記載された「口座開設のお知らせ」というメールまたは登録した住所に手紙が届きます。記載されている「口座開設コード」をログイン後の画面に記入します。

コード入力後、「口座開設」をタップすると口座開設の完了です！

これで取引ができるようになります。

手順①から手順⑤まで審査や手紙の発送も含めて最短１０分〜最長３日で完了します。

【口座開設はこちらをタップ「GMOコイン公式サイト」】

口座開設にあたっての注意点

未成年の場合、GMOコイン口座は開設ができません。基本的に国内の取引所では未成年の口座開設はできません。

そして日本国内に居住していない場合も口座開設はできません。原則として日本国内に住んでいる方のみ開設が可能です。

仮想通貨用の口座開設の手順解説は以上になります。

【口座開設はこちらをタップ「GMOコイン公式サイト」】

GMOコインのログインページ

GMOコインのアカウントがすでにあり、ログインしたい方は下のページにアクセスしてください。

https://coin.z.com/jp/member/home

GMOコインのお得なキャンペーン情報

GMOコインのお得なキャンペーン情報を紹介していきます。

※2021年10月31日時点

GMOコインの口座開設に関するキャンペーン

友達紹介キャンペーン

bn-202110-02

友達にGMOコインを紹介し、その友達が口座開設すると双方に200円分のビットコイン（BTC）が送られます。

さらにキャンペーン期間中に「販売所」「つみたて暗号資産」で5万円以上の暗号資産を購入すると、あなたに1000円、友達に3000円が追加でもらえます。

GMOコインキャンペーンプログラム情報

シンボル（XYM）の預入れで現金1万円が当たる！キャンペーン

bn-202110-01

キャンペーン期間内に、シンボル（XYM）をGMOコインに指定の数量以上預け入れると、抽選で現金1万円が50名に当たります。

暗号資産（仮想通貨）の購入で毎日10人に1,000円が当たる

bn-201911-01

「販売所」または「つみたて暗号資産」において、暗号資産（仮想通貨）を1回以上購入した場合に抽選で10名に現金1,000円が当たります。（毎日）

暗号資産FXで毎日1人に1万円が当たる

bn-201910-01

暗号資産FXにおいて、1日に600万円以上の新規取引を行うと抽選で毎日1名に現金1万円が当たります。

GMOコインの入金方法・ヘルプ

screen-2021-10-31-17.10.43-1

GMOコインの入金方法に関する情報です。おすすめの入金方法や各銀行からの入金方法についてまとめています。

基本的に、インターネットバンキングがあるユーザーは即時入金可能かつ入金手数料が無料なので、どこから送金してもGMOコイン側は変わりません。

取扱い金融機関名入金反映時間受付時間入金手数料最低入金額最高入金額
GMOあおぞらネット銀行
楽天銀行
住信SBIネット銀行
PayPay銀行		即時24時間365日無料1,000円/回1,000万円/回
三菱UFJ銀行
三井住友銀行
みずほ銀行
りそな銀行
埼玉りそな銀行
（Pay-easy）		即時24時間365日無料1,000円/回999,999円/

即時入金ができない場合は普通の振込入金を利用しましょう。

GMOコイン入金方法のおすすめは？

screen-2021-10-31-17.03.46

GMOコインの入金方法に最もおすすめなのは、「GMOあおぞらネット銀行」です。

どの銀行も銀行側の振込手数料はかかるのですが、GMOあおぞらネット銀行の場合は手数料がかかりません。

GMOと記載がある通りグループ会社ということもあって非常にスムーズに入金が可能です。

GMOコイン入金方法で手数料はどれくらい違う？

GMOコインに日本円を入金する場合は、すべて"入金手数料は無料"です。

しかし、即時入金ではなく振込入金で入金しようとすると「振込」作業を行う場合があります。振込にはもちろん"振込手数料"が発生します。

振込手数料が気になる方はGMOあおぞらネット銀行や即時入金などを活用しましょう。または各銀行の振込手数料無料枠で対応するのもいいですね。

例①：GMOコイン入金方法SBI銀行の場合

screen-2021-10-31-17.10.43-1

まずは日本円に入金ボタンを押しましょう。そこから各金融機関を選ぶページになります。

screen-2021-10-31-17.12.02

SBIネット銀行を選択しましょう。ここで違う銀行を利用している場合には各自自分のものを押してください。

screen-2021-10-31-17.12.13

金額を入力します。ボタンを使うと入力が簡単です。

screen-2021-10-31-17.12.19

金額を確定すると「住信SBIネット銀行のウェブサイトへ進む」と表示が出ます。

ここから住信SBIネット銀行のウェブサイトに進み、ログイン作業して振込の承認をすることになります。

screen-2021-10-31-17.12.33

自分の口座の支店を選んで進めていきましょう。ここから先は住信SBIネット銀行での普段どおりの操作になります。

例②：GMOコイン入金方法楽天銀行の場合

screen-2021-10-31-17.10.43-1

まずは日本円に入金ボタンを押しましょう。そこから各金融機関を選ぶページになります。

screen-2021-10-31-17.12.02-2

楽天銀行を選択しましょう。ここで違う銀行を利用している場合には各自自分のものを押してください。

screen-2021-10-31-17.12.13

金額を入力します。ボタンを使うと入力が簡単です。

screen-2021-10-31-17.16.16

ここから楽天銀行にログインして振込承認を行っていきます。

注意書きでも表示されますが、振込承認後「戻る」ボタンを押さないといけないため忘れないようにしましょう。

例③：GMOコイン入金方法ゆうちょ銀行の場合

ゆうちょ銀行の場合は即時入金が使えないので「振込入金」メニューを押しましょう。

screen-2021-10-31-17.18.33

表示された口座宛に振り込みするだけで入金が完了します。なお、振込元名義などは一致している必要があるので注意しましょう。

GMOコインの入金方法はコンビニには対応してない

2021年10月31日時点でGMOコインはコンビニ入金が不可能です。

現在使える入金方法は以下の2つです。

入金方法
  1. 即時入金
  2. 振込入金

GMOコインの出金方法・出金に関するヘルプ

screen-2021-10-31-17.22.31

出金は入金と同じメニューから行えます。最初は出金先口座情報の登録が必要になるので登録しましょう。

口座情報を入力済みなら出金操作が行えます。

※特定の時間は入出金の制限がかかっており操作することができません。

screen-2021-10-31-17.27.26

Q.GMOコインの出金にはどれくらい時間・日数がかかる？

金融機関営業日の17時までに日本円出金のご依頼を受け付けた場合、翌金融機関営業日の出金処理となります。

GMOコイン

GMOコインは基本的に毎日出金が可能です。17時までに依頼をすれば金融機関の翌営業日に出金処理がされます。

注意すべきなのは"金融機関営業日"なので、祝祭日・土日は除くという点です。

特に大型連休直前・年末年始は金融機関営業日が結構空くので注意しましょう。

Q.GMOコインの出金が反映されない

GMOコインからの出金が振り込まれないという例は出ておりませんので、反映が遅れているだけです。

GMOコイン側からまだ振り込まれてない（17時以降に出金処理を行ったなど）ことや、お使いの金融機関の着金反映が遅れているだけでしょう。

Q.GMOコインの出金をゆうちょ銀行や楽天銀行にしたい

screen-2021-10-31-17.35.04

登録情報ページ一番右より、銀行口座情報の変更が行なえます。

ここで、ゆうちょ銀行や楽天銀行に変更可能です。

Q.GMOコインの出金が遅い。着金しない。

GMOコインからの出金が振り込まれないという例は出ておりませんので、反映が遅れているだけです。

GMOコイン側からまだ振り込まれてない（17時以降に出金処理を行ったなど）ことや、お使いの金融機関の着金反映が遅れているだけでしょう。

Q.GMOコインの出金は土日もできる？

出金処理は土日でも可能です。しかし、出金が完了するのは金融機関翌営業日です。

Q.GMOコインの出金が処理済みになったまま何も進まない

処理済みになっているが振り込まれていないという場合です。

GMOコインからの出金が振り込まれないという例は出ておりませんので、金融機関側で反映が遅れているだけです。

GMOコイン側からまだ振り込まれてない（17時以降に出金処理を行ったなど）ことや、お使いの金融機関の着金反映が遅れているだけでしょう。

Q.GMOコインの出金先銀行はどこで設定する？

screen-2021-10-31-17.35.04-1
アカウントの登録情報ページを開き、メニューの一番右に「出金先口座情報」というメニューがあります。

ここから出金先口座を設定できます。

Q.GMOコインの出金履歴はどこで見れる？

mceclip0

日本円でのご入金・ご出金の履歴は、ログイン後の会員ページ -【入出金】-【日本円】-【取引履歴】より検索していただけます。

GMOコイン

GMOコインでは入出金の履歴が全て確認できます。

Q.GMOコインの送金制限はある？

送金制限はあります（最低入金額・最高金額/日）

日本円入金

取扱い金融機関名入金反映時間受付時間入金手数料最低入金額最高入金額
GMOあおぞらネット銀行
楽天銀行
住信SBIネット銀行
PayPay銀行		即時24時間365日無料1,000円/回1,000万円/回
三菱UFJ銀行
三井住友銀行
みずほ銀行
りそな銀行
埼玉りそな銀行
（Pay-easy）		即時24時間365日無料1,000円/回999,999円/

日本円出金

受付時間帯手数料最低金額最高金額所要時間
6:15～17:00、
18:00～5:45		無料10,000円/回（全額出金の場合、出金額に制限はございません。）2,000万円/日翌〜翌々金融機関営業日

仮想通貨

お預入ご送付
受付時間帯24時間 365日24時間 365日
手数料無料（マイナーに支払う手数料はお客様負担となります）無料
最低金額制限なし0.02 BTC / 回
最高金額制限なし10 BTC / 日
所要時間最短30分最短30分

GMOコインのアプリの使い方・ヘルプ

GMOコインアプリの利用はとても画面が分かりやすい為利用がしやすいです。

パソコンからの操作も可能ですが、アプリでも簡単に操作ができるのでスマホアプリをメインに操作方法を紹介していきたいと思います。

GMOコインアプリを無料でダウンロード・インストール

IOS／Android共にスマホアプリから無料で利用することが可能です。

GMOで検索すると関連のアプリが多く存在する為わかりにくいかもしれません。『GMOウォレット』で検索すると一番上に表示されますのでそちらのダウンロードをしてください。

GMO

GMOコインアプリの使い方・見方

GMOコインアプリは、ノーマル／トレーダー2種類のモードの選択をすることが可能です。

GMO２

※モードは後からも変更することが可能です。

GMOコインアプリで取引所を開く方法

取引所の利用をしたい場合は、アプリダウンロード後『トレーダー』の選択をしてください。

『ノーマル』を選択した場合、販売所のみの利用になります。

G１

GMOコインアプリでチャートを開く方法

各コインのチャートは取引所から見ることが可能です。

設定でチャートのカスタマイズも可能ですので、自分が知りたい情報を選択しチャートを開いてみてください。

G２

Q.GMOコインのアプリのPC版はある？

GMOコインアプリはスマホのみ対応していますが、ウェブでの利用は問題なくできます。

GMOコインの評判は？最悪・やばいって本当？口座開設・キャンペーン・手数料・出金入金方法・アプリ操作方法・レバレッジ全て解説の説明画像

ブラウザにて、GMOコインの検索をしてください。

GMOコインの評判は？最悪・やばいって本当？口座開設・キャンペーン・手数料・出金入金方法・アプリ操作方法・レバレッジ全て解説の説明画像

右上にある『ログイン』からメールアドレス／パスワードの入力をし利用することが可能になります。

GMOコインの評判は？最悪・やばいって本当？口座開設・キャンペーン・手数料・出金入金方法・アプリ操作方法・レバレッジ全て解説の説明画像

Q.GMOコインアプリで出来高を確認する方法はある？

『GMOクリックCFD』という違うアプリを導入すると出来高を確認することが可能です。

GMOコインの評判は？最悪・やばいって本当？口座開設・キャンペーン・手数料・出金入金方法・アプリ操作方法・レバレッジ全て解説の説明画像

パソコンから確認する場合は、『WebTrader』というツールを利用することで確認することが可能です。

GMOコインの評判は？最悪・やばいって本当？口座開設・キャンペーン・手数料・出金入金方法・アプリ操作方法・レバレッジ全て解説の説明画像

インジケーター内で、『出来高』と検索するといくつかでてきますのでそこから選択し確認してください。

GMOコインの送金手数料は無料

screen-2021-10-31-18.04.56

GMOコインの仮想通貨の預入と送付にかかる手数料は無料です。

他の取引所と同様で取引手数料はありますが、GMOコインでは送金に関する手数料が全て無料です。

ビットコイン・イーサリアム・リップルを買うなら送金手数料無料のGMOコインがおすすめ

基本的に送金手数料が無料になるため、日本円で買って他の場所に仮想通貨を送るだけならGMOコインが最もおすすめと言えるでしょう。

何度もトレードを行う場合には取引手数料が大きく関係してくるので、トレード主体の人はしっかり確認しましょう。

GMOコインからバイナンスへも送金手数料

もちろんGMOコインからバイナンスに送る際も送金手数料が無料です。

バイナンスを利用したいという方も、GMOコインでビットコインを買ってバイナンスに送金するなどといった方法も簡単に取れますね。

GMOコインの手数料・スプレッドまとめ

GMOコインの手数料やスプレッドについてまとめていきます。

販売所取引所
（現物取引）		取引所
（レバレッジ取引）		暗号資産FX
取引手数料無料Maker：-0.01%
Taker：0.05%		無料無料
ロスカット手数料--建玉ごとに0.5%無料
レバレッジ手数料--建玉ごとに
0.04% / 日		建玉ごとに
0.04% / 日
追加証拠金が解消されないことに伴う強制決済手数料--建玉ごとに0.5%建玉ごとに0.5%

上の表がGMOコインの取引にかかる手数料の一覧です。

GMOコインには「販売所」と「取引所」がありますが、一般的に取引所を利用することをおすすめします。

手数料はかかりますが、レートがかなり異なります。

GMOコインの手数料を他の取引所と比較

GMOコインと他の取引所を比較してみます。1点注意すべき箇所があり、ほとんどの取引所で手数料の表には「スプレッド」が記載されていないことです。

スプレッドとは？

スプレッド（spread）とは、直訳すると「広がり」といった意味の通り、売値（Bid）と買値（Ask）の価格差を指します。 FX取引では常に、通貨を売るときの値段「売値」と通貨を買う時の値段「買値」の2つの為替レートが提供されています。

スプレッドは手数料とは記載されず、売値と買値の価格の開きでしか表現されません。

更に、このスプレッドは常に一定ではなく相場が荒れていると大きくなることがあるので一概に比較できません。

手数料・スプレッド・利便性と全て含めて総合的に比較することをおすすめします。

hikaku
GMOコインビットフライヤーコインチェック
取引手数料
（取引所）		Maker：-0.01%
Taker：0.05%		 0.01 ～ 0.15%無料
スプレッド（BTC）
※販売所で計測		200,924円418,501円420,963
※2021年10月31日同時刻に計測

こう見るとかなりGMOコインはスプレッドが小さいことがわかりますね。

手数料と表記されないものの、スプレッドも取引所側が設定している数字です。しっかり確認しましょう。

GMOコインの暗号資産FXの手数料

取引手数料は無料です。

日本時間朝6:00をまたいで建玉を保有した場合、当取引日の終値から計算した評価金額に対し、建玉ごとに0.04%/日のレバレッジ手数料が発生します。

GMOコイン

暗号資産FXでは、毎日手数料が発生すると思っておきましょう。建玉（たてぎょく）とは、未決済のポジションのことです。

つまり、未決済のポジションを持っている間は毎日その量に応じて手数料が発生します。

GMOコインの取引所の手数料

Makerは-0.01%、Takerは0.05％の取引手数料がそれぞれ発生します。

GMOコイン

GMOコインの取引所ではMaker・Taker手数料が発生します。Maker（メイカー）・Taker（テイカー）が聞き慣れないと思うので補足します。

取引板を構成する上で誰かが先に注文板を出して、それにマッチングする形で取引が成立しますよね。

このときに、先に注文板を出してる側をMaker（メイカー）と呼び、後からマッチングした側をTaker（テイカー）と呼びます。

「注文板を作る（Make）」「注文板を取る（Take）」と覚えておくといいですね。

「注文板を作る」とは、指値注文を出しておくことを意味します。

『●●円になったら買う』といった注文が、取引板を構成していくんですね。

GMOコインのレバレッジ手数料

取引手数料は無料ですが、下記の手数料が発生します。

ロスカット手数料：ロスカット注文が発動された場合、対象建玉の「建玉レート × 建玉数量 × 0.5%」の手数料が発生

レバレッジ手数料：日本時間朝6:00をまたいで建玉を保有した場合、当取引日の終値から計算した評価金額に対し、建玉ごとに0.04%/日の手数料が発生

GMOコイン

GMOコインにはロスカット手数料とレバレッジ手数料があります。

Q.GMOコインの手数料でMakerがマイナスなのはどういう意味？

GMOコインの手数料でMakerの手数料は-0.01%と記載されています。これは、「手数料を受け取れる」ことを意味しています。

つまり、手数料を払う側ではなく貰う側になっているということです。

とはいえ、0.01%という数字はトークン価格が少し動いたらすぐに超えてしまう金額なので、そこまで気にする必要もないでしょう。

Q.GMOコインの手数料は実際高いの？

結論から言うと、「国内では安く、世界的には高い」と言えます。

海外FX、バイナンス、DeFiに慣れている方からしたら全ての手数料が高く感じるでしょう。

しかし、国内の他の取引所と比べる分にはそこまで高いとは言えません。むしろ、利便性を考慮するとかなり良い取引所と考えています。

GMOコインのレバレッジ取引のまとめ

GMOコインのレバレッジ取引に関する情報です。

GMOコインのレバレッジ手数料計算方法

建玉ごとに0.04%/日の手数料が発生します。つまり、建玉の金額が大きければ大きいほど手数料も大きくなります。

レバレッジを上げれば建玉の金額も大きくなり、結果的に手数料も大きくなります。この点には十分に注意しましょう。

レバレッジ手数料計算例

建玉が100万円分の場合

1,000,000円 x 0.04%/日 = 400円/日

※GMOコインはレバレッジが変更できないです。

GMOコインのレバレッジ設定方法・やり方

GMOコインではレバレッジの設定方法はありません。自動で調整され、2倍を超えるポジションを持つことはできません。

ポジションの未決済建玉の含み損が大きくなり、証拠金維持率を下回った場合自動的にロスカットされます。

暗号資産FXの場合は証拠金維持率が75%を下回った時点でロスカットされます。

pc_12

GMOコインのレバレッジ取引の買い方・売り方

GMOコインの評判は？最悪・やばいって本当？口座開設・キャンペーン・手数料・出金入金方法・アプリ操作方法・レバレッジ全て解説の説明画像

GMOコインの暗号資産FXのページで通貨を選択し、まずは「取引数量」を記入します。

その後、売（BID） or 買（ASK）を選択します。

Q.GMOコインのレバレッジ・ロスカット・証拠金計算方法

レバレッジは証拠金とポジションに応じて自動的に計算されます。

つまり、レバレッジ1倍でポジションを持てる場合には自動で1倍になります。

レバレッジ倍率やロスカットの計算方法についてまとめてある記事があるので、参考にしてください。

https://3mikan.com/archives/2918

Q.GMOコインのレバレッジ倍率は何倍ですか

GMOコインのレバレッジは最大2倍です。2倍を超えてポジションを持つことはできません。

それ以下には自動的に調整されます。

Q.GMOコインのレバレッジは変更できますか

GMOコインのレバレッジは一律2倍に設定されていて変更できません。

とはいえ、証拠金が多くレバレッジが2倍以下でポジションを保有できる場合には自動で調整されます。

2倍を超えてレバレッジ倍率がかかることはないので、ロスカット計算などを行う際には2倍で考えましょう。

GMOコインの使い方まとめ

GMOコインは個人的にはよく使っている取引所です。

もちろん、基本的にはDeFiやバイナンスなどのサイトを利用することが多いです。

しかし、日本円を経由する場合はどうしても国内取引所を使うことになるので、そういった場合にはGMOコインをいつも利用しています。

個人的にはおすすめの国内取引所です。是非利用してみてください。

--- # 【仮想通貨】BINANCE(バイナンス)のクロスマージンとは？分離マージンとの違いは？わかりやすく解説します。(レバレッジ取引/マージントレード/証拠金取引/用語解説) 今回は、BINANCE(バイナンス)のマージン取引について深堀りしていきたいと思います。 マージン取引には「クロスマージン」と「分離マージン」の2種類がありますが、それぞれ違いがあります。取引をマスターすることができれば、相場の上昇と下降の両方で利益を出せるようになるので資金効率にもつなげることができます。… 正規URL: https://3mikan.com/archives/2760 著者: みかん 公開: 2021-09-25T13:07:44.000Z 更新: 2022-03-12T15:03:45.000Z

今回は、BINANCE(バイナンス)のマージン取引について深堀りしていきたいと思います。

マージン取引には「クロスマージン」と「分離マージン」の2種類がありますが、それぞれ違いがあります。取引をマスターすることができれば、相場の上昇と下降の両方で利益を出せるようになるので資金効率にもつなげることができます。

バイナンスのアカウントをすでに持っているという人は、担保の送金/借入取引/返済取引の３つのステップで簡単に取引が行えますので運用の幅を広げるという意味でもこの記事が参考になれば嬉しいです。

このブログでは、実際にマージン取引についてのやり方や、クロスマージン・分離マージンの違い、用語の解説をしていきます。興味のある方はぜひ最後まで読んでみてください。

【無料】ここから登録するとBinanceの取引手数料10％OFFでお得にトレードできます！

BINANCE(バイナンス)のマージン取引とは？

マージン取引(マージントレード)とは、信用取引とも言われ、買い付けに必要なお金を先に借りてから取引する方法です。先に資金を借りて取引をするので、必然的に利子が発生します。利子は１時間ごとに発生し、利率は借りる通貨やVIPレベルによって変化します。

そして、binance(バイナンス)ではマージン取引をする時に3倍〜最大10倍のレバレッジをかけて取引することができます。レバレッジを利用することで、少ない資金で大きな利益を狙えます。

レバレッジとは？＞＞＞

預けた証拠金よりも大きな金額で取引ができる機能のこと。

binance(バイナンス)では最大10倍のレバレッジが利用できます。仮に、10倍のレバレッジをかけてマージン取引をするとしたら、いま自分の手元に1万円しかなくても、9万円分をbinance(バイナンス)から借りて、10万円分の取引ができるようになります。

ただ、クロスマージンで取引するのか、分離マージンで取引するのか、またその時に取引する通貨によって利用できるレバレッジは異なります。

現物取引だと自分が持っている資金の範囲内でしか取引ができませんが、マージン取引だと、口座に預けているお金の何倍もの額の取引ができ、いま手元にない仮想通貨を先に売ってから買い戻して利益を得ることができます。

binance(バイナンス)のマージン取引は＞＞＞

取扱通貨が約200種類と豊富なのも嬉しいポイントです。

ただ、binance(バイナンス)のマージン取引では、１時間ごとに利子が発生します。利率は、取引する通貨やVIPレベルよって変わりますが、BTC(ビットコイン)だと0.00125％になります。

そして、前述した通りマージン取引には「クロスマージン」と「分離マージン」の2種類があります。次の項目でそれぞれの特徴を解説します。

BINANCE(バイナンス)クロスマージン・分離マージンの違い

それぞれの違いを表で見るとこんな感じです。

クロスマージン分離マージン
証拠金残高を全てのポジション維持の証拠金に使うポジション維持に使う証拠金は、
指定したレバレッジによって制限されて使う
証拠金の補充自動なし
ロスカット ゼロカット(全資金を失う)証拠金は失うが口座残高は残る

ロスカットとは＞＞＞

あらかじめ決められた損失に到達した場合に、それ以上の損失が起きないように仮想通貨交換業者が強制的に決済することを言う。

https://3mikan.com/archives/2918

ロスカットについて詳しく知りたい方はこちらを参考にしてください。

クロスマージンとは?

口座残高の全てを証拠金として使う取引方法です。また、取引する全ての通貨を一つの口座で管理します。クロスマージンは、ポジションを長く持ちたい場合に向いています。

損失が大きくなると証拠金が減り、ロスカットのリスクが高まりますが、クロスマージンであれば口座残高から自動的に証拠金が補充されるので、ロスカット のリスクを少なくすることができます。

ただし、ポジションと担保にしている証拠金の比率は把握しておく必要があります。急激な暴落であまりにも損失が増えた場合は、資金を全損してしまう可能性があるので資金力がある方には良いと思います。

利用する場合は、損切りライン/利食いラインを自分で必ず引いて資金を守る事をおすすめします。

分離マージンとは?

口座残高と証拠金を分けて使う取引方法です。取引する通貨ごとに財布を分けて管理しているようイメージです。仮想通貨の相場を読み慣れていない方には向いています。

証拠金が減っても自動で補充されないので、ロスカットのリスクがあります。しかし、仮想通貨の相場はとても読みにくいので損切りに強い人の方が良かったりします。仮にロスカットされてしまった場合でも、口座残高は残るので初心者の方には分離マージンをおすすめします。

「クロスマージン」と「分離マージン」はそれぞれ特徴が異なるので、自分の運用方法に合わせて選んでください。

BINANCE(バイナンス)の借入モードと返済モードの違い

binance(バイナンス)のマージン取引は、注文する際に「借入」を行い、決済する際に借りていた資金を「返済」するシステムとなっています。

あとで注文の仕方を解説する際に出てくるので、なんとなくでも良いので覚えておいてください。

借入モードとは?

借入モードは、資金が足りなくなった場合にbinance(バイナンス)から借入ができる機能のことをいいます。

借入できる資金は口座内の資金量によって異なりますが、借入をした場合は１時間ごとに利息が発生するので気をつける必要があります。

返済モードとは?

返済モードは、取引で得た利益を自動的に返済する機能のことをいいます。

借入資金よりも先に利子が返済される仕組みになっており、取引終了後に返済しなければいけない資金が不足していた場合は手動で返済する必要があります。

BINANCE(バイナンス)マージン取引のやり方

マージン取引は５つの手順で行う事ができます。

  1. マージンアカウントの有効化
  2. マージンアカウントへの資金移動(マージン口座への振替)
  3. 仮想通貨取引
  4. 仮想通貨の借入(借入申請)
  5. 仮想通貨の返済

では実際に取引の仕方を解説していきます。

1. マージンアカウントの有効化

取引をするには、まずは証拠金取引の内容を理解した上でマージンアカウントを有効化する必要があります。

【仮想通貨】BINANCE(バイナンス)のクロスマージンとは？分離マージンとの違いは？わかりやすく解説します。(レバレッジ取引/マージントレード/証拠金取引/用語解説)の説明画像

まず、binance(バイナンス)を開いてログイン後、右上にある「トレード」をタップし「マージントレード」をタップします。

【仮想通貨】BINANCE(バイナンス)のクロスマージンとは？分離マージンとの違いは？わかりやすく解説します。(レバレッジ取引/マージントレード/証拠金取引/用語解説)の説明画像

「バイナンスマージンへようこそ」という画面が表示されます。マージン取引に関してのクイズが12問出されるので、時間があるなら回答してみてください。全て回答したら「送信」をタップしましょう。

回答が間違っていても最後に答え合わせができるので、その内容を覚えて再チャレンジすれば大丈夫です。全問正解になるとアカウントが有効化されます。

2. マージンアカウントへの資金移動(マージン口座への振替)

binance(バイナンス)では取引ごとにウォレットが分かれているため、普通に入金した状態では取引ができません。

そこでまずはbinance(バイナンス)の口座からマージントレード用のウォレットへ資金を移動させます。

【仮想通貨】BINANCE(バイナンス)のクロスマージンとは？分離マージンとの違いは？わかりやすく解説します。(レバレッジ取引/マージントレード/証拠金取引/用語解説)の説明画像

先ほどのクイズを解いてアカウントを有効化したら、取引画面にある「担保の振替」をタップします。

【仮想通貨】BINANCE(バイナンス)のクロスマージンとは？分離マージンとの違いは？わかりやすく解説します。(レバレッジ取引/マージントレード/証拠金取引/用語解説)の説明画像

「移動先となる口座(クロスマージンもしくは分離マージン)」を選択し、振替する「コイン」「金額」を入力します。内容を確認して誤りがなければ「確認」をタップします。

【仮想通貨】BINANCE(バイナンス)のクロスマージンとは？分離マージンとの違いは？わかりやすく解説します。(レバレッジ取引/マージントレード/証拠金取引/用語解説)の説明画像

(※今回はクロスマージンを選択します。)

3. 仮想通貨取引

【仮想通貨】BINANCE(バイナンス)のクロスマージンとは？分離マージンとの違いは？わかりやすく解説します。(レバレッジ取引/マージントレード/証拠金取引/用語解説)の説明画像

注文内容を決める際ですが、「通貨ペア」から取引したい通貨ペアを検索・選択します。

【仮想通貨】BINANCE(バイナンス)のクロスマージンとは？分離マージンとの違いは？わかりやすく解説します。(レバレッジ取引/マージントレード/証拠金取引/用語解説)の説明画像

通貨ペアを選択後、取引画面にて「マージン(クロスor分離)」「注文方法(リミットorマーケットorストップリミット)」「購入設定(通常or借りるor返済)」「金額」を選択・入力します。

内容を確認して誤りがなければ「購入/売却」ボタンをタップします。これで注文が完了しました。

購入設定に関して＞＞＞

  • 通常 … 既存の仮想通貨を使用した注文
  • 借りる … レバレッジにお応じて仮想通貨を自動的に借り入れする
  • 返済 … 利益から自動的に返済をする

借入・返済を手動で行いたい場合は、「通常」にチェックを入れてください。ちなみに、手動の方が管理がしやすいかと思うので、最初は「通常」がおすすめです。

4. 仮想通貨の借入(借入申請)

今回は売り注文(ロング)を行いたいと思います。マージントレードの空売り(ショート)を行いたい方は、下記記事にて紹介していますので参考にしてください。

https://3mikan.com/archives/2754
【仮想通貨】BINANCE(バイナンス)のクロスマージンとは？分離マージンとの違いは？わかりやすく解説します。(レバレッジ取引/マージントレード/証拠金取引/用語解説)の説明画像

『借入』をタップします。

価格/数量を入力し『マージン購入 BTC』をタップします。

ユーザーは、10000USDTを担保で0.00453BTCを購入することを意味しています。

すると、もともと999USDTが口座に入っていたので2000USDT自動で借りれることになります。

この借入は自動借入の手順ですが、『通常』モードで借入を行いたい場合は、画面右上の「借入」を選択し、借入する通貨と金額を入力したら「借入承認」をタップし進めることができます。

(※その際「時間あたりの利率」が記載しているので、１時間ごとに発生する利子を確認することができます。）

5. 仮想通貨の返済

BTCの相場が上場し利益がでたので返済していきたいとします。

【仮想通貨】BINANCE(バイナンス)のクロスマージンとは？分離マージンとの違いは？わかりやすく解説します。(レバレッジ取引/マージントレード/証拠金取引/用語解説)の説明画像

借入と利子を手動で返済する場合は、取引画面の右上にある「借りる」をタップします。

【仮想通貨】BINANCE(バイナンス)のクロスマージンとは？分離マージンとの違いは？わかりやすく解説します。(レバレッジ取引/マージントレード/証拠金取引/用語解説)の説明画像

「返済」をタップし、「返済する通貨」を入力します。表示された内容でよければ「返済承認」をタップします。これで完了です。

ちなみに、借入額と利子はウォレット画面でも確認が可能です。

【仮想通貨】BINANCE(バイナンス)のクロスマージンとは？分離マージンとの違いは？わかりやすく解説します。(レバレッジ取引/マージントレード/証拠金取引/用語解説)の説明画像

ログイン後、トップページから「ウォレット」→「マージントレード用ウォレット」をタップすると確認ができます。

【仮想通貨】BINANCE(バイナンス)のクロスマージンとは？分離マージンとの違いは？わかりやすく解説します。(レバレッジ取引/マージントレード/証拠金取引/用語解説)の説明画像

自動返済の方法は、『返済』をタップし数量を100%と入力し『売却 BTC』をタップします。

ユーザーは、借入した2000USDTは自動で返済され残りが自分の利益となります。

今回は、クロスマージンを選択しているので最大3倍の利益を得ることができます。

以上がマージン取引(マージントレード)の一連の手順になります。

BINANCE(バイナンス)マージントレードで負債がでた場合

仮に返済申請をしポジションを閉じた後に、借入金額を満たしていなかったとします。この場合、担保にしている資金(ウォレット)から自動で返済されることはなく手動で借入額を返済する必要があります。

商品清算手数料
クロスマージンクロスマージン清算資産*2％
分離マージン分離マージンの清算資産額*階層型レバレッジに対応する清算手数料率
仮想通貨ローン仮想通貨ローン清算資産*2%

一時間毎に発生する利子や手数料などは、ポジションクローズ後に精査されるので利確する際は十分に利益を確保しましょう。

清算手数料率 = (清算時のお客様の階層型レバレッジの清算リスク比率 - 1) *8%
(最大 清算後の資産残高の額を超えない範囲で請求する金額を設定されています。

マージントレードでは、潜在的な収益と利益を増加するためにポジションにレバレッジを追加することができます。バイナンスは証拠金レベルを使用して、証拠金アカウントのリスクレベルを評価します。

バイナンスの証拠金レベルとマージンコールの詳細

また、マージントレードにて運用を考えている人はバイナンスの証拠金レベルを把握する事をおすすめします。

買い注文（ロング）の場合は、借入せずに運用することもできるので自分のリスクを管理しながら運用することをおすすめします。

まとめ

マージン取引は資金を借り入れて取引をするので、少ない資金でも大きな利益を出すことができます。その反面、資金を損失してしまうリスクも十分にあります。

  • レバレッジが利用できる
  • 少ない資金でも大きな利益が狙える
  • 買いと売りの両方で利益が出せる
  • 証拠金を意識して取引する必要がある
  • 損失も大きくなりやすい
  • ロスカットのリスクがある

メリット/デメリットを理解した上でマージントレードは利用する必要があります。

利益を大きく出せる分損失も大きくなる可能性もあるので、特に利子の支払いが必要だということは覚えておき、仕組みを理解した上で利用してみてください。

実際にやってみると簡単ですので、余剰資金がある方は実際に取引してみるとより理解が深まると思います。レバレッジを活用したい初心者の方には、先物取引をおすすめします。

最後まで読んでいただきありがとうございました。

https://3mikan.com/archives/2066

【無料】ここから登録するとBinanceの取引手数料10％OFFでお得にトレードできます！

--- # 【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】 今回は少し前に起こった『StableMagnet』というプロトコルのラグプルについて解説していきます。 この事件を調べるにあたってTwitterや海外のニュースサイトを読み込んだのですが、利用している人が少なかったということもあり、それによって事件の詳細が少ないです。 加えてサイトが飛んでしまって状況がよく… 正規URL: https://3mikan.com/archives/1798 著者: みかん 公開: 2021-07-16T20:12:24.000Z 更新: 2022-02-08T11:03:05.000Z

今回は少し前に起こった『StableMagnet』というプロトコルのラグプルについて解説していきます。

この事件を調べるにあたってTwitterや海外のニュースサイトを読み込んだのですが、利用している人が少なかったということもあり、それによって事件の詳細が少ないです。

加えてサイトが飛んでしまって状況がよくわからないままラグられている人が多い印象だったので、正確な情報を終えていないため一部が事実と異なる可能性もあります。

ただ、今回の事件のコード情報が残っているので、その情報をもとに「こういうことができるよね」という話をしたいと思っています。

今後のラグプル対策や自分の資金を守るための知識としてぜひ最後まで読んでもらえたらと思います。

今回のラグプル事件『StableMagnet』の経緯

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

https://www.bsc.news/post/stablemagnet-and-others-rugpull-22m-in-stablecoin-through-unverified-swap-code

こちらのBSCニュースのウェブサイトを翻訳しながら解説します。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

今回2200万ドル(日本円で22億円)をラグプルで抜いたということが記載されています。

正確な被害金額は調査中でまだよくわかっていないようですが、おそらく2700万ドルくらいに昇るんじゃないかと考えられています。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

続いて「StableMagnetのラグプルは新しい攻撃法のおかげです」と記載されていますが、これは今までのラグプルの攻撃法と違うところがあり、明らかに高度化しているという意味になります。

これまでのラグプルだと、サイトを飛ばして引き起こす方法や、ハッキングのポイントをコントラクトの中に仕込んで引き起こす方法が主流だったのですが、今回のラグプルの原因はどちらの方法でもなかったということです。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

続いて「Rugdocが引用した問題は…」とありますが、そもそもRugdoca(ラグドック)が何かというと、ラグリスクなどの情報を一覧化して出してくれるプロジェクトのことをいいます。

なのでここは「Rugdocが挙げた(指摘した)問題は、EtherscanもBscScanもリンクされたライブラリ(依存情報)のソースコードを検証しなかったことにより、攻撃者たちがソースコードに引用されているものとは異なるコードライブラリを展開することができた」という意味になります。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

「攻撃者たちがソースコードに引用されているものとは異なるコードライブラリを展開することができた」というのはどういうことかというと、画像は実際のトランザクションのページの一例ですが、トランザクションを見てみると、StableMagnetSwapのメインのプールに預けていた人の資金が、結果的に誰だかわからない人のウォレットに送られていたことがわかります。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

ちなみにこの３つの合計が大体2200万ドルになります。

(上から順に大体の数字で800万ドル、700万ドル、700万ドル)

詳細な概要

冒頭でも話しましたが、今回この事件について調べるにあたってTwitterや海外のニュースサイトを読み込んだのですが、事件の詳細が少なく、加えてサイトが飛んでしまって原因がよくわからないままの印象でした。


https://www.bsc.news/post/stablemagnet-and-others-rugpull-22m-in-stablecoin-through-unverified-swap-code


StableMagnet: https://bscscan.com/address/0xb89e9365cb5bacfcf4a4b0386dfad45c3b4d3258
Dopple(修正版):
https://bscscan.com/address/0xd108bfe791d7d8bd117b750227de89d0f7056b8e#code


https://bscscan.com/tx/0xf0ba46c8a20e1e75ad382e42c509bf71393e1b3b90326165c747a5d3cc5d967C#eventlog

ただ、今回の事件のコード情報が残っているので、その情報をもとに「これが事件の原因だね」「こういうことができるよね」という話を今からしていこうと思います。

1. 使っているライブラリが独自のものだった

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

「StableMagnetのコントラクト」のCodeを見てみると、コントラクトの名前の欄に「Swap」と記載されていることがわかります。また「File 1 of 7 : Swap.sol」と記載されていますが「これがSwapファイルのメインの機能ですよ」という表示になります。

そして四角の赤枠の部分には「Contract Swap.....」と書かれていますが、この赤枠部分が機能のメイン部分になります。要はこの赤枠部分がStableTableのコントラクトの全てになります。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

続いて、他のコード部分を見てみると「import」と連なって書かれていますが、この部分は「Swap」の中にある小さな各機能を呼び出している状態になります。

例えば赤枠の下から2番目のimportの後にSwapUtilsと書かれている部分がありますが、イメージで言うと、この「Swap」という機能は「SwapUtils」といった様々な小さな機能(パーツ)が組み合わさって(呼び出されて)作られているといった感じになります。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

さらに下にスクロールしてみると、今度はSwapUtilsを構成している各機能がimportの部分に書かれています。(LPTokenやMathUtilsなど)

ちなみに、SwapUtilsというものはいろんなコントラクトで使われているので、基本的にはどのコントラクトでもコピーして使われています。

そしてイメージとしてはこの「Swap」というものが車だとしたら、ドアを構成する部分が「SwapUtils」で、さらにその「SwapUtils」というドアを構成しているものが「LPTokenやMthUtils」などのネジや鉄板にあたる。ということになります。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

なので、このコントラクトのページを見れば、どうのように機能が構成されているのか全て分かると言えます。

そして話を事件概要に戻すと、今回問題になったのはSwapUtilsの部分で、下の画像を見るとSwapUtilsのアドレスの一部を攻撃者が独自で作った全くの別物をimport(呼び出し)して今回のラグプルが起こったことがわかりました。

ぱっと見、名前も一緒で構造も似ていておかしいと思う人がいない、そもそもコードを全部読み込む人なんていないということでここが穴となり、詳しい人なら簡単にラグプルを引き起こせる状態になっていました。

2. Scanにはコードの監査的要素は無いためライブラリが別物でも認証していた

事件の概要や原因について解説してきましたが、やはり監査的要素がないのが決定的でした。

今後は、BscScanやEtherScanに頑張って欲しいなと思いますが、この監査の部分はどうしても人的要素が入るので難しいかな〜とも感じています。

おそらく自動で認証させるくらいしかできないので、Auditに頑張ってもらうべきかなのかなと思っています。

原因となったSwapUtilsをより詳しく解説

ここからはさらに詳しく解説していきたいので、StableMagnetのコントラクト(SwapUtilsのコード部分)と、事件後にDoppleFinanceが最近新しく修正したコントラクト(SwapUtilsのコード部分)を比較しながら解説していきたいと思います。

StableMagnet: https://bscscan.com/address/0xb89e9365cb5bacfcf4a4b0386dfad45c3b4d3258


Dopple(修正版):
https://bscscan.com/address/0xd108bfe791d7d8bd117b750227de89d0f7056b8e#code

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

おそらくこの機能を使ったことがない人が多いと思いますが、上にリンクを貼ったDoppleFinanceのページに飛んで「More option」をタップして「compare」をタップするとコントラクトの比較ができます。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

そして右側の検索窓にStableMagnetのアドレスを貼り付けて「Lookup」をタップすると、それぞれのコントラクトが比較できるようになります。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像
【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像
【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

次にDoppleFinanceのSwapUtilsと、StableMagnetのSwapUtilsを比較したいので、それぞれの「SwapUtils」にチェックを入れて「Compare Difference」をタップします。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

するとこのような表示がされます。左側がDoppleのコントラクトで、右側がStableMagnetのラグが起こった悪いコントラクトになります。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

続いて、先ほどの画面をズラーっと下にスクロールしていくと、途中で色が変わった部分が出てきます。

左のDoppleは825〜836〜836までがオレンジ色で長めに記載されていますが、これはただStableMagnet側の「setBalances(self.....」の部分という機能の部分を展開しただけなので、長くなっているだけです。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

問題なのは、StableMagnetの829行目です。Doppleの837行目とどこが違うかというとsafeTransferの右側にある(msg.sender, dy)と記載されている部分になります。これはmessage senderなのですが、「このコントラクトを実行した人」という意味になります。

右側のStableMagnetのsafeTransferの後ろは(to, dy)となっています。２つを比べると「to」と「msg.sender」が違うことがわかりますが、突き詰めるとこの違いがラグの原因になります。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

他にも、下にスクロールして探してみるとMintの「to」と「msg.sender」の部分が違うことがわかります。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像
【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

他にも何箇所か「to」と「msg.sender」となっている箇所があります。

２つを比較をしてみることで、Doppleが「msg.sender」に修正したところが怪しいな〜と目星がつきますよね。そしてここからさらにどう怪しいのか？どういう仕組みでラグが起こったか？攻撃者はどうんなふうに穴をついたのか？詳しく見ていきます。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

ということでまずはStableMagnetのSwaputilsを実際に見ていこうと思います。

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

まず829行目の青文字のsafeTransferのところですが、すぐ後ろにtoがついています。これは、先ほども見た通りSwapというトランザクションを発行してラグが起こっていました。(トークンを転送していた)

【ラグプル対策】22億円持ち逃げStableMagnetのラグプル事件を解説します。【DeFi】の説明画像

続いて、797行目にもaddressの後ろにtoがついています。

SwapUtilsのまとめ

本来Swapというものは仕組み通り考えれば、例えば自分がBUSDを入れてUSDTをもらうという流れなので「to」を入れる必要はありません。なぜならSwapの元に返せばいいだけだからです。ただ逆を返せばSwapした先に全く違う人を設定することができてしまいます。

要は、自分がBUSDをUSDTに交換した後に、toに他のアドレスを入力しておけば全く違う人にそのトークンを送ることができてしまいます。

なので攻撃者はAddresstoに自分たちのウォレットを設定してSwapという処理を行い結果的にTransferで全て抜き取ったということになります。

これに加えて、今回ラグった後にTwitterやテレグラムなどで「LPを解体したら何もウォレットに反映されませんでした」という報告がちょこちょこ上がっていたのですが、おそらくこれも原因は今話したことだと思います。

簡単に言い換えれば、とりあえずLPは消えずにあり、そしてLP解体もできた。とにかく被害を最小限に抑えるために早く資金を抜こうとLPを解体してみたら全てが消え去った。という感じです。コードを確認してみるとRemoveliquidityのところにあるAddressの後にtoがついていたので、LPを解体したら丸ごと持っていかれるようになっていました。

このことから攻撃者はラグが起こった後のユーザーたちの反応まであらかじめ考察した上で、toの後に引き抜きようのあどれを設定して資金を引っ張っていきました。

まとめ

今回のStableMagnetのラグに関してはあまり正確な情報がなく、コントラクトを見ながら事件の概要と詳細を解説していきました。

ひょっとしたら、元々ユーザーが減っていてそれにより情報的価値もなくなり、インプレッションやエンゲージメントが取れないなどの理由でメディアが取り上げなかったかもしれません。

なので、正確な情報かどうかは正直わからないという感じになっています。とりあえず今回は自分自身でコントラクトを見て調べた結果、今回の理由でラグが起きたのではと思っています。

文章だとわかりづらいという方は、この記事と全く同じ内容のYoutube動画もアップしているのでそちらも参考にしていただければと思います。

【3MIKAN Youtube動画：【DeFi】22億円持ち逃げStableMagnetのラグプル事件を解説します】

最後まで読んでいただきありがとうございました。

--- # 【DeFi】AlphaHomora(アルファホモラ)とは？レバレッジイールドファーミングの特徴や操作方法を解説！ 今回の記事では、AlphaHomora(アルファホモラ)でのBSCレバレッジファーミングについて解説していきたいと思います。 『AlphaHomora』とは、イールドファーミングや流動性提供にレバレッジをかけることができるサービスでAlphaFinance Labが運営するプロジェクトです。 2020年10… 正規URL: https://3mikan.com/archives/448 著者: みかん 公開: 2021-03-20T09:26:55.000Z 更新: 2022-02-04T16:52:11.000Z

今回の記事では、AlphaHomora(アルファホモラ)でのBSCレバレッジファーミングについて解説していきたいと思います。

『AlphaHomora』とは、イールドファーミングや流動性提供にレバレッジをかけることができるサービスでAlphaFinance Labが運営するプロジェクトです。

2020年10月頃にBinance Launch PadにてIEOを実施し、プロジェクトをローンチさせました。

現状Alpha Financeのガバナンストークンとして『ALPHAトークン』を発行しており、投資家はAlphaHomoraを使うことで、イールドファーミングのポジションに2〜3倍のレバレッジをかけて運用することができます。

このAlphaHomoraがバイナンススマートチェーン上でも利用できるようになったので紹介していきます。

AlphaHomora(アルファホモラ)の概要

2HR-Large-1
項目内容
名称AlphaHomora(アルファホモラ)
ガバナンストークン$ALPHA CoinMarketCap （執筆時は$1.85）
ジャンルレバレッジイールドファーミング
URLhttps://homora-bsc.alphafinance.io
チェーンBinance Smart Chain（BSC）
監査状況PeckShieldから監査済み

『AlphaHomora(アルファホモラ)』のジャンルはレバレッジイールドファーミングです。

そのため、『レバレッジイールドファーミング』についてまずは簡単に解説していきたいと思います。

レバレッジイールドファーミングとは？

レバレッジイールドファーミングは、名前の通り「レバレッジ」と「イールドファーミング」の合体です。

ですので、「レバレッジ」と「イールドファーミング」をそれぞれ理解すると意味がわかってきます。

レバレッジとは？

レバレッジとは、運用する元金に倍率を掛けて運用する方法になります。証拠金取引などと呼ばれることがありますね。

例えば、今手持ちの資金が100万円だとしたときに、200万円分を借り入れて300万円として運用するようなイメージになります。実際に、運用するイメージを掴んでもらったほうがこのレバレッジのメリット・デメリットがわかるかと思います。

レバレッジ運用のメリット
  1. 100万円で運用した場合
    →10万円の利益
  2. 200万円を借りて300万円で運用した場合
    →30万円増える→借りた200万円を返す→30万円の利益

上の①②のパターンで元手はどちらも100万円ですが、②のパターンのほうが20万円多く増えていることになります。

月利10%の運用先があったとして、100万円で運用した場合は月の利益が10万円です。ところが、300万円で運用すると月の利益は30万円となります。この仕組み（レバレッジ）を生かして運用していきます。

この例は増えたパターンでしたが、実際には損失も倍率がかかってしまいますので、レバレッジは損益に倍率をかけるものだと思ってください。

イールドファーミングとは？

イールドファーミングとは＞＞＞

AMMに流動性を提供した場合に、報酬としてトークン（通常は預けたものと別のトークン）を受け取る仕組みのことです。

このAMMの仕組みはPancakeSwapなどで当然のように利用されていますので、まだ触れたことがない方はそちらからやってみることをおすすめします。

https://3mikan.com/archives/240

例えば、PancakeSwapの例ですとBNB-BUSDペアを預け入れると、$CAKEを受け取ることができます。

レバレッジイールドファーミングのまとめ

この「レバレッジ」と「イールドファーミング」の組み合わせがレバレッジイールドファーミングとなります。

100万円分のBNB-BUSDペアにレバレッジを掛けて、300万円分のBNB-BUSDのペアとして運用できるようなイメージを持てればOKです。

AlphaHomora（アルファホモラ）のメリット4つ

Alpha Homoraはレバレッジを掛けられるところ以外にもメリットがあります。

AlphaHomoraのメリット
  1. レバレッジをかけてイールドファーミングをしたい（少ない元手で大きな利益を生みたい）
  2. BNBを貸し出して利益を得たい
  3. レバレッジを掛けずに通常のイールドファーミングをしたい
  4. LPペアを作らずにイールドファーミングを開始したい

①レバレッジをかけてイールドファーミングをしたい

これは先程説明したようにAlpha Homoraの特徴になります。

運用開始資金が少なくても、レバレッジをかけることで最大3倍の資金での運用を開始できます。3倍の資金になるということは、利益や損失も3倍になります。

この損失部分の考えもしっかり持った上で運用しましょう。

②BNBを貸し出して利益を得たい

AlphaHomoraではシンプルにBNBを貸し出す（BNBのみでイールドファーミングするイメージ）をすることも可能です。

BNBを入れておけば、あとはAlphaHomoraが全て自動で最適化してくれます。

③レバレッジを掛けずに通常のイールドファーミングをしたい

AlphaHomoraには、イールドファーミングの最適化ストラテジーが搭載されています。簡単に言えば、利益を最大化させるための運用の自動化です。

この仕組みのみを利用したい場合には、レバレッジを1倍に設定して運用すれば、レバレッジをかけずに運用することができます。

④LPペアを作らずにイールドファーミングを開始したい

AlphaHomoraでは、流動性ペア（LPペア）を作らずにトークンを直接入れることができます。

これは、PancakeSwapなどに慣れている方には逆に新鮮かと思います。バイナンスのLiquid Swapなどはこの方式を取り入れていますね。

BNB-BUSDのペアで運用したい場合に、BNB-BUSDのLPを作らずとも、それぞれのトークンを好きな比率で入れることができます。（入れた後に1:1になるように自動で変換されます）

毎回毎回LPペアを作るのが面倒だったという方にはおすすめです。

AlphaHomora(アルファホモラ)の仕組み

AlphaHomoraの仕組みは、レバレッジ倍率に合わせてBNBを借り、それを運用するという仕組みを取っています。

pasted-image-0

例えば、BNB-BUSDペアで運用をする際、1BNBと0BUSDでレバレッジ3倍で運用したとします。

この場合、レバレッジ3倍なので実際に運用されるトークンは3BNB分になります。2BNB分不足しているので、こちらをAlphaHomoraのBNBプールから借り入れます。

2BNB分を借り入れたことで3BNB分となったので、BNB:BUSD=1:1となるように変換されイールドファーミングが開始されます。

イールドファーミングによって得られた収益は一度BNBに変換され、また複利で運用されます。この時、収益の一部が借りたBNBプールに返還されます。（これによって、BNBプールにBNBを預け入れている人にも報酬が入ります。）

AlphaHomoraのやり方

AlphaHomoraの運用開始方法は至って簡単です。LPペアを作る必要がないため、すぐに開始できます。

まずは、AlphaHomoraのサイトにアクセスしてください。

screen-2021-03-20-18.21.32

アクセスすると、運用可能な一覧が並んでいますので、「Farm 3x」などのボタンをクリックします。

【DeFi】AlphaHomora(アルファホモラ)とは？レバレッジイールドファーミングの特徴や操作方法を解説！の説明画像

複数あるファームの中から、運用したいファームをクリックします。すると、各トークンの数量を選択する画面が出てきます。

【DeFi】AlphaHomora(アルファホモラ)とは？レバレッジイールドファーミングの特徴や操作方法を解説！の説明画像

その後は、「Farm 3x」をクリックします。（3xはレバレッジの倍率によって表記が変わります。）

【DeFi】AlphaHomora(アルファホモラ)とは？レバレッジイールドファーミングの特徴や操作方法を解説！の説明画像

実際にポジションが追加されていれば完了です。

AlphaHomora(アルファホモラ)で注意すべき点・リスク

「少ない元手でも利益が大きく出せる」と聞くと、飛びついてしまう人も多いとは思いますが、注意点も理解しておきましょう。

  1. インパーマネントロス（IL, 価格変動ロス）は通常通り発生します。
  2. 借りたBNBに対する証拠金が不足した場合、ポジションが精算されることがあります。
  3. BNBプールには、貸付リスクが存在します。

①インパーマネントロス（IL, 価格変動ロス）は通常通り発生します。

仮にレバレッジをかけずに（1倍で）運用していたとしても、トークン価格の変動による損失は受けます。これは、他のAMMと同様です。

②借りたBNBに対する証拠金が不足した場合、ポジションが精算されることがあります。

借りたBNBに対して、損失が大きくなった場合には自動でポジションが解消され運用が停止される（その時点で借りたBNBは返却される）ことがあります。

FXなどで言う「ロスカット」のイメージです。

③BNBプールには、貸付リスクが存在します。

BNBプールに預け入れているユーザーは、仮にロスカットされたポジションの不足分が精算されなかった場合に、債務リスクを共有することになります。

AlphaHomora(アルファホモラ)のまとめ

AlphaHomoraはレバレッジをかけてイールドファーミングをできるプロジェクトです。

他にも、運用利益の最適化やBNBプールでの運用、LPペアを作らずに運用開始できるなどの特徴があります。

一方で、インパーマネントロスは通常通り受けることや、自動ロスカットの仕組みも存在するため注意しましょう。

--- # 仮想通貨FX(ビットコインFX)おすすめのレバレッジ倍率とは？トレード方法や取引所の最大レバレッジも紹介 今回の記事では、仮想通貨FX(ビットコインFX)の『レバレッジ』について解説していきます。 仮想通貨FX(ビットコインFX)では、レバレッジを活用できることで資金効率を上げることが可能為人気のあるトレード方法の一つです。日本国内では規制により2倍までが上限ですが、海外取引所では100倍や125倍などハイレバ… 正規URL: https://3mikan.com/archives/2971 著者: みかん 公開: 2021-10-10T13:49:42.000Z 更新: 2022-01-24T15:47:21.000Z

今回の記事では、仮想通貨FX(ビットコインFX)の『レバレッジ』について解説していきます。

仮想通貨FX(ビットコインFX)では、レバレッジを活用できることで資金効率を上げることが可能為人気のあるトレード方法の一つです。日本国内では規制により2倍までが上限ですが、海外取引所では100倍や125倍などハイレバレッジ取引を可能とする取引所も多くあります。

ただ、魅力的な取引である反面リスクも大きいので『レバレッジ』の倍率は気をつける必要があります。

仮想通貨FXをまだ取り組んだ事が無い方やはじめたばかりの初心者の方は、この記事を参考にレバレッジの設定について考えていただければ嬉しいです！

仮想通貨のレバレッジ取引とは

レバレッジ取引とは＞＞＞自分の資金を担保に数倍〜数十倍の取引を可能にします。

現物取引と大きく事なる点は、今後の値動きを予測し買い注文（ロング）売り注文（ショート）にて取引を行い、変動した差額分が利益になる点です。

その注文の際に、『レバレッジ』をかけることで少ない資金でも大きな取引を行う事が可能です。

aaaaaaaaaaa-1

（例）1万円（運用資金）×レバレッジ100倍＝100万円

取引所によってはレバレッジを活用することで100万円分のポジションを、1万円の資金で持つ事が可能です。

仮想通貨取引所によってレバレッジの振り幅は異なります。
（日本の取引所は最大2倍・海外は最大888倍）

仮想通貨FXレバレッジ取引のメリット

  • 少額ではじめられる
  • 自分のライフスタイルに合わせる事ができる
  • 売り注文が可能

仮想通貨FXレバレッジ取引のメリットを３つ紹介します。

少額ではじめられる

レバレッジを活用することで、自分の手元にある資金以上の取引が可能になり少額でも運用することが可能です。

2021年10月現在１BTCは500万円ほどです。仮にBybitを利用して1BTCのポジションを持とうとすると、5万円の資金で100倍のレバレッジを利用し1BTC買えると言うことになります。

元手が少ない方でも、このレバレッジ取引を活用することでより大きなリターンを作ることが可能です。

取引上によってレバレッジの幅は異なりますが、より大きい取引がしたい場合は国外の取引所を利用します。個人的には、Binance/Bybitが利用しやすく携帯アプリも対応しているため外出中でも安心して運用が可能です。

自分のライフスタイルに合わせる事ができる

仮想通貨取引所は24時間365日対応しています。

そのため、他の投資と違い取引ができない時間や期間が無いため自分の好きな時間に空き時間を利用して運用していくことが可能です。

売り注文が可能

BTC(ビットコイン)FXでは、売り注文を出すことができます。これにより、下落相場でも利益を出すことが可能な為効率よく資金を運用していくことが可能です。

取引の多くが、安く買い高く売る事だと思いますが、レバレッジ取引は差額分が利益になる取引です。そのため、高い時に売り安くなったら買い戻すという売り注文も行えます。

仮想通貨の相場は、レンジ相場が8割です。上がる時は比較的ゆっくりで下がる時は一気に下る場面が多いため売り注文(ショート)を活用する事も一つの手段です。

仮想通貨FXレバレッジ取引のデメリット

  • 取引コスト
  • 価格変動が激しい
  • 利益を出すほど税率が上がる

仮想通貨FXレバレッジ取引のデメリットを３つ紹介します。

取引コスト

  • レバレッジ手数料（ロールオーバー）
  • スプレッド
  • 強制決済手数料
  • 必要証拠金
  • 拘束証拠金
  • 証拠金維持率

このように、レバレッジ取引には様々な手数料が発生します。取引所によってどんなコストが発生するかは異なるため、取引前に一度確認しましょう。

その中のレバレッジ手数料は、毎日発生する手数料のため長期保有すると大きなコストになりかねないです。

逆に、短期取引のスキャルピングやデイトレードはスプレッド手数料に気をつけてください。この手数料は取引ごとに毎回発生します。スプレッドが広ければ広いほど、ユーザーには損になります。

また、注文の際に成行・指値を選択すると思いますが、比較的にどこの取引所でも、指値注文の手数料が安いです。指値注文を利用して、手数料のコストを抑えることも一つの戦略です。手数料含め利益幅を考えた運用をする必要があります。

価格変動が激しい

BTC(ビットコイン)FXには、ロスカットというポジションが自動で決済されてしまう制度が存在する為損切りラインには、十分注意して証拠金維持率に余裕のある取引が求められます。

価格変動がとても激しい相場であるため、長期で保有する事がリスクになる場合がでてきます。自分の担保とレバレッジによる損切りラインの確認は必ず行いましょう。

翌日に繰り越す事なく、レバレッジをうまく活用する手法などもあるので手数料が発生する前に利確する／価格が暴落する前に利確するといったリスク管理も重要になります。自分のやりやすいやり方にあわせてレバレッジ取引を行っていく事をおすすめします。

利益を出すほど税率が上がる

利益を出すと言う点で税金の知識は重要になります。

仮想通貨ででた利益は雑所得に分類され、所得税は累進課税のため住民税と合わせると最大55％にまでなる可能性があります。

ハイリスクハイリターンなレバレッジ取引ですが、利益を出すという点において損失が出た場合もリスクが大きく利益を出した場合もまた違う問題が出てきますので知識をつけた上で取引を行う事をおすすめします。

https://3mikan.com/archives/2441

仮想通貨FXおすすめのトレード方法とレバレッジ倍率

linecamera_shareimage-1024x644-1.jpeg-1
スキャルピングポジション保有時間数秒〜数分。取引頻度多い。
デイトレードポジション保有時間一日以内。取引頻度やや多い。
スイングトレードポジション保有時間1週間以内。取引頻度やや少ない。
長期トレードポジション保有時間一週間以上 。取引頻度少ない。

仮想通貨FXには、様々なトレード方法があります。

取引期間や取引回数によってもトレード方法は区別されており、相場にあわせて取引方法を変えていくのも一つの手段になります。初心者の方には、デイトレード／スイングトレードがおすすめです。

スキャルピング高レバレッジが基本
デイトレード3~10倍のレバレッジが基本
スイングトレード3~10倍のレバレッジが基本
長期トレード3~10倍のレバレッジが基本

初心者の方はこのレバレッジ倍率を是非参考にしてください。

ファンドなどで仕事として運用しているプロのトレーダーさんでも、レバレッジ10倍を目安として運用するのが基本で、どれくらい相場の価格変動があるかまずは知る事が大事です。

初心者におすすめのレバレッジ倍率

初めてレバレッジ取引を活用する方には、３倍〜5倍のレバレッジがおすすめです。

3倍〜5倍であれば、一時的な相場変動（下落・高騰）でロスカットをされる可能性が下がるため、予期しない損失を減らすことができます。

初心者のうちはしっかりトレンドが読めていても、一時的な相場変動でロスカットされてしまい損失を出すケースが非常に多いので低レバレッジで運用しましょう。

ハイレバレッジにするほど、ロスカットラインが保有ポジションに近くなってしまうので低レバレッジで市場の雰囲気を知りながら運用するのがおすすめです。

仮想通貨FXのレバレッジ取引ができるおすすめの取引所3つ

  • Bitget(ビットゲット)：海外取引所
  • Bybit(バイビット)：海外取引所
  • Binance(バイナンス)：海外取引所

レバレッジ取引でおすすめの取引所を３つ紹介したいと思います。

Bitget(ビットゲット)

銘柄数取引手数料最大レバレッジ
２１指値▶0.04%
成行▶0.06%		125倍

Bitget(ビットゲット)の一番の魅力はコピートレードが可能な所です。

自分自身がコピートレーダーになることも可能ですが、どんなトレードをしていいか分からないという方は、プロのトレーダーさんの運用方法をコピーし自分の資金を運用することが可能です。

また、下記記事からBitgetに登録すると体験金5＄がプレゼントされます。まずは、体験金を利用してレバレッジ取引を始めてみたい方も是非参考にしてください。

https://3mikan.com/archives/2010

Bybit(バイビット)

銘柄数取引手数料最大レバレッジ
１１指値▶−0.025%
成行▶0.075%		100倍

Webサイトやアプリの使いやすさ見やすさを重視したい方はBybit(バイビット)がおすすめです。

レバレッジ取引となると、重要になってくるのがタイミングです。価格変動が激しい相場だからこそ、使いやすさは重視したいポイントだと思います。

また、指値注文の場合手数料を受け取る事ができます。取引回数が今後増えそうだなという方は、他の取引所ではない大きなメリットなので是非参考にしてください。

https://3mikan.com/archives/1945

Binance(バイナンス)

銘柄数取引手数料最大レバレッジ
２６０指値▶0.02%
成行▶0.04%		１２５倍

取引可能な通貨数を重視したい方や安定した流動性となると、Binance(バイナンス)がおすすめです。

Binanceは知名度から分かるように、世界最大級の仮想通貨取引所で取引高は世界1位です。

初めての方からすると使い方が難しいと思う方もいると思います。ただ、国内で買うことができないアルトコインを投資したいという方は、BNBを利用すると手数料が半額になるというメリットも多くあるのでぜひ参考にしてみてください。

https://3mikan.com/archives/2066

仮想通貨FXのレバレッジ取引まとめ

今回の記事では、『レバレッジ』について解説しました。

ハイレバレッジ＝ハイリスクであることをまずは認識する必要があります。

価格変動が激しい仮想通貨の相場では、初心者の方はレバレッジを低く設定することをおすすめします。リスク管理を徹底して行い、余剰資金が少ないうちは利益をちょっとずつ積み上げるのが良いと思います。

自分のリターンが1年後なのか、2週間後なのか目的に合わせて短期で利益を出したいのか、長期的に運用を行いたいのか、時間的な部分で『レバレッジ取引』の運用方法を選択するのもいいでしょう。

少額で運用したい方や生活リズムに合わせて運用したい方など、自分にあった運用方法にあわせてレバレッジ取引を活用してみてください。

--- # 【やり方】ビットコインアービトラージとは？メリット/デメリット・失敗しないコツについて解説します。 今回は「アービトラージ(アビトラ)」について、メリット・デメリット、やり方などを解説していきます。 アービトラージは「リスクが小さい」「短期トレードよりも儲かる」「初心者でもやりやすい」など言われていますが、損失を防ぐために注意しなければいけないポイントがいくつかあります。 今回紹介するアービトラージ(アビ… 正規URL: https://3mikan.com/archives/2381 著者: みかん 公開: 2021-08-24T19:09:15.000Z 更新: 2022-01-24T03:57:56.000Z

今回は「アービトラージ(アビトラ)」について、メリット・デメリット、やり方などを解説していきます。

アービトラージは「リスクが小さい」「短期トレードよりも儲かる」「初心者でもやりやすい」など言われていますが、損失を防ぐために注意しなければいけないポイントがいくつかあります。

今回紹介するアービトラージ(アビトラ)について理解できるようになれば、初心者の方でも比較的取り組みやすいと思うので、ぜひ参考にして見てください。

『アービトラージ(アビトラ)のやり方を知りたい』『仮想通貨取引の幅を増やしたい方』『リスクが低い短期トレードを知りたい』そんな方は是非最後まで読んでください。

仮想通貨のアービトラージ(アビトラ)とは？

アービトラージ-って何？-1

アービトラージとは＞＞＞取引所で仮想通貨の売買を行いその差額を利益化することです。

日本でいう「裁定取引」にあたるもので「アビトラ」とも言われ、比較的リスクが低いという特徴があります。

仮想通貨の場合は、各取引所の価格差が大きいほど利益が出やすいため、複数の口座を開設するのが基本となっています。「安い取引所で買って、高い取引所で売る」という仕組みです。

シンプルな仕組みですが、これから解説するメリット・デメリットを知識として知っておかないと、アービトラージをやってもなかなか利益が上がらなかったり損失を招くことになりやすいので気を付けましょう。

アービトラージ(アビトラ)のメリット・デメリット

アービトラージ(アビトラ)のメリット・デメリットを３つずつ紹介したいと思います。

メリットやおすすめする理由について

  • 知識がなくてもできる
  • 価格差さえあれば24時間取引できる
  • 比較的リスクが小さい

アービトラージは、「安く買って高く売る」という作業の繰り返しなので、仮想通貨の知識が少ない方でも簡単にできる方法です。チャートを見て価格差を見つけることが主な作業なので、投資経験が浅い人でもやりやすいです。

他にも、取引所同士での価格差さえあれば24時間いつでもアービトラージができます。仮想通貨は短時間で価格が乱高下するので、価格差を見つけたらトレードして、どこにいても利益を生み出すことができます。

価格差を利用して利益を上げる方法なので、価格の乱高下による影響を受けにくいと言えます。価格差を見つけた時点で売買すればいいので、短期トレードで利益を出せます。長時間の持ち過ぎで価格変動に巻き込まれ、大損するリスクも少ないです。仕組みもシンプルで簡単なので、初心者の方でも気軽にできます。

デメリットや注意点（リスク）について

  • ローリターンである
  • 売却までに価格変動するリスクがある
  • 「待ち」による時間的拘束がある

取引所同士の価格差は、常に大きく開いているわけではありません。そのため一度の取引でたくさんの利益を生み出すことは難しいです。なので「初心者だから、まずは小さい額で始めたい」という方やお小遣い稼ぎ感覚でやっている方も多いです。もしたくさんの利益を出したいのなら、繰り返しアービトラージするか、他の方法にシフトするかになります。

他にも、仮想通貨の送金には時間がかかります。BTC(ビットコイン)の場合、送金時間までに約10分かかると言われています。もし送金までの間に価格が急降下したら、損することも十分あり得ます。場合によっては送金までに１時間かかることもあるので、売却までの価格変動リスクは常に気にしておくことが大切です。

この送金ラグをヘッジするために、両方の取引所に先に入金しておく方法もあります。例えば、BTCとUSDTを両方の取引所に入れておけば、どちらの方向の売買も即座に行えます。

24時間いつでも取引ができますが、取引するためにはチャートで価格差を見ておく必要があります。そのため、適切なトレードのタイミングを待たなければならず、常にチャートを見ておかなければいけないという時間的拘束があります。「好きな時にだけチャートを見て取引する」という形では、なかなか大きな利益につながらないので、少ない取引で莫大な利益を出したいという人には向いていません。

アービトラージ(アビトラ)のやり方

アービトラージ(アビトラ)手順は大きく分けて４つあります。

ただこの４つのステップを踏むだけでできるので、是非最後まで読んでください。

1. 取引所に口座を開設する

アービトラージは前述しているように、取引所同士の価格差で利益を得る方法です。最低でも3〜4つの取引所で口座を開設しましょう。口座を開設していればその分取引所の選択肢が増えるので、利益が出しやすくなります。

おすすめの取引所は、CoinCheck / GMOコイン / DMM Bitcoin / BitFlyer になります。この４つは比較的取り扱っている仮想通貨が多いので利用しやすいと思います。

2. 日本円での入金をする

それぞれの取引所への登録が済んだら、実際に日本円を入金していきます。利益を出すためにはできるだけたくさん投資することが大切です。というのも、大きい額での入金をすれば手数料負けすることを減らせるメリットがあるからです。「まずは様子を見てみたい」という方は少額から始めて、慣れてきたら投資額を増やしてもいいと思います。

さらに効率よく利益を生み出していくためにも、入金はネット銀行を利用すると手間が省けてスムーズです。ネット銀行を利用する際には「クイック入金対応」をしている取引所を選ぶことも覚えておきましょう。

3. 相場のチェック

各取引所の登録・入金が終わったら、価格差をチェックしていきます。取引所数の目安は4〜5つです。

この時、それぞれの取引所のサイトを開いて価格差をチェックするやり方だと見づらかったり、時間がかかります。効率よく価格差を把握するためには、複数の取引所のBTC(ビットコイン)の価格を一覧で表示してくれるアプリなどを使うとスムーズです。

4. 他の取引所に送金

価格差が大きい２つの取引所が確認できたら、安い取引所から高い取引所へと送金します。この時、あらかじめ登録している全ての取引所にBTC(ビットコイン)を置いておくとスムーズなスタートができます。そして送金ができたら通貨を売却します。

これをすることで、持っていたBTC(ビットコイン)の数量は変わらず、日本円が増えることになります。

アービアービトラージ(アビトラ)のコツ３つ

アービトラージ-って何？-2
  1. 手数料が無料or安い取引所を使う
  2. 値動きが大きいタイミングを狙う
  3. 各取引所にBTCと現金を置いておく

アービトラージ(アビトラ)をやる上で意識して取る組むといいポイント３つ紹介したいと思います。

手数料が無料・安い取引所を使う

仮想通貨のアービトラージでは、購入・売却・送金には手数料がかかります。利益が出ても手数料が高ければ、結果としてあまり儲かっていない、もしくは損している状態になります。

手数料は取引所によって違うので、手数料の安いとこを選んで利用するのも上手くやるための方法です。

値動きが大きいタイミングを狙う

アービトラージで稼ぐ場合は、値動きが大きい時が最適と言えます。取引所同士での価格差が大きく動くので、タイミングを見極めるためにも、まめにチャートをチェックしておくと利益を上げやすいです。

各取引所にBTC(ビットコイン)と現金（またはUSDT）を置いておく

仮想通貨でアービトラージを行う際は、あらかじめ各取引所にBTC(ビットコイン)と現金（またはUSDT）を置いておきましょう。BTC(ビットコイン)は送金に時間がかかります。もし、取引所にBTC(ビットコイン)がない場合はその都度送金しなければいけません。

もたついている間に価格差が縮まり、利益が少なくなる場合があるので、あらかじめBTC(ビットコイン)と現金は各取引所に置いておきましょう。

アービトラージ(アビトラ)まとめ

  • 安い取引所で買って、高い取引所で売る方法をアービトラージという
  • 価格差さえあれば24時間いつでもできる
  • ローリスク・ローリターンのため超初心者でも始めやすい
  • 送金〜売却までに価格が変動するリスクがある

アービトラージについて解説してきましたが、仕組みを理解すれば初心者の方でも始めやすい方法だと思います。ローリスク・ローリターンなので、お小遣い稼ぎでやってみると面白いと思います。

いきなり大金を突っ込むのが怖いという方は、様子を見ながら始めて操作に慣れてきたら額を増やしていくのも一つの方法です。まずは、アービトラージ(アビトラ)の流れを理解し少額から取り組むことをおすすめします。

興味がある方は是非試してみてください。最後まで読んでいただきありがとうございました。

--- # ビットコインFX・仮想通貨でレバレッジ100倍！レバレッジ取引するなら海外？メリット/デメリット 今回の記事では、ビットコインFXの『レバレッジ100倍』について解説していきたいと思います。 大手取引所の一つである、Binanceは2021年7月16日にレバレッジ取引の上限を100倍から20倍に引き下げる事を発表しました。新規ユーザーから適用し徐々に全ユーザーへと反映するようですが、背景にはレバレッジ取… 正規URL: https://3mikan.com/archives/2962 著者: みかん 公開: 2021-10-09T14:29:30.000Z 更新: 2022-01-20T14:00:03.000Z

今回の記事では、ビットコインFXの『レバレッジ100倍』について解説していきたいと思います。

大手取引所の一つである、Binanceは2021年7月16日にレバレッジ取引の上限を100倍から20倍に引き下げる事を発表しました。新規ユーザーから適用し徐々に全ユーザーへと反映するようですが、背景にはレバレッジ取引に対する規制当局の監視が厳しくなっていることが挙げられています。

日本国内の取引所も、2021年5月日本仮想通貨交換業協会（JVCEA）による自主規制により、レバレッジ取引の上限を4倍から2倍までに下げました。

しかし、海外の取引所ではハイレバレッジ取引が可能なところがまだまだ多く存在します。初心者の方は、ハイレバレッジ取引のメリット・デメリットを理解することで自分の資金を守りながらも資産構築に繋げることが可能だと思います。

ビットコインFXで資金効率を上げた運用がしたい方は是非最後まで読んでください。

ビットコインFX・仮想通貨レバレッジ100倍の具体例

ビットコインFXは、レバレッジを活用することで少額でも運用していくことが可能なことから人気のある取引方法になっています。そのため、資金効率の良さが一番の大きなメリットと言えるでしょう。

では、実際にどのくらい資金効率がいいのか図を用いて現物取引と比べてみたいと思います。

aaaaaaaaaaa-1

この図のように、１BTCの売買をするとします。

Aさんは100万円で１BTCを購入し、Bさんはレバレッジを活用したことで１万円の元金で1BTCを持つことができました。

その後相場が上昇し、１BTC=150万円のレートになりそのタイミングで売ったとします。

Aさん・Bさん共に50万円の利益ですが、Bさんはレバレッジを活用したことでかなりお得な取引ができました。

レバレッジ取引を活用すると元本が少額でも、現物取引をしたユーザー同様のポジションを持つことが可能です。これがレバレッジ取引の魅力です。

レバレッジ100倍で利益を出せるパターン

トレンド相場に乗る

利益を出す点において、一番リスクが無いのはトレンド相場に乗る事です。

チャートの上がるタイミングでロング(買い注文)が出せたり、下がるタイミングでショート(売り注文)が出せたり確実に今後の動きを綺麗に予測できた場合には大きな利益に繋がります。

しかし、トレンド相場を見分ける事は簡単ではないです。

レンジ相場が８割の仮想通貨の市場では、トレンド相場は珍しいです。そのため、チャートを見る時間が必然的に増えてきます。本業がある方からすると、トレンド相場の機会に出会うという点が少なくなりそうです。

レバレッジ100倍で利益が出せないパターン

証拠金に余裕がない

投資は、皆さんも知るように簡単な取引ではないです。七割の人が損をしていると言われていますが、レバレッジ取引で利益が出ない理由の一つとして証拠金に余裕がない事が挙げられます。

低資金でもレバレッジを活用することで、資金効率を上げることができる取引ではありますが証拠金＝担保が少ないとロスカットされる頻度が高く、損失が膨らんでいってしまいます。

証拠金残高(口座資金ー損失額)÷必要証拠金(ポジション÷レバレッジ数)×100

＝証拠金維持率

ロスカットは、各取引所が決めた証拠金維持率によって実行されてしまいます。証拠金に余裕を持った取引をすることで、ロスカットはされにくくなります。しかし、大きい値幅により損失が膨らみすぎるとロスカットに繋がり資金を大きく失う可能性はありますのでポジションを持つタイミングが重要になります。

また、手数料を含め利益を出していく必要があります。プラスで利確したのに、資産が手数料分引かれてしまい結果マイナスという事がありますので必ず取引所の手数料は把握し利益幅を考えた運用をしましょう。

仮想通貨FXレバレッジ100倍を使うメリット・デメリット

仮想通貨FXでそもそも100倍のレバレッジが必要なのか？とういう疑問ですが、どんなメリット・デメリットがあるのか紹介したいと思います。

レバレッジ100倍（ハイレバ）のメリット

運用資金が少なく済む

同じ利益幅で運用するのであれば、確実にレバレッジを高く活用した方がお得な取引に繋がります。

レバレッジは高くすればするほど、資金効率を上げることができます。

レバレッジ100倍（ハイレバ）のデメリット

ロスカットが実行されやすくなる

レバレッジを上げれば上げるほど、自分が保持したポジションの近いラインに、ロスカット(強制決済価格)が設定されます。

そのため、少しの変動でもロスカットラインに触れてしまう可能性が高くなりチャートを読む力が必要になるので初心者の方にはおすすめしにくい運用です。

仮想通貨FXは海外取引所なら借金を考えなくていい

海外取引所を利用するメリットの一つに、『ゼロカット』が存在します。

日本国内の取引所を活用する場合『追証証拠金制度』が存在しますが、海外はその制度がありません。

そのため、ユーザーは証拠金以上のリスクがなく安心した取引ができます。

ビットコインFXにおける『追証』とは？

ロスカットの前に証拠金の追加を求められるシステム！

証拠金維持率が取引所で定められている割合より下回った場合や証拠金以上の損失が出てしまった場合に請求されます。

損失が膨らんで来る場合は、どの取引所もロスカットが執行されます。

基本的に、ロスカットが実行されることにより保有資金以上の損失が出てしまうことはありませんが追証がある取引所ではロスカット前に追証が求められるので借金に繋がりやすいので注意が必要です。

レバレッジ100倍におすすめのトレード方法

資金効率が上がっても、リスク管理は非常に重要です。

値動きが激しい仮想通貨の市場では、数秒で相場が大きく変わってしまう事も珍しくないです。そのため、自分なりのルールを作りトレードすることをおすすめします。個人的に意識しているルールを5つ紹介します。

  1. 短期取引で活用する
  2. トレンド相場を活用する
  3. 利食い／損切り設定をする
  4. 指値注文を活用しコストを抑える
  5. 感情で運用せず利確(決済)をしっかり行う

短期トレードは手数料負けしてしまうので避けたいという方もいると思います。しかし、『その日のうちに利確する』『寝る前に利確する』など自分がチャートを見れているうちに利益を確保することも大切です。

また、判断がつきにくいところではありますが、できるだけリスクの低いトレンド相場でレバレッジは活用しましょう。どちらにいくか全く想像がつかないけど買っておきたいという方は現物で保有するのが良いでしょう。

注文を出す際意識したいポイントは２つあります。とくに『ハイレバ（100倍など）』で取引する場合は、利食い／損切りの設定を行い相場に備えること。

取引を行う上でコストに繋がってしまう手数料を削減するためにも、慣れてきたら指値注文で行いコスト削減することです。Bybitでは、指値注文を行うと手数料を受け取ることができるのでかなりお得な取引が可能です。

トレードしていく上で利確するタイミングが非常に重要ですが、感情的になる事なく利益を確実に確保するように利確は徹底して行うのがおすすめです。

レバレッジ100倍におすすめの仮想通貨FX取引所3つ

レバレッジ100倍はどこでも利用できるわけではなく、海外取引所に絞られます。

初めて海外取引所を利用する方からすると少し不安だと感じる方も多いと思います。そのため、マイナーな取引所より実績のある安心した取引所を利用することをおすすめします。

Binance(バイナンス)

銘柄数取引手数料最大レバレッジ
２６０指値▶0.02%
成行▶0.04%		１２５倍

取引可能な通貨数を重視したい方や安定した流動性となると、Binance(バイナンス)がおすすめです。

Binanceは知名度から分かるように、世界最大級の仮想通貨取引所で取引高は世界1位です。

初めての方からすると使い方が難しいと思う方もいると思います。ただ、国内で買うことができないアルトコインを投資したいという方やバイナンスが提供している多くのサービスを利用し仮想通貨の運用の幅を増やしたいという方には特におすすめです！

https://3mikan.com/archives/2066

また、BNBを利用すると手数料が半額になるというメリットも多くあるのでぜひ参考にしてみてください。

Bybit(バイビット)

銘柄数取引手数料最大レバレッジ
１１指値▶−0.025%
成行▶0.075%		100倍

Webサイトやアプリの使いやすさ見やすさを重視したい方はBybit(バイビット)がおすすめです。

レバレッジ取引となると、重要になってくるのがタイミングです。価格変動が激しい相場だからこそ、使いやすさは重視したいポイントだと思います。

https://3mikan.com/archives/1945

また、指値注文の場合手数料を受け取る事ができます。取引回数が今後増えそうだなという方は、他の取引所ではない大きなメリットなので是非参考にしてください。

Bitget(ビットゲット)

銘柄数取引手数料最大レバレッジ
２１指値▶0.04%
成行▶0.06%		125倍

Bitget(ビットゲット)の一番の魅力はコピートレードが可能な所です。

自分自身がコピートレーダーになることも可能ですが、どんなトレードをしていいか分からないという方は、プロのトレーダーさんの運用方法をコピーし自分の資金を運用することが可能です。

https://3mikan.com/archives/2010

また、今ですとBitgetに登録すると体験金5＄がプレゼントされます。まずは、体験金を利用してトレードを始めてみたい方も是非参考にしてください。

仮想通貨FXレバレッジ100倍まとめ

今回の記事では、ビットコインFXのレバレッジ100倍について解説しました。

海外の取引所を利用しレバレッジ100倍の取引ができるという点は、資金効率を考えるととても魅力な取引です。

ただ、少ない資金で大きい利益を得ることができる反面ロスカットの可能性には注意した運用スキルが求められます。初心者の方は、やみくもにハイレバレッジ取引を行うより5倍〜10倍のレバレッジから挑戦しチャートを読み解く感覚を掴むという点が大切になるかもしれません。

また、仮想通貨の相場は、値幅がとても大きいので『余裕資金』で運用するのが望ましいです。自分にあった取引方法に合わせて、リスク管理をした上でレバレッジ100倍を活用してみてください。

--- # 【最新版】仮想通貨のロスカットとは？仮想通貨FXの強制決済価格(ロスカット)の計算方法・レバレッジからロスカットを計算【証拠金維持率の計算】 今回の記事では、強制決済価格（ロスカット）について解説していきたいと思います。 仮想通貨を運用していくにあたって、『強制決済価格があるのは知っているけど、わざわざ計算するのは面倒でしていない。』という方が多いと思います。しかし、事前に強制価格を知ることでリスク管理に繋げることが可能です。 また、仮想通貨FX… 正規URL: https://3mikan.com/archives/2918 著者: みかん 公開: 2021-10-05T14:46:42.000Z 更新: 2022-01-14T17:46:35.000Z

今回の記事では、強制決済価格（ロスカット）について解説していきたいと思います。

仮想通貨を運用していくにあたって、『強制決済価格があるのは知っているけど、わざわざ計算するのは面倒でしていない。』という方が多いと思います。しかし、事前に強制価格を知ることでリスク管理に繋げることが可能です。

また、仮想通貨FXはレバレッジ取引を可能にすることで資金効率を上げることが可能です。その反面、レバレッジを高くすればするほどロスカット(強制決済)がされやすくなります。タイミングが悪ければ注文を発注した数秒でロスカットされてしまう場合もでてきます。

そのため、事前に計算し強制価格を知っておくことでチャートと照らし合わせて注文を出すタイミングが決めやすくなります。自分の資金を守る手段の一つとして、是非最後まで読んで頂ければと思います。

仮想通貨FXの基礎知識：レバレッジ・ロスカットとは？

レバレッジ取引とは＞＞＞自分の資金を担保に数倍〜数十倍の取引を可能にします。

（例）1万円（運用資金）×レバレッジ100倍＝100万円

レバレッジをかけることで100万円分のポジションを、1万円の資金で持つ事が可能です。

仮想通貨取引所によってレバレッジの振り幅は異なります。
（日本の取引所は最大2倍・海外は最大888倍）

ロスカットとは「強制決済価格」のこと

レバレッジ取引を行う際『ロスカット』という用語をよく聞くと思いますが、強制決済価格を意味しています。

ロスカットとは＞＞＞取引所が設定している証拠金維持率を下回ると保持しているポジションが強制的に自動で決済される制度です。

強制的に取引を終了させられてしまう(ロスカット)と聞くとどこか悪いイメージがありますが、自分の資金をこれ以上失わない制度でもあります。

【最新版】仮想通貨のロスカットとは？仮想通貨FXの強制決済価格(ロスカット)の計算方法・レバレッジからロスカットを計算【証拠金維持率の計算】の説明画像
Binanceは、右下に清算価格(強制決済価格)が表示されています。
【最新版】仮想通貨のロスカットとは？仮想通貨FXの強制決済価格(ロスカット)の計算方法・レバレッジからロスカットを計算【証拠金維持率の計算】の説明画像
Bybitは、右下に強制価格が表示されています。

この強制決済価格と同じくらい耳にするのが『追証』だと思います。

追証とは＞＞＞保有しているポジションに対して一定の損失が出てしまった場合、追加で資金をいれる必要がでてくる制度のこと。

追証はこの『ロスカット(強制決済価格)』より前に請求されるものです。

ロスカット追証の違い

追証のルールもロスカット同様に取引所によって異なりますが、基本的に証拠金維持率が満たしていない場合追証の請求が発生し決済する必要があります。

この請求を、期日までに解決しなかった場合その時点で強制決済されこれを『追証ロスカット』と言います。

ロスカット追証の違いとは＞＞＞発生する基準が異なる。

ロスカットは担保の証拠金以上の損失を防ぐための『損切り』です。一方追証は、相場変動による必要証拠金の不足分の請求になります。

どちらも証拠金維持率に余裕があれば行われないものなので、取引する際は資金に余裕を持って取り組むのがおすすめです。

なぜ「ロスカット」は行われるのか

『ロスカット』は、自分が取引口座に入れた資金に対して、損失が拡大しすぎないように強制決済される仕組みになっています。

そのため、『ロスカット』が行われる意味としては損失の拡大を一定におさめる保護対策になると考えます。

ロスカットルールの比較

取引所によってロスカット（強制決済価格）のルールは異なりますので自分の利用している取引所がすでにある方は再度確認してみてください。

取引所名証拠金維持率
bitFlyer  50 %を下回った時点でロスカットルールが適応。
GMOコイン30%を下回った時点でロスカットルールが適応。
BINANCE100%を下回った時点でロスカットルールが適応。
Bybit証拠金維持率を基準としておらず、独自の「破産価格」を基準としている。※要確認

海外と国内の取引所でも大きな違いがあります。海外取引所を利用したトレードの方がリスク管理がしやすいかもしれません。

証拠金維持率の計算方法

上記でお伝えしたように、証拠金維持率を下回るとロスカットが実行されてしまいます。事前に証拠金維持率を求め担保資金やポジションを決めた運用はリスク管理につながります。

証拠金残高(口座資金ー損失額)÷必要証拠金(ポジション÷レバレッジ数)×100

＝証拠金維持率

証拠金維持率の計算方法はこのように求められる為、自分が設定する『レバレッジ』によってもロスカット(強制決済価格)は変化します。excelなどで自分の早見表などを作成するのがおすすめです。

FX計算ツールがあったのでこちらを参考にするのもいいかもしれません。こちらから▶FX計算ツール

仮想通貨FXでのレバレッジとロスカットの関係

レバレッジを設定する際『分離マージン』『クロスマージン』の選択が求められます。

このマージンによってもロスカット(強制決済価格)に違いがありますので確認が必要です。

分離マージンは自動的にロスカット価格が決まる

レバレッジ取引の分離マージンとは？

証拠金の一部のみをポジションに利用します。

強制決済時には、初回の証拠金と保持しているポジションに後から追加した証拠金のみが失われます。

分離マージンの場合＞＞＞注文時の証拠金に応じてロスカット価格は自動的に決まります。

ポジションに利用される証拠金は、トレーダーの口座残高から分離される機能です。

クロスマージンは口座残高に応じてロスカット価格が決まる

レバレッジ取引のクロスマージンとは？

証拠金口座内の利用可能残高すべてをポジションに利用します。

強制決済時には、利用可能残高すべてが失われます。

クロスマージンの場合＞＞＞ロスカット時の口座残高に応じてロスカット価格が決まります。

ポジションに利用される証拠金は、自動的にトレーダーの口座から補充される機能です。

補足：レバレッジ1倍の場合はロスカットが存在しない

【最新版】仮想通貨のロスカットとは？仮想通貨FXの強制決済価格(ロスカット)の計算方法・レバレッジからロスカットを計算【証拠金維持率の計算】の説明画像

レバレッジ取引では、このようにレバレッジ１倍での取引も可能です。

１BTC＝$50,000の際にレバレッジ１倍でポジションを保有したとします。

証拠金維持率の計算方法に当てはめると、100%損失（ロスカット）になる場合１BTC自体に価値が全くない事を意味します。

そのため、BTC自体がなくならない限りレバレッジ１倍の取引ではロスカットは存在しないと言えるでしょう。長期で運用したい人にはおすすめです。

仮想通貨FXのロスカット計算方法のまとめ

追証やロスカット(強制決済価格)は、仮想通貨取引所によって定められている証拠金維持率によって求めることが可能です。

証拠金維持率は取引所によって異なりますので、ご自身が利用している取引所のガイドラインを事前に確認することをおすすめします。

証拠金についてより詳しい内容を知りたい方は下記記事を参考にしてください。最後まで読んでいただきありがとうございました。

https://3mikan.com/archives/2587
--- # 【最強！？】ビットコインFXの両建ては勝ちやすい？やり方・両建てできる取引所・FXで両建てするメリット/デメリットを解説します。 今回の記事では、ビットコインFXの手段の一つにある『両建て』について解説していきたいと思います。 仮想通貨の相場は、８割がレンジ相場と言われており予測することが非常に難しいです。そのため、自分の資金を大きく失わない為にもリスク管理をしっかり行う必要があります。 今回紹介する両建ては、リスクヘッジの一つとして… 正規URL: https://3mikan.com/archives/2897 著者: みかん 公開: 2021-10-03T12:54:28.000Z 更新: 2022-01-12T10:02:35.000Z

今回の記事では、ビットコインFXの手段の一つにある『両建て』について解説していきたいと思います。

仮想通貨の相場は、８割がレンジ相場と言われており予測することが非常に難しいです。そのため、自分の資金を大きく失わない為にもリスク管理をしっかり行う必要があります。

今回紹介する両建ては、リスクヘッジの一つとして活用されることがあり初心者の方には難しい手法ではありますがポイントをしっかりおさえてリスクヘッジの手段として覚えて頂ければと思います。

  • Binance(バイナンス)での両建てをマスターしたい！
  • 仮想通貨取引のリスク管理として学びたい！
  • 仮想通貨の運用をはじめたいけど暴落に巻き込まれるのが怖い！

こんな方向けの記事になっています。当てはまる方は是非最後まで読んでみてください！

両建てとは？

両建てとは＞＞＞同じ通貨の、買いと売りのポジションを２つとも持つことを『両建て』と言います。

相場が激しい仮想通貨は、予測が難しい為リスクヘッジとして活用することが可能です。

長期保有したい場合やハイレバレッジでの取引の際には向いていませんが、短期取引や損失をおさえたい場合にレバレッジを低く設定し活用するのがおすすめです。

では、仮想通貨FXでの両建てについてより深堀りして解説していきたいと思います！

ビットコインFXにおける両建ての具体例

仮想通貨の相場は、『トレンド相場』と『レンジ相場』の2種類に分けられます。

通常レンジ相場が多いですが、両建てを活用する際は『レンジ相場』で活用してください。

同時に同じ数量のポジションを保有する場合

下の2つのポジションを持っているような状態です。

  • 1BTC=$50,000のところで買いポジション
  • 1BTC=$50,000のところで売りポジション
異なるタイミングで同じ数量のポジションを保有する場合

下の2つのポジションを持っているような状態です。

  • 1BTC=$50,000のところで買いポジション
  • 1BTC=$53,000のところで売りポジション

両建てはビットコインFXでのみ可能（現物では不可能）

  • 同じ通貨ペア
  • レバレッジ取引が可能
  • ロング(買い)／ショート(売り)ポジションどちらも保有

両建てが成立する条件は上記です。

現物取引では実際に日本円とBTCなどの取引する方法となり「ショート（空売り）」自体ができないので、『両建て』を行う事はできません。

ビットコインFXで両建てを行うメリット

  • 損失を相殺することができる
  • どちらも利益になる場合がある

ビットコインFX（仮想通貨FX）で両建てを行うメリットを２つ紹介します。

損失を相殺することができる

両建ては常に利益が出ていますが、同時に損失も同等にでている状態です。

同じ市場価格の『売りポジション』『買いポジション』を持つということは、価格が上がっても下がっても損益はほとんどありません。両建てした瞬間に含み損が固定されそれ以上は増えも減りもしないです。

そのため、予想と逆の動きをしてしまうとリスクが大きいレンジ相場の場合、損失を相殺してくれる点がメリットとして挙げられます。

どちらも利益になる場合がある

  • 1BTC=$50,000のところで買いポジション
  • 1BTC=$50,000のところで売りポジション

１BTC＝$50,000のレートでポジションを両建てで保有したとします。

相場が上昇し、１BTC＝$55,000のラインで利確し、その後相場が反転し下落。

売りポジションはそのまま放置し、１BTC＝$44,000まで下がったところで利確。

このように、利確するタイミングが良ければ両方のポジションで利益を出せる可能性があります。

ビットコインFXで両建てを行うデメリット・注意点

  • 取引手数料が1個のポジションよりも多くかかる
  • 両建てできない取引所がある
  • スプレッドに注意しないといけない

両建てを行う際に気をつけたいポイントを３つ紹介します。

取引手数料が1個のポジションよりも多くかかる

両建ての場合、2つのポジションを保有する為かかる手数料も倍になります。

必要証拠金も数量に応じて多くなるため、ロスカットがされやすくなります。

※取引所によっては必要証拠金も相殺される可能性があります。両建てをした場合、必要証拠金は0になります。

両建てできない取引所がある

世界最大級の取引所のBinanceは『両建て』ができない取引所の一つです。

日本の取引所は基本的に両建ての取引が可能ですが、出来高の大きい主要取引所(海外の取引所)は禁止にされている場合があります。

取引所によって両建ての証拠金ルールを設けている場合がありますので、利用される場合は事前に確認しましょう。

スプレッドに注意しないといけない

両建て取引は、取引が二重になるため、スプレッドコストも２倍に広がってしまいます。

レンジ相場の多い仮想通貨の市場では、値動きが大きくなることでスプレッドが拡大してしまいます。

これにより、含み損益が増えてしまう事が多いです。そのため、流動性が低い時間には両建ては行わないなどルールを決めてスプレッドに注意した取引が必要になります。

ビットコインFXの両建ては必ず利益が出せる？

両建ては場面によってはリスクを回避してくれる手法ですが、『必ず利益になる』という確信がある取引ではありません。以下の点を理解し安易にはじめられる簡単な取引ではないという事を知ってほしいです。

両建ては上級者向けの戦略

『両建て』は、両方のポジションを保有することにより大きな損失が出ることはありません。その反面、どちらかが利益の場合どちらかが損失なので利益が大きくなることもありません。

メリットで紹介したように、運が良ければ両方のポジションにて利益を出せる可能性があります。ただ、チャートが上下に往復する必要があり利確のタイミングが難しいため、上級者向けの取引方法になります。

上手く利確した後に反転すれば良いですが、そのままトレンドが継続した場合などは損失が大きくなります。

初心者の方は、難易度のある取引をするよりまずはロング(買い)／ショート(売り)ポジションのどちらか片方の取引にしぼりトレードすることをおすすめします。

初心者は「両建て」＝「利確・損確」と意識すること

noname

逆指値をリスクヘッジとして使う際に『利確・損切』という言葉がでてきます。

それは、上の画像のAさんBさんが同じ結果になることを利用しています。

AさんとBさんが同じタイミングで１BTCを保有したとします。

Aさんは60,000$に利食注文を入れました。
Bさんは60,000$に売りの指値注文を入れました。

60,000$に到達したのでAさんは利確。
▶10,000$の利益確定。

Bさんは売りの注文が入り『両建て』の状態になります。
▶両建てのポジションを持った時点で10,000$の利益が確定しています。

つまり、AさんとBさんは注文方法は違いますが同様の決済を行っていることになります。
（両建てができない取引所の場合はBさんの取引は自動的にAさんの取引と同様になります）

【最強！？】ビットコインFXの両建ては勝ちやすい？やり方・両建てできる取引所・FXで両建てするメリット/デメリットを解説します。の説明画像

両建てができない取引所の場合はこのように、売りの注文を入れようとすると利確(利食)になるのでポジションを持つ証拠金は発生しません。

新しくポジション持たなくとも現状のポジションを決済することで希望の注文方法を実現できるため、新規ポジションのための証拠金が不要になるのです。

ビットコインFXの両建てでは「スワップポイント狙い」は難しい

スワップポイントとは？

スワップポイントとは「金利差調整分」と呼ばれています。

2カ国間の金利差によって発生する利益です（※逆に、低金利の国の通貨を買って高金利の国の通貨を売る場合は、金利差分のスワップポイントの支払いが発生します）。

メリットとしては、決済を行ってそのポジションを解消しない限り、利益を毎日獲得できることです。

ビットコインFXでは、ロング(買い)／ショート(売り)のポジションを保有するとスワップポイントが発生します。（資金調達率と表現されます）

基本的にはロング・ショートのどちらかが「金利を受け取る側」となり、逆が「金利を支払う側」となります。

https://3mikan.com/archives/2939

法定通貨FXの場合ロング・ショートの両方がプラス金利になることがあり、その場合は両建てをするとスワップポイントで利益を出すことができます。両建ての為、ポジションによる損失を出すこともないため人気な手法です。

しかし仮想通貨FXの場合はこの「金利の支払い・受取」のタイミングで取引所の手数料も支払う必要があり、ロング・ショートの両方ともマイナスになるケースが多いです。

そのため、ビットコインFXではスワップポイント狙いの両建ては難しいと考えます。

ビットコインFXの両建てができるおすすめ取引所3選

ビットコインFXで両建てを行う際、取引手数料を意識し取引することをおすすめします。

Bybit(バイビット)：海外取引所

銘柄数取引手数料最大レバレッジ
11指値▶−0.025%
成行▶0.075%		100倍

Webサイトやアプリの使いやすさ見やすさを重視したい方はBybit(バイビット)がおすすめです。

レバレッジ取引となると、重要になってくるのがタイミングです。価格変動が激しい相場だからこそ、使いやすさは重視したいポイントだと思います。

また、指値注文の場合手数料を受け取る事ができます。取引回数が今後増えそうだなという方は、他の取引所ではない大きなメリットなので是非参考にしてください。

https://3mikan.com/archives/1945

Bitget(ビットゲット)：海外取引所

銘柄数取引手数料最大レバレッジ
21指値▶0.04%
成行▶0.06%		125倍

Bitget(ビットゲット)の一番の魅力はコピートレードが可能な所です。

自分自身がコピートレーダーになることも可能ですが、どんなトレードをしていいか分からないという方は、プロのトレーダーさんの運用方法をコピーし自分の資金を運用することが可能です。

また、下記記事からBitgetに登録すると体験金5$がプレゼントされます。まずは、体験金を利用してトレードを始めてみたい方も是非参考にしてください。

https://3mikan.com/archives/2010

GMOコイン：国内取引所

国内の取引所から利用したい方や、費用を抑えて取引をしたい方にはGMOコインがおすすめです。

GMOコインは他の取引所とは違って「入金・出金・送金・取引」すべての手数料が無料です。さらに、専用のスマホアプリがあるのでいつでも状況を確認することができ、簡単に取引ができます。

仮想通貨投資（取引）を始めるには「仮想通貨用の口座開設」→「日本円の入金」→「仮想通貨の購入」が必要です。その後「仮想通貨の売却」→「日本円の出金」という取引の流れになります。そのため、仮想通貨初心者の方でも簡単に始めやすい「GMOコイン」も選択の一つとして是非参考にしてください。

https://3mikan.com/archives/224
--- # 【短期トレード】ビットコインFXのデイトレードとは？仮想通貨初心者こそ覚えたいトレード方法を徹底解説。【メリット・デメリット】 今回の記事では、トレード方法の一つであるデイトレードについて紹介していきたいと思います。 仮想通貨のトレード方法はいくつかあります。取引期間や取引回数によっても区別されており、相場にあわせて取引方法を変えていくのも一つの手段だと思います。 また、自分なりのルールを持つことで安定したトレードにつなげることが可… 正規URL: https://3mikan.com/archives/2168 著者: みかん 公開: 2021-08-19T11:09:36.000Z 更新: 2022-01-08T01:41:25.000Z

今回の記事では、トレード方法の一つであるデイトレードについて紹介していきたいと思います。

仮想通貨のトレード方法はいくつかあります。取引期間や取引回数によっても区別されており、相場にあわせて取引方法を変えていくのも一つの手段だと思います。

また、自分なりのルールを持つことで安定したトレードにつなげることが可能だと思っているので、SNSで情報を拾いながら勉強するのも良いでしょう。自分のライフスタイルに合わせた運用方法で、無理なく続けられるといいなと思います。

このブログでは、『なんとなく始めたけど、仮想通貨取引にはどんな手法があるの？デイトレードは仮想通貨に向いてるの？』そんな疑問がある方は是非最後まで読んでいただければと思います。

仮想通貨FXのデイトレードとは？

デイトレードとは＞＞＞一日のうちにポジションの売買を終わらせる事を言います。

linecamera_shareimage-1024x644-1

その他にも、スキャルピングトレード／スイングトレード／長期トレードと期間でトレードする手法がありますが、この中で二番目に短い取引方法になるのがデイトレードです。

スキャルピングポジション保有時間数秒〜数分。取引頻度多い。
デイトレードポジション保有時間一日以内。取引頻度やや多い。
スイングトレードポジション保有時間1週間以内。取引頻度やや少ない。
長期トレードポジション保有時間一週間以上 。取引頻度少ない。

ビットコインFXデイトレードのメリット

デイトレードは次の日にポジションを保有することなく、利確を終える方法の一つですがどのようなメリットがあるのか紹介したいと思います。

リスクを抑える事ができる

仮想通貨の相場はボラティリティが激しいです。朝起きると、暴落している事が多々あります。

そのため、一日以内で取引を成立させるという事はリスクヘッジにも繋がります。

仮想通貨取引所は、24時間取引が可能

株式やFXでは、取引時間が限定され利用できない時間もあります。それに比べて、仮想通貨取引所は24時間365日取引が可能です。

そのため、自分の時間にあわせ好きな時にトレードが可能です。

仮想通貨の相場変動と相性がいい

仮想通貨の相場の変動は激しいですが、この相場がデイトレードには向いていると思います。

そのため、この振り幅があればあるほど取引チャンスや利益拡大のタイミングは増えます。

ビットコインFXデイトレードのデメリット

デイトレードは魅力的な手法ではありますが、デメリットもあります。理解した上で実践されることをおすすめします。

手数料のコストが膨らむ可能性がある

プラスで利確したはずなのに、なぜか資金が減っている。短期取引をしているとそんな場面に遭遇することもあるかもしれません。仮想通貨取引では、取引所毎にいろんな種類の手数料があります。

取引毎に手数料は発生するため、デイトレードは取引頻度と利幅を頭に入れ利益を出す必要があります。

https://3mikan.com/archives/2344

安易に始められるほど簡単な取引ではない

初心者だけでなく、経験あるトレーダーさんでも勝ち続ける事は難しいです。仮想通貨FXにはロスカットがあるように、自分のポジションと同時に損切りラインも決まります。そのため、闇雲にトレードするのではなくまずは少額からスタートしトレードする流れや感覚を掴んでいきましょう。

はじめは少額からトライし、余剰資金で行う事をおすすめします。

感情に流されやすくなる

相場の変動によって自分の感情が左右されることがあります。短期トレードであればあるほど、ここの課題はでてくると思います。利確を行うのが早すぎたり、利確するタイミングを逃してしまったり…。

感情的になりがちだと思う方は、事前に利食・損切注文を必ず行い心に余裕の持てるトレードをしましょう。

ビットコインFXデイトレードで勝率をあげるコツと注意点

注意点を知ることで勝率を上げるコツにつなげることもできるので、個人的に意識しているポイントを３つ紹介したいと思います。

流動性が高い通貨や取引所を選ぶ

仮想通貨取引では、流動性が低いと買いたいけど買えない・売りたいけど売れなくなってしまいます。ポジションを持つタイミングが非常に大切になるので、『買いたい時に買える／売りたい時に売れる』取引所を選びましょう。

通貨によっても大きく違うので、流動性は一つ確認したいポイントです。

https://3mikan.com/archives/2117

勉強をしスキルをつける

必ず勝てる必勝方法があるわけではありませんが、チャートの見方や分析・手法などを勉強し身につける事は大切だと思います。はじめのうちは情報を得ることに苦戦するかと思いますが、習慣にすることで知識が活躍する場面が増えてきます。

トライアンドエラーでチャートを分析しながら、自分にあった取引方法をみつけることが大切だと思います。

売り注文も可能なレバレッジ取引をうまく活用する

仮想通貨取引の一つに、レバレッジ取引があります。売り注文もできる為、激しい相場とデイトレードの相性は良いと思います。レバレッジ取引を活用して、利益拡大に繋げてみるのもおすすめです。

現物と違い、この売り注文を利用することで資金効率を上げた仮想通貨取引をすることができます。

  • 取引高1位Binance(バイナンス)

Binance Japanの運営会社・登録・提供サービスを確認

  • 初心者でも使いやすいBybit(バイビット)

スプレッドが最も小さいBybit（バイビット）の使い方！現物・レバレッジ取引を徹底解説！

  • 自動で稼ぐ？忙しい方におすすめのBitget(ビットゲット)

コピートレードが可能！Bitgetの体験金で先物取引スタート！キャンペーン・使い方を解説！

まとめ

今回はデイトレードについて紹介しました。この取引戦略が一番いいというわけではなく、大切な資金を失う可能性も十分にあります。リスク含め、自分にあったトレード方法を是非みつけていただければと思います。

まずは、少額から様々な取引を経験してみることをおすすめします。

また、デイトレードよりも短いトレードを『スキャルピング』と言いますが、こちらについて興味がある方は是非下記記事を参考にしてください。

https://3mikan.com/archives/2415
--- # 【初心者向け】仮想通貨(ビットコイン)のスプレッドとは？スプレッドの見方・確認したいポイント・各取引所を徹底比較 今回は仮想通貨の「スプレッド」についてわかりやすく解説していきたいと思います。 仮想通貨の運用を始めると「スプレッド」という言葉をよく聞くと思いますが、取引をしていく上でかなり重要なポイントになります。 スプレッドとは簡単にいうと「手数料(のようなもの)」なのですが、特に短期トレードをする方は、損をしないた… 正規URL: https://3mikan.com/archives/2685 著者: みかん 公開: 2021-09-15T15:08:24.000Z 更新: 2022-01-06T14:40:40.000Z

今回は仮想通貨の「スプレッド」についてわかりやすく解説していきたいと思います。

仮想通貨の運用を始めると「スプレッド」という言葉をよく聞くと思いますが、取引をしていく上でかなり重要なポイントになります。

スプレッドとは簡単にいうと「手数料(のようなもの)」なのですが、特に短期トレードをする方は、損をしないためにもスプレッドについて知識をつけておくことをお勧めします！

『スプレッドは広い方がいい？狭いほうがいい？』『スプレッドの見方が分からない』「取引手数料とスプレッドの違いって何」などスプレッドについての知識をこのブログで知ることができます。是非最後まで読んでみてください。

仮想通貨（ビットコイン）のスプレッドとは？

スプレッドとは＞＞＞買う時と売る時の「価格の差」のことを言います。

仮想通貨だけに限らず、FXでも使われている言葉です。FXでは価格の変動が起こった際に通貨の売り買いをすることで利益を出すことができます。

例えば、BTC(ビットコイン)で例えると＞＞＞「1BTCの購入価格が105万円、売却価格が100万円」であれば、スプレッドは5万円となります。仮に105万円で購入し、100万円で売却すると5万円の損が出ます。なので利益を上げるには1BTCの価格が5万円上昇するまで待たなければいけません。

このことから取引をする際は、「スプレッドは狭い(少ない)方が良い」ということがわかります。

そしてこのスプレッドは取引所によって差があるので、いろんな取引所を比較した上で利用するとお得に取引ができます。

仮想通貨のスプレッドは手数料とは違うの？

仮想通貨の取引には大きく分けて「販売所形式」と「板取引」の２つの方法があります。

多くの取引所では、通貨の取引(購入/売却)の際に「取引手数料」が徴収されますが、「販売所形式」の時だけスプレッドが手数料として徴収されます。

なのですべての取引所で、このスプレッドが手数料として徴収されるわけではありません。しかし、販売所にとってはスプレッドは貴重な収入源なので、"販売所"においては「スプレッド=手数料」と言えます。

取引所と販売所でスプレッドは異なる？

仮想通貨の取引ができる場所は「取引所」と「販売所」の2種類があります。

「取引所」とは＞＞＞取引所に参加しているユーザー同士で取引をこなうため、自分の希望する購入価格・売却価格を提示することが可能です。なのでユーザー同士の希望価格がマッチすれば、スプレッドが狭い状態での取引が行えます。

「販売所」とは＞＞＞販売所を運営する企業とユーザーの間で取引が行われます。企業がすでに購入価格・売却価格を設定しているので、ユーザーは設定された価格で取引を行うことになります。

このことから、仮想通貨をお得に取引したいなら取引所の利用がおすすめです。

これに加えて、取引量の多い取引所はスプレッドが小さく、取引量の少ない取引所はスプレッドが大きい傾向にあります。例えば、取引量の多いビットコインと取引量が少ないリップルのスプレッドを比較すると、開きに差があることがわかります。

安くお得に利用したい方は、アルトコインのスプレッドは注意し取引することを覚えておきましょう。

スプレッドが小さい取引所を選ぶポイント３つ

取引所をスプレッドで比較するポイントは３つです。

  1. 取引所を利用する
  2. スプレッドは同じ時間帯で比較する
  3. 通貨ごとに取引所を変える

取引所を利用する

前述したとおり、スプレッドは狭い方がお得なので「販売所」ではなく「取引所」を利用する方がおすすめです。

基本的に国内取引所より海外の取引所はスプレッドが小さいので、よりお得に利用したいと言う方は海外取引所を利用することをおすすめします。

  • 取引高1位Binance(バイナンス)

Binance Japanの運営会社・登録・提供サービスを確認

  • 初心者でも使いやすいBybit(バイビット)

スプレッドが最も小さいBybit（バイビット）の使い方！現物・レバレッジ取引を徹底解説！

  • 自動で稼ぐ？忙しい方におすすめのBitget(ビットゲット)

コピートレードが可能！Bitgetの体験金で先物取引スタート！キャンペーン・使い方を解説！

スプレッドは同じ時間帯で比較する

スプレッドは状況によって変動するので、取引所同士でもスプレッドの開きに差が出ることがあります。なので同じ時間帯でそれぞれ比べてみることも大切です。

通貨ごとに取引所を変える

取引所によってはコインごとに取引方法が異なります。

そして通貨の取引量によってもスプレッドに差が出るため、安く買いたいならば通貨ごとに取引所を使い分ける必要があります。

スプレッドの確認方法と見方

スプレッドが重要であることは理解できると思いますが、実際の確認方法はどこで知ることができるのか？と疑問に思われる方も多いと思います。

取引所のスプレッドは分かりやすく明記されていることが少ないので、知らないうちに損失を出してしまっている方も多いと思います。いくつか取引所のスプレッド確認方法を紹介したいと思います。

GMOコインのスプレッド見方・確認方法

【初心者向け】仮想通貨(ビットコイン)のスプレッドとは？スプレッドの見方・確認したいポイント・各取引所を徹底比較の説明画像

今回はBTC（ビットコイン）のスプレッドを確認している画面になります。

アカウントログイン後、『販売所』をタップします。自分が確認したい通貨をタップすると右上の方に売却価格・購入価格が表示されます。これがGMOコインのスプレッドの確認方法になります。

Coincheck(コインチェック)のスプレッド見方・確認方法

【初心者向け】仮想通貨(ビットコイン)のスプレッドとは？スプレッドの見方・確認したいポイント・各取引所を徹底比較の説明画像

アカウントログイン後に、販売所（購入・売却）どちらかをタップし『通貨レート』をタップします。

【初心者向け】仮想通貨(ビットコイン)のスプレッドとは？スプレッドの見方・確認したいポイント・各取引所を徹底比較の説明画像

するとこのように、タップ時のレートが表示されます。

ボラが激しいと購入時にはレートが変わってしまっているのでこまめに確認するのがおすすめです。

仮想通貨のスプレッドが小さい取引所を比較

これまでお伝えしてきたポイントを踏まえて、国内の大手取引所をそれぞれ比較していきます。

自分に合った取引所を是非見つけてみてください！

bitFlyer(ビットフライヤー)

【初心者向け】仮想通貨(ビットコイン)のスプレッドとは？スプレッドの見方・確認したいポイント・各取引所を徹底比較の説明画像
  • 国内取引量・仮想通貨サービス利用率 No.1
  • 100円からBTCの取引ができる
  • 取扱通貨は13種類
  • 取引手数料・入金手数料が無料

bitFlyerは「仮想通貨取引量国内No.1」として非常に有名で、流動性が抜群です。取引量が多く流動性が良いということは、それだけ取引が成立しやすくなるということなので、自分の希望にあった取引を行いやすくなります。

ただ、前述したとおり、通貨によって取引所のスプレッドに差があるので、bitFlyerだけにこだわらず、いくつかの取引所で分散して資産管理をすることをお勧めします。

コインチェック

【初心者向け】仮想通貨(ビットコイン)のスプレッドとは？スプレッドの見方・確認したいポイント・各取引所を徹底比較の説明画像
  • 取扱取扱い通貨は17種類と、国内取引所では豊富
  • 500円から仮想通貨を購入することができる
  • Webサイト・アプリが使いやすい
  • 取引手数料がかからない
  • スプレッドは業界最狭水準で設定

コインチェックは取扱異通貨が豊富なので、いろんな通貨を取り扱ってみたい方におすすめです。

また「貸暗号資産(仮想通貨)サービス」や「コインチェックつみたて」などの、取引所に預けると自動で運用してくれるサービスもあるので、長期的な資産運用を検討している人には便利です。

サイトも使いやすいので、初心者の方には一番始めやすい取引所だと思います。

Coincheck（コインチェック）をお得に始めたい方はこちらから登録

DMM Bitcoin

【初心者向け】仮想通貨(ビットコイン)のスプレッドとは？スプレッドの見方・確認したいポイント・各取引所を徹底比較の説明画像
  • 取引手数料・送金手数料・入出金手数料が無料(BitMatch取引手数料を除く)
  • 投資事業に強いDMMグループ傘下なのでセキュリティ抜群
  • 取扱通貨は12種類

DMMといえば、FXでも人気の高い企業なので、投資関連の事業運営に実績があります。

国内取引所の中でも圧倒的に手数料が安く、取引手数料・入金手数料・出金手数料・送金手数料が全て無料に設定されています。(※BitMatch取引手数料を除く)

現物取引とレバレッジ取引を行うことができ、登録から最短１時間で取引を始めるとができます。

GMOコイン

【初心者向け】仮想通貨(ビットコイン)のスプレッドとは？スプレッドの見方・確認したいポイント・各取引所を徹底比較の説明画像
  • 取引手数料・送金手数料・入出金手数料が無料
  • 取扱通貨は14種類
  • GMOインターネットグループ傘下なのでセキュリティが安心
  • 取引所形式を採用しているのでスプレッドがダントツで狭い

GMOコインはユーザー同士で取引を行う「取引所形式」なのでスプレッドが狭く、お得に取引をすることができます。

さらにレバレッジ取引にも対応していることから、初心者から上級者まで幅広い支持を得ている取引所です。

GMOコインの評判は？キャンペーン・手数料・出金入金方法・アプリ操作方法・レバレッジ徹底解説

bitbank(ビットバンク)

【初心者向け】仮想通貨(ビットコイン)のスプレッドとは？スプレッドの見方・確認したいポイント・各取引所を徹底比較の説明画像
  • スプレッドがほぼないのでお得に取引ができる
  • 取扱通貨は6種類
  • 取引手数料が無料
  • XRP(リップル)の取引量が世界一

ビットバンクも利用者が多く、XRP(リップル)の取引量は世界一です。取引所の流動性が高いので、注文が通りやすく取引しやすい取引所です。

XRP(リップル)を扱いたい方や、安さ重視で取引したい方はビットがバンクがおすすめです。

仮想通貨(ビットコイン)スプレッドについてのまとめ

仮想通貨を運用するにあたって、お得に取引するには「スプレッドが狭い」取引所を使うことが重要だということがわかったと思います。

さらに、自分が取扱いたい通貨によって取引所を変える方がよりお得に取引ができます。２種類以上の取引所に登録しておくと、比較ができて良い条件で取引ができるようになると思います。

また、取引量が多ければ多いほどスプレッドは安定してくるので、取引量が多い通貨を選ぶのもポイントです。

ただ一概に「ここの取引所が一番取引量が多いから、ここが一番良い！」というわけでもないので、まずは先ほど紹介した取引所を参考にいくつか登録して実際にスプレッドを自分で見て取引してみてください。

見えない手数料に気をつけ利益拡大に繋げましょう。最後まで読んでいただきありがとうございました。

--- # 【やり方】仮想通貨FXのスキャルピングとは？1分で利確？ビットコインのスキャルピング取引のコツ・ポイントを紹介【レンジ相場で活かす戦略】 今回の記事では、トレード方法の一つであるスキャルピングトレードについて解説していきたいと思います。 数多くあるトレード方法の中でも短期間で取引を終わらせる戦略方法になります。この方法は、レンジ相場との相性がよく仮想通貨市場の８割がレンジ相場と言われているので是非この手法は取り組んでみるのがおすすめです。 自… 正規URL: https://3mikan.com/archives/2415 著者: みかん 公開: 2021-08-28T16:36:21.000Z 更新: 2021-12-29T05:45:06.000Z

今回の記事では、トレード方法の一つであるスキャルピングトレードについて解説していきたいと思います。

数多くあるトレード方法の中でも短期間で取引を終わらせる戦略方法になります。この方法は、レンジ相場との相性がよく仮想通貨市場の８割がレンジ相場と言われているので是非この手法は取り組んでみるのがおすすめです。

自分の好き嫌いがトレード方法には影響してくると思いますが、知識として理解するだけで取引の幅が広がります。一日で細かく利益を積み上げて行きたいという人は、今回紹介する『スキャルピング』という手法を是非参考にしていただければと思います。

仮想通貨FXのスキャルピングとは？？

linecamera_shareimage-1024x644-1.jpeg-1

仮想通貨FXには、スキャルピング/デイトレード／スイングトレード／長期トレードと期間でトレードする手法があります。スキャルピングは、この中で最も取引頻度が多いものになります。

スキャルピングとは＞＞＞

ポジションの保有期間が数秒〜数分と短い時間で取引を行う事を言います。

ボラティリティーが大きい仮想通貨市場では戦略として活かすことが可能です。

このように仮想通貨市場に合わせ短い時間で今後の予想をしていく為、集中力・瞬発力などがかなり求められるものになります。では実際に、スキャルピングで意識したいポイント・コツを紹介していきます。

https://3mikan.com/archives/2168

※デイトレードについて詳しく知りたい人は、こちらの記事を参考にしてください。

スキャルピングのやり方

【やり方】仮想通貨FXのスキャルピングとは？1分で利確？ビットコインのスキャルピング取引のコツ・ポイントを紹介【レンジ相場で活かす戦略】の説明画像

スキャルピングは、数秒〜数分の取引であることは先程の説明で理解することが出来たと思います。そのため、やり方はとてもシンプルで数秒〜数分で利確を行うのが『スキャルピングのやり方』になります。

ではどういったタイミングで行うのがいいのか？という問題ですが、『トレンドのタイミングでポジションを持つ』のが最も安全で勝率の高い運用になると思いますがトレンドを見極めるのはとても難しいです。

個人的には、少しずつ上がる上昇トレンドよりも一気に下る下降トレンドで活用するのが良いと思ってます。そして、スキャルピングを利用する際のルールを持つことがおすすめです。

仮想通貨FXのスキャルピング取引のポイント

スキャルピングを行う際、こういった状況の時にスキャルピングを使う！こういった状況ではスキャルピングは使わないといった自分ルールが大切になってくると思います。

  1. マイナー通貨ではスキャルピングを行わない。
  2. チャートを見る余裕が少ないときにスキャルピングを行わない。
  3. 手数料が多く発生してしまう取引所ではスキャルピングを行わない。

マイナー通貨ではスキャルピングを行わない

短期取引の場合取引量はとても重要です。

そのため、マイナーすぎる通貨でスキャルピングを行うとなかなか流動性が提供されず相場が動かず利確することができないという事に繋がります。そのため、主要な銘柄での取引が良いでしょう。

チャートを見る余裕が少ないときにスキャルピングを行わない

基本的に本業がある方は、チャートを見ることができる時間を確保することが難しいと思います。

そのため、数秒〜数分の取引のスキャルピングは魅力的な取引ではありますが、スキャルピングではポジションを持つタイミングが重要になってきます。チャートを分析することなくポジションを保持してしまっても利確ができればいいですが、値幅がなかなか取れず利確できないことも多いです。

明日はチャートが見れないから今日は見れるという時にスキャルピングトレードをし今日のうちに資産を増やす事を徹底して取り組むといった流れが良いでしょう。本業がある方や忙しい方など、時間が取れないけど仮想通貨の運用をしたいという方には、ステーキングがおすすめです。

Binanceの旧DeFiステーキングと現行サービス、リスクの解説

手数料が多く発生してしまう取引所ではスキャルピングを行わない

取引頻度が最も多い取引ではありますが、利幅を取れなかった場合手数料負けに繋がってしまいます。

そのため、十分なり幅をとれるようにレバレッジを活用するか手数料コストが低い海外取引所がおすすめです。

仮想通貨FXのスキャルピング取引のメリット

スキャルピングを行うメリットを紹介します。

リスクを抑える事が可能

短期トレードのメリットとして翌日にリスクを持ち込まないという点が挙げられます。

仮想通貨の激しい相場に対して、長くても数分の取引というスキャルピングはその点リスクヘッジに繋がります。急激な暴落などに対しても素早く損切りを行い損失の拡大を最小に留めることができます。

チャートの時間を見る時間があまり取れないかたにとっても、『仕事中に暴落していた』というリスクから逃れることにも繋がります。

資金が少なくても運用可能

スキャルピングはレッバレッジ取引との相性がいいです。そのため、海外の取引所をうまく活用し少ない資金に高いレバレッジで取り組む事ができれば資金効率をかなり上げることができます。

数時間・数日の取引で利幅が結局戻ってしまった場合と比較すると、長期運用分の手数料コストを抑えることにも繋がります。

仮想通貨FXのスキャルピング取引のデメリット

スキャルピングを行うデメリットを紹介します。

手数料がかさむ

スキャルピングの特徴として、薄い利益幅でも確実に利益にしていくという利点がありますが。その分取引回数がかさみ手数料も発生していきます。利益とコスト(手数料)のバランスは考え、取引することをおすすめします。

事前に自分が利用する取引所の手数料を把握し、自分のポジションに対しての利幅はどれくらい必要なのかを知ることをおすすめします。

メンタル維持

スキャルピングの取引時間は数秒〜数分の為、何度も取引をする必要があります。チャートをチェックする時間や集中して戦略を考える時間というのがとても増えるので、時間に余裕がある日など無理なく取り組むことをおすすめします。

仮想通貨の運用方法は、数多くありますのでうまくカスタムしながら時と場面ごとに『スキャルピング』を活用することをおすすめします。

レンジ相場でのスキャルピング戦略とは

レンジ相場とは、ボックス相場とも呼ばれ一定の値幅で上下している相場を言います。

レンジ相場の特徴として値幅が小さい事が挙げられるので、取引回数が多いほうが資金効率よく運用することができます。そのため、スキャルピングとレンジ相場の相性はとてもよくコツコツ利益を得ることができます。

レンジ相場で活用できるテクニカルとしていくつか紹介したいと思います。

レンジ相場で逆指値を活用する

トレンド相場に乗り取引する戦略を行いたい場合ですが、見分けることが難しい人には逆指値注文をおすすめします。

トレンド相場より多い相場である、レンジ相場を活用することができるので比較的利用しやすい手法です。興味がある方は、詳しい内容やり方について下記記事で紹介していますので参考にしてください。

https://3mikan.com/archives/2216

レンジ相場はハイレバレッジ取引を活用する

メリットでお伝えしたように、レバレッジを活用し資金効率を上げることをおすすめします。ただ、レバレッジを上げれば上げるほどロスカットのリスクも大きくなるため注意が必要になります。

https://3mikan.com/archives/2918

レバレッジとロスカットの関係性などについて詳しく知りたい方は、こちらを参考にしてください。

また、レバレッジの規制がない海外取引所を利用することでよりハイリターンの取引が可能になります。国内取引所にはある『追証制度』に関しても、海外取引所にはないので借金の心配もなくおすすめです。

【初心者向け】仮想通貨FXにおすすめのレバレッジ倍率とは？トレード方法や取引所を紹介

スキャルピング取引におすすめの取引所

私がいくつかトレードしてきた中でのおすすめの取引所を３つほど紹介したいと思います。

スキャルピング取引で一番気をつけたいのは手数料です。国内の取引所は、スプレッドが大きいのでスキャルピングはおすすめしません。スキャルピングを実践したいと思っている方は是非、海外取引所を活用してみてください。

流動性を重視したい方にはBinance(バイナンス)

仮想通貨取引で『流動性』を意識した取引はとても重要になります。

【DeFi】流動性とは？Priceimpacttoohigh・スリッページ・フロントラン（frontrun）について徹底解説

世界最大大手取引所のBinance(バイナンス)は、安定して高い流動性を保持しておりサービス内容もとても豊富です。初心者の方でも問題なく利用ができますので、興味がある方は下記ブログを参考にバイナンスでのスキャルピング取引を初めてみてください。

https://3mikan.com/archives/2066

使いやすさ重視の方にはBybit(バイビット)

スキャルピングだけでなく、仮想通貨FXにおいてスムーズな取引はとても重要になります。

Bybit(バイビット)のスマホアプリは個人的に一番使いやすいと思っています。外出先でも安心した取引が行えるので、海外取引所に少し抵抗がある方にもおすすめです。是非一度下記記事からチェックしてみてください。

https://3mikan.com/archives/1945

無料で練習したい方にはBitget(ビットゲット)

国内・海外共にどこの取引所でもキャンペーンをおこなっています。そのキャンペーンを利用することでお得にトレードに参加することが可能です。

その中でもBitget(ビットゲット)の取引は、とても魅力的な物が多いです。ボーナス内容や使い方など詳しく知りたい方は下記記事を参考にしてみてください。

https://3mikan.com/archives/2010

スキャルピングのまとめ

今回はスキャルピングについて紹介しました。利益だけでなく、いかに損失に備えていくかという所も踏まえレバレッジや逆指値注文という＋αの要因もしっかり抑えていく必要があると思います。

またスキャルピングは瞬発力が求められます。取引のしやすさや画面の見やすさなども含め、自分のライフスタイルに合わせたトレードができると自分にも負担がなくトレードすることができるのではないのかなと思います。

個人的には、スマホの場合Bybitでの取引が利用しやすくおすすめです！各取引所の操作方法については、他の記事を参考に是非お得な情報も知っていただければと思います。

最後まで読んでいただきありがとうございました。

https://youtu.be/SlQBD0wPqNM
--- # 【DeFi】BSC（バイナンススマートチェーン）とは？概要と主要なプロジェクトを紹介 「DeFiは気になるけど、あまり良くわかってない...」と思っている人は非常に多いです。私が運営しているテレグラムなどでの会話を見ていても痛感しています。 DeFiを支えているブロックチェーン技術は理解するのが難しい（というよりも、体感的にイメージを掴むのが難しい）ので、なかなかよくわからないという悩みをよ… 正規URL: https://3mikan.com/archives/316 著者: みかん 公開: 2021-02-20T02:03:00.000Z 更新: 2021-12-27T16:03:55.000Z

「DeFiは気になるけど、あまり良くわかってない...」と思っている人は非常に多いです。私が運営しているテレグラムなどでの会話を見ていても痛感しています。

DeFiを支えているブロックチェーン技術は理解するのが難しい（というよりも、体感的にイメージを掴むのが難しい）ので、なかなかよくわからないという悩みをよく聞きます。

ですが一方で、DeFiは年利10%などは普通で100%などの運用方法も存在し、高いもので行くと数千%のものも存在する世界です。徐々に理解してくれば現実世界の「法人」のように捉えて考えていくこともできる非常に面白い分野です。

この記事では、DeFiの中の一つのネットワーク（規格）であるBSCを中心に解説していきます。

【DeFi基礎】BSC（バイナンススマートチェーン）とは？

famtom.004

BSCはネットワークの総称です。バイナンススマートチェーンという取引所バイナンスが主導となって開発したネットワークを指しています。

元はイーサリアム（ETH）によるネットワークのERC20がベースとなっています。理解が難しい場合は、このERC20をコピーして開発したと考えましょう。

BSCの実際のネットワーク名称はBEP20と書きます。これは、バイナンスで入出金をする際にネットワークの選択画面にも出てきますね。

それぞれのネットワークに、「ネットワークのベースとなるトークン」「ネットワークの名称」があります。BSCでは$BNBとBEP20のことです。

「ネットワーク（規格）」の意味がわかりにくい方向け

DeFiというよりも仮想通貨全体としてネットワーク（規格）に対する理解は大事です。これを正しく理解してない場合、資金を紛失する確率が非常に高くなります。

まずは日本の各銀行のように考えてみましょう。A銀行とB銀行みたいに２つの銀行をイメージしてみてください。

基本的に全員がA銀行とB銀行の両方で口座を持てるとします。そして、あなたは既に両方の銀行で口座を持っています。

A銀行からA銀行への送金・B銀行からB銀行への送金のような同銀行間での送金は非常に簡単です。これは現実でも「手数料が低い」などの優遇があるのと同様です。

しかし、A銀行からB銀行のように銀行をまたぐ送金は追加の手続きが必要になります。

A銀行の従業員はA銀行間での送金データなどは確認できますが、B銀行間の送金データは確認できません（社外ですので）。また、A銀行が独自で考えたポイントなどをB銀行に持っていっても「なにそれ？」となります。

このように役割がほとんど同じでも、銀行間をまたごうとすると弊害が出るというイメージだけ覚えておいてください。

BSC以外の他のネットワーク

BSC以外にも主要なネットワークがあります。そもそも、BSCは一番最初のネットワークではありません。

  • ERC20（イーサリアムネットワーク）
  • TRON（トロンネットワーク）
  • Polygon（ポリゴンネットワーク/旧マティックネットワーク）

DeFiが騒がれ始めてブームになった瞬間に一番利用されていたのがBSCのため、BSCから参加しているユーザーが多いです。

また、BSCの場合はバイナンスが開発元ということもあり、バイナンスから連携しやすく作成されているのでバイナンス自体のユーザー数の恩恵もあります。

基本的にDeFiでは参加ユーザーが多いほど良いため、人気なネットワークを選ぶことは大事です。

BSC（バイナンススマートチェーン）のDeFiの始め方

この記事では、DeFiのプロジェクトを紹介していきますが、はじめ方については別の記事で紹介させていただきます。

PancakeSwap（パンケーキスワップ）というDeFiプロジェクトの参加方法を解説していますので、一旦この記事に沿って導入してみてください。

https://3mikan.com/archives/240

「自分がやりたいプロジェクトと違う」というあなたも、まずはPancakeSwapに接続するところから始めてみましょう。

というのも、DeFiは実際に操作できるまでの流れは大変ですが、一度どれかのプロジェクトを触れるようになれば他のプロジェクトも簡単に操作していけるからです。

DeFiには「ウォレットを接続する（Connect Wallet）」という操作があり、ここまで到達できていれば基本的に全てのプロジェクトにすぐにアクセスできます。

  1. 仮想通貨を入手する
  2. ネットワークに対応しているウォレットを準備する（基本MetamaskでOK）
  3. ウォレットにネットワークを設定する
  4. ウォレットに仮想通貨を送金する
  5. プロジェクトのサイトでウォレットを接続する

基本的にはこの5つの流れで共通しており、①〜④までが完了していれば全て⑤のみで完了できます。

BSCの場合は、どのプロジェクトをやるにしても「BNB」というネットワークトークンが必要になります。これはバイナンスのトークンでもあり、今後のためにもバイナンスのアカウントを持っておくことをおすすめします。

下のリンクから登録すると、取引手数料が10%安く取引できます。ぜひご利用ください。

【無料】Binanceに手数料優遇アカウントで登録したい方はクリック

主要なBSCのDeFiプロジェクト3つ

BSCで始めるならまずはこのDeFiに触れてみましょうというプロジェクトが3つあります。私が実際に運用で使っているのはこの3つ以外にもありますが、この3つだけは別枠でまとめる必要がありました。

DeFiのプロジェクトは一般の人でも誰でも作成する事ができます。もちろん、私やあなたも作成してファームを提供したりできるということです。

しかしながら、「一般の人でも作れる」ということは「詐欺師でも簡単に作れる」ということです。これがDeFiに潜在したリスクになります。

ここで紹介する3つのプロジェクトは、背景に「バイナンス」が絡んでいる可能性が非常に高いプロジェクトだからです。

PancakeSwap（パンケーキスワップ）

screen-2021-10-05-22.20.32

独自トークンは$CAKEのDEX（AMM）です。おそらく、現状最も有名なDEXでしょう。

BSCでの中心的なDEXであり、BSCのDEX（AMM）のほとんどはこのパンケーキスワップが元になっています。（パンケーキスワップはERC20のUniSwapを元に作られています）

初心者が初めてDeFiに触る場合には、このパンケーキスワップから参加することをおすすめします。

https://pancakeswap.finance/

※DEX（AMM）という概念については下の記事を参考にしてみてください。

https://3mikan.com/archives/2126

Venus（ヴィーナス）

screen-2021-10-05-22.24.46

独自トークンは$XVSと$VAIです。レンディングプラットフォームでトークンを預けたり借りたりすることができます。

$VAIは1ドルにペグさせることを目標としているトークンで、Venusで低い手数料で借りる事ができます。

レンディングプラットフォームは、「長く持ちたくは無いけど利用したいトークンがある」という場合に最適です。

初心者には少しむずかしい使い方かもしれませんが、DeFiに触れている内に使い方が自然と理解できてくるはずです。

https://app.venus.io/dashboard

https://youtu.be/4PUwIJAuzyo

PancakeBunny（パンケーキバニー）

screen-2021-10-05-22.29.36

独自トークンは$BUNNYです。Vaults（ボルツ）というファーム運用の自動化を行ってくれるプロジェクトです。

「ファーム運用の自動化」ですので、あくまでファーム運用が元にある概念となっています。ですので、まずはパンケーキスワップのような通常のファームになれることをおすすめします。

パンケーキスワップなどに触れていると「どうにか複利で簡単に回せないかな」と思うはずです。それを簡単に実現してくれるのがこのパンケーキバニーです。

ただ、一度エクスプロイト（ハッキングのようなもの。攻撃を受けたということです。）を受けており、$BUNNYの価格が大暴落しています。リスクは上2つよりも高いと考えたほうが良いでしょう。

https://pancakebunny.finance/pool

個人的に推したいBSCのDeFiプロジェクト5つ

DeFiプロジェクトは現在めちゃくちゃあり、時期によって流行り廃りがあります。また、今は非常に優良なプロジェクトでも一回のエクスプロイトを期に地獄のような状態になることもあります。

基本的には自分で探し納得した上で参加するようにしてください。一応、私が触れているものを紹介しますが、おすすめしているわけではありません。

まずは、どのような基準で探しているかから共有していきます。

おすすめの基準
  1. DappRadarに載っている
  2. 流動性をある程度確保できている
    （すでにユーザーがいる）
  3. CoinMarketCapでトークンを検索して出る
  4. パンケーキスワップと操作性が似ている

上記のような基準で選んでいます。通貨価値の上がり下がりやプロジェクトが飛ぶ可能性なども考慮しています。

また、ユーザーが多いほうが年利や通貨価値の上下の振れる速度が遅いので、ユーザーは比較的多いものを選んでいます。

パンケーキスワップと操作性が似ているものを選んでいる理由は、操作を間違えて資金ロストしたりするリスクを抑えるためです。

以下の5つのプロジェクトが個人的に推したいBSCのプロジェクトです。

個人的に推したいBSCのDeFiプロジェクト5つ
  1. CafeSwap（終了済みの旧サービス）
  2. ApeSwap（エイプスワップ）
  3. AlpacaFinance（アルパカファイナンス）
  4. SwampFinance（スワンプファイナンス）
  5. BeefyFinance（ビーフィーファイナンス）

DeFiに参加する際の注意事項

DeFiはリスクが高いとよく言われますので、すでに理解されているかたも多いとは思いますが再度お伝えします。

DeFiは資金ロストの可能性が非常に高い運用方法です。

  • DeFiプロジェクトのサーバーが消滅し、その時に預けていた資金が消滅する恐れがあります。
  • 仮想通貨自体の価値が落ち、損失を被る可能性があります。
  • 購入したトークンが偽装トークンで、価値のないものの恐れがあります。

こういった注意点を理解できる方のみが運用にご参加ください。

また、最初は失っても大丈夫な金額で投資されることをおすすめします。

--- # 【使い方】Binance(バイナンス)の送金・入金方法を解説。アプリからの送金手順・取引手数料などを安く済ませるやり方について 今回はBINANCE(バイナンス)への送金・入金方法について解説します。 「BINANCE(バイナンス)で仮想通貨を購入したいけど、送金(入金)手順がわからない」「なぜか入金できない・反映に時間がかかる」など初心者の方に向けて、画像付きで手順を説明したいと思います。 BINANCE(バイナンス)は海外取引所… 正規URL: https://3mikan.com/archives/2642 著者: みかん 公開: 2021-09-12T17:34:04.000Z 更新: 2021-12-27T15:59:15.000Z

今回はBINANCE(バイナンス)への送金・入金方法について解説します。

「BINANCE(バイナンス)で仮想通貨を購入したいけど、送金(入金)手順がわからない」「なぜか入金できない・反映に時間がかかる」など初心者の方に向けて、画像付きで手順を説明したいと思います。

BINANCE(バイナンス)は海外取引所になりますので、初心者の方には最初難しいと感じるかもしれません。しかし、バイナンスへの送金・入金方法はいくつかあります。自分がやりやすいなと感じる方法でトライしてみてください。

また、BINANCE(バイナンス)へ送金する時、どの取引所を使って送金するかで手数料の差がかなり開きます。手数料を抑えたい方はぜひ参考にしてもらえたらと思います。

【無料】ここから登録するとBinanceの取引手数料10％OFFでお得にトレードできます！

バイナンス送金(入金)の注意点・知っておいた方がいいこと

Binance（バイナンス）への送金時に注意したい点とお得な取引方法を４つ紹介していきたいと思います。

  1. binance(バイナンス)への日本円での送金(入金)は不可
  2. binance(バイナンス)への送金反映時間はBTCで約15分
  3. binance(バイナンス)への入金手数料は無料
  4. 送金手数料が無料の国内取引所を使うことで最大6000円安く送金できる

① binance(バイナンス)への日本円での送金(入金)は不可

仮想通貨の取引所を利用する時、まずは取引所に日本円で入金をして、仮想通貨を購入しなければいけません。

binance(バイナンス)では、米ドルやユーロといった様々な法定通貨を取り扱っていますが、日本円は現在取り扱われていないので、日本円での入金はできません。

どうしても日本円での入金がしたいという方は、BTC(ビットコイン)、ETH(イーサリアム)などの 主要な仮想通貨であれば、クレジットカードで仮想通貨を購入することが可能です。また、P2P取引を利用することで日本円での購入が可能ですが、初心者の方には難しい取引かもしれません。

そのためbinance(バイナンス)を利用するならば、まずは国内の仮想通貨取引所で日本円と仮想通貨を交換し、そこで得た仮想通貨をbinance(バイナンス)へ送金(入金)する方法がおすすめです。

② binance(バイナンス)への送金反映時間はBTCで約15分

binance(バイナンス)では、着金までの承認作業を２回設定しており、BTC(ビットコイン)であれば最短15分〜で送金(入金)が反映されます。

XRPやETHのような仮想通貨の場合は、送金に時間がかからないので数分で送金(入金)が反映されます。

③ binance(バイナンス)への入金手数料は無料

binance(バイナンス)では仮想通貨の入金手数料が無料です。なのでbinance(バイナンス)に送金する際は手数料を気にする必要がありません。

その代わり、仮想通貨を送金する際のネットワーク手数料や、送金元(国内取引所)のウォレットに送金手数料が設定されていることがあるので、仮想通貨の送金元の手数料がいくらかかるのか調べておくことをおすすめします。

④送金手数料は最大6000円安くできる

最近テレビCMやYoutube広告などで、日本の国内仮想通貨取引所であるコインチェックを知り、コインチェックを使ってbinance(バイナンス)に送金しているという人もいます。

確かにコインチェックは初めて仮想通貨を運用するという人にとっては使いやすいかと思いますが、送金手数料が￥4000〜最大￥6000かかる場合があります。異常に高い送金手数料なので、知らずに利用して後から後悔する人もいます。

そこでおすすめなのがGMOコインです。GMOコインは国内取引所であり、送金手数料が無料なので、かなりコストを抑えられます。なので今回は、GMOコインを例に、GMOコインからbinance(バイナンス)へ送金する手順を画像付きで解説していきたいと思います。

binance(バイナンス)の送金(入金)方法３つ紹介

binance(バイナンス)への入金方法は主に３つです。

  • P2P取引(銀行振込)で仮想通貨を購入し入金する
  • クレジットカードで仮想通貨を購入し入金する
  • 別の取引所で購入した仮想通貨を送金(入金)する

binance(バイナンス)では日本円での入金が認められていないので、大半の日本人はクレジットカードで仮想通貨を購入し入金するか、別の取引所で仮想通貨を購入し送金(入金)する方法になります。

ただ、クレジットカードの場合、入金手数料が高いことから「別の取引所で仮想通貨を購入し送金(入金)する方法」が一番行われているやり方になります。

P2P取引(銀行振込)で仮想通貨を購入し入金する場合

  • トレードの一つなので初心者には難しい
  • 日本円での取引が可能
  • テイカー側の手数料は無料

P2P取引は、バイナンスのトレード方法の一つです。

自分と第三者によるユーザー間で行われる取引で、買いたい人・売りたい人共に支払い方法が一致した場合取引を成立させることが可能になります。支払い方法には、銀行・LINE Payなどがあり日本円を利用したい方・手数料を抑えたい方にはおすすめの取引です。

P2P取引では『USDT』の購入がおすすめですが、他の通貨を利用したい場合は取引後にバイナンスのトレードでスワップし自分が欲しい通貨に変える流れがいいと思います。P2Pの手順については、下記ブログを参考にしてください。

https://3mikan.com/archives/152

クレジットカードで仮想通貨を購入し入金する場合

  • 入金手数料が高い
  • 取扱い法定通貨は180カ国
  • 最低入金額は1700円
  • 購入できる仮想通貨はBTC/ETH/BNB/XRP/USDT/BUSDの６つ
  • 即日反映

クレジットカードで入金したい場合、手数料が高めですがクレジットカードのポイントを貯めたいという方や、どうしても日本で仮想通貨を購入したいという方にはおすすめの方法です。

マイナーな通貨は日本円での売買ができないため取引前に確認してください。

別の取引所で仮想通貨を購入し送金(入金)する場合

  • 仮想通貨での入金は手数料が無料
  • 日本国内の取引所を開設する必要がある
  • BTC/ETH/USDT/BNB/EOSの５種類の入金が可能
  • 数分から数十分で反映(通貨による)

手数料がかからないことから、日本では一番行われている入金の方法だと思います。すぐに送金(入金)が反映されるので、初めてbinance(バイナンス)を利用する人や、急いでいる人にはおすすめです。

入金手数料が無料のバイナンスではありますが、国内取引所の場合スプレッドが広いことで手数料などのコストが海外取引所より多くかかってしまうため注意してください。

クレジットカードで仮想通貨を購入し入金する方法

クレジットカードを利用して入金する方法はとても簡単に行う事が可能です。

  1. 入金画面でクレジットカードを選択する
  2. 購入内容を決める
  3. 利用したいクレカの情報を入力する

日本円での主要銘柄購入を考えている方には、おすすめです。

①入金画面でクレジットカードを選択する

【使い方】Binance(バイナンス)の送金・入金方法を解説。アプリからの送金手順・取引手数料などを安く済ませるやり方についての説明画像

「ウォレット」→「ウォレット概要」をタップします。その後「入金」をタップします。

【使い方】Binance(バイナンス)の送金・入金方法を解説。アプリからの送金手順・取引手数料などを安く済ませるやり方についての説明画像

「カードで仮想通貨を購入します」をタップします。

②購入内容を決める

【使い方】Binance(バイナンス)の送金・入金方法を解説。アプリからの送金手順・取引手数料などを安く済ませるやり方についての説明画像

「購入」をタップし、「購入金額」を入力し、この内容でよければ「続行」をタップします。

【使い方】Binance(バイナンス)の送金・入金方法を解説。アプリからの送金手順・取引手数料などを安く済ませるやり方についての説明画像

「支払い方法」を選択し「次へ」をタップします。

③利用したいクレカの情報を入力する

【使い方】Binance(バイナンス)の送金・入金方法を解説。アプリからの送金手順・取引手数料などを安く済ませるやり方についての説明画像

カード情報を入力し、「次へ」をタップします。

【使い方】Binance(バイナンス)の送金・入金方法を解説。アプリからの送金手順・取引手数料などを安く済ませるやり方についての説明画像

「個人情報」を入力し「カードを追加」をタップします。

【使い方】Binance(バイナンス)の送金・入金方法を解説。アプリからの送金手順・取引手数料などを安く済ませるやり方についての説明画像

「次へ」をタップします。

【使い方】Binance(バイナンス)の送金・入金方法を解説。アプリからの送金手順・取引手数料などを安く済ませるやり方についての説明画像

内容を確認したら60秒以内に「承認」をタップします。これで購入が完了です。

国内取引所で仮想通貨を購入し送金(入金)する方法

今回は「GMOコイン取引所」を利用して、binance(バイナンス)にBTC(ビットコイン)を送金したいと思います。

取引所を利用し送金する場合、操作手順はどこの取引所も変わりありません。自分が利用したい取引所がある場合も、これから説明する手順を参考にしてみてください。

  1. GMOコインで日本円を入金する
  2. GMOコインでBTCを購入する
  3. binance(バイナンス)を開きBTCのアドレスをコピーする
  4. GMOコインを開きコピーしたアドレスを貼り付ける・認証
  5. GMOコインからbinance(バイナンス)へBTCを送付する

※なお、解説に使う画像はすべてアプリでの操作画面になります。

GMOコインは送金手数料が無料なので、かなりコストを抑えられます。最近CMなどでコインチェックなどをよく目にしますが、コインチェックは送金手数料が高く、最大で6000円かかる場合もあります。これだと手数料がかなりもったいないので、個人的には送金手数料が無料のGMOコインがおすすめです。

では早速手順を解説していきたいと思います。

① GMOコインで日本円を入金する

GMOコインでアカウントをまだ持っていないという方はアカウント登録から始めてください。今回は登録手順は省きます。(GMOコインへの登録はこちらから)

S__9928731

では、まずはGMOコインアプリを開き「日本円入出金」をタップします。

S__9928733

「即時入金」もしくは「振込入金」をタップして、利用する金融機関を選びます。(画像に写っている以外の金融機関も使えます。)

あとはそれぞれ表示される手順通りに操作を進めると入金ができます。

② GMOコインでBTCを購入する

S__9928706

GMOコインアプリを開き、トップページの下にある「保有/履歴」をタップします。

S__9928708

「BTC」をタップします。

S__9928709

「【販売所】購入/売却」をタップします。

S__9928711

金額を入力し「購入」ボタンをタップします。

S__9928712

6秒以内に「注文確定」ボタンをタップします。

これで5000円分のBTCを購入できました。

③ binance(バイナンス)を開きBTCのアドレスをコピーする

S__9928713

続いてbinance(バイナンス)アプリを開き、トップページにある「入金」をタップします。

S__9928714

「BTC」を上の検索窓で検索し、タップします。

S__9928715

画像ナイの赤丸マークをタップでアドレスのコピーは完了します。

④ GMOコインを開きコピーしたアドレスを貼り付ける・認証

S__9928716

GMOコインアプリを開き「預入/送付」をタップします。

S__9928717

「BTC」をタップします。

S__9928719

「送付」をタップし「➕ 新しい宛先を追加する」をタップします。

S__9928720

「名称」「先ほどコピーしたアドレス」をそれぞれ入力します。入力したら「登録する」をタップします。

S__9928721

メールアドレスに届いたメールに記載されているリンクをタップします。(※リンクの期限は10分です。)

S__9928722

「認証を完了する」をタップします。

これでbinance(バイナンス)へBTCを送金する準備が整いました。

⑤ GMOコインからbinance(バイナンス)へBTCを送付する

再度GMOコインアプリを開き、「預入/送付」→「BTC」の順にタップします。

S__9928725

そして「送付」をタップし先ほど登録したアドレスが表示されているのでチェックを入れます。

S__9928724

下にスクロールして、いくら送金するのか入力します。この時注意しなければいけないのが、送付数量の加減は１回あたり0.02BTCです。これより下回ると送付ができません。ですが、全額送付またはGMOコイン内の送付の場合は加減はありません。

なので今回は、0.02BTCを下回るので全額をbinance(バイナンス)に送金します。

「送付数量」を入力し「SMSで二段階認証コードを受け取る」をタップし、電話番号に届いた数字６桁を空欄に入力します。そして「確認画面へ」をタップします。

S__9928726-1

確認して誤りがなければ「実行」をタップします。

S__9928727

するとこのように表示されます。あとはbinance(バイナンス)に送金が反映されるのを待つのみです。

S__9928728

binance(バイナンス)への送金が完了すると、binance(バイナンス)から入金確認のメールが届きます。今回私の場合だと、入金反映までに18分ほどかかりました。

以上で、binance(バイナンス)への送金(入金)は無事完了しました。

入金(送金)時にトラブルが起きた場合の対処法

入金・送金共にそこまで難しい手順ではありませんが、バイナンスは海外取引所の為初心者の方は最初トラブルが発生しやすいかもしれません。

慣れるまでは、おちついて操作を一つ一つ丁寧に行う事が大切です。

binance(バイナンス)の入金上限額/最低額を確認する

binance(バイナンス)では、入金する際の上限額と最低額が決められています。

仮想通貨で入金するのか、クレジットカードで購入して仮想通貨を入金するのかでも上限額/最低額が違うので、入金する際は画面に表示されている注意書きをよく読んでから操作してください。

クレジットカードが対応しているか確認する

クレジットカードで入金する際は、使用するカードがbinance(バイナンス)での入金に対応しているものなのか確認してください。

カード会社の中には、海外サイトではカードが利用できないようにしているところもあります。

また、滅多にないとは思いますが、残高不足になっていないか確認したり、カード口座やbinance(バイナンス)のアカウントが凍結されていないか確認してみてください。

認証したアドレスが間違っていないか確認する

仮想通貨のアドレスを間違えて認証すると、送金の手続きはできても反映がされません。一度送金してしまうと元には戻らず、資金が消えて無くなる状態になるので、アドレスの入力ミスがないか確認しましょう。

アドレスの入力ミスを防ぐためにも、手入力より、コピーして貼り付けることをお勧めします。

binance(バイナンス)送金・入金方法のまとめ

今回は、送金手数料が無料のGMOコインを扱いましたが、他にも国内取引所はたくさんあるので、自分が使いやすい取引所を見つけて利用していただいて全く問題ありません。

はじめて海外の取引所を利用するという方にはbinance(バイナンス)が個人的にはおすすめなのですが、日本円が使えないので、まずは国内取引所で仮想通貨を購入しbiance(バイナンス)へ送金するところから始まります。

初めての方からすると、binance(バイナンス)を利用する前にあれこれ準備しなければいけないので、戸惑う方も多いと思います。binance(バイナンスで)仮想通貨の運用を始めたい方や、独自トークンのBNBを買ってみたい方はぜひ、今回の記事を参考にしていただけたらと思います。

最後まで読んでいただきありがとうございました。

【無料】ここから登録するとBinanceの取引手数料10％OFFでお得にトレードできます！

https://3mikan.com/archives/224
--- # 【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！ 2020年ごろから急成長を遂げた1INCH。最近よく耳にするようなった人も多いと思います。とはいえまだ１INCHがどんなものなのかよくわからない人も多いです。 実際、配布後すぐに何度か高騰をみせるなど今後仮想通貨市場で存在感を増していきそうです。 今回の記事ではこの1INCHの特徴や使い方について詳しく解説… 正規URL: https://3mikan.com/archives/574 著者: みかん 公開: 2021-04-17T15:03:23.000Z 更新: 2021-12-24T15:56:39.000Z

2020年ごろから急成長を遂げた1INCH。最近よく耳にするようなった人も多いと思います。とはいえまだ１INCHがどんなものなのかよくわからない人も多いです。

実際、配布後すぐに何度か高騰をみせるなど今後仮想通貨市場で存在感を増していきそうです。

今回の記事ではこの1INCHの特徴や使い方について詳しく解説していきます。

1INCHとは？

1INCHとは、2020年あたりから注目されている1inch.exchange(ワンインチドットエクスチェンジ)というDEX(分散型取引所)が開発した独自のガバナンストークンです。

これからこの1inch.exchange(ワンインチドットエクスチェンジ)の特徴について解説していきます。

フロントランニング防止機能

フロントランニングとは、自分以外のユーザーが取引しようとしたのを見計らい、先回りすることで自分の取引を成立させることを言います。

他のユーザーに自分より不利なレートで取引させ、自分は利ざや(「売値と買値」の差額によって生じる利益金)を稼ぐことになるので、DEXを利用する上で問題になっています。

ですが1inch.exchange(ワンインチドットエクスチェンジ)は、ユーザーの取引情報が他のユーザーに露見することを防ぎ、フロントランニングを防止する機能が備わっています。

DEXアグリゲーターである

1inch.exchange(ワンインチドットエクスチェンジ)はDEXアグリゲーターといい、トレーダーに最も有利な価格で約定させることができるDEX(分散型金融)になります。

わかりやすく例えると、旅行の比較サイトを利用した際に、行き先や料金などを入力し、その中から一番いい条件のものを探し出してくれるように、たくさんあるDEXの中から最も良いレートを選んでくれるDEXになります。

1INCHを利用すると、32種類のDEXなどから最良レートで仮想通貨の交換を行うことができます。

試しに1inch.exchange内でBUSDとUSDTの交換を比較してみると、今回は1inch.exchange(ワンインチドットエクスチェンジ)が一番お得に交換ができるようだったので、1inch.exchangeで10000コインのBUSDをUSDTに交換してみると9998.44USDTに交換されました。

【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！の説明画像

また、試しに別のDEXであるパンケーキスワップで同じ額の10000コインのBUSDをUSDTに交換してみたら、9975.52USDTに交換されました。

【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！の説明画像

比較してみると分かるように、1inch.exchangeとパンケーキスワップでは、大体23USDT分くらい違います。

これを日本円に直すと二千円ほど違うので、積み重ねていくとかなりの金額の差になります。なので、取引額が大きい方は1inch.exchangeを使用してみるとかなりお得に取引ができます。

ちなみに、1INCHの月平均取引高は10億ドル(約1036億円)を超えており、これはDEXアリゲーターのジャンルの中では最大級の規模で、DEX市場全体から見ても10％程度のシェアがあります。

DEXアグリゲーターを実際に使ってみた

取引する際に、「過去に交換したことのあるトークン(通貨)」と「初めて交換するトークン(通貨)」とでは表示される項目が違うので、今回は、その２パターンのやり方について解説していきます。

過去に交換したことのあるトークン(通貨)

BDOをMSCに交換してみます。

まず、それぞれ通貨をタブの中から選択します。次にいくら交換するのか入力します。ちなみに右上にある「Balance」をタップすると全額分入力されます。

【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！の説明画像

次に、交換する前に左下にある「Exchanges」の欄を確認します。ここは、どこのDEXが今一番お得に交換・取引できるかが比較して表示されたものです。たまたま今回は1inch.exchangeが一番お得だったので、このまま交換します。

確認後、全て入力したら青いボタンの「SWAP Token」をタップします。

【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！の説明画像

次に確認画面が小さく表示されるので赤いボタンの「Accept」、青いボタンの「Comfirm Swap」をタップします。

【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！の説明画像
【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！の説明画像

次に、右側にまた画面が表示されるので、青いボタンの「確認」をタップします。これで取引が完了です。

【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！の説明画像

初めて交換するトークン(通貨)

BTDとMSCを交換してみます。

初めて交換するトークンの場合、右側にオレンジ色の鍵マークが表示されています。まずはこの鍵マークをタップします。

【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！の説明画像

次に青いボタンの「Unlock」をタップします。

【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！の説明画像

次に、右側上部に画面が表示されるので、青いボタンの「確認」をタップします。

【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！の説明画像

この一連の操作は、1inchにこのトークンを移動させる権限を許可する作業になります。

この操作を済ませたら、あとのやり方は一緒です。通貨と交換する数量を入力し、青いボタンの「Swap Token」をタップします。

【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！の説明画像

出てきた表示画面にある「Comfirm Swap」をタップし、

【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！の説明画像

右側に表示された画面にある青いボタンの「確認」をタップします。これで取引の完了です。

【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！の説明画像

利用する際の注意点

1inchにトークンを移動させる権限を許可する操作について解説しましたが、この操作の裏を返すと「権限さえあればトークンを勝手に動かすことができる」ことになります。

これを悪用して、人のウォレットからトークン引き抜こうとする人もいます。Defiではたまに悪質なプロジェクトがあり、抜かれてしまう被害が起こっています。

今実際にバイナンススマートチェーンでは１日に1~2個、そういった被害が起こっているので、今この操作は何をしているのか？何を許可しているのか？しっかり知識をつけておきましょう。

また、1inch内でのこういった引き抜きの被害に遭わないための予防として知っておいて欲しいのですが、先ほど画像で説明した際に「鍵マーク」をタップした後に出てくる青色の「Unlock」と緑色の「Infinite Unlock」がありました。

【DeFi】1inch.Exchangeの特徴＆使い方を画像付きで解説！の説明画像

青色の「Unlock」は、すぐ下に数量が表示されていますが、これは表示されている数量内での引き出しができる状態を表しています。

緑ボタンの「Infinite Unlock」にすると無限に引き出せる状態になります。言い換えれば、制限がない状態です。

なので、引き抜き被害の対策として、使う度に制限をかけて、使い終わったらリボーク(切断)をすることが大切です。こちらの操作についてはまた別の記事で紹介できたらと思います。

ちなみに、マイナーなコインの引き抜き被害はあまりなく、ハッキングする側の人間からすると、すぐに資産に変えられるBUSDやBNBなどのコインが狙われやすいので、メジャーなコインを取引する際の操作には注意しましょう。

--- # 【基礎】ビットコインFX（仮想通貨FX）における必要証拠金とは？特徴や計算方法を徹底解説 今回の記事では、ビットコインFXの用語理解として『証拠金』について深堀りしていきたいと思います。 ビットコインFX（仮想通貨FX）は証拠金(レバレッジ)取引とも言われ、『証拠金』に関する用語として『証拠金維持率』『必要証拠金』『追加証拠金』『拘束証拠金』などがあります。 そのため、ビットコインFXを仮想通貨… 正規URL: https://3mikan.com/archives/2587 著者: みかん 公開: 2021-09-17T15:51:41.000Z 更新: 2021-12-12T09:05:43.000Z

今回の記事では、ビットコインFXの用語理解として『証拠金』について深堀りしていきたいと思います。

ビットコインFX（仮想通貨FX）は証拠金(レバレッジ)取引とも言われ、『証拠金』に関する用語として『証拠金維持率』『必要証拠金』『追加証拠金』『拘束証拠金』などがあります。

そのため、ビットコインFXを仮想通貨運用として取り組む上で『証拠金』は大切な用語になります。

『レッジの損益計算がよく分からない方』『必要証拠金や証拠金維持率などの計算方法を知りたい方』『追証やロスカットのルールを知りたい方』など初心者の向けの基礎知識として参考になれば嬉しいです。

今回の記事から身につく知識
  • 証拠金とFX取引の関係性
  • 資金を守るための計算方法
  • 資金を守るためのポイント

これから取り組もうと考えている方は重要な内容ですので是非最後まで読んでください。

ビットコインFX(仮想通貨FX)における証拠金とは？

BTC(ビットコイン)FXでは、『証拠金』という担保を預け入れる事でポジションを保有することができます。

また、各取引所の口座に入れた資金を『証拠金』といい、レッバレッジ取引ではこの資金源を超えた取引が可能になります。よく、レバレッジ取引にかける為の『担保』と説明される方が多いです。

  1. 必要証拠金：余剰資金が少ない方は確認したい！
  2. 証拠金維持率：大切な資金を守る上で確認したい！
  3. 追証証拠金：取引所を選ぶ際に確認したい！
  4. 拘束証拠金：証拠金維持率との関係性について確認したい！
  5. 注文中証拠金：拘束証拠金との関係性について確認したい！
  6. 有効証拠金：証拠金との違いを理解する上で確認したい！
  7. 余剰証拠金：自分の余裕度を把握する上で確認したい！

今回はこの７つの『証拠金』について解説します。

ビットコインFX（仮想通貨FX）を取り組んでいる方や取り組もうと考えている方にはとても重要な用語になります。では、証拠金に関するそれぞれの用語について詳しく解説していきたいと思います！

ビットコインFXにおける必要証拠金の計算方法について

言葉どおり、BTC(ビットコイン)FXの取引に最低限必要な資金の事を指しています。

自分のポジションを持つ際に『買い・売り』を決めるだけでなく、『数量・レバレッジ数』なども決めると思いますが、それらの取引金額に応じて必要になる資金です。

レバレッジをかけるということは、自分が持っている資金よりも多くの資金のポジションを持つということになりますので、その際の「証拠」となる資金を自分が払う形になります。

レバレッジ倍率から合計の購入金額が計算できることから、証拠金も計算することができます。

必要証拠金の計算方法

必要証拠金＝数量×レート（約定時価格）÷レバレッジ数

このように必要証拠金は計算することが可能です。

自分の持ちたいポジションの資金は、予め口座に入れておく必要があります。

ビットコインFXにおける証拠金維持率の計算方法について

BTC(ビットコイン)FXでよく証拠金維持率という用語を聞くと思います。

これは、あなたが仮にポジションを保有しているとしたら、その証拠金の残高の割合を指しています。

細かい計算も可能ですが、ざっくり理解するなら「残高がこれ以上減ると今のポジションが持っていられなくなるライン」とでも理解しておくといいと思います。

証拠金維持率の計算方法

証拠金残高(口座資金ー損失額)÷必要証拠金(ポジション÷レバレッジ数)×100

＝証拠金維持率

必要証拠金同様に、証拠金維持率も計算で求める事が可能です。

他のブログでも何度もお伝えしてきましたが、仮想通貨の相場は値動きが非常に激しいです。

そのため、この証拠金維持率がどれくらいを保っていると安全だと言うことが断言できない所ではありますが、証拠金維持率はロスカットと関係があるので非常に重要になります。

ロスカットの一般的な基準として、証拠金維持率が20〜30%と言われています。

ビットコインFXにおける追証証拠金について

取引所によって追証証拠金がある所とない所があります。

証拠金以上の損失が出てしまった場合、追加証拠金が発生します。イメージ的には、借金になります。

個人的には、追加証拠金がない取引所をおすすめします。なぜかというと、ロスカットされた場合にリセットして再度新しくポジションを持つことが可能だからです。

追加証拠金の支払いをしないと新しく取引ができなかったり、借金のように返済しないといけない形になると追加の損失を被ることになります。

追証証拠金がない取引所のメリット

追証証拠金は、追加で支払わなければいけないものです。そのため、追証になるたびに請求がきてしまいます。

ポジション保持(損失が出た場合)▶追証▶ロスカット。

この順序で取引が行われる為、追証がない取引所の場合、ロスカットされるまで支払う必要はありません。

追証をすることで、証拠金維持率が上がり取引が継続できる点においてメリットを感じる方もいらっしゃるかと思います。ただ、追証をしてもロスカットされてしまう場合はありえますので注意が必要です。

取引所によって追証のルールは異なります。

もし追証がある取引所を利用される方は事前にリサーチすることをおすすめします。

ビットコインFXにおける拘束証拠金の計算方法について

言葉どおり、取引の際に拘束される証拠金を拘束証拠金と言います。

拘束証拠金の計算方法

注文中証拠金＋必要証拠金＝拘束証拠金

注文中証拠金は、発注済未約定の注文に必要な金額を指しています。指値・逆指値の新規注文をしている分の証拠金額を注文中証拠金といいます。

拘束証拠金から証拠金維持率を求める事も可能です。

拘束証拠金＋評価損益÷拘束証拠金×100%＝証拠金維持率

ビットコインFXにおける有効証拠金について

よく、証拠金とセットで有効証拠金というワードも耳にすると思います。

有効証拠金は、取引として利用可能な証拠金の総額を指しています。

有効証拠金と証拠金の違いは？？

証拠金と含み損益の合計金額が有効証拠金になります。

含み損益は、まだ決算していない損失の事をいい決済した場合損失に変わります。

そのため、計算方法は証拠金ー含み損益の金額＝有効証拠金になります。

※利益が出ている場合は＋で求め、ポジションを持っていない場合の有効証拠金は、証拠金＋0円＝有効証拠金で求めることが可能です。

評価損益から有効証拠金を求めるため、市場にあわせて数値も変動します。

なお、証拠金維持率は有効証拠金を元に計算されます。チャートの動きに合わせて有効証拠金の残高が上下するために証拠金維持率が変動する理由です。

有効証拠金÷必要証拠金＝証拠金維持率

ビットコインFXにおける余剰証拠金の計算方法について

余剰証拠金は、自分の口座の余裕度を数値化したものになります。

有効証拠金のうち消費されていない資金を指しています。

余剰証拠金の計算方法

有効証拠金ー必要証拠金＝余剰証拠金

この計算からもわかるように、余剰証拠金が大きいほど比較的安全な取引を行えているということがわかってくると思います。逆を言うと、この余剰証拠金に余裕がない場合リスクが高い取引をしていると言えます。

余剰証拠金がマイナスになった場合、証拠金維持率もマイナスになっています。

『ロスカットがされやすくなる』ということと『通貨の購入ができなくなる』という事はおさえておきましょう。また、レバレッジを上げることで必要証拠金が低くなります。これにより、余剰証拠金を増やすということも一つの戦略になると思います。

証拠金取引のまとめ

  • 必要証拠金：自分のトレードしたいポジション分は予め用意！
  • 証拠金維持率：ロスカットの基準は維持率が20〜30%！
  • 追証証拠金：追証証拠金のあるなしは事前にチェック！
  • 拘束証拠金：拘束証拠金からも証拠金維持率を求めることが可能！
  • 注文中証拠金：指値・逆指値注文の新規の証拠金を指す！
  • 有効証拠金：証拠金との違いを理解！
  • 余剰証拠金：自分の余裕度を把握！

今回紹介した証拠金は7種類です。

値動きの激しい仮想通貨の市場を逐一計算で求めるのは、厳しいです。そのため、計算ツールを利用したり事前にエクセルなどで計算式を作成することをおすすめします。

特に「レバレッジを◯倍で取引したい」と先に決めておけば、証拠金は計算できます。自分の残高に合わせてレバレッジを調整することは非常に重要です。（プロは5~10倍で取引していると言われています。）

損益ばかりに目がいきがちですが、証拠金を理解することでFXについてかなり詳しくなります。知識として、用語理解は深めていく事が大切です。

https://3mikan.com/archives/2486
--- # 【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】 今回の記事では、仮想通貨取引には欠かせないウォレットの一つである『メタマスク（MetaMask）』について解説していきたいと思います。 『どのウォレットがいいか悩んでいる』『メタマスクの作成方法が分からない』『メタマスクについて詳しく知りたい』そんな方は是非参考にしていただければと思います。 正直なところ…… 正規URL: https://3mikan.com/archives/3598 著者: みかん 公開: 2021-10-30T16:32:25.000Z 更新: 2021-12-09T14:10:19.000Z

今回の記事では、仮想通貨取引には欠かせないウォレットの一つである『メタマスク（MetaMask）』について解説していきたいと思います。

『どのウォレットがいいか悩んでいる』『メタマスクの作成方法が分からない』『メタマスクについて詳しく知りたい』そんな方は是非参考にしていただければと思います。

正直なところ…メタマスク（Metamask）を作成するだけで、できることの幅がかなり広がります。『仮想通貨の運用を始めたい』『仮想通貨の知識を広げたい』『メタマスクを利用しているが利用用途を広げたい』そんな方も入口の基礎知識として最後まで読んでいただけると嬉しいです。

メタマスク（Metamask）とは

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

メタマスク（Metamask）とは、数多くある仮想通貨ウォレットの一つです。

ウェブウォレットタイプのウォレットになっていて、ブロックチェーン上のトークンを管理／送金／出金／受け取りなどを可能にしてくれます。

今年から話題に上がることの多いNFTなどのブロックチェーン技術を利用したサービスと連動し、様々なサービスの利用も可能にしてくれます。

知名度からも分かるように、ユーザー数が最も多い仮想通貨ウォレットです。私自身も利用していますが、初心者の方はもちろん一番最初に利用するウォレットとしておすすめです。

DeFiに参加する上でウォレットは必須

メタマスク（Metamask）が必ず必要なサービスの一つに『DeFi』があります。

新たな金融系として注目度を年々集めているDeFiですが、必ず仮想通貨ウォレットとの連携を求められます。

DeFiとは？？

DeFiとは日本語で分散型金融と言います。

ブロックチェーン上で構築された金融サービスになっていて、金融機関のような中央集権システムを必要としないものになっています。

このサービスにより、多くの収益化を生み出す事が可能になりました。

https://3mikan.com/archives/316

メタマスク（Metamask）以外の有名なウォレット

メタマスク以外にも、ウォレットは複数あります。

サービス内容が異なりますので、利用される前に各ウォレットのガイドマップを読まれることをおすすめします。

Trustwallet（トラストウォレット）

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

Trustwalletは、2017年より開始された仮想通貨ウォレットになります。

世界最大暗号通貨取引所のBINANCE（バイナンス）の公式ウォレットにもなっていて、これにより複数の仮想通貨を管理できるようになりました。

ただ、Appleの規約でTrustwalletのブラウザが削除されたことによってiPhoneユーザーは少々使いにくいかもしれません。

Safepal（セーフパル）

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

Safepalは、オンライン上で管理ができるウォレットと外部機器で管理ができるハードウェアウォレットの両方に対応している仮想通貨ウォレットになります。

今年から独自トークンの発行も行っていて保持すると手数料の割引などを受けることが可能になっています。

取り扱い通貨数が豊富・機能面も豊富なSafepalですが、国内取引所を経由せずクレジットカードからの直接入金も可能なので利用がしやすいと思います。

メタマスク（Metamask）はスマホアプリも用意されている

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像
2019年からiOS/Android共にスマホアプリが対応可能になりました。

これによって外出先でも安心して取引を行う事が可能です。

※PCブラウザでは、chrome/Firefox/Brave/Edgeの拡張機能に対応しています。

スマホからDeFiを操作することも可能

スマホ版アプリが使えることによって、スマホからもDeFiを操作することも可能です。

そのため、外出先でもファーミングやコンパウンドなどの取引が可能です。

https://3mikan.com/archives/1593

メタマスク（Metamask）を利用するメリット

メタマスクを利用する7つのメリットを紹介したいと思います。

  1. メタマスクの作成は無料
  2. 各チェーンのトークンをまとめて管理できる
  3. 取引所が証明つしても自分のウォレットなので安心
  4. トークンのスワップができる
  5. ガス代が自分で調整できる
  6. シードフレーズ・秘密鍵を使えばどの端末でも復元できる
  7. DeFiを操作できる

メタマスクの作成は無料

  • PCブラウザの拡張機能の利用
  • スマホ版アプリからの利用

メタマスクは、PC／スマホ共に無料で作成が可能です。

各チェーンのトークンをまとめて管理できる

  • イーサリアムメインネット
  • Matic mainnet
  • BinanceSmartChain　など

Maticでは、自分のウォレットアドレス一つで各チェーンのトークンをまとめて管理することができます。

取引所が消滅しても自分のウォレットなので安心

仮想通貨ウォレットは自分の財布と同じと考えて大丈夫です。

そのため、仮に利用していた取引所が消滅した場合でもウォレットが使えなくなる事はありません。

トークンのスワップができる

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

メタマスクではトークンのスワップを行う事ができます。

ウォレットを通じてスワップが行えると言うことは、わざわざ取引所を利用してトークンを交換する必要がなくなるので手数料面でのコスト削減や取引所選びに時間を割く手間がなくなります。

ガス代が自分で調整できる

14597814179746_0

メタマスクでは、自分でガス代の調整が可能です。

Confirmする際に編集というボタンが右上に表示されるので、そこで設定を変更することが可能です。

その設定で必ず通るとは限りません。ガス代が高いユーザーから順に承認されていく為、低くすればするほど処理される確率も低くなります。

シードフレーズ・秘密鍵を使えばどの端末でも復元できる

メタマスク作成時ですが、シードフレーズという12個の単語が表示されます。仮にウォレットの復元が必要になる場合（スマホを新しくした・無くしたなど）必要なワードになります。

この秘密鍵を利用すれば、どの端末でもウォレットの復元が可能な為必ず必ず必ずメモに残しておきましょう。そして、第三者に教えることがないようにメモは大切に保管しておきましょう。

自分の資産を守る為にも他のウォレットを作成する際もこのワードが出たら必ず必ずメモしてください。

DeFiを操作できる

メタマスクのウォレットを一つ作成するだけで多くのDeFiのサービスを利用することが可能です。

メタマスクを利用したDeFiのサービス方法をいくつか紹介していますので、参考にしてください。

https://3mikan.com/archives/240
https://3mikan.com/archives/574

メタマスク（Metamask）を利用するデメリット・リスク

メタマスクには3つのリスクも存在します。それぞれ紹介していきます。

  1. 操作ミスで送金時にトークンを紛失する可能性がある
  2. エラーが起きて再インストールが必要になる時がある
  3. シードフレーズ・秘密鍵を無くすと全て紛失する可能性がある

操作ミスで送金時にトークンを紛失する可能性がある

メタマスクに限らず、仮想通貨ウォレットの送金時に注意する必要があります。

送金時のネットワークを間違えるとその資金は紛失してしまいます。

例：メタマスク→バイナンスに送金する

メタマスクからバイナンスなどのCEXに送金する場合、ネットワークの選択を正しく行わないと資金が紛失します。

バイナンスなどは入金時にネットワークの選択画面があり、どのネットワークを選んだかで入金アドレスが変わります。

例えば、"ERC20"に送るつもりなのに"BEP20"を選択して入金アドレスに資金を送ってしまうと着金しません。

このパターンで資金を紛失している方が非常に多いので気をつけてください。

例：バイナンス→メタマスクに送金する

例えば、BINANCE（バイナンス）からETH（イーサリアム）をメタマスクに送金する際ネットワークの選択が３つほど出てきます。

  • BinanceChain（BEP2）
  • BinanceSmartChain（BEP20）
  • Ethereum（ERC20）

メタマスクで利用したいネットワーク宛に送金してください。どのネットワークを選択してもメタマスクには着金しますが、そのネットワークでしか利用できません。

※BINANCE（バイナンス）からBTC（ビットコイン）など他の通貨の場合も同様。

エラーが起きて再インストールが必要になる時がある

まれにですが、メタマスク操作中にエラーが消えなかったり保留中が永遠に続いたりする場合があります。

様々な方法がありますが、一番効果的なのは再インストールになります。

ブラウザでの操作中の場合は、拡張機能から消去／スマホの場合はアプリの消去を行い再度インストールしてみてください。

シードフレーズ・秘密鍵を無くすと全て紛失する可能性がある

メリットでお伝えしたシードフレーズですが、逆を言うと資金の全てが紛失する可能性があります。

シードフレーズのメモを忘れたり、他人に教えてしまったりといったことがあると自分の資金を失うリスクは高くなってしまうので必ずメモを取る事／第三者には教えない事を徹底しましょう。

メタマスク（Metamask）の作成方法：PC（ブラウザ）

メタマスクのパソコンでの作成ですが、アプリではなく拡張機能として利用します。

※操作時間は3分ほどです。

①ウォレットの作成方法

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

ブラウザで『メタマスク／Metamask』どちらかで検索をします。

  • chrome
  • Firefox
  • Brave
  • Edge

対応ブラウザは上記4つです。

基本的に検索すると一番上にくるかと思いますが、ウェブストアの『Metamask』をタップ。

ダウンロードができる画面が表示されているかと思います。完了後の手順は下記画像順になります。

ここから先は、画像で解説していきます。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

"メタマスク"と検索するとwebサイトが出ます。まずは「開始」から進めてください。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

はじめてウォレットを作る場合は「ウォレットの作成」から進んでください。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

どちらを選択しても大丈夫ですが、「同意します」を選んであげましょう。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

ウォレットを開く時のパスワードです。これはウォレット自体のパスワードではなく、端末側に保存されるパスワードです。

つまりPC、スマホで違うパスワードを設定することが可能です。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

ここから、シードフレーズの説明に入ります。ここからが最も重要です。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

シードフレーズ部分をクリックして表示しましょう。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

シードフレーズは12個の単語です。必ずコピーしてください。

順番も大事になるので、順番もそのまま保存しましょう。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

先程メモしたシードフレーズをそのまま入力していきます。パズルのような感覚で並べていきましょう。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

これで、ウォレット作成の手順は全て完了です。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

②アカウント（ウォレットアドレス）の追加方法

メタマスクでは、複数のウォレットを作成することが可能です。

ウォレットアドレスを分けることで自分の運用資金を細かく管理することも可能です。

ここから先は、画像で解説していきます。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

まずはウォレットの右上に表示されているアイコンをクリックしてください。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

「アカウントの作成」をクリックします。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

アカウントに名前をつけることが可能です。アカウントと書いてありますが実際には「新しいウォレット」です。2つめの財布を作るようなイメージで考えてください。

用途別にアカウントを分けたりする方が多いです。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

作成が完了すると前のウォレットとアドレスが違うウォレットが作成できたことが分かると思います。

③一覧に表示されるトークンの追加方法

ウォレット作成時、『ETH』のみが表示されています。

その為、他のトークンを利用したい場合トークンの追加が必要になります。

ここから先は、画像で解説していきます。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

まずは「Import tokens」をクリックしてください。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

選択したいトークンの名前を検索します。メジャーではないトークンの場合は、「カスタムトークン」からインポートが必要です。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

カスタムトークンから、直接コントラクトを貼り付けてトークンを追加することが可能です。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

例えばUSDTを追加する場合には、USDTと検索して追加します。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

Import Tokensをクリックしたら完了です。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

トークンの個別ページに飛べたら完了している証拠です。トップでは一覧で残高も確認できるようになります。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

④ネットワークの追加方法・変更方法

ウォレット作成時、『イーサリアムネットワーク』のみが表示されています。

その為、BNBなどのBinanceSmartChainのトークンなどを利用したい場合ネットワークの追加が必要になります。

ここから先は、画像で解説していきます。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

右上の「イーサリアムメインネット」と記載のある箇所をクリックしてください。

それまでに色々操作している方は違う名称が記載されている可能性があります。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

一覧で出てきた別のネットワークをクリックすると変更することができます。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

ネットワークを追加したい場合には「カスタムRPC」をクリックします。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

各項目を埋めて「ネットワークの追加」をすれば完了です。

入力すべき項目は、各ネットワークのガイドなどに記載があります。参考にしてください。

⑤ウォレットアドレスの取得

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

自分のウォレットアドレスはタップするだけで取得することが可能です。

⑥送金方法

メタマスク内の他のウォレットに資金を移行することも可能ですし、他の取引所への送付も可能です。

ここから先は、画像で解説していきます。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

ウォレットの送金ボタンを押します。各トークンページからも可能です。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

送付先のウォレットアドレスを入力します。

【DeFi】メタマスクとは？PC・スマホアプリ操作方法完全版！作成・送金（入金出金）・ガス代変更【Metamask】の説明画像

トークンと数量を入力して「次へ」進めていってください。

メタマスク（Metamask）の作成方法：スマホ（アプリ）

メタマスク（Metamask）はスマホからも簡単に作成が可能です。

※iPhone／Android共に可能です。

①ウォレットの作成方法

それぞれの端末にあるアプリストアで『メタマスク／Metamask』の検索をしダウンロードしてください。

ここから先は、画像で解説していきます。

1

PC版と流れはほとんど同様ですが、「新しいウォレットの作成」から進み、シードフレーズをメモしてください。

2

パソコンで作成したウォレットを反映も可能です。

  1. シードフレーズを利用する場合
  2. QRコードから同期する場合

上記二通りの方法がありますが、ブラウザによっては拡張機能のQRコードを現在利用することができない場合もあります。※Chrome可能／Firefx不可能

３

②アカウント（ウォレットアドレス）の追加方法

ウォレットを追加後名前の変更も可能です。

４

ウォレットアドレスの追加は、アイコンをクリックしてアカウント一覧を表示させ、下部に表示される「新しいアカウントの作成」から追加できます。

③一覧に表示されるトークンの追加方法

ホーム画面下にある『トークンの追加』から操作することが可能です。

  • 検索して追加
  • トークンアドレスから追加

二通りの追加方法があります。

５

ホーム画面の下（トークン一覧の一番下）に「トークンの追加」が表示されているのでそこから追加していきましょう。

追加方法はPC版と全く同様です。

④ネットワークの追加方法・変更方法

イーサリアムメインネットのみが最初ありますが、設定から他のネットワーク追加ができます。

PCでと操作が異なりますが、簡単に追加することが可能です。

６

スマホアプリの場合は「設定」→「ネットワーク」から新規追加ができます。ここのみ操作が異なり、あとは基本的にPCと同様です。

⑤ウォレットアドレスの取得

ウォレットを取得し取引所などの送付先としても利用することが可能です。

７

⑥送金方法

メタマスクから他のウォレットに送付することが可能です。

８

補足：「Dapp」って何？なぜメタマスクが必要？

冒頭で説明した『DeFi』ですが、DeFiのサイトは全てメタマスクまたは他のウォレットアプリが必要です。

『Dapp』と『DeFi』の関係性はDappについて理解するとわかります。

Dappとは？？

Dappとは日本語で、分散型アプリケーションといいます。

通常のアプリは、サーバーを主体として管理される方式で動作しています。このような中央集中型のアプリケーションはその単一箇所が動かないとシステム全体が障害となるようなリスクを抱えています。

Dappでは、ネットワーク全体でサーバーとコミュニティーによって共同管理されるので単一障害点がなく、過去のデータを操作することができない透明性のある環境を構築することが可能です。

これを金融（Finance）に応用したものが『DeFi』です。共同管理と過去のデータを改竄できない思想を応用したものです。

これにより信頼性の高い分散型金融プラットフォームを創造することが可能になりました。

DappおよびDeFiでは、「分散型」がポイントです。

そのため分散型金融においては、一般的な取引所のように全てのユーザーのウォレットを一元管理することはありません。

各ユーザーが自分で自分のウォレットを管理するという"分散型"の仕組みになっています。これが、各自がウォレット（メタマスクなど）を利用しなければいけない理由です。

「いまいちイメージがつかめない...」という方は、下の２つの例を考えてみてください。

  1. ●●銀行に入っているあなたのお金
  2. あなたのお財布に入っているあなたのお金

①の銀行の場合には、"銀行が潰れたり、ハッキングされて資金が盗まれたら"あなたのお金は盗まれてしまいますよね。

メタマスク（Metamask）のまとめ

今回の記事では、メタマスクの作成から用途について解説しました。

メタマスクは、PC/スマホ共に数分で作成をすることが可能です。管理方法や送金方法などに関しても、比較的に初心者の方でも利用しやすいウォレットになっているかと思います。

注意点としては、作成時の『シードフレーズの保管』／送金時の『ネットワークの選択』この２点がメタマスク利用時の注意して欲しい箇所になります。

今後DeFiを利用したい方や興味のある方は必要になりますので参考にしていただけると嬉しいです。

最後まで読んでいただきありがとうございました。

https://3mikan.com/archives/3708
--- # 【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方 今回の記事では、最新レンディングサービスの『Qubit Finance』について解説したいと思います。 レンディングプロトコルと言えば、最近CreamFinanceが3度目のハッキングをされ14億円もの被害を受けました。資産構築においてレンディングは便利なサービスではありますが、Defiのリスクを体感する事… 正規URL: https://3mikan.com/archives/3833 著者: みかん 公開: 2021-11-04T15:54:22.000Z 更新: 2021-12-05T14:53:08.000Z

今回の記事では、最新レンディングサービスの『Qubit Finance』について解説したいと思います。

レンディングプロトコルと言えば、最近CreamFinanceが3度目のハッキングをされ14億円もの被害を受けました。資産構築においてレンディングは便利なサービスではありますが、Defiのリスクを体感する事件だったと思います。

今回の記事では、『レンディングサービスに興味がある』『他の仮想通貨運用方法を覚えたい』『Qubit Financeについて詳しくしりたい』そんな方の参考になれば嬉しいです。

実際にQubit Financeでレンディングした手順を画像付きで解説していきます。

Qubit Financeとは？

1500x500

Qubit Financeは、2021年7月に誕生した新しいレンディングプロトコルになります。

11月現在Qubit FinanceのTVL（預け入れ総資産）は、日本円で680億円ほどです。この『Qubit Finance』ですが、自動福利運用の『Pancake Bunny』を運用しているチームが立ち上げたレンディングプロトコルになっています。

このことから、一つ実績があるチームとしての信頼性は高いと感じます。

また、QubitFinanceではガバナンスコインとしてQBTを受け取る事が可能です。

レンディングプロトコルとは？

レンディングプロトコルとは、名前の通りレンディングが可能なプロトコルです。

具体的に何ができるかというと、Supply(預ける)とBorrow(借りる)の２つができます。言い換えると、誰かが預けたものを借りることができたり、自分が預けて自分で借りるということもできます。

また、BTCやETHなどスワップせずに持っておきたいトークンがある場合にはとても便利です。

例えば、何か運用したい場合はスワップする必要があります。ただ、この操作をした後にトークンの価格が上がった場合、「もったいないことした」というパターンになることもあります。

特に今後もトークンを持っておきたいという人にとってはスワップしたくない方もいると思います。そういう時にこのサービスを利用しトークンを預け、他のトークンを借りて運用すると言う流れです。

そのため、ホールドしておきたいトークンがあるときなどの普通であれば、交換しないといけないトークンを、買い戻せなくなるリスクをヘッジすることができるのがレンディングです。

レンディングプロトコルの利率は高い？

『レンディングプロトコル』の良さとして、利率の高さがあります。

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

例えば、日本の年利だと0.001％ほどですがQubit FinanceではBNBを預けることで4.46％ほどです。

他の全てのDeFiプロトコルと比較するとAPRが小さく見えてしまいますが、レンディングの場合は主要なトークンの運用に使うことが多いです。

つまりBTCやETH・BNBなどの、その他ステーブル通貨を運用する場合は基本的にレンディングプロトコルから選ぶことになります。

利用率に応じて利率が上がる制度を取っているので、Borrow側が多くなると20%程度などかなりいい利率になります。

レンディングプロトコルの注意点とは？

  • ハッキングされやすい
  • プロジェクトによって条件が異なる

レンディングプロトコルの注意点として上記2つが挙げられます。

レンディングプロトコルはハッキングされやすい

『ハッキング』されやすい理由としては、TVLが集まりやすいことから狙われやすいという点です。

冒頭でも説明したように、CreamFinanceは今年に入り3度のハッキングを受けトータル89億円もの被害を出しています。

レンディングプロトコル＝「狙われやすい」というのがいちばんの理由なので、利用する場合は過去に起きている事件を確認することをおすすめします。

絶対に安全とは思わずに、どういう事件が起きているのか自分も被害者になりうるリスクがあることを確認する必要があります。

レンディングプロトコルはプロジェクトによって条件が異なる

プロジェクトによって利用できるトークン・条件が異なります。

「預けられるトークン」「借りられるトークン」「担保にできるトークン」が違うので、自分が預けたい／借りたいトークンによって利用できるプロトコルが変わってきます。

もう一つは、Borrow Limitまでの割合(借りることができる上限の割合)も異なります。

そのため、『Qubit Finance』だけでなくその他のレンディングプロトコルもリサーチする事をおすすめします。

Qubit Financeの対応ネットワーク

現時点でQubit Financeの対応ネットワークは、BEP20のみです。

送金の際送り間違いのないように注意が必要になります。

Qubit Finance以外の有名なレンディングサービス

Qubit Finance以外にもレンディングサービスはいくつかあります。

気になる方は各プロジェクトの利用方法を参考にしてください。

Venus（ビーナス）

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

Venusでは、ステーブルコインとして『VAI』・ガバナンスコインで『XVS』を貰う事ができます。

Defiの運用で懸念する理由の一つに手数料がありますが、バイナンスが提供しているBSC上で運用することができるのでコストを抑えた運用が可能です。

https://youtu.be/YVc-n6khiP4
※Venusの使い方はこちらを参考にしてください。

ForTube（フォーチューブ）

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

他のプロトコルと比べると、多少ではありますが返済金利が低いのがこの『Fortube』です。

利用可能なネットワークは、BSC／ETH／BSC／Polygon／OEC／Arbitrumです。アセットも世界的に人気ある通貨が多いので、利用のしやすさがあると感じます。

https://3mikan.com/archives/1235
※Fortubeの使い方はこちらを参考にしてください。

AAVE（アーベ）

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

レンディングサービスの中でも古くからあり規模が大きいのがこの『AAVE』です。

AAVEは、イーサリアムネットワーク（ERC20）・Polygon 上で運用することができるプラットフォームになります。フラッシュローンという一つの決済で借り入れ・返済を処理することで、無担保で仮想通貨を借りることができるサービスを一番はじめに始めたプロトコルでもあります。

https://3mikan.com/archives/1305
※AAVEの使い方はこちらを参考にしてください。

Qubit Financeの使い方

実際にQubit Financeを利用し今回はETH（イーサリアム）を預けQBTを借りたいと思います。

事前にすることとしては、上記2点です。

ネットワークがBSCの為、メタマスクのSmartChainにBinanceからETH（イーサリアム）を入金しQubitFinanceとMetamaskの連携を行ってください。

Supply(預ける)の方法

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

『Supply Markets』でETHの選択をし『APPROVE』していきます。

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

全額預ける場合は『Max』ボタンで入力することが可能です。

トランザクションとガス代の表示がありますので確認ボタンで進みます。
※今回のガス代は0.003BNBほどでした。

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

『APPROVE』から『Supply』に変わったらボタンを押してください。

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

ガス代の『確認』が再度でてきますのでそちらを押して完了です。

Borrow(借りる)の方法

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

ETHを担保にしてQBTを借りたいと思います。

『Collateral』のバーの部分をタップします。

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

『UseETHasCollateral』をタップしガス代の確認をします。

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

この画面がでたら担保にすることが完了しています。

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

『BorrowMarkets』でQBTを借りていきます。
※今回のガス代は0.006BNBほどでした。

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

これで借りる一連の流れが完了しました。

QBTのRewardがあるのでNETAPRが増えた事が確認できると思います。

その他の利用手段（ガバナンスコインを更に運用）

QubitFinanceの運用方法としてもう2点紹介します。

  • ガバナンスコインを預け入れる
  • ガバナンスコインをロックする

※参考程度に利用される場合は、ガイドラインを確認の上利用してください。

ガバナンスコインを預け入れる

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

QubitFinanceでは、ガバナンスコインとしてQBTを受け取れます。

画面右上で確認することができます。

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

手順はETHで預け入れをした流れで行う事ができ、預けることでよりAPRを上げることが可能です。

ガバナンスコインをロックする（QBT Locker）

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

QubitFinanceでは、『Locker機能』がありこれを利用して運用することも可能です。

この機能もAPRを上げることが可能になり、最大2.5倍の利率を上げることができます。

14597814179746_0

1週間から最大2年までのロック期間を選択することが可能です。

Qubit Financeのまとめ

【QubitFinance】BSCの新レンディングサービスを紹介！QBT Lockerの解説・使い方の説明画像

QubitFinanceを実際に利用する過程を紹介しましたが、これから読み取れる事としてこの工程だけですでに資産がプラスであることが分かると思います。

ETH（イーサリアム）は預けた事で金利が発生し、QBTは返済分がー5.42％ありますがボーナスが＋33.8％です。そのため、借りるだけで返済分を引かれてもプラスである事がわかります。

しかし、利用者が増加すればするほどAPRは下がります。このQubitFinanceも当初は、ETHを預けると10％ほどの利率ありましたが私が今回預けた際は0.5％でした。それでも国内の金利と比べるとかなり高いですが利用する場合はリスク含めガイドライン確認の上利用することをおすすめします。

興味がある方は実際に利用しながらレンディングプロトコルについて理解を深めていただければと思います。最後まで読んでいただきありがとうございました。

--- # 【仮想通貨FX】逆指値（条件付き注文）とは？基本的な使い方・注文方法・メリット・デメリットを紹介 今回の記事では、仮想通貨取引で利用できる注文方法の一つである逆指値注文について解説して行きたいと思います。 特に本業がある方や運用時間が限られている方など、チャート画面をみている時間の確保が難しい方におすすめの注文方法になります。この注文方法は自動で決済する流れなので場面に応じて利用することが可能です。 仮… 正規URL: https://3mikan.com/archives/2216 著者: みかん 公開: 2021-08-22T12:50:40.000Z 更新: 2021-11-22T17:37:26.000Z

今回の記事では、仮想通貨取引で利用できる注文方法の一つである逆指値注文について解説して行きたいと思います。

特に本業がある方や運用時間が限られている方など、チャート画面をみている時間の確保が難しい方におすすめの注文方法になります。この注文方法は自動で決済する流れなので場面に応じて利用することが可能です。

仮想通貨FXで利用することが可能な注文方法として、成行き注文／指値注文／OCO注文／IFD注文／IFD-OCO注文などがありますが今回はその中の『逆指値注文』について解説します。

簡単に説明すると現在の価格より、『高くなったら買いたい・低くなったら売りたい』注文方法です。比較的利用しやすい注文方法ではありますので使い方含め理解しておきたいポイントを知っていただければ嬉しいです。

仮想通貨FXでは『条件付き注文』から注文する必要がありますが、通常の指値注文ではできない逆指値の注文方法を知りたいという方は、是非最後まで読んでいただければと思います。

逆指値とは

逆指値注文は、条件を満たした場合に自動で発注される注文です。

『逆指値』という言葉通り、指値注文の逆になります。指値注文では通常『指定した価格以下で買い注文・指定した価格以上で売り注文』ですが、この逆を行うため逆指値と呼ばれます。

指定していた条件より高くなったら買い・低くなれば売りの注文が自動で入るように設定する注文方法です。

S__25141250

（例）現在の価格を1200円とします。1100円の売り注文の予約をしている状態です。

①指値注文の場合

▶この時点で1100円の売り注文を行ってしまうと1200円で約定してしまいます。現在価格が1200円の為、その瞬間に約定し、売りポジションに変わってしまうという事です。

②逆指値注文の場合

▶この時点で1100円の売り注文を行っても、現在価格が1200円の為注文はすぐに実行されません。指定した価格まで現在価格が下がった時に、1100円の売り注文が実行されるという事です。

逆指値注文の使い方

今回は大手海外取引所のBYBIT（バイビット）での逆指値注文を例にします。

  1. 逆指値で損切りする手順
  2. 逆指値を利用し利確・損切り両方を注文する手順
  3. 逆指値を利用しトレンド市場に乗る手順

この3つの利用手順を紹介していきます。

逆指値注文を利用する前に知りたいこと

【仮想通貨FX】逆指値（条件付き注文）とは？基本的な使い方・注文方法・メリット・デメリットを紹介の説明画像

仮想通貨FXでは、『逆指値注文』という注文は無く『条件付き注文』を利用して注文を出します。

画像の逆指値注文の内容

『48500.00以下になったら売り注文を実行する』という注文になります。

この状態ではまだポジションになっていないので、証拠金などは利用されていないです。

その為、注文内容の変更／キャンセルを行う事が可能な状態で、現在の株価が条件を満たした時に市場に注文が発注されます。

逆指値の使い方：流れ①（逆指値で損切）

リスクを抑えたい時に利用する方法です。

今利確したいわけではないが、相場が予想と反転した場合損失を最小限に抑えたい時に利用することができます。

【仮想通貨FX】逆指値（条件付き注文）とは？基本的な使い方・注文方法・メリット・デメリットを紹介の説明画像
  1. 条件付きを選択：参入注文から変更が可能です。
  2. 価格の設定：トリガー／注文価格の値を決めます。
  3. 注文タイプの選択：
    トリガーは3種類可能【成行・インデックス・マーク】
    注文価格は【成行・指値】
    ※ここを「成行」にすると純粋な逆指値注文が発注できます。
  4. 数量の選択：買い・売りの数量を決めます。
  5. 逆指値注文：市場が、上がった場合ロング（買いの注文）／下がった場合（売りの注文）で参入します。
今回の逆指値注文の意味
  1. BTCが上がると予想したので、$49001.00で『買いの注文』を入れました。
  2. 相場が仮に下がった場合に備えて、$48500.00で『売りの逆指値』注文も出します。
  3. 相場が48500.00まで下がり、売り注文が実行された場合$501の損失に限定という意味になります。（実質的な損切り）

※損失の拡大を防止するために、逆指値を利用した例になります。

逆指値の使い方：流れ①の応用版（利確ライン＋逆指値で損切）

仮想通貨の市場は、レンジ相場８割と言われています。

そのため、相場が読みにくい時利確として利食いを設定して発注に加えて反転した場合のリスクヘッジとして損切り注文として逆指値を活用する方法です。

【仮想通貨FX】逆指値（条件付き注文）とは？基本的な使い方・注文方法・メリット・デメリットを紹介の説明画像
今回の逆指値注文の意味
  1. BTCが上がると予想したので、$49001.00で『買いの注文』を入れました。
  2. $51467.5の売りの指値(利食注文)と同時に相場が仮に下がった場合に備えて、$48500.00で『売りの逆指値』注文も出します。
  3. 相場が予想通り上昇し、$51467.5で利確設定。逆に相場が下落し48500.00まで下がった場合には、売り注文が実行され$501の損失に限定という意味になります。

※読みにくい相場に対してトレンドに乗れるように、フォロー注文として逆指値を活用。

逆指値の使い方：流れ②（トレンドフォロー）

上昇トレンド／下降トレンドの２つ市場に対してトレンドに乗って利益を出せるように逆指値を利用します。

【仮想通貨FX】逆指値（条件付き注文）とは？基本的な使い方・注文方法・メリット・デメリットを紹介の説明画像
今回の逆指値注文の意味
  1. （現在レンジ相場で下降トレンドになる予想）
  2. レンジ相場が崩れ、下降トレンドと見極められる瞬間（$48,500）に売り注文が入れれるように逆指値を設定
  3. 相場が$48,500を下回ると自動的に売りポジションを持ち、下降トレンドに乗っかる形で利益を出せる

逆指値のメリット３つ

  • 上昇・下降しそうだと思う所で逆指値注文を利用し、上昇トレンド・下降トレンドに乗ることができます。（トレンドフォロー）
  • 今回の利用方法のようにリスクヘッジに繋げる事も可能です。（損切として利用）
  • 予想と逆のパターンになってしまっても一定の利益を確保することが可能です。（利確として利用）

①トレンドに乗り利益に繋げられる

上昇・下降しそうだと思う所で逆指値注文を利用し、トレンドに乗ることができます。

トレンドを見分けるのが難しい場合でも、逆指値を利用することでトレンドに乗ることができます。

②リスクを最小に抑えられる

利用方法でも紹介したように、損切りとして逆指値を利用することが可能です。

そのため、チャートを見ていられない時間に暴落などがあったとしても逆指値注文をオーダーしておくことでチスクを抑えることができます。

③損失をカバーする

予想と逆の市場になることの方が多いと思います。

そんな時でも、逆指値をタイミングよく利用することで利益を確保するのにつなげることも可能です。

逆指値のデメリット３つ

  • レンジ相場になっている場合、指定している相場に中々入る事がなく注文が実行されにくい。
  • 手数料が発生する。仮想通貨の取引は取引ごとに手数料が発生するのでそちらを含め利益幅を作る必要がある。
  • 相場の変動が激しいことが多いため、損切りとして活用する場合とトレンドで利用する場合に備えたい。

①注文が実行されない

レンジ相場になっている場合、自分で指定している相場に中々入る事がない時があります。

その場合は注文に変わることがないので、チャートを見る時間がある場合は指値注文を活用したほうがいいです。

②手数料のコストが発生する。

仮想通貨の取引は注文ごとに手数料がいくつか発生するのでそちらを含め利益幅を作る必要があります。

今回紹介した、Bybit（バイビット）の手数料をしりたい場合はこちらを参考にしてください。

https://3mikan.com/archives/2344

③相場によっては利用する方がリスク

仮想通貨の相場は変動が激しいことが多いため、市場が反転してもまたすぐ反転する場合もあり逆指値注文がよりリスクに繋がる場合もあります。

今回紹介した以外にも損失限定条件付き利食い狙い／利益確定／レンジ抜けの買い・売りなど逆指値の利用パターンは他にもあります。

しかし、損切りとして活用する場合とトレンドで利用する場合この２つの場合に利用する事をおすすめします。

逆指値の補足

  • 逆指値の場合の利確・損切りとは？
  • 逆指値が利用できない取引所は？
  • 指値注文と逆指値の違いは？

逆指値注文の補足説明として３点紹介します。

逆指値の場合の利確・損切りとは？

noname

逆指値をリスクヘッジとして使う際に利確・損切という言葉がでてきます。

それは、上の画像のAさんBさんが同じ結果になることを利用しています。

AさんとBさんが同じタイミングで１BTCを保有したとします。

Aさんは60,000$に利食注文を入れました。
Bさんは60,000$に売りの指値注文を入れました。

60,000$に到達したのでAさんは利確。
▶10,000$の利益確定。

Bさんは売りの注文が入り両建ての状態になります。
▶両建てのポジションを持った時点で10,000$の利益が確定しています。

つまり、AさんとBさんは注文方法は違いますが同様の決済を行っていることになります。
（両建てができない取引所の場合はBさんの取引は自動的にAさんの取引と同様になります）

逆指値が利用できない取引所は？

すべての取引所で逆指値注文が利用できるわけではありません。

利用する前に確認するのが良いでしょう。

【仮想通貨FX】逆指値（条件付き注文）とは？基本的な使い方・注文方法・メリット・デメリットを紹介の説明画像

両建てができない取引所の場合はこのように、売りの注文を入れようとすると利確(利食)になるのでポジションを持つ証拠金は発生しません。

新しくポジション持たなくとも現状のポジションを決済することで希望の注文方法を実現できるため、新規ポジションのための証拠金が不要になるのです。

※上記取引画面はBinance（バイナンス）になります。

指値注文と逆指値の違いは？

冒頭でも説明したように、指値注文の逆を行うので逆指値注文になります。

上記で手順を紹介したように、逆指値の場合はすぐに注文として市場にでる指値注文と違い決定実行ではなく『こうなるかもしれない』というリスクヘッジや利益に拡大に繋げる注文方法になります。

指値注文の内容：１０００円以下で買う／１０００円以上で売る

逆指値注文の内容：１０００円以上になった場合買う／１０００円以下になった場合売る

このように、注文内容の目的が異なるので自分の場面に応じて使い分けることをおすすめします。

逆指値のまとめ

逆指値注文は主に

  1. 損失に備えて注文を設定しておく
  2. トレンドフォローができるように注文を設定しておく

この2つを実現するために使える注文方法です。

今回紹介したBybitでの逆指値注文ですが、細かいトレード方法はこちらのブログで紹介していますので興味がある方は参考にしてください。

実際に利用することでより『逆指値注文』のやり方手順が理解することができると思いますので、余剰資金がある方は挑戦してみるのも良いかもしれません。Bybitでは少額からでも取引が可能です。

最後まで読んでいただきありがとうございました。

https://3mikan.com/archives/1945
--- # NFT化とは？仕組み・特徴・面白いNFT・NFT化の価値・リスク・注意する点を紹介！ 今回の記事では、『NFT化』について解説していきたいと思います。 よく耳にすることが増えたNFTですが、デジタルデータに数億円の価値が付くなどNFTの価値には驚く事が多くあります。またNFTのジャンルも幅広くなってきているなと感じるこの頃です。 今回はそんな面白いNFTをいくつか紹介しながら『NFT化』につ… 正規URL: https://3mikan.com/archives/3871 著者: みかん 公開: 2021-11-06T09:49:19.000Z 更新: 2021-11-06T09:49:33.000Z

今回の記事では、『NFT化』について解説していきたいと思います。

よく耳にすることが増えたNFTですが、デジタルデータに数億円の価値が付くなどNFTの価値には驚く事が多くあります。またNFTのジャンルも幅広くなってきているなと感じるこの頃です。

今回はそんな面白いNFTをいくつか紹介しながら『NFT化』について深堀りしていきたいと思います。

今回の記事から学べること
  • NFT化とは？仕組み・特徴について
  • なにがNFT化できるか？面白いNFTの紹介
  • NFT化の価値とは？リスク・注意する点も

NFTとは？

NFTとは、日本語にすると非代替性トークンと呼ばれます。

仮想通貨技術のブロックチェーンを利用したデジタルデータです。

このブロックチェーンを利用する事で、デジタルデータに価値を創造することが可能になりBTC(ビットコイン)やETH(イーサリアム)のようにNFT(非代替性トークン)にも資産価値が発生します。

NFT化の仕組みとは？

NFTの３つの特徴からNFT化の仕組みについて理解したいと思います。

  1. ブロックチェーンで『一意性』が証明される
  2. トークン同様ウォレットに保存して利用ができる
  3. だれでも作成することができる

ブロックチェーンで「一意性」が証明される

NFT(非代替性トークン)は、デジタルデータ管理にブロックチェーン技術を利用したことにより他の作品とは交換することが不可能になり「一意性」が証明できるようになりました。

NFTを購入すると『Token ID』が発行され、モノを保有する権利を証明されます。

この『Token ID』が異なる場合は「違うモノ」とみなされるため、結果的に一意性が保てるということです。

トークン同様ウォレットに保存して利用することができる

NFT化とは？仕組み・特徴・面白いNFT・NFT化の価値・リスク・注意する点を紹介！の説明画像

NFTを購入した場合、そのデータは購入サイトだけでなく自分のウォレットにも保存されます。

そのため、トークン同様に利用（送金など）することが可能です。

誰でもNFTを作成することができる

NFTは、特に何かしらの技術や資格がなくてもだれでも作成することが可能です。

BTC(ビットコイン)やETH(イーサリアム)といった通貨を発行するとなると難しく感じますが、NFT(非代替性トークン)は自分で作成したデジタルアートのコンテンツをNFTマーケットプレイスで出品するだけです。

デジタルアートを作った事がある方などは、手順はさほど変わりませんのでより簡単にNFT化することが可能だと思います。

何がNFT化できる？

どんなものがNFT化することができて、できないのか？

これについては、NFTの用語理解をすることで分かってくると思います。

NFTは英語で『Non Fungible Token』と書きます。

「ファンジブルトークン」の逆なので、代替不可能なトークンという事になります。この意味を元にいくつかおもしろいNFTがあったので紹介したいと思います。

※『ファンジブル』についてより詳しく知りたい方は下記の記事を参考にしてください。

https://3mikan.com/archives/3552

編集長の役職を『NFT化』？？

2021年11月15日より『NFT化』して発行することが決定している『役職NFT』があります。

発行元は、株式会社トレジャーコンテンツという日本の企業になります。

目的としては、編集長という役職をNFT化することで関ってくれた方がバトンを引き継いだ後も誰がかかわっていたのかブロックチェーン上に残すことができるという点です。

この取組は日本初めてになり『関わってきた人が徐々に繋がっていく世界観が、メディアという一種の作品を通して可視化される』と㈱トレジャーコンテンツが発表しており魅力あるNFTだと感じました。

気になる収益化の部分ではありますが、歴代の所有者には報酬を分配する仕組みになっているそうです。より詳しい内容を知りたい方はチェックしてみてください。

日本を象徴する刀を『NFT化』？？

2021年10月27日〜10月29日の期間で開催されていた、ブロックチェーンEXPOのNFTブースで世界初の『日本刀のNFT』が出展されました。

目的としては、日本刀は伝統的な価値ある資産の為、この日本刀とNFTをかけ合わせたことで資産を守ることができるという点です。

現物資産の保管に着目したNFT化は様々なところで検討されており、よくみかける今後のNFT展開として不動産があると思います。

現在は不動産という現物に対して所有権は「書類」で管理されています。実際に不動産を持ち歩くことはできないので、所有権を示す書類で代行しています。

この書類を電子化できないかと考えついた先がNFTです。わざわざ「紙」にしなくてもNFT化することで、所有権をブロックチェーン上で管理でき、譲渡も容易になります。

自分自身を『NFT化』？？

少し前の話にはなりますが、23歳のフランス人が自分をNFT化し日本円で200万円ほどで投資家さんの手に渡りました。

目的としては、将来自分の会社を創る上でスタートアップとしての資金調達になります。

自分をトークン化するということは、信用・信頼を買ってもらうという事になりそうですがクラウドファンティングとしてもすごく手軽に活用できることを証明されたNFT化だと感じました。

しかし、リスクももちろんあります。NFTで資金調達した場合に限らずですが、投資家の意見に自分の行動をコントロールされる可能性があるためです。

一方で、NFTは「人権侵害」までは効力を持たないと思われますので、全て投資家にコントロールされる状態になる可能性は低いでしょう。

NFT化で価値が付く理由とは？

2015年からNFTが登場し、2021年の前半から急成長している市場のNFTは、自分で作成した作品(資産)をNFT化することによって販売・購入・転売などにより資産の価値を高める事が可能です。

基本的に一次流通の売買がほとんどですが、二次流通を身近にできることはとても魅力的に感じます。

ではなぜ資産価値を創造することができるのか？という点ですが。

ブロックチェーン

最も多い利用が、デジタルアート／ゲームといった所有証明書としての、デジタルとデジタルの掛け合わせになっています。最近では、物理的なモノとの所有証明書としての、有形とデジタルの掛け合わせもでています。

このことから一意性を証明することができなかった分野にNFTを活用することで希少価値の創造を可能にしているので、ブロックチェーンという技術が価値を創造している気がします。

だれでも入れる市場ではありますが、安易に始めるほどだれでも利益を生み出すことが可能なのかと言われると個人的には違う気がします。

例を出すなら、YouTuberが流行っているからYouTube初めて見たけどなかなか簡単な分野じゃない…となるようなイメージです。

収益化の一つの手段ではありますがまずは、「NFTという概念」の学習や資産・アイデアとして触れてみるのがいいでしょう。

今後のNFT化にはとても期待ができるため、資産構築の分野として情報を集めていきたいところです。

NFT化の注意点

NFT化するにあたっていくつかの注意点があります。

  • ガス代が高い
  • 著作権問題がある

主にこの2つが『NFT化』にあたっての注意点になります。

上記2つは自分が販売する上での注意点ですが、購入者側にも注意しなければならない点がいくつかあります。

実際にあった事件を参考にNFT化のリスク・注意点を知りたい方はこちらの記事を参考にしてください。

https://3mikan.com/archives/3299

ガス代が高い

NFT化する際ですが、ブロックチェーン技術を利用していることからガス代が発生します。

そのため、手数料分を考えた価格設定が最初は大切になるかもしれません。または、ガス代が発生しないオフチェーンのマーケットプレイスも存在します。

自分の取引をどういった市場でおこないたいのか？どのNFTマーケットが適しているのか？リサーチする必要が出てきます。

個人的におすすめは、OpenSeaです。手数料は発生しますが、規模感が違うので安心した取引が可能です。

著作権問題がある

NFTは、権利者でないけどマネタイズが可能になってしまう場合があります。

例えば有名な漫画のどらえもんやワンピースなどの画像を勝手に出品することができてしまいます。

そのため、自分が著作権を持っていなくても販売が可能です。気持ちがいい売買ができるように、この問題は個々に気をつける必要があります。

NFT化のまとめ

今回は『NFT化』について解説してきました。

個人的に今後どんなものが『NFT化』されるのか、気になるところではあります。

販売する側・購入する側共に注意する点がNFTにはありますので利用される場合は様々な情報を確認の上取り組むんでみてください。

各マーケットプレイスの利用法方もいくつか紹介していますので、これから『NFTを作成・販売したい』『NFTを購入したい』そんな方は是非下記記事を参考にしていただければと思います。

https://3mikan.com/archives/3326
https://3mikan.com/archives/3446
--- # メタマスク（Metamask）の送金操作方法・反映されない、遅い場合の対策・キャンセルの方法 今回の記事では、メタマスク（Metamask）の送金について解説していきたいと思います。 メタマスクを一番利用する用途は送金だと思います。操作一つ一つは簡単ではありますが、初めて利用する場合慣れるまでは難しいと感じることが多いかと思います。 この記事では、初心者の方向けに送金の操作方法について紹介してますの… 正規URL: https://3mikan.com/archives/3708 著者: みかん 公開: 2021-10-31T07:44:59.000Z 更新: 2021-10-31T08:00:36.000Z

今回の記事では、メタマスク（Metamask）の送金について解説していきたいと思います。

メタマスクを一番利用する用途は送金だと思います。操作一つ一つは簡単ではありますが、初めて利用する場合慣れるまでは難しいと感じることが多いかと思います。

この記事では、初心者の方向けに送金の操作方法について紹介してますので『メタマスクの操作方法を知りたい方』は是非最後まで読んでみてください。

送金ミス／操作エラーなどの対処法も紹介しますので参考にしていただき、今後起きるかもしれないトラブルにスムーズに対応できるように備えて頂ければと思います。

メタマスク（Metamask）の送金操作方法

メタマスクの送金といってもパターンが多く存在するわけではありません。

やり方流れはとても簡単に取り組む事が可能ですが、『操作ミス』がトラブルに繋がりやすいのでそれらの操作方法含めて紹介していきたいと思います。

メタマスクからトークンを他のアドレス宛に送金する

パソコンからの操作方法になります。

メタマスクから他のウォレットへの操作方法です。

メタマスク（Metamask）の送金操作方法・反映されない、遅い場合の対策・キャンセルの方法の説明画像

ウォレットの『送金ボタン』を押します。各トークンページからも可能です。

メタマスク（Metamask）の送金操作方法・反映されない、遅い場合の対策・キャンセルの方法の説明画像

自分が送りたい送付先のウォレットアドレスを入力します。

メタマスク（Metamask）の送金操作方法・反映されない、遅い場合の対策・キャンセルの方法の説明画像

トークンと数量の指定を行ってください。

この時ガス代分を残した金額にしましょう。最大（MAX）の金額にしてしまうと送付操作を実行することができません。金額の横にある『最大』をタップし入力した場合はガス代を引いた金額を自動的に表示してくれます。

メタマスク（Metamask）の送金操作方法・反映されない、遅い場合の対策・キャンセルの方法の説明画像

最後に、gas feeの金額が記載あると思います。

今回ETH（イーサリアム）での一連の操作ですが、ガス代がかなり高いことが分かると思います。

初めてDeFiに触る人は、資金を準備する時点で手数料が結構発生するので注意しましょう。

メタマスクのスマホアプリで送金する方法

スマホからも簡単に送金することが可能です。

操作方法はパソコンとほぼ同じです。

スマホめた

メタマスクの送金が反映されない場合

１５謙遜
こじか

メタマスクから送金したはずなのに着金されてない・・・。

メタマスクの送金が反映されない場合は、いくつかの状況や原因が考えられます。それぞれの理由と対策を記載していきます。

先にチェーン上の状態を分けてください。 tx hash、receipt、status、block、from、nonceを使ったpending・failed・dropped候補・replacedの判定は、トランザクション状態の確認フローで説明しています。receiptがsuccessなのに取引所の残高へ反映されない場合は、取引所入金のTxID・confirmations・Memo確認手順で受取側の条件を確認します。誤ったnetwork・addressを疑う場合は、追加送金を止めて送信chainと送付先の管理主体を確認する手順へ進んでください。

メタマスク側の送金が失敗している

pwDhs

メタマスク側の履歴を見ると確認できますが、メタマスク側で送金処理が失敗している可能性があります。

メタマスクアプリの「アクティビティ」から確認してみてください。エラーが起きている場合はエラーの表記が出ています。

エラーが出ていた場合には再送すれば問題ありません。

逆にエラーが出ていない場合には、送金が正しく行われています。

受取側の反映が一時的に遅い

受け取り側で反映が遅れているパターンです。

そもそもですが、取引所などに送付した場合には着金側の確認作業（Confirming）があります。着金してから確認作業が終わるまで残高には反映されません。

バイナンスなどでは確認作業の進捗は入金履歴から閲覧可能です。このパターンは待っていれば解決されます。

送金のトランザクションがまだ実行されていない

一時的にネットワークが混んでいる状態だと、トランザクションが実行されていない可能性があります。

PolygonがIRON FINANCEで流行った時などにはよく起きておりました。

この場合も、メタマスクのアクティビティを確認しましょう。実行前のトランザクションがある可能性があります。

screely-1600955671450

受け取り側（取引所）のバグ

稀に、受け取り側（特に取引所）のバグがあり反映されない時があります。

私も一度バイナンスにSOLを入金した際に反映されなくなりました。こうなった場合には、まずは一旦落ち着きましょう。

ブロックチェーンは全てのトランザクションが保存されています。つまり、あなたが取引所の入金アドレス宛に送金した履歴も記録されています。

そのトランザクションのTxIDを送りましょう。ブロックチェーンエクスプローラーのURLを送ればOKです。

ブロックチェーンエクスプローラーとは？

ブロックチェーン上のデータを見やすくしてくれているサイトです。

ETH(ERC20)ならEtherScan、BNB(BEP20)ならBscScanのようにそれぞれのネットワークで用意されています。

以下の3点を用意して、お問い合わせフォームから送るといいです。

  • ブロックチェーンエクスプローラーのURL
  • 指定された入金アドレスのスクリーンショット
  • あなたのウォレットアドレス

送り先間違いによる紛失・ネットワーク違い

最悪なパターンがこれです。アドレスを間違えて送ったり、ネットワークを間違えて送るパターンです。

特に取引所に送る場合は、入金アドレスは毎回確認しましょう。一定期間で切り替わる可能性があります。

また、入金時にネットワークの選択を必ず確認してください。『メタマスクはBEP20なのに、バイナンスのERC20に送金する』といった紛失パターンが非常に多くあります。

メタマスクの送金が失敗する場合

１５謙遜
こじか

手順通り送金操作したはずなのに送金エラーになる・・・。

メタマスクの送金が失敗する場合は大きく２つです。

ガス代が不足している

まず、ガス代が不足していて送れないパターンです。ガス代分のトークンを補充すれば問題ありません。

ETHネットワークで、ETHを全額送金する際などに起きやすいエラーです。とはいえ、分かってしまえば対策は簡単です。

ガス代分を残して送るか補充して送るようにしましょう。

アドレスがネットワークの規格にあっていない

アドレスとネットワークの規格が違うパターンです。

例えば、ERC20系のネットワーク（BEP20、Polygonなどなど）は全て0x〜〜のアドレスになっています。

ということは、ERC20で送金をする際に送金先のアドレスが0x~~になっていない場合はエラーになります。

メタマスクの送金をキャンセルしたい場合

１５謙遜
こじか

メタマスクからの送金をキャンセルしたいけどできるのかな・・・。

送金のキャンセルは可能です。しかし、トランザクションが実行される前に行わなければいけません。

screely-1600955671450

上画像の時点で、矢印と逆の「Cancel」を押して実行してください。間に合った場合にはキャンセル処理が行われます。

メタマスクの送金が遅い場合

１５謙遜
こじか

メタマスクからの送金処理が長い・・・まだ終わらないよ。

メタマスクの送金が遅いのは、トランザクションが実行されていない状態です。

送金のトランザクションがまだ実行されていない

一時的にネットワークが混んでいる状態だと、トランザクションが実行されていない可能性があります。

PolygonがIRON FINANCEで流行った時などにはよく起きておりました。

この場合も、メタマスクのアクティビティを確認しましょう。実行前のトランザクションがある可能性があります。

screely-1600955671450

メタマスクの送金が保留になる場合

１５謙遜
こじか

メタマスクから送金したいのに保留になってしまった・・・。

メタマスクからの送金が「保留」になる場合です。これは、メタマスク側で完了しているにも関わらず取引所側で「保留」と表示される場合のことです。

このパターンでは、時間経過で完了する可能性が非常に高いので待ちましょう。

受取側の反映が一時的に遅い

受け取り側で反映が遅れているパターンです。

そもそもですが、取引所などに送付した場合には着金側の確認作業（Confirming）があります。着金してから確認作業が終わるまで残高には反映されません。

バイナンスなどでは確認作業の進捗は入金履歴から閲覧可能です。このパターンは待っていれば解決されます。

例：メタマスクからトークンをコインチェックに送金する方法

メタマスクにある資金をコインチェック（国内取引所）に送金したい場合、５分ほどで送金することが可能です。

仮想通貨ウォレット（メタマスク）と暗号通貨取引所（コインチェック）のアカウントがある前提で進めていきますのでない場合はこちらを参考に作成してみてください。

メタマスクの作成方法
コインチェック公式ページ
メタマスク（Metamask）の送金操作方法・反映されない、遅い場合の対策・キャンセルの方法の説明画像

コインチェック側のウォレットアドレスの取得をしていきます。

メタマスク（Metamask）の送金操作方法・反映されない、遅い場合の対策・キャンセルの方法の説明画像

『アドレス作成』から取得することが可能です。

メタマスク（Metamask）の送金操作方法・反映されない、遅い場合の対策・キャンセルの方法の説明画像

先程コインチェックで作成したアドレスをメタマスクの送金手順で実行していきます。

ウォレットアドレスを貼り付けし、数量の指定をしてください。

送金時にネットワークを間違えるとその資金は紛失してしまいます。

コインチェックのETH（イーサリアム）のネットワークは、ERC20です。コインチェックに限らず基本的に選択画面がなければERC20の為、ネットワークはイーサリアムメインネットを選択して送金処理してください。

他のネットワーク（例：BinanceSmartChainのETH）からコインチェックのアドレス宛に送ってしまうと資金を紛失してしまうので注意してください。

メタマスク（Metamask）の送金操作方法・反映されない、遅い場合の対策・キャンセルの方法の説明画像

確認ボタンで送金が完了します。

バイナンスに間違えて送金したら返金される？

基本的に、バイナンスなどの取引所に誤送してしまった場合返金されないと思った方がいいです。

バイナンスなどは入金時にネットワークの選択画面があり、どのネットワークを選んだかで入金アドレスが変わります。

例えば、”ERC20″に送るつもりなのに”BEP20″を選択して入金アドレスに資金を送ってしまうと着金しません。

このパターンで資金を紛失している方が非常に多いので気をつけてください。

リスクを回避する手段を一つ学ぶだけで、大事な資金を守ることが可能です。今回のメタマスクの操作方法を参考にしていただきリスク管理に繋げていただけると嬉しいです。

最後まで読んでいただきありがとうございました。

--- # 【DeFi】Vaults基礎知識！APY/APR/日利の関係性・計算方法の徹底解説 Vaultsは開発者の目線として面白い仕組みだと思っています。今回はそんなDefiのVaultsについて解説していきたいと思います。 こあら 「APYとAPRの違いがよくわからない...」「APYって結局なんのことなのかわからない...」「Vaultsの仕組み・使い方・見方がわからない...」「日利（dai… 正規URL: https://3mikan.com/archives/738 著者: みかん 公開: 2021-05-12T12:27:07.000Z 更新: 2021-10-28T12:36:40.000Z

Vaultsは開発者の目線として面白い仕組みだと思っています。今回はそんなDefiのVaultsについて解説していきたいと思います。

１３考える
こあら
  • 「APYとAPRの違いがよくわからない...」
  • 「APYって結局なんのことなのかわからない...」
  • 「Vaultsの仕組み・使い方・見方がわからない...」
  • 「日利（daily）をどう見ていいかわからない...」

こんな悩みを抱えている方向けの解説記事になります。一度目を通していただければ、複利の基本的なことからVaultsの深い知識まで一括で理解できます。


また『Vaultsの独自トークンを持つ』という事がどういうメリットに繋がるのか知りたい・効率的に資産を運用したいという方は是非読んでみてください。

Vaultsとは？利益の仕組み

Vaults(ボールト)と表現される事が多いですが、本来の機能からイールドファーミング・オプティマイザーという名称でも呼ばれています。

複利運用を自動で行うサービスで、その仕組みを解説していきます。

本来ファームで複利をしたい場合にはハーベストしてステークするという作業を行う必要があります（つまりCompound）。

ただ、Compoundを手動で行うにはいくつかのハードルがあります。

Compoundを手動で行う場合のハードル

  • 仕事などの関係で何回もDeFiサイトを開くことができない
  • 何度もCompound作業を行うのが面倒
  • 毎回ガス代が発生するため、ガス代がもったいない

こういった問題を解消してくれるのが『Vaults』です。自動でCompound作業を行ってくれるため、サイトを開く事もガス代の負担も無くなります。

イールドファーミング・オプティマイザー（最適化）という名称の由来はここにあります。

イールドファーミングでの運用を最適化するため、複利戦略を備えた運用方法を実現してくれるプロトコルがVaultsです。

Vaultsの紹介

BSCの有名所だけでも、13のVaultsがあります。

種類は多いですが、それぞれ内容に違いがあるため注意が必要です。（もちろんリスクも違います）

※BSCニュース参照画像

【DeFi】Vaults基礎知識！APY/APR/日利の関係性・計算方法の徹底解説の説明画像

実際に私が運用しているサービスの詳細に関しては、下記動画を参考にしてください。

https://youtu.be/dMdkrpfF8Q8
https://youtu.be/BAzCrSrGKlY

Vaultsの仕組みについて

個人的にVaultsの一番好きな仕組みは、運用している人のアイディアと開発力のみでサービスが作れる点です。ファームを作らなくてもいい部分と、資金もいらない点はかなり画期的だなと思っています。

【DeFi】Vaults基礎知識！APY/APR/日利の関係性・計算方法の徹底解説の説明画像

図のように、
①ユーザーはファームで複利運用をしたいと思っています。
そのため、『Vaults』に資金を預けます。

②複利マンは、その預かった資金をもとに複利運用を開始します。

③報酬は複利運用した人に返ってくるので、複利マンは受け取った報酬を元に手数料を引いた資金をユーザーに返却します。

これが、『Vaults』の仕組みになります。

Vaultsのポイント

  1. compoundが一回で済む！
    →複数ユーザーの資金をまとめて運用するため、ガス代の節約に繋がります。

    ※複利マン・ユーザー共に節約
  2. 運用先ファームは決まっている！
    →金融機関と違い運用先を考える戦略やロジックが不要

    ※そこを調整する必要がない為、運用方法を作る側としては楽
  3. 複利マンは、仕組みのみの提供で元手不要！
    →入金手数料・出金手数料・利益から運用手数料を取ることができる！

    ※個人的に一番すごいと思う点
  4. 独自トークンを報酬で出すケースが多い！
    →ファーム側ができるだけ多くの資金を集めたい為
  5. ファーム側は、TVLが増える！
    →詳しいメリットをしりたい方はこちらの動画をcheckしてください。
https://youtu.be/9zjCKIxcHsk

APY/APR/日利の違い・関係性・計算方法

APY・APRの違い

複利を考えるか考えないかという違いがあります。

APR＝複利を考えない方
APR＝複利を考える方

APR：年換算利回り
→『今の利率のまま１年間放置したとしたら何％になる？』
APY：年間利回り
→『今の利率のまま複利して運用したら何％になる？』
※daily-compound(１日１回複利)を元に記載されている事が多い。
Daily(Monthly)：日換算利回り
→『Daily＝APR÷３６５』逆『Daily×３６５＝APR』になります。
※同じように１２で割るとMonthlyも出すことができます。

この計算方法は是非、覚えて頂ければと思います。単純計算の為、APRが高くなればDAILYも高くなります。

例：BREWのLP

APR：301.49％
→『301.49％÷365＝0.83％』複利▶『100.83%**365 - 100% ≒ 1913.73％』

【DeFi】Vaults基礎知識！APY/APR/日利の関係性・計算方法の徹底解説の説明画像

複利効果早見表：日利（or APR）→APY

こちらの早見表では、日数に対してどのような倍率になるかを載せています。

例：1%で一年間運用すると37.78倍になる事が表から読み取れると思います。

【DeFi】Vaults基礎知識！APY/APR/日利の関係性・計算方法の徹底解説の説明画像

複利効率化：1%の100回複利と2%の50回複利どっちが高い？

早見表があることで計算がしやすいだけでなく、Vaultsを行う上で重要な考え方にも繋がると思います。

Q:Daily2％の運用先があったとします。半日(12時間)で１％。
(１日１回複利するor半日ごとに１日２回複利する)どちらの方が利率がよくなりますか？？

A:1日2回複利をするケースのほうが利率が良くなる
※表を見るとすぐに分かります。(１％の100回が２.７倍・2％の50回が2.69倍)

各自エクセルやスプレッドシートなどで作成しておくことをおすすめします！

【DeFi】Vaults基礎知識！APY/APR/日利の関係性・計算方法の徹底解説の説明画像

1%を100回の方が利率が良い事が表から分かったと思います。そのため、同じように考えるとできるだけ細かく複利(compound)したほうがいい事が分かります。（2％50回＜1%100回＜0.5％200回＜0.25％400回…）

この考えでVaultsについて考えると、できるだけ細かく複利を行ったほうがいいと言うことが分かってきます。

Vaultsの運用方法2パターン（ガス代負担型・ストラテジー型）

Vaultsの運用パターンは大きく分けて、ガス代負担型・ストラジー型の2パターンに分かれています。

ガス代負担型

・複利(compound)分のガス代を一般ユーザーに負担してもらう方式
・負担してくれたユーザーにはその時の運用益から一部報酬を出す

※compoundのガス代を一般ユーザーが負担してくれるので、Vaultsとしてはガス代がかからない。そのため、福利すればするほどユーザーは利益を出しやすいという形になります。

【DeFi】Vaults基礎知識！APY/APR/日利の関係性・計算方法の徹底解説の説明画像

ストラテジー型

・後述する理由で、compoundするタイミングのロジックを作っています。
・compoundは自動でbotが行う方式です。たまに一般ユーザーもいるハイブリッド方式がある。

※autofarmやbeefyなどはこちらの方式です。

【DeFi】Vaults基礎知識！APY/APR/日利の関係性・計算方法の徹底解説の説明画像

APR/APY/日利の関係から分かるストラテジーの予備知識

なぜストラテジーが存在するのかという点について。

・ガス代がかからない場合
→とにかく細かく複利を行ったほうがいいです。（1%と2％の比較参照）
→ストラテジーが不要
bearn(bVaults)・ValueDefi(vSafe)など
※ユーザーがcompoundを押してくれるほど勝手に運用してくれるので良い。

・ガス代がかかる場合
→複利する度にガス代がかかる為、細かくやると損になる。

例：1日100CAKE収穫できる（1回の収穫にガス代0.1CAKE発生）
1日1回（daily-compounded）＝ガス代0.1CAKE分
1日24回（hourly-compounded）＝ガス代2.4CAKE分

どちらのほうが利益がでるのか？これを最適化するのがストラテジーです。
※一番利益の出る所で止めないといけないと最適化してくれる。

→ガス代を考え、どれくらいpending(収穫待ちの報酬)が溜まったらcompoundするかというストラテジーを作ってbotで自動複利する。beefy・autoform・swampなど
※ストラテジーによって多少APYに差がでる。どこで複利するかが場所で違う為。

Vaultsのまとめ

  1. Vaultsは複利運用をスムーズにしてくれる機能
  2. Vaultsは『仕組み』を作っている。ファームを作る必要はない
  3. APR・APY・Dailyはシンプルな計算で繋がっている
  4. ガス代を考えなくてもいいならcompoundが多いほどいい
  5. ガス代を考慮してストラテジーを組んだbotがcompoundしている

便利なサービスではありますが、Defiは自ら積極的に調べることが何より大事ではあります。うまく活用しながら、運用手段の一つとして参考にして頂ければ嬉しいです。

--- # ビットコインETFとは？アメリカ（米国）の先物ベースBTCのETF承認について解説 今回の記事では、『ビットコインETF』について解説していきたいと思います。 2021年10月19日米国初の、ビットコイン先物ETFが取引開始され仮想通貨市場が賑わいを増しました。 日本国内では、程遠い話ではありますが今話題の『ビットコインETF』について紹介したいと思います。 『ビットコインETFについて知… 正規URL: https://3mikan.com/archives/3566 著者: みかん 公開: 2021-10-26T14:05:21.000Z 更新: 2021-10-26T14:05:22.000Z

今回の記事では、『ビットコインETF』について解説していきたいと思います。

2021年10月19日米国初の、ビットコイン先物ETFが取引開始され仮想通貨市場が賑わいを増しました。

日本国内では、程遠い話ではありますが今話題の『ビットコインETF』について紹介したいと思います。

『ビットコインETFについて知りたい方』『今後の仮想通貨市場が気になる方』などの参考になればうれしです。

ETFとは？

ETF-1

ETFとは日本語で『上場投資信託』と呼ばれています。金融商品取引所で取引される商品なので、投信会社指定の金融商品になります。

「上場投資信託」という名称の通り、ETFは「投資信託」です。それが上場しているか非上場なのかの違いで呼び方が変わっているだけです。

上場した銘柄は私達が証券取引所で売買できることになるので、一般的な投資信託と区別するためにETFという名称で呼ばれています。

証券取引所で売買できるということは証券会社に口座を開設するだけで株式同様に手軽な売買が可能ということです。同様の理由で、取引時間や最小金額などに制限があります。

ビットコインETFが登場

mockup-g5b430fc88_1920

現在ビットコインETFは、カナダ／ブラジル／ドバイで開始されおり今月(10月)からアメリカが参入しました。

2013年に米国では初めてビットコインETFによる上場申請がされましたが承認がされず、今回もスポットベースのビットコイン現物ETFは承認がされていません。

なにが米証券取引委員会に承認されたかというと、先物ベースの投資商品に限定された承認であり原資産を保有するものではありません。

その為BTC（ビットコイン）そのものではなく、BTCのデリバティブと連動がされています。

ETFによるビットコインへの影響

historical-stock-ga4a5e2267_1920

世界的には、今回アメリカで承認された先物ベースのETFではなくスポットベースのビットコイン現物ETFが主流になっています。

スポットベースのビットコインの良さとして、コスト面が挙げられています。先物ETFより、原資産の価格により密な運用が可能な為BTC（ビットコイン）を直接運用したい人にとっては魅力的だからです。

これらによって、ビットコインETFの登場が先物商品の需要が高まりETF市場に資本が流れBTC（ビットコイン）の買い圧力が高まることに繋がるかもしれません。

ビットコインETFまとめ

今回は、『ビットコインETF』について解説しました。

今までは、仮想通貨取引をしたいとなると各自取引所を選び口座を開設し運用をする必要がありました。

しかし、ビットコインETFの登場によって証券口座から仮想通貨に連動した投資が可能になり『新しくウォレットを開設しない』『仮想通貨取引所を通さなくてもいい』そんな運用が可能になりました。

また、『ETF』と『投資信託』とは何が違うのか？という点においては、上場しているのかいないのか／証券取引所を通じて取引するかしないかがポイントになります。

投資の世界に正解はありませんが、資産運用の幅を広げることは自分自身にあった取引も増えるので今後の運用の選択幅としても勉強していきたいところです。

最後まで読んでいただきありがとうございました。

--- # 「ファンジブル」とは？NFT（ノンファンジブルトークン）とトークンの違いを解説 今回の記事では、NFTブームによってよく耳にするようになった『ファンジブル』という単語について解説していきたいと思います。 そもそも、NFTはノン・ファンジブル・トークンの頭文字を取った用語になります。 言葉の単語を理解することで、よりNFT（用語）に関する知識が理解しやすくなると思います。今回の記事を通じ… 正規URL: https://3mikan.com/archives/3552 著者: みかん 公開: 2021-10-25T12:36:07.000Z 更新: 2021-10-25T12:48:29.000Z

今回の記事では、NFTブームによってよく耳にするようになった『ファンジブル』という単語について解説していきたいと思います。

そもそも、NFTはノン・ファンジブル・トークンの頭文字を取った用語になります。

言葉の単語を理解することで、よりNFT（用語）に関する知識が理解しやすくなると思います。今回の記事を通じて、トークンのあり方を知っていただけると嬉しいです。

『NFTの理解を深めたい』『トークンの概念を理解したい』そんな方は、是非最後まで読んでみてください。

「ファンジブル(fungible)」とは？

『ファンジブル』とは、直訳すると代替可能であることです。

世の中に同じ価値が存在し、代わりが効くことを意味する為ドル紙幣や円紙幣、BTCやETHなどの仮想通貨もすべてファンジブルトークンになります。

「ファンジブル」なモノの例

例ファンジブル

例えば、①と②の交換があったとします。

『ファンジブル』の概念でいうと、例①が正しい交換になります。

例②はたしかに、100円玉✖10枚＝1000円なので"両替"は可能です。（交換ではない）

100円玉10枚と1000円札1枚では機能が違います。このように、価値または機能にずれが生じてしまう場合はファンジブルではありません。

①の交換のように、自分が所持している1000円札と誰かが所持している1000円札を交換しても価値や機能が変わらず、同じように利用することが可能な場合を『ファンジブル』と言います。

その他の例：１BTCもファンジブルです。

NFTはノンファンジブルトークンの略称

NFTは英語でNon Fungible Tokenと書きます。

「ファンジブルトークン」の逆なので、代替不可能なトークンという事になります。

例：絵画・音楽などは全く同じものが存在しない為、同じ価値を創造することが不可能です。そのため、ノン・ファンジブルに分類されます。

「ファンジブル」に関する分類

  • ファンジブル・トークン（FT）：代替できるトークン
  • ノン・ファンジブル・トークン（NFT）：代替できないトークン
  • ハイブリッド・トークン（HT）：2つの中間に位置するトークン

トークンは、これら３つに分類することができます。

ファンジブル・トークン（FT）

FT（ファンジブルトークン）は代替することができるトークンになります。

代替することが可能という事は、他のトークンと交換をしても価値や機能は変わらないという事です。

仮想通貨や紙幣といった、自分と第三者で交換しても同じ価値として利用できるものをFT（ファンジブルトークン）と呼ばれています。

ノン・ファンジブル・トークン（NFT）

NFT（ノンファンジブルトークン）は、代替することができないトークンになります。

代替することができないという事は、同じ価値を持つものが存在しないという事になります。

絵画など今までは本物かどうか（一意性）を証明する事が不可能だったものを、ブロックチェーン技術を利用しデジタル化した事によってトークンとして利用が可能になったものがNFTと呼ばれています。

ハイブリッド・トークン（HT）

HT（ハイブリッドトークン）は、ファンジブルトークン／ノンファンジブルトークンの中間に位置するトークンになります。

代替可能かつ代替不可能でもあるという事であり、「数量制限のある代替可能トークン」と考えてもらうと良いです。

「コンサートのチケット」や「世界に5本だけしか無い腕時計」など個数に制限が有る場合、限られた範囲でのみ交換ができるがそれ以上の範囲では代替不可能になるトークンがHT（ハイブリットトークン）と呼ばれます。

「ノンファンジブルトークン」で実現できること

NFT（ノンファンジブルトークン）は、価値があると証明することができなかった分野にNFTを活用することで希少価値の創造を可能にしました。

現在は、デジタルアート／ゲームといったジャンルで所有証明書としてNFT化し販売することが多いです。最近では、物理的なモノとの所有証明書としての、有形とデジタルの掛け合わせもでてきました。

代替することができない一意性があるのがノンファンジブルトークン／作ることに制限が設けていなければファンジブルトークンです。この事を一つ覚えるだけで、どのような事が実現できるか非かを判断することが可能になると思います。

https://3mikan.com/archives/3124
--- # Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説 今回の記事では、Polygonのネットワークの参加方法（ETH→Maticブリッジを使う）について解説していきます。 簡単にPolygonを始めたい方は、取引所で直接Maticを購入して送る方法の方が簡単なので以下の記事のやり方をおすすめします。 https://3mikan.com/archives/13… 正規URL: https://3mikan.com/archives/869 著者: みかん 公開: 2021-05-15T14:41:59.000Z 更新: 2021-10-25T12:18:13.000Z

今回の記事では、Polygonのネットワークの参加方法（ETH→Maticブリッジを使う）について解説していきます。

簡単にPolygonを始めたい方は、取引所で直接Maticを購入して送る方法の方が簡単なので以下の記事のやり方をおすすめします。

https://3mikan.com/archives/1302

BSCに次ぐDefiと期待されているネットワークがMaticです。メインのDEXはQuickSwapで、トークンはQuickです。ガス代が安く、SolanaやFTMと同じくMaticというネットワークの中にDefiがあります。

今回はリブランディングをし、Polygonという名前になってから動きが活発になり話題になった為、利用方法について紹介したいと思います。詳しく知りたい方は、是非最後まで読んでみてください。

Matic（Polygon）の始め方について

現状バイナンスでMaticを購入することは可能です。

2021年10月25日現在、バイナンスでMaticの入出金が可能です。

※以下の内容はバイナンスがMaticに対応する前に執筆したものです。バイナンスがメンテナンス中で利用できない場合などに参考にしてください。

しかし、Maticネットワークでそのまま送る事ができません。そのため、はじめにイーサリアムネットワークに送りネットワークを切り替えて使う必要があります。

今回のやり方ではバイナンスでETHを購入し、そのETHをスワップしてブリッジする方法を取ります。

①バイナンスでETHを購入

クラシックをクリック

02CA8F80-ABCA-4BEF-B421-DFEE45DF6866

ETHの検索：ETH／BUSDのペアをクリック

EEDEC968-40C9-49DD-8F8F-C117B62418B3

今回は500ドル分購入してみます。

50349817-352B-47BB-8BBE-CC78E82D6D47_4_5005_c

②MetamaskにETH送金

先程購入したETHをMetamaskに送金します。

※イーサリアムネットワークであることを確認してください。

5E1921A3-0168-441A-9675-FA88427CD8D6

この画面がでたら、イーサリアムの出金リクエストが完了しています。

Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像

Metamask側にイーサリアムが届くまで待機します。

Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像

Metamask側で着金が確認する事が確認できました。

③Sushiswap（or Uniswap）でガス代分を残してETH→Matic スワップ

Sushiswapまたは、 Uniswapでガス代分を残してスワップしていきます。

ETH▶MATICにスワップします。

※今回はSushiswapを利用します。
※ブリッジガス代分のETHを残しておいてください。

638F4F1F-E093-446E-B249-349D05F14866
98062C5E-E361-48FB-AFF3-A435E0ADEACD

これで、スワップしていきます。

※ここも先程同様に時間がかかるので少し待機になります。

Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像

画面右上にこのような表示がでたら、Maticが購入できています。

④MetamaskにMaticネットワークを追加

Metamask右上にある『Ethereumメインネット』の中にある『カスタムRPG』を選択します。

Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像

Matic公式のMetamask設定解説ページより設定方法が出てくるので、同じように追加していきます。

Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像

入力後、保存で完了です。

Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像

⑤Matic web walletでETH→Maticに移行

Matic web walletを使いブリッジしていきます。

Metamaskをクリックし接続していきます。

Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像

Move funds to Matic Mainnetをクリック。

すると、EthereumからMaticに送る画面が表示されます。

Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像
Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像

Maticを選択後Transferしていきます。

Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像

Continueをクリックし進めていきます。

※この際のネットワークは、Ethereumメインネットを選択してください。（ETH→Maticへの変換となります）

Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像

Approveしていきます。

Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像

Confirm the Depositの表示がでたらContinueで進めます。

Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像

Confirmが完了するとこのような画面が表示されます。

こうなると、7分〜8分程でDepositできます。後は、Maticのウォレット側でMaticの着金待ちをしていきます。

Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像

Metamaskの方をMaticに変えて待機したいと思います。

Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像
Matic（Polygon）のDeFi参加方法・Ethからブリッジ・QuickSwapの使い方徹底解説の説明画像

Matic mainnetに届いたので、これでMaticのネットワークに参加することが可能です！

このMaticを使えばQuickSwapなどのMaticネットワークのDeFiに参加することが可能です。

QuickSwapでLPを組んだ後、RewardsでDepositしたりbeefyのQuick-MaticにLPを預けることも可能です。

Matic（Polygon）DeFi参加方法まとめ

操作で難しい部分が少しあるのと、全体的に待ち時間が長かったです。

今回ガス代に50$〜60$程発生しています。そのため、あまり動かす予定の資金がない方や初めてDefiを触る方は正直あまりおすすめはしないです。少し待てば、BSCからのブリッジやバイナンスからの直接の送金ができるようになるかもしれないのでそれを待つのもいいかなと思います。

参加される方は、やっている過程でガス代が足りなくならないように注意して頂ければと思います。

--- # 【NFT】各サイト手数料はどれくらい？NFT出品・販売・送付にかかる全ての手数料を徹底比較！ 今回の記事では、NFT取引における『手数料』について解説していきたいと思います。 手数料というと少額の事が多い為、なかなか気にすることがない方が多いと思います。しかし、仮想通貨の市場において手数料は無視ができないコストです。 利益を出していきたいと思えば思うほど、この手数料が負担に感じてきます。 今回はそん… 正規URL: https://3mikan.com/archives/3475 著者: みかん 公開: 2021-10-23T15:22:19.000Z 更新: 2021-10-25T08:38:42.000Z

今回の記事では、NFT取引における『手数料』について解説していきたいと思います。

手数料というと少額の事が多い為、なかなか気にすることがない方が多いと思います。しかし、仮想通貨の市場において手数料は無視ができないコストです。

利益を出していきたいと思えば思うほど、この手数料が負担に感じてきます。

今回はそんな手数料について、徹底的に解説していきます。『どこのマーケットプレイスがいいか分からない』『情報が多すぎてなかなかNFTの取引を始められていない』そんな方の参考になれば嬉しいです。

NFTのマーケットプレイスとは？

NFTにおけるマーケットプレイスは、通常のトークン（BTCなどの）プラットフォームとは概念が少し違います。

そもそも『NFT』とはブロックチェーン上のトークンであり、ブロックチェーンにおいて『トークン』は資産の１単位を示しています。

同じブロックチェーン技術を利用し作られているBTC（ビットコイン）などとなにが違うのかというと、NFTがさしているのはデジタル作品の所有権を意味しています。

ブロックチェーン技術を利用した事によって一意性を証明できるため、今まで市場取引が困難だとされていたアート／ゲーム／音楽といったジャンルで新たな価値を創造することが可能になりました。

そのNFTを一次販売・二次販売と取引できる場を提供してくれているのが、NFTマーケットプレイスになります。

NFTの売買にかかる手数料はどんなものがある？

  • 販売手数料／出品手数料
  • 決済手数料
  • 振り込み手数料
  • 入庫手数料
  • 出庫手数料
  • 出品手数料
  • 二次販売手数料
  • ネットワーク手数料
  • 発行手数料

各取引所によって、発生するもの／しないものがあります。

表記もそれぞれ異なるため、利用される前に一度取引所のガイダンスを確認されることをおすすめします。

初めてDeFiに触る人は、売買時の資金を準備する時点で各取引所で手数料が結構発生するので注意しましょう。（特に国内取引所を使った場合は手数料が高いです）

NFTのマーケットプレイス使いやすさ・手数料比較

年々NFTマーケットプレイスも増加し、販売所によってもサービス内容が大きくことなります。

私がおすすめする国内・海外のマーケットプレイスを紹介したいと思いますので、選択肢の参考にしていただければと思います。

【国内】おすすめのNFTマーケットプレイス

Coinchack NFT（β版）

【NFT】各サイト手数料はどれくらい？NFT出品・販売・送付にかかる全ての手数料を徹底比較！の説明画像

Coincheck NFT（B版）は日本国内で一番最初にできた、NFTマーケットになります。

オフチェーンの為、手数料の多くが無料です。出品時のネットワーク手数料(ガス代)は発生します。

入庫手数料無料
出品手数料無料
販売手数料販売価格の10%
出庫手数料0.01ETH（※ネットワークの手数料の変動によって変わる）

オフチェーンという部分がとても魅力ある取引所になります。

しかし、販売手数料が国内・海外の中でもとてもとても高いので、頻繁に売買したい場合は他の取引所に慣れた方がいいでしょう。

Adam byGMO（β版）

【NFT】各サイト手数料はどれくらい？NFT出品・販売・送付にかかる全ての手数料を徹底比較！の説明画像

GMOアダム株式会社がコンテンツ流通革命の支援を目的としたNFTマーケットプレイスは、2021年8月31日より販売を開始した比較的新しい販売所になります。

多様な決済方法により、NFTを簡単に利用することが可能になっています。

入庫手数料無料
出庫手数料0.005ETH／回
決済手数料クレジットカードの場合売上金の３%
日本円での支払いの場合300円手数料発生
振り込み手数料銀行振り込みの場合別途発生（各銀行によって異なる）
ネットワーク手数料ETH（イーサリアム）での支払いの場合別途発生
二次販売手数料売上金の５％（ロイヤリティの設定がある場合は別途プラスで発生）

AAdam byGMO（β版）では、日本円での取引が可能です。

そのため、仮想通貨を購入がしたことがないユーザーにとっては取引がとてもしやすいです。

【海外】おすすめのNFTマーケットプレイス

OpenSea（オープンシー）

OpenSeaは「NFTマーケットプレイス（NFTの売買ができる場所）」というジャンルの中で最も有名なサイトです。

一日の取引高は74億円（2021年10月現在）とピーク時には一日8万件という驚異の取引数を記録している最大手になります。

https://3mikan.com/archives/3326
入庫手数料（MINT）無料
販売手数料売上金の2.5%（ロイヤリティの設定がある場合は別途プラスで発生最大10%）

複数のネットワークを利用できるという点において、ユーザーからは利用しやすいと感じます。

また、NFTマーケットプレイスという業界では最大大手のため安心感はあり高い流動性によりほかのサイトよりは取り組みやすいかもしれません。

Rarible（ラリブル）

【NFT】各サイト手数料はどれくらい？NFT出品・販売・送付にかかる全ての手数料を徹底比較！の説明画像

Raribleはアメリカの会社が運営しているプラットフォームです。

取引量・アクティブユーザー数共に上位の為、とても人気のある取引所になります。

販売手数料売上の2.5％

Raribleでは、RARI（ラリ）と呼ばれるガバナンストークンを発行しており、これをファームで稼げることが一番の魅力だと思います。

Raribleで販売または購入をすることでマイニングができる市場流動性マイニングという仕組みをサービスとして提供しています。

また、OpenSeaと結合していることからRaribleで作成・収集したNFTをOpenSeaで管理することも可能です。ETHだけでなく、RARIでも購入が可能なのでお得な取引ができそうです。

BINANCE NFT

【NFT】各サイト手数料はどれくらい？NFT出品・販売・送付にかかる全ての手数料を徹底比較！の説明画像

2021年６月よりサービスが始められたBinance NFTは、主に３つのマーケットプレイスで販売をおこなっています。

Coincheck同様に、オフチェーンのプラットフォームの為お得な取引が可能です。

https://3mikan.com/archives/3446
発行手数料0.005BNB
取引手数料承認されたコントラクトアドレスからのNFT取引に関しては無料
二次販売手数料売上金の１パーセント（ロイヤリティとして）

自分の作品を販売したいという方には、現在サービスが一般公開されていないため利用ができません。

ただ、サイトの使いやすさ・見やすさ・購入に関してはとても使いやすいと感じました。

NFTのマーケットプレイスを使う際の注意点

販売・購入共に比較的に簡単に取引をすることが可能ですが、注意点がいくつかあります。

  • 購入のキャンセルや返品ができない
  • ユーザー同士の取引の為、品質を保証されない（偽物も存在する）
  • 仮想通貨の価格変動に巻き込まれる可能性もある

購入のキャンセルや返品ができない

NFTの場合、購入後返品やキャンセルを行う事ができません。

通常商品を購入すると、クーリングオフのような期間でキャンセルや返品が可能が場合がありますがデジタルの場合基本そのような処理はありません。

ウォレットを通じて決済する過程に、『確認』『署名』がありこの時に取引をキャンセルすることは可能ですが支払いしてしまうとキャンセル／返品ができませんので注意が必要です。

ユーザー同士の取引なので、品質を保証されない（偽物も存在する）

NFTは、自分に著作権がなくても作成・販売が可能のため、購入したNFTが偽物である可能性もでてきてしまいます。

例えば、有名な漫画の一つであるワンピースの画像をデジタルデータにしNFT化し販売することもできてしまいます。

NFTマーケットプレイスは、NFTの売買を可能にする場を提供してくれているだけであって、取引は商品を売りたいユーザーと商品を買いたいユーザー間の取引になります。

そのため、品質を保証されているわけではないので注意が必要です。

仮想通貨の価格変動に巻き込まれる可能性がある

NFT取引では、支払いの際基本的にほとんどの取引所が『仮想通貨』での支払いになります。

そのため、ETHやBNBで買うことが必然的に増え仮想通貨の価格変動に巻き込まれてしまう可能性が十分にあります。現に、ETHが高騰したことによってNFT取引では手数料が大きなコストになります。

個人的には、仮想通貨自体の知識をある程度持った上でNFTに取り組む事をおすすめします。

NFTのマーケットプレイス・手数料まとめ

今回の記事では、NFTにかかる手数料について解説しました。

取引所によって内容は異なりますが、1回の取引で複数の手数料が発生し取引回数が増えれば増えるほどもちろんコスト面が膨らんでしまいます。

手数料面だけでなく、NFT取引には様々なリスクも存在しますので取引の際には十分に気をつけて被害者・加害者にならない知識が必要です。

https://3mikan.com/archives/3299
https://3mikan.com/archives/3124
--- # 【NFT】OpenSea(オープンシー)とは？NFTの買い方・出品方法・手数料まで徹底解説 今回の記事では、NFTマーケットプレイスの最大大手である『OpenSea』について解説していきたいと思います。 NFTの情報を得ようとすると『OpenSea』という言葉はよく目にするほど有名なオンライン取引所になります。しかし、購入や出品方法は初心者の方からすると難しい点があります。 仮想通貨とはまた違う価… 正規URL: https://3mikan.com/archives/3326 著者: みかん 公開: 2021-10-19T16:24:31.000Z 更新: 2021-10-20T01:37:25.000Z

今回の記事では、NFTマーケットプレイスの最大大手である『OpenSea』について解説していきたいと思います。

NFTの情報を得ようとすると『OpenSea』という言葉はよく目にするほど有名なオンライン取引所になります。しかし、購入や出品方法は初心者の方からすると難しい点があります。

仮想通貨とはまた違う価値であるNFTですが、ブロックチェーン技術を利用していることにより購入・販売時にはETH(イーサリアム)やPolygon(ポリゴン)といった仮想通貨が必要になります。

今回は初心者の方でも、スムーズに取引が行えるように画像つきで解説していきたいと思います。

『NFTを購入・販売がしたかった』『仮想通貨の準備の仕方が分からない』という方の参考になれば嬉しいです。

OpenSea（オープンシー）とは？

【NFT】OpenSea(オープンシー)とは？NFTの買い方・出品方法・手数料まで徹底解説の説明画像

OpenSeaとは、NFTマーケットプレイスの一つになります。

一日の取引高は74億円（2021年10月現在）とピーク時には一日8万件という驚異の取引数を記録している最大手になります。

2021年前半から話題になることが増えたNFT市場ですが、同時にNFT取引所も増えています。初めての取引という方は、まずは取引数が最も多い『OpenSea』の利用をおすすめします。

NFTの有名なマーケットプレイス

OpenSeaは「NFTマーケットプレイス（NFTの売買ができる場所）」というジャンルの中で最も有名なサイトです。

ゲームなどのDeFiプロトコルよりは取引高は劣りますが、NFT売買に特化しているプラットフォームでは初期から常に上位にいます。

ほとんどの新規マーケットプレイスはOpenSeaを真似して作られています。

多数のNFTが購入可能

OpenSeaのマーケット規模の大きさは、NFTのジャンルの多さからも人気が伺えます。

現在は8種類に分類わけされています。

  1. Art(美術)
  2. Music(音楽)
  3. DomainNames（ドメイン名前）
  4. VirtualWords（仮想単語）
  5. TraidingCards（トレカ）
  6. Collectibles（収集品）
  7. Sports（スポーツ）
  8. Utility（効用）

NFTブームで拡大中

【NFT】OpenSea(オープンシー)とは？NFTの買い方・出品方法・手数料まで徹底解説の説明画像
※DappRadar参照

2017年よりサービスを開始したOpenSeaですが、2020年後半から2021年前半に『NFT』というワードがニュースで見かけることが増えてきました。

この『NFTブーム』により、OpenSeaは更に拡大を広げています。

2021年7月には、日本円で約110億円の資金を調達したことによりOpenSeaの企業価値が日本円で約1,600億円のユニコーン企業になりました。さらに、翌月8月のユーザー数は6万人から22万人に増加しています。

OpenSea（オープンシー）の特徴３つ

  • 複数のネットワークに対応している。
  • ガス代のみで作成できる。
  • オファーなどいろんな販売方法が可能。

複数のネットワークに対応している

OpenSeaの対応ネットワークは3つあります。

  • ETH(イーサリアム)
  • Polygon(ポリゴン)
  • Klaytn(クレイトン)

この複数のネットワークに対応しているという点もOpenSeaの魅力の一つです。

ネットワークが多いほど、ユーザーからすると利用がしやすいです。

ガス代のみでNFTが作成できる

ブロックチェーン

NFT化するにあたってOpenSeaの役割は、誰でも作成することができるプラットホームの提供になります。

自分でコントラクトを利用し作成・販売することは可能ですが、普通の方からすると難しいです。そのため、NFT販売所が必要になりその販売所であるOpenSeaでかかる費用はガス代のみです。

そのため、仮想通貨FXと比べると比較的に低コストで取り組む事が可能です。

オファーなどいろんな販売方法が可能

【NFT】OpenSea(オープンシー)とは？NFTの買い方・出品方法・手数料まで徹底解説の説明画像

OpenSeaでの販売方法は３つあります。

  • 固定価格での販売▶今すぐ購入することができる
  • オークション方式での販売▶期間内で一番高値をつけた場合購入することができる
  • オファー価格での販売▶価格交渉にて購入することができる

このように色々なバリエーションで商品の売買が可能です。

※注意点として、販売後はこの設定の変更ができない為選択時は注意が必要になります。

OpenSea（オープンシー）の使い方①買い方

NFTを買う際、事前に準備する必要があるものが2つあります。

  1. ウォレット(財布)の作成
  2. ネットワーク対応の仮想通貨

ウォレットを連結しなくても、作品を見ることは可能ですが買うことがきまっているのであれば事前にこの2つは準備しましょう。スムーズに取引を行う事が可能になります。

【NFT】OpenSea(オープンシー)とは？NFTの買い方・出品方法・手数料まで徹底解説の説明画像

対応ウォレットは上記です。今回はMetaMaskを利用し取引をおこなっていきます。

ウォレットを持っていないという方は、MetaMaskを作成することをおすすめします。

MetaMask(メタマスク)の作成方法

https://youtu.be/9lqHp2S_fLc

MetaMaskの作成方法は、上記動画がとてもわかりすく解説している為参考にしてください。

MetaMask自体が日本語にも対応しているため簡単に作成することができます。

ウォレット作成時ですが、シードフレーズという12個の単語が表示されます。これは必ず必ず必ずメモに残しておきましょう。そして、第三者に教えることがないようにメモは大切に保管しておきましょう。

仮にウォレットの復元が必要になる場合（スマホを新しくした・無くしたなど）必要なワードになります。自分の資産を守る為にも他のウォレットを作成する際もこのワードが出たら必ず必ずメモしてください。

イーサリアムをMetaMaskへ送金

ウォレットが作成できたら、MetaMaskに資金を送金します。

この資金を利用して、NFTを購入・販売していきます。ご自身の必要だと思う金額を入金してください。

【NFT】OpenSea(オープンシー)とは？NFTの買い方・出品方法・手数料まで徹底解説の説明画像

OpenSeaのイーサリアムはERC20の為送金時『ERC20』であることを確認し選択してください。

GMOコインからMetaMask(メタマスク)に送金する方法

日本の取引所であるGMOコインからMetaMaskに送金することができます。

https://3mikan.com/archives/224

GMOの作成方法は、上記記事を参考にしてください。

※MetaMaskへの送金ですが、GMOの場合『最低0.1ETH／最大150ETH』になります。

Binance(バイナンス)からMetaMask(メタマスク)に送金する方法

https://3mikan.com/archives/869

バイナンスをもっている方はこの記事を参考にMetaMaskへ送金してください。

旧Binance Globalと現在のBinance Japanでは提供条件が異なります。利用前に運営会社・登録・提供serviceの確認記事を参照してください。

※海外の取引所の口座を持っていないという方は手順が難しく感じると思うので上記GMOからの送金をおすすめします。

OpenSea（オープンシー）の登録

  1. OpenSeaの公式サイトにアクセス
  2. 画面中央にある『作成』クリック
  3. ウォレット連結画面が表示される為『MetaMask』をタップ

上記3つでOpenSea(オープンシー)の登録は完了です。

※プロフィールの設定は出品して販売をしたいという方はアイコンを設定をおこなってください。

OpenSea（オープンシー）でNFTを購入

https://3mikan.com/archives/3124#rtoc-16

NFTの実際の購入方法については、上記記事で実践しています。

『購入したい作品がある』『今後購入する予定』という方は参考にしてください。

OpenSea（オープンシー）の使い方②売り方

NFTを売る場合は買う際に必要だった2つの事に加えて自分が出品するようの画像などのデータが必要です。

  1. ウォレット(財布)の作成
  2. ネットワーク対応の仮想通貨
  3. 出品する用のデータを準備

買い同様スムーズに取引を行う為に上記３つを事前に準備しましょう。

①②に関しては、買い方と同様になるのでこのページを上にスクロールして確認してください。③のみ解説していきます。

③NFT出品する用のデータを準備

OpenSeaには「画像」や「動画」などの電子データがNFTとして出品できます。

特に画像の中でも「イラスト」や「3Dデータ」の出品が多いです。高額で有名になっているNFTも大体はイラストですね。

割とどのデータ拡張子にも対応しているので、画像で準備する場合はjpgやpngなどどれでも大丈夫です。ただし、「著作権が他人にある作品」などを出品しないようにしましょう。

NFTの場合は『価値』がついてしまう場合があるため、トラブルになる可能性があります。

OpenSea（オープンシー）の手数料・ガス代について

OpenSeaの手数料・ガス代についてまとめておきます。

手数料：2.5%（販売額の2.5%、NFTの転売をする際には別途出品者のロイヤリティ）

ガス代：利用しているチェーン次第（ETHの場合は$150ほど）

出品した後に価格は変更できる？

【NFT】OpenSea(オープンシー)とは？NFTの買い方・出品方法・手数料まで徹底解説の説明画像

出品した後に価格の変更はできます。出品しているNFTのページにて「Lower Price」をクリックすれば変更できます。

なお、「普通の販売」「オークション」といった販売方式は変更できません。

他に何か費用はかかる？

手数料・ロイヤリティとガス代以外で別途かかる費用はありません。

初めてDeFiに触る人は、ETHを準備する時点で各取引所で手数料が結構発生するので注意しましょう。（特に国内取引所を使った場合は手数料が高い）

OpenSea（オープンシー）の買い方まとめ

今回の記事では、大手NFTマーケットプレイスのOpenSea(オープンシー)について解説しました。

NFTの販売／購入を健闘されている方の参考になれば嬉しいです。

記事の工程にて、注意点をいくつかお伝えしてきましたので『ウォレットの作成』『仮想通貨の購入』『NFTの取引』には注意点を踏まえ取り組んでいただければと思います。

--- # 【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！ 今回は、AscendEXという取引所の紹介と、AscendEXで、MaticネットワークのDeFiにすぐ参加できる出金方法があるので、その紹介をしていきます。 ちなみにAscendEXは、2021年の3月にBitMaxから名前が変更されたので、ひょっとしたら知っている人もいるかもしれません。 Maticに参… 正規URL: https://3mikan.com/archives/1302 著者: みかん 公開: 2021-06-11T20:14:22.000Z 更新: 2021-10-19T15:58:48.000Z

今回は、AscendEXという取引所の紹介と、AscendEXで、MaticネットワークのDeFiにすぐ参加できる出金方法があるので、その紹介をしていきます。

ちなみにAscendEXは、2021年の3月にBitMaxから名前が変更されたので、ひょっとしたら知っている人もいるかもしれません。

Maticに参加したい方や、興味のある方は、画像付きで実際の操作方法を解説してるので、是非最後まで読んでみてください。

AscendEXとは？

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

AscendEXとは下の画像を見ても分かるとおり、ごく普通の取引所です。

ちなみに個人的な印象としては、Maticが直接送金できるならAscendEXを利用してみようかなという感じです。AscendEXで何か運用する事は考えてはいません。運用するならBinanceでいいかなと考えています。

紹介制度がある

Binanceと仕組みが似ています。手数料の数パーセントを紹介された側の人に、どれくらい還元するかを設定ができます。

下のリンクは、紹介された側に手数料が全て戻るように設定してあるので、お得にトレードしたいと思っている方は下のリンクを使ってください。

AscendEX 公式サイトはコチラから

ちなみに自分でAscendEXを検索して、そこから登録しても構いません。このリンク自体利益を出そうとは考えてはいないので、好きに利用してもらえればと思っています。

BITMAXのリブランディング

元々、BITMAXという取引所があったのですが、現在はAscendEXに名前を変えています。

ただ、LINEからアクセスできる仮想通貨取引所がまだBITMAXと記載されているので、LINE経由だけBITMAXという名前を使っているのかもしれません。

BinanceのようにStakingなどが利用できる

画像付きで簡単に説明します。

AscendEXにログイン後、「Investment Product」をタップして「Staking」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

ぱっと見、Binanceと同じような機能があります。Maticの参加を考えている方などは、すでにDeFiの知識がある方だと思うので、ここら辺の操作に関しては割愛します。

ページの雰囲気だけ見てもらえたらと思います。気になる方は、登録して見てみてください。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

BSC/Matic/Solanaに対応している

AscendEXは、BSC(BEP20) / Matic(Matic) / Solana(Solana)の直接送金に対応しています。

SolanaはBinanceでも対応しているので、個人的にはおそらくMaticをメインで使うと思います。とはいえ、今後BinanceがMaticに対応するかもしれないので、そうなった場合には利用しないかなと思っています。

Maticに参加する際の手間が省ける

今までMaticに参加する場合は、ETHからブリッジする必要がありました。

BSCからブリッジできれば安いのですが、BSCからはできず、Maticに参加するとなると手数料が高くつくデメリットがありました。ちなみにガス代だけでも$60くらいとられます。

ですがこのAscendEXを利用するとBNBだとBEP20で、BSCで入金してMaticを出金するというルートがあります。

次の項目ではこの操作を画像付きで解説していきます。

AscendEXの使い方

KYCは完了したところから解説していきます。

AscendEXの入金方法

AscendEXを開きログインしたら、右上にある「My Asset」をタップして「Total Asset」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

「Deposit」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

「Please select your token」をタップして出てきた検索窓に「BNB」を入力します。ヒットして表示されたBNBをタップします。

※自分が利用しているトークンに置き換えてください。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

「Confirm」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

「BEP20」をタップしてデポジットアドレスをコピーします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

「MetaMask」マークをタップして「送る」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

先ほどコピーしたデポジットアドレスを貼り付けて「次へ」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

「確認」をタップします。これで今、1BNBをAscendEXに送りました。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

次にAscendEXを開くと先ほど送ったBNBが反映されています。反映されていな場合は少し待ってみるか、ページをリロードしてみてください。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

続いて、左上にある「Trade」をタップしてCash Tradingの「Standard」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

次にUSDTに全額変えようと思っているので、左側にある検索窓でBNB-USDTを探して、表示されたらタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

「Market」をタップして、数量を選択し「Sell BNB」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

続いて「Matic-USDT」を検索してタップします。その後同じく「Market」をタップして数量を入力して「Buy MATIC」をタップします。

数量を見ると247 MATICと表示されています。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

そしてここからが注意点なのですが、数量MAX(247MATIC)で選択すると「Not Enough Account Balance」と表示されて拒否されます。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

どうやら数量が多いと拒否されるようなので、そういう時は数量を小さくして何回かに分けてやってみてください。これで購入が完了です。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

続いて、出金します。

右上の「MyAsset」をタップして「TotalAsset」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

AscendEXの出金方法

MATICの「Withdraw」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

「Matic Network」を選択して、自分のアカウントアドレスをコピペします。その後「Confirm」ボタンをタップします。

ちなみに手数料が2MATICなので$2くらいで済みます。ブリッジして参加する方法だと＄60くらいかかるのでかなり安くなります。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

再び「Confirm」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

続いて、登録した電話番号またはメールアドレスに、パスコードが送信されるので、どちらにパスコードをくるのか選択します。その後、送られてきたパスコーを入力してください。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

先ほどの操作が完了すると、下の画像のように表示されます。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

一応、Metamaskで確認してみるとちゃんと届いていました。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

Matic（Polygon）に参戦

続いて、実際にMatic Networkで使用できるか操作してみます。

今回は、AAVEというMatic Networkで使えるレンディングプロトコルを使います。AAVEは元々ETHにもありましたがMatic Network(polygon)にも参加してきました。

AAVEに関しては別の記事で詳しく紹介しているので気になる人はそちらも読んでみてください。

では早速操作説明に進みます。まず「MATIC」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

「接続する」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

「Browser Wallet」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

「預入」をタップして「MATIC」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

数量を入力して「入金」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

「確認」をタップします。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

このように表示が変われば操作完了です。

【CEX】AscendEXの使い方！Matic（Polygon）の直接送金・BSC（BEP20）からの入金・出金が可能な取引所！の説明画像

AscendEXの手数料

AscendEXでは、取引手数料が、ASD保有量と過去30日間の取引量に応じて階層化されています。

現物取引の手数料

レベルOKB保有量30日間取引量(USDT)MakerTaker
Lv0≧0≧00.100％0.100％
Lv1≧5,000≧100,0000.090％0.100％
Lv2≧20,000≧1,000,0000.075％0.085％
Lv3≧100,000≧5,000,0000.060％0.070％
Lv4≧250,000≧10,000,0000.050％0.060％
Lv5≧500,000≧25,000,0000.040％0.050％
Lv6≧1,000,000≧50,000,0000.030％0.040％
Lv7≧1,500,000≧100,000,0000.020％0.030％
Lv8≧2,500,000≧150,000,0000.000％0.025％
Lv9≧5,000,000≧500,000,000-0.015％0.020％

先物取引の手数料

レベルOKB保有量30日間取引量(USDT)MakerTaker
Lv0≧0≧00.0200％0.0600％
Lv1≧5,000≧5,000,0000.0150％0.0600％
Lv2≧20,000≧50,000,0000.0100％0.0500％
Lv3≧100,000≧100,000,0000.0075％0.0450％
Lv4≧250,000≧150,000,0000.0050％0.0400％
Lv5≧500,000≧300,000,0000.0025％0.0350％
Lv6≧1,000,000≧500,000,0000.0000％0.0320％
Lv7≧1,500,000≧1,000,000,0000.0000％0.0300％
Lv8≧2,500,000≧2,000,000,000-0.0050％0.0300％
Lv9≧5,000,000≧5,000,000,000-0.0150％0.0300％

AscendEXで出金できない時

「AscendEXから出金できない！」という意見をたまにいただきますので、よく引っかかっている部分をまとめておきます。

これに該当しないか確認してみてください。

  • 最低出金額（5,000円）以下で出金しようとしてる
  • KYC（本人確認）を行っていない
  • 1日の出金上限額に達している（KYCと組み合わせて制限がある）
  • その他一時的にネットワークがメンテナンス状態にある（アナウンスがあります）

AscendEXのまとめ・注意事項

MATICの参加手順について説明してきましたが、今回紹介したやり方だとMATICの入金が早く済ませることがき、ブリッジする手間も省け、ガス代も必要なくなるのでかなりお得に楽にできると思います。

最後に注意点ですが、AscendEXはBITMAXのリブランディングということなので、基本的には"新しく出てきた取引所が飛んじゃった"なんて事はないと思いますが、本格的にメインの取引所にするかどうかは、各自自分で調べた上で判断してもらえたらと思っています。

この記事自体はMaticが上がるか下がるかといったことを伝えるために書いているわけではないので、あくまでMaticのDeFiに参加したいという人がいたら、この手順だとお得に楽にできますよ。という紹介記事になります。

Maticに参加した方がいいですよ！という記事ではないので、そこだけ注意してください。

最後まで読んでいただきありがとうございました。

--- # 【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】 今回は、高騰銘柄BANANAを生み出したDEXである「ApeSwap(エイプスワップ)」について紹介します！ この記事ではApeSwapについての基本的な解説や、操作方法について解説していきます。 この記事の内容 ApeSwapの概要BANANAトークンの詳細情報ゴールデンバナナ（GNANA）の買い方・使い… 正規URL: https://3mikan.com/archives/1237 著者: みかん 公開: 2021-06-07T09:12:33.000Z 更新: 2021-10-19T09:26:29.000Z

今回は、高騰銘柄BANANAを生み出したDEXである「ApeSwap(エイプスワップ)」について紹介します！

この記事ではApeSwapについての基本的な解説や、操作方法について解説していきます。

この記事の内容
  • ApeSwapの概要
  • BANANAトークンの詳細情報
  • ゴールデンバナナ（GNANA）の買い方・使い方
  • IAOの概要
  • NFAの概要

これらの内容を紹介していくので、利用したことがない方や興味がある方は是非読んでみてください。

ApeSwap（エイプスワップ）とは？

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

簡単にどんなものかと言うと、PancakeSwapのようなイールドファーミング兼DEXになります。

「ApeSwap Info」というページでは、全てのLiquidity(市場流動性)や概要などが確認できます。ちなみに、PancakeSwap Infoと似ているので普段からチェックしている人は見やすいかと思います。

また、ApeSwap InfoはPancakeSwapに比べると、毎度しっかり情報が更新されるので、安心感があります。

https://3mikan.com/archives/240

ApeSwapの機能

ApeSwapの機能やできることは以下の５つです。

ApeSwapでできること
  1. DEX機能（スワップ、ファーミング）
  2. Vaults機能（自動複利）
  3. IAO（IDO）
  4. NFA（NFT）マーケット
  5. ゴールデンバナナ（GNANA）への変換

現在の対応ネットワーク（チェーン）

現在の対応ネットワークは2つです。

対応ネットワーク
  • BSC（バイナンススマートチェーン）
  • Polygon（ポリゴン）

ApeSwap（エイプスワップ）の独自トークンはBANANA

screen-2021-10-19-17.18.11

もともとはずっと$1で停滞しておりましたが、有名インフルエンサーなどが紹介したのをきっかけにいきなり高騰しました。（日本人は知ってる方おおいはず）

私自身＄1くらいで持っていて、＄7まで上がったときにある程度売りました。現在は$2程度に戻ってきています。

BANANAのトークノミクス（Token Economics）

BANANAのトークン詳細情報に関してです。

発行上限数（Hard Cap）

BANANAの発行上限数（hard cap）はありません。

開発側は「hardcapが無いことが投資する上での懸念点なのは分かるが、流動性提供のインセンティブを考慮して設定する予定はない」としています。

排出量（Emission）

排出量はファームなどの報酬で新規発行される数を指しています。

ブロックあたりのBANANA排出量1日あたりのBANANA排出量
11 (10はファーミング、1は開発者へ）316,800

配布の割合

配布先ブロックあたりの報酬率ブロックあたりの報酬数1日あたりの報酬
Farms75%7.5216,000
Pools25%2.564,000

基本的に排出量や配布は普段は気にならないと思います。というのも、実際にはプールを利用しているすべてのユーザーとのシェア率によるからです。

詳しい補足はイールドファーミングの基礎知識の記事で紹介しています。ファームに関する理解がかなり深まります。

https://3mikan.com/archives/1593

デフレーションメカニズム

トークン価格を維持する上でデフレ（トークンを減らす）機構は重要です。

  • スワップ手数料の100%がBANANAの買い戻し→バーンに使われる
  • IAOに利用されたすべてのBANANAはバーンされる

ApeSwap（エイプスワップ）各機能の簡単な紹介

ApeSwapのメニューにある各機能に関して紹介していきます。

ApeSwapの機能
  1. Trade（スワップ・LP作成解体）
  2. Farms / Pools（ファーム・プール）
  3. Vaults（自動複利機能）
  4. IAO（IDO機能）
  5. NFA（NFTマーケット機能）
  6. GNANA（ゴールデンバナナ）

①Trade（スワップ・LP作成解体）

screen-2021-10-19-17.48.09

メニューのTradeからExchange（スワップ）・Liquidity（LP作成/解体）ページに飛ぶことができます。

screen-2021-10-19-17.48.58

ここでは他のDEX同様スワップやLPの作成解体ができます。

最近はApeSwap関連がこの黒い画面のUIで新しい機能を追加してくることが多いです。（開発者が変わったんですかね...）

②Farms / Pools（ファーム・プール）

screen-2021-10-19-17.51.55

他のDEX同様FarmやPoolがあります。

ApeSwapは、古参のイールドファーミングなので割と初期段階からあるFarmです。

そのため、トップページの右下に表示されている通り、TVL(預かり資産)は約5億ドル($522,616,374)集まっていることが分かります

③Vaults（自動複利）

screen-2021-10-19-17.54.31

自動複利の機能であるVaultsも最近追加されました。UIはまた黒い画面です。

screen-2021-10-19-17.54.21

もともとはApeRocketというApeSwapの子プロジェクト的なところでVaultsを作っていたのですが、いつの間にかApeSwap内にできていました。

利用方法は他のBeefyなどのVaultsと同じです。

https://3mikan.com/archives/407

④IAO（IDO機能）

IAOは簡単にいうと無料でトークンがもらえる仕組みのことを言います。

ApeSwapのIAOのページを見てみると、BANANAとBNBのペアを組んでおくと新しいトークンのセールに参加できると書いてあります。

具体的には、BANANA-BNBで組んでいた数量で割り当てが決まり、その分の購入ができるという仕組みです。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

ちなみに、ここでIAOをしたものはPoolに入ってくるので、仕組みとしてはスムーズにできているんじゃないかと感じます。

⑤NFA（Non Fungible Apes）（NFTマーケット機能）

仕組みや内容はNFT(非代替性トークン)とほぼ同じです。「Check out the NFA aftermarket at NFTKEY!」をタップすると実際に購入ができます。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

そもそもNFTや、このNFAがビットコインやイーサリアムなどのコインとどう違うのかということを説明します。

例えば、現実世界で自分が百円玉を持っていたとして他の誰かと百円玉を交換しても特に困ることはありません。百円は百円です。

したがって百円玉は代替が可能な性質を持つと言えます。ビットコインやイーサリアムなどの仮想通貨も基本的には同じで代替可能な性質を持っています。

一方で、NFTやNFAが扱うものは代替不可能なものです。例えば、絵画を購入したとして、他の絵とランダムに交換されるようなことがあっては困ります。

この他にも座席指定付きのコンサートチケットや、ゲーム内で育成したキャラクターなどは非代替性のものです。

現在、NFTやNFAに紐付けられたアートや音楽は、数十億を超える金額で取引が成立していて、まさにバブルのような状態となっています。

そしてApeSwapのNFAは、謎のお猿さんが購入できるということなのですが、現在ApeSwapのNFAは具体的な使い方がありません。

ただ、NFTやNFAが注目されているので、今後ApeSwapにおいてNFAがないと特定の操作ができないといったことが増えてくるかもしれません。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

⑥GNANA（ゴールデンバナナ）

screen-2021-10-19-18.00.22

元々はApeZoneという名称でした。BANANAをゴールデンバナナ（GNANA）に変換したり戻したりできます。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

ここでは、独自トークンであるBANANAを使ってGNANAにミントする(購入する)ことができます。

購入したGNANAは、BANANAに戻すこともできます。ただ、レートが悪いのでGNANAからBANANAに戻すと元の数より減ります。

じゃあGNANAの何が良いのかというと、ApeSwapではGNANAを保有しているとIAOの追加割当や追加ファームが利用できるようになります。

GNANAのメリット

  1. IAOの追加割当
  2. 追加ファーム

GNANAのデメリット

  1. 1BANANA → 0.7GNANAと減少する
  2. 0.7GNANA → 0.7GNANAにしか戻せない
screen-2021-10-19-18.03.32
screen-2021-10-19-18.04.06

このGNANAはBANANAトークンのバーンの資金として一部が使われています。

burnとは簡単にいうと、BANANA価値を維持するために定期的にBANANA自体の数を減らすシステムのことです。BANANAの仕組みのメカニズムの一部といった感じです。

廃止された機能：Lottery

これは他のプロジェクトでも見かけることがありますが「宝くじ」になります。

２BANANAで１〜14の数字の中からランダムに組み合わせた数字４つのチケットを１枚を購入することができます。

宝くじと仕組みは同じで、参加者が購入する際に使用したBANANAを分配するシステムとなっており、集まったBANANAの一部はburn、一部は次回への持ち越しとなります。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

ApeSwap（エイプスワップ）ファーム操作方法・GNANA買い方

ApeSwapのファーム操作方法とGNANAの買い方を紹介していきます。

特にGNANAはApeSwapの特徴的な機能で、他のDEXには無いので慣れていない方も多いでしょう。

ファーム操作方法

今回はBANANA-BNBのLPを組んで預け入れたいと思います。

まずはBANANAを購入するので、トップページの左側にある「Trade」をタップし「Exchange」をタップします。すると下の画像のように表示されます。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

続いて、通貨と数量を選択します。選択し終わったら「Swap」ボタンをタップします。今回はBNBでBANANAを購入します。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「Confirm Swap」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

右側に表示された画面の「確認」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

次にLPを組んでいきます。上にある「Liquidity」にタブを合わせ、「Add Liquidity」のボタンをタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「数量」と「通貨」を選択し、「Supply」ボタンをタップします。

今回はBNBとBANANAをLPを組むので、BNBとBANANAを選択し、数量MAXで組みます。ちなみに反映に数秒〜数十秒かかるので、「Supply」ボタンが表示されるまでに少し時間がかかります。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「Confirm Supply」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「確認」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

反映まで数秒かかりますが、LPが組めるとページ上部に表示が出ます。この表示が出たらOKです。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

続いてFarmしていきます。

まずは左側にある「Farm」をタップします。次にBNB-BANANA LPの「Approve Contract」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「確認」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

数秒すると反映されるので「Stake LP」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

数量を入力して「Confirm」をタップします。今回はMax預けます。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「確認」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

このような表示になったら操作完了です。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

預け入れているとBANANAが増えていくので、自分のタイミングで「Harvest(収穫)」してください。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

引き出したい時は、「ー」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

いくら引き出すのか数量を入力して「Confirm」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「確認」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「BANANA-BNB LP」の表示が変わっていればUnstake(引き出し)完了です。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

LPの解体をする場合は、左側にある「Trade」をタップし「Liquidity」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「BANANA-BNB」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「Remove」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

どれくらい解体するのか選択して「Remove」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「Confirm」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「確認」をタップします。これでLP解体操作の完了です。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

GNANA操作方法

まずはBANANAをミントする必要があるのでその操作から解説します。

ページ右側にある「ApeZone」をタップして、数量を入力し、「Approve Contract」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「確認」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「Buy」をタップします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

「確認」をタップします。これでGolden Bananaの購入が完了しました。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

反映されると、このように表示が変わります。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

このGolden Bananaを保有することで、いくつかのPoolなどが特別に利用できたりします。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

注意点ですが、Poolした後にUnstakeして、GNANAからBANANAに変える場合は、GNANAが「１」以上ないと変えることができないので注意してください。

画像を見て気づいた方もいるかと思いますが、割りがあまり良くないので、GNANAを使ってPoolした後、すぐにUnstakeしてBANANAに変えるのはお勧めしません。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像
【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

ApeSwap（エイプスワップ）のロードマップ確認

ApeSwapのロードマップを翻訳しながら見ていきたいと思います。

【DeFi】ApeSwap（エイプスワップ）とは？始め方・ゴールデンバナナ（GNANA）・IAO参加方法など徹底解説【仮想通貨】の説明画像

April 2021 : (4月)

・高度なバーニングメカニック(マシン)の導入
・ユーザーインターフェースのリヴァンプ
・NFAページの強調(推進)

May 2021 : (5月)

・新しいファームの追加
・NFAを使ってイニシャルプラットフォームに参加できる

June 2021 : (6月)

・ガバナンスメカニズムの統合

September 2021 : (9月)

・オートコンパウンディングとボルツ(ボルトを自社で自作する)
今、AutoFarmやbeefyなどでやっているボルツを自社で始めるようです。
おそらくですが他のトークンもボルツ利用できるんじゃないかと思っています。

ApeSwap（エイプスワップ）まとめ

ポテンシャル的にはPancakeSwapを同じくらいのポテンシャルを持っていると思っています。

それが評価されてBANANAの価値も上がり、TVLもどんどん上がっていると感じます。

購入を考えている人は、情報収集した上で購入してください。

最後まで読んでいただきありがとうございました。

--- # 【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなど 今回はDeFiのイールドファーミングの基礎知識について解説していきます。 1年ほど前からよく聞くようになった「イールドファーミング」ですが、DeFiのサービス内容などから注目が高まっています。 興味のある人や、改めて機能やサービス内容について確認したい人はぜひ読んでいただけたらと思います。 https://… 正規URL: https://3mikan.com/archives/1593 著者: みかん 公開: 2021-07-02T21:53:50.000Z 更新: 2021-10-19T04:19:55.000Z

今回はDeFiのイールドファーミングの基礎知識について解説していきます。

1年ほど前からよく聞くようになった「イールドファーミング」ですが、DeFiのサービス内容などから注目が高まっています。

興味のある人や、改めて機能やサービス内容について確認したい人はぜひ読んでいただけたらと思います。

https://youtu.be/OElbJ7EbeRA

1.この記事のメリット・目的

目の前の数字に踊らされずに判断する

私がDeFiに参加する上で重要だと思っていることは、目の前の数字にやチャートに踊らされずに知識知識をつけて参加することが大切だということです。

なぜかというと、APRがいくら高くてもトークン価格が下がってしまうと損失になってしまったり、チャートが上がっているように見えてもパンプ（いろんな人の企みによって上がっているだけ）の場合もあります。

DeFiは良くも悪くも無法地帯なので、ファームの質もピンキリです。なのでまずはちゃんとした知識をつけることが大切です。

そして知識をつけるためにも、普段をファームを見ていて「なんでこのファームはこのプールだけAPRが高いんだろう？」といったことを気にして運用するだけでも、かなり慎重に判断できる知識がついてくると思います。

基本的な知識が必要

基本的なDeFiの知識をつけていないと、ちんぷんかんな考えのもと動いてしまうことが多いので、まずは基本的な知識からつけることが大切です。

また、もしかしたら今後はDeFiのサービスを日本人も作りやすくなるかもしれないので、これを見ている方の中にも、誰かが運営側に回る可能性もあります。

どんなサービスを作るにしろ、全く知識がない状態から始めるのと、少し知識がある状態から始めるのでは難易度が違うので、このタイミングでしっかり知識をつけておくことが後々自分を助けるんじゃないかなと思います。

2.イールドファーミング・DEX(AMM)とは？

【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなどの説明画像

まず、DEXというのは「トークンを交換できる取引所」のことをいます。DEXは、自動で取引する相手を見つけてくれるのですが、自動でマッチングする取引所を作るためにもトークンの流動性がすぐに交換できる状態を作る必要があります。

DEXの開発側としては、元手の資金を出さずに取引所を作って運営したいので、この流動性はユーザーに提供してもらいたいという思いがあります。こういった開発者側の考えのもと、DEXではユーザーが流動性を提供する仕組みになっています。

そして今回紹介するイールドファーミングは、流動性を提供してくれたユーザーに対しては報酬を渡すという仕組みになっています。

ちなみに「DEXの基礎知識」の記事やYoutube動画で全部紹介しているので、興味がある人は、そちらを一旦見ていただくと良いかもしれません。

参考：DeFi基礎知識動画

3.マルチプライヤーとは

DEXではいろんなユーザーが流動性を提供してくれている訳ですが、開発者によっては考えがそれぞれあり、集めたいトークンと、別にあってもなくても良いトークンの差をつけたいという発想があります。

だから流動性ペアに優先順位をつけるのですが、この流動性に順位をつけるものがマルチプライヤーになります。

例えば、開発者からするとたくさんの人に自分が作ったものを利用して欲しいので、独自トークンとのペアは優先順位が高くなります。独自トークンとは自分たちで発行しているトークンのことです。具体例として、PancakaSwapだとCAKE、BinanceだとBNB、などです。

そして、この独自トークンとのペアを高い優先順位にして、反対にUSDT、BUSD、USDCなどのステーブルコインを低い順位にして、他のトークンとの差をつけます。

ちなみに、このマルチプライヤー関連の話では「重み/Weight」という概念を使います。この用語は良く使われているので、知っておいたほうが良いと思います。

【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなどの説明画像

マルチプライヤーがイマイチ分からないという方は、ファームの横に書いてある数字をチェックしてみてください。例えば上の画像だと「Multiplier 40x」「Multiplier 8x」「Multiplier 2x」など色々表示されています。

この数字は開発者側が設定する数字です。なので、開発者側が集めたいトークンが高くなって、どうでも良いものが低くなるという仕組みになっています。独自トークンとのペアだったら勝手に高くなるというわけではありません。

ファーム報酬の計算

【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなどの説明画像

計算方法は上の図の通り、①②③を掛け合わせた数字がファーム報酬になります。

画像の左側に「報酬blockごとのearned」と書きましたが、blockという概念がざっくり言うとブロックチェーンという感じなので、わかりにくい方は「トランザクションごと」みたいな感じに思ってください。

①ブロック報酬

①ブロック報酬では「１ブロックごとのトークン排出量」と書いています。これは開発者が一方的に決めます。

PancakeSwapがわかりやすいので例に挙げながら解説していきます。まずトークンのロードマップやドキュメントを見ていくと下の画像のような表示を確認することができます。

【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなどの説明画像

この図はCAKEトークンについて書かれています。まず左上に太字で「Block Emissions」とありますが、これは１ブロックごとの報酬のことを言います。そのすぐ下の水色枠には「Minted 40 CAKE」と書かれているので、意味としては「1ブロックごとに40CAKE排出します」ということになります。

そしてさらにここから、Burn用に20CAKE、Farm&Lottery(宝くじ)用に10CAKE、Pool(Syrup pool)用に10CAKE振り分けられます。こういったことをCAKEは定められており、しっかりロードマップにして発表してくれています。

ちなみに、排出量は英語表記だと「Emissions」と記載されることが多いです。なのでEmissionsというワードが出てきたら、おそらく排出量のことなんだろうな。と考えると良いと思います。

そして、Emissionsの数字が多ければ多いほどトークンをたくさんもらえる可能性が高いです。ただ、トークンが多いからといって利益が多くなるわけではありません。なぜかというと、トークンが多いということは排出量も多く、トークンの価値が低くなりやすい傾向にあるからです。

実際に、仮想通貨やDeFiを長くやっている方はすぐわかると思いますが、この点だけ注意してください。

②プール(ファーム)割当

先ほどの計算式が書いてある画像では、「②プール(ファーム)割当「重みの割合計算」」と書いています。下のPancakeSwapのプールのページ画像を見るとたくさんプール先がありますが、例えば、一番上のCAKE-BNBの占める割合はどれくらいか？みたいなことを計算します。

【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなどの説明画像

簡単に言えば「プールの重み」を「すべてのプールの重み」で割るといった仕組みになっています。

例えば、プールが下の画像の３つしかなかったとします。その場合マルチプライヤーが「40x,8x,2x」しかないので、全体の重みの合計は「50x」となります。

そして、CAKE-BNBは「40x」なので「50xのうちの40x」となり、割合で言うと80%になります。そしてBUSD-BNBは16%、XEND-BNBは4%となります。

なので、合計のEmissions(排出量)があったとして、そのうちの80%が1番上のCAKE-BNBに、16%がBUSD-BNBに、4%がXEND-BNBに割り当てられていきます。

【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなどの説明画像

そしてEmissionsが40だとすると報酬割当は32、6.4、1.6となります。Emissionsが10だとすると報酬割当は8、1.6、0.4となります。このような流れでプールの割当が決まっていきます。

③プール内のシェア割り当て

【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなどの説明画像

③プール内のシェア割り当てでは、「自分のシェア計算」と書いています。

例えば自分がいま、上の画像にあるCAKE-BNBに入れているとします。その場合、合計(Liquidity)で$873,000,998の資産が集まっていることがわかりますが、この合計の資産の中で、自分が持っている割合はどれくらいか？を計算した数字が③になります。

わかりやすく言うなら「自分の貢献度を計算する」といった感じです。

例えば、Liquidityが＄10,000で、自分が預けた分が＄100だったとします。この場合プール内での自分のシェア率(貢献度)は１％になります。そして、プール割当の１％がもらえることになります。

仮に１ブロックごとのプール割当が32だとすると0.32もらえることになるので、毎ブロックごとに0.32が入ってくるということになります。

ここで気付いた方もいるかもしれませんが、他の人が預ければ預けるほど、自分の割り当ては減っていきます。例えば自分が＄100を預けて放置してる間に、他のユーザーが参加してきて$20,000になったとします。するとシェアは0.5になるので自分の割り当てが減ることになります。

4.ファームのAPRの意味

イールドファーミングに参加するとき、ほとんどの人がAPR(年利)を見て参加するかなと思います。

このAPR(年利)に関してですが、APRの計算はとてもシンプルで下の図にも書きましたが、直近ブロックでのLiquidityに対する報酬(ドル換算)となります。物によっては、通信の関係で直近ブロックではなく数個前のブロックをとっているファームも多いです。

勘違いしやすいので注意ですが、この下の図の計算式で出るのは１ブロックごとの報酬です。これを1年で計算したときの数字がAPRとなります。

【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなどの説明画像

APRの計算式は下の図の通りです。

【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなどの説明画像

この計算式をさらに詳しく解説すると、

下の図の赤枠の部分を計算して出た数字が「１ブロックごとのプールの報酬」になります。

【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなどの説明画像

例えば、CAKE-BNBに当てはめて上の赤枠の部分を計算してみると、１ブロックごとの報酬のドル換算ができます。この記事を書いている時点ではCAKEが＄19（約$20)くらいなので、仮に１ブロックごとに5CAKE配られているとしたら約＄100放出さることが計算できます。

【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなどの説明画像

それに対して、現在のCAKE-BNBのLiquidityをドル換算すると８億7000万ドルなので、８億7000万ドルに対して１ブロックで＄100出てくるとしたら比率が計算できます。(８億7000万ドルに対して何％か？という数字)

ここで出てきた数字に対して１年間分かけるとAPRとなります。

ファームのAPRのTIPS

【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなどの説明画像

続いて、APRに関しての詳しい情報・心付けについて話していきます。

  • Liquidityが増えると母数が増えるのでAPRは下がります。
  • ブロック報酬が増えるとAPRは上がります。
  • トークン価格が上がるとAPRが上がります。(Liquidityも上がった場合は変わらない)

３つ目の「トークン価格が上がるとAPRが上がります」についてもう少し詳しく説明すると、先ほど、CAKEの価格が現在約＄20で、CAKE-BNBで仮の場合で５CAKEが配られると言いました。

【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなどの説明画像

もしCAKEの価格が＄40になった場合、８億7000万ドルに対して$100〜＄200になるのでAPRは倍になります。ですが、Liquidityも流動性なのでLPの中にトークンがあります。どういうことかというと、例えば、CAKE-BNBというトークンが実際には中にあって、それをドル換算されたものがLiquidityと表現されています。

なのでCAKEが上がるということはLiquidityのドル換算も増えることになります。

逆にBUSD-BNBのようなCAKEではないプールの場合は、BUSDとBNBのドル換算がLiquidityになっていて、もらえるのはCAKEトークンなので、CAKEトークンの価格が変わらずにBNBが上がっていった場合にはLiquidityだけが増えていきます。すると、Liquidityだけが増えていくのでAPRは下がります。

難しく感じた方もいると思いますが、上の計算式だけでも覚えると今後何かあったときに役に立つと思います。

5.APY/APR/Daily(Monthly)の意味

APRは年換算利回り、APYは年間利回り、Dailyは日換算利回りのことを言います。

基本的にはAPRよりもAPYの方が高いです。なぜかというとAPRは何もしないで放置した場合に「今の利率のまま１年間放置したとしたら何％になる？」という計算方式になります。

それに対してAPYは「今の利率のまま複利してガチで運用したら何％になる？」という計算法式になります。特にdaily-compound(1日１回複利)をもとに計算されていることが多いです。当たり前ですが、複利した方が利率が良くなるのでAPYの方が高くなりやすいです。

続いて、Dailyについてですが、DailyはAPRを365や360で割ることが多いです。これで1日あたりの利回りが出ます。同じように12で割ればMonthlyも出せます。

このカラクリがわかっていれば下の図のような、イールドファーミングでの「APR、Daily(1d)、APY(365d)」の仕組みがわかると思います。

【DeFi】イールドファーミングの基礎知識！DEX（AMM）・ファーム報酬・マルチプライヤー・APRなどなどの説明画像

ちなみに、左のAPRは純粋な年利で、このAPRを365で割ったものがDaily(1d)となります。そしてこれをdaily-compoundしていくとAPY(1d)となる。ということになります。

ここら辺を覚えておくと、用語を間違えることもなく、勘違いすることもなくなるかと思います。

6.まとめ

ここまでの内容で難しいところがあったと思うので、イールドファーミングを利用するにあたって覚えておいた方が良い基本的な知識を簡単にまとめます。

①まず、DEXは取引所ですが、流動性がないと取引ができないので、それならイールドファーミングという形式をとればいいんじゃない？ということでイールドファーミングになりました。

②流動性の優先順位は、開発者側がどういう流動性を欲しがっているかで決まるので、開発者側が欲しいものが順位が上がります。そのために「重み」という概念を使ってマルチプライヤーという表記になっています。

③Emissionsは１ブロックごとの排出量(報酬)の意味です。

④プールごとにごとに割当が計算出来ます。

⑤プール内でのシェアでもらえる量が変わります。

⑥APRはLiquidityに対する割合です。

今回の記事では、計算式が出てきたりしたので、もしわかりにくかった方は何度か読み返してもらえたらと思います。また、この記事と同じ内容のYoutube動画もアップしているので、動画の方が理解しやすいという方は、動画をチェックしてもらえたらと思います。

3MIKAN：イールドファーミングの基礎知識

また、読むだけよりも実際にファームを見ながらやると理解しやすいと思います。長くなりましたが、最後まで読んでいただきありがとうございました！！

--- # 【DeFi】DEX（AMM）の基礎知識・用語解説！CEX/DEXの分類・トークン価格・流動性シェア・インパーマネントロスなど 今回はDEX(分散型取引所)について解説していきます。DEXについて調べるといろんな専門用語が出てきて、わかりづらいと感じる人もいると思うので、DEXについての基礎知識や専門用語、そのほかインパーマネントロスについても解説していきます。 DEXについて理解することで LPを作ることが理解できるDEXの独自ト… 正規URL: https://3mikan.com/archives/2126 著者: みかん 公開: 2021-08-18T01:55:38.000Z 更新: 2021-10-19T04:18:03.000Z

今回はDEX(分散型取引所)について解説していきます。DEXについて調べるといろんな専門用語が出てきて、わかりづらいと感じる人もいると思うので、DEXについての基礎知識や専門用語、そのほかインパーマネントロスについても解説していきます。

DEXについて理解することで

  • LPを作ることが理解できる
  • DEXの独自トークンを持つメリットを理解できる
  • イールドファーミングの仕組みを理解できる
  • DeFiが何故すごいと言われているのか理解できる

など、この先仮想通貨を運用していく上でのメリットがたくさんあるのでぜひ最後まで読んでいただけたらと思います。

DEX(分散型取引所)とは？

DEXとはDecentralized Exchangeの略で、分散型取引所のことを言います。分散型取引所とは取引の管理を中心に入って行う運営会社がなく、ユーザー同士が繋がり取引が行われている取引所のことを言います。

ユーザー同士が直接仮想通貨を取引できるので、取引するまでの時間や金銭的なコストを抑えられることができます。中央に母体となる管理会社がいないことで、人件費やその他経費、手数料が安く抑えることができ、CEX(中央集権取引所)より利用しやすい特徴があります。

そしてDEX以外にも、取引所の種類はいくつかあり、「CEX」「DEX」「板方式(オーダーブック方式)」「AMM」に分類されます。それぞれの取引所の位置付けは下の図のようになります。

【DeFi】DEX（AMM）の基礎知識・用語解説！CEX/DEXの分類・トークン価格・流動性シェア・インパーマネントロスなどの説明画像

まず取引所の種類を大きく分けると「CEX」と「DEX」の2種類があります。

そしてさらにDEXは「板方式」と「AMM」の2種類に分かれます。

CEXとDEXの違い

CEXとはCentralized Exchangeの略で、中央集権取引所のことを言います。CEXではユーザーが取引に使う暗号通貨を母体となる会社が間に入って管理しています。日本の取引所やBinanceがCEXに該当します。

一方でDEXは先ほども言ったように分散型取引所のことを言い、間に入って取引を管理する会社がなくユーザー同士が繋がって取引が行われる取引所のことを言います。PancakeSwapなどがDEXに該当します。

その他CEXとDEXの違いについてわかりやすく表にまとめたので参考にしてみてください。

ーCEXDEX
カストディ(資産管理など)秘密鍵は取引所が管理する秘密鍵はユーザー自身が管理する
取引手数料元から手数料が決められている(取引高の１％など)市場環境により変化する
アカウント取引するには個人情報の提出が必要ウォレットを繋げばすぐに取引できる
コンプライアンス規制当局に登録が義務付けられているインターネットサービスという位置づけなので、現状ほとんどのDEXは法律的な立ち位置が曖昧

表からもわかるように「DEXは良くも悪くも自分次第」のようなところがり、万が一、ハッキングなどでトラブルがあった場合に、自分の元に流出した資金が戻ってくる保証はありません。

仮想通貨投資が全くの初めてという方は、いきなりDEXを利用するより、日本国内の仮想通貨取引所やCEXを利用して投資に慣れておくのも一つの方法です。

CEXとDEXの役割

CEXとDEXは、別々の形で今も進化しています。

CEXは、金融庁などの規制のもとに動いているので、利用者にとって安全で安心して使えるサービスを提供しなければいけません。なので「コンプライアンス(法令遵守)」「しっかりとしたセキュリティ体制の構築」「保証・保険制度」など、利用者が安心して使えるサービスやサポート体制を求められます。

一方でDEXは、KYC(本人確認)なしで利用することができる便利さや、ステーキングなどで得られる高いAPY(利息)の提供などが魅力的です。他にも、新しいサービスが次々と展開されていることや、CEXではまだ扱われていない新しいコインの取引ができるので、自由度が高いです。

このように、両者ともにメリットデメリットがそれぞれあるので、これを踏まえた上で自分に合った形で利用するといいかと思います。

DEXはCEXの敵？

現在DEXは急成長しており、これにより「CEXはDEXを毛嫌いしているんじゃないの？」と考える方もいると思います。

ですがそういったことはなく、今の日本ではCEXで法定通貨(円やドル)を暗号資産に交換して、交換したコインはDEXで運用するといった使い方が多いので、DEXで次々に生まれる新しいサービスへのアクセスがしやすいようにCEX側がサービスを改良し、利用者を増やしていこうという動きがあります。

なので、DEXを利用する人が増えていくことで、CEXはこれからも安心安全を前提にサービスを提供しつつ、DEXがより使いやすくなるようなルートを作っていくことができ、これによりCEXとDEXは役割がかぶることなくお互いにより多くの人に仮想通貨サービスを提供していくことができます。

CEXとDEXの未来

CEXとDEXは、どちらが良い・悪いという話ではなく、これからもお互いのメリットデメリットを補い合う形で進化していくと思います。

CEXは、DEXに比べると安心安全なので、これからも仮想通貨全体の認知や理解の普及が求められると思います。これに加えて金融庁などの規制当局との連携や、これから仮想通貨業界に参入してくる企業や非営利団体などと、どう事業展開していくかなのど課題があります。

一方DEXは、次々と新しいサービスが日々生まれているので、これからもさらに仮想通貨サービスの発展が求められていくと思います。今後の発展によって将来は、銀行口座ではなく暗号資産ウォレットを作るような時代が来るかもしれません。

DEX詳細：板方式とAMMの違い

【DeFi】DEX（AMM）の基礎知識・用語解説！CEX/DEXの分類・トークン価格・流動性シェア・インパーマネントロスなどの説明画像

続いて、板方式とAMMの違いについて解説します。板方式とAMMはどちらも「DEX」に分類されるので、どちらもユーザー同士が直接取引を行うのですが、特徴が少し違います。

「板方式」とは、市場に買い板と売り板がありマッチングした人だけが取引できるようになっている仕組みのことを言います。ただ、板が薄かったりするとマッチングできないケースがあります。ちなみに「板方式」「オーダーブック方式」「マッチング方式」という人もいます。

「AMM」とは「Automated market maker」の略で、自動マーケットメーカーとも言われ、自動でマッチングが行われながら市場が作られていきます。AMMでは「板方式の時のマッチングできない問題」が解消されています。

またAMMは2020年夏頃から注目され、DEX全体の取引高の90％を占めているといわれ、利用者数が急速に増えてきています。なので今回は、板方式についてはまたの機会に解説するとして、AMMについてより詳しく解説していきます。

AMMについて詳しく解説

AMM（Automated market maker、自動マーケットメーカー）についての解説をしていきます。

基本的にDeFiで有名になっているDEXのほとんどがこのAMM形式を採用しています。

AMMの仕組み

「中心で取引を管理する会社がないのに、どうやってAMM(DEX)は成り立っているのか？」疑問に思った人もいると思います。AMM(DEX)の仕組みを理解すると、AMM(DEX)のすごさや人気になる理由が理解できます。

例えば私がAMM(DEX)を作りたかったとします。

手持ちは1BTCと60000USDTです。ですがこれだけでは取引所を作ることができません。

【DeFi】DEX（AMM）の基礎知識・用語解説！CEX/DEXの分類・トークン価格・流動性シェア・インパーマネントロスなどの説明画像

仮に、手持ちの1BTCと60000USDT (約1BTC分)で取引所を作ったとしても、ユーザーから「2BTCをUSDTにしたいです！」といわれて、2BTCを交換してしまうと自分のUSDTがなくなってしまいます。

対応するUSDTが不足することになれば「交換する資金がないので、すみません・・。」と断らざるを得なくなってしまいます。結果、全然トレードができない取引所になってしまいます。

【DeFi】DEX（AMM）の基礎知識・用語解説！CEX/DEXの分類・トークン価格・流動性シェア・インパーマネントロスなどの説明画像

取引ができない取引所では当然利用者は増えません。そうならないために開発者は「他のユーザーに交換できるプールを作ってもらおう！代わりに、手数料の一部を還元してあげよう！」という仕組みを作りました。

この仕組みで成り立っている取引所をAMM(DEX)と言います。分かりやすくその仕組みを図にまとめたので、図を元に解説していきます。↓

【DeFi】DEX（AMM）の基礎知識・用語解説！CEX/DEXの分類・トークン価格・流動性シェア・インパーマネントロスなどの説明画像

まず、ユーザから「流動性」というものを提供してもらいます。(BTCとETHのペアや、BTCとUSDTのペアなど)

そして、例えば左下の流動性提供者から「100BTC : 6,000,000USDT(約200BTC分)」を預ったとしたら、先ほどの「2BTCをUSDTに交換したいです！」と言ってきたユーザー(スーツの男性)はすぐにトレードができるようになります。

なので、開発者は全く資金がなくても他の人が提供してくれるので、自動で市場が出来上がり取引所が活発に回るようになります。

板方式のようにマッチングできないケースはなく、AMMではマッチング相手がいなくても流動性プールの中から自動でトレードができるようになっています。

こう言った仕組みからも言えるように、AMMは開発者の元手資金がなくても成り立つことや、流動性を提供してくれたユーザーには一部が還元されること、さらに、トレードした際の手数料は開発者に入るので、取引所の運営資金として回せることができます。

こんな感じでAMM(DEX)はうまい具合に経済圏が回っています。

AMM(DEX)の可能性

AMM(DEX)はDeFi(ディーファイ)の一種です。DeFiとは分散型金融といい中央集権的な会社(仲介者)がいなくても、ユーザー同士が直接取引できる金融サービスのことを言います。

これまで金融取引といえば、お金を預けるにしろ借りるにしろ、銀行・保険会社・証券会社・CEXなどを間に挟み、仲介料や手数料を払って取引がされていました。

ですがこのDeFiサービスの登場で少なくとも仮想通貨は仲介者なしで金融取引が可能になりました。

そのため今後さらにDeFiが浸透していけば、ありとあらゆる金融サービス・金融取引が大きく変わるのではないかと期待されています。

AMM(DEX)はどんな人におすすめ？

DeFiは急激に人気が出ているので、現在たくさんのサービスが乱立しています。ブロックチェーンそのものの安全性は高いと言えますが、CEXに比べたらまだ脆弱です。

また、質の良いサービス・悪いサービスを見極める責任はユーザーにあります。

普段から、運営がやっているTelegramに参加したり、SNSで情報収集するなど、リスクを理解した上で利用することが大事です。

DEX（AMM）とイールドファーミングの関係性

AMMはイールドファーミングとの関係性が非常に強いので、イールドファーミングにも詳しくなっておきましょう！

※イールドファーミングとは自分が持っている仮想通貨をAMM(DEX)に預ける代わりに利息や手数料を受け取ることができる新しいサービスのことを言います。

大前提としてAMM(DEX)というのは流動性がないと取引ができない状態になります。

【DeFi】DEX（AMM）の基礎知識・用語解説！CEX/DEXの分類・トークン価格・流動性シェア・インパーマネントロスなどの説明画像

なので開発者としては「トレードをしてくれるユーザーよりも、まずは流動性を提供してくれるユーザーを増やしたい」と考えます。

そこで開発者は「流動性を提供してくれて、なおかつそれを資金ロックしてくれたユーザーには、独自トークンを渡します」という＋αの報酬がもらえる仕組みを作ります。これをイールドファーミングといいます。

これにより流動性を作ることが可能になり、トレードしたいユーザーも利用できるようになります。

【DeFi】DEX（AMM）の基礎知識・用語解説！CEX/DEXの分類・トークン価格・流動性シェア・インパーマネントロスなどの説明画像

分かりやすく例を挙げると、AMMである「PancakeSwap」に流動性を提供してくれたユーザーにはPancakeSwapの独自トークンである「CAKE」が報酬として渡されます。

流動性提供者からしたら、自分の資金を預けるだけでトークンがもらえるのでお得です。

すると今度は「私もトークン(CAKE)が欲しい！」というユーザーが、どんどんファームに参加してきます。結果、流動性提供者も増えます。こうなることで何が起こるかというと

  1. 流動性が増える
  2. DEXとしての利便性が上がり利用者数が増える
  3. DEX・CAKEの価値が上がる
  4. DEXの取引手数料が増え、LPへの還元・CAKEのbuybackなどが行える

といったメリットが増えます。この一連の流れがイールドファーミングとの関係性になります。

トークン価格・流動性シェア・インパーマネントロスの解説

AMM・DeFiサービスを利用している方からの質問で、よくある質問や勘違いを３つまとめたので参考にしてみてください。

１３考える
コアラ

Q.LP(流動性トークン)の作成・解体にトークン価格は関係ない？

mikan
mikan

A.

LPを作成して解体すると途中でトークン価格が変わっていた場合は中のトークン比率が変わります。
トークンの比率が変わるということは、作成時よりもトークンが増えたり減ったりしているということです。
そのため、LP(流動性トークン)の作成に・解体にはトークン価格との関係性があります。

１３考える
コアラ

Q.価格の上がりやすさ下がりやすさに流動性は関係ある？

mikan
mikan

A.

流動性が少ないと価格変動が激しいため、価格が上がりやすくも下がりやすくもなります。
そのため流動性との関係はあるといえます。

１３考える
コアラ

Q.LPを組んだ後にトークン価格が上がると損をする？

mikan
mikan

A.

一部事実ではありますが、元本割れしているわけではないです。トークン価格が上がると基本的に利益は出ます。
ただ、インパーマネントロスと言ってLPを組まずに所持していた場合の方が利益が出ていることがあり、損をしているという見解になります。
インパーマネントロスについては他の記事やYoutube動画で解説しているので、そちらを参考にしてください。

インパーマネントロス（変動損失）の補足

dex.012-1

インパーマネントロスはLPのどちらかのトークン価格が上下した場合に発生します。これは画像のようにシミュレーションが可能です。

片方のトークンが4倍になるケースを想定すると計算しやすいので、実際にやってみることをおすすめします。

上の例では、BTCが50,000USDT→200,000USDTになった場合、インパーマネントロス（変動損失）は50,000USDT分になります。

https://3mikan.com/archives/580
https://www.youtube.com/watch?v=_BBQCFbkIJM

DEXのまとめ

  • 取引所の分類は大きく分けて「CEX」と「DEX」の２つがある
  • DEXは分散型取引所といい「板方式」と「AMM」に分けられる
  • DEX全体の取引高の90%はAMM
  • AMMの利用者数が増えればトークン価格が上がる
  • DeFiサービスを利用する人はDeBankもおすすめ

DEX及びDeFiは、資金力がなくてもアイディアと技術力があればプロジェクトを立ち上げて動かすことができる為、開発者からすると革命的と言えると思います。

また今回は、DEXのAMMという分野で展開されているイールドファーミングについても図を交え解説しました。

流動性プールが拡大すると、DEXの利用者が増え独自トークンの価値は上がります。そのため、DEX(特にAMM)を利用した運用は重要な戦略になるかと思います。

ただ、CEXと違い非中央集権型の為、リスク管理をしながら知識を持った上で取り組む事をおすすめします。

最後まで読んでいただきありがとうございました。

--- # 【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】 今回は、バイナンススマートチェーン(BSC)のUranium Financeで規模が大きいハッキング事件が起こったので、解説を加えていこうと思います。 今回の記事を書くにあたって、個人的に今読んでいただいているみなさんにこの事件をもとに今後の対策を知ってもらい自分の資産を守ることにつなげてほしいと思っていま… 正規URL: https://3mikan.com/archives/1785 著者: みかん 公開: 2021-08-16T15:20:13.000Z 更新: 2021-10-19T03:56:04.000Z

今回は、バイナンススマートチェーン(BSC)のUranium Financeで規模が大きいハッキング事件が起こったので、解説を加えていこうと思います。

今回の記事を書くにあたって、個人的に今読んでいただいているみなさんにこの事件をもとに今後の対策を知ってもらい自分の資産を守ることにつなげてほしいと思っています。

ぜひ最後まで読んでいただいて、今後の運用に役立ててください。

https://youtu.be/LKVtqeteps4

この記事の目的・注意事項

諸注意ですが、この記事では「大変な事件が起こったね！」という話をしたいわけではなくこの事件を通して防御力を上げてもらうことが目的です。

今DeFiのサービスでは新しいネットワークができたりと、どんどん拡大していますがその拡大に伴ってユーザーが増え悪いことを考える人も当然増えます。今後トラブルや事件に巻き込まれる可能性はなくは無いので、できるだけ知識をつけて自分の資金を守れるようになってください。

ちなみに今回の事件では既に$500万(日本円で54億円)の資金が抜かれています。現在いろんな人の協力のもと対策や対応が進んでいるようです。

そしてこの記事を書くにあたって自分なりに調べたのですが、読み込みが不十分なところがあるかもしれません。なので「この記事に書いてあるから全て正解だ」と思わずに「もしかしたら違うかもしれないから自分で調べてみよう」など自分自身で動くことを意識してもらえたらと思います。

今回の事件から学べる被害対策

今回日本円で54億円というかなり大きい金額が飛んだのですが、Twitterなどで調べてみても「3000万いかれました」など、大きい金額での被害を受けている話が上がっていました。

なので、「ここは守っておいた方がいいポイント」を今から解説していくので、DeFi初心者の方は是非読んでもらえたらと思います。

事件から学べる被害対策 5つ

1. 消えたらまずい資金でDeFi/CeFiをやらない

2. 一点集中でステークしない

3. 新台特攻したいなら知識をつける

4.「migrate無し」「タイムロック有り」など新しいファームに参加する際のルールを決める

5. 参加しているファームのtelegramやdiscordには参加する

1. 消えたらまずい資金でDefi/CeFiをやらない

「このお金がなくなったら生活ができない」というお金でDeFiをやらないことが大事です。実際にUraniumのテレグラムで「すべての貯金・生活費を全突っ込みして、もう生活ができません」というふうになっている外国人の方などいたので、消えたらまずいお金でDeFiはやらないことを強くお勧めします。

もちろん無くなっていいお金を持っている人はいないと思いますが、無くなっても生活に支障が出ない範囲でやってもらえたらと思います。

2. 一点集中でステークしない

人間なので、いろんなDeFiに分散して入れていると、だんだん利率がいいところに入れたくなってきます。

例えば、１千万円あるとして10個に100万円ずつ分散入れる人と、利率が一番いいところ1個に全部入れちゃおう！という人がいますが、後者は今回みたいなトラブルが起きたときに一発で全部持っていかれるので、一点集中しないことが重要です。

3. 新台特攻したいなら知識をつける

新台特攻とはざっくり言うと「新しいファーム・プール」のことをいいます。

すぐにでも新台特攻したいなら、絶対に知識をつけるべきだと思っています。基本的に新しいファームやプールが本当に安全なのかどうかははっきりわかりません。

また今回の事件はセキュリティの穴を突かれたわけですが、仮に穴を突かれなかったとしても、運営がトークンを売ったり、大口のユーザーがトークンを売ったりすることでトークン価格が下がる「Dump」という状態が起きる可能性もあります。

このように、今後どれだけけセキュリティがしっかりしてきてもそう言った被害に巻き込まれる可能性はみんな等しくあります。

なので新台特攻したい場合は知識をちゃんとつけるようにしましょう。

4. 「migrate無し」「タイムロック有り」など、新しいファームに参加する際のルールを決める

参加する際のルールは絶対に決めておいた方がいいです。

実を言うと２ヶ月くらい前までは「migrateがあるない・タイムロックあるない」で多くのユーザーが過敏に反応していて、パトロールのようなものまでありました。

むしろ最近では「migrateないのが普通だよね」「タイムロックあるのが普通だよね」という状態が標準化してきて、この辺りの「あるない」の確認を誰もしていないなあという印象があるので、自分で「migurate・タイムロックのあるない」を確認するようにした方がいいと感じています。

5. 参加しているファームのtelegramかdiscordには参加する

今回のUraniumの件も含めて、ハッキングが起きてからファームのグループに参加する人が意外といます。

例えば、「どんどんトークンの価格が落ちてるぞ？どうなっているんだ？」と気づいた人がTelegramに参加して、そこで初めて３時間前にハッキングされていたと気づくケースがあります。

また、こういったグループには通称「ラグプル警察」と呼ばれるユーザーがいて「このファームはmigrateコードがあるぞ」「ここはラグプル(rugpull)だぞ」みたいにパトロールして教えてくれているユーザーがいます。こういう人のおかげで危ないファームに資金を突っ込むことを止めることができます。

ただ、彼らが本当のことを言っているかどうかもわかりませんし、中にはいろいろネガティブなことを批判されていたけどうまくいっているファームもあるので、グループに参加しつつ各自で知識をたくわえて対策できるようになりましょう。

ハッキングの概要・被害

先に言っておきますが、私自身Uranium Financeをやっていたわけではありません。実を言うと、前からUranium Financeが話題になっていたのでやろうかなと思っていました。

ただ、前に一度サイトがハッキングされて、その後ハッキングされたのかされていないのか中途半端な状況になり、いつの間にか復活していた…という曖昧な感じになっていたので「なるほどなもうここはやらないでおこう」と判断しました。

そして最近になってまた話題になり、質問も結構きていたので触り方だけ解説をやろうかなと思っていた矢先、２度目の被害が発生した。という感じでした。

なので、実際に運用していたわけではありませんが、今回被害状況などを公式サイト・ニュースサイト・Twitterなどで情報収集したので、この記事で解説していきたいと思います。

まず下の画像はUraniumの流動性のコントラクトのトランザクションになります。

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

BUSDとADAのペアなんかはガバガバに抜かれているという感じです。こんな感じで他のペアもやられていて、合計で50000万ドル分(日本円で約54億円分)持っていかれました。

この画像のページ(トランザクション)は実際に誰でも見ることができるので、できれば見ておくことをお勧めします。というのもどんな感じで資金が抜かれていくのか？や、犯人のウォレットアドレスのコントラクトを見ることもできるので勉強になるかと思います。

この画像のページを見る

何が起こったのか？

ここからはさらに細かく説明していきます。

かなり専門的な内容になるので、この部分は正直読まなくても大丈夫です。最後の「まとめ」の項目に重要だと思ったことを書いているのでここは飛ばして読んでいただいて構いません。興味のある方だけ読んでいただけたらと思います。

まず「何が起こったのか？」ということに関してですが、V2からV3に移行したときにコードに穴ができました。

V2からV3に移行したと言っていますが、具体的にはUraniumLPやUraniumFactoryというSwapやDEXの取引所の機能の部分をアップ デートしました。ですがその際に穴ができてしまったということになります。

今回のトラブルが起きた箇所は下の画像の赤線(10000)と緑線(1000の２乗)のところになります。

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

元々このUraniumはUniSwapというものをフォークして作ったそうですがUniSwapは1000,1000,1000の２乗、Pancakeは10000,10000,10000の２乗、今回のUraniumのV2は10000,10000,1000の２乗となっています。(下記画像参照)

ちなみにUranium FactoryやUraniumのLP RADSLPですべて確認できます。これは取引所の機能でいうところのSWAPになります。トークンの交換のプログラムの一部です。

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

続いて下の画像のUraniumのV1・V２・V2.1をそれぞれ比較してみると、V1は1000,1000,1000の２乗だったのでバグは起こっていませんでした。

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

ですがV2に移行した際にトラブルが起こったので、V2.1では、10000,10000,1000の２乗の部分を変数に変えていることがわかります。変数に変えたことで書き換え漏れがないのでおそらくこの部分を修正したんだろうと思われます。

ただ、これに関してTwitterやTelegramなどでは「意図的なんじゃないか？」と言っている人がちらほらいたので次の項目でこの疑問についてまとめました。

疑問点

  1. マジックナンバー(数字直打ち)おかしくない？
  2. 内部犯行では？
  3. 普通あの箇所変更しなくない？

1. マジックナンバー(数字直打ち)おかしくない？

確かに変数を打った方がいいですが、フォーク元のUniswapも直打ちなので意図的なものではないと思います。

先ほどの画像にもあったように数字の部分が直打ちしてあるのですが、確かにこれはエンジニア界隈では「普通やらないよね？」と思うやり方です。なぜなら今回のようなトラブルが起こるからです。(数字を変えたら他のところも変えなきゃいけないのに、変え忘れる人為的ミスが起こりトラブルが発生するため)

ただ、フォーク元のUniswapも数字は直打ちです。なのでUniswapの時点で本当はダメだったというだけで、Uraniumを開発した人が深く考えてやっていないだけじゃないかな？と思います。

2. 内部犯行では？

「V2からV2.1に移行します」とアナウンスが出てすぐにハッキングされて、その後該当箇所が修正されたので、内部犯行なのでは？と疑っている人もいました。

確かに話の流れがスムーズなのでそのようにも見えます。ただ、実行内容自体は技術的に誰でも可能です。V2.1移行の話も内部のエンジニアはこの箇所のミスに気付いていただけかもしれません。

ただここに関しては追加で事実情報が出てこないとあくまで予測しかないのであまり詳細な話はできないかなと思っています。

3. 普通あの箇所変更しなくない？

今回Uranium Financeは手数料を0.2%から0.16%に下げました。なので手数料率の変更に伴って必要な変更になります。連動している部分の変更し忘れといったイメージです。

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

少し詳しく説明すると、まずUraniumのV1の一番上には「balance0Adjusted」と書かれています。これは「balance0を1000倍にして手数料0.2%分を引く」という数式です。

これだけを見ると「普通に0.002倍にすればいいじゃないか」と思うかもしれないですが、あのプログラムの中では小数点ってものを扱うと少し数字がおかしくなることがあるので、「全部一回整数に戻してから計算する」というパターンがあります。

なので、0.2%を表現したいなら1000倍にします。すると１の位が0.1%の単位になるのでこれで計算すると、今回0.2%から0.16%にしたのでもう一桁必要になりました。そしてV2ではそこが反映されることになりました。

そして、V2では移行に伴い10000倍して16引くという計算が必要になりました。ただ、V2の赤文字で書かれている10000の部分を変えた時に、右下にある1000**2も変えないといけなかったのですが、変え忘れが起きました。その結果、ガッツリ資金を持っていかれてしまいました。

本当にちょっとしたことですが、これだけの差でかなりの金額でトラブルが起きてしまうので、エンジニアの仕事というのはとても大変だなと思います。

ざっと詳細を話しましたが「普通あの箇所変更しなくない？」という意見は、確かに動いているから変更しないことはわかりますが、今回は手数料を変えることになったので、変更することになったという感じです。

シミュレーション

今回の事件でが「どのようにして起こったのか？」実際にシミュレーションをしていきます。

手口としてはDEX(取引所)に対してBUSDとADAの２つを一番小さい単位で送ります。その代わりにDEXからBUSDとADAを両方とも抜きとるというやり方です。

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

BscScanでトランザクションを見てみると、かなりの金額が持っていかれていることがわかります。

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

ここから「どうやって抜き取ったのか？」その手口を解説していきます。数字が小さい方がわかりやすいので下の画像をもとに解説します。

先ほども言ったようにこれからシミュレーションでやっていく手口としては、DEX(取引所)に対してBUSDとADAの２つを一番小さい単位で送り、その代わりにDEXからBUSDとADAを両方とも打ち抜くというやり方です。

下の画像はUraniumのV2のスワップの部分です。少し見にくいですが今からこれを実際に見ていきます。

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

まず上部にamount0Out(BUSD)、amount1Out(ADA)とあります。(下記画像赤線↓)

そしてこの２つを出力するプログラムを投げます。

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

次にreserve0、reserve1とありますが、reserveというのは「取引所内の交換できるトークン数(残高)」を意味します。

そして右側の黄色の枠内を見ると残高がわかります。BUSDが63808でADAが84754となっています。

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

続いてamount0Out(BUSD)について説明します。まずsafeTransferとありますが、これは「先に取引所からトークンを送る処理の予約」を意味します。その後ろにはtoとありますが、これは犯人のアドレス先を意味していて、この先にある犯人のアドレスに57428BUSDを送ることになります。(amount1Out(ADA)も同じ流れ。76279ADAを送る。)

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

次にbalance0を見てみます。ここでいう「balance」というのは取引所内の残高の計算を意味します。計算式としては元々の「63808」に最小単位の１を送ったので「＋１−57428」となります。(balance1も同じように計算します)

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

続いてbalance0Adjustedでは「その手数料分を差し引いても、ちゃんとトークン交換ができるのか？」を見ることができます。

ここでは先ほどの計算式ででた「6381」を10000倍して0.16%分を引くという計算をします。(balance1Adjustedも同じように計算します。)

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

続いて「手数料差し引いたら交換できないんじゃないか？」というチェックです。ぱっとみ数式がバァっと並べられているだけのように見えますが、よく見ると左側の方が大きいことがわかります。なので今回は通過します。

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

ただ、本来だとこれは通過しません。何故通過しないかというと緑矢印の部分を見るとわかります。今回1000の２乗は人為的なミスでやってしまっているので数式は左側が大きくなっていますが、本来は10000の２乗なので、計算式は1000ではなく０が２つ増えて100000になるはずです。

すると10の17乗になるので、右側が大きくなり処理が停止します。処理が停止するとここまでやった内容の全てがロールバックされる(元の状態に戻される)ことになります。

【BSC】UraniumFinance（ウラン）のハッキング事件の詳細！54億円分の被害の詳細と原因・初心者の為の対策・コントラクトの解説などなど【DeFi】の説明画像

ただ、今回に限ってチェックが通過しスワップが成り立ってしまい取引所残高の90%に相当する金額を出せる仕組みになってしまっていました。

なので、流動性の中の残高がわかればその90%を何回も何回も出力させているという感じになっています。100万円あったとしたらそのうちの90万円を抜き取り、次に残り10万円から9万円を抜き取り、次に残り1万円から9000円を抜き取り、次に1000円・・・と言った感じでずっと繰り返し出力されていました。

なので、BscScanでトランザクションを見るとわかりますが、トランザクションがとにかくたくさん表示されます。(参考ページ：BscScan)

まとめ

今回はコードを見ながら解説していきましたが、コードに原因があるかもしれないからといって自分が新しいファームを見つけたときにコードを一つ一つ見ないといけないのか？と不安になる人もいるかもしれません。

ただ正直それは現実的じゃないですし、無理な話なのでファームに参加するときは「ステーキング先がハッキングされる可能性は０じゃない」と考えながらやるようにするしかありません。

それともう一つ私も含めてですが、情報発信している人も調べられる範囲には限界が必ずあります。今回のハッキングもおそらく予期しなかった人の方が圧倒的に多いです。なので、悪意を持って情報発信をしているわけではないということを理解してもらった方がいいと思います。

あくまで自分が参加してて、なおかつ情報を欲しがっている人がいるからYoutubeやTwitterで発信しとこうぐらいの感じだと思います。

本当であれば今回の記事のようにコードなども見て「ここは危ないですね。ここは安全ですね。」って言えるところまで細かく調べて発信できるのが一番いいですが、それだと時間もかかりますし専門的な知識を持っていないとわからないので現実的ではありません。

なので、発信者の情報を鵜呑みにせずあくまでも自分主体で判断して運用していきましょう。

感想

個人的に今回の事件は衝撃で、これは今後運用していく中でとても重要だなと思ったことがありました。

今回扱ったUraniumFinanceではV1からV2への移行で事件が起きました。イメージとしては、新しい台がハッキングされるわけではなくV1からV2に場所が移動した時にハッキングされたという感じだったので、V1でうまくいっていたファームだったとしてもV2になった時にラグる可能性があることが証明されました。

なので、もしかしたら今後同じようなパターンでラグるファームが増えてくるんじゃないか？と正直思っています。

V1が調子良かったからどこかのタイミング手数料を下げます！と言ってV2に移行させるとして、ユーザーもV1での安心感や信頼感をみんな感じているので「全然いいよ！」となります。その時にハッカーはセキュリティホールを作っておいて、どんどんユーザーが参加したタイミングで資金を引き抜くことができたので、今回の事件を頭に入れて今後も注意しないといけないと感じました。

とはいえ、V2に移行すればコントラクトも変わりますしRouterもFactoryも変わるので新規ファームと同じように扱わないといけないはずなんですね。ただ、V1である程度うまくいっているところだと移行しようが信用しちゃうことがあるので、今回は良い勉強になったなと思います。

これからも3MIKANでは仮想通貨に関する情報などを発信していきます。Youtube動画もアップしているので、動画の方がわかりやすいという方はぜひ見てみてください。(Youtube: 3MIKAN チャンネル)

最後まで読んでいただきありがとうございました。

--- # 【DeFi】Timelockが重要ではない3つの理由を徹底解説します 今回の記事では、『Timelockが重要ではない理由』について解説していきたいと思います。 主にDeFiの、イールドファーミングにおける話になります。 今までは、Rugpull関連の動画などでも『Timelockがあるかどうか確認してください』という話をお伝えしてきたと思います。ただ、この数週間で結構状況も… 正規URL: https://3mikan.com/archives/1753 著者: みかん 公開: 2021-07-10T02:18:23.000Z 更新: 2021-10-19T03:55:36.000Z

今回の記事では、『Timelockが重要ではない理由』について解説していきたいと思います。

主にDeFiの、イールドファーミングにおける話になります。

今までは、Rugpull関連の動画などでも『Timelockがあるかどうか確認してください』という話をお伝えしてきたと思います。ただ、この数週間で結構状況も変わり色々考えた結果Timelockはさほど重要ではないなという結論に至りました。その理由を今回は紹介したいなと思うので、是非最後まで読んで頂ければと思います。

https://youtu.be/OUcfU6YE79A

Timelockとは

Timelockのメインは引き抜き用のコード対策です。人のプールに入れてあるトークンを勝手に引き出すことができるので危険なコードと言われています。

そのため、悪意のあるプロジェクトがこういった機能を使うとどんどん資金を引き抜く事が可能でした。なので、TImelockをしている間はそうゆう機能が使えなくなるので安全だと思われています。

この記事の前提として、Timelockがあるから悪いというわけではありません。機能としては良い機能ですし、防御するという点においては、役に立つ場面もあるかと思います。

ただ、『Timelockがあるから安全』『Timelockがあるから大丈夫』という考え方は無くしてほしいなと思いこの記事を書いています。

まずはTimelock主な仕組みを2つ紹介します。

①オーナーのみの機能の実行を遅らせる

（例）MasterChef
MasterChefに一番利用されていることが多いです。

MasterChefのオーナーにTimelockを設定することで、オーナーの機能を使いたい場合はTimelock経由でMasterChefに機能を飛ばす必要があります。

Timelockにこの関数を実行したいという物を飛ばすと、６時間や２４時間後ぐらいにMasterChefで実行されます。具体的に何時間後に実行されるかは、Timelock側で決められます。この【何時間後に実行する】というこの機能がTimelockです。

②結果的にMasterChefなどの変更が即座に行われたりしない

Timelockを設定した事で結果的に、MasterChefの変更がすぐに行われる事はないです。逆にTimelockがない場合だと、開発者が実行したらすぐに変更されます。

なので、その時間何も変更されないということはラグプル起こらないよねと思われていました。ここが結果的に、勘違いの原因になってしまっていました。

重要ではないと思う理由３つ

私自身もTimelockがあることで安全だと思い込んでいました。ただ、最近のラグり方やRugpullのケースを見ているとTimelockが関係ないと思い始めました。

逆に、Timelockがあることで人が集まってしまいより被害が拡大しやすです。自分自身が被害を受けない為にも、Timelockに対する考え方は直したいと思った理由が、下記３つです。

①オーナー機能以外は利用できる

Timelockをしている間、オーナー機能以外は利用できます。
そして、現在のRugpullの主要なやり方はオーナー機能以外を使って行うやり方になっています。

例えば最近、stablemagnetでRugpullがありました。Swapと言われる普通のユーザーが使える機能を使ってラグっています。

ユーザーが使える機能＝オーナーもすぐに発行ができるので、Timelockのあるなしに関係なく実行できます。

つまり、ユーザーも触れる範囲に何かセキュリティのホールを作っておくとすぐにラグることが可能です。これが、今の主要なやり方になっています。このようなRugpullが増え結果的にオーナー機能を使わなくても、ラグれてしまうという状況になっています。

結論：Timelockがあっても無くても、普通の機能は使えてしまうので意味がない！

②防御も遅らせてしまう

Timelockは攻撃を受けたときの防御も遅らせてしまいます。この場合、悪意の無いプロジェクトにとっては邪魔でしかないです。

Timelockは運営がラグるパターンだけでなく、第三者からの攻撃を受ける場合もあります。

例えば、パンケーキバニー／IRONFINANCEのように、運営側に悪意が無くても攻撃を受けてしまった場合。防御の際もTimelockを経由する必要があるので、その度に２４時間待つことになります。これだと明らかに手遅れになり、防御を遅らせてしまう事に繋がります。

結論：Timelockは防御の邪魔になる！

③逐一確認する労力をかけるユーザーや機関が無い

Timelockはdelay（実行されるまでの時間）が設定されていてQueueという形で実行される予定のものが蓄積されていきますが逐一確認する労力をかけるユーザーや機関が無いです。

Queueで蓄積されていくことで、ユーザーはそれを見てRugpullと判断し抜けていくと思いますが。プロジェクトやプロトコルがありすぎて、全て確認することは出来ていないと思います。

確認する機関もないので、現実的に全てを把握すること自体が不可能だと思っています。なので、Queueで保存されていてもいなくても気づかなかったら意味がないと思います。仮にQueueに入っていても、気づかないうちに実行されラグられたら終わりです。

結論：気づかなかったらTimelockを設定してあっても意味がない！

まとめ

大きく上記３つの理由で、Timelockがそこまで重要ではないと考えてます。

私個人の意見として、Timelockがあるかないかではなく。そもそも、Timelockがないと安心できないようなプロジェクトには大金を突っ込まないというのが結論です。

Timelockを信用しすぎないようにし、一つの材料として見れるようになるといいんじゃないかなと思い解説しました。

RugDoc

RugDocが出しているWikiでTimelockについてよく知って欲しいという内容があったので紹介していきたいと思います。

紹介URL▶RugDocWiki

【DeFi】Timelockが重要ではない3つの理由を徹底解説しますの説明画像

背景情報

背景情報から見ていきます。

【DeFi】Timelockが重要ではない3つの理由を徹底解説しますの説明画像

①ラグらないか確認したいという意味。

Masterchefのプールにユーザーはデポジットしていると思いますが、Masterchefのオーナーが外に資金を流したら結果的に全部資金が流されてしまうので金庫のように考えてください。

②ラグってしまうと100%とられてしまうという意味。

みんなの資金をまとめて集めている金庫があったとして、その金庫の鍵を持っている人はいつでもアクセスできるし全部持っていけます。しかも、今回は電子情報なので物量的に持てないとい事もないし、一瞬で持っていけてしまう。

結論：安全なプロジェクト・信頼できるプロジェクトに資金は入れましょう！

タイムロックとは正確には何ですか？なぜ気にする必要がありますか？

タイムロックとは、【Timelock】というクッションを挟む事で、オーナーの実行を遅らせる事ができる。

Timelockの事を、boxとここでは表記してあります。

【DeFi】Timelockが重要ではない3つの理由を徹底解説しますの説明画像

①金庫の鍵を開けようと思うと、すぐに開けることができない。

このボックスは設定可能なタイマーが設定されているという点で特別である。所有者がキー入れて閉じると、ボックスが自動的にロックされる。所有者が鍵を中に入れたい場合はタイマーを開始する必要があり、タイマーが切れるとロックが解除される。これによって悪意のある所有者の能力が低下される。

②内部のコードを書き換える事ではなくて、いつ呼び出すかだけが変更される。
※金庫の話から、スマートコントラクトの話に切り替わっています。

Queueに入れられるトランザクションは、通常変数を更新したりMasterchefスマートコントラクトに存在する関数を呼び出したりすることを目的にしている。

タイムロックについての真実 

【DeFi】Timelockが重要ではない3つの理由を徹底解説しますの説明画像

①オーナーが資金を盗む可能性がある場合のみに便利。

鍵のコピーが無ければ、銀行の金庫室の鍵を使っていつでも金庫室にアクセスすることができる。そのため、所有者の能力が重要ではない。

②ラグのリスクが低い場合は、そもそもTimelockは関係ない。

Timelockは、オーナーから身を守るのを助けるだけです。そのため、オーナーではない機能を使われてしまうと意味がない。

③オーナー機能ではない所にセキュリティホールを作ると実行できてしまう。

所有者は、マスターボールトキーをタイムロックに『デポジット』する前にそのコピーを作成でき全てを盗むことが可能。これは、スマートコントラクトが開発者ロールの機能を隠してアクションを実行できるようにする場合のようになります。

④所有者はTimelockのタイマーを短く設定することも可能。

タイマーが６時間しかない場合、所有者は夜にタイマーを開始しユーザーが目を覚ます前にユーザーの資金で逃げることが可能。

タイムロックが有害な場合

【DeFi】Timelockが重要ではない3つの理由を徹底解説しますの説明画像

オーナーが悪意がない場合Timelockをかけるだけ邪魔になる。

Timelockの間は誰も中に入ることができない為、その間に事件が大きくなりやっと中に入れた時には資金が全てなくなってしまう。

結果的に守る時にも邪魔になる！！

まとめ

以上がRugDocに記載してあった内容になります。

DeFiを行う上で、基本的に自分で情報を集め実践されている方がほとんどだと思います。是非このRugDocも参考にしていただいて、一つの学びとして見ていただければと思います。

今回はTimelockが重要ではないという内容をお伝えしましたが、もちろんTimelockがあってはいけないというわけではないです。Timelockも目的があって一つの機能を守ることができています。

ただ、『Timelock＝安全・安心』この考えが少しでも変われば自分の資金を守ることに繋がるのではないかなと思います。

--- # 【IRON】20億ドル→0ドル。IRON・TITANで起きた事件を解説します【DeFi】 今回は最近起こったironfinance(アイアンファイナンス)の暴落について、画像付きで解説をしていきたいと思います。暴落と言いましたが、崩壊に近いです。 この記事を書くにあたって自分でもいろいろ調べたのですが、TwitterやSNS上で「運営が飛んだ、逃げた」など、他にも間違った情報が飛び交っている部分… 正規URL: https://3mikan.com/archives/1454 著者: みかん 公開: 2021-06-24T14:48:25.000Z 更新: 2021-10-19T03:54:50.000Z

今回は最近起こったironfinance(アイアンファイナンス)の暴落について、画像付きで解説をしていきたいと思います。暴落と言いましたが、崩壊に近いです。

この記事を書くにあたって自分でもいろいろ調べたのですが、TwitterやSNS上で「運営が飛んだ、逃げた」など、他にも間違った情報が飛び交っている部分があったので、事実を元にして解説していきたいと思います。

また、このironfinanceは、仮想通貨業界のインフルエンサー的な方の発信や、その他いろんな人の発信を見てやったという人が多いようですが、基本的には自分で判断しないといけない世界なので、この解説記事もあくまで参考程度に見ていただけたらと思います。

はじめに

先に、私個人のironfinance運用状況について書いておきます。

私自身もIRON-USDCペアで途中までやっていましたが、１回目の暴落で＄60から＄40まで落ちた時があり、そこで売っています。

ちなみにこの時、私が運営しているテレグラムのグループの中で「このタイミングで私は抜けますね。」と言って売っているので、気づいている人は気づいていると思います。もしテレグラムのグループに参加して、自分も情報収集したいという方は下のリンクからグループに参加してください。

【3MIKANのテレグラムに参加する】

では早速、本題に入っていきます。

暴落の概要

今回何が起きたのかを簡単に言うなら、「TITAN」が$60から限りなく０に近い$0.000001ともいえるところまで暴落したことにより、その後、IRONの売却がどんどん進み価格が暴落していったという感じです。(下記画像参照↓)

【IRON】20億ドル→0ドル。IRON・TITANで起きた事件を解説します【DeFi】の説明画像

最初、TITANは＄60から$40くらいまで暴落しているのですが、この時に私は抜けました。その後＄50くらいまで一旦回復して、また一気に暴落した感じです。

ちなみに＄50からほぼ０のところまで暴落した時は、日本が深夜の時間帯だったので朝起きてチェックしてみたら言葉が出ない・・・。という人もいたと思います。

０まで暴落した時には、PolygonNetworkがとても重たくなっていて、トランザクションが通らない状況でした。なので「売り抜ける」ということが出来ず、売れないままどんどん価格が下がっていき、ページをリロードする度に価格が下がっていく・・・という悲惨な状況でした。

暴落時にはTITANが物凄い速さで売られすぎて「そうなったらIRONも持つ意味ないよね」という流れになり、IRONを持つ人が減り、TITANの暴落に引っ張られる形でIRONも暴落していきました。

すると結果として、TITAN、IRONを持っていた人が大きな損失を被る結果となりました。

IRON･TITANの仕組み

続いて、IRON･TITANの仕組みを簡単に解説していきます。より詳細な解説はSNSなどで詳しい方たちが発信してくれているので、ここではざっくり解説していきます。

【IRON】20億ドル→0ドル。IRON・TITANで起きた事件を解説します【DeFi】の説明画像

まず、USDCとTITANを使ってIRONのMINTができます。

IRONは＄1の価値があるとされていた通貨ですが、それを＄1のUSDCではなく、MINTすることで、上の画像の数字の場合83.40%のUSDCと、残りをTITANで＄1のIRONが取得できます。

そして同じようにREDEEMを使うことで、＄1分のIRONを、USDCとIRONに変更できます。

このMINTとREDEEMがあるおかげで、これとは別にUSDCとIRONのLPが組まれているので、USDCとIRONは普通にスワップができるようになっています。

例

例えば、IRONの価格が＄1を下回っていたら、スワップしてREDEEMで分解することが出来ます。すると結果的に＄1分のトークンが手に入ります。

そしてその流動性から買ってREDEEMで分解するということを繰り返しやれば、稼ぐことができるプラス、流動性の方のIRONの価格も＄1に戻ってきます。

逆に、流動性の方のIRONの価格が＄1を上回っていった場合には、MINTをして、＄1でIRONを生成して流動性で売ります。これをすることで利益が出て価格を下げることができる仕組みになっています。

この一連の操作は「TITANを混ぜる」ことがポイントになっています。TITANが入ることでクッション的な要素が入り、USDCと完全な一対一ではなくなるのでこのようなことが出来ます。

正直、ここが今回の問題となった箇所です。ここに関してはいろんな方が考察してくれているので、チェックしてみてください。

暴落までの流れ

今回どのように暴落に至ったのか運営サイドが詳細を発表しているので、それを元に流れを解説していきたいと思います。

内容は、下の画像を見てのとおり大きく分けて６つあります。この内容をGoogle翻訳にかけて、順に詳しく解説していきます。

【IRON】20億ドル→0ドル。IRON・TITANで起きた事件を解説します【DeFi】の説明画像

１について

【IRON】20億ドル→0ドル。IRON・TITANで起きた事件を解説します【DeFi】の説明画像

「TITANは非常に高価で60〜65米ドルに急騰しました。」と書かれていますが、これは、一番最初に値上がりした時のことを言っています。(下記画像参照)

このとき、すごい上がり方をしていたので、人によっては億り人になった人もいたんじゃないかなと思っています。

【IRON】20億ドル→0ドル。IRON・TITANで起きた事件を解説します【DeFi】の説明画像

そして次に、「その後、60に戻ると、クジラが投棄され、少しパニックになりました。」と書かれています。

クジラとは大口ユーザーのことを言います。大口ユーザーの人がかなりの金額を売ったことで約＄20下がり、少しパニックになりました。ちなみに何度も言うようですが、私もこの時に売っています。

次に、「20万件の取引が行われ、多くの人が即座に売りました。」と書かれています。これは翻訳通りの意味です。約＄20ほど下落して＄40になった時に、TITANを売った人やIRONを売った人が続出したということです。

2について

【IRON】20億ドル→0ドル。IRON・TITANで起きた事件を解説します【DeFi】の説明画像

「その後、TITANが急激に低下したため、IRONはペグを失いました。」と書かれています。文字通り、TITANが急激に低下すると制御不能になります。さらっと書いてありましたが、これが制御不能を招いた全ての理由です。

次に「これで、90セント相当のトークンを75セントのstablecoinと25セントのTITANに交換できます。」と書かれています。どういうことかと言うと、まずIRONを売る人が増え、IRONの価格が下がり、流動性の方でIRONが90セントになったので$0.9で購入できるような状況になってしまいました。

ということは、先ほど「例」の項目で解説したように、＄0.9でIRONを購入後、REDEEMで分解することで＄1に変えることができるので、「これ、無限に稼げるんじゃない？」と考える人がいました。

次に「したがって、裁定取引の機会がありますが、これには毎回新しいTITANを作成する必要がありました。」と書かれています。まず裁定取引とは＄0.9で買って＄1で分解することを言います。そして、この操作をするには毎回新しいTITANを作成する必要がありました。というふうに書かれています。

なので、REDEEMする場合にはどうしてもTITANが25％生成され、さらにREDEEMの操作を繰り返すことでよりTITANが生成されることになる。といった内容になります。

3について

【IRON】20億ドル→0ドル。IRON・TITANで起きた事件を解説します【DeFi】の説明画像

「大きなクジラは非現実的なペースで裁定取引を開始し、市場に新たに鋳造されたTITANが殺到しました。」と書かれています。大口のユーザーが非現実的なスピードで裁定取引を始めたということになりますが、おそらく手動ではなく、Botを組んでいたんじゃないかと思われます。

そして、裁定取引が繰り返し行われたことでTITANの生成が進み、価格も下がっていきました。

なぜTITANの価格が下がるのかというと、まずREDEEMをする時に＄1のIRONを入れたとしたら＄0.25のTITANが生成されます。

ただ、TITANの価格が下がれば下がるほど＄0.25分には多くのTITANが必要になります。

例えば、TITANの価格が＄1だった場合、生成に必要なTITANは0.25で済みますが、仮にTITANの価格が＄0.025だったら、生成には10TITANが必要になります。このような感じで、TITANの価格が下がれば下がるほどたくさんのTITANを生成しなきゃいけなくります。

次に「誰もがパニックに陥り、依然としてTITANの価格を押し下げており、ペグはTITANの価格に関連しているため、下落し続けています。これは、ペグを取り戻さないと止められない悪循環です。」と書かれています。

これはもう文面そのままの意味で理解ができると思います。補足するとしたら、REDEEMの際に生成したTITANはすぐ売られるので価格がどんどん下がります。

そして、「ペグを取り戻さないと止められない悪循環」とはどういうことなのかというと、MINTする際にはTITANが少し混ざります。この時TITANは担保のような役割だと考える人が多いですが、TITANが暴落してほぼ$0になった時、結果的に83%のUSDCで＄１のIRONを発効している状態になってしまいました。要は、USDCしか価値を持っているものがなくなり、USDC分の担保しかなくなった状態になりました。

4について

【IRON】20億ドル→0ドル。IRON・TITANで起きた事件を解説します【DeFi】の説明画像

「ペグは15分間回復し、TITANは回復しているように見えました。しかし私たちは再びペグを失い、TITANの鋳造と販売のフィードバックループがすぐに再開しました。」と書いてあります。

ここも、文面そのままの意味で理解できると思います。ペグは15分回復し、TITANは回復しているように見えたが、結果、ダメになったということですね。

5について

【IRON】20億ドル→0ドル。IRON・TITANで起きた事件を解説します【DeFi】の説明画像

「結果：Ironがペグされていない限り、TITANは無限にドロップします。また、TITANがドロップし続けると、Ironはペグされません。」と書かれています。これが、暴落が起こる数日前に起こっていた価格上昇です。このことを踏まえると、ironfinanceは上がる時も早ければ下がる時も早いです。

続いて「最終結果：TITANは数分の１セント、IRONは安定したコイン(71〜75セント)に支えられています。」と書かれています。この、安定したコインというのはUSDCのことを言っています。MINTの際にUSDCを預けてもらった分があるので、その部分が確保できているという意味です。

そして、「多くの人がここで数千ドルを失いました、私は皆なに申し訳ありません。」と書かれています。今回の暴落では日本人の中には2000万くらいの損失をしている人もいました。(Twitterで偶然拝見しました。)

6について

【IRON】20億ドル→0ドル。IRON・TITANで起きた事件を解説します【DeFi】の説明画像

「彼らがそれを修正できる唯一の方法は、TITAN開発者がミンティングプロトコルについて何かをする場合です。これは、IRONステーブルコインの基板全体は基づいているため不可能と思われます。」と書かれています。

１〜５までの内容がわかれば、ここの意味もなんとなくわかるかと思います。以上で、ことの顛末はこんな感じになります。

補足・まとめ

ちなみにですが、TwitterやSNS上では「運営が飛んだ、逃げた」と間違った情報が出ていますが、運営は売ってもなければ、逃げてもいません。また、ハッキング、ラグプル、エクスプロイトでもありません。シンプルに、仕組みが関係して価格が下がり崩壊していったという感じです。

そして、「USDCの担保の行方」についても話題になっていましたが、元々、USDCはAAVEというレンディングプロトコルで運用されていて、そこから引き出されていたので「飛ぶんじゃないか？」と言われていました

ですが、今のところは飛んでませんし、実際過去に１度問題が起きた時に飛んでいないので、今回もおそらく飛ぶことはないんじゃないかと思っています。

というのも、すでにREDEEMの再開のアナウンスも出ていますし、コンペンセーション(賠償金)はまだですが、保証のプランも今後出てくると、個人的には読んでいるからです。また、下の画像の上部には、運営から「今は買わないでください」と赤く表示されているので、ちゃんと整理をしたいんじゃないかと思います。

そして「REDEEMを解放していたから、こんなことが起きたんじゃないのか？」と言っている人もいますが、確かに仕組みを見ればその通りではあるのですが、この機能がなければIRONを買う人がかなり少なかったと思います。

このREDEEMはIRONの価格維持機構の一つなので、この機能がなければIRONのペグが外れやすい＝＄1を外れやすいということになるので、IRONはもうステーブルコインとは言えなくなります。となると、USDCからスワップする必要もなくなってしまいますよね。

それに、このことは「MINTする時にTITANを混ぜる」という時点で、元々分かっていたことです。当時は画期的と言われていましたが、画期的な反面、崩壊の懸念点にもなると詳しい人たちの間ではずっと言われていました。

今回のこの件では、間違った認識をしている人も多いので、TwitterなどのSNSで情報収集をする時は気をつけてください。また、もし損失をした人がいたら、これからテレグラムやTwitterの公式アナウンスをチェックしてみてください。今回の保証とは関係なく他でAirdropがあります。ここに関してはまた別で記事を書きたいと思います。

そして、今後は　どこにリスクがあるのかということを考えた上で、まずはしっかり理解して投資をするようにしたほうが良いかなとは思います。

注意喚起

あくまで自分で判断しましょう

今回の件で、仮想通貨関連を発信してくれていた有名なインフルエンサーの方が鍵垢になってしまったのですが、かなりのアンチが出てきたんだろうなと思います。

インフルエンサー的な人の発信を見て動いた人がかなりいたのかな。と思いますが、あくまでも発信者は選択肢を見せてるだけと思ってください。

「お前が言っていたから買ったのに、落ちたじゃないか！」的なことを言われまくって鍵垢にしたのかな？と察しますが、私がもし同じ立場だったら、正直私も鍵垢にすると思います。

せっかく発信しているのに、その意味もなくなってしまいますし、一人の人間として精神的なダメージは当たり前に受けます。また、避難を浴びせまくると、発信してくれる人も発信してくれなくなるので、あくまで自分で判断してお金を使っているということを忘れないようにしていきたいですね。

ステーブル関連のプロジェクトはTVLが非常に集まりやすい

今回扱った、ironfinanceやSafedollarなどステーブルをうたっているプロジェクトはTVLが非常に集まりやすいです。

過去に、MidasDollar、bdollar、MonsterSlayerCashなどが流行り、かなりTVLも集まり、トークン価格も上がったのですが結果的に悲惨なことになりました。

そして今Polygonが出てきて新規の人も増えたようでまた流行りそうな雰囲気があるので、「ステーブルだから」ということに流されずに、自分でちゃんと情報収集をしてもらえたらと思います。

錬金術はない

今回、IRONの煽り文句で「錬金術」というワードが出ていたのですが、これはないと思っていた方がいいです。

ironfinanceの場合は、暴落まではめちゃくちゃうまく行き、イメージとしては自国通貨を発行するのと同じような状態になりました。

他の言い方をすれば、元々価値がついていないものに対して、「この国では何円分します」「この国ではこの価値ですよ」ということを確定させて流通させるということが可能になるかもしれませんでした。ただ、結果的に暴落しました。

なので、とりあえず錬金術なんてものはないと思っていた方が投資をする上ではいいと思います。

また、力を加えずにずっと仕事をし続ける「永久機関」もないと思っていた方がいいです。壮大ですが、昔から人類は「電力やエネルギーの生成って無限にできるよね」ということを考えている人もいて、それをずっと研究していますが未だに作れていません。

そして錬金術も同じようなものだと思います。今後も挑戦するとか、いろんな話題が出るんだとは思いますが、そんな簡単なものではないと思っていた方がいいです。

まとめ

今後自分で情報収集するときに、人が発信しているのを見て簡単に「あ！これ稼げそう！」と思って資金を突っ込むのではなく、一旦自分の判断を入れてください。

あくまで選択肢が教示されているだけなので、それを見て自分がやるかどうかは「自分」で選びましょう。

そして今回、結構大きい事件だったので記事で扱わせてもらったのですが、おそらく今後は私以外にもYoutubeやブログ、SNSなどで詳細を発信してくれる方がいて、もっとわかりやすいと思うので、勉強のためにもそういう方達の発信を見ていただけたらと思います。

最後まで読んでいただきありがとうございました。

--- # 【BSC】Exploit多発！6月16日にトークン価格が暴落した事件について解説します 今回の記事では、BSCで6月16日に起きたExploitについて解説していきたいと思います。 IRONFINACEが暴落した日の日本時間だと1日前に発生した事件になります。 Defiを行っていく上で過去に起きた事件を調べる事は大切だと思っています。そのため自分にも起こりうる可能性があると考えながら、学びの一… 正規URL: https://3mikan.com/archives/1451 著者: みかん 公開: 2021-06-23T17:30:27.000Z 更新: 2021-10-19T03:54:46.000Z

今回の記事では、BSCで6月16日に起きたExploitについて解説していきたいと思います。

IRONFINACEが暴落した日の日本時間だと1日前に発生した事件になります。

Defiを行っていく上で過去に起きた事件を調べる事は大切だと思っています。そのため自分にも起こりうる可能性があると考えながら、学びの一つとして最後まで読んで頂ければと思います。

事件の内容

何が起こったのかチャートで確認していきます。
※ケチャップトークンを用いています。

【BSC】Exploit多発！6月16日にトークン価格が暴落した事件について解説しますの説明画像

とても金額が下がり10分の１程になっています。

このように、ほぼ価値がつかないような状態にまでなりました。

Exploitについて

今回画像内の複数の箇所でExploitが起こりました。

有名な所で言うとCerberusやGaruda/CaramelsSwapなどがあります。

【BSC】Exploit多発！6月16日にトークン価格が暴落した事件について解説しますの説明画像

Exploitが発生する条件

Exploitには、発生する条件が２つほどあります。
※（細かく言うと他にもありますが大まかに2つ）

  1. トランザクションフィー（※deposit feeではない）が発生するトークン
    例）パンサー
  2. そのトークンの単体プール

この上記①②が条件になります。

例）５%のトランザクションフィーの場合

100depositしたらMasterChefに届くのは95トークン（5%トランザクションフィー）になります。
そしてMasterChefからWithdrawする際にもトランザクションフィーが発生します。
※つまり、本来ならユーザーが100トークン引き出せずに90.25しか引き出せません。

今回のExploitした内容は、単体プールに100トークンdepositして100トークンwithdraw出来てしまうといったものでした。本来であればトランザクションフィーが発生しますが、ユーザーが損失なく引き出す事ができた為、損失分の補填はMasterChefからされたという内容です。

MasterChef内のプールがほぼ空の状態に...

上記内容だけだと、Exploitを実行する側は何もメリットがありません。なぜならMasterChefに損失を出させているだけになるからです。

この攻撃自体では、MasterChefのプールがほぼ空になり（損失分の補填をしてしまったため）ましたが攻撃者は稼げていません。

この後の操作により、攻撃者は利益を得ていきます。

例）ブロック報酬として決められているのが100だとして、本来なら基本的にユーザーの割当の合計は１以下です。

ユーザー割当＝ユーザーのstake量／Poolのstake量
※この辺の内容を詳しくしりたい方は、『イールドファーミングの基礎知識』を見てみてください！

上記を踏まえて、先程の攻撃を繰り返し行うと、MasterChefの中身がなくなっていき、『Poolのstake量』はすべて攻撃者のstakeになります。

つまり攻撃者はプールのシェアの100%を取っている状態になります。

なので、既存ユーザーのstake量を考えると合計が１を超えます。となると、想定以上にmintされトークンがばらまかれた可能性が非常に高いです。
※mint＝トークンの新規発行

例）ブロック報酬が100あり、Aさんが1トークンstakeしている・Bさんが攻撃したとします。

Bさんが最後に0.001トークンだけstakeに残した場合。
▶Aさんの割当は、100／0.001＝100,000% になります。

そのため、Aさんは異常なブロック報酬になり大量に収穫できることになります。

コントラクトから読み取れる内容

最後がlpSupplyで終了しています。これは、プール内の合計のトークン量で割っていることを指します。なので、合計のトークン量が重要になります。

もしここが、ユーザーが今までに入れたトークンの合計量や違う計算方法だとしたら防げていた可能性があったかもしれません。

しかし、今回の場合は実際のプール内の合計トークン量だったため、LpSupplyをとても小さくした場合、プールパーシェアがとても増え本来1を超えないものが1を超えることになります。

【BSC】Exploit多発！6月16日にトークン価格が暴落した事件について解説しますの説明画像

リファラルプランにおけるExploit

Cerberusでは紹介制度を利用していました。

コントラクトにある、commissionAmountこれにより紹介された人が沢山トークンをファームできることによって紹介者にも大量に入りました。そのため、売り圧がもっとかかることになりどんどん価格が下がったということになります。

【BSC】Exploit多発！6月16日にトークン価格が暴落した事件について解説しますの説明画像

まとめ

Exploitは潜在的には条件の①②に当てはまるものに該当するものになります。トランザクションフィーが発生するトークン。そのトークンの単体プールであれば起こる可能性が十分にあります。

トークンの単体プールに入れる際に、トランザクションフィーを取っていれば問題ありません。
（例）100depositして100引き出せないモノ。

以前紹介したモカトークンも該当するものでしたが、これは問題がないです。理由は、モカトークンはトランザクションフィーが発生しないホワイトリストっていうを設定しています。

ユーザーに送った場合は発生しますが、プールに入れた場合は発生しない振り分けをしています。だからといって他の事件を起こさない可能性はないですが、ホワイトリストみたいなものの設定をしてあるかを確認することは大切だと思います。

以上が、BSCで一気に起こったExploitでした。運用していく上で対策の一つとして覚えて頂ければと思います。

--- # 【BSC】PancakeBunnyハッキング事件！トークン価格が100分の1に暴落した原因を徹底調査。次回の対策に役立ててください！【DeFi】 今回は5月20日に起こったPancakeBunnyハッキング事件について解説をしていこうと思います。 まずは事件の内容の詳細を簡単に説明して、その事件がどうやって起こったのか原因調査の解説をしていきます。 PancakeBunny事件情報 基本的にはVaultsがメインとなっています。元々話題になっていて、… 正規URL: https://3mikan.com/archives/1309 著者: みかん 公開: 2021-06-19T06:48:47.000Z 更新: 2021-10-19T03:54:18.000Z

今回は5月20日に起こったPancakeBunnyハッキング事件について解説をしていこうと思います。

まずは事件の内容の詳細を簡単に説明して、その事件がどうやって起こったのか原因調査の解説をしていきます。

PancakeBunny事件情報

基本的にはVaultsがメインとなっています。元々話題になっていて、ユーザーも多かったということもありTVLが非常に多く集まっていてので、狙われやすくなっていたと思われます。

【BSC】PancakeBunnyハッキング事件！トークン価格が100分の1に暴落した原因を徹底調査。次回の対策に役立ててください！【DeFi】の説明画像

事件直後、出金停止になっており、もしかしたら出金できていないだけなのかもしれませんが、現在の(5月23日時点)で$1,051,987,622のとなっています。

他のVaultsを知っている人からすると、この数字はかなり大きいことがわかります。

ちなみに、ハッキングと言われていますが、厳密に言うとハッキングではなく事故です。「Exploit(エクスプロイト)」などいろんな表現がありますが、分かりやすく言えば「事故」です。普通にコードに不備があったという感じです。

DeFiをやっていると、ハッキング・ラグ・エクスプロイトがごちゃ混ぜになって話をされることが多いので、この記事のタイトルにはあえて「ハッキング」と入れていますが、今回のPancakeBunnyの事件については、厳密にいうと、開発者のPCに入り込んだり、サーバーを乗っ取るようなハッキングではありません。

では何が原因で事件が起きたかというと、コントラクトが全て公開されているので「BscScan」というトランザクションを全て保存しているところに処理が全て残っており、その穴を突かれた。といった感じです。なので正直、ある程度の知識と技術があれば、やろうと思えば誰でもできます。

このように、最終的に今回は悪意を持った人が突いてきたことで起きた事件です。なので、知識・技術・資金力さえあれば誰でもやろうと思えばできるので厳密にいうとハッキングとは言えません。

チャートで解説

赤枠の部分が、5月20日のエクスプロイトによる下落になります。一瞬で＄200から＄3まで下落しました。

【BSC】PancakeBunnyハッキング事件！トークン価格が100分の1に暴落した原因を徹底調査。次回の対策に役立ててください！【DeFi】の説明画像

ただ、よく見てみると＄147から＄200まで一旦上昇していることがわかります。これもエクスプロイトの一部です。

【BSC】PancakeBunnyハッキング事件！トークン価格が100分の1に暴落した原因を徹底調査。次回の対策に役立ててください！【DeFi】の説明画像

現在、事件後と比べると徐々に回復はしていますが、仮想通貨全体でかなりの下落が起こっているので、その波にも巻き込まれているようです。

なので、この状況だとアルトコインも持ちにくいですし、特にBUNNYなどの大手取引所に上場していないようなトークンは持ちにくいと思います。となると、BTCやETHなどを押さえておきたいという人が多いので、やはり「買い」は伸びにくいです。

とは言え、下落直後に広げた人は十分に利益になっているという感じです。私自身も買おうか悩みましたが、ポートフォリオにこういったトークンをあまり入れておらず、レンディングして運用することが多く、DeFiの主要なトークンよりマイナーなトークンはあまり持たないようにしているので買うのをやめました。

ちなみに、下の画像はPancakeBunnyのTwitterで公開されたツイート文ですが、「現段階ではとりあえずVaultsは危険にさらされていない」「プロジェクト自体は問題ない」と書かれています。

【BSC】PancakeBunnyハッキング事件！トークン価格が100分の1に暴落した原因を徹底調査。次回の対策に役立ててください！【DeFi】の説明画像

また、今回の事件は簡単にいうと、BUNNYの価格を誰でも操作できてしまう状態だったため、その穴を突かれて起きた事件(エクスプロイト)だったということも記載されています。

そして、Vaultが危険にさらされたわけではないので、ユーザーの資産が吹き飛んだり吹き飛んだりといったことはないと、簡単ですが記載されています。

とは言えBUNNYが絡んでいるVaultは、BUNNYの価格がかなり落ちたことで被害は受けています。

ただ、詳しい人から見ればVaultの機能自体が事故を起こしたわけではないとわかるので、このときにBUNNYを買い増しした人もいるかと思います。

事件のより詳細な解説・原因調査

Pancake Bunnyの公式アナウンスが一番わかりやすかったので、翻訳した内容をもとに、重要な項目だけ抜粋して解説していきます。

項目１の内容

【BSC】PancakeBunnyハッキング事件！トークン価格が100分の1に暴落した原因を徹底調査。次回の対策に役立ててください！【DeFi】の説明画像

まず１の項目では、「エクスプローラーはPancakeSwap（PCS）で資金を確保し、フラッシュローン攻撃を実行しました（以下、「フラッシュ」と呼びますが、一連の流れは1回の取引で行われました）。」と記載されています。

ちなみにフラッシュローンは、いろんなところで出てくる用語ですが、簡単にいうと「借りて返す」というトランザクション処理を１回のトランザクションで行っているという意味です。

フラッシュローンで調べてもわかりにくかったりするので、アービトラージだと考えるといいです。

項目６の内容

【BSC】PancakeBunnyハッキング事件！トークン価格が100分の1に暴落した原因を徹底調査。次回の対策に役立ててください！【DeFi】の説明画像

６の項目では、「ステージ5で新たに作成されたBUNNY/BNBでは、BNB価値が約2,324,152BNBと算出され、結果として6,972,455BUNNYが発行されました。」と記載されています。

詳しく解説すると、ステージ５で新しく何か作成されていたときに、本来ならBNBの価値は１BNBのはずが計算のバグがあり、2,300,000BNBと計算されてしまった。そのため、一つのトークン価値が230万倍に跳ね上がってしまったという内容になります。

こうなると、BNB-BUNNYのペアを持っていた場合、BNBの価格が跳ね上がれば、その相方のBUNNYのトークン数量が増えます。そして数量が増えたときに売られることで攻撃者の利益となってしまうのです。

じゃあ、そもそもなぜ2,300,000BNBまで跳ね上がるようなことが起きたのか？

その理由は別のページに記載されています。

参考ページURL　(9項目目になります)
https://slowmist.medium.com/slowmist-pancakebunny-hack-analysis-4a708e284693

項目９の内容

【BSC】PancakeBunnyハッキング事件！トークン価格が100分の1に暴落した原因を徹底調査。次回の対策に役立ててください！【DeFi】の説明画像

９の項目では、「valueOfAssetの計算では，WBNB-BUNNYプールのWBNBのリアルタイム数を2倍してWBNB-BUNNYのLPの総数で割ったものを使って，1枚のLPの価値を計算しています（valueInBNB）。しかし、ステップ7以降では，WBNB-BUNNYプールのWBNBの予想外の量が大幅に増加していることがわかり，1枚のLPの価値を計算する際にBNBに対して非常に高い価格になっています。」と記載されています。

こちらも詳しく解説すると、「Value Of Asset」というプログラムの関数があり、この「Value Of Asset」はWBNB-BUNNYプール内のWBNBのリアルタイム数に、まず２をかけます。その後、総量で割って単一のLPの値を計算します。

この事件が起こった時、攻撃者はWBNB-BUNNY LPの中に、BNBを大量に突っ込むように攻撃を仕掛けていました。

この状態で、リアルタイム数に２をかけ、出た数に対してLPの総量で割ることで、BNBの価格がおかしくなってしまい、また、これによって単一のLPの値を計算するときにBNBに比べて非常に高くなるということが起こりました。

そして今回、WBNB-BUNNY LPの計算方法がおかしかった関係で、BNBの価格が急上昇し、BUNNYのトークン数量が勝手に増やされて、そのタイミングで売られて攻撃者の利益になってしまったという事件が起こりました。

なので見方としては、BUNNYトークンが一方的に売られてしまったという感じです。その関係でBUNNYがとてつもなく下がりました。

結果論ではありますが、もし本当に公式アナウンスが発表している内容通りで事件が起きたならば、こんな簡単にできてしまう、事件が起きてしまうものかな？という気もします。

今後のBUNNYと補填の話

トークン価格に関して

私個人の予想としては、割とすぐに回復するんじゃないかなあと思っています。

なぜかというと、BUNNYトークンの価格が下げられただけの話であって、他のValueなどの機能は普通に使えますし、ということはValueの売り上げもそのまま使えるはずと思っています。

それに、今回のエクスプロイトを受けてBUNNYが何も対策をしないわけがないですし、Buyback/Burnなど、売り上げの中から出していくんだろうなという気はしています。ユーザーも多くTVLも非常にたくさん集まっているので問題ないと見ています。

とは言え、今現在仮想通貨の相場全体が下落しているので、その影響を受けてなかなか戻りにくいという思いがけない壁が現れてはいます。

補填に関して

【BSC】PancakeBunnyハッキング事件！トークン価格が100分の1に暴落した原因を徹底調査。次回の対策に役立ててください！【DeFi】の説明画像

「Go Forward Plan」というタイトルで発表されています。mediumに出ているので、補填の内容が気になる方は下のリンクから直接確認した方がいいかと思います。

補填に関して

補填の内容を大まかに解説すると、pBUNNYというトークンをエクスプロイトの前のスナップショット、トークンホルダーに対して行います。とい言うふうに記載されています。

そして、成功報酬についても記載されているのですが、pBUNNYを持っている人の補填をするために新しい報酬プールを作りますと記載されています。その報酬プールの資金源というのはVaultの成功報酬です。なのでPancakebunnyの利益から出す、という感じです。

個人的には、ここらへんの補填の仕方やトラブルに対する姿勢が良いな。と思っています。それに対応が早いというのも評価できます。

ちなみに、pBUNNYのAirdropなどが既にPancakebunnyのプールのページ表示されているので、まだ気付いていない人がいたら早めに確認してみてください。

【BSC】PancakeBunnyハッキング事件！トークン価格が100分の1に暴落した原因を徹底調査。次回の対策に役立ててください！【DeFi】の説明画像

注意喚起

ハッカーになろう！

DeFiのジャンルは全てSmartcontractというものでコードが公開されています。コードが公開されているということは、詳しい人間が見れば、いつでもハッキングできる状態(今回の場合で言うとエクスプロイトができる状態)です。

そんな中で私たちは自己防衛していかないといけません。なので、自分たちがアタッカー側だったらどう考えるかな？と言うことを頭に入れて動いていかないといけません。

自分たちでセキュリティーの穴を見つければ、そのプロジェクトを使わなければ良いだけの話なので、気づいたときには、できれば周りの人にも発信して教えてもらえたらと思います。

規制のない世界では自衛するしかない

DeFiでは誰も守ってくれません。今回の場合で言うと補填案は出ましたが、実際これまでは補填がないことがたくさんありましたし、そもそも運営が持ち逃げしているパターンもあったので自衛するしかありません。

なので、100%人に頼りっきりにならずに、自分でも守ることができるようになれば被害に遭うことも防げると思います。

信頼しすぎない

監査や提携先があるからといって信用しすぎないことが大切です。

監査団体のTechrateなど、そもそも信用性があるのかどうかも怪しいです。監査があるからといって飛ばないわけではないですし、セキュリティーホールがあるわけでもないです。

また、提携先が大きいからといって飛ばないわけでもありません。そう言ったところを肝に命じておきましょう。

まとめ

今回の事件を振り返ると、エクスプロイトの原因は、PancakeBunny価格の評価の部分に不具合があり、そこを突かれてBUNNYが一方的に売られたという内容でした。

自分たちで穴を見つけて何かしら対策ができたら被害に遭うことを防げますが、意外と信頼しきっちゃている人も多いので、今後こういった経験を通して各自賢くなっていって自分で穴を発見できるようになるしかないんじゃないかなあと思っています。

今回の事件はいいお勉強だったと思って、これからの仮想通貨の運用に役立ててもらえたらと思います。

最後まで読んでいただきありがとうございました。

--- # 【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】 今回は、レンディングプロトコルであるAAVEの使い方について、Matic Networkで紹介していきます。 レンディングプロトコル とは？ 名前の通りレンディングができるプロトコルです。 具体的に何ができるかというと、Supply(預ける)とBorrow(借りる)の２つができます。言い換えると、誰かが預け… 正規URL: https://3mikan.com/archives/1305 著者: みかん 公開: 2021-06-13T15:33:53.000Z 更新: 2021-10-19T03:54:11.000Z

今回は、レンディングプロトコルであるAAVEの使い方について、Matic Networkで紹介していきます。

レンディングプロトコル とは？

名前の通りレンディングができるプロトコルです。

具体的に何ができるかというと、Supply(預ける)とBorrow(借りる)の２つができます。言い換えると、誰かが預けたものを借りることができたり、自分が預けて自分で借りるということもできます。

また、BTCやETHなどスワップせずに持っておきたいトークンがある場合には便利です。例えば、今回のケースで言うと、Maticというネットワークトークンがあり、何か運用したい場合にはMaticをスワップしてクイックに変えないといけません。

ただ、この操作をした後にMaticの価格が上がった場合、「もったいないことした」というパターンになることもあります。

特に今後もMaticを持っておきたいという人にとってはスワップしたくない人もいると思うので、そういう時に使える方法を今回紹介していきます。

簡単な流れの説明としては、Maticを預けて、他のトークンを借りて運用すると言った感じです。ちなみにクイックは借りられません。この方法はホールドしておきたいトークンがあるときに便利です。

AAVEの使い方

まずAAVEを開き右上の「預入」をタップして「MATIC」をタップします。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

数量を入力して「入金」をタップします。今回は260預けます。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

「確認」をタップします。これで預け入れ完了です。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

反映されると下の画像のように表示されます。すでに担保の設定になっているので、この状態で他のトークンを借りることができます。

これから借り入れの操作手順を説明します。

今回はお試しで操作しているのでMATICを借ります。

まずは右上にある「借入」をタップして、その後数量を入力して「Continue」をタップします。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

金利のタイプを選び、「Continue」をタップします。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

「承認する」をタップします。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

「確認」をタップします。これで借入操作の完了です。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

ちなみに、MATICの運用に関してですが「Polycat」にVaultsがあるのでそこでMATICを預けることができます。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

続いて、返済操作を説明していきます。

まず「ダッシュボード」をタップして「返済」をタップします。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

数量を入力して「Continue」をタップします。今回の数量はMAXにします。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

「返済」をタップします。これで返済が完了です。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

次に、このまま引き出したい場合は「出金」をタップします。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

数量を入力して「Continue」をタップします。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

「出金」をタップします。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

「確認」をタップします。これで出金操作が完了です。

【Matic】AAVEの紹介！メジャーなレンディングプロトコルの使い方を解説・現在はボーナスでMaticがもらえます！【DeFi】の説明画像

以上が、一通りの使い方になります。

AAVEの対応ネットワーク

AAVEの対応ネットワークはETH(Ethereum)とMatic(Polygon)です。

ETHは早いうちからあったレンディングプロトコルなので、話題になっていて、そこにMaticも対応してくれたという感じです。

レンディングプロトコルの注意点

過去の事件を確認する

私が扱っている内容はBSCやVenusの話題が多いのですが、レンディングプロトコルですでに起きている事件はちゃんと各自で確認しておいたほうがいいです。

なぜかというと「狙われやすい」というのがいちばんの理由だからです。というのも、TVLが集まりやすいので、狙われやすく実際に事件が何回か起きています。

絶対に安全とは思わずに、どういう事件が起きているのかを確認しておいてください。

プロジェクトによって条件が違う

プロジェクトによっては、使えるトークンや条件が違います。

今現在、把握している限りではMATICだとAAVEくらいしかレンディングがないのですが、プロジェクトによって「預けられるトークン」「借りられるトークン」「担保にできるトークン」が違います。

あともう一つは、Borrow Limitまでの割合(借りることができる上限の割合)が違います。AAVEでMATICを預けた場合は50%までしか借りることができません。

まとめ

AAVEの紹介をしてきましたが、興味のある方は一度自分でどんなものか触ってみることをお勧めします。

そして注意点でも話しましたが、レンディングプロトコルでは過去に事件が何回か起きているので必ず確認しておくようにしてください。

また、プロジェクトによって条件が全く違うので、今後レンディングプロトコルが増えてきたら、それぞれ違いを理解した上で利用してみください。

最後まで読んでいただきありがとうございました。

--- # 【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】 今回は、新しい仮想通貨のネットワークであるFantom(ファントム)というネットワークのトークンでDeFiができるので、その紹介をしていきます。 Fantom・FTMという単語を聞いたことがある人や、どんなものか気になる人は読んでみてください。 Fantomのネットワーク上でDeFiが誕生 少し前からFan… 正規URL: https://3mikan.com/archives/1115 著者: みかん 公開: 2021-06-03T19:16:01.000Z 更新: 2021-10-19T03:53:40.000Z

今回は、新しい仮想通貨のネットワークであるFantom(ファントム)というネットワークのトークンでDeFiができるので、その紹介をしていきます。

Fantom・FTMという単語を聞いたことがある人や、どんなものか気になる人は読んでみてください。

Fantomのネットワーク上でDeFiが誕生

少し前からFantomのネットワークでDeFiが開始され、2021年の4月28日時点で爆発的にトランザクション数(取引数)が増えています。(下記画像参照)

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

上の画像(トランザクションチャート)を見てもここ数日でDeFiにユーザーが流入していることがわかります。おそらくBinanceの出金メンテナンスもこれが原因だと思われます。

下の画像の詳細を見ても分かるとおり、2021/04/28時点で、約20万回のトランザクション(取引)があることがわかります。

すごいスピードで増えているので、乗りに乗っているなあ〜！という印象です。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

2.BSC(バイナンス スマートチェーン)との比較

FantomとBSCを比較した表をもとに、この中にある主要な項目をいくつか解説していきます。

TPS(Transaction per sec)

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

「TPS」とは、「１秒間あたりのトランザクション処理速度」のことを言います。

BSCは１秒間に300回の処理能力ですが、Fantomは１秒間に4500回以上の処理能力があります。

この数値に関しては、以前Raydiumのsolanaネットワークが同じように「うちはトランザクション処理能力が高いですよ〜」と言っていたものの、現在苦戦しているようなので、ひょっとしたらFantomもユーザーが増えてトランザクションなどのいろんな負荷が増えた場合、１秒間に4500回の処理能力が維持できなくなる可能性があります。

Validators(バリデーター)

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

「Validators(バリデーター)」とは、ブロックチェーンに記録されるデータの記録が正しいかどうかを検証するノード(コンピュータ端末)のことを言います。

なので、このValidators(バリデーター)数がBSCに比べるとFantomは約２倍あるということがわかります。

Node structure(ノードストラクチャー )

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

「Node structure(ノードストラクチャー )」とは、ざっくり言うと管理体制のことを言います。

FantomはDecentralized(分散型)、BSCはCentralized(中央集権型)と記載されています。

ちなみに、BSCが出てきた頃から言われていたことがあるのですが、BSCのプロジェクトは、中央集権型なのでほとんど管理者がいる状態です。DeFi(ディーファイ)と言われてはいますが、実際のところ厳密に言うと「管理者がいる」という意味合いで、CeFi(シーファイ)と位置付けられます。

Transaction cost(トランザクションコスト)

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

Transaction cost(トランザクションコスト)は、トランザクションにかかるコストのことを言います。

一回あたりのトランザクションコストはFantomが$0.00002、BSCが$0.06となっており、Fantomの方がとても低いことがわかります。

個人的な基本戦略

もともと私はBSC(バイナンススマートチェーン)をメインでやっていて、「ネットワークの主要トークンをしっかり持っておく」という方法でやっています。

例えば下の画像にもありますが、ETHの場合はETHとUNI、Solanaの場合はSOLとRAY、BSCの場合はBNBとCAKE、Fantomの場合はFTMとSPIRITとBOOになります。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

基本的にDeFiというのは、DeFiのプロジェクトやDeFiに参加してくるユーザーが増加するにつれてネットワークの主要トークンの需要が増えるので、わざわざマイナーなトークンを探さなくてもある程度の利益は出ると考えています。

実際、いざ自分で情報収集するとなると、BSCだけでも情報が膨大で大変ですし、それに加えてSolanaやFantomも…となると、わざわざマイナーコインを調べるというのは大変です。(全く調べないというわけではありませんが。)

なので、戦略が定まっていない人や、何を選べば良いのかわからない人・不安な人は、「ネットワークの主要トークンをしっかり持っておく」という方法である程度の利益は出るので、慣れるまではこの方法で試すのも良いと思っています。

4.FTMのDeFiの始め方

ここからはFTMのDeFiの始め方について画像付きで解説していきます。

流れとしてはこんな感じです。

①Metamaskでウォレットを作成
②MetamaskにFantomネットワークを追加
③バイナンスでFTM(Fantom)を購入
④バイナンスからMetamaskにFTM(Fantom)を送金
⑤DeFiへ(fWallet/Spirit/Booを利用)

①Metamaskでウォレットを作成

ここのやり方については、いろんなところで紹介されているので画像での解説は割愛します。

簡単にいえば、Metamaskのサイトを開いてウォレットを作るだけです。

②MetamaskにFantomネットワークを追加

まず、Metamaskの設定ページを開きます。

その後、右上にある「？」マークがついているボタンをタップして「カスタムRPC」をタップします。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

次に、空欄に情報を入力していきます。ここに入力する情報はFantomのサイトでMetamaskの設定方法が記載されています。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

下にスクルールすると空欄に入力する情報が記載されているので、それを空欄にコピペしていきます。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

接続が完了すると右上に「？Fantom Opera」と表示されます。コレで接続が完了です。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

③バイナンスでFTM(Fantom)を購入

Binanceを開いて「トレード」をタップして「クラシック」をタップします。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

USDTでFTM(Fantom)を購入します。右上にある検索窓で「ftm/usdt」と入力すると、検索窓の下に「FTM/USDT」と表示されるのでそこをタップします。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

下にスクロールして「マーケット」をタップします。今回は全額購入するので、バーを一番右まで選択して、最後に緑色の「購入」ボタンをタップします。

ちなみに、ある程度分かる方はマーケットではなく指値で購入するのも良いです。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

以上で購入が完了です。

試しに、BinanceのWallet概要を確認してみると、ちゃんとFantomが追加されていました。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

④バイナンスからMetamaskにFTM(Fantom)を送金

BinanceでWallet概要ページを開きます。

右側にある「出金」をタップします。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

左側にあるタブから「FTM」を選択します。

続いて、受取人のFTMアドレスの欄に「Metamaskのウォレットアドレス」をコピペして、「FTM」をタップして送金します。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

⑤DeFiへ(fWallet/Spirit/Booを利用)

SPIRIT、BOOをステーキングしていきます。どちらかひとつでも良いですし、両方利用するのも良いです。今回は、SpiritSwapサイトでのSPIRITの利用方法を解説します。

ちなみに、紹介程度にこちらの画像はSpooky Swap(BOO)のサイトになります。ハロウィン感があって、デザインもかわいいですね。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

では早速、Spiritの利用方法手順の解説をしていきます。

まずはSpiritSwapのサイトを開いて、右上にある「Connect」をタップします。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

「Metamask」をタップします。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

続いて左にある「Trade」をタップして「Exchange」をタップします。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

右側にあるタブからFTMとSPIRITを選択します。その後、数量を入力してFTMをSPIRITに変更してLPを組んでいきます。

全て入力したら下にあるボタンをタップします。これでLPが組めました。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

LPを組んだら画面左上にある「Farming」をタップして「SPIRIT-FTM LP」のところにステーキングします。

ステーキングのやり方や、LPの組み方など、基本的にBSC(バイナンス スマートチェーン)とやり方が全く同じなので割愛します。不安な方は、他の記事や3MIKANの公式YouTubeで紹介しているので、そちらを見てもらえたらと思います。

参考↓
【DeFi】LPの作り方・解体・インポート・変動損失などの注意点を徹底解説！バイナンスチェーン・PancakeSwap【BSC】

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

fWallet(エフウォレット)の紹介

LPを組んでステーキングする手順を解説してきましたが、fWalletからステーキングすることもできます。

操作内容的にみると、慣れていない人は分かりにくいかなと思います。

基本的には、いくら預けるのか数量を入力し、バリデータを選び、トークンを預けるといった操作内容になります。

【FTM】Fantom・SpiritSwap・SpookySwapのDeFiの始め方！新しいFTMネットワーク・基本戦略などなど【DeFi】の説明画像

以上がFTMのDeFiの始め方の解説になります。

解説してきた通り、ステーキングの主要な運用方法としてはfWallet・Spirit swap・Spooky Swapの３つのうちどれかになると思います。

5.まとめ

今回は、新規ネットワークであるFTM(Fantom)によるDeFiを紹介しました。

現状ではネットワークの主要トークンは比較的伸びやすく、どの通貨を運用しよう悩む方や不安な方は、まずは主要トークンを運用してみてはいかがでしょうか。

ただ「絶対にうまくいく！」という保証はないので、そこは自己責任で行うようにしてください。

最後まで読んでいただき、ありがとうございました。

--- # 【DeFi】CreamFinanceの紹介！レンディングプロトコルの使い方を解説 今回の記事では、レンディングのプロトコルであるCreamFinanceについて解説していきたいと思います。 今までに紹介したレンディングのプロトコルの、【Venus】【DEFIPIE】と同じような感じです。 紹介となるとメリットが多くなりがちです。そのため最後の注意事項までしっかり読んで頂ければと思います。… 正規URL: https://3mikan.com/archives/1172 著者: みかん 公開: 2021-05-29T12:18:35.000Z 更新: 2021-10-19T03:53:31.000Z

今回の記事では、レンディングのプロトコルであるCreamFinanceについて解説していきたいと思います。

今までに紹介したレンディングのプロトコルの、【Venus】【DEFIPIE】と同じような感じです。

紹介となるとメリットが多くなりがちです。そのため最後の注意事項までしっかり読んで頂ければと思います。

レンディングプロトコルとは？

Supply（預ける）Borrow（借りる）ことができるの仕組みのこと。

預けた場合の金利と借りた場合の金利に差があるので預けた側は金利を貰うことができ、借りた側は金利を払う必要があります。その差額がレンディングプロトコルの収益になります。

どういう時に利用するのか


BTC/ETHなどのスワップしないで持っておきたいトークンがある場合有用。普通であれば、交換しないといけないトークンですが、同時に買い戻せなくなるリスクがあると思います。それをヘッジできるのが、レンディングです。

レンディングを使った運用方法

先程伝えたレンディングですが、こちらを利用して運用している人もいます。

やり方は難しいですが、運用方法の一つとして下記動画を参考にして頂ければと思います。

https://youtu.be/4PUwIJAuzyo

CreamFinanceの使い方

左側が預ける側になります。右が借りる側になります。

例）BNBを預けると5.58％の年利になり、借りている場合は14.65％の年利をつけて返す必要があります。
預けておいて運用することも可能です。

【DeFi】CreamFinanceの紹介！レンディングプロトコルの使い方を解説の説明画像

今IOTXという自分自身でもよく分かっていないのを預けています。

預けると、Collateralというボタンが追加されて上部に表示されます。
担保に設定するという設定になり、ONにしたりOFFにしたりできます。

ONにしていると、その金額分が担保になり何か他のトークンを借りることが可能です。

【DeFi】CreamFinanceの紹介！レンディングプロトコルの使い方を解説の説明画像

預ける方法

①預ける金額を入力後Supplyをクリック。

【DeFi】CreamFinanceの紹介！レンディングプロトコルの使い方を解説の説明画像

※初めて預ける場合はEnableを押すとSupplyのボタンに切り替わります。

【DeFi】CreamFinanceの紹介！レンディングプロトコルの使い方を解説の説明画像

②CollateralをONにする

※最初はCollateralがOFF状態で担保になっていない状態です。
これだと、トークンを借りる割当に使えないです。

【DeFi】CreamFinanceの紹介！レンディングプロトコルの使い方を解説の説明画像

③Collateralで完了です。

※トランザクション待ちがある為、待機時間が少し長めになります。

【DeFi】CreamFinanceの紹介！レンディングプロトコルの使い方を解説の説明画像

借りる方法

①数字を入力し、Borrowをクリック

Borrow Limit：借りれる上限
※上限を抜けると勝手に精算されます。

精算されるというのは、トークンの一部がSwapしたことと同じになります。
IOTXの返済義務が無くなる代わりに、担保が一部消えます。

【DeFi】CreamFinanceの紹介！レンディングプロトコルの使い方を解説の説明画像

これで10借りることができました。

【DeFi】CreamFinanceの紹介！レンディングプロトコルの使い方を解説の説明画像

返却方法

①Repayをクリック。
※返済しないと行けないIOTXが増えている為、IOTXから追加して完済してください。

【DeFi】CreamFinanceの紹介！レンディングプロトコルの使い方を解説の説明画像

担保の金額を抜く方法

①Withdrawをクリック

※Collateralをオフにしてもいいですが、オンのままでも抜くことが可能です。

【DeFi】CreamFinanceの紹介！レンディングプロトコルの使い方を解説の説明画像

CreamFinanceの対応ネットワーク

Marketの見方含め対応ネットワークを紹介します。

Ethereum/Iron Bank/BSC/Fantomが利用できます。
※特にFantomで使えるレンディングプロトコルが少ないので、Creamを利用してFantomも運用しています。

【DeFi】CreamFinanceの紹介！レンディングプロトコルの使い方を解説の説明画像

Total Supply：合計の預け入れ金額
Supply APY：預け入れた場合の金利
Total Borrow：合計の借り入れ金額
Borrow APY：返済の金利

【DeFi】CreamFinanceの紹介！レンディングプロトコルの使い方を解説の説明画像

全部のトークンが見れることで何が良いかと言うと例を用いて説明します。

預け入れられている金額に対して、借りられている金額が多いと返済金利が上がります。
利用率が上がると金利は上がります。これが、レンディングプロトコルの基本的な仕組みです。

【DeFi】CreamFinanceの紹介！レンディングプロトコルの使い方を解説の説明画像

このように、マーケットを見ることで安心材料にして頂ければと思います。

自分が借りようとしているトークンの利用率が低ければ金利がそれほど上がらない。借りようとしているトークンの預け入れられているトークン量が多いほど、利用率が上がりにくいという見方もできるかと思います。

レンディングプロトコルの注意事項

  • Venusなど、すでに起きている事件は確認しましょう。
    主要なトークンが多い事や、TVL(合計資産)が集まりやすい為レンディングプロトコルは狙われやすいです。
  • プロジェクトによって扱えるトークンや条件が違います。
  • 預けられる／借りられるトークンが違います。
    Cream・Venus・Defi Pie・AAVEでもそれぞれ異なります。
  • 担保にできるトークンが違います。
    預けることができても、担保にできないトークンもあります。
    ※Creamの場合はないです。
  • BorrowLimitedまでの割合が違います。
    担保にした資産に対しての設定がサイトによって異なります。

利用してみたいという人は、それぞれの違いなどを把握し、今までどんな事件が起こったのかリスクを調べた上で実際に使ってみることをおすすめします。

--- # 【DeFi】yieldwatch（イールドウォッチ）で資産管理！使い方・PRO機能・項目について解説 「Yieldwatch(イールドウォッチ)」とは、自分が組んでいるLPや、トークンの価値、ウォレットの合計の資産額が一発でわかるとても便利なツールです。 DeFiを利用している人の中には、一度は「Yieldwatch(イールドウォッチ)」という言葉を聞いたことがある方がいるかもしれません。 今回は「Yiel… 正規URL: https://3mikan.com/archives/578 著者: みかん 公開: 2021-05-11T16:46:19.000Z 更新: 2021-10-19T03:52:38.000Z

「Yieldwatch(イールドウォッチ)」とは、自分が組んでいるLPや、トークンの価値、ウォレットの合計の資産額が一発でわかるとても便利なツールです。

DeFiを利用している人の中には、一度は「Yieldwatch(イールドウォッチ)」という言葉を聞いたことがある方がいるかもしれません。

今回は「Yieldwatch(イールドウォッチ)」の見かた・使いかたについて解説していきます。

「Yieldwatch(イールドウォッチ)」の公式サイトはこちらから。

yieldwatch（イールドウォッチ）でできること概要

screen-2021-10-17-21.34.41

YieldwatchでできることはPRO機能も含めて

  1. ウォレット資産のサマリー（合計いくらかなど）の確認
  2. どのファームにいくら入れているのかの確認
  3. ファームのAPR確認（デイリーはPRO）
  4. ファーム詳細（PRO）

などがあります。正直「ファーム詳細」がPRO機能になった時点で他のツールの方が優秀です。

yieldwatchと類似の機能を持つサイト

yieldwatchと同様の機能を持っているサイトも紹介しておきます。

基本的にユーザーは1つのツールのみではなく複数のツールを使っていますし、サイトが落ちた場合などは他のサイト利用を余儀なくされます。

そのためにもyieldwatchのように自分の資産を確認できるサイトを知っておくことは大事です。

なお、私はDeBankなどがメイン利用になっています。

yieldwatchと同様機能のサイト

yieldwatch（イールドウォッチ）で確認できるプロジェクト

2021年5月現在、「Yieldwatch(イールドウォッチ)」で確認できるプロジェクト(DeFi)は10個です。

【DeFi】yieldwatch（イールドウォッチ）で資産管理！使い方・PRO機能・項目について解説の説明画像

上記画像にも小さく表示されていますが、

  • beefy.finance
  • PancakeSwap
  • Hyperjump Swap
  • bDollar Protocol
  • Jetfuel.Finance
  • Autofarm
  • PancakeBunny
  • ACryptoS
  • Venus Protocol
  • Cream Finance

が確認できます。

yieldwatch（イールドウォッチ）の使い方

Yieldwatchにログインする方法

まず「Yieldwatch(イールドウォッチ)」の公式サイトを開きます。

次に、検索窓に自分のウォレットアドレスを入力して、右隣にある双眼鏡マークをタップします。

【DeFi】yieldwatch（イールドウォッチ）で資産管理！使い方・PRO機能・項目について解説の説明画像

補足ですが、上記画面上に「Login PRO」とありますが、これはプロ版を利用している人専用のログインボタンになります。

プロ版を利用するには資金面などで一定の条件があるので、まずは初めてYieldwatch(イールドウォッチ )を利用する人向けに解説していきます。項目まで解説したら記事の後半でPro版の使い方について説明していきます。

なのでまずは「Login PRO」は気にせず、検索窓に自分のウォレットアドレスを入力してログインしてください。

ログインすると下記画面が表示されます。

【DeFi】yieldwatch（イールドウォッチ）で資産管理！使い方・PRO機能・項目について解説の説明画像
各項目の解説

①Wallet Balance
ここをタップするとウォレットの残高を確認できます。

②NET WORTH
全てのトークンや、組んでいるLPの合計

③TOTAL DEPOSIT
デポジットしている金額の合計

④TOTAL YIELD
収穫できている金額の合計

⑤TOTAL DEBT
債務の合計

⑥LP Vaults
どこにどのLPを組んでいるのか全て表示されます。

DeFiをやっていると、いろんなところにトークンを預けたり、LPを組んで預けたりしている人も多いです。

そのため預けている数が多ければ多いほど、いちいち各サイトにアクセスして確認しなければならず、預けている全体の合計を知りたい時に、結局のところ損をしているのか？利益が出ているのか？非常に分かりづらくなってしまします。

加えて、いろんなところに預けていると「そういえばどこに何を預けていたんだっけ？」と忘れたり分からなくなりがちですが、上の画像を見ても分かる通り、全ての総合計を表示してくれるので非常に便利です。

LPの詳細を確認する方法・項目解説

それぞれ預けているLPを確認する方法、各項目の見かたについて解説します。

まず、右上にあるインフォメーションマーク「ｉ」をタップします。例として今回は、左上にある、MSCとBNBのLPを元に解説していきます。ちなみに基本どのLPでも表示は同じです。

【DeFi】yieldwatch（イールドウォッチ）で資産管理！使い方・PRO機能・項目について解説の説明画像

「i」マークをタップすると下の画像のように、より詳細な数字が表示されます。

【DeFi】yieldwatch（イールドウォッチ）で資産管理！使い方・PRO機能・項目について解説の説明画像
各項目の解説

上記画像を元に各項目について簡単に説明します。これから解説する項目を見ておけば、自分が組んだLPがどんな状況なのかを把握することができます。

①Deposited Tokens」
LPを組んだ時の合計の元々のトークン数のこと。

②Token Changes
トークンの変動

③Current Tokens
現在のトークン数

④Current Price
現在の価格

⑤HODL Value
一番最初に預け入れた当時の合計額
（何もしないでトークンを持っていて、今売った場合の金額）

⑥Current Value
LPを組んで解体した時の金額
(トークン数に変動が起きたあとの金額)

⑦Impermanent Loss
一時な的損失(通貨を預けたために発生した機会的損失)

主要な項目は以上です。正確に把握したい人はPro版の使用をお勧めします。

yieldwatch（イールドウォッチ） Pro版の解説

ここでは、Pro版でしか利用できない機能や項目について解説しています。

まずは、トップページを開いて「Login Pro」をタップします。

【DeFi】yieldwatch（イールドウォッチ）で資産管理！使い方・PRO機能・項目について解説の説明画像

次にウォレットリストが表示されるので、選択します。

【DeFi】yieldwatch（イールドウォッチ）で資産管理！使い方・PRO機能・項目について解説の説明画像

右上に表示された小さい画面にある「署名」をタップします。

【DeFi】yieldwatch（イールドウォッチ）で資産管理！使い方・PRO機能・項目について解説の説明画像

するとウォレットアドレスが検索窓に入力されるので「双眼鏡ボタン」をタップしてログインします。

【DeFi】yieldwatch（イールドウォッチ）で資産管理！使い方・PRO機能・項目について解説の説明画像

ログインするとPro版ではないときと同じような表示になります。(下記画像参照↓)

ちなみに、右上にある「💲」ボタンをタップするといろんな単位で表示を変えて見ることができます。

【DeFi】yieldwatch（イールドウォッチ）で資産管理！使い方・PRO機能・項目について解説の説明画像

試しに、「$」から「BNB」の表示に変えてみます。

【DeFi】yieldwatch（イールドウォッチ）で資産管理！使い方・PRO機能・項目について解説の説明画像

上の画像２枚を見比べてみると、全ての項目で単位が変わり、数値も変化している事が分かりますね。

そして次に、再度＄表示に戻し、「 i 」マークをタップして、より詳しいLPの詳細をみていきます。

例として、左上にあるMSCとBNBのLPを見ていきます。

【DeFi】yieldwatch（イールドウォッチ）で資産管理！使い方・PRO機能・項目について解説の説明画像

上の画像を見ても分かるように全ての項目で表示がされています。

また、左上にある「Vault - Tx」「LP - Tx」のタブを表示することで「組んだLPが何％プラスになっているのか」など、より詳細な内容も確認することができます。

基本的なYieldwatch(イールドウォッチ)の使い方はこんな感じです。

では、どうやったらPro版を利用することができるのか？について解説していきます。

yieldwatch（イールドウォッチ） Pro版を利用する方法

Yieldwatch(イールドウォッチ)Pro版を利用するには、自分の資産額に見合った「WATCH」というトークンを購入することが必須です。

購入したWATCHは「トークンのまま持っておく」「トークンのままウォレットに入れておく」「LPを組んで持っておく」「LPをbeefyなどに入れておく」などしても大丈夫です。

ただ注意点として、WATCHを購入すればそれで良いというわけではなく、Yieldwatch(イールドウォッチ)で管理・把握したいトークン数(NET WORTHの数値)に応じたWATCHの購入が必要です。

例えば、＄5,000を把握したいなら＄５のWATCHを購入する、＄10,000を把握したいなら＄10のWATCHを購入しておかないといけないといった感じです。

なお、WATCHの価値や価格を把握したい場合は画面左上にある「Watch Value」をタップすると確認できます。

【DeFi】yieldwatch（イールドウォッチ）で資産管理！使い方・PRO機能・項目について解説の説明画像

yieldwatch（イールドウォッチ）のまとめ

Yieldwatch(イールドウォッチ)の使い方・Pro版の使い方について解説しましたが、正直なところWATCHが欲しくない場合は、無理にPro版にしなくても大丈夫です。

というのも、大きい額のウォレットを把握しようとすると、10万円分のWATCHを購入しなければならなかったりするからです。なので、Pro版にするかどうかは最終的にはご自身の判断で行ってください。

Yieldwatch(イールドウォッチ)の使い方についてはYouTubeでも紹介しているので、文章だと分かりにくいという方は動画も見てみてください。

最後まで読んでいただきありがとうございました。

https://youtu.be/6zLKpff9bvo
--- # 【DeFi】beefy.financeのやり方を紹介！複利運用の概要・BIFIトークンの特徴・使い方・実際の運用状況を解説【BSC】 今回はBSC（Binance Smart Chain, バイナンススマートチェーン）の中の自動複利運用アグリゲーターサービス(Vaults)であるBeefy.Financeについてまとめていきます。 PancakeSwapなどを利用していて、Compound（複利運用）を毎回押すのが面倒といった方に特におす… 正規URL: https://3mikan.com/archives/407 著者: みかん 公開: 2021-03-18T12:28:36.000Z 更新: 2021-10-19T03:51:45.000Z

今回はBSC（Binance Smart Chain, バイナンススマートチェーン）の中の自動複利運用アグリゲーターサービス(Vaults)であるBeefy.Financeについてまとめていきます。

PancakeSwapなどを利用していて、Compound（複利運用）を毎回押すのが面倒といった方に特におすすめのサービスになります。

https://3mikan.com/archives/240

なお、DeFiサービスとなりますので利用時には紛失リスクなどは自己責任でお願いいたします。

beefy.financeに関しては、動画でも紹介しているので動画のほうがわかりやすいという方は以下の動画を参考にしてください。

https://www.youtube.com/watch?v=BAzCrSrGKlY

Beefy.Finance（ビーフィー）の概要

1616052698378@2x

まずはBeefy.Financeの概要についてまとめてみました。

項目内容
名称Beefy.Finance（通称beefy）
ガバナンストークン$BIFI CoinMarketCap （執筆時は$2,425.47）
ジャンルValuts（自動複利運用最適化サービス）
URLhttps://app.beefy.finance/
チェーンBSC・Polygon・Fantom・HECO・AVALANCHE・HARMONY・ARBITRUM
監査状況Certikから監査済み

自動複利運用(Vaults)に関する補足

vaultsとは.009

「自動複利運用」というのが聞き慣れない方もいると思います。実際には造語の可能性もありますので補足で説明します。

まず、複利運用について考えていきたいのですが、わかりやすく月利30%（日利1%）で運用できる投資があったとします。

この場合、毎月の利益（30%分）を再投資すると複利運用になりますね。

ただ、このときに月末に再投資するのではなく10日,20日,30日と3回に分けて再投資するとどうなるでしょうか。つまり、10%利益が出る度に複利にするとどれくらいの差がでるのでしょうか。

この場合の計算は以下のような形になります。

月末に複利運用： 1.3倍(130%)

10日,20日,30日に複利運用：1.1(110%) x 1.1 x 1.1 = 1.331倍

このように複利運用の回数を増やすことで、運用パフォーマンスに差が出てきます。今回の例だと0.031倍分の差になります。

投資資金が100万円だとすると、31,000円もの差になります。更にこの差が毎月複利で膨らんでいく形です。

（実際には、日利は固定じゃなかったり、複利の際に手数料がかかったり（入出金手数料など）するのでここまで簡単ではないのです）

今回の例のように「1.3倍」と「1.331倍」だったらどちらがいいでしょうか。もちろん、「1.331倍」ですよね。

でも、10日ごとに複利運用をするのってめんどくさい...。

ところが、これを自動化してくれるのが自動複利運用なんですね。

Beefy.financeの最大の特徴：複利運用の自動化

DeFiはどこも日利換算で表記するほど利率が高いので、ほとんどのユーザーが複利運用しています。

PancakeSwapなどでもCompoundボタンを使って複利運用ができますが正直面倒ですし、これがCAKE-BNBのLPなどの複利になれば更に面倒です。

（$CAKEを収穫→半分を$BNBに変換→CAKE-BNB LPを作成→stake　という流れ）

参加しているユーザーなら「この作業がもっと楽になればいいのに...」と当然思うレベルのことで、実際にこの複利運用を自動化できるのでBeefyです。

実は自動複利運用は他のサービスもある

Beefy.FinanceはBSC上では自動複利運用のポジションをどんどん築き上げてきています。

実は、BSCにはautofarmという大きな自動複利運用サービスがあるのですが、後発組として頑張っているような感じですね。

autofarmとの違いは、扱えるLPの種類と、運用中にガバナンストークンである$DIFIが収穫できない点です。

Beefy.financeの特徴、他サービスとの違い

以下にBeefy.Financeの特徴についてまとめてみました。

Beefyの特徴
  • 自動複利運用の最適化（Vaults）
  • ガバナンストークンは$BIFIだが、他トークン・LPの運用で収穫はできない。
  • $BIFI所有者はプラットフォームへの提案を行う権利がある。
  • $BIFI用のpoolがあり、Beefyの運用時の引き出し・預け入れ手数料はそのpoolに還元される。
  • $BIFIはバイナンスに上場している

実際の運用時のスクリーンショットがこんな感じです。

50242838-ED3C-482F-894C-0A843239B27A

このAPYが複利計算のものです。牛さんの強みの利回りにはほんとに驚かされます。

19F846DA-9455-4EBC-BB01-662D90E9154F

20分でこのくらい（0.02$）増えていました。最近はドルで今の預け入れ金額が見えるようになったので更に便利になりました。

Beefy.financeの操作方法

Beefyの操作方法は至って簡単です。

Beefyの操作方法
  1. 預けたいトークンまたはLPを用意する
  2. Beefyの運用箇所を「APPROVE」する
  3. 預けたい数量DEPOSITする（全ての場合はDEPOSIT ALL）
  4. 引き出したい場合はWithdrawする

①預けたいトークンまたはLPを用意する

screen-2021-03-18-21.19.12

まずはトークンを用意するか、PancakeSwapなど指定の場所でLPを用意します。

②Beefyの運用箇所を「Approve」する

screen-2021-03-18-21.20.11

その後、Beefyにアクセスして、運用先の「APPROVE」ボタンを押します。

※この「APPROVE」は実はリスクを伴う重要な意味合いがあります。本格的にDeFiを利用する際にはしっかり理解することをおすすめします。

③預けたい数量DEPOSITする（全ての場合はDEPOSIT ALL）

screen-2021-03-18-21.22.23

数量を記入して「DEPOSIT」するか、「DEPOSIT ALL」で全て預け入れます。

基本的な操作はここで終了です。あとは放置しておけば自動で複利で回ります。

※預け入れ・引き出しには0.05%~0.1%の手数料がかかります。

④引き出したい場合はWithdrawする

screen-2021-03-18-21.23.25

引き出したい場合には数量を記入して「WITHDRAW」、または「WITHDRAW ALL」で全て引き出せます。

※預け入れ・引き出しには0.05%~0.1%の手数料がかかります。

Vaultsとは

Vaultsとは、利回りを最高にしようとする一連のアクションの自動化プロセスのことです。

月末に複利運用： 1.3倍(130%)
10日,20日,30日に複利運用：1.1(110%) x 1.1 x 1.1 = 1.331倍

先程例に出した途中で複利運用すると利率が良くなるという比較ですが、これを1日単位・半日単位・1時間単位とどんどん狭めて複利で回すと、利率は上昇していきます。

ただ、入出金の回数が増えればその分手数料もかかるので、複利の回数をいい塩梅で調整する必要があります。これを勝手にやってくれるのがVaultsだと思ってください。

Beefy.Financeの「Vaults」というサービスを使うと、仮想通貨100種類以上のイールドファーミングの複利運用を独自の戦略に基づいて、完全に自動化することができます。

Vaults運営側のメリット

vaultsとは.013

beefy.financeのような自動複利運用のプラットフォームをDeFiでは「Vaults（ボルツ）」という名称で呼んでいます。

Vaultsは複利運用をする上では非常に有用なサービスですが、これを開発する側にはどんなメリットがあるのでしょうか？

Vaultsの収入構造は投資信託などのファンドと非常に似ています。ユーザーとファームの間に入ることで、一部の運用報酬を得ています。（厳密には預け入れ手数料・出金手数料なども）

なので、Vaultsとしては多くの利用者がいたほうが報酬が増えていきます。

そもそも流動性の提供が必要な理由

そもそも、なぜトークンを預けたり、LPを預けたりすると増えて返ってくるのでしょうか。これの答えは、「流動性の提供が必要」という点にあります。

実はトークンやLPを預けているというよりも、DEXという管理者のいない暗号資産取引所に対して貸し出したり、LPを貸し出しているイメージが近いです。

DEXでは管理者がいないので、自分がしたい取引が約定するかが補償されていません。A→Bという交換をしたくても、DEX内にBトークンがゼロであれば交換ができません。

このときに、A⇔Bのペア（LP）を作って貸し出します。これが流動性の提供となり、このペアのおかげでA→BやB→Aというトークンの交換が可能になります。

DEX側としては、この流動性が多ければ多いほど取引がスムーズに行くのでその見返りとしてイールドファーミングという仕組みを用意して、メリットを提示しています。

https://3mikan.com/archives/2126

なぜDEXを利用するのか

DEX以外にも、運営会社や管理者がいる取引所も複数存在します。日本の国内取引所であるビットフライヤーやコインチェックは運営会社がいますよね。

こういった取引所は運営会社が流動性を担保しています。

DEXの場合には、こういった運営会社がいる取引所に比べて「手数料が低い（人件費分がかからないため）」「運営会社側のヒューマンエラーが起こらない」などのメリットがあります。

イールドファーミングの存在理由・流行る理由

DEXでは、流動性の提供が必要だと書きましたが、ただ「貸してください」では誰も貸してくれません。

そこで、手数料や報酬を還元するという仕組みを作り、貸主にメリットを提示しています。これがイールドファーミングです。

これによって、貸す側に報酬というわかりやすいメリットができ、「貸す」だけで報酬が得られてしっかり「返される（引き出せる）」ので人気が出ています。

（今回はインパーマネントロスなどには触れずに説明しています。実際には流動性による通過変動リスクがあります）イールドファーミングが流行る理由

Beefy.financeで注意すべきポイント

BeefyはCertikから監査を受けています。さらにバイナンスにも上場していることを考えると、ハイプや飛ばしのように、急にサイトが消えたりなどのリスクは低いと言えます。

とは言え、新興仮想通貨である以上リスクはありますので、以下にまとめておきます。（バイナンスにもイノベーションゾーンとして上場しています。）

  • 表記されているAPYは、トークン価値が下落した場合を考慮していません。トークン価値が下落した場合、元本割れのリスクがあります。
  • 表記されているAPYはリアルタイムで変動します。
  • Beefyのサーバーがハッキングなどされた場合には、資金損失リスクがあります。

Beefy.financeのまとめ

今回は自動複利運用サービス（Vaults）であるBeefy.Financeについてまとめました。

PancakeSwapなどのイールドファーミングに比べて、複利運用の手間が少ないので取り組みやすいかと思います。

自己責任の上で、この運用方法を試してみたいという方は是非試してみてください。

--- # 【おすすめ】DeBankの情報を網羅！できること・使い方・Revokeについて【DeFi】 私はDeBankが一番使いやすいですね。今のところ。 DeFiでの資産管理ツールって結構出てきましたよね...。基本的には「PRO機能」という名目でトークンを買わせるものが多いです。 しかし、DeBankの場合はトークンを買う必要も無いのにポートフォリオ管理ができて、Revokeもできて、トークンスワップも… 正規URL: https://3mikan.com/archives/3273 著者: みかん 公開: 2021-10-17T14:19:05.000Z 更新: 2021-10-19T03:49:06.000Z

私はDeBankが一番使いやすいですね。今のところ。

DeFiでの資産管理ツールって結構出てきましたよね...。基本的には「PRO機能」という名目でトークンを買わせるものが多いです。

しかし、DeBankの場合はトークンを買う必要も無いのにポートフォリオ管理ができて、Revokeもできて、トークンスワップもできるという良いことづくしです。

そんなDeBankについて詳細を伝えていきます。

DeBankとは

screen-2021-10-17-22.23.33

DeBankはウォレットの資産状況を確認できるツールです。DeFiでファームしている状況を確認することができます。

基本的な資産状況の見やすさと、トランザクション履歴・Revoke（後述）の機能が備わっているのでかなり人気のあるツールです。

私も最近ポートフォリオ管理をする場合はDeBankを使っています。

https://debank.com/

DeBankでできること

DeBankでできることを一通りまとめるとこんな感じです。

DeBankでできること
  1. ポートフォリオの管理
  2. ネットワーク絞り込み
  3. Revoke（Approveのキャンセル）
  4. トランザクション履歴の確認
  5. TokenSwap（DEXアグリゲーター機能）
  6. DeFiリスト・ランキング
  7. アドレスフォロー機能

わざわざいろんなサイトを開いて自分の損益状況を確認しなくても、DeBank上ですべて確認できるのでチェックだけならこのツールを見れば十分です。

収穫やUnstakeなどはできないので、その場合は実際にサイトを開く必要がありますがサイトへのリンクも貼ってあるので楽々飛べます。

対応しているDeFiプロトコルもリスト形式で掲載されています。

DeBankの対応ネットワーク

screen-2021-10-17-22.31.43

DeBankでチェックできるネットワークの一覧です。このネットワークのポートフォリオのみに絞り込んで確認するとが可能です。

  • Ethreum
  • BSC
  • Polygon
  • xDai
  • Fantom
  • OKExChain
  • HECO
  • Avalanche
  • Arbitrum
  • Optimism
  • Celo

ある程度のユーザー数がいるネットワークは基本的に対応していますので、「自分のネットワークは使えなくて困る」ということは少ないでしょう。

DeBankの使い方

screen-2021-10-17-22.36.06

それでは実際のDeBankの使い方を解説していきます。まずは「Connect Wallet」からウォレットを接続しましょう。

または、他人のウォレットでウォレット接続ができない場合にはウォレットアドレスを入力しましょう。

この操作ができている前提でそれぞれの使い方を紹介します。

ポートフォリオ管理

screen-2021-10-17-22.39.00

ウォレットを接続するかアドレスを入力すると一番最初に開かれるページがポートフォリオ管理のページです。

自分の資産状況やファームの運用状況が確認できます。収穫前のトークンの利益分も表示してくれます。

ネットワーク絞り込み

screen-2021-10-17-22.31.43-1

表示されているネットワークをクリックすると、そのネットワークに絞り込んで資産状況をチェックできます。

グレーになっているネットワークは自分の資産が入っていないネットワークです。

複数ネットワークで運用しているとファームの運用状況がわかりにくくなりがちなので、絞り込んで確認することをおすすめします。

Polygonなどの重たいネットワークの場合、情報の更新に時間がかかるケースがあります。

Revoke（Approveのキャンセル）

Dappを触っているとトークンのApproveを行うことがあると思います。これは必要な処理で基本皆さんが行うものです。

このApproveは「他のコントラクトが自分の資金を動かすことを承認する」意味になります。これによって、ファームのDeposit処理などを行うことができます。

しかし、この承認は同様に「盗む」ことにも使えてしまいます。Deposit処理のようにあなたのウォレットからトークンを他の人間に送りつけることができます。

これを防ぐためにはApproveのキャンセルであるRevokeをする必要があります。DeBankではこのRevokeを行うことができます。

screen-2021-10-17-22.45.36-1

ポートフォリオ管理の「Approval」をクリックし、キャンセルしたいApprove処理を「Decline」します。

この時いつもどおりウォレットの確認画面が出てきますので「確認」を押して進めてください。

Revoke処理の中身は「valueが0のApprove」処理になります。トークンを0個しか動かせないApprove処理で上書きするということです。

つまり、実際の処理内容はApproveとほとんど同様です。なのでウォレットの確認画面が出てくるわけです。

トランザクション履歴の確認

screen-2021-10-17-22.51.26

「History」をクリックすると自分のトランザクション履歴を確認できます。各行をクリックするとexplorerに飛べるので便利です。（BSCならBSCScan）

今までのすべてを閲覧できるわけではなく、直近の何件かのみ見れるので注意してください。

Token Swap（スワップ）

screen-2021-10-17-22.54.23

DeBankにはトークンスワップ機能もついています。これはDeBankが用意したDEXではなく、DEXアグリゲーターの機能なのも便利な点です。

DEXアグリゲーターについての解説は最も有名な「1inch.exchange」の記事を参照してください。使い方もほぼ同様で各行の「Swap」を押すだけです。

https://3mikan.com/archives/574

簡単に言うと「一番良いレートで交換させてくれる取引所」です。

※1inchは自動で最適ルートをおすすめしてくるのでクリックするだけですが、DeBankは自分で選ぶ必要があります。

DeFiリスト・ランキング

screen-2021-10-17-22.58.40

DeBankでは他のDeFiプロトコルを調べることもできます。私はずっとDappRadarを使っていたのですが、DeBankに乗り換え始めています。

１３考える
こあら

DeFiリストの使いみちがイマイチわからない…

という方に私が普段使っている際の使い方をお伝えしておきます。

  • テレグラムやdiscordなどで新しいトークンを聞いたときに「どれくらいのユーザーがいるのかを調査する」
  • 新しいDeFiプロトコルが出てきてないか調べる
  • 運用しようとしているトークンが上位プロトコルで信頼に値するか調べる

などになります。

アドレスフォロー機能

screen-2021-10-17-23.01.49

他人のアドレスを見ている時限定ですがDeBankには「アドレスフォロー機能」があります。

この機能を使う場合には「Rabby」というブラウザ拡張機能が追加で必要になります。

「どうしても◯◯さんのウォレットをストーカーしたい！」という場合には使ってみましょう。

DeBank類似のツール

DeBankとほぼ同機能を持つツールを紹介しておきます。私は最近はDeBankが一番使いやすいです。

時期によったり見たい項目によって使い分けするのがいいと思います。

  • ApeBoard
  • farm.army
  • JDIYIELD
  • yieldwatch
https://3mikan.com/archives/1208
https://3mikan.com/archives/1782
https://3mikan.com/archives/827
https://3mikan.com/archives/578

DeBankのまとめ

DeBankは資産管理ツールとしてはかなり出来がいいと思います。とりあえずこのツールをブックマークしておけば毎日のチェックには十分でしょう。

ぜひ自分で一度チェックしてみてください。

https://debank.com/

--- # 【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】 今回は最近注目されているSolanaネットワークのRaydium(レイディウム)について、メリット・デメリット、Raydium(レイディウム)とはどんなものなのか？解説していきます。 最近ではTwitterなどで有名な仮想通貨系インフルエンサーの方々がRaydium(レイディウム)の魅力についてツイートした… 正規URL: https://3mikan.com/archives/610 著者: みかん 公開: 2021-04-14T16:56:54.000Z 更新: 2021-10-19T03:48:23.000Z

今回は最近注目されているSolanaネットワークのRaydium(レイディウム)について、メリット・デメリット、Raydium(レイディウム)とはどんなものなのか？解説していきます。

最近ではTwitterなどで有名な仮想通貨系インフルエンサーの方々がRaydium(レイディウム)の魅力についてツイートしたり、実際に運用しているなど、非常に人気が高まり注目されています。

ただ「Raydium(レイディウム)ってそもそも何？」という方もいると思うので、今回はRaydium(レイディウム)について分かりやすく画像も交えて、包括的に解説していきます。

https://www.youtube.com/watch?v=4bSm2O3oOrY

Raydium(レイディウム)とは？

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

Raydiumの特徴について解説していきます。大きくは以下の項目になります。

Raydiumの特徴
  • Solanaチェーン上のDEX（分散型取引所）
  • AMM形式を採用していてRAYなどを稼ぐことができる
  • ガス代がETHやBSCに比べて安い
  • 処理能力が高い
  • 板方式のトレードが可能
  • AcceleRaytor（アクセラレーター）というIDOプラットフォームがある

それぞれについて解説をしていきます。

Solanaチェーン上のDEX（分散型取引所）

Raydium(レイディウム)は、DEX（分散型取引所）です。

Solana(ソラナ)ブロックチェーン上に構築されているDEXで、他の人気DEXと同様に「スワップ(取引)」「ファーミング」「ステーキング」「IDO」ができます。

なお年利は150%越えと非常に高く、人気・注目されていることがわかります。

DEXは今までの取引所と何が違うのか？という点については参考になる記事があります。そちらを是非読んでみてください。

https://3mikan.com/archives/734

AMM形式を採用していてRAYなどを稼ぐことができる

screen-2021-10-15-15.36.14

RaydiumはAMM形式を採用していて、ファーム・ステーキングによりRAYを稼ぐことが可能です。

各チェーンの主要DEXの中では年利も高い方に設定されています。

ガス代がETHやBSCに比べて安い

DEX(分散型取引所)の有名どころと比べてRaydium(レイディウム)は手数料が安いことからこれから人気が出てくると予想されています。

  • ETHのUniSwap（ユニスワップ）：ガス代約$20
  • BSCのPancakeSwap（パンケーキスワップ）：ガス代約$1
  • SOLのRaydium（レイディウム）：ガス代約$0.001以下

ETHやBSCチェーンのDEXに比べて遥かにガス代が安くなっています。

ちなみになぜガス代が安いのかというと、Solana(ソラナ)ブロックチェーンを採用しているからです。ガス代というのは、どのブロックチェーンを採用するかによって左右されます。

例えば、「UniSwap(ユニスワップ)」はイーサリアムというブロックチェーンを採用しています。「PancakeSwap(パンケーキスワップ)」はBSC(バイナンススマートチェーン)というブロックチェーンを採用し、安い手数料を実現し人気が出ました。

PancakeSwap(パンケーキスワップ)BSC（バイナンススマートチェーン）
UniSwap(ユニスワップ)ETH（イーサリアム）
Raydium(レイディウム)Solana(ソラナ)
(↑各DEXが採用しているブロックチェーン↑)

処理能力が高い

現在、UniSwapが採用しているイーサリアムでは処理能力のスピードや手数料の高さが問題視されています。

しかし、Raydium(レイディウム)が採用しているSolana(ソラナ)ブロックチェーンは処理が高速で、しかもBSCよりも手数料が安いです。

このSolanaの処理能力が凄まじく、この処理能力のおかげで「スケーラビリティ問題(取引混雑時の手数料高騰/ガス代高騰)」に強力な耐性があります。

板方式のトレードが可能

screen-2021-10-15-15.33.40

RaydiumにはCEXにあるような板取引型のトレードができるUIがあります。これはDEXではかなり珍しいです。

私は実際には使ったことはないですが、指値を入れることができる場合にはトレードの戦略がかなり幅広くなりますからね。

ただ、Telegramなどを見ている限り稀に表示バグに遭っているユーザーもいるようなので、使う際には注意が必要です。

AcceleRaytor（アクセラレーター）というIDOプラットフォームがある

screen-2021-10-15-15.38.46

RaydiumにはAcceleRaytorというIDOプラットフォームがあります。「RAY」というトークンにちなんで名前がつけられているのでスペルミスではありません。

AcceleRaytorによるIDOローンチは既に何回か行われていて恒例化しています。IDO直後は多少ネットワークが重くなる傾向があります。

回数トークン名
第1弾MEDIA（Media Network）
第2弾MER（Mercurial Finance）
第3弾SNY（Synthetify）
第4弾SLRS（Solrise）
第5弾LIKE（Only1）
第6弾ATLAS & POLIS（Star Atlas）
第7弾GRAPE（Grape Protocol）

2021年10月15日現在で既に第7弾まで行われています。私は第1弾しか参加していませんが、基本的に毎回複数のプール割当が用意されています。

「何日までにRAYのシングルステーキングに◯◯RAY以上ステーキングしておく」などのルールが定められており、毎回ルールが変わるため参加する場合には確認しましょう。

もちろん、条件をこなさなくとも「一般セール」には参加可能です。

Raydium(レイディウム)のメリット/デメリット

メリット

  • 処理能力が高い
  • 手数料が安い
  • 注目度が高い

先ほども解説した通り、Raydium(レイディウム)はSolana(ソラナ)ブロックチェーンを採用しているため、処理が早く手数料が安いです。

2021年の2月にローンチされ比較的若いDEX(分散型取引所)ですが、数あるDEX(分散型取引所)の中ではすでにいいポジションについています。

Solanaの高騰によって一気に話題性が上がったこともあり、認知もかなり広がっています。

デメリット

どのDEX(分散型取引所)にも共通しますが、ブロックチェーンに問題が起こるとRaydium(レイディウム)にも影響が及ぶ可能性があります。

また、ネットワークトークンであるSolana（SOL）の価格の影響を受けます。

運営の資金の持ち逃げやサービス終了などの懸念もありますが、Raydiumのドキュメントなど見ても今のところ随時更新されていて、利用者に対しての情報共有などちゃんとしているなと印象を受けます。そこまで心配する必要はないかと思います。

特に目立ったデメリットがあるわけではないのでこれといって心配する必要はないかと思いますが、他の人気DEX(分散型取引所)同様に運用する際はテレグラムに参加したり、公式ツイッターなどから情報収集をして自己責任で利用するようにしましょう。

Raydium(レイディウム)の使い方

Raydium(レイディウム)を利用するには

Raydiumの使い方
  1. Sollet(Solanaのウォレット)を作る
  2. SOLをバイナンスで購入する
  3. 購入したSOLをSolletに送金
  4. RaydiumとSolletを接続する
  5. RaydiumでSOLをRAYに交換

という流れになります。これから画像付きでやり方を解説していきます。なお、画像は全てPCでの表示画面になるので、iPhoneアプリなどの表示画面とは異なる場合がります。

①Sollet(Solanaのウォレット)を作る

screen-2021-10-15-15.57.01

Solletを開くと、一番最初の画面に「新しいウォレットを作成する」と表示されているので、そこから表示されている手順通りに操作していくと簡単にウォレットが作れるので、ここでの詳しい解説は割愛します。

→　Sollet（ウォレット）を作る

② SOLをバイナンスで購入する

次にバイナンスでSOL(ソル)というトークンを購入します。

なぜSOL(ソル)を購入する必要があるかというと、このSOL(ソル)で手数料(トランザクション)の支払いを行うからです。

このSOL(ソル)がなければSwapもできませんし、とにかく全ての取引ができません。なのでSOL(ソル)というトークンを買います。

「SOL(ソル)を購入するにはFTXという取引所で購入すると良い」と書かれている記事が多いのですが、今回は初心者の方でもやりやすいbinance(バイナンス)を使ってSOL(ソル)を購入していきたいと思います。

バイナンスの取引画面を開いてSOL/USDTまたはSOL/BUSDを開きます。(今回はSOL/BUSDを利用します。)

「購入」「マーケット」を選択して、いくら購入するか金額を入力します。入力したのち緑ボタンの「購入 SOL」をタップして購入します。これでSOL(ソル)の購入が完了です。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

③ 購入したSOL(ソル)をSolletに送金する

binance(バイナンス)の「ウォレット概要」というページを開きます。先ほど購入したSOL(ソル)のアイコンが表示されているので、その隣にある「出金」ボタンをタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

次に左にある「通貨」の欄で「SOL」を選択し「受取人のSOLアドレス」と「合計額(出金額)」を記入し「提出」ボタンをタップします。(※「受取人のSOLアドレス」の入力方法は次で説明します。)

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像
※「受取人のSOLアドレス」の入力方法

まず手順①で作ったSolletを開きます。SOLが表示されているのでそこをタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

次に「RECEIVE」をタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

SOLアドレスが表示されるのでコピーします。

S__9322498

再度、binance(バイナンス)の出金画面に戻り「受取人のSOLアドレス」のところに、先ほどコピーしたSOLアドレスを貼り付けます。

「受取人のSOLアドレス」を貼り付け「合計額(出金額)」も入力したら、黄色の「提出」ボタンをタップします。

S__9322499

「メール認証コード」「スマホ認証コード」「Google認証コード」が送られてくるので、それぞれ送られてきたコードを入力したら「提出」ボタンをタップします。(「メール認証コード」「スマホ認証コード」は欄の右隣にある「コードを送信」をタップするとコードが送られてきます。)

S__9338882

このような画面が出たら、出金完了です。(3分ほどでSolletに着金します。)

S__9338884

ちなみにSolletに着金すると手数料分が引かれた金額がこのように表示されます。

S__9338885

④RaydiumとSolletを接続する

SOLをRAYに交換するには、RaydiumとSolletを接続する必要があるので、まずはRaydiumを開きます。Farmにタブを合わせて、右上にある「Connect」ボタンをタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

このように表示が出てくるので「Sollet」をタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

左上にSolletの画面が小さく表示されるので、Solletの自分のアカウントのパスワードを入力し、右下の「UNLOCK」をタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

次に、同じくSolletの小さい画面の方に「CONNECT」と右下に表示されるので、そのボタンをタップするとRaydiumとの接続が完了します。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

⑤RaydiumでSOLをRAYに交換

Solletを開いて、右上にある「＋」ボタンをタップします。

S__9347079

次にRAYを選択します。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

RAYが追加されるとこのように表示されます。

S__9347078

そして次にRaydium(レイディウム)を開き、交換する通貨(今回はSOLとRAY)を右のタブから選択します。次にSOLの数量を入力し「Swap」のボタンをタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

再度左側にSolletの画面が表示されるので「APPROVE」をタップします。これでSwapができました！

S__9347077

Raydium（レイディウム）でLPを作成してステークする方法

今回はLP作成から解体まで、一連の操作方法を解説します。手順は次のとおりです。

  1. LPを作成する
  2. ステークする
  3. ステークを解除する
  4. LPを解体する

LPを作成する

まず下の画像の上部にある「Liquidity」にタブを合わせて、それぞれSOLとRAYを選択します。次にSOLの数量を入力し「Supply」のボタンをタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

左側にSolletの画面が出てくるので「APPROVE」をタップします。

S__9347076

ステークする

上部にある「Farms」をタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

「RAY-SOL LP」をタップし、右側にある「Stake LP」をタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

数量を入力して「Comfirm」をタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

再度、Solletの画面が表示されるので「APPROVE」をタップします。これでステーク完了です。

S__9347074

ステークが完了するとこのように表示されます。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

ステークを解除する

まずは「−」をタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

数量を入力し「Confirm」をタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

「APPROVE」をタップしたらステーク解除の完了です。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

LPを解体する

上部にある「Liquidity」をタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

「Remove」をタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

数量を入力し「Confirm」をタップします。

【Raydium】レイディウムの始め方・RAY/SOLの特徴・使い方・IDOを徹底解説！【Solana】の説明画像

「APPROVE」をタップします。これでLPの解体操作が完了です！

S__9347081

Raydium（レイディウム）各機能の簡単な紹介

screen-2021-10-15-16.10.36

Raydiumの各機能についての簡単な紹介をします。

Raydiumの機能（メニュー）
  1. Trading（トレーディング）
  2. Swap（スワップ）
  3. Liquidity（リクイディティ）
  4. Pools（プール）
  5. Farms（ファーム）
  6. Staking（ステーキング）
  7. AcceleRaytor（アクセラレーター）
  8. DropZone（ドロップゾーン）
  9. Migrate（マイグレート）
  10. Info（インフォ）

※2021年10月15日時点（変更されている可能性あり）

【Raydiumの機能】①Trading（トレーディング）

screen-2021-10-15-16.15.46

冒頭でも紹介した板取引型のトレードページになります。CEX同様の注文方式を行うことができます。

基本的には使い方はCEX同様ですが、CEXと違う点はブロックチェーンに直接書き込んでいく点です。そのため、決済完了時などには少しもっさり感を感じるでしょう。

とはいえ、DEXの低い手数料で指値ができるのは非常に有用です。

【Raydiumの機能】②Swap（スワップ）

screen-2021-10-15-16.17.53

DEXでよく見るスワップの画面になります。

まだDEXアグリゲーターが普及しきっていないSolanaでは、Raydiumのスワップ画面は割と使うことになるかと思います。

最近は試していないですが、以前は通貨交換時の自動ルーティング機能が使えない時がありました。（STEP→USDC→RAYのように他のトークンを経由するスワップ）

【Raydiumの機能】③Liquidity（リクイディティ）

screen-2021-10-15-16.41.29

スワップの次はLiquidityのページです。流動性提供のためのページですね。

LPを作成したり解体したりする用のページになります。

【Raydiumの機能】④Pools（プール）

screen-2021-10-15-16.42.30

プールと書いてありますが、このページ自体にはプールできる機能はなく今のプール状況の統計ページになります。流動性の量や取引高などを確認できます。

ほとんどの場合は一番右の項目「1y Fees / Liquidity」を見るといいでしょう。LPあたりの手数料収入について記載があります。

【Raydiumの機能】⑤Farms（ファーム）

screen-2021-10-15-16.45.01

LPを用いてのファーミングページになります。

「Fusion」というファーム種類は、RAY以外のトークンを稼ぐことができます。（複数トークンもらえるものもある）

【Raydiumの機能】⑥Staking（ステーキング）

screen-2021-10-15-16.46.14

シングルステーキングページです。昔はRAY以外のトークンを預けられた気がしますが、今はRAYだけとなってしまいました。

とはいえ、AcceleRaytorでRAYシングルステーキングが条件に入ることが多く、以外と登場回数が多いページです。

【Raydiumの機能】⑦AcceleRaytor（アクセラレーター）

screen-2021-10-15-16.48.19

AcceleRaytorというIDO用のページになります。今までのIDO一覧を再度掲載しておきます。

IDO中はこのページを操作していくことになります。普段はすでに終わったIDOの一覧が載っています。

回数トークン名
第1弾MEDIA（Media Network）
第2弾MER（Mercurial Finance）
第3弾SNY（Synthetify）
第4弾SLRS（Solrise）
第5弾LIKE（Only1）
第6弾ATLAS & POLIS（Star Atlas）
第7弾GRAPE（Grape Protocol）

IDOに参加したい場合にはRaydiumの公式テレグラムなどに参加してアナウンスを確認しておきましょう。

【Raydiumの機能】⑧DropZone（ドロップゾーン）

screen-2021-10-15-16.51.42

NFTに特化したプロジェクトチームサポート用のプラットフォームです。ほとんどIDOのようなものと思っていいでしょう。

【Raydiumの機能】⑨Migrate（マイグレート）

screen-2021-10-15-16.53.21

Migrateの処理が必要になったときに操作するページになります。

Migrate（移管）は、DEXのコントラクトが変更されてLPの再作成が生じたり、トークンのバージョンが上がりトークンの移行をする必要があるときなどに行います。

基本的にはアナウンスが来たらやればいい内容です。

Raydium（レイディウム）関連トークン（RAY・SOL）について

まず、Solana（SOL）とRaydium（RAY）はネットワークトークンとその主要DEXの独自トークンになります。

ETHにおけるETHとUNI、BSCにおけるBNBとCAKEみたいな関係性です。

RAYの特徴・価格推移

screen-2021-10-15-18.25.17

RAYはRaydiumでファームできる独自トークンなので、Raydiumの成長度合いと連携します。

AcceleRaytorなどでRAYのシングルステーキングが必要になるケースが多く、一時的に需要が多くなるパターンが多いです。

ただ同時期にAcceleRaytorの需要を見込んで売り抜けるユーザーもいますので、AcceleRaytorに参加したはいいけどRAYの価格が下がってマイナスというケースも起こります。

実際、常に右肩上がりのチャートのトークンではないので購入の際にはきちんとトークンの内容を見直しましょう。

SOLの特徴・価格推移

screen-2021-10-15-18.24.59

SOLはSolanaネットワークのネットワークトークンの為、SolanaネットワークのDeFiプロジェクトが賑わうとつられて上昇します。

特にSolanaはERC20のフォーク系列のチェーンと少々異なるため、「SOLネットワークに触るならSOLを一度購入する必要がある」ケースが多いです。

そのため、新規で参加してくるユーザーは基本的にはSOLを購入する必要性があるので、価格が上がります。

また、バイナンスなどの主要CEXでも購入することができSOLネットワークにもしっかり対応している点もいい点でしょう。

Raydium（レイディウム）のまとめ

実際にRaydium(レイディウム)を操作してみると実感できるのですが、読み込みがとにかく早くサクサク操作ができます。

Raydiumの特徴まとめ
  • Solanaチェーン上のAMM形式のDEX
  • 処理能力が高く、ガス代が安い（$0.001以下）
  • 板方式のトレードが可能
  • AcceleRaytor（アクセラレーター）というIDOプラットフォームがある

Solanaのトークン価格が一気に上がったことで認知度が上がりましたが、まだまだ参入してる人が少なくこれからさらに利用者数は増えると見込んでいるので、今のうちに参入してみるといいかもしれません。

マイナーな印象があり、まだ発展途上と言えますが、気になる方はぜひ利用してみてください。

--- # 【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法 今話題のPancakeSwapの始め方を紹介していきます。 仮想通貨のDeFiプロジェクトとなりますので、ハイリスクハイリターンな運用方法となります。以下のリスクを踏まえて記事を確認ください。 この記事はあくまで利用方法の解説記事となります。運用を推奨する意図はございませんので各自でご判断ください。当記事の… 正規URL: https://3mikan.com/archives/240 著者: みかん 公開: 2021-02-17T07:18:20.000Z 更新: 2021-10-19T03:47:28.000Z

今話題のPancakeSwapの始め方を紹介していきます。

仮想通貨のDeFiプロジェクトとなりますので、ハイリスクハイリターンな運用方法となります。以下のリスクを踏まえて記事を確認ください。

  • この記事はあくまで利用方法の解説記事となります。運用を推奨する意図はございませんので各自でご判断ください。
  • 当記事の内容を参考にして損失を被った場合には自己責任となります。理解の上で進めてください。
  • 今回紹介するサービスは年利100%超えなどの超高利回りの表記があるプロジェクトとなります。一方でリスクも大きいということをご理解ください。

この記事は以下のような方を対象としている記事になります。

この記事の対象ユーザー
  • 仮想通貨を持っており、バイナンスの口座を持っている（または開設するリテラシーがある）
  • 100%損失のリスクを受け入れることができる
  • 分散投資するくらいの軍資金がある
  • USDTを知っている・アルトコインに関する知識がある

このようなユーザーは今後のためにDeFiを体験してみるという上では非常に有用かと思います。

一方で、「USDTが何かわからない」というユーザーは一旦仮想通貨についての情報収集をし直すところからしたほうがいいかと思います。

テザー（USDT）という通貨について知らないということは、かなりの初学者かと思いますので、一度しっかり知識を入れましょう。

途中にウォレット作成や送金などを含むため、上級者でも運用開始までが骨が折れます。時間が確保できる時に行いましょう。

PancakeSwap（パンケーキスワップ）とは？

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

PancakeSwapとは、バイナンススマートチェーンというプラットフォームをベースに構築された、DEX（分散型取引所）になります。

DEXとはブロックチェーン技術によって構築された金融システム（Defi）の中のサービスの中の一つのようなイメージです。

簡単にいうと『管理者がいない、ブロックチェーンのみで動いている取引所』になります。

DEXとは何か？

dex.007

DEXは「管理者がいない取引所」です。では、どのように私達は取引ができるのでしょうか？

まずDEXの開発者が、取引用の資金プールを作成します。一般ユーザーはそこに資金を預けていきます。これを流動性（Liquidity）といいます。

流動性が増えてくると取引ができるようになります。「資金プールにBTCを入れるとレートをあわせてUSDTが返却される」みたいなイメージです。

開発者はあくまでプラットフォームを提供しただけでSwap（交換）のもとになる資金は一般ユーザーが提供しています。これが「管理者がいない」という意味です。

AMM（自動マーケットメーカー）のDEX

イールドファーミングの基礎知識.006

DEXで流動性を提供した場合、LP（Liquidity Provider）という流動性提供の証明トークンをもらうことができます。

流動性提供者にはDEXでの取引手数料の一部が還元されますが、「さらに流動性を提供してもらうにはどうするか？」を考えた結果出てきたアイデアがAMMです。

AMM（自動マーケットメーカー）は、LP（流動性提供の証明トークン）を預けることでファーム運用できるようにしたものです。

PancakeSwapの場合にはCAKEを収穫することができ、流動性を提供したユーザーは手数料に加えて別のトークンを稼げることになります。

独自トークンCAKE（ケーキ）の価格推移

screen-2021-10-11-23.16.32

ファームでもらえるCAKEも価格がほとんど無いわけではなく、しっかり値がついています。

「なぜCAKEの価格が上がるのか」に関しては私のYoutubeを一通り見てもらったほうがいいです。分かってしまえば簡単ですが、最初は複雑に見えますよね。

https://youtube.com/playlist?list=PLc68AqeefY7Uj12dLBJ2varJtvpkIm5qk

PancakeSwap（パンケーキスワップ）でできること

PancakeSwapでできることは複数あります。私もまだ数日しかやっていないですが、機能が増えたり減ったり（変わったり）しているようなので、今後も変更されていくと思います。

簡単にまとめると以下のような感じです。

PancakeSwapでできること
  1. 2種類の仮想通貨を預けて（流動性を提供して）、報酬をCAKEトークン（仮想通貨）でもらう
  2. CAKEトークン（仮想通貨）を預けて、金利という形で仮想通貨を獲得する
  3. CAKEトークンを使って宝くじを買う
  4. プロフィールを作成する（今後追加機能がありそう）
  5. NFTを売買する

上記のようなことができます。主にほとんどのユーザーは①②で利用しています。

ステーキングなどの用語を知っている方は、②の方が馴染みがあるかと思います。

①②の細かい運用スタイルに関しては下にかいてあるので参考にしてください。

①は「流動性」の意味がわかってしまえば理解できるのですが、少し補足します。

『流動性』の補足

PancakeSwapはDEX（分散型取引所）で、管理者がいません。

なので、あなたがPancakeSwap上で仮想通貨を交換したい場合（例えばBTC→USDTなど）に、マッチングする相手（USDT→BTC）が居ない場合には取引ができません。

仮想通貨のトークンは複数ありますから、ピンポイントでリアルタイムにマッチングする可能性はかなり低いですよね。つまり、それだと交換できないということになってしまいます。

こういう時のためにDEXは「流動性」を確保します。「BTC→USDT」の交換を即座に提供できるように、プラットフォーム上にいろんな仮想通貨を滞留させているんです。

この滞留がユーザーが提供した「流動性」です。つまり、ユーザーが流動性を提供してくれることで、他のユーザーが即座に交換できるようになります。

その流動性を提供してくれていることの報酬として、仮想通貨が報酬で得られるといった具合です。

PancakeSwap（パンケーキスワップ）の実際の運用のイメージ

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

PancakeSwapの運用画面はほとんどこの画像の通りです。各メニューは、これを詳細に見れるようなイメージですね。

CAKEトークンが溜まっていき、たまに回収するの繰り返しです。CAKEトークンは仮想通貨なので、リアルタイムで価値が変動していきます。

この画像のときは、12CAKE x 6.6$で73$くらいが報酬になっていますね。

仮想通貨では、運用利益を確保することを「収穫（Harvest）」と表現するので、その表現を利用します。

①流動性を提供している場合の収穫方法

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

流動性を提供している方式の収穫画面になります。

各仮想通貨ペアに応じて収穫ボタンがあります。「Harvest」を押すと収穫できます。

※収穫の度にBNBで手数料を払う必要があるので、たまに収穫する程度にしましょう。

②CAKEトークンを預けて金利を得る場合の収穫方法

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

CAKEトークンを預けている場合の画面です。

こちらも「Harvest」を押すと収穫できます。CAKEトークンの場合のみ、収穫分を預け直し複利で運用することができますので、その場合には「Compound」を押します。

それでは、簡単にPancakeSwapのメリット・デメリットのお話をしてから実際の運用方法を紹介していきます。

PancakeSwap（パンケーキスワップ）のメリット

まずはPancakeSwapのメリットになります。

  1. 高利回りの運用ができる
  2. 交換や運用にかかる手数料が低い
  3. CAKEトークンがあれば、いろんな仮想通貨を得られる

この辺りが現状わかりやすい主なメリットでしょう。

メリット①：高利回りの運用

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

PancakeSwapでは高利回りの運用ができます。APYは年利のようなイメージですので、APY 142%＝年利142%のようなイメージです。

年利100%超えの運用がたくさん並んでおり、ここから選んで運用する方式になります。

実際に細かく計算したことはないですが、しっかり1年間収穫でき、仮想通貨の価値が不変だとしたらAPYの通りの年利になるのでしょう。

※この年利は、当然ですが今後の仮想通貨の価値変動は考慮していません。仮想通貨の価値が下がった場合には損失になる可能性があります。

マルチプライヤー（x1・x10など）の表示に関して

イールドファーミングの基礎知識.010

ファームの年利を見ていると大体のユーザーは「もっと年利が高いものを選びたい！...あれ、この数字はなんだろう？」という感じで『x1』や『x10』などの数字に着目します。

これは、マルチプライヤーと呼ばれていてファームの重み値を示しています。この重み値が大きいほど、そのファームに割り当てられているトークンが多いということです。

まず全てのファーム合計のトークン配布スピードは開発者が決めています。そこから割合でファームに割当が決まっています。

さらに、その割当をファームにあずけているユーザーのシェア率で分けていく形になっています。このあたりは動画で説明しているので参考にしてください。

https://youtu.be/OElbJ7EbeRA

メリット②：手数料が低い

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

これは、仮想通貨に慣れている人にしかピンと来ないかもしれませんが、送金にかかる手数料が安いです。（1回あたり20円程でした）

「送金」と書きましたが、通貨の交換や収穫など、通貨の移動が行われるところでは全て手数料がかかることになります。

少し前に流行っていたETHを元にしたサービスでは、1回1000~2000円程度かかっていたようなので、かなり安くなっています。

この安さはBSC（Binance Smart Chain）というネットワークを用いたことによる恩恵です。詳しく知りたい方は調べてみてくださいね。

メリット③：いろんな仮想通貨を得られる

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

仮想通貨の値上がり方を見ていると、「私も今は人気じゃないマイナーなコインを持ってみたい！」と思う方もいるでしょう。

ただ、普通に買うのって少し抵抗ありますよね。下がるかもしれないので...

そんな方には、PancakeSwapのPoolで収穫していくのがおすすめです。CAKEトークンを使えば、いろんなコインを収穫できます。

この記事をかいているときは、ちょうどBRY（ブルーベリー）が出たところですね。

PancakeSwap（パンケーキスワップ）のデメリット

逆にPancakeSwapのデメリットになります。こちらにはリスク面も記載させていただきます。

  1. PancakeSwap自体のサービスが消滅する可能性がある
  2. 運用中に仮想通貨自体の価値が下がる可能性がある
  3. バイナンスなどでも扱っていないマイナーな通貨も置いてある
  4. 運用開始までが少し大変

ハイリターンなのでハイリスクなのは当たり前ですが、①のような全損リスクもありますのでそこは覚悟しておきましょう。

デメリット①：サービス消滅の可能性

これは全てのサービスに言えることですが、『サービス自体が消滅』するリスクがあります。その場合には、そのサービス内に預けている資金ごと全て消えます。

実際に数年前に仮想通貨のブームになった際に流行ったマイニングプールサービスなどは、いつの間にか終了しアクセスできなくなっていました。

こういう場合には「資金が全損」になりますので、許容できない場合は利用しないほうがいいでしょう。

デメリット②：仮想通貨の価値の下落の可能性

金融資産に慣れている方ならすぐに分かることですが、高利回りで運用できるとはいえ、通貨自体の価格が下がったらマイナスになります。

例えば、PancakeSwapではCAKEトークンをよく使いますが、運用している間にCAKEトークンが10円程度になる可能性もあります。

そうなった場合には、差額分がマイナスになります。

デメリット③：マイナーな通貨

メリットのほうに「いろんな通貨を得ることができる」と書きましたが、場合によってはデメリットにもなります。

あまりにもマイナーすぎて、バイナンスで取引できないような通貨も含まれているからです。

そういった通貨はPancakeSwapから出金したい場合に、対応したウォレットを準備する必要があります。

デメリット④：運用開始までの大変さ

これは仮想通貨に詳しい人でも直面する課題ですが、運用開始までの手順が結構あり大変です。

更に途中で行う操作が結構リスクが高い操作なので、慎重にすすめていく必要があります。（送金ミス・ウォレットの復旧パスのメモ忘れなど）

この記事ではできる限り操作方法を全て載せていますが、サービスのアップデートに対応していない場合もあります。

あなたの操作時に表示されている文字をしっかり読むようにしてください。英語ですが頑張って読みましょう。

PancakeSwap（パンケーキスワップ）の利用方法

それでは、PancakeSwapの利用までの流れを説明していきます。

手順は以下のような流れになります。

PancakeSwapの利用手順
  1. Binance（バイナンス）の開設・入金
  2. BinanceにてBNB・CAKEを購入
  3. ブラウザ拡張機能の「Binance Chain Wallet」を追加
  4. Binance Chain Walletのウォレットを作成
  5. Binance Chain Walletに送金
  6. PancakeSwapにアクセスし、Binance Chain Walletと連携
  7. PoolにCAKEを追加（※）
  8. 定期的にHarvest

このような流れとなります。今回は簡単のために以下のような運用方法で進めていきます。

  • PoolにCAKEを入れて運用する（上記②の運用方法）
  • 送金処理諸々用にBNBを0.1BNBだけ購入
  • 連携ウォレットはBinance Chain Wallletを利用
  • ブラウザはFirefox
    （普段はChromeですが、わかりやすく分けました）

手順①：Binance（バイナンス）の開設・入金

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

まずはBinanceの開設を行いましょう。これがないと始まりません。

なにより、今後どの仮想通貨を使うにもあると便利なサービスなので口座開設＋KYCは早めに終わらせておくことをおすすめします。

下のリンクから登録すると、取引手数料が10%安く取引できます。ぜひご利用ください。

【無料】Binanceに手数料優遇アカウントで登録したい方はクリック

その後は、実際に入金しましょう。もともと仮想通貨を持っていない方は、以下の記事などを参考にUSDTを買うといいと思います。

USDTはビットコインなどの他の仮想通貨と比べて値動きが小さいので、価値の上がり下がりが起こりにくいです。

また、いろんな通貨との交換に利用できるので、非常に便利な仮想通貨です。

https://3mikan.com/archives/152

手順②：BinanceにてBNB・CAKEを購入

Binanceアカウントと入金を済ませたら、次はBNBとCAKEを購入します。

  • BNB＝送金手数料用の資金
  • CAKE＝Poolに預ける用の資金

のようなイメージです。

BNBを購入

１

Binanceメニューの「トレード」＞「クラシック」を選択します。もちろん、慣れている方はアドバンスでも構いません。

2

検索窓に「BNB」と入力して、通貨ペアを探します。今回は、BNB/USDTで取引したかったのでそれを選択します。

3

今回は、0.1BNBを購入したいので「0.1」と入力して購入ボタンを押します。

※画像では指値注文と呼ばれる注文方式をとっています。とにかく早く取引したい場合には、『購入BNB』という文字の上の「マーケット」を選択ください。

CAKEを購入

次はCAKEを買っていきましょう。CAKEは通貨ペアが少ないので、BNBまたはBUSDを持っている必要があります。

（BNBを買う際にまとめて全部変えちゃえばよかったのですが...勉強としてBUSDを経由することにします。）

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

「CAKE/BUSD」または「CAKE/BNB」での交換ができますが、今USDTしか持っていないので、USDT→BUSD→CAKEと交換していきます。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像
【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

今までと同様に、「BUSD/USDT」のペアを見つけます。その後に交換したいBUSDの数量を入力していき、BUSDを購入します。

今回は全額交換してしまいたいので、スライダーを利用して100%交換しました。25%・50%・75%・100％など交換したい場合には数量を直接入力するより簡単です。

BUSDを買ったら同様にCAKEを購入していきます。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

「CAKE/BUSD」のペアで、全額交換します。

1回やってみたところ、指値注文（リミット）ではすぐに交換できなかったので、成行（マーケット）注文で交換しました。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

BinanceのウォレットにBNBとCAKEが入っていることが確認できたら、ここの作業は完了です！

次のステップに進んでいきましょう。

手順③：ブラウザ拡張機能の「Binance Chain Wallet」を追加

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

次は、ブラウザ拡張機能を使います。GoogleChromeまたはFireFoxをご利用ください。

ページを開いたら「利用」や「インストール」など追加しそうなワードになっているボタンを押してください。

追加ができると、拡張機能欄にBinanceのアイコンが追加されます。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

追加すると、こんな感じで表示が出ます。ここからウォレットの作成に進んでいくので次のステップに行きましょう。

手順④：Binance Chain Walletのウォレットを作成

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

最初は、「I do not own a wallet（私はウォレットを持っていません）」から進んでいきましょう。

（これは、Binanceのアカウントが無いということではなく、Binance Chain Walletをまだ作っていませんということです。）

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

パスワードを2回入力します。ここで設定するパスワードはセキュリティの強さに指定があるので、よく見ましょう。

下にパスワードの注意点をまとめています。

  • 8文字以上
  • 大文字を1文字以上含む
  • 数字を1文字以上含む
  • 記号を1文字以上含む

※ここで入力したパスワードは必ずメモっておきましょう。紛失すると資金を失う恐れがあります。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

パスワードを入力すると、ウォレットの復旧コードが表示されます。

パソコンが変わったりブラウザが変わったり、パスワードを忘れたりした場合などとにかく紛失しかけた場合に必要になるものです。

この12個のフレーズの中から、3つ指定されたりして記入する必要があるので、バラバラに保存するのではなく順番通りメモしておきます。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

その後仮想通貨のウォレットっぽいものが表示されます。ここまでくれば完了です。

※他のブログではMetaMaskを利用している人が多いようですが、私はBinanceに合わせてBinance Chain Walletを利用しました。

どちらが良い悪いとかはあまり無いと思います。

手順⑤：Binance Chain Walletに送金

次は、Binance Chain Walletに資金を移します。Binance Chain WalletはBinanceとダイレクトに連携できるので、連携→資金移動を行います。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像
【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

Binance Chain Walletの右上のアイコンをクリックすると「Connect to Binance.com Account」と出ます。

これが連携ボタンになるのでクリックして進めていきます。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

Binance.com側での認証作業になります。ここ操作は普段のBinanceの操作とほぼ一緒ですので少し割愛していきます。

4

Binance Chain Wallet側で確認ボタンが出る場合、このようにブラウザが新規で開かれます（ここの表示が若干時間がかかる）

「Confirm」「Verify」などを押して進めていきます。

1

Connecting Address Listに追加されたら連携完了です。ちなみに、Binance Chain Wallet側にも「Connected」と表示されます。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

これで連携完了です。次は送金です。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像
【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像
【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像
【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

送金とは言え、すでにBinance Chain Walletでは連携済みなので、Binance Chain Wallet側で「Receive」をすると簡単に移していけます。

※送金には数分かかることがあります。気長に待ちましょう。

BNBとCAKEを移していきます。次はやっとPancakeSwapに進みます。

手順⑥：PancakeSwap（パンケーキスワップ）にアクセスし、Binance Chain Walletと連携

PancakeSwapにアクセスしましょう。「PancakeSwap」と検索しても出てきます。

アクセスしたらまず、右上の「Connect」をクリックして、Binance Chain Walletと連携します。

2-2
3-1
【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

PancakeSwapを動かしていく中で、このConnect作業は何回か行いますので慣れておきましょう。

実際にConnectできると、右上の表示が変わります。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

手順⑦：PoolにCAKEを追加（※）

次は、Poolに実際にCAKEを投げてみましょう。今回は、LITを手に入れるためにPoolしてみました。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

最初は、「Approve CAKE」をクリックします。これはステーキングの開始のような意味合いです。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

Binance Chain Wallet側で通知が出てくるので、Confirmをクリックします。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像
【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像
【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

表示が変わったら「+」をクリックし、数量を選択してConfirm。その後、Binance Chain Wallet側でもConfirmをします。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

Your Stakeに入れたCAKEが反映されれば完了です！あとは時間をあけるごとに、Harvestしましょう！

手順⑧：定期的にHarvest

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像
【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

あとは、溜まってきたなーと思ったらHarvestするだけです。

Harvestの度に毎回0.002BNB（大体20円）消費しますので、あまりにも収穫数が少ないとマイナスになります。その場合には時間を空けて、まとめて収穫するようにしましょう。

PancakeSwap（パンケーキスワップ）での他の運用スタイル

今回の記事では、Poolを利用してCAKEでLITを収穫していく方法を選びましたが他にもやり方があります。

※上で紹介した画像は私の知り合いの画像素材をもらっています。（始める時に取り忘れてしまったので）

他のパターンを簡単に紹介していきます。

その他の運用方法①：流動性を提供して報酬を得る

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

LP（Liquidity Provider, 流動性提供者）となり、報酬を得るスタイルです。

多分PancakeSwapの中でも一番メジャーな運用方法ではないでしょうか。

手順を簡単に説明します。

流動性提供手順
  1. 提供したい通貨ペアを同価値分用意します。
    （PancakeSwap内でExchangeしてもOK）
  2. 流動性トークンに変更
  3. 流動性トークンをステーク

まずは、通貨ペアを同価値分用意する必要があります。

「BNB100$分・CAKE100$分」のようなイメージです。メニューのLiquidityで見ると、比率がわかりやすいかと思います。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

例えば、上の例ですと10BNBを入れたい場合は、同価値分のCAKEを用意しようとすると158.619CAKEが必要になります。

この場合は「10BNB」と「158.619CAKE」をまず準備するのが必要になります。

その後に、同じLiquidityのメニューでSupplyしていくとLPを取得できます。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

LPを手に入れたら、Farmsメニューに進みLPを追加してあげるだけです。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

その他の運用方法②：宝くじを購入する

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

1CAKEで1枚宝くじのチケットを購入でき、抽選に参加できます。

【DeFi】PancakeSwap（パンケーキスワップ）の始め方・おすすめ運用方法の説明画像

購入した宝くじには4エリアに1~14のどれかの数字が記載されてます。

エリアと数字が一致していたら当選といった形ですね。

2箇所以上一致していれば報酬が帰ってきますので、比較的当選率は高いと言えます。（還元率はしっかり計算してないのでわかりません）

毎回の当選金額も変動しているので、場合によってはかなりプラスになることもありそうです。私は1回購入して外れてて、その後は購入するのが面倒でやってないです笑

PancakeSwap（パンケーキスワップ）をこれから始める方へ

これからPancakeSwapを始めてみたいという方は、まずBinanceの口座があるか確認しましょう。

【無料】Binanceに手数料優遇アカウントで登録したい方はクリック

その後のフローを再度まとめておきます。

PancakeSwapの利用手順
  1. Binance（バイナンス）の開設・入金
  2. BinanceにてBNB・CAKEを購入
  3. ブラウザ拡張機能の「Binance Chain Wallet」を追加
  4. Binance Chain Walletのウォレットを作成
  5. Binance Chain Walletに送金
  6. PancakeSwapにアクセスし、Binance Chain Walletと連携
  7. PoolにCAKEを追加（※）
  8. 定期的にHarvest

私はまあまあな金額を入れて試してますが、あなたの許容できるリスクの範囲で遊んでみてくださいね！

リスクについて：PancakeSwap（パンケーキスワップ）は安全なのか？

DeFiは高年利が非常に魅力的ですが、果たして安全なのでしょうか？これはみんなが気になる箇所かと思います。

結論からいうと安全ではありません。というのも、これはDeFiの概念を理解したら自然と分かってくることです。

ただそれでもユーザーがいるのは、「年利高い！やったー！」というユーザー層と「DeFiは興味深い」というユーザー層がいるからですね。

安全ではない理由の中心は「誰でも作れる」からですが、補足していきます。

DeFiは全体的にハイリスク・ハイリターン

DeFiという分野は基本的に全てがハイリスク・ハイリターンです。見て分かる通り、3%とかでも低いと言われる世界で、これは法定通貨では異常ですよね。

日本の銀行預金年利が0.001%なので、それよりも10000倍くらいリスクは高いと思ってください。

法定通貨の株や投資信託をやったことがある方は、年利100%はどれくらい異常かをご存知だと思います。

リターンの分だけリスクを抱えていると思ってください。その中でプロジェクトによってリスクの大きさが多少変わるだけです。

プロジェクトが明日無くなるリスクも考えよう

DeFiプロジェクトは誰でも作れるので、詐欺師が作っている可能性もあります。

そういうプロジェクトの場合、ある日突然サイトがなくなってしまうこともあります。これを「ラグ」といいます。

自分が運用する際には「明日無くなるかも」というのは忘れずに考えておいてください。

BNBなどのトークンの相場も影響する

結果的に仮想通貨で全て運用していくので、BNBやETHなど別のトークンの相場変動も影響してきます。

これが原因で、ファームでいっぱいトークンを受け取っているのに損益はマイナスといったことが起こります。

特に、全体的な相場の大幅下落などが起きた場合には損益はマイナスになり、必要もないトークンを持っているというパターンにもなりかねません。

PancakeSwap（パンケーキスワップ）のまとめ

PancakeSwapはDeFiにおけるチュートリアルのような存在です。これを操作できるようになれば、他のプロジェクトも問題なく触れるでしょう。

ただDeFiはハイリスク・ハイリターンなことを忘れずに、運用する場合は許容できるリスクの範囲内でやりましょう。

私はDeFiの「技術面」や「将来性」に非常に期待しているので色々と触っている人間です。この概念は確実にブレイクスルーを起こせると思っています。

あなたももし興味が出てきたらより深く知識をつけてみてください。きっと面白いはずです。

その他の仮想通貨情報

このサイトでは、他にも仮想通貨の情報をまとめていますので一通り目を通すことをおすすめします。

仮想通貨は非常に奥が深いので、いろんな情報に触れておきましょう。

https://3mikan.com/archives/101