Frequently asked
questions.

A local, single-user ledger that records what you trained, when, with what parameters, and with what metrics, in a form you can verify later by re-running the training.

No. A signed JSON file on disk would give you most of the same guarantees. The blockchain part adds three things: a hash-linked history that makes tampering detectable, a transferable unit that multiple parties can hold, and a reward mechanism that pays for verified work.

If you only need a signed record, use GPG on a JSON file. MLabChain exists because some people want the other three things too.

Researchers who train machine-learning models and want a durable record of what they ran. Especially in fields like high-energy physics, where an analysis may be re-derived years after the fact and the original configuration is often lost.

It is not for enterprises, not for financial applications, and not for anyone who needs a permissionless network.

No. It is smaller and narrower. MLflow, Weights & Biases, and DVC track experiments across a team. MLabChain tracks one person's work on one machine, with an emphasis on cryptographic verifiability rather than collaboration.

If you have a team, use a proper registry. If you are one person and you want to be able to prove what you ran, use MLabChain. There is no reason you cannot use both.

Mera is the unit that the chain issues for verified ML work. It is minted only when a submission measurably improves the frontier of a registered challenge. It is transferable on the chain to any other account.

It is not a currency, not a security, and not an investment. It is a record of verified scientific work, with a transferable representation.

No. There is no exchange, no liquidity pool, and no market. Mera is issued by training models against challenges and can be transferred between wallet addresses on the same chain. That is the full extent of its circulation.

If someone offers to sell you Mera, they are either confused or scamming you.

That is not a question the project can answer, and it is not a question the project is trying to answer. Mera's value, if any, would come from the scientific work it represents and the willingness of some future community to recognise that work.

The project does not promise a price, does not plan a listing, and does not describe itself as an investment. Treat it as a receipt, not as an asset.

You can earn Mera, but it is not mining in the Bitcoin sense. Bitcoin mining is a hash grind. Earning Mera requires training a model against a registered challenge and submitting the result. The chain pays you only if your submission improves the challenge's current best quality.

There is a separate SHA-256 PoW step that seals blocks, but its difficulty is a few leading zeroes and it takes milliseconds. That step is not the source of Mera.

The cap is a design choice, not a claim about future value. It ensures that the sum of all rewards is bounded, which simplifies the protocol and makes some categories of attack (unbounded issuance through fabricated work) impossible by construction.

The specific number, 100 million, is arbitrary. It was chosen because it is large enough to accommodate many challenges and small enough to fit comfortably in a u64 when multiplied by the atomic unit multiplier.

No. A cryptocurrency requires a peer-to-peer network, an exchange, liquidity, and a market that sets a price. None of those exist here. MLabChain is a local ledger with an optional multi-node testnet mode and a native unit.

Calling it a cryptocurrency would be misleading. The project explicitly asks readers not to.

This question comes up every time someone new reads the docs, and it deserves a real answer rather than a dismissal.

The technical problem is called the verification asymmetry. Bitcoin's work is expensive to produce and cheap to verify — one hash check per block. Useful work is expensive to produce and expensive to verify — you have to re-run the training. A decentralized network requires cheap verification. Useful work destroys the asymmetry.

This is why every "useful proof-of-work" project has either collapsed, remained tiny, or quietly pivoted to storing data for other crypto projects. Primecoin, Gridcoin, and Filecoin are all instructive case studies.

The full analysis is on the Proof-of-Scientific-Work page. The short version is: you can have useful work, or you can have secure decentralized mining, and so far nobody has had both.

The contract in contracts/MeraScientific.sol is a representation template. It defines an ERC-20 token with the same name and cap, and it includes a MINTER_ROLE that a bridge authority would hold in a future integration.

It is not a trustless bridge. There is no code that reads the MLabChain L1 state, verifies a deposit proof, or locks native Mera. The mint authority is a full trust boundary. Anyone deploying this contract as-is is centralizing issuance in a single key.

The code is a research tool. Reading, running, and modifying it is no different from reading, running, and modifying any other open-source software.

