VResArc: Progress-Difficulty Emission
with a Protocol-Owned Liquidity Reserve.
§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.
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
| Bucket | Share | Quantity (VRES) | Custody & binding |
|---|---|---|---|
| PoW Emission Pool | ≈74.9998% | ≈23,999,755.86 | programmatic — 20,000 blocks, difficulty-gated, miner-claimable |
| POL Reserve | ≈25.0002% | 8,000,000 | genesis-minted → LP vault · single-purpose |
| Team / Presale / Advisor | 0% | — | structurally absent |
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 ½:
| epoch | block interval | reward/block | epoch supply | difficulty |
|---|---|---|---|---|
| 0 | 0 – 1,199 | 10,000 | 12,000,000 | 2^20 |
| 1 | 1,200 – 2,399 | 5,000 | 6,000,000 | 2^21 |
| 2 | 2,400 – 3,599 | 2,500 | 3,000,000 | 2^22 |
| … | … | … | … | … |
| 16 | 19,200 – 19,999 | 0.1526… | 122.07 | 2^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.
§4The Proof-of-Work Gate
Mining reduces to an offline search over a 84-byte namespace:
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.
| Property | Binding |
|---|---|
| Mint event | single genesis mint · one-time · observable in the deployment tx |
| Destination | immutable vault address (constructor-fixed) |
| Unlock schedule | none — no vesting, no linear-release tranches |
| Disbursement | one intended action: VRES/USDC depth at the post-mint liquidity migration |
| Reallocation | not 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 owner field, no pausable gate, no proxy, no upgrade path, and no secondary mint. 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 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.