Itâ€™s somewhat more complicated than that.

By only knowing the Ethereum **address**, you cannot get at the **public key**, because the public key goes through a SHA3 hash to get to the address.

*However*, you can recover the public key by observing a valid eth transaction to that address. To verify the signature, the public key must be revealed.

So unless the address was never used, you essentially always have the matching public key.

Now. The list of addresses is generated via BIP-32. All addresses start with a private secret derived from your seed, and then you descend down a tree consisting of hardened and unhardened steps.

The default derivation path for Ethereum is `m/44'/60'/0'/0/x`

, where `x`

goes from 0 to 1 million. The steps denoted with `'`

are *hardened* and we donâ€™t care about those, because you always need a private key to do that step.

But the last two steps are *unhardened*, meaning that if you somehow got a hold of the (extended) public key at `m/44'/60'/0'`

, you can compute the remaining `/0/x`

yourself and get a public key of *any* address this way.

And it turns out that the public key at `m/44'/60'/0'`

is commonly called an â€śxpubâ€ť and people work with it regularly. In particular, MetaMask will ask Trezor for your xpub and only then show the list of your addresses. AFAIK the xpub is not stored, but technically it *can* be.

This was designed with Bitcoin in mind, where an *account* consists of many addresses and you need a convenient way to collect all of them. Ethereum stupidly adopted the same structure, despite it making very little sense, but then six years of development happened and now weâ€™re pretty much stuck with it.

In conclusion: if you just have an **address**, then you canâ€™t calculate the other addresses. If you have an **xpub**, you can calculate all the addresses below that xpub.