Operator Guide.

Pre-arrival checklist

Before hardware arrives, prepare:

• Deployment site. Reliable power, physical security, stable internet. Clear sky view if using the solar option.
• Network plan. Ethernet preferred over Wi-Fi. Keep packet loss low for validation windows.
• Wallet. Cardano or Base wallet ready, with the Device DID registration flow in the Mālama dApp tested.
• KYB documentation. Legal entity verification documents, UBO disclosure, sanctions-screening-ready (required for PONO qualification at day 90).
• Reservation confirmation. Your reservation ID and hex zone ID accessible.

On-arrival checklist

Progress saves in your browser.

1. Inspect hardware on arrival. Verify NEMA 4X enclosure seals before any field exposure. Check the full BOM against the packing list. Confirm device certificate card is included.
2. Mount the hardware. Install using the included mounts. Most setups complete in under 30 minutes. Keep the sensor array exposed to open air for accurate atmospheric readings.
3. Power on and wait for device boot. The secure element provisions its Device DID on first boot, approximately 60 seconds. The status LED sequence confirms successful provisioning.
4. Register via the Mālama dApp. Connect your Base or Cardano wallet. Enter your node’s Device DID. This binds your hardware identity to your NFT-HEX geographic assignment and triggers the boot tranche unlock (18,750 MLMA, 15%).
5. Confirm network connectivity. The dApp dashboard shows live status: online or offline, last heartbeat timestamp, validation queue. First SaveCard production should appear within 15 to 30 minutes of successful registration.
6. Await Genesis audit clearance. Validation distributions begin after the Genesis Hex Sale audit confirms your node is operational and compliant. Audit takes place in early 2027.
7. Begin the 90-day PONO qualifying period. From successful boot, you have 90 days of continuous operation to qualify for PONO. See Section D below.

Field notes

• Use extension cables if the enclosure must sit in partial shade. Prioritize panel exposure over enclosure placement convenience.
• Verify gasket seals before the first storm season. NEMA-rated housing protects electronics but does not protect sensor calibration if moisture reaches the probe assembly.
• Ethernet preferred. Wi-Fi bridge acceptable if packet loss stays consistently below the validation window threshold.
• Nodes offline for 30 consecutive days during the qualifying period restart the 90-day clock. Nodes offline for 90+ consecutive days post-PONO trigger revocation review.

Bill of materials

Multi-vendor silicon strategy

The protocol is silicon-agnostic. SaveCards are valid if signed by any whitelisted hardware root. The whitelist is governed by the DAO. Qualified alternatives:

Multi-vendor qualification means a single-vendor supply disruption does not halt operator onboarding. Foundation maintains 12-month silicon inventory bond for production continuity.

Technical minimums

The Device DID

Your node’s identity is its Device DID, derived from the secure element provisioned at manufacture. The private key is non-exportable. It exists only in that specific chip. Every SaveCard your node produces is signed by this key.

The Device DID is displayed on the node screen during first boot and printed on your included device certificate card. You need it for dApp registration.

What your node produces

The data your node validates flows through this pipeline:

1. Sensor produces signed reading. An enterprise sensor (ERW site, biochar kiln, AI data center rack) produces a hardware-signed reading. ECDSA-signed at the source before transmission.
2. Data broadcasts to the Hex Node network. Verified data is broadcast to the validator network. Your node receives data assigned to your hex zone or allocated via fallback routing.
3. Your node performs decentralized audit. Your node participates in Proof-of-Truth consensus: validating the cryptographic signature, cross-checking against neighboring validators, and contributing to the consensus outcome for the data packet.
4. Validated data becomes a SaveCard. Once consensus is reached, data is anchored to Cardano via CIP-25 / CIP-68 as a SaveCard. For carbon: feeds LCO₂ pre-finance and VCO₂ credit conversion. For AI compute: produces a hardware-verified Scope 2 disclosure record.

Genesis Hex Sale audit

MLMA validation distributions do not begin automatically at a calendar date. They begin after the audit confirms your node is operational, compliant, and properly registered. The audit takes place in early 2027.

• Nodes that pass receive full Year 1 Genesis multiplier benefits (1.5×) from the clearance date.
• Nodes that do not yet pass are notified with specific remediation steps.
• The boot tranche (15%) is not affected by audit status. Only validation distributions are withheld until compliance is confirmed.

Data retention

Operators are not responsible for raw sensor data retention. That obligation sits with sensor operators and Mālama Labs (10-year S3-compatible off-chain retention with immutability lock). Your node’s validation records are anchored on-chain permanently via Cardano.

Retain locally:

• Your reservation agreement.
• Your Device DID certificate card.
• Your deployment registration confirmation.
• KYB documentation (required for annual renewal).

Fraudulent attestations and slashing

PONO is a non-transferable on-chain credential issued automatically by the Mālama protocol to operators meeting specific KYB, uptime, and operational criteria. PONO is required for governance and is the qualification condition for the 90-day MLMA tranche (15%, 18,750 MLMA).

KYB requirements

