Harmony is an open and fast blockchain. Our mainnet runs Ethereum applications with 2-second transaction finality and 1000 times lower fees.

Harmony is your open platform for assets, collectibles, identity, governance.

Build on Harmony

This Gitbook document has introduction and resources for all audience:

Bridge to All Chains

Harmony’s 2025 roadmap focuses on achieving 1-second finality, unifying decentralized finance, and creating an open AI ecosystem.

We are continuously upgrading our protocol for seamless performance with enhancements such as Verkle Trees, State Expiry, and improved network resilience through Stream Sync and Leader Rotation. These innovations power platforms like pump.one for memecoin creation and exchange.one for stablecoins and perpetual trading. Meanwhile, the .country top-level domains enable AI agents to own self-custodial wallets and domains.

We aim to simplify DeFi, expand liquidity, and attract new users. Innovations such as yield enhancer and perpetual options markets, combined with AI-driven frameworks like Eliza OS—empowering autonomous agents for trading, governance, and decision-making—are designed to make DeFi intuitive and accessible to everyone. By leveraging AI to create cult-like memes and autonomous agents that amplify engagement through viral narratives and real-time market insights, we aim to redefine community-driven finance with creativity and precision.

These advancements aim to onboard millions of DeFi assets, billions of community memes, and trillions of intelligent models. Together, these efforts reflect our vision for 2025: building a blockchain that is fast, simple, and accessible to everyone.

Read more:

Harmony in 2021 will focus on adoption through developers and partners. We will continue to strengthen our network features, to lead industry in our cross-chain architecture, and to engage broad ecosystem to build with us. There will be explosive growth and new applications this year in blockchains — Harmony is ready to be leading a part of this global fintech revolution.

Towards our mission, Harmony’s current strategy is “Cross-Chain Finance” as decentralized finance and interoperable protocols are the product-market fit in 2021. We are building trustless bridges to Bitcoin and Ethereum for broader access of users and assets with Harmony as a hub. An example of utility is a cross-chain exchange without custodial risks. Our current settlement layer and soon liquidity infrastructure will enable further financial innovations, leading to cross-exchange integrations and cross-border finance.

Read more:

Crypto Startup School

Crypto Thesis for 2021

NFT Canon

‌Harmony is a fast and secure blockchain for decentralized applications. Our production mainnet supports 4 shards of 1000 nodes, producing blocks in 2 seconds with finality.

Our Effective Proof-of-Stake (EPoS) reduces centralization while supporting stake delegation, reward compounding and double-sign slashing.

Harmony aims to build an open network of nodes operated and governed by a large community. This node community is called Pangaea.

Are we decentralized yet? There’s no consensus without participation. There are now 1,000 Harmony nodes – so far 800 of them run by the community – in line with thousands of Bitcoin and Ethereum nodes. Pangaea consists of volunteers and validators from more than 100 countries and most of them have never run a node before.

Key Innovations

Fully Scalable Architecture

Harmony’s sharding works not only on the network communication and transaction validation, but also on the blockchain state. This makes Harmony fully scalable on all three aspects of the blockchain: network, storage and transaction processing.

Secure Random Sharding

Harmony’s sharding process is provably secure against shard attacks because the network validators are randomly assigned and shuffled among shards. The randomness used in the sharding is obtained with a distributed randomness generation algorithm (based on VRF and VDF) which is unpredictable, un-biased, verifiable and scalable. Harmony reshards the network in a non-interruptive manner using “Cuckoo Rule” to prevent against slowly adaptive byzantine adversaries.

Efficient and Fast Consensus

Harmony’s consensus algorithm is called Fast Byzantine Fault Tolerance or FBFT. FBFT is a highly efficient and speedy consensus algorithm built upon the famous PBFT (Practical Byzantine Fault Tolerance) algorithm which is the cornerstone for distributed systems and consensus research for the past 30 years. Harmony’s FBFT is able to confirm blocks within 2 seconds thanks to the adoption of aggregated BLS (Boneh–Lynn–Shacham) signature. FBFT is also highly optimized in network message processing and block proposal pipelining so that the consensus can scale to hundreds of validators at the same time.

Effective Proof-of-Stake

Unlike traditional blockchains which require PoW (Proof of Work) to reach consensus, Harmony is a Proof-of-Stake blockchain which is energy efficient and low-cost for node runners. The process to elect validators is called Effective Proof-of-Stake (EPoS) which is the first sharding-focused PoS mechanism that prevents stake centralization. In EPoS, validators with a large amount of staked tokens are obligated to run more nodes to support the network while validators with less stake run fewer nodes. Besides, EPoS is able to randomly and evenly distribute the stakes among all shards so no shard is less secure than other shards.

Scalable Networking Infrastructure

Harmony’s network layer is based on the industry-leading p2p protocol named libp2p. We use libp2p’s gossip protocol for network message broadcasting and stream protocol for decentralized state synchronization. To achieve high performance, we adopt RaptorQ fountain code and use Adaptive Information Dispersal Algorithm to quickly and efficiently broadcast large blocks. Harmony also features a design where Kademlia routing is used to achieve cross-shard transactions that scale logarithmically with the number of shards.

Asynchronous Cross-Shard Transactions

Harmony supports cross-shard transactions to achieve composability of assets between shards. We designed a receipt-based asynchronous cross-shard communication mechanism which achieves eventual consistency so no double-spending is possible between shards.

Fun Facts

Why is the project called “Harmony”?

Harmony is the beautiful music when we sing in different notes but resonate. It’s analogous to our high-performance protocol of multiple shards but reaching consensus.

Why is the token called “ONE”?

Harmony’s vision is “For One and For All,” creating open consensus for 10 billion people.

Why is the logo designed as such?

Secure, Random State Sharding

Harmony has transcended the blockchain trilemma by bringing the best research to production. Sharding is proven to scale blockchains without compromising security and decentralization.

We divide not only our network nodes but also the blockchain states into shards, scaling linearly in all three aspects of machines, transactions and storages.

To prevent single shard attacks, we must have a sufficiently large number of nodes per shard and cryptographic randomness to re-shard regularly. Each shard has 1/4 of nodes for strong security guarantee against Byzantine behaviors. We use Verifiable Random Function (VRF) for un-biased and unpredictable shard membership.

Fast Consensus w/ Instant Finality

Harmony has innovated on the battle-tested Practical Byzantine Fault Tolerance (PBFT) for fast consensus of block transactions. Our Fast BFT (FBFT) leads to low transaction fees and 1-block-time finality in Harmony Mainnet.

We use Boneh–Lynn–Shacham (BLS) constant-sized signatures to commit blocks in a single round of consensus messages. We achieve 2-second block time with view changes in production against adversarial or unavailable leaders.

Harmony Mainnet was launched in June 2019. Our network has produced 30M+ blocks with 450k+ transactions in publicly traded, native ONE tokens.

Effective PoS & Token Economics

Harmony has designed a novel Proof-of-Stake (PoS) mechanism for network security and economics. Our Effective Proof-of-Stake (EPoS) reduces centralization and distributes rewards fairly to thousands of validators.

Our staking mechanism supports delegation and reward compounding. To support 100% uptime but fully open participation, EPoS slashes validators who double-sign and it penalizes elected but unavailable nodes.

Harmony Economics Model caps the annual issuance at 441 million tokens (about 3% rate in long term). Our model gives validators a simple and predictable return. All transaction fees are burnt to offset the issuance, naturally leading to zero inflation when our network usage becomes high.

On-chain Verifiable Randomness

Harmony allows smart contracts to receive random numbers on chain, using a Verifiable Random Function (VRF) powered by distributed randomness generation (DRG). This allows any DAPP in the Harmony ecosystem to leverage randomness without relying on off-chain oracles.

Harmony’s sharding approach depends on a secure randomness source so the validators can be assigned to shards in a truly random manner to avoid single-shard attacks. Harmony designed a distributed randomness generation (DRG) protocol which involves both VRF (Verifiable Random Function) and VDF (Verifiable Delay Function) to achieve the follows key properties:

1. Unpredictable: No one should be able to predict the random number before it is generated.

2. Un-biased: The process of generating the random number should not be biasable by any participant.

3. Verifiable: The validity of the generated random number should be verifiable by any observer.

4. Scalable: The algorithm of randomness generation should scale to a large number of participants.

Since the random assignment (resharding) of validators only happens every epoch, Harmony’s DRG protocol only needs to execute once per epoch. It works as follows:

1. During the epoch, each validator takes turns to become the FBFT leader and at the end of the epoch, all validators should have become leader for at least once. Each new leader runs VRF to create a random number R and a proof P using its BLS key. The random number and the proof will be attached to the first proposed block by the leader, which will be verified by the validators and committed to the blockchain.

2. As soon as more than 2/3 of the validators have done the VRF submission, the immediate next leader will combine all the submitted random numbers with an XOR operation to get the preimage pRnd of the final randomness.

3. The leader runs FBFT among all the validators to reach consensus on the pRnd and commit it in block.

4. After pRnd is committed, the leader starts computing the actual randomness Rnd=VDF(pRnd, T), where T is the VDF difficulty and is set algorithmically such that the randomness can only be computed after k blocks.

5. Once Rnd is computed, the leader initiates a FBFT among all validators to agree on the validity of Rnd and finally commit the randomness into the blockchain.

The VDF (Verifiable Delay Function) is used to delay the revelation of the final randomness in order to be secure against last-revealer-attack.The VDF is used to provably delay the revelation of Rnd and prevent the last leader from biasing the randomness by choosing to submit or not the last random number. Because of the VDF, the last leader won’t be able to know the actual final randomness before pRnd is committed to the blockchain. By the time Rnd is computed with the VDF, pRnd is already committed in a previous block so the leader cannot manipulate it anymore. Therefore, the most a malicious leader can do is to either blindly commit the randomness pRnd, or stall the protocol by not committing pRnd. The former is the same as the honest behavior. The latter won’t cause much damage as the timeout mechanism in FBFT will be triggered to switch the leader.

In the updated economic model of our network, the total reward across the network (issuance plus transaction fees) will remain constant regardless of average block time and staking ratio. The goal of this change is to achieve a higher staking ratio, to simplify the model and to create a path to 0 issuance, all of which we believe will bring long term benefits for Harmony.

ONE Token

ONE is the native token for Harmony which supports the monetary flow of the entire Harmony economic system. ONE has 18 decimals.

The smallest unit of ONE is called Atto, which is 0.000000000000000001 ONE. (equivalent to Wei in Ethereum).

The second smallest unit of ONE is called Nano, which is 0.000000001 ONE (equivalent to Gwei in Ethereum)

Utility of ONE

ONE token has several important utilities that’s required for using the network and is essential to the security of the network.

Pay for transaction fee

ONE token is the native token for paying transaction fees. Users need to specify a certain amount of transaction fee in ONE so the transaction can be successfully processed and included in the blockchain.

Stake to secure the network and earn reward

Harmony is a Proof-of-Stake blockchain which means the security of the network is protected by staked tokens. ONE token is the native token that’s accepted for staking. Potential node runners need to stake a certain amount of ONE token to be elected as a validator. ONE token holders are also able to delegate their ONE tokens to existing validators to participate in the staking process. The more ONE token staked, the more secure the network becomes. Elected validators who successfully sign blocks will receive block rewards in ONE tokens as compensation for their services.

