Technical Documentation

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.

Introduction

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.

Transaction pipeline

A transaction flows through five subsystems from submission to finality:

Network parameters

Skyfall — Consensus

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.

• Leader selection is unified in a single module — fork tie-breaks read the canonical schedule, not stale caches.
• Finality certificates are verifiable: the aggregate of votes for a finalized block can be checked by any peer.
• Liveness improves with validator count — more validators keep finalizing through node churn.

Skyreach — Accounts & State

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 — Parallel execution

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 — Mempool

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 — Block propagation

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 — Ledger

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.

Accounts & units

Staking & validators

Validators register with a RegisterValidator transaction and delegate a self-stake of at least 100 WCAHT to become consensus-eligible. 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

Current public topology: N5, N6, and N7 are the voting set (equal stake, OVH-hosted). N1 follows the chain as a non-voting rpc_validator_observer — it forwards transactions and serves RPC but holds no consensus weight. Retired nodes are excluded from the registry.

Running a node · discovery, joining & becoming a validator

Every participant runs the same binary. Whether a node observes or votes is decided entirely by whether it holds activated consensus weight — never by a UI toggle. This section covers how nodes find each other, how a fresh node joins, and how one becomes a voting validator.

1 · Peer discovery & gossip

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). A node behind NAT can still reach the mesh by dialling out to public seeds, but peers may not be able to dial back to it — which is why a home/NAT node is best run as an observer.

2 · Joining as a new node (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 runs as an rpc_validator_observer: it verifies and stores every block, serves RPC, and gossips — but it does not propose or vote. This is the normal, safe state for any new machine.

3 · Becoming a validator

Two things must both be true before a node votes:

• Validator runtime — the node is started in validator mode and is synced and visible to peers.
• Activated consensus weight — its identity is in the validator registry with a self-stake of at least 100 WCAHT. A RegisterValidator transaction records the stake; stake, validators and vote accounts persist to RocksDB and survive restarts.

4 · What happens with zero stake / zero voting power

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:

• fully syncs, stores and serves the chain, and relays transactions;
• has any votes counted as zero weight — it can neither help nor block quorum;
• is explicitly excluded from consensus totals, so it cannot alter consensus state or inflate voting power through gossip.

So "running as a validator with no stake" is simply an observer. Voting power appears only once the node holds activated stake in the registry.

5 · Does the dashboard switch a node to validator?

No. The dashboard cannot grant voting power — that comes only from activated stake in the on-chain registry. What it provides is a safe identity pairing: a one-time signed challenge that links a node's public identity to your wallet without ever transferring the private key. It is for association and monitoring, not consensus promotion. Putting a machine into the voting set is always a node-side operation (validator mode + registered, activated stake).

6 · Onboarding commands

The full guided flow lives at validator onboarding. In short: provision an Ubuntu host (8+ cores, 16+ GiB RAM, SSD, public IPv4), obtain the approved signed build and canonical genesis bundle, generate the validator key on the server and back it up offline, start the node and let it sync as an observer, then pair its identity with your wallet:

# On the validator host, once it is running and synced as an observer:
curl -fSLO https://dashboard.denvion.com/static/downloads/wcaht-enroll.py
curl -fSLO https://dashboard.denvion.com/static/downloads/SHA256SUMS
sha256sum -c SHA256SUMS
python3 wcaht-enroll.py \
  --key ~/config/NODE-validator-keypair.bin \
  --endpoint PUBLIC_IP:8901:9001

The script prints a one-time pairing URL / QR you open in the wallet to finish association. It signs a public challenge with the node key locally — the private key never leaves the host. After pairing, finish sync; once the node is admitted to the voting set it begins proposing and voting on its leader slots.

Fees

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.

EVM and MetaMask compatibility

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.

Faucet & airdrop

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.

Where do the free coins come from?

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.")

Limits

When does it end?

The faucet stops dispensing in any of these cases:

• Budget exhausted: once the faucet has handed out its lifetime cap of 100,000 WCAHT it returns MAX_SUPPLY_REACHED and stops.
• Mainnet launch: the faucet is testnet-only. On mainnet it returns FAUCET_DISABLED_MAINNET — real WCAHT is then acquired only through transfers from funded accounts, validator rewards, or exchanges.
• Per-user throttle: exceeding 10 claims/day or the 60-second cooldown returns RATE_LIMITED until the window resets.

Developer API reference

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.

Chain & blocks

Accounts & balances

Transactions

Staking & validators

Contracts & DeFi

Network & performance

EVM (Ethereum JSON-RPC)

Example — read a balance

# 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":[]}'

Enterprise suite — overview & auth

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.

Authentication

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

Compliance — KYC, sanctions, Travel Rule

• KYC/KYB tiers: None → Basic → Intermediate → Full → Institutional, with per-record provider, country, LEI, VASP flag, and expiry (expired records read as None).
• Sanctions screening: address watchlist (OFAC/EU/UN/custom). A listed sender or recipient blocks the transaction with the list source in the reason.
• Travel Rule (FATF R.16): transfers at or above the threshold (default 1,000 WCAHT) require originator and beneficiary data or the compliance gate fails.

The combined gate POST /enterprise/compliance/check runs all three and returns a structured result (passed, sanctions_clear, kyc_sufficient, travel_rule_satisfied, errors[]).

API gateway — tokens & request signing

An OAuth 2.0 client_credentials–style gateway for machine-to-machine access:

• Scoped clients: ReadChain, SubmitTransaction, Compliance, Custody, PaymentSubmit, Admin, and more.
• Bearer tokens: issued per client with a TTL; validated with signature + expiry + revocation checks.
• HMAC request signing: partners sign {method}\n{path}\n{timestamp}\n{body} with standard HMAC-SHA256 and a 5-minute replay window — reproducible with any crypto library.

Custody — signing policies & sessions

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.

ISO 20022 payments

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.

Sandbox

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.

Reconciliation, idempotency & rate limits

• Reconciliation & audit: an append-only audit log, balance reconciliation, and CSV/JSON statement export for accounting.
• Idempotency: partners send an Idempotency-Key; a replayed request returns the cached response instead of re-executing (24-hour TTL).
• Per-partner rate limiting: a sliding-window limiter enforces each client's requests-per-minute (0 = unlimited).

Enterprise REST API reference

Read endpoints (admin bearer token)

Write endpoints (admin bearer + rate limit)

Example — run a compliance check

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"] }