MobileCoin, and the payments network that puts its state in SGX enclaves

A payment network with no central authority

MobileCoin is a payment network with no central authority, and the fundamental goal of the network is to safely and efficiently enable the exchange of value, represented as fractional ownership of the total value of the network.

Like most cryptocurrencies, MobileCoin maintains a permanent and immutable record of all successfully completed payments in a blockchain data structure. Cryptography is used extensively to establish ownership, control transfers, and to preserve cash-like privacy for users.

The interesting part is where the cryptography runs. Transactions are prepared by the user on their local computer or mobile device, and submitted to a secure enclave running on a validator node of their choice. The validator node checks the transaction and, assuming it believes the transaction is valid, shares it with other nodes in the network.

Then the constraint that shapes the whole architecture appears. The transaction is passed only to peer secure enclaves that can establish, via remote attestation, that they are running unmodified MobileCoin software on an authentic Intel processor. Each secure enclave replicates a state machine that adds valid transactions to the ledger in a deterministic order using a consensus algorithm called the MobileCoin Consensus Protocol.

That is a strong statement about the trust model. The nodes are trusted to relay and to run the software, but not trusted to validate, because the validation happens inside hardware the node operator does not control, and the enclave attests to what it is running. The MobileCoin Consensus Protocol is described as a high-performance solution to the byzantine agreement problem that allows new payments to be rapidly confirmed.

The primary language is Rust, the licence is a custom one recorded per crate, and the recent releases are v7.2.1 from 2026-10-14, v7.2.0 from 2026-10-08 and v7.1.0 from 2025-10-10.

Key images, and why the ledger does not say who paid whom

The transaction model is the part of the design that most directly delivers the privacy claim, and the project description is precise about it.

The MobileCoin blockchain is the source of truth for the allocation of value. It consists of an ordered collection of transaction outputs, organized into blocks. Each transaction output, a txo, has a unique corresponding construction called a key image. Every txo initially appears in the blockchain in a spendable state, as an unspent transaction output or utxo. Every successful payment consumes some utxos as inputs and creates new utxos as outputs. When a utxo is consumed, its corresponding key image is permanently added to the blockchain, ensuring that it cannot be spent a second time.

That is the double spend defence, and it is the whole trick. The key image is a value that is published when the output is spent, derived from the output in a way that lets the network verify the spend without revealing which output it came from. Anyone can check that a key image has not appeared before, so a coin cannot be spent twice, and nobody can tell from the ledger which utxo was consumed.

Ownership of a utxo is equivalent to knowledge of two private keys, the spend private key and the view private key, which together provision control over discovery and transfer of value. Most users derive both from a single underlying key called the root entropy. To receive a payment, a user calculates the two public key values corresponding to their private keys to share with the counterparty, and MobileCoin specifies a standard encoding scheme using a base-58 symbol library for exchanging payment information safely.

The project description refers to CryptoNote-style transactions to preserve the privacy of both the sender and the receiver, and points at the transaction crate for the details and at the ledger_db crate for the blockchain format and storage.

A fixed supply of 250 million, and a lot of small crates

The total value of the MobileCoin network is fixed by convention at a sum of 250 million mobilecoins, and each mobilecoin consists of 10 to the power of 12 indivisible parts, each referred to as one picomob. Each utxo represents an integer number of picomob that can be consumed in a valid payment.

A fixed supply and a twelve decimal place unit is a deliberate combination. The unit is fine enough that a payment can be a micropayment without rounding, and the supply is small enough to be meaningful per coin, which is a design goal shared with privacy coins that argue the divisibility of a large supply is a privacy liability.

The repository is a large Rust workspace, and the crate names describe the system better than any summary.

The attest family is the remote attestation primitives, with crates for the attestation key, the API, core, trusted and untrusted parts, and the verifier with its config and types. The enclave-boundary crate is the Intel SGX ECALL infrastructure, and the sgx crate is the SGX support layer. The mcbuild crate is the tooling for building and signing enclaves, and mcconnection provides attested MobileCoin connections.

The crypto family is the largest group and is worth reading as a list of primitives: box, digestible with a derive macro and its test utilities, signature, keys, memo-mac, message-cipher, multisig, noise, ring-signature with a signer, sig, and x509 utilities.

The consensus family contains the enclave, its EDL interface, its implementation, the measurement crate, a mock, mint-client, and the scp crate for the consensus protocol with a play binary and types. The fog family covers the private payments for mobile devices part, and the remaining crates handle peers, mobilecoind, the ledger, the transaction layer, the common crate for shared items and build-info for compile time measurements.

The fog: where a blockchain becomes a mobile payment system

The fog directory is described as private payments for mobile devices, and it is the part of the repository that makes MobileCoin a payment network rather than a cryptocurrency.

