Whitepaper

1. Summary

Parmeton Network is an independent layer-1 blockchain. Its testnet uses a block graph, or DAG, and Proof of Matrix (PoM). Miners produce proofs on GPU and nodes replay them on CPU. PMN is the network’s native asset.

The project is developing a distributed inference service. The user will choose in Ollama either a local model or a model from the Parmeton network. For a network request, a miner will run the model and stream the answer off-chain. The wallet will authorize funding in PMN. Proof of Inference (PoI) aims to verify the computation provided. The service protocol and its settlement are still under development.

The blockchain keeps the transactions, the state and the commitments needed for validation. Prompts and answers travel off-chain. Infrastructure diagnostics stay in the administration tools.

2. Consensus and mining

The deployed testnet (0.2.51) uses the genesis parmeton-testnet-v4. The 0.2.52 RC2 candidate uses the genesis parmeton-testnet-v5: the testnet is reset, with no compatibility with 0.2.51. A block can reference up to 16 parents. GHOSTDAG, with K = 124, orders parallel blocks and the node applies transactions to the UTXO state. A transaction consumes existing outputs and creates new outputs controlled by Ed25519 keys.

Difficulty targets an interval of 100 ms, or 10 blocks/s on average. DAG progress and DAA score progress are measured separately. The finality point follows the selected-parent path with a depth of 432,000 DAA, about 12 hours if the score advances at 10 DAA/s. The actual delay depends on the network.

The active PoM uses the Phi-4-mini-instruct Q8_0 profile. The GPU computes candidates bound to the requested work and to the reference model. Nodes verify the proofs on CPU and apply the rules of the DAG and the ledger. A validation node can run without a GPU. The DAG and the 0.2.52 RC2 architecture pages detail these rules.

3. PMN, emission and pricing

V4 testnet monetary policy

• 21 million PMN in the initial schedule, with a tail emission accounted for separately. One PMN equals one billion atoms.
• 90% to the miner, 10% to the treasury for the reward actually created. Outputs become spendable from the canonical creation DAA plus 10,000.
• Transfers pay network fees. The base rate changes over windows of 661 DAA. Miner authorization transactions are exempt.
• The first spend of a miner reward output is taxed on the whole value of that output, including in a consolidation. The reference rate starts at 15% at creation and decreases to zero at 77,760,000 DAA. Maturity applies before the spend. Treasury reward outputs are exempt.
• The ledger burns the fees and the tax when the transfer is applied. The burn does not credit the emission schedule back.

The Emission page gives the calculation parameters and the supply snapshot. Production rules will be the subject of a decision separate from the testnet profile.

Envisaged inference pricing

In the envisaged model, users pay for services in existing PMN and workers receive PMN. AIC is a unit of measurement and display equivalent to 4 joules. PMN remains the only settlement asset.

A reference price list can convert the flat energy of input and output tokens into a cost, then express that cost in PMN. The relationship between an AI token and the energy allowance, the price sources, the validity of the quote and the rounding to atoms remain to be specified. The quote will have to be shown before authorization and settlement will have to respect the accepted cap.

reference energy (kWh) = billable tokens × joules per token / 3,600,000
reference cost (EUR) = reference energy × electricity price (EUR/kWh)
reference amount (PMN) = reference cost / PMN price (EUR per PMN)

4. Ollama, inference and payment

The client is the Ollama fork installed on the user’s machine. Local mode runs the models on their computer. Parmeton mode sends a request to the network and receives the generated tokens as inference proceeds. The spending key and the recovery phrase stay in the wallet. Ollama uses a Service key with a bounded delegation.

The miner provides the compute capacity. The planned integration lets it pause PoM on the accelerator during an inference, then resume mining. Reusing the same weight buffer for PoM and the inference engine remains to be qualified. The choice of worker depends in particular on the exact model, availability and latency.

The miner must verify the payer’s authority, the recipient, the required finality, the DAA lock and the remaining budget. The poi.fundingInfo read remains to be connected to the active node. Resuming a funding request must reuse the same identifier and, if it has already been signed, the same transaction.

What the proofs must establish

• Funding: the chain establishes the canonical effect of the transfer and its finality status.
• Delivery: the client attests to what it received according to the session rules.
• Execution: the commitments bind the computation to the model and to the parameters chosen. A sampled audit covers the operations examined and its guarantees depend on the audit protocol.

The client can receive tokens without waiting for a block at each step. The quote and the generation limits must cap spending before the start. Service continuity and failover to another worker or model remain to be qualified.

In the experimental protocol, the miner and the relay can read the content transmitted to them. Prompts and answers stay off the public ledger. A confidentiality guarantee with respect to these operators would require additional mechanisms and qualification.

5. Nodes, storage and recovery

The node validates blocks and maintains the DAG and the UTXOs. Paged storage publishes changes in batches. The journal and the checkpoints are used to reuse local state and to resume processing after a stop. The storage checkpoint and the finalized point of the DAG have distinct roles.

0.2.51 keeps the history. Pruned nodes and synchronisation from a distributed snapshot remain targets to be qualified. A network bootstrap snapshot must be anchored to a verifiable reference and contain the consensus data needed to validate what follows. The minimum hardware configuration will depend on measurements on representative histories and workloads.

6. Hardware and models

PoM results are subject to the same CPU validation. Capability announcements are signed by the miners. The signature authenticates the declaration, in which the GPU and the memory remain self-declared.

The active PoM profile and the future inference catalogue have distinct uses. A model is identified by its manifest, its weights and its compute profile. The weights stay off-chain. The selection of inference models will also depend on their licence, tokenizer, context and the memory actually usable.

Multi-GPU and multi-model configurations, ROCm/HIP, Ryzen AI Max, DGX Spark and other accelerators remain areas of work to be qualified. Model distribution between peers and pools also remain to be studied.

7. Transparency and limits

The public site shows an HTTPS snapshot of the seed published every 30 seconds. It presents the state observed by this node, notably the DAG, the DAA, the peers and the emission. Throughput in blocks/s measures the net progress of the counter between two snapshots. PoM attempts/s and inference tokens/s are distinct measurements.

The node’s JSON-RPC is reserved for private access. VPSmon is used for operations and distinguishes PoM replay from admission work. A full historical explorer and metrics covering the whole network require a dedicated indexing layer.

Security priorities include DAG reorganizations, state recovery, authorization replay, double budget commitments and forged proofs. The ledger’s finality guarantees and those of the inference service must be qualified separately.

8. Project status and next steps

White paper · Updated 5 November 2026 · Technical reference for the deployed 0.2.51 testnet and the 0.2.52 RC2 candidate.