Phase 1 Complete · Phase 2 Incoming · Mainnet Target Q4 2027

Verifiable randomness.
One API call.

PTX will deliver cryptographically verifiable random outputs via a simple API, backed by a decentralised Gamemaster quorum, with every result committed on-chain. No smart contracts. No Solidity. If your game can make an HTTP call, it will use PTX.

Where we are: Phase 1 complete — ahead of schedule. Real hemisd binaries, 10-node regtest cluster, 109/120 tests passing. Phase 2 (threshold BLS, testnet) is next. The API shown is finalised by design — not yet callable in production. Mainnet target: Q4 2027.
See the Roadmap Phase 0 Results →
ptx_roll · single-player · dice roll
// Roll 2d6 — provably fair, on-chain proof
const result = await ptx_roll({
  count: 2,   // two dice
  low:   1,   // min face
  high6,   // max face
  unique: false
});
 
// ✓ 1–3 second response, quorum-signed
result.results     // → [4, 5]
result.tx_id      // → "a3f8c1..." (verify on-chain)
result.quorum_sig  // → BLS threshold signature
410 active Gamemaster nodes
Threshold BLS · phase 2+
NIST SP 800-22 tested
All results on-chain forever
No smart contracts required

// how it works

From API call to
on-chain proof in seconds.

PTX separates fast randomness generation from permanent on-chain commitment — so your game gets results instantly, and players get proof forever.

01
📡

Call the API

Your game server calls ptx_roll() with your parameters — count, range, unique. One HTTP call. No blockchain knowledge needed.

02
🔐

Quorum Signs

A decentralised quorum of Gamemaster nodes reaches threshold BLS consensus. Nobody — not Hemis, not the nodes, not your studio — can predict or influence the result.

1–3 seconds
03

Seed Delivered

Your game receives a verifiable random output with a quorum signature. Use the integers directly or pass the round seed to your procedural generation engine.

04
⛓️

Committed On-Chain

The seed, signature, and quorum members are written to the Hemis blockchain. Any player, regulator, or third party can verify every result — now and forever.

~60 seconds · next block
410
Active Gamemaster nodes
1–3s
Time to result
2²⁵⁶
Seed space
15/15
NIST SP 800-22 tests passed

// api reference

ptx_roll() — the simplest
surface for single-player.

One call handles everything. For multiplayer sessions, ptx_create_session() gives you the full lifecycle API.

PARAMETERS
count int
Number of random values to draw
low int
Minimum value, inclusive
high int
Maximum value, inclusive
unique bool
Draw without replacement (e.g. card shuffles)
exclude int[] | tx_id[]
Values to exclude — accepts integers or previous round tx_ids
RESPONSE · ptx_roll(count:5, low:1, high:52, unique:true) 200 OK
{
  "results":     [17, 4, 51, 33, 9],
  "session_id": "a3f8c1d2...",
  "round_seed": "b7e3a9f1...",
  "quorum_sig": "c2d8b4e7...",
  "block_height": 284419,
  "tx_id":      "f1a9c3b8..."
}

Pass tx_id to any block explorer to independently verify the result. The quorum signature cryptographically binds the output — it cannot be altered after the fact.


// use cases

Any outcome that needs
to be trusted.

PTX is a randomness primitive — not a game engine. What you build with it is entirely up to you.

🎲

Dice & Card Games

Roll dice, draw cards, shuffle decks. Every result is on-chain and player-verifiable from session creation.

ptx_roll · unique:true
🗺️

Procedural World Gen

Seed your map generator or dungeon layout from a verifiable PTX output — players can confirm terrain was generated fairly.

ptx_roll · high:2³²
🎁

Loot Drops & Gacha

Prove your drop rates on-chain. Real rates emerge from actual session data, not developer-published tables.

ptx_roll · count:1
🏆

Tournament Draws

Bracket seedings, player matchups, team selection — all provably fair with a shared on-chain seed before the draw.

ptx_create_session · n>1
🎨

Generative NFT Minting

Trait assignment committed to chain before reveal. Collectors verify their mint was fair from the permanent record.

