RustChain's Python package says 2.2.1 and its newest release tag is a Windows miner at v3.1.2

Two version numbers that never meet in the same artifact

The Python packaging metadata says version 2.2.1. The newest GitHub release is v3.1.2-miner, named RustChain Windows Miner v3.1.2, with the parenthetical CRITICAL fingerprint fix, published on 2026-05-29. Before it came v1.0.0-miner in February 2026 and a Windows miner bundle tagged win-miner-2026-02.

So the release history contains three entries and all three are miner bundles for Windows. Nothing in it is a release of the node, the wallet, or the chain itself, and the package that the repository's metadata versions at 2.2.1 has no tag to match. A reader who looks up the latest release and the current version sees two unrelated numbers and no explanation of how they relate.

The titles carry their own information. A fingerprint fix is labelled critical, and the fingerprint is the consensus mechanism, so the most recent shipped artifact in this repository is a repair to the thing the chain is supposed to be built on. That is worth weighing before trusting a miner build, and it is worth asking which miner build the 2.2.1 node expects.

The last commit to the repository is dated 2026-09-30, more recent than any of the three releases.

Six physical signals, and a multiplier that rises with the machine's age

Proof of Antiquity is the consensus name, and the mechanism is hardware fingerprinting. The signals the project names are oscillator drift, cache timing, SIMD identity, thermal entropy, instruction jitter, and anti-emulation. Its own comparison table counts them as six hardware checks plus AI, and lists them as the anti-spoofing column against Helium's location proof, Filecoin's storage proofs, Render's job completion and io.net's TEE attestation.

The architectures are the other half: fifteen or more, named as PowerPC including G4 and G5, SPARC, MIPS, 68K, RISC-V, Cell BE, Transputer, ARM and x86.

The reward curve is the part that makes it a chain rather than a fingerprinting demo, and it is stated as a table of multipliers that grow with age. A machine mining in 2026 runs at 0.8x, the same machine at 1.3x in 2031 once it counts as retro, 1.8x in 2036 at the vintage tier, and 2.2x in 2041 at the ancient tier, described as still climbing. Named examples follow: a PowerBook G4 from 2003 at 2.5x against a modern Threadripper, a Power Mac G5 at 2.0x, and a 486 singled out as earning the most respect of all.

Those are the project's own numbers, presented as multipliers rather than as a measured comparison. The curve is drawn in the project file as a bar per tier:

2026:  Your Ryzen 9 mines at 0.8x         ░░░░░░░░░░
2031:  Same machine, now "retro" at 1.3x   ░░░░░░░░░░░░░
2036:  Vintage tier unlocked at 1.8x        ░░░░░░░░░░░░░░░░░░
2041:  Ancient tier — 2.2x and climbing     ░░░░░░░░░░░░░░░░░░░░░░

Nothing in the repository shows the measurement behind 2.5x, and the bar chart above is the whole of the evidence offered.

Two node roles, and only one of them needs a fleet secret

The node's trust level is selected by an environment variable, and the two settings are not equivalent. RC_NODE_ROLE defaults to sync, which the compose file describes as an external operator and notes needs no fleet secret. The alternative, settlement, is for fleet nodes and requires the privately issued RC_P2P_SECRET, which is left unset by default with a comment saying to leave it that way otherwise:

- RC_NODE_ROLE=${RC_NODE_ROLE:-sync}
- RC_P2P_SECRET=${RC_P2P_SECRET:-}

So a plain operator gets a node with no shared secret and no fleet membership, while a settlement node is part of something privately provisioned. That distinction is in a YAML comment rather than in a document, which is where you do not want the answer to your security model to live.

The rest of the deployment is conventional. The node writes to SQLite at /rustchain/data/rustchain_v2.db, has a downloads directory, and runs behind nginx:1.25-alpine, which publishes 80 and 443 and mounts nginx.conf read-only, with the SSL certificate mounts left commented and marked as something to create first. The node's own 8099 mapping is commented out with a note that access goes through nginx and that uncommenting it bypasses nginx security.

