PROTOCOL SPECIFICATION

VargaMesh Technical Paper

Technical protocol specification for the live VMESH mainnet — inspectable, versioned and without statements about future value or trading availability.

Document type: Technical protocol specification. This document is not presented as a crypto-asset white paper, prospectus, investment recommendation or solicitation to buy or sell VMESH. It describes the publicly observable technical implementation and, in particular, does not claim a binding classification as “issuerless” or as outside the scope of MiCA.
Revision 1.228 Sep 2026Mainnet liveGit: ati1993de/vargamesh-core
1 · STATUS

Document status and scope

This revision describes the VargaMesh mainnet with VargaMesh Core v0.2.0 and the portal/pool functions as of 28 September 2026. Consensus rules are determined by the node software actually performing validation; websites, dashboards and pool policy can change independently.

If this document conflicts with validating node software, the consensus implementation governs block or transaction validity. For pool payouts, the confirmed coinbase transaction of the relevant block is authoritative.

2 · NETWORK IDENTITY

VMESH mainnet

Project
VargaMesh
Ticker
VMESH
Chain ID
22093 / 0x564D
P2P port
29666
RPC port
29667 · private
Bech32 HRP
vm
Genesis hash
00000000b0c55c00c13e2ee67b54fe33c327c8806f8da5050cfa47095d182d9a
PUBLIC INTERFACES

Inspectable rather than trusted

Explorer and Public API expose selected chain data. Core RPC remains private. A full node validates independently according to its own local consensus rules.

Live network →
3 · CONSENSUS

Proof of work and block cadence

VargaMesh uses double SHA-256 (SHA-256d) proof of work. AuxPoW is active from block 1. Difficulty follows an ASERT-based adjustment model with a target spacing of 120 seconds. Actual block intervals vary because proof of work is probabilistic.

Network hashrate shown by the portal is an estimate derived from chain data. Pool hashrate is separate Stratum/share telemetry and may differ.
4 · ISSUANCE

Block subsidy

Initial subsidy
25 VMESH
Halving interval
1,051,200 blocks
Coinbase maturity
100 blocks
Premine
None; genesis output is unspendable
IMPORTANT SEPARATION

Consensus ≠ pool policy

The 1% pool fee is not a protocol tax or consensus parameter. It is an operational rule of the public mining infrastructure.

5 · TRANSACTIONS

UTXO model and addresses

VMESH uses a Bitcoin-style UTXO model. Addresses are not server-side accounts; control over spendable outputs is based on private keys. The portal supports Bech32 addresses with the human-readable part vm. Signed transactions are relayed to the P2P network and become publicly replicated when included in blocks.

The WebWallet signs locally. Public address lookups and broadcasts remain visible to the API server as network requests.

6 · AUXPOW

Mining path

SHA-256d miners can participate through Stratum work on the public pool. Parent work can secure a VMESH child block through AuxPoW. A miner supplies a Stratum username that the public pool implementation uses as a VMESH payout destination.

POOL POLICY

99% / 1%

The portal states a 99% miner share and 1% pool/development share for its public pool infrastructure. This is operational policy, not consensus. The actually confirmed coinbase output of a block is authoritative.

Mining is probabilistic; share work or past block finds do not guarantee future revenue.

7 · VARGAPROOF V1

Proof-of-existence via OP_RETURN

VargaProof computes SHA-256 locally and anchors only a 32-byte digest. VPF1 uses four magic bytes 56504631 (“VPF1”) plus 32 bytes of SHA-256 in an OP_RETURN.

6a 24 56504631 <32-byte SHA-256>

The confirming block provides a publicly verifiable latest-existence time for that exact digest. It does not by itself establish authorship, ownership, content truth, priority over unpublished evidence, or a particular legal effect.

8 · SECURITY

Trust model

Full nodes validate locally. Private WebWallet keys are intended to remain in the browser. Core RPC is not public. Public APIs are read layers and not a substitute for independent consensus validation.

RISKS

Early network

A young proof-of-work network may have low hashrate or node diversity and can experience reorganisations, software defects, forks or outages. Users and integrators should independently verify critical information rather than treating dashboard values as guarantees.

9 · REGULATORY BOUNDARY

Technical documentation, not a sales or listing document

VargaMesh (VMESH) is an open-source blockchain project and public network with community participation. Attila Varga, trading as Varga-Tech, operates vargamesh.com and selected public infrastructure and contributes to software development and maintenance. That website/infrastructure role does not mean that Varga-Tech owns the public network or controls independent third-party nodes, miners, wallets or services. This document does not label VMESH “issuerless” and does not assert a binding regulatory classification.

vargamesh.com itself provides no ICO, direct token sale, customer purchase/sale or exchange service. Third-party exchanges or trading platforms may independently list or support VMESH under their own terms and regulatory responsibilities; such activity is not an exchange service operated by this portal. No price, liquidity, continued transferability, exchange availability or returns are promised.

VMESH is technically created under the consensus rules as a block reward. MiCA distinguishes, among other roles, issuers, offerors and persons seeking admission to trading. Title II contains requirements that can apply to public offers or admission to trading of crypto-assets other than asset-referenced tokens or e-money tokens, subject to the Regulation’s scope and exemptions. These provisions are cited here only as general regulatory context; the applicable role and obligations depend on the actual activity and facts.

MiCA recital 22 and the European Commission answer in ESMA Q&A 2552 dated 18 February 2026 address crypto-assets without an identifiable issuer. This website expressly does not infer from that guidance that VMESH has that status. A trading platform must assess that question independently.

Any activity by the website operator that could constitute a public offer, seeking admission to trading, custody, brokerage, exchange or another regulated crypto-asset service must be assessed separately under the law applicable to that activity. The Technical Paper does not replace any crypto-asset white paper that may be legally required for a specific offer or admission-to-trading activity.

General legal context: Regulation (EU) 2023/1114 (MiCA). This page is not individual legal advice. Binding classifications depend on the actual facts and are for competent authorities and courts.