ptx_roll · exclude:prev_tx
🎯

Raffles & Jackpots

Winners selected from a verifiable seed. The result is on-chain before you announce it — no trust required.

ptx_roll · count:1
🧬

Character Stats & RPG

Roll character attributes at creation with a session seed players can inspect. Stat manipulation is cryptographically impossible.

ptx_roll · count:6
🔬

Scientific Sampling

Reproducible, auditable random samples with a permanent proof of the seed used. Methodology becomes independently verifiable.

ptx_roll · custom range
⚔️

Multiplayer PvP Events

Both players contribute to a combined seed — neither side can influence the outcome. Disputes resolved by block explorer link.

ptx_create_session · n=2

// the guarantee

Not "trust us".
Verify us.

The difference between PTX and every other random number service is what happens after the result is delivered.

✗ Without PTX

"Our drop rates are fair."

A server-side RNG your players can't inspect. Rate manipulation is undetectable. Regulators demand internal audit logs. Data miners find inconsistencies and you face a PR crisis.

✓ With PTX

"Our drop rates are on-chain. Verify them."

Every result is cryptographically signed by a decentralised quorum. Manipulation is impossible — the seed determines the outcome. Regulators get a block explorer link, not a self-certification. Data miners verify your rates are correct.

✗ Without PTX

"Trust the platform's dice roller."

The platform controls the RNG. Players have no way to confirm results. Tournament outcomes can be disputed forever. No recourse, no audit trail.

✓ With PTX

"The session seed is on-chain. Derive the result yourself."

Players, journalists, and regulators can independently reproduce every outcome from the on-chain seed. Your competitive moat isn't a marketing claim — it's a block explorer link that no competitor can replicate.


// roadmap · may 2026

Where we are.
Where we're going.

Dates beyond Phase 1 are estimates. This page reflects actual completion dates as each phase finishes — not targets we hope are true.

Design Complete Phase 0 Complete Phase 1 Complete
Phase 2 Incoming
Phases 3–5 Upcoming
Design, Phase 0, and Phase 1 were all delivered ahead of the Q3 2026 target — Phase 1 completed May 2026. Phase 2 preparation is underway. All dates for Phases 2–5 are estimates.
Design
May 2026
Phase 0
May 2026
Phase 1
May 2026
Phase 2
Q4 2026–Q1 2027
Mainnet
2027
Q4 2027 target
COMPLETE
Design
May 2026

Architecture & Design Finalisation

Full PTX architecture locked. 28 Key Design Decisions recorded and closed. 16 Open Design Choices tracked with explicit resolution criteria. API contract finalised. Full design document v3.5 issued. Phase 1 implementation plan issued.

✓ Architecture locked✓ 28 KDDs closed✓ API contract finalised✓ Design doc v3.5 issued
COMPLETE
Phase 0
May 2026

Protocol Simulation & Statistical Validation

Python simulator with full hash commit-reveal state machine. Adversarial scheduler tests. Output mapping uniformity confirmed. Full NIST SP 800-22 battery passed on the reference C implementation across 640 million bits.

✓ 9/9 adversarial tests✓ 11/11 χ² uniformity✓ 15/15 NIST SP 800-22 (ref C)✓ 640M bits · 100 runs
Scope: A simulation — no real nodes, no real network, no threshold BLS. Full details in the Phase 0 section below.
COMPLETE
Phase 1
May 2026

Regtest Multi-Node — Real Node Binaries

10 hemisd nodes on a single virtualised Proxmox host (CT101–CT110). Modified hemisd binaries with ptx_roll and ptx_getroundstatus RPCs. First time PTX ran on actual node software. Completed ahead of Q3 2026 target.

Results: 109/120 tests passing. 7 bugs fixed (including 2 HIGH severity blockers). Remaining 11 are Phase 2 architectural deferrals — none are regressions.