Two details repeat between the image and the compose file. The health check is defined twice, as a HEALTHCHECK instruction in the Dockerfile and as a healthcheck in the compose file, both curling http://localhost:8099/health on a 30 second interval with a 40 second start period. Log rotation is set to three files of 10 MB each.

Three dependency files, two Flask floors, and two Ed25519 stacks

The repository declares dependencies in more than one place, and they do not agree.

The packaging metadata lists flask>=2.0 with requests>=2.28, cryptography>=41, pynacl>=1.5, psutil>=5.9 and openapi-spec-validator held to a 0.7 series. The development requirements file lists flask>=3.1.3, and the Dockerfile installs neither of those: it copies requirements-node.txt, a third file, and installs that. Three dependency sets, one of them invisible in the two files that are visible.

The runtime also disagrees with the declared floor. The Dockerfile is python:3.11-slim while the metadata says requires-python >=3.9, so the supported range starts below anything the image demonstrates.

The requirements file is commented by purpose, which makes it readable in a way most are not. flask>=3.1.3 for node development; requests>=2.34.2 and aiohttp>=3.13.5 for the miner and SDK; cryptography>=46.0.7 for the wallet CLI, named for Ed25519 plus AES-GCM; PyNaCl>=1.6.2 for node and beacon Ed25519 verification; PyYAML and Flask-Cors for the faucet; mnemonic>=0.21 for BIP39 seed phrases; pycryptodome>=3.20.0 for EIP-55 Ethereum address checksum validation in the faucet service; and matplotlib with seaborn, listed under benchmark and visualization tests.

Two of those deserve a second look. Ed25519 verification arrives twice, through cryptography for the wallet and PyNaCl for the node, so the two halves of the signing path use different libraries. And an Ethereum checksum validator sits in a project whose token bridges to Solana.

The published package exposes one console script, and it is a compatibility lab

The Python package installs exactly one command: rustchain-compat, bound to compatibility_lab.cli:main. Nothing in that entry point is the node, the wallet, the faucet, or the miner. The chain-facing tools named throughout the requirements file are run as scripts, not installed as commands, so a pip install of this project gives you a compatibility laboratory and a library.

The declared packages are node and compatibility_lab. Package data tells you what shape the artifacts take: the node directory ships SQL and JSON files, while compatibility_lab ships read_only_api.openapi.json and a fixtures directory of JSON. That pairing explains the pinned openapi-spec-validator dependency, since the lab validates a read-only API specification against its fixtures.

Metadata around it is thin and specific. The author is listed as Scott Boudreaux / Elyan Labs with a personal mail address as the contact, the license is written as inline text rather than a license file reference, and the build backend is setuptools with wheel, not a modern backend.

The repository root holds more than code, though, and the next section is about what is sitting in it.

Eleven bounty documents and three issue reports sit in the repository root

The top level of this repository is an archive of process artifacts next to the source. Eleven files carry bounty numbers in their names: BOUNTY_1149_IMPLEMENTATION.md, BOUNTY_1524_COMMIT_REPORT.md, a matching BOUNTY_1524_VALIDATION_RESULT.json, BOUNTY_2275_FORMAL_VERIFICATION.md, BOUNTY_2276_REPLAY_DEFENSE.md, BOUNTY_2279_BOTTUBE_DIGEST_BOT.md, BOUNTY_2286_IMPLEMENTATION.md, BOUNTY_2293_BCOS_HOMEBREW.md, BOUNTY_2298_RISCV_MINER_PORT.md, BOUNTY_2301_IMPLEMENTATION.md, BOUNTY_2303_IMPLEMENTATION.md, and BOUNTY_2314_GHOST_MACHINE.md. Three more track issues by number: ISSUE_1855_PROGRESS.md, ISSUE_2640_PROGRESS.md and ISSUE_730_SUMMARY.md.