Participate in open governance

Harmony is a permission-less and decentralized network which is governed by the community. Any protocol level decisions or improvements will be put as a proposal which will go through the open governance process to finalize. ONE is the only accepted token used as the measure for voting in the governance process.

The LayerZero-Harmony Bridge Interface (“Interface”) is an interface that facilitates use of a third-party cross-chain communication system (“Bridge”) that is designed to enable users to send messages between certain blockchains to enable the exchange of crypto assets between such blockchains. Your use of the Interface and the Bridge is entirely at your own risk.

The Interface and the Bridge are available on an “as is” basis without warranties of any kind, either express or implied, including, but not limited to, warranties of merchantability, title, fitness for a particular purpose and non-infringement.

You assume all risks associated with using the Interface and the Bridge, and digital assets and decentralized systems generally, including but not limited to, that: (a) digital assets are highly volatile; (b) using digital assets is inherently risky due to both features of such assets and the potential unauthorized acts of third parties; (c) you may not have ready access to assets; and (d) you may lose some or all of your tokens or other assets. You agree that you will have no recourse against anyone else for any losses due to the use of the Interface or the Bridge. For example, these losses may arise from or relate to: (i) incorrect information; (ii) software or network failures; (iii) corrupted cryptocurrency wallet files; (iv) unauthorized access; (v) errors, mistakes, or inaccuracies; or (vi) third-party activities.

The Interface and the Bridge do not collect any personal data, and your interaction with the Interface and the Bridge will solely be through your public digital wallet address. Any personal or other data that you may make available in connection with the Bridge may not be private or secure.

Transaction Finality

Block finality refers to the concept that a proposed block is finalized by the blockchain and can not be reverted or the cost of reversion is prohibitively high. Block finality is usually measured by how long it takes for the newly proposed blocks to be finalized. For example, in Ethereum, it takes more than 6 blocks or 1 minute to have reasonable confidence that the block is finalized and can not be reverted.

Thanks to the nature of Harmony‘s FBFT consensus, blocks can be finalized as long as the 2/3 majority quorum is reached on the block. On Harmony mainnet, it now takes 2 seconds to finalize a newly proposed block and the transactions inside. Read more about our 2-second finality here:

Transaction Fees

Harmony follows the same transaction fee model as Ethereum where users pay a certain amount of tokens to get their transactions processed and included in the blockchain. Since Harmony is fully EVM-compatible, users can translate directly the fee model from Ethereum and apply to Harmony. For example, a normal token transfer transaction cost 21000 gas. The gas price can be as low as 0.0000001 ONE (or 100 Gwei as in Ether) since Harmony have high TPS and the network is highly efficient and rarely clogged. This means a normal transfer cost only about 0.0021 ONE. In General, transactions in Harmony network cost around $0.00003 gas fee.

The reason for Harmony to be able to afford such low fee is twofold. First, Harmony is Proof-of-Stake chain where the cost of running a node is much cheaper than PoW chains as no wasteful computation is needed. Second, Harmony is a highly scalable blockchain which currently provide thousands of transactions per seconds as throughput. This means users don't need to bid with high fee to get their transaction processed in time. We expect the low fee situation will stay as long as Harmony network is not fully utilized and even if that happens, we can solve the problem by extending the network with more shards to provide more transaction processing power.

Cross-Shard Smart Contract Transaction

We will adopt the asynchronous cross-shard communication model just like we did for cross-shard ONE token transfer. Meaning any smart contract which needs to call another smart contract from another shard will have the sender contract transaction finalized first at initiating shard, then a receipt will be created including the call data, and finally the receipt will be sent and processed at the destination shard.

A new Opcode “CALL2” will be added to the virtual machine which is used for a cross-shard smart contract call.

CALL2’s input is similar to CALL but with an another shardID parameter:

(caller ContractRef, addr common.Address, input []byte, gas uint64, value *big.Int, shardID uint32)

Unlike CALL which actually executes the contract code within the same shard, CALL2 won’t run any code but only lead to the creation of a receipt after the transaction is successfully confirmed in this block. The receipt structure can be like this:

// CXReceipt represents a receipt for cross-shard transaction
type CXReceipt struct {
  TxHash    common.Hash // hash of the cross shard transaction in source shard
  Sender    common.Address
  From      common.Address
  To        common.Address
  ShardID   uint32
  ToShardID uint32
  Input     []byte
  Amount    *big.Int
  Gas       uint64
}

Specifically:

• TxHash: the transaction hash of the original transaction sent from the real user

• Sender: the address of the transaction sender

• From: the address of the caller smart contract which initiated the cross-shard call

• To: the address of the callee smart contract in another shard

• ShardID: the shardID of the caller smart contract

• ToShardID: the shardID of the caller smart contract

• Input: the input data for the smart contract call, exactly like the payload of a normal intra-shard transaction that calls a smart contract

• Amount: is the among of ONE that is sent along with the call to the callee smart contract

• Gas: the gas that’s going to be paid to the destination shard.

Once the corresponding block of the receipt is finalized, a proof data for the receipt will also be generated. This is exactly the same as cross-shard ONE token transfer:

// CXReceiptsProof carrys the cross shard receipts and merkle proof
type CXReceiptsProof struct {
  Receipts     CXReceipts
  MerkleProof  *CXMerkleProof
  Header       *block.Header
  CommitSig    []byte
  CommitBitmap []byte
}

Once the receipt and proof are obtained, they will be sent from source shard to destination shard (CXReceipt.ToShardID) for processing.

The destination shard process the cross-shard smart contract receipt by:

1. Verify the receipt is valid using the proof data

2. Use the CXReceipt.To as the callee smart contract address and CXReceipt.Input data as the contract call data for contract execution. CXReceipt.Amount and CXReceipt.Gas are also used the same way as normal contract calls.

3. If this contract call produces additional cross-shard contract calls. Additional receipts will be generated and the same cross-shard call process will happen.

Design Questions:

1. What if the callee contract doesn’t exist in the destination shard?

   1. We could simply abort the cross-shard call but credit the gas to the destination shard. This way, we don’t need another cross-shard receipt to go back to the source shard to credit the gas.

   2. Or we could create a brand new contract. This requires the receipts include the contract bytecode which can be user specified or the same as the caller contract’s code (in case of HRC20 contract replication across shards)

2. What if the gas sent in the receipt is not enough to pay for the transaction?

   1. Simply abort the contract call as a normal transaction “Out of Gas” situation.

3. In any failure cases of the cross-shard contract call. The sent token in CXReceipt.Amount should be credited to?

   1. The sender address in the destination shard. This avoids having to send another cross-shard receipt to credit the token back to the sender shard.

What is LayerZero bridge?

LayerZero is a cross-chain bridge that allows exchange of crypto assets (e.g., fungible/non-fungible tokens, stablecoins) between Ethereum or Binance Smart Chain and Harmony blockchains.

The Bridge is used to migrate assets from one chain to another. If you have assets on Ethereum or Binance Smart Chain, you can use the bridge to move them to Harmony blockchain and get corresponding assets on Harmony. LayerZero also allows redemption of the exchanged assets back at any time.

Is there a tutorial explaining how to use LayerZero?

What account can I use to receive bridged tokens?

You need to be able to open your wallet in the network you sent your tokens to. Check that there are no network restrictions that prevents you from it. Also check if there is no limitations on a token type you can receive. Never send tokens to an exchange account!

Can I bridge tokens to the contract address?

No, bridging to contract address directly is not supported. It might result in permanent loss of your tokens.

What token will I get after bridging?

Bridge transfer completed but I can't see in metamask?

What kind of assets can be bridged using LayerZero?

Oracle 1LINK

Natives

• 1ONE (Wrapped ONE on Ethereum) - no redeploy required

• bscONE (Wrapped ONE on BSC) - no redeploy required

• ETH

• 1ETH

• bscONE (Wrapped ONE on BSC) - no redeploy required

• BNB

• bscBNB (Wrapped BnB on Harmony)

• 1WBTC

Stablecoins

• 1USDC

• 1USDT

• 1DAI

• 1BUSD

• bscBUSD

Partners

• 1AAG - no token redeploy

• 1FRAX

• 1FXS

• 1SUSHI

• xSUSHI

• 1AAVE

How are assets mapped between blockchains?

Assets are mapped 1:1. For example, 10 BUSD on Ethereum after bridging will be available as 10 1BUSD on Harmony. Here, “1BUSD“ is the token symbol of the token on Harmony corresponding to “BUSD“ token symbol on Ethereum.

Same 1:1 mapping holds true for Binance Smart Chain. However, the assets from two different parent chains (Ethereum or Binance Smart Chain) after bridging will be represented using different bridged assets on Harmony. For instance, 5 Binance Smart Chain BUSD after bridging will be available as 5 bscBUSD on Harmony. Here, “bscBUSD” is the token symbol of the token issued on Harmony corresponding to “BUSD” token symbol on Binance Smart Chain.

And, the 1BUSD and bscBUSD on Harmony chain are not interchangeable, meaning one cannot bridge BUSD from Ethereum to Harmony and then withdraw it on Binance Smart Chain. Same for other tokens.

Can I bridge as many tokens as I want, or is there a limit?

There is no limit on the amount of tokens that can be bridged.

Can I send my bridged tokens back?

Yes: you can bridge tokens back and receive back the same amount of the original token there. For example, you bridged USDC from Ethereum to Harmony and got 1USDC token on Harmony. At any time you can bridge 1USDC back to Ethereum and receive USDC token.

Can I send the Ethereum bridged tokens to Binance?

No, Ethereum bridged tokens can only be sent back to Ethereum. Same applies for Binance bridged tokens.

Can I send bridged tokens from Harmony blockchain to other blockchains or exchanges?

No, do NOT send bridged tokens directly to other blockchains or exchanges. This will not work and might result in permanent loss of your tokens. Bridged tokens can only be used on Harmony network. The only way to send them out is bridging them back.

Are bridged tokens transferable?

Yes. You can transfer the bridged tokens to other users, and they can redeem them back to their Ethereum or Binance accounts. This is possible because when you lock your token, it gets pooled into a bridge smart contract from which any redeem request can be serviced without tying the locked tokens and redemption to a specific user account.

What happens to my original tokens after I bridge them to Harmony?

Once you use LayerZero to transfer your original tokens to Harmony, the original tokens get stored and locked in the LayerZero contracts: you do not own those tokens on Ethereum or Binance anymore. You receive the same amount of tokens on the Harmony blockchain.

Does the token supply increase when using LayerZero?

No: The supply of the original token never change as a result of using LayerZero: LayerZero bridge locks a certain amount of a token on Ethereum blockchain (essentially taking it out of circulation) and mints the exact same amount of tokens on the Harmony blockchain, that represents in all respects the original token (i.e. regenerating the locked supply). As a result, the circulating supply of the original token will stay the same: it's just split across two different blockchains instead of one.

Which coins do I need to pay the transaction fees on the bridge?

It depends on which blockchain you want transfer assets from. If it is from Harmony blockchain, you need ONE tokens, if it is from Ethereum you need ETH tokens, from Binance Smart Chain (BSC) BNB tokens and so on.