✓ Real hemisd binaries · 10 nodes✓ ptx_roll / ptx_getroundstatus RPCs✓ Block height anchoring✓ PoSe penalty mechanics✓ Auto-commit · no accept_window (KDD-027)✓ exclude pipeline — dynamic allocation (BUG-003/004 fixed)✓ Input validation — type, param count, hex salt (BUG-006/007/008)✓ ptx_test_suite_v4.py — 109/120 passing✓ Tagged phase1-close @ 4c0895f · github.com/vileda-hemis/Hemis-PTX-MVP1Hash commit-reveal (BLS in Phase 2)P2P round broadcast (BUG-005 · Phase 2)GM role separation (BUG-009/010 · Phase 2)
NEXT
Phase 2
Q4 2026–Q1 2027

Quorum Validation — Threshold BLS Signing

11-node Docker testnet. Hash commit-reveal replaced by threshold BLS12-381 via supranational/blst — the cryptographic core of PTX. For any given seed and quorum key, exactly one valid output exists. Last-revealer advantage eliminated entirely. Toxiproxy fault injection. Prometheus/Grafana telemetry.

Threshold BLS · BLS12-381Trusted-dealer DKG · n=11Toxiproxy fault injectionLottery distribution · 10,000 roundsGamemaster node software released
UPCOMING
Phase 3
Q2 2027

Public Testnet — External Operators & SDK

21+ geographically distributed nodes run by independent operators. Full Pedersen DKG. Public block explorer. SDK and API docs released. First real-world measurement of the 1–3 second latency design target under actual network conditions. Developer access opens here.

Full Pedersen DKG · n=21SDK & API docs releasedPublic block explorerReal WAN latency measuredCommunity audit
UPCOMING
Phase 4
Q3 2027

Hybrid Public Testnet — Pre-Mainnet Hardening

External operators become the majority of Gamemaster nodes. Session expiry and fee model finalised with real developer data. The 1–3 second latency design target confirmed or revised based on actual production measurement.

External operator majorityFee model finalised (ODC-008)1–3s latency confirmed in productionHSM / remote-signer path validated
UPCOMING
Phase 5
Q4 2027

PTX Mainnet — API Open to All Developers

Full production launch. ptx_roll() callable by any game developer. n=21+ quorum, t≈67% threshold. Full codebase open-sourced at launch. This is when PTX becomes a real production service.

ptx_roll() open to all developersn=21+ quorum · t≈67%Full open source at launchSDK & docs at launchGovernance voting live

// phase 0 results · may 2026

What we've proven.
What we haven't yet.

Three independent test batteries. All exit criteria met. Being clear about the scope is as important as the results.

COMPLETE · May 2026 Python Simulator NIST SP 800-22 Reference C
Scope boundary: Phase 0 is a Python simulation — no real nodes, no real network, no threshold BLS. SHA256 commit-reveal was used as a stand-in. It proves protocol logic and statistical properties are sound. The full system proof happens in Phases 1–4.
Overall Verdict
PASS
All exit criteria met
Protocol Tests
9/9
Adversarial scenarios
Uniformity Tests
11/11
χ² all game types
NIST Python
12/15
3 harness bugs found
NIST Ref C
15/15
Ground-truth result
Bits Tested
640M
100 runs × 6.4M bits
Battery 1 — Adversarial Protocol Tests  9 / 9

1,000 rounds per scenario. Does the protocol produce a valid result and correctly penalise misbehaving nodes?

ScenarioDescriptionResult
All honestAll nodes commit and reveal correctlyPASS
Single withholderOne node commits but withholds reveal — PoSe penalty applied, round resolves from remaining nodesPASS
Multiple withholdersMultiple nodes withhold — protocol degrades gracefully within thresholdPASS
Invalid commitmentNode submits an invalid commitment hash — rejected by protocolPASS
Late revealNode reveals after window closes — treated as withhold, PoSe appliedPASS
AbstainerQuorum node does not participate at all — protocol continues without itPASS
Reveal mismatchNode reveal does not match commitment — rejected, PoSe appliedPASS
Threshold boundaryExactly t nodes honest, n−t withhold — resolves at minimum valid thresholdPASS
Below thresholdFewer than t honest nodes — round correctly declared failed, no result producedPASS
PoSe penalty mechanism worked correctly in all scenarios. Misbehaving nodes lost lottery eligibility and accumulated PoSe score. No capital forfeiture — by design (KDD-023).
Battery 2 — Output Uniformity  11 / 11

