# [EIP85] トークンアドレスからHDウォレットパスを導く仕組みを理解しよう！

> Ethereumやそのトークンを扱うウォレットにおいて、アドレスの階層的な生成方法（HDウォレット）を標準化することは、ユーザーにとっての一貫性や相互運用性を確保する上で重要です。

- URL: https://cardene.dev/articles/af5d53ac31897721b225
- 公開日: 2025-08-09
- 更新日: 2025-08-09
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

今回は、Ethereumの各トークンに対して、トークンアドレスを使って一意のHDウォレットパスを割り当てることで、安全なトークン管理を可能にする仕組みを提案している**EIP85**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

https://github.com/ethereum/EIPs/issues/85

他にも様々なEIPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

Ethereumやそのトークンを扱うウォレットにおいて、アドレスの階層的な生成方法（HDウォレット）を標準化することは、ユーザーにとっての一貫性や相互運用性を確保する上で重要です。
**EIP85**では、EtherやEthereumトークンを対象にした**BIP44**ベースのHDパスを提案しています。

## BIP44とは

**BIP44**は、HD（Hierarchical Deterministic）ウォレットにおけるアドレス階層の標準を定めた提案です。
特定の形式に従ってアドレスを階層的に導出できるようにし、複数の通貨やアカウント、受け取り用/残高返却用アドレスなどを整理して管理できるようにすることを目的としています。

BIP44の標準的なパス形式は以下のとおりです。

```
m / purpose' / coin_type' / account' / change / address_index
```

ここで`purpose`は常に`44`（BIP44準拠であることを示す）、`coin_type`は通貨の種類（例：Bitcoinは`0`、Etherは`60`）、`account`はアカウントの区別、`change`は0（受け取り用）または1（残高返却用）、`address_index`はインデックス番号です。

## Ethereum用のHDパス

Ethereumにおいては、すでに**BIP44**に準拠したHDウォレットが普及しており、標準的なHDパスは以下のようになります。

```
m / 44' / 60' / a' / 0 / n
```

ここで`60`はEtherに割り当てられた`coin_type`（**SLIP44**に登録済み）、`a`はアカウント番号、`n`はn番目に生成されるアドレスを意味します。

### EthereumトークンのHDパスをどう扱うべきか

Ethereumには無数の**ERC20**トークンが存在します。
Etherと同様に、それぞれのトークンに対して一意なHDパスを割り当てることができれば、トークンごとのアドレス管理が容易になります。

しかし、Etherのように各トークンごとに**SLIP44**で新しい`coin_type`番号を登録していくことは現実的ではありません。
トークンの数が多すぎて、すべてを個別に登録するのは管理上困難です。

そこで、提案されているのが、Ethereumトークン用の共通`coin_type`番号として「`61`」を予約し、それをベースに各トークン固有のHDパスを構築するという方法です。

#### トークンアドレスをHDパスに変換する方法

各トークンは固有の160ビットアドレス（20バイト）を持っていますが、**BIP32**の階層的導出では、それぞれのレベルに使用できるのは最大31ビットの整数（2³¹未満）です。

そのため、この提案では160ビットのアドレスを次のように6つのセグメントに分割します：

```
x = x0 || x1 || x2 || x3 || x4 || x5
```

* `x0`〜`x4`
    * 各28ビット
* `x5`
    * 残りの20ビット

このように分割することで、各セグメントを**BIP32**のハードンドパス（`'`付き）に利用可能な範囲に収めることができます。

#### トークンごとのHDパス構成

最終的なHDパスは以下のような形式になります。

```
m / 44' / 61' / x0' / x1' / x2' / x3' / x4' / x5' / a' / 0 / n
```

この形式により、`coin_type`が`61`に固定されたうえで、トークンアドレスを使って一意のHDパスを作成できます。

これにより、トークンごとにまったく別のアドレス空間を持つことができ、セキュリティや管理の観点からも利点があります。

#### 実例：Unicornトークン

例えば、Unicornトークンのコントラクトアドレスが以下だったとします。

```
0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7
```

これを上記のように分割・変換した場合、各セグメントは次のようになります。

```
x0 = 0x89205A3  = 143787427
x1 = 0xA3b2A69  = 171649641
x2 = 0xDe6Dbf7  = 233233399
x3 = 0xf01ED13  = 251784467
x4 = 0xB2108B2  = 186714290
x5 = 0xc43e7    = 803815
```

これらをHDパスに組み込むと、以下のような完全なパスになります。

```
m/44'/61'/143787427'/171649641'/233233399'/251784467'/186714290'/803815'/a'/0/n
```

#### メリットと課題

**EIP85**のメリットは、各トークンごとに明確かつ衝突のないHDパスを持つことができる点です。
これにより、トークンごとのアドレス管理が整理され、ウォレット間でのインポートや復元も容易になります。

一方、**BIP44**は本来、`coin_type`に1つの整数しか許容しておらず、**EIP85**のようにトークンアドレスを`coin_type`の下層に階層的に組み込む構造は、**BIP44**の厳密な仕様から外れるとも言えます。
そのため、「**非公式な拡張**」として扱うのが妥当です。

## 最後に

今回は「Ethereumの各トークンに対して、トークンアドレスを使って一意のHDウォレットパスを割り当てることで、安全なトークン管理を可能にする仕組みを提案している**EIP85**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://chaldene.net/

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4