TECHNICAL SPECIFICATION

VResArc: Progress-Difficulty Emission
with a Protocol-Owned Liquidity Reserve.

CLASS: Fair-launch utilityNETWORK: Arc (native-USDC L1)

§0Notation

Throughout, b ∈ ℕ₀ denotes the global emission counter (blockCount); all balances are denominated in 18-decimal VRES wei unless stated; native-USDC quantities are likewise 18-decimal.

H(x) = keccak256(x) · ‖ ≡ abi.encodePacked concat
target(b) = (2256 − 1) >> (20 + ⌊b / 1,200⌋)
stage(b) = ⌊b / 1,200⌋   ω(b) = 10,000 × 2−stage(b)  VRES

§1Positioning Statement

VResArc is a single-entry, zero-overhead emission primitive deployed on the Arc network. The contract exposes exactly one state-transition surface — mine(nonce) — whose acceptance predicate is a partial-order test over the digest space of keccak-256. Accepted transitions mint against a pre-committed, monotone, time-invariant reward schedule.

The issuance ledger is partitioned at genesis into two disjoint pools: (i) a miner-accessible emission pool (≈75%) governed by the difficulty schedule below, and (ii) a protocol-owned liquidity reserve (25%) minted in a single genesis event to a dedicated vault destination, reserved exclusively for the post-mint liquidity bootstrap. The structure admits no third bucket — no team allocation, no presale tranche, no advisor grant, no treasury vote.

It is a distribution machine, not a consensus network. This document does not claim otherwise.

§2Genesis & Distribution Profile

BucketShareQuantity (VRES)Custody & binding
PoW Emission Pool≈74.9998%≈23,999,755.86programmatic — 20,000 blocks, difficulty-gated, miner-claimable
POL Reserve≈25.0002%8,000,000genesis-minted → LP vault · single-purpose
Team / Presale / Advisor0%structurally absent
hardCap = Σb<20,000 ω(b) + POL_alloc  =  31,999,755,859,375,000,000,000,000 wei
total ≈ 31,999,755.86 VRES ≈ 32,000,000 (nominal)

At deployment the constructor performs a single irreversible mint to the vault destination (LP_VAULT), emitting Transfer(address(0), LP_VAULT, 8e24). The emission pool thereafter is reachable exclusively through the proof-of-work gate; no minting entry exists outside mine().

§3Emission Schedule

The mining window spans 20,000 blocks. Within each epoch of 1,200 blocks the per-block reward is constant; across epoch boundaries it decays geometrically with ratio ½:

epochblock intervalreward/blockepoch supplydifficulty
00 – 1,19910,00012,000,0002^20
11,200 – 2,3995,0006,000,0002^21
22,400 – 3,5992,5003,000,0002^22
1619,200 – 19,9990.1526…122.072^36

The cap is computed, not asserted: the constructor accumulates per-epoch issuance over the actual block schedule — including the truncated terminal epoch — such that MAX_SUPPLY is, by construction, equal to the supremum the machine can ever emit. No governance patch, no approximation error, no re-base.

Front-loaded issuance. Because decay is geometric with epoch length 1,200, the first epoch alone distributes 50% of total supply at the minimum difficulty — a deliberate design property colloquially termed the supply cliff. By block 10,800 (54% of the window) ≈99.8% of supply has cleared the gate.

§4The Proof-of-Work Gate

Mining reduces to an offline search over a 84-byte namespace:

accept ⇔ H( miner ‖ b ‖ nonce ) < target(b)

The acceptance threshold is recomputed at execution time from the live counter — the EVM re-derives target(blockCount) inside every call frame, so stale or fabricated proofs revert atomically with the block, wasting only gas; the mint ticket itself is never at risk of partial consumption. As blockCount is a monotone global serial counter, the state space is fork-free and double-spend-free by construction; competition collapses to a Poisson race whose sole manipulable surface is a one-block mempool-ordering window.

Time-invariance of the scheduler

The scheduler is a pure function of block progress. It ingests no oracle, no wall-clock timestamp, and no network-hashrate telemetry — rendering clock games, difficulty-adjustment griefing and time-warp attacks structurally inapplicable. Aggregate hashpower entering or leaving the system cannot relax the schedule; it can only accelerate progress toward the cliff and the terminal 2^36 regime.

§5Protocol-Owned Liquidity Reserve (25%)

8,000,000 VRES are minted once, at genesis, to LP_VAULT. The reserve exists to answer a structural defect of hash-launches: a fully mined token with no trading depth is a token without a market. The POL tranche is the counterweight — it remains vaulted across the entire mining window and migrates into pool depth only after the terminal block.

PropertyBinding
Mint eventsingle genesis mint · one-time · observable in the deployment tx
Destinationimmutable vault address (constructor-fixed)
Unlock schedulenone — no vesting, no linear-release tranches
Disbursementone intended action: VRES/USDC depth at the post-mint liquidity migration
Reallocationnot provisioned

The token layer does not impersonate a treasury. Contract-level custody is deliberately minimal: a single immutable destination and a genesis-only mint. Downstream disbursement is a one-time, fully transparent on-chain event by design — the commitment is structural, and the ledger stays silent on intent beyond that. A nominal fraction of the terminal supply remains provisioned against downstream protocol utilities — beyond markets, and specified only after the final block.

§6Immutability & Security Posture

All economic constants — TOTAL_BLOCKS, INITIAL_REWARD, HALVING_BLOCKS, DIFFICULTY_STEP, POL_ALLOC, BASE_TARGET, MINT_FEE, FEE_RECEIVER, LP_VAULT — are constant/immutable and fixed at construction. The contract carries no pausable gate, no proxy, no upgrade path, and no secondary mint. Its single privileged entry point is withdraw(): reserved to OWNER — bound at construction to the fee receiver and not transferable — and confined to sweeping stray native USDC to that same fee receiver. The destination is hard-wired, so the call cannot divert value to any third party, and it cannot move a single VRES: the contract never custodies tokens, every balance sits directly under its holder. ERC-20 semantics (approve/transferFrom) are implemented natively; mint events surface as canonical Transfer(address(0), ·, ·) records, keeping the ledger composable with standard indexers and DeFi rails.

§7Auditability

The deployed contract is verified and readable on the Arc block explorer0x911c…f5fd. Source file, compiler version, optimizer settings and constructor arguments are all matched against the live bytecode, so every claim in this document can be read in code rather than taken on faith. The contract is a single, dependency-free source file; the complete test matrix (emission math, difficulty–reward linkage via state mutation, ERC-20 semantics, genesis POL mint, fee/low-nonce reverts) passes against Foundry. Exact constants, selectors and schedule tables are enumerated above; any discrepancy between this specification and the deployed bytecode is, by construction, a spec bug, not a contract bug.