χ² tests across all game value mapping types. Rejection sampling and Fisher-Yates both confirmed bias-free.

Game TypeMapping MethodResult
Dice (d6)Rejection sampling · low=1, high=6PASS
Dice (d20)Rejection sampling · low=1, high=20PASS
52-card drawFisher-Yates shuffle · unique=truePASS
Card draw (no replacement)Fisher-Yates · unique=true, count=5 · zero duplicates verifiedPASS
Player selection (pool of 10)Rejection sampling · count=1, high=10PASS
Unique player selection (3 of 10)Fisher-Yates · unique=true, count=3PASS
Custom range (non-power-of-2)Rejection sampling · bias testPASS
Large range (1–1000)Rejection sampling · χ² uniformityPASS
Single value drawcount=1 · χ² uniformityPASS
Multi-value draw (count=10)10 independent values · independence + uniformityPASS
Beacon expansionSHA256 chain expansion · no truncation bias (KDD-024 fix verified)PASS
Battery 3 — NIST SP 800-22  15 / 15 (reference C implementation)

The Python harness reported 3 failures. All were traced to bugs in the Python test code — not the beacon. The same bitstreams passed all 15 tests on the official NIST reference C binary.

Python vs reference C: The 3 Python failures are test harness bugs — a cycle detection issue and a KS test edge case. The beacon bitstreams are identical in both environments. The NIST reference C implementation is the authoritative result.
TestPython RatePythonRoot Cause (if fail)Ref C
Frequency (Monobit)97.0%PASSREF PASS
Frequency within Block99.0%PASSREF PASS
Runs99.0%PASSREF PASS
Longest Run of Ones99.0%PASSREF PASS
Binary Matrix Rank100.0%PASSREF PASS
Discrete Fourier Transform97.0%PASSREF PASS
Non-overlapping Template99.0%FAIL (KS)KS p-value edge case in Python chi² aggregation — not a beacon defectREF PASS
Overlapping Template100.0%PASSREF PASS
Universal Statistical100.0%PASSREF PASS
Linear Complexity97.0%PASSREF PASS
Serial98.0%PASSREF PASS
Approximate Entropy99.0%PASSREF PASS
Cumulative Sums97.0%PASSREF PASS
Random Excursions92.9%FAILPython cycle detection bug — artificial zero appended, biasing chi-squared. Beacon not at fault. Ref C: 128/128.REF PASS 128/128
Random Excursions Variant95.2%FAIL (KS)Same cycle detection bug as above. Ref C: 281/288.REF PASS 281/288
Conclusion: The beacon is statistically indistinguishable from true randomness on the NIST reference C implementation. All 15 tests pass at ≥95%. The Python failures are test harness bugs — the beacon bitstreams are identical in both test environments.

// phase 1 · complete · may 2026

Regtest Multi-Node.
Real Software.

PTX running on actual hemisd node binaries for the first time. 10 regtest nodes. Phase 1 criteria met and closed ahead of the Q3 2026 target.

COMPLETE · May 2026 10 Regtest Nodes · CT101–CT110 Real hemisd Binaries Hash Commit-Reveal
Phase 0 proved the math. Phase 1 proved the code. The same protocol logic validated in simulation runs correctly on actual hemisd node binaries with real block production, real mempool commits, and a full adversarial test suite.
// phase 1 results — ptx_test_suite_v4.py · 120 tests

What the tests showed.

~1,400 real ptx_roll() calls on live nodes. ~7,000 node-level cryptographic operations. Two full runs: standard suite + adversarial suite.