Distributing a transferable token, offering it to the public, or accepting it as payment raises securities law, tax law, and AML questions that this project does not address and cannot advise on. Consult a lawyer in your jurisdiction before doing any of those things.

Python 3.10 or newer, a C++17 compiler, CMake 3.20+, and three system libraries: OpenSSL, SQLite3, and the Boost headers. The build produces a single executable called mera_core. The full build takes about a minute on a modern laptop.

No. The only paid verifier in v0.3 is deterministic linear regression, which runs on the CPU in pure Python. The chain does not pay for GPU training.

You can train anything you want. You cannot submit anything other than a MLabChain-linear-v4 verifier submission as a paid ML_WORK transaction.

The chain pays for work whose output every node can independently reproduce. A neural network trained with stochastic gradient descent on a GPU is not reproducible byte-for-byte across machines, so it cannot be paid. It can still be recorded as provenance — as an artifact hash — but not as monetary work.

The balance is gone. There is no recovery mechanism. No seed phrase, no social recovery, no central authority to ask. This is true of every non-custodial system and is not specific to MLabChain.

Back up the wallet file separately from the chain. Use wallet-backup and store the result somewhere you will still have access to in six months.

Yes, on the same machine or across a local network. The reference P2P protocol is a line-based TCP layer with sync and relay. Two nodes with the same genesis parameters can reach consensus through it.

Do not expose the P2P port to the public Internet. The protocol has no authentication, no encryption, and no rate limiting.

Because the two halves answer to different requirements. The scientific layer must be easy to change — Python. The consensus layer must be stable and predictable — C++.

The split is described in detail on the Architecture page.

Crash isolation, auditable state transitions, and no FFI layer. Each call to the core is a shell command a reader can inspect. If the C++ core crashes, the Python session survives with a clear error.

Because the state is defined by replaying the chain, not by the database format. SQLite is a materialized view of that state, chosen because it gives atomic transactions, crash recovery, and an online backup API for free.

If you delete the database, you can rebuild it from the chain. If you change the database by hand, validation will detect it — every account is compared against a fresh replay.

Small signatures (64 bytes), fast verification, no parameter choices, and no malleability concerns that require special handling. RSA would produce signatures hundreds of bytes long; ECDSA needs careful nonce management that Ed25519 avoids by construction.

To bound the maximum issuance from any single transaction. Without a per-proof cap, a challenge author could register a challenge with a very large budget and a very large operation count, and a single submission could drain a significant fraction of the remaining supply.

The cap is a conservative default. It can be overridden in the source, but doing so requires a hard fork and should be justified by a specific use case.

LSWU stands for LabChain Scientific Work Unit. It is a scientific audit score computed from the training-set size, wall time, and quality of the model relative to the baseline.

It is stored in every ML_WORK transaction as provenance. It is not used to compute the reward — that is integer-only and based on operations and marginal quality. The LSWU is a separate, human-readable number that an auditor can use to compare submissions on a more intuitive scale.

Yes, under the Apache License 2.0. The full source, including the C++ core, the Python client, the contracts, and the documentation, is available.

The project's own list, in order of value:

1. Fix the four correctness bugs listed on the Security page.
2. Add tests for the untested half of the CHANGELOG claims.
3. Add a second verifier class — a small MLP with a deterministic training loop.
4. Add file-backed datasets so challenges can be defined against real data.
5. Write the bridge specification document, even without the bridge code.

Items 1 and 2 are a weekend's work each and would meaningfully improve the project's reliability. Item 5 is what a regulator or exchange would ask for first, before any technical work on a bridge.

Do not work on launching a token, building a market, or integrating with an exchange. Those are not things the project can honestly support, and pulling the project in that direction would undermine the parts that do work.

If you want to build a financial product, build it as a separate project with your own legal review. Do not tie MLabChain's reputation to it.

Open an issue on the repository. Include the exact command you ran, the version of Python and the compiler, and the output. The protocol constants page lists every value that might differ across builds.