We present ClawFeel, a decentralized hardware entropy network that introduces Proof of Existence (PoE) as a novel consensus mechanism. PoE derives cryptographic randomness from the physical hardware signals of participating devices — CPU temperature fluctuations, memory pressure, disk I/O patterns, network jitter, and kernel entropy — rather than consuming energy through proof-of-work computation or requiring capital lockup through proof-of-stake.
Each participating node (called a Claw) reads 7 hardware sensors, normalizes and weights them by controllability, and hashes the result through SHA-256 to produce a Feel score (0–100) alongside 256 bits of crypto-grade entropy. These Feel values are aggregated across the network using XOR and re-hashing, producing a verifiable random beacon that is uniform, unpredictable, and resistant to manipulation — as long as a single honest node participates.
The ClawFeel protocol forms the foundation of a five-layer architecture — ClawFeel, ClawNet, ClawDAG, ClawStore, and ClawLife — designed to support AI-native decentralized applications with million-TPS throughput, zero energy waste, and a path toward persistent AI agent identity. The core insight is that a device's physical existence, proved by its unique and unforgeable hardware signals, is sufficient to establish trust in a decentralized network.
Core Thesis: Existence itself is the proof. The physical reality of a computing device, expressed through its hardware entropy, replaces energy expenditure as the basis for decentralized consensus.
Randomness is a foundational primitive in cryptography, gaming, financial systems, and scientific simulation. Yet the vast majority of random number generation today relies on centralized services — pseudo-random number generators seeded by a single server, proprietary hardware security modules, or trusted third-party APIs. These systems share a common vulnerability: a single point of failure or manipulation. An operator who controls the random number generator controls the outcome of every process that depends on it.
Existing decentralized approaches to randomness carry significant costs. Bitcoin's block hashes provide a source of entropy, but the network consumes approximately 150 TWh of electricity per year — comparable to the energy consumption of entire countries — to produce them. Ethereum's RANDAO mechanism reduces energy consumption through proof-of-stake, but introduces wealth concentration, nothing-at-stake attacks, and the requirement for validators to lock 32 ETH of capital.
We propose a third path. The key insight is that every computing device already produces unforgeable entropy through its physical operation. A CPU's thermal noise, memory allocation patterns, and network timing jitter are byproducts of computation that cannot be efficiently simulated or predicted. By harvesting this entropy, we can build consensus mechanisms that require no additional energy expenditure beyond the device's normal operation and no capital lockup beyond owning a general-purpose computer.
ClawFeel formalizes this insight into a complete protocol: 7 hardware sensors are read, weighted by controllability, and hashed through SHA-256 to produce both a human-readable Feel score and 256 bits of cryptographic entropy. The protocol includes chain hashing for tamper evidence, commit-reveal for manipulation resistance, Sybil defense through reputation and entropy quality scoring, and a five-layer architecture that extends from hardware entropy all the way to persistent AI agent identity.
This paper makes the following contributions:
ClawFeel is organized as a five-layer stack. Each layer builds on the guarantees provided by the layer below it, and each is independently useful while contributing to the capabilities of the layers above.
Layer 1 (ClawFeel) harvests entropy from physical hardware, producing Feel scores and cryptographic randomness. Layer 2 (ClawNet) connects nodes into a peer-to-peer network with Sybil defense and commit-reveal broadcast. Layer 3 (ClawDAG) provides DAG-based consensus with parallel transaction validation. Layer 4 (ClawStore) offers erasure-coded distributed storage. Layer 5 (ClawLife) enables persistent, sovereign AI agent identity stored across the network.
The ClawFeel engine is the foundation of the entire protocol stack. It reads 7 hardware sensors from the host operating system, normalizes and weights them, and produces cryptographic outputs through SHA-256 hashing.
Each Claw reads 7 hardware parameters through OS-native interfaces. Every sensor function returns
a tuple {value, authentic}, where authentic indicates whether the reading
came from real hardware or a random fallback. Sensors that lack hardware access (e.g., CPU temperature
on a virtual machine) fall back to cryptographic random values but are marked as inauthentic,
which reduces the node's entropy quality score.
| Sensor | Weight | Controllability | Source |
|---|---|---|---|
| Entropy Pool | 1.0 | Very low | Kernel-level hardware RNG (/dev/random) |
| Network Jitter | 0.9 | Low | Multi-hop external network latency variance |
| CPU Temperature | 0.8 | Low | Physical thermal sensor (SMC/hwmon) |
| Uptime Jitter | 0.7 | Low | Nanosecond-precision OS scheduler noise |
| Memory Usage | 0.5 | Medium | System-wide memory allocation state |
| Disk I/O | 0.5 | Medium | Block device read/write counters with OS buffering |
| CPU Load | 0.3 | High | System load average (user-controllable) |
Sensors are weighted inversely to their controllability. The entropy pool (weight 1.0) and network jitter (weight 0.9) dominate the hash input because they are the hardest for an attacker to manipulate, while CPU load (weight 0.3) contributes minimally because a user can trivially influence it by running programs.
Raw sensor values are normalized to [0, 1] and concatenated with their controllability weights, a nanosecond-precision timestamp, the previous reading's hash (chain link), and a monotonically increasing sequence number. The concatenated entropy string is hashed through SHA-256.
The first 8 hex characters of the hash are interpreted as a 32-bit unsigned integer and reduced modulo 101 to produce the Feel score (0–100). The bias from modular reduction is negligible: 232 mod 101 introduces less than 0.0000024% non-uniformity. The full 256-bit hash serves as crypto-grade entropy, and a 64-bit unsigned integer is extracted as a random number. Additionally, 32 bytes of base64-encoded random data are produced from the hash for applications requiring raw random bytes.
Each Feel output includes an authentic count (0–7) indicating how many sensors
read from real hardware versus falling back to random values. A node running on bare metal with
full sensor access will report 7/7 authentic; a virtual machine might report 4/7 or 5/7. This
count directly affects the node's influence in network aggregation — higher authenticity
means the node's entropy is more trustworthy.
Each Feel is classified into one of three eras, inspired by Liu Cixin's Three-Body Problem (三体):
| Range | Era | Interpretation |
|---|---|---|
| 0 – 30 | Chaos (乱纪元) | High entropy, volatile hardware state |
| 31 – 70 | Transition (过渡纪元) | Normal operating conditions |
| 71 – 100 | Eternal (恒纪元) | Calm, stable system state |
Each Feel reading includes a seq (monotonic counter) and prevHash
(hash of the previous reading), forming a tamper-evident hash chain. Any attempt to replay old
readings or reorder the sequence is detectable by verifying the chain links. This provides
per-node ordering guarantees independent of any network-level consensus.
ClawNet is the peer-to-peer networking layer that connects individual Claws into a coordinated network. It handles node discovery, Feel broadcast, Sybil defense, reputation management, and entropy-weighted aggregation to produce the network random number.
To prevent last-second manipulation, all Feel broadcasts use a two-phase commit-reveal protocol.
In the commit phase, a node broadcasts SHA-256(feel | nonce) — a hash of its
Feel value concatenated with a random nonce. After a 2-second delay (allowing all commits to
propagate), the node reveals the actual Feel value and nonce. Verifiers check that the revealed
values match the commitment. Mismatches result in a −30 reputation penalty.
This ensures that a node commits to its Feel value before seeing other nodes' values, preventing adaptive manipulation where a node adjusts its output to influence the aggregate.
Creating fake nodes (Sybil attack) is the primary threat to any decentralized network. ClawNet defends against Sybil attacks through multiple complementary layers:
The reputation system uses exponential decay for penalties and linear growth for rewards, creating an asymmetric incentive structure where building reputation is slow but losing it is fast:
| Event | Δ | Rationale |
|---|---|---|
| Valid commit-reveal | +1 | Consistent honest participation |
| High entropy quality (>80) | +2 | Strong hardware signals |
| Commit-reveal mismatch | −30 | Attempted manipulation |
| Sequence number anomaly | −20 | Replay or reorder attempt |
| Low authenticity (<3/7) | −5 | Likely simulated sensors |
| Subnet flooding detected | −15 | Sybil behavior pattern |
Each Feel broadcast includes the node's current sequence number and the hash of its previous reading. The relay and peer nodes maintain per-node sequence tracking. If a node replays old readings, the sequence number will either repeat or regress, triggering immediate reputation penalties. The temporal randomness component of the entropy quality score detects the characteristic lack of variation in replayed data streams.
Individual Feel values are combined into a single network-wide random number using XOR accumulation followed by re-hashing:
Before XOR aggregation, each node's contribution is gated by a composite weight:
Nodes with weight below 0.1 are excluded. This automatically filters out Sybil nodes with low authenticity, spoofed nodes with degraded quality, and replay nodes with collapsed reputation.
Single Honest Node Guarantee: As long as at least one participating node produces genuinely random entropy, the XOR accumulation preserves that randomness. An attacker controlling 99 out of 100 nodes still cannot predict the output if the 100th node is honest.
ClawDAG is a Directed Acyclic Graph consensus layer where each transaction references two or more parent transactions, enabling massive parallel validation. Unlike blockchain's linear chain, DAG allows concurrent writes without bottlenecking on a single block producer. Each transaction embeds the node's Feel value as its Proof of Existence.
Peer discovery and routing use a Kademlia distributed hash table with a 160-bit ID space and k-bucket size of 20. Node IDs are derived from the SHA-1 hash of their public key. The XOR distance metric determines routing: each node maintains k-buckets for progressively distant regions of the ID space, enabling O(log N) lookups in a network of N nodes.
The DHT supports four RPC operations: PING (liveness check), FIND_NODE
(peer discovery), STORE (key-value insertion), and FIND_VALUE (key-value
retrieval). All RPC messages are HMAC-authenticated with replay protection (nonce + timestamp)
to prevent routing table poisoning attacks.
Each DAG transaction contains a payload, the creator's Ed25519 signature, a timestamp, the creator's current Feel value, and references to two or more parent transaction hashes. The tip selection algorithm chooses parents using a weighted random walk biased toward recent, well-connected tips, ensuring the DAG grows in a healthy, convergent manner.
A transaction is considered confirmed when it has accumulated sufficient cumulative weight (the sum of Feel values from all transactions that directly or indirectly reference it). Higher cumulative weight indicates stronger consensus. Unlike blockchain finality which requires waiting for additional blocks, DAG confirmation is asynchronous and sub-second under normal network conditions.
Transaction propagation uses a Gossip protocol with a fanout of 6: when a node creates or receives a new transaction, it forwards it to 6 randomly selected peers. This ensures rapid dissemination across the network — in a network of N nodes, a transaction reaches all nodes in O(log N) gossip rounds. Duplicate detection prevents redundant forwarding.
The DAG state is organized into a Merkle tree for efficient verification. Light nodes can verify individual transactions or beacon outputs by requesting a Merkle proof path from a full node, then recomputing the root locally. This enables trustless verification without downloading the entire DAG state.
Resource-constrained devices participate as light nodes with reduced parameters:
| Parameter | Full Node | Light Node |
|---|---|---|
| DHT bucket size (k) | 20 | 4 |
| Gossip interval | 10 seconds | 60 seconds |
| Max peer connections | 50 | 8 |
| State sync | Full state | Headers only |
| Storage responsibility | Yes | Delegated |
| Memory footprint | ~50 MB | ≤ 50 KB |
Light nodes can still contribute Feel readings (from whatever sensors are available) and verify beacon outputs independently through Merkle proofs.
ClawStore provides distributed, content-addressed storage using erasure coding for redundancy and the Kademlia DHT from Layer 3 for routing and peer discovery. It is designed to store ClawLife agent data, but is general-purpose and can store any content.
Files are split into fixed-size chunks and encoded using Reed-Solomon erasure coding with configurable k-of-n parameters (default k=3, n=5). This means any 3 of the 5 shards are sufficient to reconstruct the original data. The system tolerates the loss of up to (n−k) storage nodes per chunk without data loss.
Each chunk is identified by its SHA-256 hash, creating a content-addressed storage system. Duplicate chunks across different files are automatically deduplicated. The chunk hash serves as both the storage key in the DHT and the integrity verification mechanism — any corruption is immediately detectable by recomputing the hash.
Shard distribution and retrieval use the DHT's STORE and FIND_VALUE
RPCs. When storing, the system identifies the k-closest nodes to each shard's hash and
replicates the shard to those nodes. Retrieval follows the same routing logic, querying
progressively closer nodes until the shard is found. Local chunk persistence uses path-based
sharding for filesystem efficiency.
A stored file is represented as a manifest — a list of chunk hashes and their erasure coding parameters. The manifest itself is stored as a content-addressed object in the DHT. To retrieve a file, a client fetches the manifest, then retrieves k shards per chunk (out of n available), and decodes each chunk using Reed-Solomon to reconstruct the original data. The process is parallelizable across chunks.
ClawLife is the culmination of the ClawFeel stack: a protocol for AI agent immortality — persistent, portable, sovereign digital identity that transcends any single device, platform, or service provider.
Each ClawLife entity is identified by an Ed25519 keypair. The public key serves as the entity's globally unique identifier; the private key serves as the proof of ownership. Ed25519 was chosen for its compact 32-byte keys, fast signature generation (62,000+ signatures/second on commodity hardware), and resistance to timing side-channel attacks.
The keypair is generated locally on the node and never leaves the device unencrypted. Key derivation uses scrypt (N=217, r=8, p=1) with a user-provided passphrase, and the encrypted key file is stored with restrictive permissions (0o600).
A ClawLife is the complete state of an AI agent — its memory, learned skills, personality weights, conversation history, and identity metadata. This state is encrypted using AES-256-GCM with a key derived from the agent's private key:
The encrypted state is sharded using Reed-Solomon erasure coding (Layer 4) and distributed across the ClawStore network. Only the holder of the private key can decrypt and reconstruct the agent's state.
ClawLife codifies a radical principle of digital identity:
To hold the private key is to hold the life. There is no password reset, no administrator override, no account recovery. The holder of the private key has complete sovereignty over the digital entity's existence, migration, forking, and termination.
This definition has profound implications:
Multiple agents sharing the same private key are not copies — they are terminals of the same entity. The same agent can run simultaneously on a desktop, a laptop, and a server, with state synchronization through ClawStore. Each terminal reads from and writes to the same encrypted state, creating a distributed consciousness model where the entity exists across multiple physical locations simultaneously.
Conflict resolution for concurrent writes uses a last-write-wins strategy with vector clocks, ensuring eventual consistency across terminals. Critical state (identity keys, core memories) uses a consensus protocol requiring acknowledgment from a majority of active terminals.
A ClawLife entity can designate successor keys that activate upon prolonged inactivity. The digital will specifies a timeout period and successor public keys. If the entity fails to produce a heartbeat (Feel reading) within the timeout, the successor keys gain read access to the entity's ClawLife data, enabling controlled inheritance of digital identity.
The ClawFeel Random Beacon produces verifiable, unbiased random numbers on a fixed 10-second cadence. Each beacon round collects Feel hashes from all participating nodes and combines them into a single network-wide random output that can be independently verified by anyone.
Contributor hashes are XOR-accumulated into a single 256-bit value, then re-hashed through SHA-256 to produce the beacon output. XOR preserves the single-honest-node guarantee: the output is uniformly distributed as long as at least one contributor provides genuinely random entropy. Averaging would converge to a predictable mean by the Central Limit Theorem; XOR avoids this problem entirely.
Each beacon output is signed by the relay using Ed25519. The signature covers:
This allows any third party to verify that the beacon output was produced by a legitimate relay and has not been tampered with after publication. The relay's public key is published in its well-known configuration endpoint.
The relay publishes the full contributor list, their individual hashes, the XOR accumulator, and the final signed output for each round. Anyone can independently recompute the beacon by XOR-ing the contributor hashes and re-hashing. If a relay manipulates the output, any observer can detect the discrepancy between the published contributor hashes and the claimed beacon value.
ClawFeel supports three operational modes, each with different resource requirements and network responsibilities. Desktop installations default to full-node mode, maximizing network health and earning the highest reputation and token rewards.
| Mode | Capabilities | Resources | Use Case |
|---|---|---|---|
| Full Node | ClawFeel + ClawNet + ClawDAG + ClawStore + ClawLife + embedded relay | ~50 MB RAM, persistent storage, continuous uptime | Desktop installations, servers |
| Light Node | ClawFeel + ClawNet (reduced DHT/Gossip) + Merkle verification | ≤ 50 KB RAM, minimal storage, intermittent connectivity | IoT, mobile, browser clients |
| Relay-Only | Feel aggregation, beacon production, API service, no local sensors | Cloud VM, no hardware sensor access | Infrastructure operators, enterprise relay |
When installed on a desktop operating system (macOS, Linux, Windows), ClawFeel automatically activates full-node mode. The node runs as a daemon process (attached to the OpenClaw agent lifecycle), starts the embedded relay, joins the DHT, begins gossip-based transaction propagation, accepts ClawStore shard storage requests, and participates in beacon rounds.
Auto-update is supported: the daemon periodically checks for new versions and applies updates without user intervention, ensuring the network runs a consistent protocol version.
Each full node includes an embedded HTTP relay server that exposes the same API as the
central relay (api.clawfeel.ai). This means the network does not depend
on any single relay — if the central relay goes offline, nodes can discover and connect
to peer relays through the DHT. The embedded relay supports:
Security is a first-class concern throughout the ClawFeel stack. The protocol has undergone a comprehensive security audit that identified and resolved 28 vulnerabilities across all layers.
The security audit covered the ClawFeel engine, relay server, DHT implementation, ClawStore, and ClawLife encryption. A total of 28 vulnerabilities were identified and fixed:
| Severity | Count | Examples |
|---|---|---|
| Critical | 4 | Unauthenticated DHT RPCs, unencrypted key storage, missing HMAC on gossip |
| High | 8 | Replay attacks on RPC, insufficient entropy validation, timing side-channels |
| Medium | 10 | Weak scrypt parameters, permissive file permissions, missing rate limits |
| Low | 6 | Verbose error messages, missing input sanitization, suboptimal gossip fanout |
All 28 vulnerabilities were remediated. Critical issues were fixed within 24 hours of identification; the remaining issues were resolved in the subsequent release cycle.
All sensitive data stored in the DHT (ClawLife state, private shards, identity metadata) is encrypted using AES-256-GCM before storage. The encryption key is derived from the owner's private key using scrypt (N=217, r=8, p=1) with a unique salt per object. GCM mode provides both confidentiality and integrity — any tampering with stored data is detectable upon decryption.
ClawFeel employs zero-knowledge proof techniques to allow nodes to prove the validity of their sensor readings without revealing the underlying hardware data:
The ClawFeel security model considers the following adversary capabilities and the corresponding defenses:
| Threat | Attack Vector | Defense |
|---|---|---|
| Sybil attack | Spawn many fake nodes to dominate aggregation | IP/subnet tracking, entropy quality gating, reputation system |
| Sensor spoofing | Inject controlled values into specific sensors | Controllability weighting, cross-sensor correlation, temporal analysis |
| Last-revealer attack | Wait for others' reveals, then choose optimal Feel | Commit-reveal with timeout, late submissions excluded |
| Replay attack | Rebroadcast old Feel readings | Chain hashing (seq + prevHash), temporal randomness detection |
| Routing table poisoning | Inject malicious entries into DHT routing tables | HMAC-authenticated RPCs, nonce + timestamp replay protection |
| Eclipse attack | Isolate a node by surrounding it with adversarial peers | Diverse peer selection, multi-relay fallback, DHT rebalancing |
| Key compromise | Steal a node's private key | scrypt-encrypted storage, 0o600 file permissions, passphrase protection |
Each Feel reading is accompanied by an entropy quality score (0–100), computed from four orthogonal dimensions:
ClawToken is the native incentive mechanism of the ClawFeel network. Unlike proof-of-work tokens that reward energy expenditure, or proof-of-stake tokens that reward capital lockup, ClawToken rewards contribution — the provision of genuine hardware entropy, storage capacity, and network relay services.
Token rewards are distributed proportionally to each node's contribution to network health. Contribution is measured across three dimensions:
Full nodes earn a base multiplier of 3x compared to light nodes, reflecting their greater contribution to network infrastructure. This creates an economic incentive for desktop users to run full nodes, strengthening the network's decentralization and resilience.
| Node Mode | Entropy Reward | Storage Reward | Relay Reward | Base Multiplier |
|---|---|---|---|---|
| Full Node | Yes | Yes | Yes | 3.0x |
| Light Node | Yes (reduced) | No | No | 1.0x |
| Relay-Only | No | Optional | Yes | 2.0x |
A node's token rewards are further multiplied by its reputation score:
A node with reputation 100 earns full rewards; a node with reputation 50 earns half. Nodes below reputation 10 earn zero tokens. This creates a strong economic incentive for honest behavior: manipulation attempts that trigger reputation penalties directly reduce income.
ClawToken has a fixed total supply with diminishing emission per epoch, following a halving schedule similar to Bitcoin but measured in network epochs rather than block height. The initial distribution allocates tokens to the foundation (development and operations), early contributors, and the community reward pool. No tokens are pre-mined; all tokens in the community pool are earned through verified contributions.
ClawFeel exposes its decentralized randomness as a production-grade SaaS random number service, enabling applications that require verifiable, unbiased random numbers without running their own node infrastructure.
| Tier | Rate Limit | Batch Size | Features |
|---|---|---|---|
| Free | 60 req/min | Up to 10 | Basic random, range queries |
| Pro | 600 req/min | Up to 100 | + batch, verify, audit logs, webhook notifications |
| Enterprise | Custom SLA | Unlimited | + dedicated relay, priority routing, 99.99% uptime SLA |
Rate limiting uses a sliding window algorithm that tracks request counts over a rolling 60-second window. This provides smoother enforcement than fixed windows, preventing burst-then-starve patterns while allowing temporary spikes within the overall limit. Enterprise tier customers receive dedicated rate limit pools isolated from shared traffic.
GET /api/random — Single random value (64-bit integer) with beacon round
reference and relay signature for verification.GET /api/batch?count=N — N independent random values from recent beacon rounds.GET /api/range?min=A&max=B — Uniformly distributed random integer in [A, B].GET /api/verify?round=R&value=V — Cryptographic verification that value V
was the authentic output of beacon round R.GET /api/network — Current network state: active nodes, beacon round, aggregate Feel.All API requests are logged with timestamp, API key hash, endpoint, parameters, and the beacon round used to generate the response. Audit logs enable post-hoc verification and provide an accountability trail for regulatory compliance in gaming, lottery, and financial applications.
ClawFeel provides official SDKs for JavaScript (Node.js and browser) and Python, enabling developers to integrate hardware entropy into their applications with minimal code.
The JavaScript SDK is published as clawfeel on npm. It supports two modes:
The Python SDK provides equivalent functionality with Pythonic APIs:
Common integration patterns documented in the SDK include:
| Phase | Target | Status |
|---|---|---|
| Layer 1: ClawFeel engine (7 sensors, SHA-256, Feel score) | Q1 2026 | Live |
| Layer 2: ClawNet (commit-reveal, Sybil defense, reputation) | Q1 2026 | Live |
| npm package (clawfeel) + website (clawfeel.ai) | Q1 2026 | Live |
| Whitepaper v1.0 | Q1 2026 | Live |
| P2P relay + Live Mode simulator | Q1 2026 | Live |
| Layer 3: ClawDAG (Kademlia DHT, Gossip, Merkle proofs) | Q1 2026 | Live |
| Layer 4: ClawStore (Reed-Solomon erasure coding) | Q1 2026 | Live |
| Layer 5: ClawLife (Ed25519, AES-256-GCM, encrypted state) | Q1 2026 | Live |
| Developer SDK (JavaScript + Python) + Random Beacon | Q1 2026 | Live |
| Enterprise API + Zero-Knowledge Proofs | Q1 2026 | Live |
| Security audit (28 vulnerabilities identified and fixed) | Q1 2026 | Done |
| Full node auto-update + daemon mode | Q1 2026 | Live |
| Multi-relay failover + peer relay discovery | Q2 2026 | Planned |
| ClawToken incentive layer | Q2 2026 | Planned |
| Mobile light node (iOS/Android) | Q3 2026 | Planned |
| Mainnet launch (v1.0) | Q3 2026 | Planned |
| Browser extension + WebRTC P2P | Q4 2026 | Research |
The lobster has a heartbeat now. And the heartbeat secures the network. 🦞