• Legal entity verification (corporation, LLC, partnership, or natural person operating as sole proprietor).
• Jurisdiction of organization disclosed.
• Ultimate Beneficial Ownership (UBO) above 25% threshold disclosed.
• Sanctions screening against OFAC SDN, EU consolidated, UN consolidated, and UK HMT lists (zero positive matches required).
• Operational address verified.
• Politically Exposed Person (PEP) screening (positive matches require enhanced due diligence approval).
• For natural persons operating as sole proprietors: government-issued ID plus proof of address (utility bill or bank statement < 90 days old).
• KYB renewal annually with material-change reporting interim.

Operational requirements · throughout 90-day qualifying period

• Active hardware: connected and signing readings for 99.0% of the qualifying period (measured per minute, aggregated monthly).
• Reading volume: minimum 1,000 valid signed readings per 30-day window.
• Anchor participation: hardware contributed to at least 95% of monthly Merkle anchors.
• Geographic coherence: 100% of signed readings within declared hex zone boundary (no GPS drift).
• Hardware tamper status: no detected tampering events (secure-element tamper detection signals).

Qualifying period mechanics

• 90 consecutive days of operation post-deployment registration on mainnet.
• Operator must meet all KYB, uptime, reading volume, anchor participation, and geographic coherence requirements continuously.
• During the qualifying period, the operator earns the boot tranche but cannot vote in governance (probationary status).
• 30 consecutive days of non-compliance during the qualifying period restart the 90-day clock.

Post-issuance maintenance

10% UBO governance cap

Getting help

Primary support runs through Discord and the hardware ticket queue. Phone support is available for scheduled calls on critical deployment issues.

Frequently asked questions

Where do I get firmware or pairing help?

Use the Launch Discord #hardware-support channel and the hardware ticket queue. Include your Device DID (from the device certificate card or the dApp) and your hex zone ID from your reservation confirmation.

Can I move my node to a different hex?

Your geographic license (NFT-HEX) is tied to a specific H3 hex cell. Relocation is governed by the NFT-HEX transfer and resale rules in your reservation agreement. Contact support before physically relocating. Unauthorized relocation may trigger PONO suspension and milestone forfeiture review.

What if validation volume is low at my hex at launch?

Network demand ramps as enterprise sensor deployments come online across carbon MRV, AI compute monitoring, and parametric insurance verticals. Your node also validates data from across the network, not only data produced in your specific hex zone. Your Hex Type and Data Demand Score reflect the commercial, regulatory, and research value of your zone and feed the bounded reward calculation for the validation work your node performs. No distribution guarantees are made.

My node has been offline for several days. What do I do?

Open a hardware ticket in Discord with your Device DID immediately. Brief outages reduce your uptime score but do not automatically forfeit milestones. During the 90-day qualifying period, 30 consecutive offline days restart the clock. Post-PONO, 30 consecutive offline days suspend PONO and reduce distributions to 0.5×. 90+ offline days trigger revocation review.

When does my MLMA allocation begin vesting?

Vesting begins at hardware boot and successful deployment registration. The boot tranche (15%, 18,750 MLMA) unlocks at successful registration. The next tranche (15%, 18,750 MLMA) unlocks at PONO issuance after the 90-day qualifying period. The remaining 70% vests across three operational milestones at 6, 9, and 12 months (20% / 20% / 30%). See Phase 1 Timeline for dates.

What is the Device DID and where do I find it?

The Device DID is the cryptographic identity of your specific node hardware, derived from the secure element provisioned at manufacture. It is displayed on the node screen during first boot and printed on the device certificate card included in your hardware kit. You need it for dApp registration. It is different from your wallet address, cannot be changed or transferred, and is permanently bound to that piece of hardware.

Do I need to own or deploy sensors to receive validation distributions?

No. A Genesis 200 Hex Node is a validation node, not a sensor. You receive MLMA distributions for validating data produced by enterprise sensor deployments (ERW sites, biochar kilns, AI data center racks) operated by carbon project developers, data center operators, and industrial clients. You do not need to deploy any sensors. Sensor deployment by a node operator is optional and would increase local data volume in your zone, potentially increasing your validation weight.

Is operating a Hex Node passive income?

No. Operating a Genesis 200 Hex Node requires labor: physical installation, network setup, ongoing uptime maintenance, and active stewardship of validation work. Only 15% of the MLMA allocation unlocks at boot. The remaining 85% vests against operational milestones (PONO 90-day, 6-month, 9-month, 12-month). Missed milestones forfeit unvested tranches.

What happens to my node if I stop operating it?

Nodes offline for 90+ consecutive days trigger PONO revocation review. Affected operators forfeit unvested milestone tranches to the post-emission governance reserve. Vested MLMA remains in your wallet. Your NFT-HEX may be reclaimed by the protocol via governance vote.

What if I miss an operational milestone but want to come back?

Operators reentering compliance after a missed milestone may petition the DAO for a partial-restoration vote (>50% threshold). Restoration is discretionary and not guaranteed. The simpler path is maintaining continuous PONO eligibility.

Does the Stewardship multiplier apply to me?

The 1.5× Stewardship Multiplier applies to operators on Indigenous lands or in partnership with Native communities, in regions where the Stewardship Pool has been activated via FPIC consultation, cultural advisor sign-off, and governance supermajority. Regional activation is community-led. Operators interested in qualifying for the Stewardship multiplier should contact the Mālama team to discuss partnership pathways.