What’s the cost of using the bridge?

Cost of the bridge operation consists of the LayerZero bridge fee and costs of transactions. You'll see the page with the fee information that you need to confirm before the operation. Transaction fee depends on the chain gas prices and are confirmed in Metamask before the transaction. LayerZero fees are calculated dynamically based on Oracle and Relayer prices for the destination chain. They are transferred in the same transaction as the bridges amount. Fees are paid in native tokens of the first chain, so if you transfer any token from Ethereum, you pay fees by ETH token, ONE for Harmony and BNB for Binance.

How to find out what's with my bridge operation?

Transaction pending for too long

Operation in progress for too long

Operation status is success, but I can’t find my tokens

• Note that:

• Bridge is not a swap, and you won't receive ONE if you weren't bridging ONE token.

• A token address is never the same in the different networks, even when a symbol is the same.

• If you added a token and tokens aren’t shown, check that:

• You added a token to the receiver wallet of your operation.

• The receiver address of your operation is correct. If you found out that you made a mistake in the address, we can’t help you with that. You can reach your funds only if you have access to the wallet.

• The receiver wallet is connected to the correct network. For example, if you bridged tokens to Harmony, you need to be connected to Harmony mainnet.

• You’ve added a token that you really received. Check the transaction data.

• Tokens haven’t been transferred after the bridge.

Bridge error, funds lost

I can’t bridge because of an error

There can be many possible causes. Sometimes the reason is clear from the error message (for example, low balance, not enough tokens to cover gas). Often there is a problem with the wallet connection. Try these steps to solve it:

• Make sure your browser and the wallet extension are updated to the latest version

• Make sure that your browser doesn’t block pop-up windows.

• Try to clear the cache and relogin.

• Try using another browser or/and wallet extension.

• If you use a mobile version, try it on the desktop.

By mistake sent tokens to an exchange wallet (e.g. Binance exchange)

Unfortunately, your tokens are permanently lost and not recoverable.

I sent tokens to a wallet that doesn’t support the network I used

If you can’t open your wallet in the network where your tokens were sent, we can’t assist. You can try to reach a support of the service that gave you this account.

By mistake sent tokens to a wrong address or a token address

Unfortunately, we can't help in such case. We don't have access needed to transfer tokens between accounts.

I have a question about the LayerZero bridge

Here you can specify the network by pressing its button. If your token is on Binance or Ethereum, it can help you to avoid confusion. You can also set a filter by a token type if you know it.

Search a token you plan to bridge. You can enter its address / symbol / name.

Click on the paired token address, and it will lead you to the token page.

There are tokens named the same in the different networks, but they always have different addresses. Compare token address and name to your token data to avoid a confusion.

If you bridge a token from the network where it was issued, you receive a mapped token. Usually it has a prefix in the name that indicates a wrap.

If you have a token on Harmony that is originated from Binance or Ethereum, you can bridge it back only to the network it came from. As a result you’ll get the origin token.

Frequently bridged tokens:

ONE

BNB

ETH

BUSD

DAI

USDC

USDT

Harmony blockchain is sharded in three dimensions: state, network and transaction.

State Sharding

In Harmony, each shard maintains it's own chain of blocks and state database. Therefore, the validators of each shard only need to store 1/N of the global state, where N is the number of shards. The consistency between states from different shards are guaranteed by the property of eventual atomicity of cross-shard transactions, which guarantees that double spending between shards can not happen.

Network Sharding

Harmony's validator network is also divided into shards where each shard involves a separate set of validators connected closely with each other and running consensus between themselves. Most of the time, validators communicate with other validators within the same shard to reach consensus or synchronize blocks. In cases of cross-shard transactions and beacon chain synchronization, validators from different shards send messages across shards through the globally connected network.

Transaction Sharding

Transactions in Harmony blockchain are sent to and processed by a specific shard instead of all shards. This way, shards can process transactions in parallel which greatly improves the overall transaction processing capacity of the blockchain. Users need to specify a field named shard_id in the signed transaction which indicates which shard this transaction belongs to. For cross-shard transactions, another field named to_shard_idis needed to indicate the destination shard while the shard_id field indicates the source shard.

Epochs

An epoch in Harmony blockchain is a pre-determined period of time when the validator committees of shards stay unchanged. In Harmony mainnet, one epoch is 32768 blocks which translates to around 18.2 hours. In Harmony testnet, one epoch is 8192 blocks which is around 4.6 hours.

When one epoch ends, the election for the new validator committees will be conducted in beacon chain and the result (i.e. shard state) will be written in the last block of the epoch in the beacon chain. After that, beacon chain enters the new epoch with the new validator committee producing blocks. Once beacon chain enters new epoch, all the other shards will follow and also enters the new epoch. The new shard state from the beacon chain will be written in the new block of the shards which also marks the last block of the epoch for that shard.

Crosslinks

Crosslink is an important piece of data which is sent from shard chains and stored in beacon chain. A crosslink contains data for block signatures and the block identifier data such as block hash, block number, view id and epoch etc. When a new block is confirmed in a shard chain, the corresponding crosslink will be created and sent to the beacon chain. Upon the receipt of the crosslink, the beacon chain verifies its signature and checks that it’s from the canonical chain of the shard. Successfully verified crosslinks will be added in the new block of the beacon chain to permanently endorse the block of the shard chain as canonical. Shard chain blocks without corresponding crosslinks endorsed in the beacon chain won’t be recognized by the network and will be deemed as invalid blocks.

Besides serving the purpose of marking canonical blocks of the shard chains, crosslinks are also used to record and tally the signing activity of the shard chain validators. Since epoch transition and EPoS election happens only on beacon chain, the validator signing activity from shard chains are sent to the beacon chain via the crosslink so it can be used for block reward calculation and uptime calculation which affect the validator’s election status.

You can find your token from your final step transaction if it’s correctly displayed (sometimes there are delays in data representation).There is a token symbol near the amount in “Tokens transferred”/ ”Token transfers” section that leads to the token page.

You can also look for the token in a token list on your wallet address page in the target chain explorer (it also can take some time for a token to appear).

Click on the token symbol, and you’ll see all necessary token information.


Don’t forget, that address should be in ETH style (starting 0x...). For Harmony Explorer, there is a switcher in the top right corner.

If you can’t find your token there, please use this page to find a token address you should have after the bridge.

Check that you add token to a receiver wallet of your operation and the wallet is connected to the correct network.

Where do I get Harmony One?

What Wallets accept Harmony One?

What DApps work with Harmony One?

What is Staking?

For those wishing to participate in staking without running a validator, delegation is the best approach to still get involved and earn block rewards. The act of delegating tokens and earn rewards is called staking.

The earned block rewards are stored in a separate reward balance of the delegator, which can be immediately withdrawn to the delegator’s account balance. The block rewards can also be staked again to achieve the compounding effect of staking.

Your delegated tokens are also associated with slashing risks of the validator. As a delegator, you should carefully choose validators based on their historical performance metrics such as APR, uptime and commission. In case of indifference or indecisiveness, you should distribute your delegations among multiple validators in order to minimize risk.

How to Stake?

New Delegators Quick, Simple Walkthrough:

✍️ Using the new extension create a new wallet or recover an existing one using seed words.

👀 Choose a validator (or a few)

💰 Stake your tokens

🤑 Earn block rewards every 2 seconds.

More Questions?

Fast Byzantine Fault Tolerance (FBFT)

The consensus algorithm is a key component of any blockchain. It determines the security and performance of a blockchain and is often referred to as the "engine" of a blockchain. Harmony’s consensus algorithm is called Fast Byzantine Fault Tolerance (FBFT), which is an innovative upgrade on the famous PBFT algorithm. FBFT is one order of magnitude faster and more scalable than PBFT because BLS (Boneh–Lynn–Shacham) aggregate signature is used to significantly reduce the communication cost. Specifically, FBFT allows at least 250 validators to reach consensus within 2 seconds.

For every round of consensus in FBFT, one validator serves as the “leader” and there are three phases: the announce phase, the prepare phase and the commit phase. In the announce phase, the leader proposes a new block and broadcasts the block hash to all of the validators. In the prepare phase, validators verify the message and sign on the block hash, as well as sending the signature back to the leader. The prepare phase finishes when signatures with more than 2/3 of the voting power are collected. After that, the leader aggregated the collected signatures into a O(1)-sized BLS aggregate signature and then broadcast it with the whole block to start the commit phase. The commit phase involves validators verifying the block and doing a similar signing process as the prepare phase (i.e. 2/3 voting power collection). The consensus is reached after the commit phase is done. This whole process can be done within 2 seconds in mainnet.

Specifically, Harmony’s FBFT consensus involves the following steps:

1. The leader constructs the new block and broadcasts the block hash to all validators. This is called the “announce” phase.

2. The validators check the validity of the message, sign the block hash with a BLS signature, and send the signature back to the leader.

3. The leader waits for valid signatures with more than 2/3 voting power from validators (including the leader itself) and aggregates them into a BLS aggregate signature. Then the leader broadcasts the new block and the aggregated signature along with a bitmap indicating which validators have signed. Together with Step 2, this concludes the “prepare” phase.

4. The validators check that the aggregate signature has at least 2/3 of total voting power, verify the new block, sign the received block from Step 3, and send it back to the leader.

5. The leader waits for valid signatures with more than 2/3 voting power (can be different signers from Step 3), aggregates them together into a BLS aggregate signature, and creates a bitmap for all the signers. Finally, the leader commits the new block with the aggregate signatures and bitmaps into local DB, and broadcasts the aggregate signature and bitmap for all validators to confidently commit the block too. Together with Step 4, this concludes the “commit” phase.

Synchronous View Change

One of the drawbacks of BFT-based consensus is the potential stallment of the consensus if the leader is malicious. The solution to this in PBFT algorithm is the additional view change protocol on top of the consensus which is able to switch leaders when the consensus is stalled. The view change in PBFT works well in the traditional distributed system setting but it fails in the more complicated blockchain space. Particularly, the view change in PBFT is relying on the timeout mechanism where the timer is triggered based on the live progress of the consensus. This works fine if the nodes are always online and are in sync with the consensus progress. However, this won’t be true in the real world situation where nodes can be down for extended time or restarted due to machine crash, which will make the nodes having inconsistent view IDs and not able to make progress in the view change.

We solve this problem by using an improved version of the view change protocol that’s fully synchronous based on the local clock rather than assuming the liveness of the nodes. Specifically, instead of setting the validator’s view ID based on the live progress of the consensus, the view ID is calculated based on the elapsed time of the last successfully committed block’s timestamp. Of course, there is no global clock to rely on in the calculation of elapsed time. Each validator will use their own local clock for that. However, this is totally fine as long as more than 2/3 of the validators maintain a relatively accurate local clock that’s not drifting by a few seconds. This is achievable in the protocol to make validators to periodically synchronize its local clock with NTP time.

This improvement makes our view change protocol fully robust and functional as long as more than 2/3 of the honest validators are online, guaranteeing the liveness of the FBFT consensus. Besides, BLS aggregate signatures are also used in the view change protocol to reduce network communication cost, making it a very efficient process which takes a few seconds to finish.

