Metaverse main net parameter info

Metaverse main net parameters

Total amount:100,000,000 ETP

Current circulation:

Mining algorithm: Improved version of ETHASH

Actual block generation time: 33 Seconds

ETP mining rewards: The initial reward is 3ETP. Mining rewards decrease by 5% every 500,000 blocks.

Algorithm difficulty adjustment: Adjusts every block (with no difficulty bomb)

Main net go-live time: February 11, 2017

Read More

Metaverse is about to release details about MIP


Metaverse’s network began operating on February 11th, 2017 and has been running safely for three months (89 days) now. Some of our network’s operating parameters are as follows.

◦ Total volume: 100 million
◦ Current turnover: 26.93 million
◦ Mining algorithm: ethash
◦ Average block generation speed: 33 seconds.
◦ PoW mining reward: the reward starts at 3 ETP and will decrease by 5% every 500,000 blocks.
◦ PoW difficulty adjustment: the difficulty is adjusted every block.
◦ Date network went online: February 11th, 2017

For more details, interested readers can refer to our white paper:

MIPs (Metaverse Improvement Proposals)

Metaverse’s core development team has updated a total of 7 patch versions during this period, namely versions 0.6.6-0.6.8.

Most of the bug fixes have been posted on Github:

With an increase in the number of users, we found some problems. Some problems are related to the wallet experience, while others concern compatibility issues. After discussing this, our core team has decided to focus on fixing non-functional bugs first. As for digital identity, asset pledges and other functions, Metaverse will release a process similar to BIPs , with the aim of building a better Metaverse by adopting community suggestions. This process will be called MIP and is currently being drafted. More detailed information can be found on Github: details. (continuously updated).

Regarding the MIP, Metaverse will provide ETP incentives. Please anticipate the release of more detailed information.

First MIP - digital identity (Avatar, Digital Identity)

The next goal of Metaverse’s core development team is to design and realize digital identities (Avatars).

The team has been researching on digital identity, and has drafted a working definition:

Digital identity is a general name for the Profile information of an account corresponding to the master private key owned by a user.

Profiles are assigned a unique identifier within the network. On Metaverse, this identifier will be called a DID (Digital Identity, similar to the concept of aliases in Bitshares).

A Profile contains the following information:

◦ Personal transaction records.
◦ Statistics and record details, does not require additional storage.
◦ Asset information.
◦ Statistics and record details, does not require additional storage.
◦ Feedback records from across the entire network.
◦ Statistics and record details, does not require additional storage.
◦ Customized field description.
◦ This customized field has a validity period. The field should indicate the height interval at which it is valid, and this field can be modified to correspond to different block heights.
◦ This field is presented in the form of key: value and has no upper limit. However, the fee incurred increases exponentially as the number of characters increases.
◦ Requires additional storage.

A digital identity’s core functions are authentication and transaction authorization.

Metaverse will successively release pieces of research and design related to digital identities.

Metaverse core development and operations team

Read More

User guide for Metaverse ETP Wallet server


The Metaverse Wallet is built on Libbitcoin.
The use of rpc is similar to bitcoin’s, but they have different interfaces.

RPC Allocation

The default port for RPC initiation is 8820. Https is not supported for now.
You can configure to other ports on mvs.conf.
Please visit: for code samples of PHP linking to ETP wallets. Sample codes in other languages will be available soon.

Mvs-cli also invokes port 8820 by default to execute RPC.
Hence, the data retrieved from the user explorer is the same as the call of mvs-cli.

Checking help information

All commands support the “help” command.
Mvs-cli can also be an operating console within the user explorer.
1. # Check all commands
2. mvs-cli help
3. # Check specific command parameters and descriptions
4. mvs-cli help send
5. # or
6. mvs-cli send -h

Commands traversing blocks

1. # Inquire the block hash corresponding to a block height
2. ./mvs-cli fetch-header -t $block_height
3. # Check the previous block structure for a corresponding block hash
4. ./mvs-cli getblock $block_hash --json=true

Creation of HD accounts and address management

Metaverse discarded the idea of using random keys since the beginning of its design process. All transactions are managed by sub-private keys of a master private key.

The master private key + index generates corresponding sub-private keys.