Tests Passing
109
of 120 total
Hard Blockers
2/2
BUG-003 & BUG-004 fixed
Bugs Fixed
7
across phase
API Calls Made
~1,400
on live nodes
BUG-004 verify
850
iterations · zero violations
Verdict
CRITERIA MET
phase 1 closed
// exit criteria — all met
CriterionTestsResult
End-to-end PTX flow on real binariesFull round from API call through commit-reveal to on-chain PTXSESS transactionT01–T10 · 10/10
BUG-003 fixed — exclude ≥96 no longer crashesexclude sizes 97, 200, 500, 1000 all succeed — no fixed buffer remainsT101–T104 · 4/4
BUG-004 fixed — zero exclusion violations850 iterations across exclude sizes 10–90 — zero violations. P(<10⁻¹⁰) if bug present.T114–T116 · 3/3
Chi-square uniformityCoin flip, d6, d20, d100 — all pass at p>0.05T39–T42 · 4/4
Game scenariosDice, cards, raffle, multi-round chainingT29–T38 · 10/10
Multi-round game correctnessCard game, depleted deck (47 excluded), 90% excluded densityT117–T120 · 4/4
Concurrent loadUp to 30 simultaneous ptx_roll() calls — no crashes, no corruptionT81–T85 · 5/5
Nonce chaining KDD-015Fixed salt across sequential calls produces distinct seeds per roundT96–T98 · 3/3
Adversarial mechanicsWithhold, abstain, PoSe accumulation, recovery — all confirmed on live nodesT71–T80 · 10/10
Block height anchoring KDD-003block_height present in response and consistent with chain stateT92 · PASS
// bugs fixed in phase 1
BugSeverityDescriptionStatus
BUG-001FIXEDPTX parser separator @ vs : mismatchEarly Phase 1 · no regression
BUG-002FIXED-ptxmynodeid config flag name mismatchEarly Phase 1 · no regression
BUG-003HIGH · FIXEDexclude ≥96 items → HTTP 500. Exclude pipeline rebuilt with dynamic allocation throughout.T101–T104 · PASS
BUG-004HIGH · FIXEDExclusion fallback returned excluded values ~30% of the time. Replaced with deterministic exhaustive search.T114–T116 · 850 iterations · zero violations
BUG-006LOW · FIXEDexclude accepted non-array types silently. Added typed validation at RPC entry.T59/T60/T62/T63 · PASS
BUG-007LOW · FIXEDExtra RPC params silently accepted. Added upper bound param count check.T66 · PASS
BUG-008LOW · FIXEDNon-hex caller_salt accepted without error. Added hex format validation at RPC entry.T68 · PASS
// what phase 1 did not test

Threshold BLS signatures

Phase 1 uses hash commit-reveal. The last-revealer advantage is economically deterred by PoSe penalties but not cryptographically eliminated. Threshold BLS12-381 — which eliminates it entirely — is Phase 2.

Real P2P network conditions

All 10 nodes are on a single Proxmox host. No real latency, no packet loss, no network partitions. Fault injection is simulated via RPC flag, not real node misbehaviour.

PoSe persistence across restarts

PoSe scores are held in memory only in Phase 1. A node restart clears all penalties. Disk persistence and score decay are Phase 2 items (KDD-028).

1–3 second latency

Cannot be meaningfully measured on single-host regtest. Signing latency is sub-millisecond on localhost. Real-world latency is first measured in Phase 3 under actual WAN conditions.

// deferred to phase 2
ItemReason for deferral
BUG-005 — P2P round status broadcastRound status is only visible on the initiating node. Requires a real multi-party testnet to test meaningfully. Phase 1 regtest is single-host.
BUG-009/010 — GM role separation + dedicated caller nodeAll Phase 1 testing was conducted from GM nodes — acceptable for regtest. Proper enforcement and testing requires a non-GM caller node which is Phase 2 infrastructure.
KDD-028 — PoSe decay and disk persistenceIn-memory only in Phase 1. Restarts are controlled and deliberate in regtest. Decay logic and persistence require Phase 2's longer-running live environment.
ODC-017 — UTXO lock contentionPTXSESS builder and staking thread contend on the GM wallet. Resolved architecturally by the dedicated caller node (BUG-010) in Phase 2.

// phase 2 · next

Threshold BLS.
Real Testnet.