Harmony is one of the first production mainnets to feature a fully sharded PoS architecture. Across the 4 shards in Harmony mainnet, blocks are produced every 2 seconds and cross-shard transactions are finalized in 2 block times.

Harmony’s Effective Proof-of-Stake (EPoS) is the first staking mechanism in a sharded blockchain that achieves both security and decentralization. EPoS allows staking from hundreds of validators and the unique effective stake mechanism reduces the tendency of stake centralization. Meanwhile, stake delegation, reward compounding, double-sign slashing, and unavailability checking are also supported.

Effective Stake

Let’s call the bid price of the elected BLS keys the raw stake. The effective stake of an elected BLS key is a bounded value on its raw stake with a threshold around the median bidder’s raw stake (denoted as median_stake in the picture below). The upper threshold is 115% of the median_stake and the lower threshold is 85% of the median_stake. For a key with raw stake that’s out of bound of the threshold, its effective stake will be bounded by the corresponding threshold, otherwise, the effective stake is the same as the raw stake.

The effective stake of each BLS key is determined at the last block of an epoch during the election process and will stay the same throughout the next epoch.

Shard Committee and Voting Power

After the election and shard assignment, the BLS keys assigned in a shard become the committee of that shard. The voting power of an elected BLS key in a committee is the metrics used to measure the key’s weight in the consensus voting process. The total voting power of a shard committee is always 1.0 (or 100%). The consensus of a committee is only reached if more than 2/3 of the voting power is collected in the votes.

Each BLS key in the committee has a certain voting power proportional to the share of its effective stake among the whole committee. For example, if the sum of the effective stake of all the keys in the committee is 10k ONE, a BLS key with effective stake of 1000 ONE will have voting power 0.1 (or 10%).

Block Reward

For each of the blocks produced and confirmed within a shard, it should contain signatures from the keys with more than 2/3 of the total voting power of the shard committee. Each confirmed block will produce 7 ONE as block reward for the validators behind the committee. The 7 ONE is initially allocated to all the validators whose BLS key(s) signed on the block, proportionally to the voting power of the key(s) that signed.

The allocated block reward for a validator will be further distributed to delegators proportionally to their stake after the commission fee is charged. For example, a validator with a commission rate of 25% got allocated 4 ONE for a block it signed. The validator staked 1000 ONE itself and it has 2 delegations each with 1000 ONE. The block reward distribution for this validator works as follows:

1. The commission fee of 1 ONE (4 ONE * 25%) is cut from the original reward and credited to the validator.

2. The rest of the reward of 3 ONE is then distributed to all the stakers (including both the validator and its delegators) proportionally based on their stake. Since the stakers (the validator and the two delegators) each staked/delegated 1000 ONE, they each receive 1 ONE in the reward distribution.

Double Sign Slashing

If any BLS key(s) are detected signing conflicting blocks (i.e. blocks with the same height and view ID but with different block hashes), the validator will be slashed and forever banned from the network. When a validator is slashed, a certain percentage (i.e. slashing rate) of staked tokens from the validator and its delegators will be forfeited, of which half will be burnt and another half will be credited to the reporter of the double sign event.

The slashing rate is calculated by simply summing all the voting power of the double signing keys with a minimum of 2%. For example, if 3 BLS keys with voting power of 3%, 3% and 4% double signed at the same time, 10% of all staked tokens will be slashed on the validators who hold the 3 BLS keys.

Uptime and Unavailability Penalty

The elected validators are obligated to validate blocks with their elected BLS keys. In every epoch, an elected validator should sign more than 2/3 of the signatures that its BLS keys are asked to sign.

The signing performance is represented by a percentage value called uptime. A validator’s uptime is the ratio of the number of signatures its elected BLS keys signed over the total number of signatures the keys should sign. For example, a validator has 2 elected BLS keys and each of the keys is presented 100 blocks to sign. In the final tally, the first key signed 70 blocks and the second key signed 80 blocks. Overall, the validator’s uptime is (70+80) / (100*2) = 75%.

At the end of each epoch, the validators with uptime of no more than 2/3 (66.66%) will have their status set to “Inactive” and be ruled out from the new election. For these inactive validators, they are required to manually set their status to “Active” by sending an EditValidator transaction in order to participate in future elections. We encourage validators to be proactive in maintaining a high uptime to ensure they remain elected and earn the most block reward possible.

Trezor wallet can be used along with Metamask to perform ONE transfers on Harmony network. Follow the steps below.

Project Summary

👩‍👩‍👧‍👦 WHOM: Global consumers with just a few thousand dollars and no technical background.

🤯 MAGIC

• No emails, SMS, passwords or government documents necessary.

🔨 HOW

• Harmony supports non-custodial and trustless transactions in 2 seconds and at less than $0.01 fees.

🚀 WHEN: Product launch in 2021 Q3 with 1000 users, then 10k users in Q4 with each wallet holding $1000. A prototype with minimal features on mainnet in July.

💡 Terms

• Non-custodial: no network, software, developers, government or even Harmony control your fund.

Security Goals

ONE Wallet is designed with these goals in mind for security:

Social (people)

• Resilient. Funds are recoverable through time locks and multiple safety nets. No single point of failure such as thefts, cracks, loss, censorship or coercions is catastrophic.

• Sufficient. All steps are well defined without delegating to hardware devices or seed phrases in safety boxes. Users do not need any passwords or rely on biometrics.

• Anonymous. An account is a fresh cryptographic hash, not tied to existing systems or real-world identity. Derived paths support multiple public keys to protect privacy.

Smart (code)

• Composable. One-time or low-entropy passwords are useful for small funds. Multiple authentications can independently boost protection thresholds against brute-force.

• On-chain. A decentralized network with high stakes and fast finality validates all transactions. Its platform has sustainable incentives and open governance to evolve.

• Programmable. Operations can call third-party contracts, store history of states, or upgrade its code. Complex applications may use oracles of time, locations and events.

Hard (math)

• Self-Sovereign. No third parties, government documents, designated guardians, backup servers or hardware enclaves are necessary. Users have full custody and self control.

• Air-Gapped. Key-loggers and man-in-the-middle attacks are minimized. The full parameters of transactions are easy to verify and approve without cables or cameras.

• Verified. Trusted are only open source and hardened cryptography. Formal verification, through logical frameworks, assures end-to-end security beyond tests and audits.

Tradeoffs

There may be conflicts, tradeoffs or impracticality of the goals above. Here's our rule of thumb:

1. Toward validating our innovation with 10k users (each with $100 assets), focus on these three goals: sufficient, resilient and composable.

2. Toward adopting our product with 1m users (each with $1k assets), differentiate with these three goals: on-chain, self-sovereign and air-gapped

2. Choose transfer direction

3. Connect your Metamask account via Metamask button

On wallet connection destination address is chosen automatically. You can specify another address on which you would like to receive your tokens.

4. Select a token from the list. You can use the search field.

When selected, token addresses for both networks will appear on the page. Note that token you receive never have the same address in destination network. You can check what token you get by following its address link. Please check if it's a desired token, and it has a liquidity in the target network.

5. Enter the amount.

When all fields are correctly filled in click on Continue to perform the bridge action.

6. You'll see the notice. Please read it carefully.

7. Read the message with fees very carefully on the next page. If you agree, click on Confirm.

8. The bridge action will begin, and you will be asked multiple times to sign transactions using Metamask. Just click on Confirm for every action

There are several steps in the bridge operation. Normally, it takes up to 20 min to finish the operation step.

When the transaction is over, its hash appear on the corresponding step. You can follow the link for transaction details.

9. If all went well, we have a successful bridge action.

10. In order to see the tokens you might need to add the tokens to your wallet. There is a special button for it in the interface. You need to confirm adding in Metamask notification window.

The Harmony team is focused on delivering a strong foundation for our network and ecosystem. We are grateful for the engagement and support of our validators, developers, community members, grantees and collaborators. Our current ecosystem map as of February 2022 is below and only includes a portion of projects launched on the Harmony network.

See below our 2021 Year in Review & Ecosystem Growth:

Ledger Nano X and Nano S

The Nano X and Nano S are hardware wallets created by Ledger. A hardware wallet stores the private keys to Harmony tokens on a separate device, making it much harder for malicious parties to steal them. In fact, the private keys never leave the Nano wallet itself, so they will remain secure even if the device is connected to a compromised computer. As long as you follow best practices when using your Nano, it is virtually impossible for an attacker to steal your funds.

Plug in your Ledger and open the Harmony Ledger App. Your device will be detected by your computer.

You will be directed to the Validators page on the Staking Dashboard and a small trident logo will appear on the chrome tab. Your Ledger Nano will display "waiting for commands" before you click on any buttons.

Click the "Show on Ledger" button to display your address on your Ledger device.

Press the right button on Ledger to continue and confirm the address is correct.

Download & Setup HMY

Interacting with Ledger

With that in mind, you can run any other command via HMY CLI using your Ledger.

Below, are a few practical examples on how to interact with your Ledger device.

1. Displaying your Address

For example, if you want to show your Ledger address you would simply run:

Using the Binary:

./hmy keys list --ledger

Using the Shell Wrapper:

./hmy.sh -- keys list --ledger

2. Displaying your Balance

Using the Binary:

./hmy balances --node="<endpoint-address>" <ONE-address> --ledger

Using the Shell Wrapper:

./hmy.sh -- balances --node="<endpoint-address>" <ONE-address> --ledger

3. Sending Transactions

Using the Binary:

./hmy transfer --node="<endpoint_address>" \
 --from <ONE_address> --to <ONE_address> \
 --from-shard <shard> --to-shard <shard> \
 --amount <amount> --chain-id <chain-id> --passphrase --ledger

Using the Shell Script:

./hmy.sh -- transfer --node="<endpoint_address>" \
 --from <ONE_address> --to <ONE_address> \
 --from-shard <shard> --to-shard <shard> \
 --amount <amount> --chain-id <chain-id> --passphrase --ledger

Gnosis Safe on Harmony

Connect Wallet

2) Chose your wallet.

Connecting with MetaMask

Select the MetaMask option in the connect wallet menu. Check that the correct MetaMask account is active and connected to the Harmony Network.

Create Safe

1) Press Create new Safe.

2) Name the safe. This will be stored locally. Press Start to continue.

3) Add additional owners if you want. For each additional owner:

1. Click Add another owner

2. Give Owner a Name

3. Enter Owner an Address

4. Select how many owners will be required to confirm a transaction

5. Press Review

4) Submit your safe by clicking on Submit. You will need a very small amount of ONE tokens to confirm the transaction.

5) Confirm the transaction on Metamask.

6) If all steps were sucessfull your Safe should have been deployed. Just click on Continue.

Load Existing Safe

You can load the Safe on other devices, so everyone can sign transactions using the same safe, but using different accounts.

1) On main page there is an option called Load Existing Safe. Click on this button as shown by the image below.

2) Pick a name for your Safe and paste the Safe Address. The Safe Address can be found on the main page. If you are in doubt please check section Receive Tokens.

3) Review owners by clicking on Review.

4) Load Safe by clicking on Load.

If sucessfull, you should see your Safe loaded on main page.