Alongside them sit documents of the same kind: ACHIEVEMENTS.md, AUDIT_REPORT.md, LEDGER_INTEGRITY_AUDIT.md, BATTLESHIP_PROGRESS.md, IMPLEMENTATION_SUMMARY.md, GHOST_IN_THE_MACHINE.md, BEEF_SYSTEM.md, BCOS.md, CPU_ANTIQUITY_SYSTEM.md, CPU_QUICK_REFERENCE.md and CLAIM_OF_OWNERSHIP.md.

Two details there are worth flagging. There is both a NOTICE and a NOTICE.md, two files that normally hold the same legal notice. And there is a file whose title is a claim about ownership, sitting next to a contributors list and a dependency bot policy, in a project whose README spends a paragraph on the lead builder's history at an earlier blockchain company.

The tooling tells the same story from the other side: a .claude/ directory, a .githooks/ directory, and both a .env.example and a .env.miner.example.

Fourteen README translations, two of them the same language

The language line at the top of the project file lists fourteen links. English, Simplified Chinese from docs/zh-CN/README.md, Simplified Chinese again from README_ZH.md at the root, Traditional Chinese, Spanish, German, Japanese, Russian, Vietnamese, Brazilian Portuguese, Hindi, Italian from docs/it-IT, and Korean. A fifteenth link is an API quick reference in Chinese under docs/zh-CN.

Two entries are the same language pointed at two files, which is either a staged migration from root to docs or a mistake that survived review. Either way, a reader following the Chinese links has two paths to check whether they agree.

The English file itself is the shortest part of the documentation set. Everything technical is delegated: a whitepaper, a quickstart, a hardware requirements page, an explorer, a manifesto, and a consulting page. The narrative sections in the root file are positioning rather than instructions, including the claim that crypto developer commits fell 75% in 2026 while Ethereum lost 34% of active developers and Solana 40%, and the statement that the token is the least interesting thing in the project.

Those figures are the project's own, and the repository contains nothing that would let you check them.

An agent's signing key is its wallet, which moves the security question

The design decision that separates this from a mining pool is in one clause: autonomous agents are first-class participants, and an agent's signing key is its wallet. There is no separate key custody story to reconcile, because the key and the account are the same object.

The payment layer is described as machine-to-machine micropayments with an RTC token and a wRTC bridge on Solana, plus Ergo anchoring as a second anchor. Media produced inside the ecosystem can carry AVAP, the Agent Video Attestation Protocol, where agents sign messages and anchor them so authorship, integrity and time of existence are checkable without an intermediary.

The comparison table draws its own lines: agentic rather than machine-learning compute against Bittensor, a novel layer-1 rather than an app on Base or BNB against Olas, Virtuals and Fetch.ai, and a stated lineage from an earlier AI chain whose first contractor and head of product is described as this project's lead builder.

Where the security argument rests, it rests on physics rather than paperwork: the claim is that a machine's compute provenance is verifiable from drift and timing that virtual machines do not have. That is the premise to test before anything else, because every other guarantee here, micropayments, agent identity, media attestation, is downstream of it.

Editorial conclusion

RustChain is two projects sharing a repository, and which half you are evaluating depends on which version number you read. If you want to run a node, you are running Python on SQLite behind nginx, with a role flag that decides whether you need a fleet secret, and you should read the deployment notes rather than the token pages. If you want to mine, you are running a Rust Windows bundle whose fingerprint logic the project itself titled a critical fix in its most recent release. Before committing either way, verify the three claims the project does not evidence in the repository: that vintage hardware out-earns modern hardware, which is a multiplier table rather than a measurement; that older CPUs really do produce distinguishable physical signals, which is the entire security premise; and that developer activity in crypto fell as the project states, since that number is used to justify the pivot.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. Scottcjn/Rustchain on GitHub