Hash commit-reveal replaced by threshold BLS12-381. 11-node Docker testnet. Real P2P networking and fault injection for the first time.

NEXT · Q4 2026–Q1 2027
11-Node Docker Testnet Threshold BLS12-381 Toxiproxy Fault Injection
Phase 2 has no firm completion date. Q4 2026–Q1 2027 is the current estimate. Threshold BLS implementation is the primary unknown. These are the planned deliverables based on the current design — not a commitment.
// what phase 2 will test

Threshold BLS12-381 — unbiasability

Hash commit-reveal replaced by threshold BLS via supranational/blst (formally verified). For any given round seed and quorum public key, exactly one valid output exists. The last-revealer advantage is eliminated entirely — no individual node can see what the output will be before signing.

Trusted-dealer DKG · n=11

Distributed key generation with 11 nodes establishes the quorum signing key. Phase 2 uses a trusted-dealer setup — full Pedersen DKG comes in Phase 3.

Adversarial conditions under real networking

Toxiproxy fault injection introduces real latency, packet loss, and connection drops between nodes. Phase 1 fault injection was RPC-flag simulation. Phase 2 is real network misbehaviour.

P2P round status broadcast (BUG-005)

Round status, committed lists, and withheld lists broadcast to peer nodes so any node in the cluster can answer status queries — not just the initiating node.

PoSe decay and disk persistence (KDD-028)

PoSe scores persist across restarts. Score decay added: -1 per honest round participated. Misbehaving nodes can recover; attacking nodes accumulate penalties that survive node restarts.

Dedicated caller node (BUG-009/010)

GM nodes are prohibited from calling ptx_roll(). A dedicated non-GM caller node is provisioned. This also resolves the UTXO lock contention (ODC-017) between PTX fee payment and the staking wallet.

Lottery distribution over 10,000 rounds

Quorum lottery selection validated over 10,000 rounds. Node selection distribution confirmed to match the ticket-weighted probability model.


// whitepaper · v3.0 · may 2026

Hemis PTX
Whitepaper

What Hemis is, how PTX works, the HMS token, the network, and how to get involved. No blockchain expertise required.

// what ptx is

A randomness service.
Not a games platform.

This distinction matters. PTX does one thing: it will produce verifiable random numbers. What you build with them is your business.

What PTX will do

Produce verifiable, tamper-proof random integers. Return them with a cryptographic proof. Post a permanent on-chain record. That is the entirety of what PTX will do.

What PTX will not do

PTX will have no concept of game outcomes, winners, losers, wagers, prizes, or payments. A result of [7, 23, 4, 51, 12] is five integers. What those mean is entirely the caller's concern. Application logic, payments, and regulatory compliance are the developer's responsibility.

// the trust problem

Why existing RNG
isn't good enough.

The difference between PTX and a server-side RNG is what happens after the result is delivered.

✗ Without PTX

"Trust us, the drops are random."

A server-side RNG players can't inspect. Rate manipulation is undetectable. Regulators demand internal audit logs. Data miners find inconsistencies and you have a PR crisis with no recourse.

✓ With PTX

"Our drop rates will be on-chain. Verify them."

Every result will be cryptographically signed by a decentralised quorum. Manipulation is mathematically impossible after the seed is set. Regulators will get a block explorer link. Players become your quality assurance.

✗ Without PTX

"Trust the platform's dice roller."

The platform controls the RNG. Players can't confirm results. Tournament outcomes disputed forever. No audit trail, no recourse.

✓ With PTX

"The session seed will be on-chain. Derive the result yourself."

Players, journalists, and regulators will be able to independently reproduce every outcome from the on-chain seed. Your competitive moat will be a block explorer link — not a marketing claim.

// architecture

Three layers.
One verifiable result.

L1
⛓️

Base Chain — Audit Layer

UTXO blockchain, Bitcoin-derived, Proof of Stake, 60-second blocks. Every PTX result will be committed here permanently. The public record anyone can inspect.

Live since Feb 2024
L2
🔐

Gamemaster Network — Randomness Layer