Send Tokens

1) On the main page click on New Transaction.

2) On next window click on Send funds. You can also send collectibles, but for this example we will be sending normal tokens.

3) On next window fill the recipient address you want to send your tokens to and the amount. After that click on Review.

4) O next window click on Submit.

5) A Metamask window will pop up for you to confirm the transaction. You should see your transaction confirmed on the next window. On our example we are using 2 of 3 signatures for the tokens to be sent out of the Safe.

6) We need at least one more account to confirm the transaction on the safe. Just click on Confirm logged in with the required account.

7) Approve the transaction by clicking on Approve Transaction.

8) If all the parts have confirmed the transaction you should see Success on top.

Receive Tokens

Once you have a Safe deployed, you can use the Safe address to receive tokens. Just click on Copy to clipboard.

Using Harmony hardware wallet on the Ledger requires a few things. You will need:

• Your Ledger

• The Harmony app installed on your Ledger

To send ONE tokens to an address, click the "Transfer funds" button and the send window will pop-up.

Input the amount of tokens to send and the destination address, then click the "next" buttons.

Click the "Confirm and Sign" button to sign the transaction.

Check your ledger Nano S, the LED display on Nano S is shown as below. Click on the right button to review transaction on Ledger.

Check and confirm the destination address is correct.

Check and confirm the amount is correct.

Currently, staking dashboard only supports transaction on shard0.

Click the right button to start signing the transaction:

Once transaction is signed, Send window will pop-up on the staking dashboard and display the transaction status.

It will display "Successful Send" once the transactions completes.

Metamask can be used along with ledger to perform transfers.

Steps:

Installing using Ledger Live (RECOMMENDED)

1. Turn on Developer

Open Ledger Live, select Manager. Turn on Developer Mode in Manager: Settings -> Experimental Features -> Developer Mode, as shown below:

2. Search for the App in the Catalog

Ledger live provides app catalog for different types of apps, as shown below:

To find the Harmony app, type harmony in the search bar, as shown below:

3. Install/Remove the App

There are two buttons associated with Harmony One app. The install button can be clicked to install Harmony One app to Ledger Nano. The app can be uninstalled by clicking the trash bin button.

4. Using the App

To use Harmony One app, please check your Ledger Nano device and click both buttons to open the app.

Installing Manually (Windows)

1. Install Python

At the end make sure you add the python binary to the path:

2. Install Packages

Execute the commands below on the windows terminal:

python -m pip install --upgrade pip
pip install virtualenv
virtualenv venv
cd venv
cd Scripts
Activate.bat
pip install ledgerblue

2. Download Latest Version

3. Install the App

Move the ver1.6.0.hex file downloaded before tovenv\Scripts folder and execute the command below to install the app:

python -m ledgerblue.loadApp --appFlags 0x40 --path "44'/1023'" --curve secp256k1 --tlv --targetId 0x31100004 --targetVersion="1.6.0" --delete --fileName ver1.6.0.hex --appName One --appVersion 1.6.0 --dataSize 0 --icon 01ffffff00ffffff00ffffffffffffc7e1bbcdbbddbbcdbbc50bd8a3ddbbddbbddb3edc7e3ffffffff

Confirm the installation of the app on your Ledger.

Installing Manually (Ubuntu Linux)

1. Install Packages

sudo apt update
sudo apt install libudev1 libudev-dev libusb-1.0-0-dev python3-dev python3-pip python3-testresources git
sudo pip3 install -U setuptools
sudo pip3 install virtualenv
virtualenv -p python3 venv
source venv/bin/activate
pip install ledgerblue

2. Downloading the App

git clone https://github.com/harmony-one/ledger-app-one
cd ledger-app-one

3. Installing the App

sudo ~/venv/bin/python -m ledgerblue.loadApp --appFlags 0x40 --path "44'/1023'" --curve secp256k1 --tlv --targetId 0x31100004 --targetVersion="1.6.0" --delete --fileName release/ver1.6.0.hex --appName One --appVersion 1.6.0 --dataSize $((0x`cat debug/app.map |grep _envram_data | tr -s ' ' | cut -f2 -d' '|cut -f2 -d'x'` - 0x`cat debug/app.map |grep _nvram_data | tr -s ' ' | cut -f2 -d' '|cut -f2 -d'x'`))  --icon 01ffffff00ffffff00ffffffffffffc7e1bbcdbbddbbcdbbc50bd8a3ddbbddbbddb3edc7e3ffffffff

Confirm the installation of the app on your Ledger.

Download SafePal Mobile Apps

Quick Start

SafePal Hardware Wallet

SafePal is a secure and user-friendly hardware wallet designed for the masses. SafePal S1, its first flagship hardware wallet, adopts multiple layers of security schemes and intuitive user interfaces, enabling users to store, transfer and trade coins in the wallet in the easiest way.

Check the validators page to see list of validators. Click on desired validator logo to check validator details.

Click on the "Delegate" button to delegate to this validator.

Enter the desired delegation amount or scroll the percentage slider in the pop-up Delegate window. Delegation must be at least 100 ONE. Click on "Next" and confirm the signature request.

Check your Ledger, it will display "Delegate Stake" in the LED screen. Press the right button to start signing the transaction.

Check the delegator address. Press the right button to show full address. If correct, press both left/right buttons to continue.

Check the validator address. If correct, press both left/right buttons to continue.

Check the delegation amount. If correct, press the right button to continue:

Press right button for Sign Stake confirmation.

The entire process is shown below:

Once transaction is signed, Delegate window will pop-up on the staking dashboard and display the transaction status.

Create New Wallet

Import Wallet (Recover)

MetaMask is an extension for accessing Harmony enabled distributed applications, or "dapps", from your browser. The extension injects the Harmony web3 API into every website's javascript context, so that Web3 applications can read from the blockchain.

In this section, we walk through the process of installing MetaMask, configuring it on the Harmony network, and importing an existing account using a previously generated private key.

How to send ONE in SafePal？

1. Click on the 'Send' segment in SafePal App menu bar and select ONE.

1. Input the destination address by pasting the address or scanning the QR code. Enter all transaction details - amount, fee and don't forget to select the shard number.

1. Then clink “Send”to check the transaction details.

Tips: If you don't know the exact shard number, don't worry, you can simply use Shard 0 as the default shard.

1. Sign the order with your SafePal S1 hardware wallet.

1. Confirm the payment.The transfer is broadcasted on chain. Don't forget to check transfer status later.

How to receive ONE in SafePal?

To receive ONE tokens you need to provide the sender your ONE address which can be found using the SafePal app or wallet.

Using the SafePal App:

1. Select ONE which gives you the option of receive and send, click on receive

2. You can either copy your ONE address for the wallet, save the QR code, or have the other party scan the QR code from your phone

Using the SafePal Wallet:

1. Turn on the wallet

2. Scroll to "Asset Management" in the main menu

3. Select "Harmony" out of all the options

4. Click on receive, and then enter your PIN code

5. Your QR code, as well as the ONE address for the wallet will show for the other party to use

In order to create a new account, click on the icon on top as shown by the image below and then on Create Account:

On next window, provide an account name and then click the Create button to complete the step.

Retrieving the 0x Equivalent Address

• Search for your one1 address at the top.

• At top of the screen, toggle the address format from ONE to ETH.

• Copy the 0x address format by clicking on the small icon right to the address

You now have the 0x address which corresponds to your one1 address.

Sending a Regular Transaction

To send a transaction on MetaMask, click on Send button and on next window paste the destination address starting with 0x, fill the amount you want to send, click on Next, and then click on continue.

Receiving a Regular Transaction

In order to receive a transaction, simply share the 0x address format with the sender.

Adding a Custom Token

Open MetaMask, select the Harmony network, then click the Assets tab. Near the bottom, click "Import Tokens" and complete the empty fields.

Add the Token Contract Address, Token Symbol, and the Decimals value. Note the Token Symbol and Decimals may auto-populate. These details are usually provided by the token creator.

Complete the step by clicking on "Add Custom Token". Your custom HRC20 Token will show up in MetaMask along with its balance.

Sending a HRC20/HRC721 Transaction

Click on the asset you want to send your tokens from on the Asset tab. Click on Send button and on next window copy paste the destination address starting with 0x, fill the amount you want to send, click on Next and then on Confirm.

Receiving a HRC20/HRC721

In order to receive a transaction, just share the 0x address format of your wallet. One Wallet supports sending HRC20/HRC721 transactions to either addresses starting with 0x or one1.

Adding Harmony to MetaMask

Open MetaMask and click the list of networks at the top, then select "Add Network".

Fill the Endpoint Information

You will be prompted for additional information. Use the table below to complete the step. Below you will see multiple options for RPC URL and Chain ID corresponding to mainnet vs testnet, and the various shards within each.

The example below shows the configuration that needs to be done to connect to Harmony Mainnet on Shard 0:

Click the Save button and your configuration should be done!

Installation

1. Open the extension in your browser and create new password.

1. Select Harmony from the list of networks.

You can choose to create a wallet through the extension or import your existing wallet using a mnemonic phrase or a private key.

When you create a wallet, please write down your mnemonic correctly and keep in a safe place.

You may also import your Harmony Account using your mnemonic or private key.

You can also choose to export your keys in Settings. Your keys will be exported into a txt file with both private key and mnemonic.

1. Obtaining a Private Key

Importing an account is done by taking an existing private key and importing it into MetaMask. How you obtain the private key is dependent on the wallet in use.

For the Harmony Chrome extension wallet, click the Menu button at the top right, click Export Private Key, enter your password, and copy the private key displayed.

2. Using a Private Key

Click on the icon on top as shown by the image below and then on Import Account:

On next window, select the option to import from a Private Key, paste your key and click on Import to complete the step.

Your account should now be imported.

Opening Web Wallet

You will need to open Web Wallet in order to view account details and perform transactions.

1. Please select the wallet you want to open and click Web Wallet on the Math Wallet extension popover interface.

2. After clicking Web Wallet, a new tab will open asking you to login into Math Wallet, click on login and you will enter the Web Wallet.

Sending transactions

1. Specify the shard you want to pull funds from using the Shard dropdown in the sidebar.

2. Specify which account you want to send funds to using the To Address field.

3. Specify which shard you want to send funds to using the Shard dropdown to the right.

4. Specify the amount you wish to send in the Transfer Amount field.

5. Specify the gas price you wish to pay using the Fee slider. Gas is a fee charged by the network for the computational work of mining a transaction into the blockchain.

6. Click Transfer to complete the transaction! You will be shown a transaction receipt before finalizing the transaction.

The screen will prompt you to make a selection.

Choose "Use an Existing Address".

Click "Use Math Wallet" from the next selection of options and then click "Sign In".

Sign in to your Math Wallet browser extension. You will see a Login Request pop up. Select your wallet and then click Accept.

You will be brought back to the Validator page of Staking Dashboard. You will be able to see your address on the top left corner under the Harmony logo which means you are now signed in to your account.

Locate and click on your preferred validator from the list.

The validator profile page will open. Click on the Delegate button.

Option #1: Enter the desired amount of tokens you would like to delegate and click next or...

Option #2: Use the slider to determine the percentage of your ONE you wish to stake.

