Estimation broke environmental markets. Sensors are the truth.

Mālama replaces estimation and self-reported figures with hardware-signed sensor readings. Each reading is signed at the device, anchored on chain, and verifiable by anyone. One protocol, two product lines: carbon proved it, AI compute scales it.

01 Start where you are

These docs route by role. Pick the path that matches what you are here to do.

02 What the network does

• Signs environmental sensor readings at the device with ECDSA, before anything can alter them.
• Anchors each reading on Cardano as a SaveCard, using CIP-68 datum metadata, as archival proof.
• Settles market activity, staking, and governance on Base through the MLMA digital tool.
• Pays operators who run Hex Nodes and validators who verify the data.
• Serves verified data into nine markets, from carbon to AI compute emissions to grid intelligence.

03 Live proof

The carbon product line has run continuously on Cardano preproduction since June 2024. This is operating infrastructure, not a concept.

Quick start

The shortest path through the docs depends on what you came to do. Each route below is three pages or fewer to a working understanding.

01 If you are evaluating a Hex Node

1. Read Genesis 200 overview for the program shape and price.
2. Read Genesis rewards for how the reward is calculated and vested.
3. Read Operator guide for what running a node actually involves.

02 If you are evaluating the token and the model

1. Read Token overview for the digital-tool framing and what MLMA is for.
2. Read Supply and allocation and Emissions and revenue.
3. Read The nine verticals and Oracle and settlement.

03 If you are integrating or auditing

1. Read How verification works for the signing path.
2. Read The two chains for what lives where.
3. Read Agent access to consume the docs programmatically.

Key concepts

Five ideas carry the rest of the documentation. Read these once and the reference set reads easily.

01 The Reality Engine

The protocol is a six-layer pipeline that takes a physical measurement and turns it into a verifiable, tradeable record.

02 dMRV

Distributed measurement, reporting, and verification. Conventional environmental markets rely on estimates and periodic audits. dMRV replaces the estimate with a continuous, device-signed reading, so the measurement and its proof are the same object.

03 SaveCards

A SaveCard is the on-chain record of a signed reading, anchored on Cardano using CIP-68 datum metadata. The proof is permanent. The underlying data stays under the control of the party that produced it. These are two separate properties and the docs hold them apart deliberately.

04 Hex Nodes

A Hex Node is the sensor and signing unit operators deploy. The name follows the H3 geographic cell system that the network uses to place and reason about coverage. Each node signs its readings at the hardware level before they leave the device.

05 Two chains, two jobs

Cardano carries archival proof. Base carries market activity, staking, and governance through the MLMA digital tool. The two are not bridged at the token generation event. See The two chains for why the split is intentional.

Glossary

One definition per term. Where a term has a fuller treatment, the definition links to it.

What Mālama is

Mālama Labs builds the physical data oracle for environmental markets: hardware-signed, cryptographically verified data infrastructure for carbon, energy, AI-compute emissions, and the markets that depend on them.

01 The problem it addresses

Environmental markets run on estimates. Carbon credits, ESG reports, supply-chain claims, and now AI energy disclosures are mostly self-reported and audited after the fact. The gap is not a shortage of data. The gap is that very little of the data is tied to physical reality at the point of measurement. That gap becomes expensive at scale, in the form of disputes, discounts, and fraud.

02 What it builds

A distributed MRV stack that signs sensor readings at the device and anchors them on chain as SaveCards. The signature happens in hardware, before any system or operator can alter the value. The anchor makes the record independently checkable. The result is a measurement that carries its own proof.

03 Two product lines, one pipeline

How verification works

The verification path is short by design. Fewer steps between the physical event and the permanent record means fewer places for the value to drift.

01 Signed at the device

Each Hex Node signs its readings with ECDSA inside a hardware secure element before the value leaves the sensor. A reading that is altered after signing fails verification. This is the property that separates a hardware-signed reading from a self-reported figure.

02 Anchored as a SaveCard

The signed reading is anchored on Cardano as a SaveCard, using CIP-68 datum metadata. The on-chain record is the proof. It is permanent and independently checkable. The underlying data remains under the control of the party that produced it.

03 Served to markets

Verified records feed the oracle and settlement layer, which serves them into the nine markets the network supports. Market activity, staking, and governance settle on Base. See The two chains.

The two chains

The network uses two chains for two different jobs. The separation is intentional, and the two are not bridged at the token generation event.

Live proof

The carbon line has run continuously on Cardano preproduction since June 2024, with no gaps in the record.

01 Texas Pilot Node #1

The pilot is a single node on a test network. It is non-tribal, and the docs describe it as a pilot, not a production deployment. The signal it carries is a strong uptime record and an unbroken chain of anchored readings since June 2024. That record is the basis for the network's claims about reliability, and nothing more is claimed than the record supports.

Genesis 200

The first node cohort. 195 external nodes plus 5 reserved, at $2,000 each, for a $390,000 external raise. Genesis operators earn from a fixed 25M reward pool, calculated by a transparent formula.

01 The cohort

The 5 reserved nodes are funded separately and are not part of the external raise.

02 How a Genesis operator earns

Genesis reward eligibility is calculated, not promised. A base figure is scaled by three multipliers, then normalized across the cohort to a fixed 25M pool. The full mechanism is on Genesis rewards. Operators also earn ongoing validator fees in USDC, which sit outside the supply cap.

03 Timeline