Peer-to-peer network of collateralised Gamemaster nodes. Threshold BLS signing. No individual node will be able to determine or influence the output alone.

410 nodes live
API
📡

PTX API — Developer Layer

ptx_roll(count, low, high, unique, exclude). One call. Result in seconds. On-chain proof automatic. No smart contracts required.

Opens Phase 3 · Q2 2027
// cryptographic path

How the randomness will be generated — and why it cannot be manipulated.

Phase 1
Hash Commit-Reveal

MVP Cryptographic Path (Current)

Each Gamemaster generates a secret, commits to it with a hash, then reveals it. The beacon is SHA256 of all revealed secrets. Nodes that withhold receives PoSe penalties and lose lottery eligibility.

Limitation: a last-revealer knows other nodes' contributions and could theoretically withhold. The PoSe penalty makes this economically unattractive but doesn't eliminate the mathematical possibility. Threshold BLS (Phase 2) eliminates it entirely.

Phase 2+
Threshold BLS

Production Cryptographic Path

Threshold BLS12-381 via supranational/blst (formally verified). For any given round seed and quorum public key, exactly one valid output exists. Last-revealer advantage is eliminated entirely — no individual node can see what the final output will be before signing.

// hms token

HMS — the network utility token.

TOTAL SUPPLY
~30M HMS

Linear emission over 10 years. No halving. ~7.99M in circulation as of May 2026.

ACTIVE GAMEMASTERS
410

Active Gamemaster nodes as of May 2026. Running on the existing chain — PTX will extend their role.

LAUNCH
Feb 2024

Public airdrop to 951 recipients across 56 countries. No token sale. No VC allocation.

CategoryTokens% SupplyNotes
Investors200,0000.67%Distributed at launch
Founders600,0002.00%Distributed at launch
Airdrop800,0002.67%Community · 951 recipients · 56 countries
Dev Fund (Year 1)292,0000.97%12 monthly instalments · transparent treasury
To be minted (10yr)~29,200,00093.69%Linear emission to stakers & Gamemasters · no halving
Fee model not yet locked. PTX round fees are payments for randomness generation — not wagers or entry fees. The fee amount is an Open Design Choice (ODC-008) that will be finalised using real developer feedback in Phase 3.

// how hemis has evolved

Original 2023 vision
vs current PTX design.

What was proposed in July 2023, what PTX delivers in May 2026, and where the two diverge — recorded factually, not as spin.

Original Whitepaper: July 2023 Current Design: May 2026
Purpose of this section: To document continuity and change honestly. The evolution reflects a change in team composition and a deeper design process — not a failure of the original vision.
// the original vision · july 2023

Hemis is a new layer 1 blockchain platform that will provide platform agnostic tools for the creation of simple and fun games with elements of chance without the need to write complicated and expensive contracts.

— Daniel Ames, Project Co-Founder, Original Hemis Whitepaper, July 2023

2023 framing: a games platform

The original whitepaper described a toolkit for creating and playing games of chance. It proposed NFT game pieces with attributes, game creator royalties, play-to-earn mechanics, and a game publishing platform. The audience was game creators and community investors.

What Daniel got right

The core architectural proposition — a Layer 1 UTXO chain with collateralised second-layer nodes using deterministic quorum subsets to produce verifiable randomness, delivered via a simple API with no smart contracts — survived intact from 2023 to 2026. Daniel wrote the load-bearing structure. Everything else was layers on top of it.

// why it changed

Three reasons the design diverged.

Reason 1

Change in team composition

Takosha Churu, the technical architect, died in June 2023 before the design could be fully specified. Daniel Ames stepped back in 2025. The community DAO elected a new team who inherited the whitepaper, the chain, and 410 nodes — but not the original architects' detailed technical intent. Their first task was to understand what they had. The formal KDD/ODC design process — 28 decisions, 16 open choices — was their output.

Reason 2

The design process revealed scope creep in the original framing

Working through design decisions formally revealed that NFTs, royalties, and a game creator toolkit were not required for the core primitive to work. Each was a layer on top. Each layer added complexity and attack surface. Each was removed. This is not a criticism of the 2023 whitepaper — it was written for a community audience, not as a technical specification.