Click Next and then click Confirm and Sign.

Click Accept to confirm the signature request on the Math Wallet pop-up window and wait a few seconds. If the transaction completes, you will find a success confirmation pop-up on your screen.

You are now staking your ONE with a validator and will begin earning rewards at the start of the following epoch.

Click the Portfolio link on the left to view your stake amount, rewards accumulated, and a list of any validator to whom you have delegated your coins.

With your ONE staked to one or more validators, your delegation begins earning rewards with each block. You may collect these rewards at any time and may be re-delegated to compound your interest assuming you have 100 or more ONE.

Visit the staking dashboard at staking.harmony.one and click the Portfolio link on the left.

Log into the dashboard if you're not already signed in.

With your address confirmed, proceed by clicking the Claim Rewards button to collect the ONE earned through staking.

Note the staking dashboard currently only displays whole integers, which means <1 ONE rewards will display as zero and cannot be collected.

Proceed by clicking the Next button at the window below.

Then click the Confirm and Sign button to send the transaction for signing in Math Wallet.

This will cause Math Wallet to pop up and request you to accept the signature request.

Click the Accept button to sign the transaction and collect your rewards.

Your rewards are collected once you see a Successful Withdrawal message.

Your ONE rewards, generated by staking your coins, are now added to your wallet.

Click on the Portfolio link to the left.

This page will display information about your staked ONE including a list of validators to which you've delegated your ONE, amount of staked ONE, and unclaimed rewards.

You can undelegate from one or more validators where your ONE is staked.

From the Portfolio view, select the validator(s) from which you wish to undelegate by clicking on their validator name. This brings up the validator profile page.

Click the Undelegate button.

You will be prompted to specify how much you wish to undelegate from the validator. From here, specify an amount you wish to undelegate or click Set Max to undelegate all ONE from the validator.

Click Next and then click Confirm and Sign. This will open a window for Math Wallet.

Click the Accept button to sign your undelegation / unstaking transaction.

You should see a notification for your successful undelegation.

Your ONE is now undelegated from the validator. You may have more ONE staked with other validators. To undelegate fully, repeat these steps again through the list of validators on your Portfolio page.

Manage your Harmony, Ethereum, HRC20, HRC721, ERC20 & ERC721 Tokens in a trustless manner.

Cobo is the first leading wallet company in the world to offer Staking and masternode rewards on user holdings, making it easy for users to grow their digital assets effortlessly. As a company, they emphasize long-term security, reliability, and convenience.

Description: "The ultimate gateway to decentralized finance in a user-friendly, multi-currency and convenient cryptocurrency wallet for all your needs."

Average setup time is 3-5 minutes:

2. Click on Get Started

3. Select Create a new wallet

4. Scroll and select No thanks for Metamask data

5. Create Password and select Face ID (MetaMask cannot recover your password, write this down in a safe place, DO NOT TAKE A SCREENSHOT)

6. Allow Face ID

7. Secure Wallet (*even more important than password, should never be shared with anyone, even MetaMask)

8. Review Metamask Tips (store phrase in a secure location)

9. Make sure no one is watching before revealing phrase, click View

10. Write your Secret Recovery Phrase in a safe place

11. Choose to enable automatic security checks (we recommend that you enable this)

14. Click Wallet at the top of the screen

15. Click Add Network

16. Select Add for Harmony Mainnet Shard 0

17. Approve (make sure the information is the same)

18. Switch to Network

19. To Get ONE you’ll need your ONE address

20. With Metamask open make sure the Wallet is on Harmony Mainnet Shard 0

21. Click your address on the top of the page to copy it

22. Once the address is copied, select ONE

23. Select the three dots on the top right and View on block explorer

24. Paste in Search

25. Your ONE address will automatically load

26. Select the copy icon to copy the address

Description: "ONTO is the first truly decentralized, cross-chain wallet, allowing users to securely manage their identities, data, and digital assets. Wallet users can manage their crypto assets (including NFTs), perform cross-chain swaps, keep up-to-date with the blockchain and crypto industry’s latest developments and events via the ONTO news feed, and enjoy a variety of dApps."

Harmony Smart Defi Wallet

Send. Swap. Connect. | Available at https://sefwallet.one

Sef Wallet is a smart DeFi wallet built for Harmony blockchain. Always low fees, and fast transaction time.

ADVANCED SECURITY

• Guardians for added protection

• Spending limits

• Open-source contracts

• Independently audited

AUTHENTICATOR RECOVERY

No more worrying about losing mnemonic keys, private keys, email or passwords to restore your wallet. Recovery is done with your authenticator codes on the blockchain with merkle proof.

ASSETS MANAGEMENT

• Supports HRC20 send/transfer

• Local prices conversions to dozens of languages

SWAP ON SUSHISWAP

• Native support for sushiswap

• Supports over dozens of of tokens

CONNECT TO DAPPS

• Connect any dapps with WalletConnect

• Access to Defi features on Sushiswap.

Frontier is a chain-agnostic DeFi aggregation layer. Users can stake in Harmony using Frontier.

Description: Stake and exchange Harmony ONE tokens using Guarda Wallet. Stake, exchange, earn and buy Harmony, Bitcoin, Ethereum and thousands of other assets.

New Wallet

Using the Binary:

./hmy keys add <account-name> [--passphrase]

Using the Shell Wrapper:

./hmy.sh -- keys add <account-name1> [--passphrase]

Example:

./hmy keys add test-account --passphrase

This creates a keystore at the following directory:(hmy keys location)/account-name1/UTC--2019-09-16T21-25-35.297331000Z--678e7ea3dcb5f4e9724c0e761843572f10c49b73

When creating keys this way, hmy will ask you to provide a passphrase.‌ Make sure you keep track of this passphrase for future use because the passphrase is used to decrypt the keystore when signing transactions. Also make sure you save the seed phrase, also called a mnemonic.

To know where your wallet file has been created, run the following command:

Using the Binary:

./hmy keys location

Using the Shell Wrapper:

./hmy.sh -- keys location

You can check the list of wallets (local accounts) with the following command:

Using the Binary:

./hmy keys list

Using the Shell Wrapper:

./hmy.sh -- keys list

Import Wallet

Importing a Keystore

‌You might have an existing keystore made by Harmony's old wallet.sh program that ends with ".key" in the file name (example):

one16qsd5ant9v94jrs89mruzx62h7ekcfxmduh2rx.key

Or that starts with "UTC" in the file name (example):

UTC--2020-01-15T01-02-06.606670000Z--9689a0711642bf08ea92ed98d552f0c1b8c8cefb

Both these files can be imported into hmy using the command import-ks as shown below.

Using the Binary:

./hmy keys import-ks <absolute_path_to_keystore> --passphrase

Using the Shell Script:

./hmy.sh -- keys import-ks <absolute_path_to_keystore> --passphrase

Examples:

./hmy keys import-ks /home/harmony/one16qsd5ant9v94jrs89mruzx62h7ekcfxmduh2rx.key --passphrase
./hmy keys import-ks /home/harmony/UTC--2020-01-15T01-02-06.606670000Z--9689a0711642bf08ea92ed98d552f0c1b8c8cefb --passphrase

‌Keep in mind that you should know the passphrase associated with the imported keystore and pass it as a parameter as shown in the commands above. For keystores created by Harmony's wallet.sh, the default passphrase is an empty string; this matters for signing transactions.‌

Importing a Private Key

Sometimes you might have a secp256k1 private key, such as the one generated from the following command:

openssl ecparam -genkey -name secp256k1 -text -noout -outform DER | xxd -p -c 1000 | sed 's/41534e31204f49443a20736563703235366b310a30740201010420/PrivKey: /' | sed 's/a00706052b8104000aa144034200/\'$'\nPubKey: /'

You can import the key with an optional name and passphrase

Using the Binary:

./hmy keys import-private-key <secp256k1_private_key> [wallet_name] [--passphrase]

Using the Shell Script:

./hmy.sh -- keys import-private-key <secp256k1_private_key> [wallet_name] [--passphrase]

Example:

./hmy keys import-private-key b8798ca0a56ce16517ea37c6b1229cbb67cf0e022c423b044fe8f537830d8be5 my_wallet_name_here --passphrase

If no account name is provided, a random word concatenated with -imported will be used. If no passphrase is provided, the default passphrase will be used (which is blank). Note that the CLI currently only supports importing secp256k1 private keys.

Importing a Mnemonic Phrase

You can recover lost wallet keys by entering the mnemonic words you received (and hopefully saved) when creating it:

Using the Binary:

./hmy keys recover-from-mnemonic [wallet_name]

Using the Shell Script:

./hmy.sh -- keys recover-from-mnemonic [wallet_name]

Example:

./hmy keys recover-from-mnemonic nameofyourkey

Incoming transactions

The funds that are sent within shard 0 will be viewed correctly in Trust Wallet.

If you receive funds in a shard other than shard 0 (i.e. in shard 2), you will not see the transaction receipt in the Trust Wallet app. Since your account balance will only show the funds in shard 0, your total balance will not change.

Outgoing transactions

Since there is no shard selection in the Trust Wallet UI, all transactions will originate from shard 0 and will be sent to shard 0.

For more details, please see these example cross-shard transactions using Trust Wallet:

What to do if you receive funds in a shard other than shard 0 when using Trust Wallet?

You will need to export the account in which you received the funds and import it to another wallet such as the CLI or Math Wallet.

Example Using Math Wallet:

1. Open Trust Wallet app

2. Click on "Settings" on the bottom right

3. Click on "Wallets"

4. Click on the info circle next to "Multi-Coin Wallet"

5. The screen will show backup options, select "show recovery phrase"

6. Your mnemonic recovery phrase will show up, make sure to note them down accurately and securely

7. Open Math Wallet Chrome Extension

8. Click the + sign next to Harmony

9. Select "Import Wallet"

10. Select "Import by mnemonic"

11. Type in your mnemonic that you noted from Trust Wallet, and click next

12. Name your new imported wallet

13. Open "web wallet" from the extension and you can access all your funds in all shards

Import/Export Wallet

Below are the official instructions on how to restore/import Recovery Phrase (mnemonic) on Trust wallet.

Introduction

Features

With the hmy CLI you can create a wallet, check your balance, send signed transactions to the Harmony blockchain, look up previous transactions, recover keys from previous mnemonics, create new keystores, and create new BLS keys.

Supported Platforms

• OSX: main development platform

• Linux: tested

• Windows: tested/working under Windows Subsystem for Linux (WSL)

Release information

Description: "Trustee Wallet is the altcoins & Bitcoin wallet app for secure storage, profitable purchase of cryptocurrencies and tokens using bank cards."

Get JSON output of balances on all shards of a given ONE address with the balances subcommand:

Using the Binary:

./hmy balances <ONE-address> --node="<endpoint-address>"

Using the Shell Wrapper:

./hmy.sh -- balances <ONE-address> --node="<endpoint-address>"

Example:

./hmy balances one1km7xg8e3xjys7azp9f4xp8hkw79vm2h3f2lade --node="https://api.s0.t.hmny.io"

Delegating to a Validator

You can delegate tokens to a validator using the following command:

