# Accounts

## Accounts

Crypto Wallets (or Accounts) can be created and represented in unique ways on different blockchains. For developers who interface with account types on Swisstronik, e.g. during wallet integration on their dApp frontend, it is therefore important to understand that accounts on Swisstronik are implemented to be compatible with Ethereum-type addresses.

### Prerequisite Readings[​](https://docs.evmos.org/protocol/concepts/accounts#prerequisite-readings) <a href="#prerequisite-readings" id="prerequisite-readings"></a>

* [Cosmos SDK Accounts](https://docs.cosmos.network/main/basics/accounts.html)
* [Ethereum Accounts](https://ethereum.org/en/whitepaper/#ethereum-accounts)

### Creating Accounts[​](https://docs.evmos.org/protocol/concepts/accounts#creating-accounts) <a href="#creating-accounts" id="creating-accounts"></a>

To create one account you can either create a private key, a keystore file (a private key protected by a password), or a mnemonic phrase (a string of words that can access multiple private keys).

Aside from having different security features, the biggest difference between each of these is that a private key or keystore file only creates one account. Creating a mnemonic phrase gives you control of many accounts, all accessible with that same phrase.

Cosmos blockchains, like Swisstronik, support creating accounts with mnemonic phrases, otherwise known as [hierarchical deterministic key generation](https://github.com/confio/cosmos-hd-key-derivation-spec) (HD keys). This allows the user to create accounts on multiple blockchains without having to manage multiple secrets.

HD keys generate addresses by taking the mnemonic phrase and combining it with a piece of information called a [derivation path](https://learnmeabitcoin.com/technical/derivation-paths). Blockchains can differ in which derivation path they support. To access all accounts from a mnemonic phrase on a blockchain, it is therefore important to use that blockchain's specific derivation path.

### Representing Accounts[​](https://docs.evmos.org/protocol/concepts/accounts#representing-accounts) <a href="#representing-accounts" id="representing-accounts"></a>

The terms "account" and "address" are often used interchangeably to describe crypto wallets. In the Cosmos SDK, an account designates a pair of the public key (PubKey) and private key (PrivKey). The derivation path defines what the private key, public key, and address would be.

The PubKey can be derived to generate various addresses in different formats, which are used to identify users (among other parties) in the application. A common address form for Cosmos chains is the bech32 format (e.g. `swtr1...`). Addresses are also associated with messages to identify the sender of the message.

The PrivKey is used to generate digital signatures to prove that an address associated with the PrivKey approved of a given message. The proof is performed by applying a cryptographic scheme to the PrivKey, known as Elliptic Curve Digital Signature Algorithm (ECDSA), to generate a PubKey that is compared with the address in the message.

### Swisstronik Accounts[​](https://docs.evmos.org/protocol/concepts/accounts#evmos-accounts) <a href="#evmos-accounts" id="evmos-accounts"></a>

Swisstronik defines its own custom `Account` type to implement an HD wallet that is compatible with Ethereum-type addresses. It uses Ethereum's ECDSA secp256k1 curve for keys (`eth_secp265k1`) and satisfies the [EIP84](https://github.com/ethereum/EIPs/issues/84) for full [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) paths. This cryptographic curve is not to be confused with [Bitcoin's ECDSA secp256k1](https://en.bitcoin.it/wiki/Secp256k1) curve.

The root HD path for Swisstronik-based accounts is `m/44'/60'/0'/0`. Swisstronik uses the Coin type `60` to support Ethereum-type accounts, unlike many other Cosmos chains that use Coin type `118` ([list of coin types](https://github.com/satoshilabs/slips/blob/master/slip-0044.md))

#### Addresses and Public Keys[​](https://docs.evmos.org/protocol/concepts/accounts#addresses-and-public-keys) <a href="#addresses-and-public-keys" id="addresses-and-public-keys"></a>

[BIP-0173](https://github.com/satoshilabs/slips/blob/master/slip-0173.md) defines a new format for segregated witness output addresses that contains a human-readable part that identifies the Bech32 usage. Swisstronik uses the following HRP (human readable prefix) as the base HRP:

| Network     | Testnet |
| ----------- | ------- |
| Swisstronik | `swtr`  |

There are 3 main types of HRP for the `Addresses`/`PubKeys` available by default on Swisstronik:

* Addresses and Keys for **accounts**, which identify users (e.g. the sender of a `message`). They are derived using the **`eth_secp256k1`** curve.
* Addresses and Keys for **validator operators**, which identify the operators of validators. They are derived using the **`eth_secp256k1`** curve.
* Addresses and Keys for **consensus nodes**, which identify the validator nodes participating in consensus. They are derived using the **`ed25519`** curve.

|                    | Address bech32 Prefix | Pubkey bech32 Prefix | Curve           | Address byte length | Pubkey byte length |
| ------------------ | --------------------- | -------------------- | --------------- | ------------------- | ------------------ |
| Accounts           | `swtr`                | `swtrpub`            | `eth_secp256k1` | `20`                | `33` (compressed)  |
| Validator Operator | `swtrvaloper`         | `swtrvaloperpub`     | `eth_secp256k1` | `20`                | `33` (compressed)  |
| Consensus Nodes    | `swtrvalcons`         | `swtrvalconspub`     | `ed25519`       | `20`                | `32`               |

#### Address formats for clients[​](https://docs.evmos.org/protocol/concepts/accounts#address-formats-for-clients) <a href="#address-formats-for-clients" id="address-formats-for-clients"></a>

`EthAccount` can be represented in both [Bech32](https://en.bitcoin.it/wiki/Bech32) (swtr`1...`) and hex (`0x...`) formats for Ethereum's Web3 tooling compatibility.

The Bech32 format is the default format for Cosmos-SDK queries and transactions through CLI and REST clients. The hex format on the other hand, is the Ethereum `common.Address` representation of a Cosmos `sdk.AccAddress`.

* **Address (Bech32)**: `swtr1qa2h6a27waactkrc6dyxrn2jzfjjfg24dgxzu8`
* **Address (**[**EIP55**](https://eips.ethereum.org/EIPS/eip-55) **Hex)**: `0x07557D755E777B85D878D34861CD52126524A155`

#### Address conversion[​](https://docs.evmos.org/protocol/concepts/accounts#address-conversion) <a href="#address-conversion" id="address-conversion"></a>

The `swisstronikd debug addr <address>` can be used to convert an address between hex and bech32 formats. For example:

Bech32

```
 $ swisstronikd debug convert-address swtr1qa2h6a27waactkrc6dyxrn2jzfjjfg24dgxzu8
    Address bytes: [7 85 125 117 94 119 123 133 216 120 211 72 97 205 82 18 101 36 161 85]
    Address (hex): 07557D755E777B85D878D34861CD52126524A155
    Address (EIP-55): 0x07557D755E777B85d878D34861cd52126524a155
    Bech32 Acc: swtr1qa2h6a27waactkrc6dyxrn2jzfjjfg24dgxzu8
    Bech32 Val: swtrvaloper1qa2h6a27waactkrc6dyxrn2jzfjjfg24x9fqs6
```

Hex

```
 $ swisstronikd debug convert-address 07557D755E777B85D878D34861CD52126524A155
    Address bytes: [7 85 125 117 94 119 123 133 216 120 211 72 97 205 82 18 101 36 161 85]
    Address (hex): 07557D755E777B85D878D34861CD52126524A155
    Address (EIP-55): 0x07557D755E777B85d878D34861cd52126524a155
    Bech32 Acc: swtr1qa2h6a27waactkrc6dyxrn2jzfjjfg24dgxzu8
    Bech32 Val: swtrvaloper1qa2h6a27waactkrc6dyxrn2jzfjjfg24x9fqs6
```


---

# 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.swisstronik.com/swisstronik-docs/general/accounts.md?ask=<question>
```

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.