Hex types

A node's placement sets one of the multipliers on its reward eligibility. The Hex Type multiplier ranges from 0.95 to 1.30×.

Placement reflects coverage value. The network rewards nodes that extend reach over nodes that crowd into already-covered cells.

Data Demand Score

The second multiplier on reward eligibility reflects demand for a node's data. It ranges from 0.70 to 1.30×.

01 What it measures

Not all data is equally useful to the markets the network serves. The Data Demand Score scales a node's eligibility by how much its data is actually drawn on. A node producing data that markets pull frequently scores higher than one whose data sits unused.

02 Where it sits in the formula

Data Demand Score is one of three multipliers on Calculated Eligibility, alongside the Genesis Year 1 multiplier and Hex Type. See the full formula on Genesis rewards. The canonical treatment is Data Demand Score v1.0 in the reference set.

Genesis rewards

The Genesis reward is calculated, not quoted. A base figure is scaled by three multipliers to produce eligibility, then normalized across the whole cohort to a fixed 25M pool. This page describes the mechanism. It does not project earnings.

01 The formula

Because the pool is fixed at 25M and the final figure is normalized across the cohort, an operator's reward depends on the whole cohort, not on a fixed per-node number. The formula is transparent so any operator can see exactly how their eligibility is built.

02 Vesting

Rewards vest 15 / 15 / 20 / 20 / 30 across five milestones over 12 months.

Forfeited tranches route to the Genesis Performing Operator Bonus Pool. They do not return to the post-emission reserve.

03 What this page does not say

Validator fees

Validators are paid in USDC for verifying data. These fees sit outside the 500M supply cap and pay on an ongoing basis.

01 How fees work

Validator fees are a usage fee, denominated in USDC, paid for the work of verifying SaveCards and AI compute records. Because they are paid in USDC rather than minted, they do not draw on the token supply and do not count against the cap.

02 Relationship to Genesis rewards

Genesis rewards come from the fixed 25M pool and vest over 12 months. Validator fees are separate, ongoing, and outside the cap. An operator can earn both. The canonical treatment is Validator Fees v1.0 in the reference set.

Operator guide

What running a Hex Node involves, from receiving hardware to a vesting node. This page is a stub in the preview build and expands before launch.

01 Sequence

1. Receive hardware. Genesis 200 hardware ships at the end of December 2026.
2. Deploy and boot the node. The boot milestone releases the first vesting tranche.
3. Run continuously. Uptime and the Data Demand Score shape ongoing eligibility.
4. Pass the PONO milestone at roughly 90 days, then the 6, 9, and 12-month milestones.

The MLMA digital tool

MLMA is the network's digital tool on Base, used for staking, governance, and market activity. It is a digital tool under the SEC-CFTC Joint Interpretation of March 17, 2026 (S7-2026-09). The docs do not describe it as a utility token.

01 Contract

02 What MLMA is used for

• Operators. Genesis rewards from the fixed 25M pool, vesting over 12 months.
• Stakers. A share of network revenue, on Base.
• Governance. Voting on network parameters, on Base.
• Foundation. A share of revenue directed to the Foundation.

03 Regulatory framing

Supply and allocation

A 500M hard cap, allocated across four groups. The community allocation is the largest, and it breaks down further into emissions, the Genesis pool, stewardship, and a reserve.

01 Top-level allocation

02 Community sub-allocation

Emissions and revenue

Network emissions follow a smooth eight-year taper, then the network becomes revenue-funded. Revenue is split four ways, with the largest share burned until a floor is reached.

01 Emission schedule

The 60M emission allocation releases over eight years on a declining taper, summing to 60M.

02 Revenue split

Once the network is revenue-funded, network revenue is divided four ways.

The burn continues until circulating supply reaches a 250M burn floor. After the floor, the burn share redirects to the Foundation.

The nine verticals

Verified physical data serves nine markets. The same signing and anchoring path underlies all of them; what changes is who buys the verified record and why.

Instruments

The network settles two carbon instruments. They serve different stages of a project's life.

Oracle and settlement

The oracle and settlement layer serves verified records into the nine markets and settles the fees they generate. The figures below are modeled, not actuals.

01 Modeled oracle and settlement revenue

02 Headline

Total modeled Year 5 revenue is $147.44M, of which oracle and settlement fees are the $68.44M recurring subset. These are modeled figures from the financial model, labeled as such, and are not a forecast of token price or operator earnings.

Agent access

These docs are built to be read by software, not only by people. Two of the peer DePIN networks expose machine-readable docs; Mālama follows the same practice.

01 Markdown sources

Each page is published as clean Markdown at a predictable path, generated from the same canonical source as the rendered page, so an agent can fetch the Markdown directly rather than parsing HTML. The per-page Markdown layer rolls out in Phase 2; the index below is live now.

02 Index

A root index lists the canonical pages for ingestion.

Canonical document set

The five V1 documents are the reference floor for everything in these docs. Each renders behind the page pattern and links its print-ready PDF.

Resources

Status, help, and the things a reader reaches for when stuck.

01 Status and proof

The pilot record is the network's live status: 2,786+ SaveCards on Cardano preproduction since June 2024, zero gaps, on Texas Pilot Node #1. See Live proof.

02 Team

03 Links

• malamalabs.com, the marketing and investor site.
• aipower.fyi, the Foundation's open AI energy dashboard.
• GitHub, the network's open repositories.