./hmy --node="https://api.s0.t.hmny.io" staking delegate \
    --delegator-addr [ONE ADDRESS] --validator-addr [ONE ADDRESS] \
    --amount [AMOUNT] --passphrase

The CLI will ask for the passphrase for the delegator-addr keystore file.

--delegator-addr is the ONE address of the delegator (string)

--validator-addr is the ONE address of the validator (string)

--amount is the number of ONE tokens to delegate to the validator (float)

Undelegating from a Validator

You can un-delegate tokens from a validator using the following command:

./hmy --node="https://api.s0.t.hmny.io" staking undelegate \
    --delegator-addr [ONE ADDRESS] --validator-addr [ONE ADDRESS] \ 
    --amount [AMOUNT] --passphrase

The CLI will ask for the passphrase for the delegator-addr keystore file.

--delegator-addr is the ONE address of the delegator (string)

--validator-addr is the ONE address of the validator (string)

--amount is the number of ONE tokens to un-delegate (float)

Collecting Rewards

You can collect your block rewards with the following command:

./hmy --node="https://api.s0.t.hmny.io" staking collect-rewards \
--delegator-addr [ONE ADDRESS] --passphrase

The CLI will prompt your for the passphrase of the delegation account.

--delegator-addr is the account to collect rewards for

Download Harmony CLI tool

1. For Linux

Enter the following command into your shell of choice:

curl -LO https://harmony.one/hmycli && mv hmycli hmy && chmod +x hmy

2. For MacOS

hmy depends on some dynamic libraries, hence we recommend using the shell wrapper. Enter there commands into your terminal:

curl -O https://raw.githubusercontent.com/harmony-one/go-sdk/master/scripts/hmy.sh
chmod u+x hmy.sh
./hmy.sh -d

Now you can use hmy.sh as a wrapper over hmy and you should assume that all references to hmy in these documents refer to hmy.sh. For example, the command ./hmy becomes ./hmy.sh -- .

3. Compiling from source

If you are interested in compiling from source, then the process is more involved.

Steps:

cd $(go env GOPATH)/src/github.com/harmony-one
ls
bls harmony mcl
git clone https://github.com/harmony-one/go-sdk.git

1. Then setup the build flags:

source harmony/scripts/setup_bls_build_flags.sh

1. Call make in the go-sdk repo. This builds a binary named hmy:

cd go-sdk
make

Congratulations! You can now use the binary to run the CLI.

Perhaps the most important feature of the hmy CLI is the ability to create and send signed transactions to the Harmony blockchain.

Overview

Sending a transaction

Using the Binary:

./hmy transfer --node="<endpoint-address>" \
 --from <ONE_address> --to <ONE_address> \
 --from-shard <shard> --to-shard <shard> \
 --amount <amount> --chain-id <chain-id> --passphrase

Using the Shell Wrapper:

./hmy.sh -- transfer --node="<endpoint-address>" \
 --from <ONE_address> --to <ONE_address> \
 --from-shard <shard> --to-shard <shard> \
 --amount <amount> --chain-id <chain-id> --passphrase

Example:

./hmy --node="https://api.s0.t.hmny.io" \
 transfer --from one1yc06ghr2p8xnl2380kpfayweguuhxdtupkhqzw \
 --to one1q6gkzcap0uruuu8r6sldxuu47pd4ww9w9t7tg6 \    
 --from-shard 0 --to-shard 1 --amount 12.5 --chain-id mainnet --passphrase mypassword

Checking the transaction hash

Check for finality of the transaction by using the transaction hash like so:

Using the Binary:

./hmy blockchain transaction-receipt <transaction_id> --node="<endpoint-address>"

Using the Shell Wrapper:

./hmy.sh -- blockchain transaction-receipt <transaction_id> --node="<endpoint-address>"

Example:

./hmy --node="https://api.s0.t.hmny.io" \
 blockchain transaction-receipt \
 0x599793f313ee17566f8d09728b9d043b8e26135ddce86beeee13f98767d452f7

Detail

ChainIDs

Let's first check what chain-ids are available for us to use, we can do that easily with:

Using the Binary:

./hmy blockchain known-chains

Using the Shell Wrapper:

./hmy.sh -- blockchain known-chains

Example:

./hmy blockchain known-chains

[
  "mainnet",
  "testnet",
  "devnet"
]

Notice that the output is pretty printed JSON, most outputs of hmy are JSON encoded and hmy defaults to showing it nicely indented. Sometimes though you might want to turn that off, you can do that for any command with the flag --no-pretty.

By default, hmy assumes the testnet chain-id; override that with the --chain-id flag

Our first transaction

We'll use the transfer subcommand of hmy to send a transaction.

./hmy transfer
Error: required flag(s) "amount", "from", "from-shard", "to", "to-shard" not set

Notice that simply invoking the transfer subcommand gave us an error message about certain flags not being set. We'll need to provide legitimate values for these flags for our transaction to proceed successfully. Reading off the flags in the error message from left to right, the semantic meanings are as follows:

• amount: The quantity of Harmony One token to transfer from the senders to the receiver

• from: The sender's one address

• from-shard: Shard from which sender's balance will be drawn from

• to: Receiver's ONE address

• to-shard: Shard in which receiver will receive the amount sent by the sender

• passphrase: your wallet passphrase, which is prompted when you hit enter (or you can use a txt file with password and add it: --passphrase file.txt)

A sharded blockchain is a new kind of blockchain architecture where the network is partitioned into sub-networks called shards. Sharding is one of the distinguishing features of Harmony and it is key to solving the traditional scalability problems encountered in other blockchain protocols.

Note: The same ONE address will have a different balance in each shard. Currently Harmony mainnet has four shards while testnet has three shards. Sending a transaction from one shard to another is called a "cross-shard transaction."

Thus, a correct usage of transfer looks like:

Using the Binary:

./hmy transfer --node="<endpoint-address>" \
 --from <ONE_address> --to <ONE_address> \
 --from-shard <shard> --to-shard <shard> \
 --amount <amount> --chain-id <chain-id> --passphrase

Using the Shell Wrapper:

./hmy.sh -- transfer --node="<endpoint-address>" \
 --from <ONE_address> --to <ONE_address> \
 --from-shard <shard> --to-shard <shard> \
 --amount <amount> --chain-id <chain-id> --passphrase

Example:

./hmy transfer --node="https://api.s0.t.hmny.io" \
 --from one1yc06ghr2p8xnl2380kpfayweguuhxdtupkhqzw \
 --to one1q6gkzcap0uruuu8r6sldxuu47pd4ww9w9t7tg6 \
 --from-shard 0 --to-shard 1 --amount 10 --chain-id mainnet
{"transaction-receipt":"0x455f98a3aa11ef50ee5cc5ac8bbd79e04f2fe353180bb7e25fc6c921fc8fdc83"}

Try out your transaction with the flag --dry-run, this flag tells hmy to create, cryptographically sign the transaction but not actually send it off. Sender's balances are checked and the output is a JSON dump of the signed transaction.

Signing and sending a transaction is very quick, about 2 seconds maximum. The actual sending of the transaction is done via an RPC (Remote Procedure Call), you'll notice that we did not explicitly say where to send the transaction to. This is because the default destination of the RPC call goes to http://localhost:9500, the default HTTP RPC server running when you start a local harmony blockchain. For real world usage though, you'll want a different location. You can control that with the --node flag (see the top of this page for an example).

Result of the transaction

Once an RPC machine receives a transaction, it sends you back a transaction hash. This transaction hash is the key identifier used when querying the blockchain for transactions.

We can pull down details of the finalized transaction with ./hmy blockchain transaction-receipt as well:

Using the Binary:

./hmy blockchain transaction-receipt --node="<endpoint-address>" <transaction-hash>

Using the Shell Wrapper:

./hmy.sh -- blockchain transaction-receipt --node="<endpoint-address>" <transaction-hash>

Example:

./hmy blockchain transaction-receipt \
    --node="https://api.s0.t.hmny.io" \
    0x25dd32397b5a69146b2dc3bbdc8ef8aae271e9b12a36c6dff1eb8995cac9dcba
{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "blockHash": "0x67eb5d671af76814d9ab326f9ec36c5b889b872e0c34e8cbe484aea20f0611ea",
    "blockNumber": "0x21017f",
    "contractAddress": null,
    "cumulativeGasUsed": "0x5208",
    "from": "one1sp4q22r7cc78742mzrufu6xwcekqxjgq78jk3m",
    "gasUsed": "0x5208",
    "logs": [],
    "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "shardID": 0,
    "status": "0x1",
    "to": "one129r9pj3sk0re76f7zs3qz92rggmdgjhtwge62k",
    "transactionHash": "0x25dd32397b5a69146b2dc3bbdc8ef8aae271e9b12a36c6dff1eb8995cac9dcba",
    "transactionIndex": "0x0"
  }
}

You can tell hmy to wait until transaction confirmation by providing a positive integer value to flag --wait-for-confirm. For example, --wait-for-confirm=10 will try checking the receipt of the transaction for 10 seconds.

Generate Markdown Documentation

if you want a full list of commands the hmy tool knows in markdown format, please run the following command:

./hmy docs

Then in the same directory, hmy creates a directory named hmy-docs in which you can find all markdown files for the commands and subcommands.

Delete Account

Deletion of a one account is possible by issuing the below command

 ./hmy keys remove [ACCOUNT-NAME]

hmy provides several subcommands under the blockchain subcommand which let you query the blockchain.

--node="https://api.s0.t.hmny.io"

List of available commands

By using ./hmy blockchain help command we can see that the following options are available:

Here are some examples of the above commands that you will use frequently:

transaction-by-hash

Checking the hash of your transaction to see the transaction data and if the transaction has been completed

Using the Binary:

./hmy blockchain transaction-by-hash <transaction-hash> --node="<endpoint-address>"

Using the Shell Wrapper:

./hmy.sh -- blockchain transaction-by-hash <transaction-hash> --node="<endpoint-address>"

Example:

./hmy blockchain transaction-by-hash 0x75d91100734edcd1497200cb438f0864d2ed4a44a88bf8c87855cb2b3cc54001 --node="https://api.s0.t.hmny.io"

{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "blockHash": "0xf9c7e165d5636c7dd8a06bf2c53c364d7597028d7e10a3c5256462adf97b1f73",
    "blockNumber": "0xa35",
    "from": "one1mrrq665uarrmfur6hptevx9furph4293a37zme",
    "gas": "0x5208",
    "gasPrice": "0x3b9aca00",
    "hash": "0x75d91100734edcd1497200cb438f0864d2ed4a44a88bf8c87855cb2b3cc54001",
    "input": "0x",
    "nonce": "0xe",
    "r": "0x4a17d89f7b1818fe72d480a64fecfede1d73bd7242fcaabf907204a7022be806",
    "s": "0x557be1b9c378ecbae972e71ec6fc5d484abfe8cb7961ccd87724865c3a7020bc",
    "shardID": 0,
    "timestamp": "0x5e1cfcc1",
    "to": "one1mrrq665uarrmfur6hptevx9furph4293a37zme",
    "toShardID": 1,
    "transactionIndex": "0x0",
    "v": "0x2a",
    "value": "0xde0b6b3a7640000"
  }
}

transaction-receipt

