# Addresses All Filecoin addresses begin with an `f` to indicate the network (Filecoin), followed by any of the address prefix numbers (`0`, `1`, `2`, `3`, `4`) to indicate the address type. There are five address types:
Address prefixDescription
0An ID address.
1A SECP256K1 public key address.
2An actor address.
3A BLS public key address.
4Extensible, user-defined actor addresses. f410 addresses refers to Ethereum-compatible address space, each f410 address is equivalent to an 0x address.
Each of the address types is described below. ## Actor IDs All actors have a short integer assigned to them by `InitActor`, a unique actor that can create *new* actors. This integer that gets assigned is the ID of that actor. An *ID address* is an actor’s ID prefixed with the network identifier and the address type. Actor ID addresses are not *robust* in the sense that they depend on chain state and are defined on-chain by the `InitActor`. Additionally, actor IDs can change for a brief time after creation if the same ID is assigned to different actors on different forks. Actor ID addresses are similar to monotonically increasing numeric primary keys in a relational database. So, when a chain reorganization occurs (similar to a rollback in a SQL database), you can refer to the same ID for different rows. The expected consensus algorithm will resolve the conflict. Once the state that defines a new ID reaches finality, no changes can occur, and the ID is bound to that actor forever. For example, the mainnet burn account ID address, `f099`, is structured as follows: ```plaintext Address type | f 0 9 9 | | | Actor ID | Network identifier ``` ID addresses are often referred to by their shorthand `f0`. ## Public keys Actors managed directly by users, like accounts, are derived from a public-private key pair. If you have access to a private key, you can sign messages sent from that actor. The public key is used to derive an address for the actor. Public key addresses are referred to as *robust addresses* as they do not depend on the Filecoin chain state. Public key addresses allow devices, like hardware wallets, to derive a valid Filecoin address for your account using just the public key. The device doesn’t need to ask a remote node what your ID address is. Public key addresses provide a concise, safe, human-readable way to reference actors before the chain state is final. ID addresses are used as a space-efficient way to identify actors in the Filecoin chain state, where every byte matters. Filecoin supports two types of public key addresses: * [`secp256k1` addresses](https://en.bitcoin.it/wiki/Secp256k1) that begin with the prefix `f1`. * [BLS addresses](https://en.wikipedia.org/wiki/BLS_digital_signature) that begin with the prefix `f3`. For BLS addresses, Filecoin uses `curve bls12-381` for BLS signatures, which is a pair of two related curves, `G1` and `G2`. Filecoin uses `G1` for public keys, as G1 allows for a smaller representation of public keys and `G2` for signatures. This implements the same design as ETH2 but contrasts with Zcash, which has signatures on `G1` and public keys on `G2`. However, unlike ETH2, which stores private keys in big-endian order, Filecoin stores and interprets private keys in little-endian order. Public key addresses are often referred to by their shorthand, `f1` or `f3`. ## Actors Actor addresses provide a way to create robust addresses for actors not associated with a public key. They are generated by taking a `sha256` hash of the output of the account creation. The ZH storage provider has the actor address `f2plku564ddywnmb5b2ky7dhk4mb6uacsxuuev3pi` and the ID address `f01248`. Actor addresses are often referred to by their shorthand, `f2`. ## Extensible user-defined actors Filecoin supports extensible, user-defined actor addresses through the `f4` address class, introduced in [Filecoin Improvement Proposal (FIP) 0048](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0048.md). The `f4` address class provides the following benefits to the network: * A predictable addressing scheme to support interactions with addresses that do not yet exist on-chain. * User-defined, custom addressing systems without extensive changes and network upgrades. * Support for native addressing schemes from foreign runtimes such as the EVM. An `f4` address is structured as `f4f`, where `` is the actor ID of the *address manager*, and `` is the arbitrary actor ID chosen by that actor. An *address manager* is an actor that can create new actors and assign an `f4` address to the new actor. Currently, per [FIP 0048](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0048.md), `f4` addresses may only be assigned by and in association with specific, built-in actors called *address managers*. Once users are able to deploy custom WebAssembly actors, this restriction will likely be relaxed in a future FIP. As an example, suppose an address manager has an actor ID (an `f0` address) `123`, and that address manager creates a new actor. Then, the `f4` address of the actor created by the address manager is `f4123fa3491xyz`, where `f4` is the address class, `123` is the actor ID of the address manager, `f` is a separator, and `a3491xyz` is the arbitrary `` chosen by that actor. [Was this page helpful?](https://airtable.com/apppq4inOe4gmSSlk/pagoZHC2i1iqgphgl/form?prefill_Page+URL=https://docs.filecoin.io/basics/the-blockchain/addresses) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.filecoin.io/basics/the-blockchain/addresses.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.