Mera,
the native unit.

01What Mera is

Mera is the native unit of MLabChain. It is issued only for accepted ML_WORK certificates, and it is transferable on the chain to any other account. Balances are maintained as O(1) chain metadata, and state is defined by replaying the canonical block history.

Mera is not a contract on another chain. It is not a representation of anything off-chain. It is a balance in the C++ state engine, signed into the block history of MLabChain, and enforceable by any node that replays that history.

02Supply

Total supply is capped at 100,000,000 MERA. The cap is enforced in two places: in the C++ state engine during ML_WORK validation, and in the ERC-20 representation contract as an ERC20Capped extension.

Supply is stored as chain metadata, not recomputed from account balances. Every issuance and every burned fee updates it in a single integer. This makes supply verification O(1) instead of O(accounts).

03Issuance

Mera is not minted by mining. It is minted by verified scientific work. The reward for a submission is computed from:

• the symbolic operation count of the training run;
• the improvement over the challenge's current best quality;
• the challenge's remaining budget;
• the global supply cap.

All four are integer quantities. All four are checked by the C++ core. See the reward formula for the exact arithmetic.

04Fees

Every transfer pays a fee. Every ML_WORK submission pays a separate, higher fee. Fees are burned, meaning they are removed from supply entirely rather than paid to a miner.

Burning is a policy choice. It means total supply decreases over time as transfers happen, offsetting ML-work issuance. The steady-state supply depends on the ratio of transfers to ML submissions, which is not modelled in v0.3 and would need economic simulation before any production deployment.

Fees exist primarily to make spam expensive. A mempool with a minimum fee of zero is a mempool that fills instantly. The reference minimums are set high enough that filling the mempool has a real cost.

04Accounts and addresses

Every account is identified by an Ed25519 public key. The account address is derived deterministically from the public key:

payload = SHA256(pubkey)[:40]                    # 40 hex chars
checksum = SHA256("MERA-ADDR-V3|" + "MERA1" + payload)[:8]
address = "MERA1" + payload + checksum

The checksum is not optional. A single-character typo in a recipient address produces a checksum mismatch, and the C++ core rejects the transaction. This is a small feature that prevents a large class of user error.

05Multisig

Multisig accounts use the prefix MERA2. An m-of-n threshold signature set is required to authorise a transfer or a governance action.

Signer keys are sorted canonically before address derivation, so the same set of keys always produces the same address regardless of the order in which they are supplied. The signature set must have exactly one signature per key, in the same sorted order.

06Key rotation

A KEY_ROTATE transaction changes the authorized public key for an account without changing the account address. This lets a user replace a potentially compromised key while keeping the same balance, the same history, and the same identity on the chain.

After rotation, the new key authorizes transfers, block producer signatures, and ML submissions. The old key is no longer valid for anything.

07Transfers

A transfer is signed by the sender's current authorization key, has a monotonically increasing account nonce, and includes the recipient address, the amount, the fee, and an optional note.

The nonce is checked against the pending transaction set as well as the committed state. This means a sender can queue multiple transactions, and each one must use the next nonce in sequence. A transaction with a stale nonce is rejected.

The sender's balance is also reserved against pending transactions. A user who submits two transfers cannot spend the same balance twice, even before either one is mined.

08Wallet

The reference wallet is a single file at mera_data/wallet.json. It contains:

• the account address and public key in plaintext;
• the Ed25519 private key, encrypted.

Encryption uses Scrypt with parameters N=2^15, r=8, p=1 to derive a 32-byte key from the password, and AES-256-GCM to encrypt the private key with the authentication tag bound to the string MERA-WALLET-V2.

The KDF parameters are stored in the file so a future version can raise them without breaking existing wallets. The wallet format is versioned; a v1 wallet from the earlier line is refused.

Wallet creation asks for the password twice and requires at least 10 characters. Backups are a separate command: wallet-backup --output FILE. The wallet is not included in the chain backup.

09ERC-20 representation

contracts/MeraScientific.sol is an ERC-20 template intended as an EVM representation of Mera. It includes:

• 8 decimals, matching the native unit;
• a hard cap of 100,000,000 MERA;
• a MINTER_ROLE reserved for a bridge authority;
• a per-deposit replay protection map;
• a PAUSER_ROLE for incident response;
• AccessControlDefaultAdminRules with a 2-day delayed admin transfer;
• ERC20Permit and ERC20Burnable.

10What Mera is not

• Not a currency. No merchant acceptance, no legal tender status, no stable value.
• Not a security. No claim on any asset, no expectation of profit from a common enterprise. Whether a regulator agrees is a separate question, and one the project does not answer.
• Not an investment. There is no price. There is no market. There is no promise of either.
• Not tradeable on any exchange. There is no listing and no plan for one.
• Not a store of value. The reference implementation burns fees and issues for scientific work; the resulting supply curve is not tuned for stability.
• Not backed by anything. Mera represents a claim on the MLabChain network's own accounting. Nothing else.

Next: CLI and protocol reference →