A Hedera account has the following important components (there are others not relevant to this discussion):

• Balance of hbars (which may be zero)
• Account identifier
• Public key(s)

To create an account is to establish a new data structure in the consensus state with the above components. Once a crypto account is created, hbars can be moved out of the account (causing the balance to drop) only if the transactions directing such movements are cryptographically signed by the private key(s) associated with the public keys.

An account is created via a CryptoCreate transaction being sent to the network – this transaction created and submitted by the owner of an existing account. The creating account may transfer some hbars to the new account to fund the initial balance and will also pay a transaction fee for the creation. The CryptoCreate transaction will consequently need to be signed by the private key of the existing account as authorization for payment for both any initial balance and the fee.

The process to create an account involves two ‘users’. To illustrate the process, consider Bob and Alice.

Bob has an existing Hedera account. Bob is going to facilitate the creation of a new account for Alice. In this scenario Alice and Bob are physically collocated during the time of the creation process but it is also possible for them to interact online.

Alice will use MyHBARWallet.com (MHW), Bob will use the Hedera Mobile Wallet. Other combinations of wallets are possible and will follow the same general pattern.

The sequence of steps & messages is represented below:

Let’s explore each step.

Bob agrees to help create an account for Alice.

In MHW:

1. Alice clicks ‘Create New Account’.

2. (Not Shown) Alice will choose a mechanism for securing the new private key that MHW will generate. Currently, Alice can choose between storing the private key in encrypted form on her desktop or generating the private key from a BIP-39 mnemonic. MHW will soon support hardware wallets.

3. MHW will generate a public and private key pair. The key will be generated within the browser using a JavaScript library – the MHW server will not see the private key.

4. The MHW will display the newly generated public key.

MHW gives Alice two options for exporting her new public key – copying the public key or scanning a QR code in which the public key is encoded.

5. Alice chooses the QR code option and displays the QR code to Bob If Alice and Bob were not together, then Alice would copy the public key and send it to Bob.

In Bob's instance of the Hedera mobile wallet:

1. Bob clicks ‘Create Account’.

2. Bob imports Alice’s public key by scanning the QR code from Alice’s MHW browser window.

3. Bob can stipulate the initial balance to fund Alice’s account with.

4. Bob authorizes the transaction by clicking ‘Pay’.

Bob’s wallet will create a CryptoCreate transaction with the stipulated initial balance and Alice’s public key and use Bob’s private key to digitally sign the transaction. Of course, Bob doesn’t have Alice’s private key.

In the current version of the mobile wallet, Bob’s private key is stored within the wallet. Support for storing and protecting the private key within hardware wallets is coming.

5. After submitting the CryptoCreate transaction to the Hedera mainnet, the wallet will subsequently query for a receipt for that transaction. The returned transaction receipt will include the identifier of the newly created account. The wallet will display the account identifier of the new account to Bob.

6. Bob provides the new account identifier to Alice.

Back in MHW:

1. Alice clicks on ‘I have an Account ID’.

2. Alice enters in the account identifier as provided to her by Bob and clicks ‘Continue’.

3. MHW will refresh to show Alice’s new account and its balance.

At this point, Alice now has:

1. An account on the Hedera mainnet with the initial balance Bob provided from which only she can transfer the hbars.

2. The ability to interact with the new account via MHW. The private key associated with the new account will be protected by whatever mechanism Alice chose.

Bob paid for the creation of the account and its initial storage on the Hedera ledger. Once this initial storage period is over, Alice’s new account will need to pay for its own storage.

Before moving any additional hbars into the account (from an exchange perhaps), Alice should verify that she can spend from the account with the private key she has. How she accesses that private key will depend on whether she chose to store the private key in a keystore on her desktop, or to generate it with a mnenomic.

In addition to checking that her private key can successfully send hbars from the new account, Alice should check what public key(s) are associated with the new account.

If Bob is malicious, then it would be possible for him to attempt to, unbeknownst to Alice, add his public key to the account being created - either instead of or in addition to Alice’s public key. If he is able to do so, then it might be possible for him to subsequently transfer hbars out of that account without Alice’s involvement. This may or may not be appropriate.

Alice can defend herself against a corrupt Bob by checking the details of the created account before moving any more hbars into the account beyond the initial balance (which Bob provided).

The Hedera mobile wallet does not yet directly support such a check but nevertheless Alice can protect herself. Alice can use DragonGlass explorer (https://app.dragonglass.me/hedera/home) to reassure herself that the public key on her account is indeed hers and that no additional key has been associated with the account by Bob.

In DragonGlass, Alice:

1. Can enter the identifier of the new account.
2. Clicks on the eyeball under ‘Public key’.
3. DragonGlass will display the public key(s) associated with that account.

4. Alice can confirm that the displayed public key matches that previously generated by MHW and that she provided to Bob. If the public key is different, or there are additional public keys, then Alice should be concerned.

5. As an example, if Alice were to see that the public key was a threshold key like the below, then she should be concerned.

Even if her public key were one of the two listed keys, the above threshold key structure allows for either her key or the other to control spending from the account as the key structure logically says ‘at least 1 of these two keys must sign’ any transaction spending from the account. In a case such as this, Alice should not transfer any additional hbars into the account until the situation can be clarified.