Get information about a finalized transaction:

Using the Binary:

./hmy blockchain transaction-receipt <transaction-hash> --node="<endpoint-address>"

Using the Shell Wrapper:

./hmy.sh -- blockchain transaction-receipt <transaction-hash> --node="<endpoint-address>"

Example:

./hmy blockchain transaction-receipt 0x599793f313ee17566f8d09728b9d043b8e26135ddce86beeee13f98767d452f7 --node="https://api.s0.t.hmny.io"

{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "blockHash": "0x52171a8f3af94f639f1e6044679c4189c3cd088ffe7f1c216ce3089212373af9",
    "blockNumber": "0x6177",
    "contractAddress": null,
    "cumulativeGasUsed": "0x5208",
    "from": "0x261fa45c6a09cd3faa277d829e91d9473973357c",
    "gasUsed": "0x5208",
    "logs": [],
    "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "shardID": 0,
    "status": "0x1",
    "to": "0x06916163a17f07ce70e3d43ed37395f05b5738ae",
    "transactionHash": "0x599793f313ee17566f8d09728b9d043b8e26135ddce86beeee13f98767d452f7",
    "transactionIndex": "0x0"
  }
}

latest-header command

Checking the network status, last block, epoch, leaders, based on the shard number:

Using the Binary:

./hmy blockchain latest-header --node="<endpoint-address>"

Using the Shell Wrapper:

./hmy.sh -- blockchain latest-header --node="<endpoint-address>"

Example:

./hmy blockchain latest-header --node="https://api.s0.t.hmny.io"

{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "blockHash": "0xae23db112d22062be6a0f065ecc3989d4e9559ad6a1f34fe4344d021907e8c2e",
    "blockNumber": 415749,
    "epoch": 5543,
    "lastCommitBitmap": "fffffffffffffffb0f00",
    "lastCommitSig": "06efa677bdd327d3d9602fd246c214edb35e447692dccc2219ef08ce2fa026b96f3826fcb5a2a3f724222ecef4af66029f3b5d677e54534519ad2a405ad3b336dd5145dcc083fc2330b9d0bb398affd1745cab274b5019f32cba0287bd5e5a17",
    "leader": "one18ahxsrk9g4h4gz5r8ema7nyw6g9zpun5hhp54d",
    "shardID": 0,
    "timestamp": "2019-12-11 12:18:21 +0000 UTC",
    "unixtime": 1576066701,
    "viewID": 415745
  }
}

./hmy blockchain latest-header --node="https://api.s1.t.hmny.io"

{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "blockHash": "0x65d528672301b1c086b4f2db89ce20f6977f7aeaa494073352e211ac29f55179",
    "blockNumber": 456065,
    "epoch": 5543,
    "lastCommitBitmap": "ffffffffffffffff0f00",
    "lastCommitSig": "c8e049810c1f649625259f684e99f4a9cfc51cf01b2dd032f884136c9922ebb8fe0929e366bbf8122e430402d04d4804362013302994d4924c2990bdffeacb4b79e075c1897947a7ec5be44eef6f1bd1e013b80008f28085c15e17aa49629a09",
    "leader": "one1vaqzxt50ltk9hq4d44lgxmj4pj2x533fsp2acx",
    "shardID": 1,
    "timestamp": "2019-12-11 12:21:52 +0000 UTC",
    "unixtime": 1576066912,
    "viewID": 456065
  }
}

./hmy blockchain latest-header --node="https://api.s2.t.hmny.io"

{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "blockHash": "0xd5775e720a9bcc5a88fd13aac27d72365f4724d6a513ecf39af53c1bb826823d",
    "blockNumber": 453475,
    "epoch": 5543,
    "lastCommitBitmap": "ffffffffffffffff0f4000",
    "lastCommitSig": "701bad22a95b7ee937446c3f614755d1729f19b5976f1230af6de65fd7ecc0d8b95795396a55d78994b5a8ecaed77d028721f76a58e9919ab01f4aba36a6f3a3dda3aaf39b313e5d623e73ca83d71fc1631ae964e1747826662652be85fada18",
    "leader": "one18vn4hpu8jpu8p9pql59m7p0x8dqrpsw0jzav9u",
    "shardID": 2,
    "timestamp": "2019-12-11 12:22:26 +0000 UTC",
    "unixtime": 1576066946,
    "viewID": 453508
  }
}

./hmy blockchain latest-header --node="https://api.s3.t.hmny.io"

{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "blockHash": "0xd5775e720a9bcc5a88fd13aac27d72365f4724d6a513ecf39af53c1bb826823d",
    "blockNumber": 453475,
    "epoch": 5543,
    "lastCommitBitmap": "ffffffffffffffff0f4000",
    "lastCommitSig": "701bad22a95b7ee937446c3f614755d1729f19b5976f1230af6de65fd7ecc0d8b95795396a55d78994b5a8ecaed77d028721f76a58e9919ab01f4aba36a6f3a3dda3aaf39b313e5d623e73ca83d71fc1631ae964e1747826662652be85fada18",
    "leader": "one188345hbsgdsgstw6eenjgxsgusgs",
    "shardID": 2,
    "timestamp": "2019-12-11 12:22:26 +0000 UTC",
    "unixtime": 1576066946,
    "viewID": 453508
  }
}

block-by-number

Using the Binary:

./hmy blockchain block-by-number <block-number> --node="<endpoint-address>"

Using the Shell Wrapper:

./hmy.sh -- blockchain block-by-number <block-number> --node="<endpoint-address>"

Example:

./hmy blockchain block-by-number 0x29A1 --node="https://api.s0.t.hmny.io"

{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "difficulty": 0,
    "extraData": "0x",
    "gasLimit": "0x4c4b400",
    "gasUsed": "0x0",
    "hash": "0x5cb6e0752530cef5e25c52539feca22b8ad197cca60c04cf06f4ee05d6537096",
    "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "miner": "0x3f6e680ec5456f540a833e77df4c8ed20a20f274",
    "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "nonce": 0,
    "number": "0x29a1",
    "parentHash": "0x30d28fb69701f8348e0cd6a7abbacceb4286009fc43827dc243e79508da057d7",
    "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "size": "0x50c",
    "stakingTransactions": [],
    "stateRoot": "0x096fac171e818e54e611d3543fd43b1929a4468d17dcb8766d18eaf1e426749c",
    "timestamp": "0x5e755a56",
    "transactions": [],
    "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "uncles": []
  }
}

Here is the list of failed transaction messages which can be checked by querying your transaction hash, checking the transaction hash on explorer or checking the blockchain pool transactions.

Here is how with the hmy cli :

The easiest way to get detailed help is to use the cli itself. For example below is the cookbook which gives an overview of various commands.

./hmy cookbook --node="https://api.s0.t.hmny.io"

#Cookbook of Usage

#Note:

#1) Every subcommand recognizes a '--help' flag
#2) If a passphrase is used by a subcommand, one can enter their own passphrase interactively
#   with the --passphrase option. Alternatively, one can pass their own passphrase via a file
#   using the --passphrase-file option. If no passphrase option is selected, the default
#   passphrase of '' is used.
#3) These examples use Shard 0 of Open Staking Network as argument for --node

#Examples:

#1.  Check account balance on given chain
./hmy --node="https://api.s0.t.hmny.io" balances <SOME_ONE_ADDRESS>

#2.  Check sent transaction
./hmy --node="https://api.s0.t.hmny.io" blockchain transaction-by-hash <SOME_TX_HASH>

#3.  List local account keys
./hmy keys list

#4.  Sending a transaction (waits 40 seconds for transaction confirmation)
./hmy --node="https://api.s0.t.hmny.io" transfer \
    --from <SOME_ONE_ADDRESS> --to <SOME_ONE_ADDRESS> \
    --from-shard 0 --to-shard 1 --amount 200 --passphrase

#5.  Sending a batch of transactions as dictated from a file (the `--dry-run` options still apply)
./hmy --node="https://api.s0.t.hmny.io" transfer --file <PATH_TO_JSON_FILE>
#Check README for details on json file format.

#6.  Check a completed transaction receipt
./hmy --node="https://api.s0.t.hmny.io" blockchain transaction-receipt <SOME_TX_HASH>

#7.  Import an account using the mnemonic. Prompts the user to give the mnemonic.
./hmy keys recover-from-mnemonic <ACCOUNT_NAME>

#8.  Import an existing keystore file
./hmy keys import-ks <PATH_TO_KEYSTORE_JSON>

#9.  Import a keystore file using a secp256k1 private key
./hmy keys import-private-key <secp256k1_PRIVATE_KEY>

#10. Export a keystore file's secp256k1 private key
./hmy keys export-private-key <ACCOUNT_ADDRESS> --passphrase

#11. Generate a BLS key then encrypt and save the private key to the specified location.
./hmy keys generate-bls-key --bls-file-path <PATH_FOR_BLS_KEY_FILE>

#12. Create a new validator with a list of BLS keys
./hmy --node=https://api.s0.os.hmny.io staking create-validator --amount 10 --validator-addr <SOME_ONE_ADDRESS> \
    --bls-pubkeys <BLS_KEY_1>,<BLS_KEY_2>,<BLS_KEY_3> \
    --identity foo --details bar --name baz --max-change-rate 0.1 --max-rate 0.1 --max-total-delegation 10 \
    --min-self-delegation 10 --rate 0.1 --security-contact Leo  --website harmony.one --passphrase

#13. Edit an existing validator
./hmy --node="https://api.s0.t.hmny.io" staking edit-validator \
    --validator-addr <SOME_ONE_ADDRESS> --identity foo --details bar \
    --name baz --security-contact EK --website harmony.one \
    --min-self-delegation 0 --max-total-delegation 10 --rate 0.1\
    --add-bls-key <SOME_BLS_KEY> --remove-bls-key <OTHER_BLS_KEY> --passphrase

#14. Delegate an amount to a validator
./hmy --node="https://api.s0.t.hmny.io" staking delegate \
    --delegator-addr <SOME_ONE_ADDRESS> --validator-addr <VALIDATOR_ONE_ADDRESS> \
    --amount 10 --passphrase

#15. Undelegate to a validator
./hmy --node="https://api.s0.t.hmny.io" staking undelegate \
    --delegator-addr <SOME_ONE_ADDRESS> --validator-addr <VALIDATOR_ONE_ADDRESS> \
    --amount 10 --passphrase

#16. Collect block rewards as a delegator
./hmy --node="https://api.s0.t.hmny.io" staking collect-rewards \
    --delegator-addr <SOME_ONE_ADDRESS> --passphrase

#17. Check elected validators
./hmy --node="https://api.s0.t.hmny.io" blockchain validator elected

#18. Get current staking utility metrics
./hmy --node="https://api.s0.t.hmny.io" blockchain utility-metrics

#19. Check in-memory record of failed staking transactions
./hmy --node="https://api.s0.t.hmny.io" failures staking

#20. Check which shard your BLS public key would be assigned to as a validator
./hmy --node="https://api.s0.t.hmny.io" utility shard-for-bls 2d61379e44a772e5757e27ee2b3874254f56073e6bd226eb8b160371cc3c18b8c4977bd3dcb71fd57dc62bf0e143fd08