Reason 3

The product is more general than the original framing

The 2023 whitepaper addressed one market: people who want to build dice games. The 2026 design is application-agnostic — any application requiring a verifiable random number can use PTX. This is a broader and more defensible market position, and more honest about what the technology actually does.

// 2023 vs 2026

Side-by-side comparison.

Green = unchanged  ·  Amber = evolved  ·  Strikethrough = dropped  ·  Teal = new addition

Dimension2023 Whitepaper2026 PTX Design
What it isGames platformRandomness primitive / infrastructure layer
Who it servesGame creatorsAny application needing verifiable randomness
Core deliveryToolkit: dice, cards, NFT piecesptx_roll() — one API call
Chain foundationUTXO L1, PoS, 60s blocksUnchanged
Node networkGamemaster nodes, collateralisedUnchanged — 410 live May 2026
No smart contractsCore principleCore principle — unchanged
Cryptography"Proprietary algorithms" — unspecifiedHash commit-reveal (Ph1) → threshold BLS12-381 (Ph2+)
Statistical proofNone proposedNIST SP 800-22 — 15/15 on reference C
Anti-grindingNot specifiedBlock height anchoring (KDD-003)
API contractRPC API described — no parametersptx_roll(count, low, high, unique, exclude) fully specified
NFT game piecesCore featureDropped — application-layer concern
Game creator royaltiesCore value propositionDropped — outside PTX scope
Play-to-earnPlayer earnings modelDropped — PTX produces randomness, not rewards
SlashingImplied conventional penaltiesExplicitly rejected (KDD-023) — PoSe + lottery exclusion only
Design process9-page non-technical whitepaper28 KDDs, 16 ODCs, design doc v3.5, API ref v3.5, tech overview v3.5, Phase 1 implementation plan
Build validationNone specifiedPhase 0 formal test suite — published pass/fail results

A Layer 1 UTXO blockchain with a peer-to-peer network of collateralised second-layer nodes uses deterministic quorum subsets to produce verifiable randomness, delivered to any developer via a simple RPC API, with no smart contracts required.

— This sentence describes both the 2023 whitepaper and the 2026 PTX design. Daniel Ames wrote it in 2023. The new team implemented it in 2026.
The 2026 PTX design is not a rejection of the original vision. It is a precision instrument built from the core of that vision — with application-layer features removed, the cryptographic specification completed, the API formalised, and the statistical validity proven.

// community

Follow the build.

PTX won't accept developer integrations until Phase 3 (Q2 2027). Phase 1 is complete. Phase 2 (testnet) is next. The right move now is Discord.

Phase 1 complete — ahead of schedule. Phase 2 (testnet, threshold BLS) is next. Testnet access opens in Phase 3 (Q2 2027). Developer SDK and API docs released at Phase 3.

Discord

The primary channel for development updates, technical discussion, and support. Official support channel for the Hemis project.

discord.gg/cr6JGwPunQ

GitHub

Hemis node software and codebase. PTX is being built on top of existing hemisd infrastructure.

github.com/Hemis-Blockchain

Bluesky & X

Development announcements and updates.

@hemisblockchain

If you're a game developer

API docs and SDK will be available at Phase 3 (Q2 2027). The goal is that anyone who can make an HTTP call can integrate PTX. Join Discord now to follow the design and give feedback on the API before it locks into production.

If you want to run a Gamemaster node

410 Gamemaster nodes are currently active on the existing Hemis chain. PTX Gamemaster participation will open from Phase 2 onwards. Node operators will earn from the daily lottery reward pool.

If you hold HMS tokens

Any HMS holder can stake to earn a share of block rewards. HMS currently trades on NonKYC exchange (HMS/USDT and HMS/BTC pairs). The project operates as a community DAO.


Phase 1 · Active Development

Ready to build on PTX?

Join the Hemis developer community. API docs, SDK, and testnet access coming in Phase 4.

Community View Roadmap → Read Whitepaper →