WCAHT CHAIN
How WCAHT Chain works end to end — the consensus and execution architecture, the core account/staking/fee model, pure EVM support, and the institutional enterprise suite.
WCAHT is a high-throughput Layer 1 with stake-weighted BFT consensus and a parallel execution engine. It is not a fork of an existing chain — it is a purpose-built stack of named subsystems that each own one stage of the block lifecycle. The design goal is Solana-class throughput on commodity hardware, with an institutional compliance layer built into the node.
Use the browser extension for quick testnet access, or install the standalone Windows wallet for a dedicated desktop experience. Both wallets are non-custodial: keep recovery material private and use testnet funds only.
Install the unpacked extension from the WCAHT testnet ZIP.
chrome://extensions).Install the native wallet without running a node.
Get-FileHash .\WCAHT-Wallet-Setup-1.0.4.exe -Algorithm SHA256 and compare the result
with the SHA-256 published on the download section. If it differs, delete the file.Read this before you create a wallet. It is short on purpose.
The web wallet generates keys in your browser. The secret key is shown to you once, at creation, so you can back it up — it is not uploaded to our servers, and we cannot recover or recreate it for you. Saved wallets in the dashboard hold public metadata only; when a signature is needed, you supply the key locally for that one operation and it is discarded from memory immediately afterwards.
Public-testnet validator operators may select an encrypted v2
<name>-validator-keypair.json. The browser derives its AES key with the same Argon2id parameters
used by wcaht-keygen, authenticates and decrypts with AES-256-GCM, verifies the embedded public
identity, and discards the decrypted key after the one operation. The encrypted file and passphrase are not
uploaded or saved. On-host signing remains the recommended hardened validator path.
Signed transactions and public addresses, because a blockchain cannot work otherwise. Balance and history lookups send your public address to a WCAHT node. Private keys, secret phrases and key files never leave the browser. Key files you select for import are read locally and are not uploaded.
Everything on this site is the public testnet, chain ID 7789. Test WCAHT has no monetary value, cannot be exchanged for money, and is not an investment. Do not send assets from another network to a WCAHT testnet address — they will not arrive and cannot be returned. Mainnet is targeted for 2027 and is conditional on the security and economics milestones on the roadmap, not on a date.
No independent third-party security audit has been completed yet. It is scheduled ahead of mainnet, after outside validators are running, so that the audit covers the real network rather than a snapshot. Treat this software as testnet software: use a fresh test wallet, and do not import a wallet you use anywhere else. Desktop builds are not yet code-signed — verify the published SHA-256 before running an installer, and do not get in the habit of clicking past operating-system warnings for wallet software.
The faucet never requires a payment, a deposit, a "verification" transfer, a social media task, or contact through a private message. If you are asked for any of those in order to receive test WCAHT, it is a scam and it is not us.
Report security issues privately to the maintainers through the official Telegram or Discord channels linked in the site footer, with reproduction steps. Consensus, fork-handling and sync edge cases are the most valuable reports. Please give us a chance to fix an issue before disclosing it publicly. A paid public bug bounty is planned alongside the incentivized testnet phase. Never include a private key or recovery phrase in a report — we do not need it, and no legitimate report requires one.
A transaction flows through five subsystems from submission to finality:
Validates, prioritizes and lanes incoming transactions in a sharded mempool.
Runs non-conflicting transactions in parallel (MVCC) and computes the state root.
The scheduled leader proposes a block; validators vote to finalize at ≥⅔ stake.
Erasure-codes the block into shreds and fans them out across the validator mesh.
Commits to a fork-aware ledger and serves the canonical chain to explorers & RPC.
| Parameter | Value | Notes |
|---|---|---|
| Slot duration | 400 ms | SLOT_DURATION_MS |
| Leader schedule | Round-robin, 12 slots/leader | WCAHT_RR_SLOTS_PER_LEADER |
| Finality threshold | ≥ ⌈2N/3⌉ stake | BFT supermajority |
| Min validator stake | Query getMinimumValidatorStake immediately before registration | The RPC value is in kak; the onboarding UI converts it using 1 WCAHT = 10⁹ kak and does not hardcode a different floor |
| Max txs / block | 50,000 (soft cap 2,000) | drain-budget tunable |
| Native unit | 1 WCAHT = 10⁹ kak | EVM layer uses 18 decimals |
| EVM chain ID | 7789 (0x1e6d) | RPC at /eth |
Skyfall is the stake-weighted Byzantine-fault-tolerant consensus layer. Validators stake WCAHT and take turns producing blocks on a deterministic round-robin schedule (12 consecutive slots per leader), then vote on every block. A block is final once votes representing at least a two-thirds supermajority of active stake (⌈2N/3⌉) are collected. Because the schedule is deterministic, every node can independently verify who the leader for a slot should be.
Skyreach owns the account model and state storage. Every account is keyed by its Base58 public key and stored in a dedicated RocksDB column family. Balances are denominated in kak (1 WCAHT = 10⁹ kak), and each account tracks a nonce for replay protection. Account writes are committed per slot with commit markers so state can be recovered deterministically after a restart. Reads are lazy (loaded from the store on demand), which keeps memory bounded regardless of chain size.
Prism executes a block's transactions concurrently using multi-version concurrency control (MVCC). Non-conflicting transactions run on separate cores; conflicting ones are ordered deterministically so every validator computes an identical state root. Duplicate-transaction detection is ancestry-based — a pure function of the block and its parent chain — so consensus execution never consults node-local state and can never fork on multi-transaction blocks.
TxFabric is the ingress layer. Incoming transactions are validated (signature, nonce, fee, balance), assigned to priority lanes, and partitioned across shards so the block builder can drain them in parallel. This intra-node sharding is what feeds Prism enough independent work to saturate all cores.
Cascade distributes finalized blocks across the validator mesh using erasure-coded shreds (Turbine-style fan-out) over QUIC. A receiver can reconstruct a block from a subset of shreds, so propagation is resilient to packet loss and does not depend on any single peer. Broadcast streams are explicitly finished so receivers never truncate a block mid-stream.
Hyperion is the fork-aware ledger. It tracks competing chain tips, applies fork choice against the canonical leader schedule, and exposes the finalized chain to explorers, wallets, and the JSON-RPC / EVM endpoints.
| Concept | Detail |
|---|---|
| Address | Base58-encoded Ed25519 public key (native) / 20-byte hex (EVM) |
| Smallest unit | 1 kak; 1 WCAHT = 1,000,000,000 kak |
| Replay protection | Per-account nonce, enforced at ingress |
| Per-tx cap | 10¹⁵ kak |
Validators register with a RegisterValidator transaction and provide the self-stake required by the
connected network. Operators must obtain the quorum-backed live minimum from getMinimumValidatorStake
immediately before signing; the returned value is in kak and the website displays its exact WCAHT conversion.
Stake, validators, and vote accounts are persisted to
RocksDB and reloaded on startup, so the active set survives restarts. See the
validator guide or start validator onboarding.
Choose a setup method · Guided terminal · QR wallet pairing · Security checklist
rpc_validator_observer mode while it synchronizes, passes the readiness and backup
gates, submits RegisterValidator, and waits through the activation boundary. Only after the exact
identity has non-zero registered consensus weight should the operator explicitly change that new host to
NODE_TYPE=validator; the guided terminal rolls it back to observer mode if voting health or finality
progress fails. Stake enters a one-epoch activation queue and becomes active automatically at the next epoch
boundary. The current epoch is 172,800 slots (about 19.2 hours at 400 ms/slot).Current public topology: N5, N6, N7, N8, and N9 are the active voting set. A dedicated
service at rpc1 follows the chain as a zero-weight rpc_validator_observer and is the intended
public read/RPC tier. N1 is retired and is not part of the active topology.
All roles run the same checksum-verified WCAHT binary and canonical genesis. The practical architecture has four node types;
fullnode remains a legacy/general role and rpc_validator_observer is a compatibility hybrid.
Choose one source of truth for the role. If both are supplied, the service environment's NODE_TYPE
overrides node_role in JSON.
| Node type | Role value | Purpose | Can become voting? |
|---|---|---|---|
| RPC | rpc | Wallet, explorer, REST/EVM RPC and finalized-chain replay. | No; first move it to a validator-capable runtime. |
| Observer | observer | Verifies, follows and monitors the chain without proposing or voting. | Yes, after promotion to validator. |
| Archive | archive | Observer/RPC services plus long-history retention. | Not while archival/non-voting; use a dedicated validator host for consensus. |
| Validator-capable | validator | Loads consensus services in standby and follows finality even with zero stake. | Yes; voting activates only after registration and stake activation. |
# RPC node "node_role": "rpc", "is_validator": false, "disable_consensus": true # Observer / monitoring node "node_role": "observer", "is_validator": false, "disable_consensus": true # Archive node — omit ledger_keep_blocks or set it to null "node_role": "archive", "is_validator": false, "disable_consensus": true, "archival_mode": true, "ledger_keep_blocks": null # Validator-capable node; zero stake remains safe and non-voting "node_role": "validator", "is_validator": true, "disable_consensus": false
Use the matching service environment when the launcher requires it:
sudo systemctl edit wcaht-NODE # Add exactly one role: [Service] Environment="NODE_TYPE=observer" # rpc | observer | archive | validator sudo systemctl daemon-reload sudo systemctl enable --now wcaht-NODE
RPC/REST uses 8901/tcp; gossip uses 8001/udp; QUIC block/vote transport uses
9001/udp. Validator-capable nodes must also make the dedicated signed consensus relay
8902/tcp reachable by active validators. Restrict SSH and any operator-control endpoint to a private
management network.
curl -fsS http://127.0.0.1:8901/status | jq '{
status, height:.block_height, slot, finalized:.finalized_slot,
role:.node.effective_node_role, weight:.node.registered_consensus_weight,
can_vote:.node.can_attempt_vote, voting:.node.is_voting_validator,
behind:.sync.blocks_behind, peers:.peers.connected
}'
Every participant runs the same binary. The service role controls which subsystems are available; activated consensus weight controls whether a validator-capable node may actually propose and vote. A UI toggle alone can never grant voting power. This section covers discovery, joining and the complete voting lifecycle.
A node builds its peer set in layers: it first attempts local UDP discovery, then falls back to
the configured seed / bootstrap nodes, and finally a DHT walk. Discovered peers are
tracked by the PeerManager. Blocks, transactions and consensus votes travel over a binary QUIC
transport (port 9001) plus a gossip layer; the JSON-RPC / REST control plane is a separate HTTP port
(8901), with signed HTTP consensus fallback on 8902. A node behind NAT can still reach the
mesh by dialling out to public seeds, but a validator must provide working return paths for its advertised QUIC,
gossip and consensus-relay endpoints. A home/NAT machine without those forwards is best run as an observer.
A fresh node points at one or more seed nodes, restores the latest snapshot (fast-sync), then
replays blocks forward until it reaches the live tip. Until it is caught up and holds
activated stake it should run as either an explicit observer or a validator-capable
validator in zero-weight standby. It verifies and stores blocks, serves RPC and gossips, but cannot
propose or vote. This is the normal, safe state for a new machine.
Two things must both be true before a node votes:
validator, trusted state, near-zero sync lag, visible
to peers, and reachable on the consensus transports.RegisterValidator transaction records the stake; stake,
validators and vote accounts persist to RocksDB and survive restarts.allow_dynamic_validators) and stake activation is deterministic.
The network runs atomic-delta staking (active from slot 0): a stake's activation and deactivation
are applied in-block at the epoch boundary and bound into the state root, so every node
agrees on exactly when a stake becomes active — no wall-clock race, no fork risk. In practice: provision a node,
sync it as an observer or validator-ready node, submit a RegisterValidator transaction with at least the minimum self-stake
(query getMinimumValidatorStake), and it is automatically activated into the voting set at the
next epoch boundary — no permissioned genesis inclusion required. Keep the service non-voting through that
boundary, then explicitly enable validator mode and verify the active weight. N5, N6, N7 and N8 are simply the current
active set; anyone meeting the live stake minimum can join it. Query getEpochInfo rather than copying an
old constant; the live network currently reports 172,800 slots (~19.2 h at 400 ms/slot).The runtime asks one question — is my consensus weight > 0? If not, the node cannot attempt to vote and behaves as an observer no matter how it was launched. A zero-stake node:
The dashboard labels this state validator-ready. Voting power appears only once the node holds activated stake in the registry.
The current public dashboard publishes the checksum-verified bundle and observer-first instructions. It does not
connect to the host over SSH, fund an identity, rewrite a running service role, or enable voting. The recommended
registration path signs on the validator host. For public-testnet testing, the wallet can also read the selected
encrypted v2 <name>-validator-keypair.json in local browser memory, verify its declared identity and
sign one operation; the file, passphrase and decrypted key are not uploaded or saved.
A future restart-free promotion control will only switch a preloaded validator-capable runtime from observer to validator-ready through an authenticated node-operator endpoint. It still cannot create voting weight: the operator must explicitly fund and register the identity, and the network activates stake deterministically.
The full guided flow lives at validator onboarding. In short: provision an Ubuntu host (8+ cores, 16+ GiB RAM, NVMe SSD, public IPv4), obtain the checksum-verified release and canonical genesis bundle, generate the encrypted five-role validator key set on the server and back it up offline, start the node and let it sync as an observer, fund its public identity, then sign registration on that host:
# Use the exact command in the downloaded bundle README. sudo -u wcaht-validator env \ WCAHT_KEY_PASSPHRASE_FILE=/run/wcaht-key-passphrase \ /opt/wcaht-validator/wcaht-submit-tx \ --node http://127.0.0.1:8901 --rpc \ --genesis-keypair-path /var/lib/wcaht-validator-secrets/keys/NODE-validator-keypair.json \ --tx-type register-validator --to VALIDATOR_IDENTITY \ --amount LIVE_MINIMUM_IN_KAK --commission-bps REVIEWED_BPS
The encrypted identity stays on the validator host with this recommended method. After registration, keep observer mode through the activation epoch; then explicitly enable validator mode and verify non-zero voting weight, convergence and finality. The complete five-key role map, secure PowerShell copy/passphrase procedure, four-way identity check, optional dashboard import, registration and activation sequence is in the validator key operator flow.
Transactions pay a fee in kak that is deducted atomically with the transfer. Fee parameters are logged at node startup and are governable in the target design. All balance arithmetic on the canonical execution path is saturating and guarded, so a transaction can never underflow an account.
WCAHT exposes an Ethereum JSON-RPC endpoint for signed legacy, EIP-2930, and EIP-1559 transactions, balances, receipts, contract execution, logs, and common wallet tooling. This public testnet is still closing less-common execution-client edge cases; applications should test the exact RPC methods they depend on before production use.
# Add the network to MetaMask Network name: WCAHT Testnet RPC URL: https://denvion.com/eth Chain ID: 7789 (0x1e6d) Currency: WCAHT (18 decimals on the EVM layer)
See the Developer Hub for one-click network add and code examples.
On testnet, anyone can claim free WCAHT from the faucet (the "airdrop") so they can deploy contracts, run validators, and test transfers without buying anything.
They are not newly minted. The faucet transfers WCAHT out of the genesis treasury
account — a pool that was allocated once when the chain started. Each claim is an ordinary signed
transfer from the treasury to your address that goes through consensus like any other transaction. Total supply
never increases; coins simply move from the treasury pool to testers. (In the code:
"Faucet draws from genesis treasury — no new tokens created.")
| Rule | Value |
|---|---|
| Amount per claim | 100 WCAHT |
| Cooldown between claims (per address) | 60 seconds |
| Max claims per address per day | 10 |
| Lifetime faucet budget | 100,000 WCAHT total |
| Availability | Testnet / devnet only — disabled on mainnet |
The faucet stops dispensing in any of these cases:
MAX_SUPPLY_REACHED and stops.FAUCET_DISABLED_MAINNET — real WCAHT is then acquired only through transfers from funded accounts,
validator rewards, or exchanges.RATE_LIMITED until the window resets.{ "address": "<your_address>" } → 100 WCAHT. Also available as the "Request test tokens" button in the web wallet.Every node exposes a public HTTP API (default port 8901). Reads are open; transaction submission
requires an x-api-key. There is also an Ethereum JSON-RPC endpoint at /eth.
x-api-key. Transfers ≥ 1000 WCAHT require Travel Rule data.getBalance and getLatestBlockhash. A node operator's local endpoint remains http://127.0.0.1:8901/rpc.CreateValidatorRequest). See the validator guide.eth_* methods (eth_chainId, eth_getBalance, eth_sendRawTransaction, …). Chain ID 7789. Works with MetaMask / ethers.js / web3.js.# Native REST curl https://denvion.com/balance/<address> # EVM JSON-RPC curl -X POST https://denvion.com/eth \ -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'
WCAHT ships an institutional compliance and integration layer inside the node, exposed as a
REST API under /enterprise/*. It covers KYC/KYB, sanctions screening, the FATF Travel Rule,
custody signing policies, an OAuth-style API gateway, ISO 20022 payment metadata, reconciliation/audit,
idempotency, and per-partner rate limiting. Every module is covered by an automated verification suite.
All /enterprise/* routes require an admin bearer token. Write routes additionally pass through
per-partner rate limiting.
GET /enterprise/sandbox/info Authorization: Bearer $ENTERPRISE_ADMIN_TOKEN
None → Basic → Intermediate → Full → Institutional, with per-record
provider, country, LEI, VASP flag, and expiry (expired records read as None).The combined gate POST /enterprise/compliance/check runs all three and returns a structured result
(passed, sanctions_clear, kyc_sufficient, travel_rule_satisfied, errors[]).
An OAuth 2.0 client_credentials–style gateway for machine-to-machine access:
ReadChain, SubmitTransaction, Compliance,
Custody, PaymentSubmit, Admin, and more.{method}\n{path}\n{timestamp}\n{body} with
standard HMAC-SHA256 and a 5-minute replay window — reproducible with any crypto library.An HSM-abstraction layer with configurable signing policies (allowed hours, approval quorum, provider) and multi-step signing sessions that require explicit approval before a high-value operation proceeds. Policies and sessions are queryable and approvable over REST.
Structured payment metadata following the ISO 20022 model — credit-transfer transactions, remittance information, regulatory reporting, postal addresses, and end-to-end ID lookup — can be attached to and retrieved for on-chain transactions, so bank-grade payment context travels with the transfer.
An isolated testing environment: a sandbox-mode flag, a rate-limited test faucet (only active in sandbox mode), and a dry-run that predicts the exact balance changes and fee of a transfer without touching state.
Idempotency-Key; a replayed request returns the
cached response instead of re-executing (24-hour TTL).{total, entries[]}).POST /enterprise/compliance/check Authorization: Bearer $ENTERPRISE_ADMIN_TOKEN Content-Type: application/json { "from": "<sender_address>", "to": "<recipient_address>", "amount_kak": 2000000000000, "required_kyc": "Basic" } // → { "passed": false, "travel_rule_satisfied": false, // "errors": ["Travel Rule: data required for transfers above threshold"] }