The fog crates are organised by function. There is fog/api, fog/block_provider, fog/distribution, fog/enclave_connection and fog/kex_rng. There is a ledger group with fog/ledger/connection, fog/ledger/enclave, its api, edl, impl, measurement and server crates, and an ingest group with fog/ingest/client, enclave, its api, edl, impl, measurement, report and server crates.

The shape suggests the design. A fog server accepts a user's request, an enclave on the server side does the work, and the enclave connects to other enclaves to reach a consensus about the result, in the same attested pattern as the main consensus. The report crate in the ingest group is the part where a result is signed and returned, and the kex_rng crate is the key exchange, which is where the privacy of the client to server channel is established.

The important thing about all of this is that it is argued in a document rather than only in code. The repository carries fog-threat-model-2.1.0.md, a threat model for the fog at version 2.1.0, and that is the file to read before believing the privacy claims of the mobile path, because the fog is where a user's data touches a server the user does not own.

The two other top level directories that are not part of the core protocol are the same kind of thing. There is a light-client directory and a mint-auditor directory, which are the tools for a user who wants to verify without running a full node, and a tools directory plus a test-vectors directory, which is what a project does when it wants its cryptography to be checkable by someone other than its authors.

Building: cargo, and a Docker image for the CI environment

The build instructions are short for a project of this size, and the reason is that the workspace is a normal Cargo workspace.

The workspace can be built with cargo build and tested with cargo test, and either command recognises the cargo release flag to build with optimisations.

cargo build

The catch is the enclave dependency. Some crates, for example consensus-service, depend on Intel SGX, which adds additional build and runtime requirements, and the project points at BUILD.md for detailed information about setting up a build environment, how enclaves are built and how the build is configured.

For a quick start, you can build in the same Docker image the project uses for its CI, using the mob tool, which requires Docker to be installed.

# From the root of the cloned repository
./mob prompt

# At the resulting docker container prompt
cargo build

That is a sensible default for anything touching SGX, because the toolchain requirements for building an enclave are not the same as for an ordinary Rust crate, and a pinned image removes a whole class of local setup problems.

The repository has the supporting files you would expect from a project of this maturity. There is a rust-toolchain file, a clippy.toml and a rustfmt.toml, a codecov.yml, a .devcontainer.json, a Brewfile for the macOS side of the toolchain, a .mobconf, a CLA.md, a CHANGELOG.md and a BRANCHING.md, plus a buf.work.yaml for the protobuf workspace and a go-grpc-gateway directory and an api directory for the gRPC surface, and an admin-http-gateway.

Licence per crate, terms of use, and a cryptography notice

The licensing arrangement is unusual and worth reading carefully. MobileCoin is available under open-source licences, and the instruction is to look for the LICENSE file in each crate for more information. So there is not one licence for the project, there is one per crate, and the top level file is a starting point rather than the answer. The project metadata records the licence as a custom one that GitHub cannot classify, so the per crate files are the authoritative text.

There is a second layer of terms. The project description says you must read and accept the Terms of Use for MobileCoins and MobileCoin Wallets to use MobileCoin Software, and points at TERMS-OF-USE.md. A licence governs what you may do with the code, and terms of use govern what you may do with the network, and both apply.

The cryptography notice is the third. The distribution includes cryptographic software, and the project warns that your country may have restrictions on the use of encryption software and asks you to check your country's laws before downloading or using it. That is a real consideration for a payment network built on ring signatures and enclaves, and it is unusual to see stated this prominently in a README.

There are also three separate documents for the three audiences. TESTNET.md has the instructions for participating in the test network, MAINNET.md has the instructions for using MobileCoin, and SECURITY.md sits alongside them.

The remaining structure is the operational side of a network: the peers crate for peer to peer networking, the mobilecoind daemon and the example client code, the mobilecoind-json and mobilecoind-dev-faucet directories, the account-keys crate, the light-client, the mint-auditor, a hooks directory, a t3 directory, and a start-testnet-client.sh script.

Editorial conclusion

Adopt MobileCoin if you are working on privacy-preserving mobile payments and want a reference implementation of a CryptoNote style ledger with attested enclaves, since the repository documents the transaction model, the consensus protocol and the enclave boundary in unusual detail. Do not adopt it as a general purpose payment system for your application, because the design commits to Intel SGX hardware, a fixed supply and a specific privacy model that only holds while the enclave boundary holds. Before you build against it, read the terms of use, which must be accepted to use the software, and check the fog threat model document, since the fog directory is the part that turns a blockchain into a mobile payment system and it is where the privacy guarantees are actually argued.

Frequently asked questions

Official sources

1. Issues
2. mobilecoinfoundation/mobilecoin on GitHub
3. README
4. Releases