Your account number and password belong to the Wallet and is stored locally rather than as on-chain data. Hence, it cannot be imported using the mnemonic passphrase provided together with your Wallet (the 24-word or Mandarin character mnemonic passphrase provides a human-readable phrase to backup your Wallet in case you need to recover your it at a later date).

If you log in to a new wallet, you may not reuse your previous account name and password. A new account must be created. Lost account details are retrievable as long as you have a backup of the mnemonic passphrase.

1. # Create a new account
2. mvs-cli getnewaccount $name $password
3. # Use this account to generate addresses; these addresses absolutely belong to the account.
4. mvs-cli getnewaddress $name $password
5. # Check my account’s address
6. mvs-cli listaddresses $name #password

An account’s name and password are equivalent to the main private key’s alias within a specified wallet. Account names have a one-to-one relationship with main private keys, and using an account’s name and password is equivalent to using its corresponding main private key. Hence, the commands listed above illustrate how a main private key can be used to generate new addresses.

The total number of indexes for a main private key is about 4 billion. By default this increases from zero, so you only need to back up the main private key and should not create a backup for your account name and password.

If you have lost or forgotten your login details, you may retrieve it using your mnemonic passphrase. Using the “importaccount” command, input the size of your designated index; the Wallet will then generate a corresponding digital address. For more details, please check “help”.

On Metaverse, the only certificate of all personal assets (including assets issued by oneself) is the master private key’s mnemonic passphrase.

Metaverse Wallet has yet to make file-level backups, so please make sure to keep a backup of the mnemonic passphrase for your master private key (the 24-word phrase).

Backing up this phrase ensures that you will not lose any of your assets. There is no way to retrieve the mnemonic passphrase using your account’s username and password.

Sending transactions (key points)

1. # “send” command
2. mvs-cli send $name $password $target_address $amount
3. # “sendfrom” command
4. mvs-cli send $name $password $from_address $target_address $amount

Detailed explanation for “send” command (key points):
The “send” command has been optimized for users. It supports regular transactions, breaks up the change into multiple outputs then sends those outputs to randomly chosen addresses belonging to the user. We do not recommend using this command on the back-end.

Application of the “send”command on the server side: when small change needs to be organized or entire amounts sent to other addresses. To send change with certainty, please use the “sendfrom” command instead.

Detailed explanation for “sendfrom” command:
The “sendfrom” command supports sending change to a specific address. It is very similar to implementations of this command in other wallets.

QA about assets and transaction management

  1. How do I check assets using transaction history?
    Transaction histories contain an attachment which has “type”. If the type is etp, it was an ETP transaction. If an asset was issued, the transaction is labeled with some other symbol. Currently there are some test tokens. To view these, use “listassets” without any added parameters.
  2. How should I regard the relationship between ETP and other assets?
    ETP is equivalent to Ethereum’s ETH, and other assets are equivalent to tokens.
  3. What if someone obtains my account
    Fail to get the private key of designated address. If the designated address issues transaction, we have “sendfrom” command to support the address, then the address belongs to the account.
  4. How to create a raw transaction through transfer record? It is similar to the createrawtransaction of bitcoin.
    For rawtransaction, it belongs to component transaction, which is supported by the native command, libbitcoin. We retain the function, but it is not recommended to use. For more details, please visit: Replace the bitcoin part to the address and utxo of Metaverse, which remains valid.

  5. How to use private key to sign the raw transaction?
    As above, it is recommended to use HD address.

  6. How to generate an address via HD?
    /mvs-cli getnewaddress $account_name $account_password

Username and password are equivalent to alias of your main private key in the Wallet. Username and the main private key are one-to-one corresponding relations. The use of username and password is equivalent to the call of corresponding main private key, thus the command mentioned above is to use some main private key to generate a new address.

Read More

ReleaseNotes – the previous version of Metaverse and its download address

Version 0.6.8 release notes:

  1. Now displays transaction hash.
  2. Added the function to send ETP from a specified address.
  3. Fixed the issue of too much ETP being frozen when assets are launched.
  4. Added a feature showing all issued assets.
  5. Added designated block height - checkpoint.
  6. “listtxs”command now orders transactions sequentially, and fixed the bug of inquiring in accordance with address.
  7. Added designated address for small change for “sendmore” command.
  8. Removed the “forgot password” function
  9. Updated non-functional features.

Version 0.6.8b:

  1. Rollback: randomly distributing the search for small change among the trading body.
  2. Repaired some user-facing functionalities.

Version 0.6.8c:

  1. Repaired bug that didn’t allow assets to be transferred on the front page.
    Download address for Linux:
    Download address for OSX:
    Download address for Windows:
    This version is a patch that aims to repair bugs and improve functionality. Users do not need to re-synchronize block data.

Version 0.6.7:

  1. Amended some functionality issues.
  2. Decreased the number of logs generated while synchronizing blocks.
  3. Added the function to deposit into a specified address.
  4. Other known issues.

The updated version, which serves as a patch, aims to repair bugs and improve functions. It is not involved in any account’s data migration. If you want to download the latest version, please visit our official website:

Version 0.6.6:

  1. Added “gettransaction” command. The command takes a transaction hash as input and returns the corresponding transaction’s information and block height.
  2. Modified listtx command. After the modification, the command now returns 100 lines of an account’s transaction records by default rather than the account’s entire transaction history.
  3. Added utxo limitation. If the UTXO of an address contains assets, the ETP in that UTXO can only be used for asset transactions and cannot be used for ETP -> ETP transactions.
  4. Added a function to borrow ETP. When you transfer assets, if an address has insufficient ETP to complete the transfer, you can borrow ETP from other addresses in your account with sufficient ETP to finish the asset transfer.
  5. Updated content indicators on WebUI, making it more user-friendly
  6. Added wrong prompt content on WebUI
    Download address for Linux:
    Download address for OSX:

The updated version, which serves as a patch, aims to repair bugs and improve functions. It is not involved in any account’s data migration. If you want to download the latest version, please visit our official website

Version 0.6.5:

Amending some known issues.
Download address for Linux:
Download address for OSX:

The updated version, which serves as a patch, aims to repair bugs and improve functions. It is not involved in any account’s data migration. If you want to download the latest version, please visit our official website:

Version 0.6.4

Amending some known issues.
The updated version, which serves as a patch, aims to repair bugs and improve functions. It is not involved in any account’s data migration. If you want to download the latest version, please visit our official website:

Read More

Introduction to Metaverse input/output limitation and the rectifying of small change

When the Metaverse was first introduced this week, we realized that miners could not transfer out ETP obtained through mining. After debugging and testing, we found that there was a bug in the group transaction algorithm resulting from a lack of restriction on input/output.

Problems arose with the group transaction algorithm because Metaverse uses address rather than input as the most granular during the process of looking for input. Hence, if an account’s balance is sufficient, all ETP will be transferred retuning 0 to the address. This has led to a particularly large number of problems occurring with input, and too much input will cause a large transaction.
Metaverse uses the UTXO model. In the UTXO model, the number of inputs / outputs is limited.

In Bitcoin, transactions with one proven input and one output occupies about 161 - 250 bytes.
In Bitcoin, transactions smaller than 100kb are termed standard transactions while those larger than 100kb are termed non-standard transactions.
So in Bitcoin, the maximum number of inputs / ouputs is limited to 100KB / 161B ~ = 600 per transaction.

There are similar limitations on transaction sizes on Metaverse. However, due to the asset issue function, the number of inputs / ouputs per transaction is limited to around 333 instead.
For ordinary users, large numbers of small amounts (input) should not appear frequently. If they do, you can manually send the rectified transaction (for large denominations):
You have 900 inputs, and each input contains an ETP. When you want to return the 900 ETP, it is better to divide it into three transactions. Each transactions transfers 300 ETP to the same address A which will contain 3 inputs, with each input containing 300ETP.
This is the same for miners, and each coinbase only generates three ETP.

In other words, miners not only do mining, but also need to undertake the rectification of tokens by swapping small ETP for larger denominations of ETP then lastly placing the ETP into circulation after rectification.

Considering the limitation of around 330 ETP, each transaction can be rectified to 1,000 ETP.
For example, if miners have gotten 20,000 ETP as a reward for mining, they would require about 20 transactions sent to the same address (that is, 20 inputs; the following transactions will become normal).

We fixed the problem in updated 0.6.3 version.
The updated version, which serves as a patch, aims to repair bugs and improve functions. It is not involved in any account’s data migration. If you want to download the latest version, please visit our official website

Read More
Skip to toolbar